Традициям верны!
КРИЗИС ОТЕЧЕСТВЕННОЙ МИКРОЭЛЕКТРОНИКИ. ЧАСТЬ 2. ИНФОРМАЦИОННЫЕ СИСТЕМЫ.
Вот в продолжение к вчерашнему ещё одна статья Дмитрия Шевченко, обиженого на жизнь и суровую реальность нашей сказочной страны сисадмина из Зеленограда.
В современном мире проектирование изделий микро и наноэлектроники - это в первую очередь производство информации. Логично предположить, если отечественные предприятия, даже работая по модели «фаблесс» - проектирования с изготовлением на мощностях мировых фабрик не могут тягаться с мировыми компаниями этого же сегмента, то имеются проблемы в производстве, хранении, распространении, передаче и переработке требуемых объёмов информации. Для детального рассмотрения, как работает контора, проектирующая чипы, следует рассказать о историческом возникновении и смене форм производства.
Историческое развитие процесса проектирования - создания информационного продукта, в общих чертах повторяет историческое развитие промышленного производства. То же касается и организации труда. Когда-то разработчик отечественного изделия электронной техники повторял судьбу ремесленника средневековой мастерской. Сам разрабатывал схемотехнику и топологию, писал сопутствующую техническую документацию - ТУ, КД и т.д. Сам проверял топологию на наличие ошибок и соответствие схеме. Затем в области проектирования стало развиваться такое же разделение труда, как на промышленном производстве. Инженеры-конструкторы разделились на схемотехников и топологов. Далее пошло разделение инженеров по функциям в процессе разработки: аналоговых схем, схем управления питанием, процессоров, памяти и т.д. Аналогичные процессы шли в индустриальном производстве, разделяя людей на заготовителей, обработчиков (дерева, металла, кожи и т.д.) и сборщиков. Позднее с увеличением объемов производства, функция одного человека стала выполняться группой, цехом (заготовительные, обрабатывающие и сборочные цеха), или, в случае информационного общества, отделом.
Если исходить из того, что информационное производство можно описать через породившее его индустриальное производство, то получаем аналогии.
Обрабатывающим механическим цехам в производстве информации при создании микросхем соответствуют отделы разработки аналоговых схем, радиочастотных схем, схем памяти, схем процессоров и т.д. Сборочным цехам, собирающим как детали собственного производства, так и покупные, соответсвуют отделы топологий, со специализацией сборки: аналоговой и цифровой, собирающие в единую топологию как свои, так и покупные IP-блоки. Вспомогательным инструментальным цехам соответствуют штатные отделы программистов, пишущих программы-инструменты для облегчения и ускроения производства другими отделами, а также отделы поддержки. Контрольным операциям соответствуют проверки конструкторских и технологических ограничений -DRC, и соответствие изделия чертежу или соответствие топологии схеме - LVS. Транспортному хозяйству соответстуют каналы передачи информации. Складскому - дисковые массивы, объёмам несколько десятков терабайт. Станкам и машинам, обрабатывающим заготовки - система проектирования, включающая множество пакетов программ, систем и подсистем. Энергии, приводящей станки в движение - вычислительный парк серверов. И, наконец, заготовительным и ремонтным операциям - системные администраторы, выделяющие ресурсы и поддерживающие работоспособность для проектов: процессорное время и память для вычислений, дисковые массивы для хранения, скорость обмена информацией для транспортировки, права доступа аналогичные пропуску в цех.
Информационное общество также породило и новые способы увеличения интенсивности труда и фактического увеличения продолжительности рабочего дня. В отличие от индустриального производства, помимо основного рабочего времени, сотруднику предоставили возможность работать удалённо. С помощью технологий VPN-сети, сотрудники могли подключаться к вычислительным мощностям конторы и работать утром до работы или вечером после, задействуя машинное время максимально полно и ускоряя процесс проектирования. Но большую выгоду от возможности работать удалённо извлекло и руководство.
Проектные группы находились под постоянным давлением руководства с целью сокращения времени между началом разработки и отправкой топологии на фабрику. Такое давление приводило, как правило, не к интенсификации труда, при неизменном рабочем времени, а к увеличению продолжительности рабочего дня, в т.ч. неформальной за счёт удалённой работы. Возможность удалённой работы при сжимающихся сроках стала для части инженеров необходимостью. Но не только разработчики соглашались работать на новых условиях труда и отдыха.
Вечер выходного дня. Начальник отдела кадров звонит начальнику ИТ отдела, просит зайти в сеть и сбросить VPN-пароль. Устное распоряжение главным ИТ-шником было выполнено. Этот случай руководство приводило рядовым сотрудникам в качестве примера, как надо любить контору. Таким образом, с помощью современных технологий, у руководителей всех звеньев появилась возможность нагружать работой сотрудников и в выходной, и в отпуск. Звонки сотруднику, минимум 2 раза во время отпуска стали нормой. Ни о какой оплате сверхурочных работ по ТК РФ речи, конечно же, не шло.
Помимо современных способов увеличения отдачи в работе, использовались и классические. Во главу угла ставился принцип «инженер должен быть загружен работой на 100% и всегда». Это приводило к постоянному перебрасыванию инженеров с проекта на проект. Личный вклад инженера в общее дело и личная ответственность размывались между разными проектами микросхем, что с учётом давления приводило к снижению инициативы, качества и возникновению ошибок. Поэтому в спецификациях на микросхемы росло количество новых, неисправленных ошибок (errata) и медленно исправлялись старые. Аналогичные явления происходили и в индустриальную эпоху в нашей стране, когда отчуждение труда приводило к снижению качества ширпотреба настолько, что многие гнались за импортом, а склады были завалены отечественной продукцией.
В скором времени после моего трудоустройства мозайка задач и проблем конторы стала складываться в цельную картину. Объём информации систем был так обширен, что потребовал не один месяц анализа. Большинство являний конторы, принадлежащих к виртуальному миру, могут описываться явлениями реального. Решение большинства информационных проблем в момент появления потребовало бы гораздо меньше сил и средств, как вовремя сформированная садовником крона молодого дерева сэкономит затраты труда при отпиливании неправильно выросших больших веток.
Система проектирования на предприятии находилась в терминальном состоянии и требовала реанимационных мероприятий. Одной из особенностей российского строительства являются, особенно в провинции, горы мусора на стройках. Те же явления наблюдались и в виртуальном мире системы проектирования интегральных схем. Обычно такие системы разворачиваются на «железе» под управлением linux и состоят трех частей.
Первая часть включает структуру каталогов хранения информации её клиентскую и серверную части. Вторая часть организует отслеживание ошибок или назначение задач, что сейчас слилось в функционале трекинг систем. Третья часть отвечает за контроль версий файлов и соответственно называется системой контроля версий (далее СКВ).
Несмотря на то, что системы контроля версий существуют относительно давно: CVS c 1990 г., SVN с 2000 г., и GIT с 2004 г., внедрение СКВ в конторе началось только в 2012 году. Выбор конторы пал на Cliosoft SOS, типичное клиент-серверное приложение, заточенное под процесс проектирования аналоговых интегральных схем. Центральное хранилище располагалось на сервере. Рабочие копии в виде ссылок на файлы сервера находились у клиентов, приводя к экономии дискового пространства.
В это же время провинциальный филиал, брошенный без поддержки центра на произвол судьбы, выбрал SVN. Часто в своей работе «изобретал велосипеды» при решении задач, с какими головная контора справилась много лет назад.
Большинство начальников пришло в контору, если не с основания, то в первые годы её работы. В те времена контора состояла из десятка-другого знавших друг друга разработчиков, сидевших максимум в двух помещениях. Обмен файлами между разработчиками происходил стихийно. После бурных государственных вливаний в микроэлектронику в течение более чем десятка лет, штат разработчиков микросхем вырос за сотню человек. На личностном уровне стало работать невозможно. Вот тогда и начали в спешном порядке внедрять систему. Это ещё одна особенность отечественных контор, не развиваться планомерно, а «тушить пожар», когда «горит». Результаты такой спешки, вместе с одноразовыми решениями, «подпорками», «костылями» и приходилось мне разгребать после предшественника.
С разрастанием парка серверов предыдущий админ системы проектирования не обновлял версии программ СКВ, а каждый раз при установке нового сервера устанавливал новую версию. В итоге было 2 несовместимых версии СКВ, 6-я и 7-я. Причём на 7-й было по вышеназванным причинам 5 подверсий. «Зоопарк» на разных серверах, вызывал у пользователей системы - разработчиков микросхем ошибки доступа и файловые конфликты. Название групп доступа к файлам менялось предшественником раза три, вызывая проблемы с обращением к файлам через СКВ из одного сервера к другому или у одного клиента к двум серверам. Помимо этого провинциальный филиал насоздавал десяток проектов микросхем в СКВ SVN, модули которых из-за несовпадения систем контроля версий в работе, было нельзя использовать и поддерживать в других проектах, сохраняя историю изменений. Да ещё несколько десятков проектов лежало «меловыми отложениями» в наследство от эпохи, не знавшей версионирования. Это были только первые скелеты в шкафу конторы...
Если для САПР большой тройки: Cadence, Mentor, Synopsys; имелась хоть какая-то однозначная структура хранения информации, то для библиотек и комплектов разработчика (PDK) на файловых хранилищах лежали настоящие авгиевы конюшни. Представьте себе библиотеку, в которой книги стоят на стеллажах не на своих местах. Третья часть книжного фонда валяется в кучах на полу. При этом центральный каталог ведётся, как придётся. В некоторых книгах не хватает страниц, а другие лежат в нескольких одинаковых экземплярах, листы которых перепутаны. Из-за чего все считают копии одной книги разными. Часть обложек не соответствует содержанию книжек. И каждый месяц прибывают штук по 20 томов размера БСЭ. Переведите на язык файлов и папок - вы получите картину маслом.
Жалкое подобие системы сосуществовало с хаотичным разбросом файлов, их версий, папок, неверных названий, неверных путей и занимало место 1,3 Терабайт. Из всех средств отслеживания и учёта информации (аналога книг/карточек складского учета на производстве), установленной в эту кучу была только почта предыдущего админа, из которой восстановить историю наполнения и изменения не представлялось возможным. Вскоре выяснилось, что не только админ мог изменять файлы в куче. Правами на изменения файлов обладал также начальник отдела разработки топологий, который менял свои файлы без согласования с админом. А также те пользователи, кто на личном уровне попросили предыдущего админа систем сделать в отдельные папки полный доступ - своеобразные чёрные ходы. Помимо этого существовала иерархия проектных папок с пользовательскими папками внутри, чье содержимое анализировать ещё предстояло.
Т.к. работающую систему на исправление и обслуживание останавливать нельзя, то работа админа напоминает трюки каскадёра по замене колеса машины, мчащейся на полном ходу. При этом подразумевают, что «каскадёр-пожарник» должен быть «человеком-заводом» выполнять ещё другую работу, например помимо реанимации систем поддерживать работу пользователей на рабочих машинах, в случае возникновения проблем, скачивать библиотеки у фабрик, а также писать инструменты для миграции проектов между фабриками.
В день по работе приходило по 20 разнородных вопросов, начиная от «не могу забрать файл» и заканчивая «скачать и установить библиотеку X в папку Y». Сроки задач варьировались от «исправить как можно скорее» до «сделать в течение квартала».
Т.к. возникновение ошибки, вопроса или задачи - процесс случайный, то для анализа состояния системы проектирования необходимо накапливать их статистику. Полученное распределение ошибок по времени и частоте возникновения даёт детальную картину о проблемах и хронических болезнях систем. Также статистика помогает расставить приоритеты их решения, при ограниченных временных и человеческих ресурсах.
Из анализа списка обращений сотрудников за первый месяц, на первом месте стояли нарушения в работе СКВ. Поэтому был сделан вывод о первоочерёдности реанимации СКВ, пока она окончательно не умерла, парализовав работу дизайн-центра. Затем планировал анализировать, упорядочивать иерархию библиотек и сделать нормальную книгу учёта поступающей и изменяемой информации, т.к. по трудозатратам и обращениям заготовительная операция - выкачивание и установка файлов с фабрик занимала второе место.
Через месяц работ зоопарк взаимоглючных версий и подверсий сократился до двух: шестой и седьмой, не совместимых меж собой.
Скоро наступали майские праздники - время, когда админы могли заняться приведением систем в порядок, как в индустриальную эпоху пустели цеха по праздникам, давая возможность сервисным службам завозить оборудование, капитально ремонтировать станки, а энергетикам прокладывать новые магистрали воды, электричества, газа и т.д. Договорился с админами linux о проведении массовых ремонтных операций во время майских праздников, совмещая их работы с операционными системами и мою, с системами проектирования. Но в связи с круглосуточной работой серверов, накапливались задачи, отложенные до перезапуска. Сроки обслуживания постоянно сдвигались так, что за праздники админы еле успели сделать свою накопившуюся работу, требующую перезагрузки серверов. Эстафету мне передали, когда настал рабочий день. И в течение трёх рабочих дней, при крайнем неудовольствии, сопротивлении и попытках отката назад отдельных разработчиков я привёл всю систему головного офиса конторы к единой версии СКВ. После переподключений пользователей на рабочих местах к новой системе часть проблем испарилось как утренний туман. В админке СКВ красовались одинаковые версии системы. Волна обращений схлынула. Но праздновать победу было рано. Расчистка одного завала привела к обнаружению следующего. Локализовалась причина проблем с: проектными группами, ошибками доступа, созданием снимков текущего состояния разработки, подключения блоков других проектов. Поля доступа БД в СКВ по причине небрежного администрирования предшественником, оставались либо пустыми, либо содержали разные названия групп, приводя к блокировкам обращений. Решение этих проблем требовало проверки всех баз данных проектов. Но, с учётом политики максимально полной загрузки сотрудика задачами, выделение месяца работ в рабочее время на исправление баз было проблематичным.
Решение вопроса с рабочим временем напоминало решение двух математических задач. Первой была о двумерной упаковке - разместить в рюкзаке вещи с максимальной стоимостью в минимальный объём. Второй была задача о раскраске графа - однородные задачи нуждались в разбавлении творческими. Иначе от рутины падала производительность. Сроки выполнения и количество задач, падающих в единицу времени или обнаруженных в процессе работы, как уже говорилось, менялись в широких пределах от минут до месяцев. Сами времена выполнения задач и были теми «предметами», которые надо было уложить в «рюкзак», шириной в рабочий день, с допущением небольшого расширения для срочных вопросов так, чтобы время выполнения всех накопившихся задач, распределённых по разным рабочим дням было минимальным.
С учётом загрузки меня поддержкой пользователей и установкой обновлений фабричных поставок, изначально времени на исправление баз не было. Но после применения математического подхода к проблеме рабочего времени, резервы появились, и встала необходимость вынесения крупных задач в план. Как раз в это время проектными менеджерами внедрялась система назначения задач сотрудникам. Исходя из того, что любой, даже самый плохой план много лучше стихийного «пожаротушения» и переработок, я приложил все усилия, по внесению задач проверки баз в план. Хотя система назначения задач была крайне неудобная, двигала задачи без согласования с пользователем и не строила диаграммы Ганта, это было куда лучше, чем обслуживание системы проектирования в аврально-простойном режиме, так часто встречаемом на отечественных предприятиях.
После задания равномерной загрузки на месяц, появилось время анализировать всё остальное. Первое, до чего дошли руки, была структура каталогов, хранивших фабричные поставки комплектов разработчиков (PDK), библиотек (STD, I/O, PADs) и прочих инструментов проектирования, поставляемых иностранными полупроводниковыми фабриками. У каждой полупроводниковой фабрики была своя структура и иерархия хранения данных. Они были небрежно развёрнуты моими предшественниками в общей структуре каталогов. Кроме самих разработчиков, использующих библиотеки, было проблематично и практически невозможно определить версию, назначение, необходимость обновления, местонахождение зависимой информации и используемость библиотек.
После изучения структуры нагромождений и завалов в библиотеках фабрик, у меня сложилось впечатление, что часть библиотек лежит горой мусора. Для проверки предположения, мной был написан скрипт для командной оболочки bash, просматривающий содержимое файлов с поиском обращений из пользовательских рабочих папкок в фабричные каталоги. Результаты его работы оказались довольно неожиданными. По пользовательским путям в lib-файлах и символическим ссылкам следовало, что пользователи-разработчики массово работают мимо системы контроля версий, ссылаясь на рабочие папки друг друга. Или, как говорят специалисты IT - работают мимо репозитория. Результаты такого теневого обмена не заставляли себя долго ждать. Файлы, папки и целые библиотеки терялись регулярно. Затем силами сотрудников и админов всё кропотливо восстанавливалось неделями, и так до следующего исчезновения.
Другим следствием работы мимо репозитория и создания ссылок между пользовательскими папками друг на друга, стала невозможность быстрого изготовления из этой информации сложнофункциональных блоков (IP-блоков) на продажу. Проекты переплелись друг в друга, как корни деревьев. Это не давало извлечь проекты из рабочей области без потери части информации. Судя по такой низкой культуре работы с проектами, в конторе никогда и не ставилась задача делать IP-блоки на продажу.
Конечно, все эти проблемы можно было решать по мере сил при неизменных объёмах производства информации в конторе. Но логика развития системы не оставляла даже шанса на спокойное и планомерное решение поступающих задач. В микропроцессорной технике развитие по экспоненциальному закону называют законом Мура. По закону Мура росло и число сотрудников в конторе год от года. Также, чем меньше проектные нормы фабрики в нанометрах, тем больший обьём информации приходится хранить и перерабатывать дизайн-центру. Для проверки гипотезы я запросил админов linux график заполнения хранилищ с самого начала ведения статистики. Зависимость количества хранимой информации от времени также была экспоненциальной. И мы находились в точке, когда экспонента резко разворачивается вверх. Такие объёмы информации можно обрабатывать только, если она упорядочена.
Видя проблему масштаба всего дизайн-центра, я поднял вопрос на уровне директора.
Решением должно было послужить введение стандартов и регламентов - законов, по которым налаживается централизованный обмен и хранение: система контроля версий, как единственный источник обмена с уничтожением теневого обмена файлами пользователей, единая структура хранения данных, всеобщая инвентаризация информации с установлением происхождения и назначения библиотек, параллельно с упорядочиванием журнала изменений в единую иерархическую систему задач и ошибок. Решение было далеко не новым. Банковская система для юридических лиц работает по такому же принципу, осуществляя расчёты посредством системы АБС. При этом теневой обмен наличными, не отражённый больше лимита, либо не отражённый в документах не допускается.
Но гладко бывает, как известно, только на бумаге. Говоря словами индустриальной эпохи, пошло сопротивление начальников отделов упорядочиванию и инвентаризации хранящихся на складах материально-производственных запасов, введению единого складского учёта и единого пропускного режима - доступа к общей фабричной информации на запись.
Начальники не хотели ничего менять в сложившемся положении дел, т.к. «всё и так работает». Директор на себя ответственность по изменениям брать не стал. Бардак многих устраивал, а убедить людей в отечественных конторах в необходимости изменений, как это часто случается в ведущих западных компаниях и о чём пишут в книгах по бизнесу, не представляется возможным.
Если отстаёт уровень организации труда и уровень человеческого сознания начальников от передовых мировых достижений, то никакими силами и никакими средствами нельзя устоявшийся коллектив людей заставить работать по-новому. При любых попытках внедрения нового, такая стабильно работающая система либо переламывает отдельного человека под себя, лишив его личостных качеств, либо выплёвывает, не сумев переварить. Единственным вариантом внедрения передовых методов может быть «пожар», когда идёт угроза глобальной остановки производства, и стоит вопрос жизни и смерти контор или колоссальных убытков. И здесь не обходится без переработок сотрудников, которых начальство тщетно пытается заставить за несколько дней сделать работу нескольких лет.
Впрочем, руководство на уровне генерального видело проблемы с ухудшением качества управления компанией при её росте. Но решать организационные проблемы пыталось, повысив накал корпоративной идеологии: личностными планами развития, фотосессиями с корпоративной атрибутикой, игрищами: командными, спортивными и азартными; корпоративами, кодексом этики - в общем, чем угодно кроме научного анализа процессов, протекающих в конторе.
написано 07 ноября 2017
ЗЫ бороться со старыми МЭПовскими традициями?! Если некое явление живёт полвека, то наверное так как минимум кому-нибудь надо. Первая часть доступна здесь.
Вот в продолжение к вчерашнему ещё одна статья Дмитрия Шевченко, обиженого на жизнь и суровую реальность нашей сказочной страны сисадмина из Зеленограда.
В современном мире проектирование изделий микро и наноэлектроники - это в первую очередь производство информации. Логично предположить, если отечественные предприятия, даже работая по модели «фаблесс» - проектирования с изготовлением на мощностях мировых фабрик не могут тягаться с мировыми компаниями этого же сегмента, то имеются проблемы в производстве, хранении, распространении, передаче и переработке требуемых объёмов информации. Для детального рассмотрения, как работает контора, проектирующая чипы, следует рассказать о историческом возникновении и смене форм производства.
Историческое развитие процесса проектирования - создания информационного продукта, в общих чертах повторяет историческое развитие промышленного производства. То же касается и организации труда. Когда-то разработчик отечественного изделия электронной техники повторял судьбу ремесленника средневековой мастерской. Сам разрабатывал схемотехнику и топологию, писал сопутствующую техническую документацию - ТУ, КД и т.д. Сам проверял топологию на наличие ошибок и соответствие схеме. Затем в области проектирования стало развиваться такое же разделение труда, как на промышленном производстве. Инженеры-конструкторы разделились на схемотехников и топологов. Далее пошло разделение инженеров по функциям в процессе разработки: аналоговых схем, схем управления питанием, процессоров, памяти и т.д. Аналогичные процессы шли в индустриальном производстве, разделяя людей на заготовителей, обработчиков (дерева, металла, кожи и т.д.) и сборщиков. Позднее с увеличением объемов производства, функция одного человека стала выполняться группой, цехом (заготовительные, обрабатывающие и сборочные цеха), или, в случае информационного общества, отделом.
Если исходить из того, что информационное производство можно описать через породившее его индустриальное производство, то получаем аналогии.
Обрабатывающим механическим цехам в производстве информации при создании микросхем соответствуют отделы разработки аналоговых схем, радиочастотных схем, схем памяти, схем процессоров и т.д. Сборочным цехам, собирающим как детали собственного производства, так и покупные, соответсвуют отделы топологий, со специализацией сборки: аналоговой и цифровой, собирающие в единую топологию как свои, так и покупные IP-блоки. Вспомогательным инструментальным цехам соответствуют штатные отделы программистов, пишущих программы-инструменты для облегчения и ускроения производства другими отделами, а также отделы поддержки. Контрольным операциям соответствуют проверки конструкторских и технологических ограничений -DRC, и соответствие изделия чертежу или соответствие топологии схеме - LVS. Транспортному хозяйству соответстуют каналы передачи информации. Складскому - дисковые массивы, объёмам несколько десятков терабайт. Станкам и машинам, обрабатывающим заготовки - система проектирования, включающая множество пакетов программ, систем и подсистем. Энергии, приводящей станки в движение - вычислительный парк серверов. И, наконец, заготовительным и ремонтным операциям - системные администраторы, выделяющие ресурсы и поддерживающие работоспособность для проектов: процессорное время и память для вычислений, дисковые массивы для хранения, скорость обмена информацией для транспортировки, права доступа аналогичные пропуску в цех.
Информационное общество также породило и новые способы увеличения интенсивности труда и фактического увеличения продолжительности рабочего дня. В отличие от индустриального производства, помимо основного рабочего времени, сотруднику предоставили возможность работать удалённо. С помощью технологий VPN-сети, сотрудники могли подключаться к вычислительным мощностям конторы и работать утром до работы или вечером после, задействуя машинное время максимально полно и ускоряя процесс проектирования. Но большую выгоду от возможности работать удалённо извлекло и руководство.
Проектные группы находились под постоянным давлением руководства с целью сокращения времени между началом разработки и отправкой топологии на фабрику. Такое давление приводило, как правило, не к интенсификации труда, при неизменном рабочем времени, а к увеличению продолжительности рабочего дня, в т.ч. неформальной за счёт удалённой работы. Возможность удалённой работы при сжимающихся сроках стала для части инженеров необходимостью. Но не только разработчики соглашались работать на новых условиях труда и отдыха.
Вечер выходного дня. Начальник отдела кадров звонит начальнику ИТ отдела, просит зайти в сеть и сбросить VPN-пароль. Устное распоряжение главным ИТ-шником было выполнено. Этот случай руководство приводило рядовым сотрудникам в качестве примера, как надо любить контору. Таким образом, с помощью современных технологий, у руководителей всех звеньев появилась возможность нагружать работой сотрудников и в выходной, и в отпуск. Звонки сотруднику, минимум 2 раза во время отпуска стали нормой. Ни о какой оплате сверхурочных работ по ТК РФ речи, конечно же, не шло.
Помимо современных способов увеличения отдачи в работе, использовались и классические. Во главу угла ставился принцип «инженер должен быть загружен работой на 100% и всегда». Это приводило к постоянному перебрасыванию инженеров с проекта на проект. Личный вклад инженера в общее дело и личная ответственность размывались между разными проектами микросхем, что с учётом давления приводило к снижению инициативы, качества и возникновению ошибок. Поэтому в спецификациях на микросхемы росло количество новых, неисправленных ошибок (errata) и медленно исправлялись старые. Аналогичные явления происходили и в индустриальную эпоху в нашей стране, когда отчуждение труда приводило к снижению качества ширпотреба настолько, что многие гнались за импортом, а склады были завалены отечественной продукцией.
В скором времени после моего трудоустройства мозайка задач и проблем конторы стала складываться в цельную картину. Объём информации систем был так обширен, что потребовал не один месяц анализа. Большинство являний конторы, принадлежащих к виртуальному миру, могут описываться явлениями реального. Решение большинства информационных проблем в момент появления потребовало бы гораздо меньше сил и средств, как вовремя сформированная садовником крона молодого дерева сэкономит затраты труда при отпиливании неправильно выросших больших веток.
Система проектирования на предприятии находилась в терминальном состоянии и требовала реанимационных мероприятий. Одной из особенностей российского строительства являются, особенно в провинции, горы мусора на стройках. Те же явления наблюдались и в виртуальном мире системы проектирования интегральных схем. Обычно такие системы разворачиваются на «железе» под управлением linux и состоят трех частей.
Первая часть включает структуру каталогов хранения информации её клиентскую и серверную части. Вторая часть организует отслеживание ошибок или назначение задач, что сейчас слилось в функционале трекинг систем. Третья часть отвечает за контроль версий файлов и соответственно называется системой контроля версий (далее СКВ).
Несмотря на то, что системы контроля версий существуют относительно давно: CVS c 1990 г., SVN с 2000 г., и GIT с 2004 г., внедрение СКВ в конторе началось только в 2012 году. Выбор конторы пал на Cliosoft SOS, типичное клиент-серверное приложение, заточенное под процесс проектирования аналоговых интегральных схем. Центральное хранилище располагалось на сервере. Рабочие копии в виде ссылок на файлы сервера находились у клиентов, приводя к экономии дискового пространства.
В это же время провинциальный филиал, брошенный без поддержки центра на произвол судьбы, выбрал SVN. Часто в своей работе «изобретал велосипеды» при решении задач, с какими головная контора справилась много лет назад.
Большинство начальников пришло в контору, если не с основания, то в первые годы её работы. В те времена контора состояла из десятка-другого знавших друг друга разработчиков, сидевших максимум в двух помещениях. Обмен файлами между разработчиками происходил стихийно. После бурных государственных вливаний в микроэлектронику в течение более чем десятка лет, штат разработчиков микросхем вырос за сотню человек. На личностном уровне стало работать невозможно. Вот тогда и начали в спешном порядке внедрять систему. Это ещё одна особенность отечественных контор, не развиваться планомерно, а «тушить пожар», когда «горит». Результаты такой спешки, вместе с одноразовыми решениями, «подпорками», «костылями» и приходилось мне разгребать после предшественника.
С разрастанием парка серверов предыдущий админ системы проектирования не обновлял версии программ СКВ, а каждый раз при установке нового сервера устанавливал новую версию. В итоге было 2 несовместимых версии СКВ, 6-я и 7-я. Причём на 7-й было по вышеназванным причинам 5 подверсий. «Зоопарк» на разных серверах, вызывал у пользователей системы - разработчиков микросхем ошибки доступа и файловые конфликты. Название групп доступа к файлам менялось предшественником раза три, вызывая проблемы с обращением к файлам через СКВ из одного сервера к другому или у одного клиента к двум серверам. Помимо этого провинциальный филиал насоздавал десяток проектов микросхем в СКВ SVN, модули которых из-за несовпадения систем контроля версий в работе, было нельзя использовать и поддерживать в других проектах, сохраняя историю изменений. Да ещё несколько десятков проектов лежало «меловыми отложениями» в наследство от эпохи, не знавшей версионирования. Это были только первые скелеты в шкафу конторы...
Если для САПР большой тройки: Cadence, Mentor, Synopsys; имелась хоть какая-то однозначная структура хранения информации, то для библиотек и комплектов разработчика (PDK) на файловых хранилищах лежали настоящие авгиевы конюшни. Представьте себе библиотеку, в которой книги стоят на стеллажах не на своих местах. Третья часть книжного фонда валяется в кучах на полу. При этом центральный каталог ведётся, как придётся. В некоторых книгах не хватает страниц, а другие лежат в нескольких одинаковых экземплярах, листы которых перепутаны. Из-за чего все считают копии одной книги разными. Часть обложек не соответствует содержанию книжек. И каждый месяц прибывают штук по 20 томов размера БСЭ. Переведите на язык файлов и папок - вы получите картину маслом.
Жалкое подобие системы сосуществовало с хаотичным разбросом файлов, их версий, папок, неверных названий, неверных путей и занимало место 1,3 Терабайт. Из всех средств отслеживания и учёта информации (аналога книг/карточек складского учета на производстве), установленной в эту кучу была только почта предыдущего админа, из которой восстановить историю наполнения и изменения не представлялось возможным. Вскоре выяснилось, что не только админ мог изменять файлы в куче. Правами на изменения файлов обладал также начальник отдела разработки топологий, который менял свои файлы без согласования с админом. А также те пользователи, кто на личном уровне попросили предыдущего админа систем сделать в отдельные папки полный доступ - своеобразные чёрные ходы. Помимо этого существовала иерархия проектных папок с пользовательскими папками внутри, чье содержимое анализировать ещё предстояло.
Т.к. работающую систему на исправление и обслуживание останавливать нельзя, то работа админа напоминает трюки каскадёра по замене колеса машины, мчащейся на полном ходу. При этом подразумевают, что «каскадёр-пожарник» должен быть «человеком-заводом» выполнять ещё другую работу, например помимо реанимации систем поддерживать работу пользователей на рабочих машинах, в случае возникновения проблем, скачивать библиотеки у фабрик, а также писать инструменты для миграции проектов между фабриками.
В день по работе приходило по 20 разнородных вопросов, начиная от «не могу забрать файл» и заканчивая «скачать и установить библиотеку X в папку Y». Сроки задач варьировались от «исправить как можно скорее» до «сделать в течение квартала».
Т.к. возникновение ошибки, вопроса или задачи - процесс случайный, то для анализа состояния системы проектирования необходимо накапливать их статистику. Полученное распределение ошибок по времени и частоте возникновения даёт детальную картину о проблемах и хронических болезнях систем. Также статистика помогает расставить приоритеты их решения, при ограниченных временных и человеческих ресурсах.
Из анализа списка обращений сотрудников за первый месяц, на первом месте стояли нарушения в работе СКВ. Поэтому был сделан вывод о первоочерёдности реанимации СКВ, пока она окончательно не умерла, парализовав работу дизайн-центра. Затем планировал анализировать, упорядочивать иерархию библиотек и сделать нормальную книгу учёта поступающей и изменяемой информации, т.к. по трудозатратам и обращениям заготовительная операция - выкачивание и установка файлов с фабрик занимала второе место.
Через месяц работ зоопарк взаимоглючных версий и подверсий сократился до двух: шестой и седьмой, не совместимых меж собой.
Скоро наступали майские праздники - время, когда админы могли заняться приведением систем в порядок, как в индустриальную эпоху пустели цеха по праздникам, давая возможность сервисным службам завозить оборудование, капитально ремонтировать станки, а энергетикам прокладывать новые магистрали воды, электричества, газа и т.д. Договорился с админами linux о проведении массовых ремонтных операций во время майских праздников, совмещая их работы с операционными системами и мою, с системами проектирования. Но в связи с круглосуточной работой серверов, накапливались задачи, отложенные до перезапуска. Сроки обслуживания постоянно сдвигались так, что за праздники админы еле успели сделать свою накопившуюся работу, требующую перезагрузки серверов. Эстафету мне передали, когда настал рабочий день. И в течение трёх рабочих дней, при крайнем неудовольствии, сопротивлении и попытках отката назад отдельных разработчиков я привёл всю систему головного офиса конторы к единой версии СКВ. После переподключений пользователей на рабочих местах к новой системе часть проблем испарилось как утренний туман. В админке СКВ красовались одинаковые версии системы. Волна обращений схлынула. Но праздновать победу было рано. Расчистка одного завала привела к обнаружению следующего. Локализовалась причина проблем с: проектными группами, ошибками доступа, созданием снимков текущего состояния разработки, подключения блоков других проектов. Поля доступа БД в СКВ по причине небрежного администрирования предшественником, оставались либо пустыми, либо содержали разные названия групп, приводя к блокировкам обращений. Решение этих проблем требовало проверки всех баз данных проектов. Но, с учётом политики максимально полной загрузки сотрудика задачами, выделение месяца работ в рабочее время на исправление баз было проблематичным.
Решение вопроса с рабочим временем напоминало решение двух математических задач. Первой была о двумерной упаковке - разместить в рюкзаке вещи с максимальной стоимостью в минимальный объём. Второй была задача о раскраске графа - однородные задачи нуждались в разбавлении творческими. Иначе от рутины падала производительность. Сроки выполнения и количество задач, падающих в единицу времени или обнаруженных в процессе работы, как уже говорилось, менялись в широких пределах от минут до месяцев. Сами времена выполнения задач и были теми «предметами», которые надо было уложить в «рюкзак», шириной в рабочий день, с допущением небольшого расширения для срочных вопросов так, чтобы время выполнения всех накопившихся задач, распределённых по разным рабочим дням было минимальным.
С учётом загрузки меня поддержкой пользователей и установкой обновлений фабричных поставок, изначально времени на исправление баз не было. Но после применения математического подхода к проблеме рабочего времени, резервы появились, и встала необходимость вынесения крупных задач в план. Как раз в это время проектными менеджерами внедрялась система назначения задач сотрудникам. Исходя из того, что любой, даже самый плохой план много лучше стихийного «пожаротушения» и переработок, я приложил все усилия, по внесению задач проверки баз в план. Хотя система назначения задач была крайне неудобная, двигала задачи без согласования с пользователем и не строила диаграммы Ганта, это было куда лучше, чем обслуживание системы проектирования в аврально-простойном режиме, так часто встречаемом на отечественных предприятиях.
После задания равномерной загрузки на месяц, появилось время анализировать всё остальное. Первое, до чего дошли руки, была структура каталогов, хранивших фабричные поставки комплектов разработчиков (PDK), библиотек (STD, I/O, PADs) и прочих инструментов проектирования, поставляемых иностранными полупроводниковыми фабриками. У каждой полупроводниковой фабрики была своя структура и иерархия хранения данных. Они были небрежно развёрнуты моими предшественниками в общей структуре каталогов. Кроме самих разработчиков, использующих библиотеки, было проблематично и практически невозможно определить версию, назначение, необходимость обновления, местонахождение зависимой информации и используемость библиотек.
После изучения структуры нагромождений и завалов в библиотеках фабрик, у меня сложилось впечатление, что часть библиотек лежит горой мусора. Для проверки предположения, мной был написан скрипт для командной оболочки bash, просматривающий содержимое файлов с поиском обращений из пользовательских рабочих папкок в фабричные каталоги. Результаты его работы оказались довольно неожиданными. По пользовательским путям в lib-файлах и символическим ссылкам следовало, что пользователи-разработчики массово работают мимо системы контроля версий, ссылаясь на рабочие папки друг друга. Или, как говорят специалисты IT - работают мимо репозитория. Результаты такого теневого обмена не заставляли себя долго ждать. Файлы, папки и целые библиотеки терялись регулярно. Затем силами сотрудников и админов всё кропотливо восстанавливалось неделями, и так до следующего исчезновения.
Другим следствием работы мимо репозитория и создания ссылок между пользовательскими папками друг на друга, стала невозможность быстрого изготовления из этой информации сложнофункциональных блоков (IP-блоков) на продажу. Проекты переплелись друг в друга, как корни деревьев. Это не давало извлечь проекты из рабочей области без потери части информации. Судя по такой низкой культуре работы с проектами, в конторе никогда и не ставилась задача делать IP-блоки на продажу.
Конечно, все эти проблемы можно было решать по мере сил при неизменных объёмах производства информации в конторе. Но логика развития системы не оставляла даже шанса на спокойное и планомерное решение поступающих задач. В микропроцессорной технике развитие по экспоненциальному закону называют законом Мура. По закону Мура росло и число сотрудников в конторе год от года. Также, чем меньше проектные нормы фабрики в нанометрах, тем больший обьём информации приходится хранить и перерабатывать дизайн-центру. Для проверки гипотезы я запросил админов linux график заполнения хранилищ с самого начала ведения статистики. Зависимость количества хранимой информации от времени также была экспоненциальной. И мы находились в точке, когда экспонента резко разворачивается вверх. Такие объёмы информации можно обрабатывать только, если она упорядочена.
Видя проблему масштаба всего дизайн-центра, я поднял вопрос на уровне директора.
Решением должно было послужить введение стандартов и регламентов - законов, по которым налаживается централизованный обмен и хранение: система контроля версий, как единственный источник обмена с уничтожением теневого обмена файлами пользователей, единая структура хранения данных, всеобщая инвентаризация информации с установлением происхождения и назначения библиотек, параллельно с упорядочиванием журнала изменений в единую иерархическую систему задач и ошибок. Решение было далеко не новым. Банковская система для юридических лиц работает по такому же принципу, осуществляя расчёты посредством системы АБС. При этом теневой обмен наличными, не отражённый больше лимита, либо не отражённый в документах не допускается.
Но гладко бывает, как известно, только на бумаге. Говоря словами индустриальной эпохи, пошло сопротивление начальников отделов упорядочиванию и инвентаризации хранящихся на складах материально-производственных запасов, введению единого складского учёта и единого пропускного режима - доступа к общей фабричной информации на запись.
Начальники не хотели ничего менять в сложившемся положении дел, т.к. «всё и так работает». Директор на себя ответственность по изменениям брать не стал. Бардак многих устраивал, а убедить людей в отечественных конторах в необходимости изменений, как это часто случается в ведущих западных компаниях и о чём пишут в книгах по бизнесу, не представляется возможным.
Если отстаёт уровень организации труда и уровень человеческого сознания начальников от передовых мировых достижений, то никакими силами и никакими средствами нельзя устоявшийся коллектив людей заставить работать по-новому. При любых попытках внедрения нового, такая стабильно работающая система либо переламывает отдельного человека под себя, лишив его личостных качеств, либо выплёвывает, не сумев переварить. Единственным вариантом внедрения передовых методов может быть «пожар», когда идёт угроза глобальной остановки производства, и стоит вопрос жизни и смерти контор или колоссальных убытков. И здесь не обходится без переработок сотрудников, которых начальство тщетно пытается заставить за несколько дней сделать работу нескольких лет.
Впрочем, руководство на уровне генерального видело проблемы с ухудшением качества управления компанией при её росте. Но решать организационные проблемы пыталось, повысив накал корпоративной идеологии: личностными планами развития, фотосессиями с корпоративной атрибутикой, игрищами: командными, спортивными и азартными; корпоративами, кодексом этики - в общем, чем угодно кроме научного анализа процессов, протекающих в конторе.
написано 07 ноября 2017
ЗЫ бороться со старыми МЭПовскими традициями?! Если некое явление живёт полвека, то наверное так как минимум кому-нибудь надо. Первая часть доступна здесь.