Запуск любого производства, будь то сервера для дата-центра или бытовой электроники, строится на трёх ключевых столпах: техническая документация (ТД), тестовая оснастка (ТО) и тестовое программное обеспечение (ТПО). Эти три элемента — основа реализации массового производства: от первого прототипа до серийной партии. Но довести их до совершенства практически невозможно. Всегда можно сделать что-то лучше: добавить новые функции в ПО, сделать новый чертёж в ТД или улучшить функциональность тестовых стендов. Однако жесткие сроки, бюджеты и нехватка ресурсов заставляют выбирать, где быть идеалистом, а где — прагматиком.

В статье мы рассмотрим, как находить этот компромисс между теорией и практикой. Мы обсудим подходы к созданию ТД и ТПО, поймем, как конфликты между инженерами и управленцами влияют на производственный цикл, и разберем ситуацию, когда важно остановить разработку вовремя, даже если задача выглядит всё ещё "недоделанной". Эта статья адресована инженерам, технологам, проектировщикам, а также менеджерам, которые хотят глубже понять сложный процесс превращения технических идей в реально работающие продукты.

Практики и академики

Отмечу два диаметрально противоположных подхода к ТД, ТО и ТПО. Первая крайность, когда некоторые ТД не написали вообще, а многое написано только для того, чтобы сослаться на существование документа. Адепты такого подхода утверждают, что ГОСТы и ЕСКД нужно, дальше цитирую: "...Для того, чтобы старые пердуны у контрактников могли объяснить, почему качественно и в срок не выполнили наш заказ. Это я тебе как практик говорю".

Второй подход встречается реже. Его адепты настаивают на соблюдении всех требований написания ТД, согласно стандартам. И на все замечания у них есть ссылка на ГОСТ, для подкрепления своих слов. Собственно, на этом всё. Совершенно не обязательно, что когда-нибудь ОКР будет завершён. Это не является целью адептов данного подхода. Кстати, когда Вы слышите ссылку на ГОСТ, просите конкретики. Если автор замечания на самом деле знает ГОСТ, то он сошлётся на разделы, подразделы, пункты и подпункты. Но не будет козырять ГОСТом целиком.

Игроки и фракции

В процессе разработки изделия принимают участие специалисты, которых автор условно разделит на инженеров и управленцев. Инженерам, за редчайшим исключением, остро не хватает ресурсов: времени, размера сетевого хранилища, мощности серверов, внешних SSD, их скорости и объёма, и так далее. Автор этой статьи - инженер с опытом работы с электроникой более 15 лет. И большую часть времени испытывал разной степени нехватку информации, времени, оборудования или расходных материалов. Управленцам же, обычно, остро не хватает исполнителей - инженеров. Им приходится перераспределять дефицитные ресурсы между исполнителями задач и, фактически, заставлять исполнителей выдавать результаты в условиях нехватки кадров, времени, оборудования, даже мощности кондиционеров и количества розеток (когда нельзя добавить ещё один сервер в стойку, так как помещение перегревается и не хватает электрической мощности розеток).

В интересах инженеров получить больше ресурсов и взять на себя меньше обязательств. А в интересах управленцев экономить ресурсы и выжимать из инженеров больше результатов, которые можно преподнести начальству выше. Хотя, бывает, что "игроки" начинают играть за чужую команду. Иной инженер готов выпустить "сырой" продукт под давлением начальника, зная, что несварение от "сырости" будет не у него. А вот РПшник бьётся за обеспечение своих исполнителей необходимым оборудованием. Ситуационная логика и временные союзы, фракции и группировки, политика и многоходовки. Но если обе фракции "тёртые калачи", то скоро наступает паритет. И большая часть действующих лиц концентрирует свои усилия на заработке денег для компании при минимуме издержек для себя.

Точные параметры и параметры для справки

Прежде, чем продолжать развивать свою мысль, нужно сделать важное замечание. В конструкторской документации бывают точные размеры и размеры для справки. Точные размеры представляют собой конкретные параметры, которые должны быть соблюдены при производстве деталей или сборке изделия. Например, если в документации указано, что длина детали должна составлять 50 мм с допуском ±0,1 мм, это означает, что деталь должна быть изготовлена именно в этом диапазоне. Точка.

С другой стороны, размеры для справки предоставляют дополнительную информацию, которая может быть полезна для понимания конструкции или ее взаимосвязей, но не имеют жестких требований к точности. Они могут служить для указания примерной длины кабеля USB, который соединяет некое изделие с ПК оператора на рабочем столе. И не важно, будет этот кабель 1 м или 1,5 м. Даже если кабель будет длиной всего 0,5 м, изделие можно будет подключить к ПК и оно будет работать. Может пользоваться этим изделием будет не так удобно, но функционал не будет потерян.

Все точные параметры изделия, обязательные требования к его эксплуатации и минимально необходимые производственные тесты должны быть прописаны точно и скрупулёзно. Необходимо на этапе сборки финальных прототипов на производстве собрать максимально возможное количество сообщений об ошибках в документации, стендах и ПО, чтобы устранить их. Но допустимо, что логи теста ноутбука, пока ещё, сохраняются на USB-флешку, а не на SFTP-сервер компании. А качество цветопередачи проверяется вручную на каждом 50-м мониторе из партии в 3.000 шт. Хотя есть план делать это автоматически на каждом мониторе, да ещё с внесением настроек в прошивку этого изделия. В процессе запуска в массовое производство следующего подобного изделия, будут сделаны эти или даже ещё более технологичные доработки.

Бесконечные и конечные игры

Итак, есть некий минимум, который обязательно нужно выполнить. А дальше... Дальше начинается бесконечность вариаций, масса возможностей и доработки без конца и края. Дайте полноценному отделу разработчиков со своими программистами x86-64, программистами микроконтроллеров, электрониками и тестировщиками задачу "Создать стенд для производственного тестирования системной платы сервера", исправно снабжайте эту команду деньгами и наблюдайте. Уверен, что максимум через пару лет эта команда будет знать про системные платы, процессоры Intel и AMD, BMC, DDR, PCIe и т.д. столько, что могли бы написать пятисотстраничную книгу. Будут готовы открыть свой учебный центр, с программой актуальнее ВУЗовской. И эти инженеры станут отбиваться от инвесторов, навязывающих команде идею стартапа по оснастке для производственных тестов материнских плат. Однако, партия системных плат в 600 шт., под которую эта задача ставилась, так и не будет запущена на производство. Ведь ещё столько смелых и нереализованных ранее идей не проверены на практике...

Есть другой путь, навязанный нам ограничениями капиталистического мира. В процессе написания документов, сборки тестовых стендов и кодинга тестового ПО, команда инженеров стремится выпустить изделие с минимальным процентом брака и рекламаций от заказчиков. Всё. Ничего больше. Так называемый минимально жизнеспособный продукт: достаточная документация, достаточный стенд и тестовое ПО.

Если сроки поджимают, кадровый голод, а проценты по взятым компанией кредитам выросли, то автор настаивает на формировании технологического долга, вместо затягивания сроков выпуска серийных партий. Пусть будут точки, как разделители, вместо запятых (3.5 В, вместо 3,5 В). Пусть будут "mm" латиницей, а не кириллицей. Пусть некоторые места в инструкции по производственному тестированию будут скорее понятными, чем красивыми. А упомянутые выше мониторы проверяются вручную. Пусть все эти второстепенные замечания накапливаются в "Списке доработок". Том самом техническом долге, который инженеры закроют позже. И пусть партия изделий будет поставлена на производство, пройдёт испытания и отгружена на склад вовремя!

Хотя бы потому, что в процессе выпуска первой партии будут найдены ещё недоработки КД, тестовых стендов и тестовго ПО.

Связанные одной целью

«Путь тяжёл, но цель прекрасна, как огонь костра» © Ария про квартальную премию.
Если в командах управленцев и инженеров конструкторского отдела накопилось достаточно профессионалов. Если продавцы заложили в свои планы достаточно времени на запуск изделий в производство. Если экономисты компании смогли найти деньги и вовремя оплатить BOM. Если... если... если...
Когда совпадает сразу множество векторов сил, команды начинают сотрудничать. И тогда рождается Консенсус (в данной статье - это имя собственное). Редкий в наших широтах зверь. И у разных компаний он свой. Автор предлагает вам своё видение.

Представим, что перед нами задача впервые произвести партию в 3000 серверов 19" U2 с корзиной на 12 дисков впереди. Вот план:

1. Разработка и утверждение конструкторской документации (КД)

• На этом этапе важно, чтобы все этапы производства были описаны настолько точно и подробно, что подрядчик сможет повторить изделие точно так, как требовалось в ТЗ и без помощи со стороны заказчика. Автор мог бы много написать про поля для разделения мультипликаций МПП. О покрытиях контактных площадок и выводов компонентов. О банальном положении реперных точек и отверстий на платах. Но, автор не конструктор печатных плат. Специализация автора - запуск и поддержка массового производства. И его зона ответственности включает только часть технической документации.

2. Подготовка технологической документации (ТД)

• Технологические карты, инструкции по производственному тестированию:
  концентрируем своё внимание на том, чтобы любой рабочий, которого наняли для "отвёрточной сборки" смог проделать все манипуляции без ошибок и без посторонней помощи. Если текст понятен 9 из 10 сборщиков и тестировщиков, то не важна его красота. Концентрация внимания на однозначность определений и описания последовательности действий.

  Здесь важно пройти все этапы "ручками". И здесь мы открываем "Список доработок". Все критические ошибки немедленно исправляются, а второстепенные попадают бэклог, откуда их будут брать освободившиеся специалисты для доработки. Примеры:

  • Нет описания как подключать бэкплейн фронтальной корзины в сервере, подробного и с фотографиями. В итоге при тестовой сборке производство решает задачу "как Бог на душу положил" и подключает лишние кабель "из-под полы", так как считают, что не хватает одного кабеля. И в неправильном порядке устанавливают диски во фронтальную корзину. Такую ошибку необходимо устранить здесь и сейчас. Сделать подробное описание какие разъёмы каким концом какого кабеля соединить с каким портом на какой плате сервера. Какие диски вставить в верхние корзины, какие в средние, какие в нижние. С указанием артикулов кабелей и дисков, с фото. А на фото стрелочки и рамочки с указанием разъёмов и мест крепления. Естественно, фото кабелей делаем не в упаковке, а держим разъёмами в кадре. Так будет ясно, что кабель, например, с SlimSAS на SAS HD. И, да, крупным кадром, в фокусе. Когда фото пойдёт в документацию, не нужно будет лишний раз резать и будет четко видно объект.

  • В ПМИ нет формы Акта о прекращении испытаний, как и Акта об успешном прохождении испытаний. Думаю, что в коммерческих компаниях редко бывает, чтобы разработка закончилась Актом о прекращении испытаний. Потратив столько денег, времени и сил, компания приложит достаточные усилия, чтобы преодолеть все организационные и технические/технологические трудности. Однако, если в организации налажена размеренная разработка, то такой акт может быть промежуточным звеном. И отработав все замечания, конструкторский отдел направит на повторные испытания изделие. Ну, а подписание акта, согласно которому замечаний нет - заветная цель ТЗ. Так что формы обоих актов могут быть в приложении к ПМИ. Но это никак не повлияет на успех или провал ОКРа. Можно записать две строчки в беклолг и оставить, например, для стажёров.

• Программы и методики испытаний (ПМИ): испытания всех составных частей изделия отдельно и изделия в сборе. На каждую плату сервера пишем ПМИ и проводим испытания, чтобы подтвердить все спецификации плат. И чтобы избежать сюрпризов. Концентрация внимания на покрытии проверками всех пунктов ТЗ. А может и выход за его рамки, с последующей доработкой ТЗ и подачей обновленного документа в архив по извещению.

• Материальные спецификации: Описание всех используемых материалов, компонентов и оборудования.
  Очень важно реализовать систему версионности таких документов. Чтобы, в частности, контрактники гарантированно получали актуальный BOM. И эти документы нужно заменять целиком, а не выпускать дополнение к ним. Иначе путаницы и ошибок не избежать.

3. Закупки компонентов и обеспечение поставок

Опять чужая зона ответственности. Автор только попросит закуперов добиваться, чтобы BOM, заранее собранный в дружественных странах, оплачивался вовремя и поступал в производство с ещё годными к пайке компонентами и печатными платами, аккумуляторами и т.д.

4. Разработка и подготовка тестовой инфраструктуры

• Тестовые стенды: Разработка производственных тестовых стендов для проверки функциональности систем серверов. Что мешает нам собрать программно-аппаратный комплекс для автоматического тестирования всех систем сервера? И чтобы каждый аппарат прошёл полные испытания согласно ПМИ. Такое - мечта инженера ОТК. Но есть входной контроль МЭК (микроэлектронных компонентов). Проверка плат, полученных от контрактника. Входной контроль плат и блоков, купленных в готовом виде у сторонних поставщиков. Выборочное нагрузочное тестирование готовых аппаратов 24 или даже 72 часа. Дублировать тесты нет смысла. К тому же, часть испытаний ПМИ совсем уж чрезмерно повторять на каждом экземпляре изделия. Такие, например, как вибрационные и климатические. Особенно в тех компаниях, где нет своего испытательного оборудования для таких проверок. Поэтому в программу автоматизированного производственного тестирования входит основные функциональные проверки и проверки, направленные на выявление ошибок сборщиков:

  1. Проверить запуск и определение ЦПУ, ОЗУ, обоих БП, проверить работу и показания датчиков BMC.

  2. Проверить актуальность BIOS/BMC.

  3. Проверить полный состав изделия и сравнить его с заказом.

  4. Убедиться, что все платы расширения стоят в своих разъёмах и райзерах, и инициировались на своих скоростях.

  5. Сверить данные вендора в BIOS. Прописать MAC-адреса.

  6. Обновить встроенное ПО у всех плат расширения на версии, которые проверены и совместимы между собой.

  7. Проверить верность установки и подключения накопителей, их ёмкость и состояние.

  8. RAID. Создать, проверить.

  9. Протестировать работу всех сетевых адаптеров. Факт инициализации, скорость, факт успешной передачи файла в 500 МБ.

  10. Проверка всех внешних интерфейсов: USB, VGA и пр. Может надо даже записать лог инициализации через COM-порт, если в заказе это явно указано.

  11. Тест связи и удаленного управления сервером через BMC. У кого-то даже Redfish есть. Тогда многое упрощается.

  12. Стабильность работы под нагрузкой, в том числе проверка работы теплоотвода.

  13. Внесение в BIOS и BMC настроек, которые запросил заказчик.

  14. Финальный осмотр открытого и обесточенного сервера сотрудником ОТК. Этот пункт можно автоматизировать чек-листами и удобством подтверждения, что изделие прошло ОТК. Сравнение всех "больных точек" с фото. Так же нужно реализовать способы удобного создания подробного и понятного листа несоответствий.

• Автоматизация тестирования.  Здесь важно отметить, что нужно стараться автоматизировать всё, что только можно. Нужны способы автоматически проверить компоненты и записать объективные данные по результатам проверок. Но если все эти проверки делаются впервые, то можно сначала делать вручную, особенно при производстве пилотной партии. Это будет даже полезно, если инженеры обнаружат, что автоматические тестовые системы выдают показатели, отличные от результатов ручных тестов. Все проверки нужно тщательно многократно отработать вручную и уже потом автоматизировать и описать в инструкции по производственному тестированию и ПМИ. Только архитектуру тестирования нужно выстраивать с целью автоматизировать всё, что возможно. То, что нельзя автоматизировать, заранее проработать с технологами производства.

5. **Производство первых тестовых партий

• Выпуск пилотной партии: Чаще всего изготавливаются 5-10 серверов для доработки технологических процессов. В рамках выпуска тестовой партии проводят:

  • Отработку сборочного процесса.

  • Проверку работы КД и ТД.

  • Первичное тестирование оборудования (включая испытания по ПМИ).

• Список доработок: Если на этапе разработки тестовых стендов и инфраструктуры всё делали медленно, то на этом этапе инженеры стараются всё ускорить. И снова что-то исправляют сразу, что-то заносят в список на потом, а что-то игнорируют. Не так важно, что разделителем разрядов работает точка, а не запятая. Если и так ясно, что это десятичная дробь.

6. Организация серийного производства

• Сборочные линии:

  • Настройка сборочного оборудования.

  • Проверка готовности рабочих мест.

• Обучение персонала.

• Здесь работают технологи, автор только оказывает им техническую поддержку. Хотя этот пункт - океан для опытного технолога.

7. Этапы тестирования

• Входной контроль компонентов: Проверка МЭК, комплектующих, соответствие спецификации и качество.

• Этапное тестирование: Проверка работоспособности серверов на различных этапах сборки. Бывает и такое. Хотя, обычно, многоступенчатая проверка (сначала микроэлектронные компоненты, потом платы по отдельности, затем уже сервер в сборе) позволяет обойтись одним этапом - тестом полностью укомплектованного сервера целиком.

• Конечные тесты достаточно подробно описано в разделе 4 данного плана.

• Прогон: Выборочное проведение углубленных тестов на определенном проценте партий (например, каждые 50-е устройство проходит усиленные тесты).

8. ОТК и упаковка

• Конечный осмотр изделия: Сотрудник ОТК осматривает сервер с открытой верхней крышкой на предмет правильной сборки.

• Маркировка и упаковка: Серверы маркируются (серийные номера, штрихкоды, логотипы), упаковываются (индивидуальная и транспортная упаковка). Этот пункт частично исполняется на этапе производства печатной платы - лазерная гравировка QR-кода. Частично вначале этапа сборки сервера - наклейка или лазерная гравировка QR-кода на корпусе (оно же шасси, по науке)

• Инженер ОТК осматривает корпус сервера перед тем, как его закроют в упаковке. Убеждается, что уложен и упакован сервер верно, в полной комплектации согласно спецификации.

Заключение

Производство — это баланс между идеализмом и реальностью, между «правильностью» процессов и скоростью их выполнения. Необходимость жестко подстраиваться под временные и ресурсные рамки учит инженеров и управленцев совместно работать в условиях ограничений, эффективно распределяя приоритеты. Этой статьёй автор хотел напомнить о том, что идеала достичь невозможно, но ключевой задачей всегда остаётся запуск продукта, который будет соответствовать заявленным характеристикам, минимизировать количество брака и удовлетворять ожидания клиентов.

Важно понять, что любой технический долг — будь то недооформленный пункт в инструкции, незавершённая автоматизация тестов или недостаточные ресурсы для проверки всего оборудования — не фатален. Его можно закрывать в процессе развития предприятия и модернизации процессов. Производственным и конструкторским командам необходимо находить консенсус между проектными ограничениями и качеством ради достижения успеха разработки.

Эта статья предлагает не просто пошаговый алгоритм работы, а приглашение к открытому обсуждению проблем и решений. Какие механизмы используете Вы? А как выглядит Ваш «зверёк» под названием Консенсус? Поделитесь своим опытом в комментариях — возможно, именно Ваши подходы помогут ещё одной команде найти баланс между скоростью, качеством и соблюдением ГОСТов.