Inquisitor — основа производства компании ETegro Technologies

PDF-версия статьи: (Русский, English)

ETegro Technologies была основана в 2005 году и является довольно молодой компанией. Но российский компьютерный рынок в целом тоже весьма молод — ему всего около 15 лет, и ядро ETegro составляют люди, которые стояли у истоков российского компьютерного рынка.

Основная сфера деятельности компании — производство серверов и рабочих станций, а также специализированных компьютеров для правительственных и военных заказов. По итогам 2007 года и по результатам первых двух кварталов 2008 года, компания уверенно занимает 5 место на российском серверном рынке с совокупной долей около 7 % и среднегодовым количеством поставляемых серверов около 10000 штук (данные IT Research).

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

В целом можно выделить четыре подхода к выходному тестированию компьютерного оборудования:

1. Не тестировать вообще — проверять только на включение (включается → проходит POST → значит работает). Недостатки такого подхода очевидны — он годится только для «гаражных» компаний.
2. Зачатки системы тестирования → используются какие-то готовые широко распространённые тесты (например, 3DMark под Windows), которые «прогоняются» на тестируемых компьютерах. В целом такое тестирование бессистемно, и не даёт каких-либо данных для анализа и выполнения корректирующих действий по улучшению качества продукции.
3. Самописные (homebrew) системы тестирования. Распространённое явление в компаниях, прошедших вторую стадию. Могут быть достаточно неплохими в целом, но имеют две основные проблемы: как правило, их архитектура не продумана для решения возникающих при увеличении объёмов производства задач, плюс вся система обычно сильно завязана на основного разработчика, и после его ухода из компании есть большая вероятность, что система перестанет развиваться.
4. Open source или partially open source системы тестирования. С нашей точки зрения, это оптимальный вариант — система развивается силами community, архитектура, как правило, спроектирована более грамотно; пока есть активное сообщество, система продолжает развиваться. При этом возможна (и даже необходима!) кастомизация под профиль деятельности компании, у которой система внедряется, могут быть какие-то закрытые части — например, собственные web-интерфейсы.

Практически с момента основания ETegro Technologies, в компании использовалась самописная система тестирования (стадия 3 по нашей классификации). Так как основатели компании — люди, работающие в компьютерной индустрии уже достаточно давно, с самого начала работы компании ими было принято решение работать по схеме с централизованной системой тестирования. За относительно небольшие сроки (несколько месяцев) специалистами компании была разработана homebrew-система, получившая название TOS, которая взяла на себя функцию основной производственной системы. По внешнему принципу действия система достаточно похожа на Inquisitor Enterprise — компьютеры загружались по сети, дальше была возможность запускать некие тесты и регистрировать их выполнение на центральном сервере.

Сначала TOS работала достаточно адекватно, но весьма скоро, через год-полтора, начали вскрываться её многочисленные недостатки. Лавинообразное дописывание системы на ходу, без какой-то систематизации, для добавления всё нового потока требуемых возможностей, привело к совершенно бесконтрольному процессу разработки. Отсутствие адекватного версионирования и продуманной системы сборки привело к тому, что существовала всего одна инсталляция системы — 32-битная, и портирование её на 64-битную платформу было бы равносильно ручной пересборке и переустановке всех компонентов системы. Также стало очевидно, что сами тесты тоже оставляют желать лучшего: мощные серверные системы требуют совсем другого подхода к нагрузочному тестированию, нежели обычные десктопы. Кроме того, система, изначально рассчитанная на тестирование десятка компьютеров в день, была недостаточно автоматизирована и требовала значительных человеческих ресурсов, что становилось настоящим препятствием для быстрой работы, когда в растущей компании стало требоваться тестирование сотен машин в день.

Назрел переломный момент: старая система всё хуже справлялась со своими обязанностями, и нужно было принимать решение, что делать дальше. В середине 2007 года был проведен всесторонний анализ возможных альтернатив, который, к сожалению, дал фактически отрицательные результаты. Мы рассмотрели существующие на рынке коммерческие решения (которых довольно немного), и пришли к следующим выводам:

• многие из внедряющих компаний не работают с Россией;
• ни одна из этих систем не интегрируется с самой распространенной в России и используемой в ETegro Technologies системой управления предприятием «1С Предприятие»;
• зачастую компании реализуют не систему управления производством и качеством производимой продукции (компьютеров и серверов в данном случае), а предлагают сложные аппаратные решения, связанные с построением конвейеров, автоматизацией производства с помощью роботов и т. п.;
• ни одна из найденных компаний не предлагала готового законченного решения именно для нашего рынка: в лучшем случае у компании был опыт по автоматизации какого-то этапа (например, сборки компьютеров на конвейер), причём система учёта и тестирования продукции оставалась за кадром;
• все такие внедрения очень дороги — как правило, речь идёт о десятках миллионов долларов, строительстве собственных заводских комплексов и занятости тысяч человек персонала.

Поиск готовых open source решений для такой задачи показал, что всё, что существовало на тот момент (StressLinux, Cerberus от VA Linux, система от linuxmafia), либо слишком просто и потребует значительных доработок, либо заброшено и не развивается.

К счастью, в августе 2007 года удалось разрешить некоторые юридические вопросы, что привело к тому, что полноценно стала доступной в качестве open source проекта система Inquisitor. Эта система ведёт свою историю с 2004 года, первоначально она была разработана ALT Linux по заказу компании MaxSelect и была внедрена как в самой компании, так и у её многочисленных партнёров на территории всей РФ.

Адаптация Inquisitor к условиям ETegro, очевидно, заняла бы достаточно продолжительное время, поэтому ETegro Technologies, с одной стороны, поддержала основных разработчиков проекта Inquisitor, а с другой — часть разработчиков компании переключились на работу над этим проектом. После достаточно длительного обсуждения была выработана следующая стратегия развития Inquisitor: из просто системы тестирования он должен был превратиться в платформу для построения систем тестирования, т. е. в тиражируемый набор модулей, из которых можно при желании собрать всё, что нужно в конкретном случае.

Работы по внедрению Inquisitor в ETegro заняли достаточно продолжительное время — связано это в первую очередь с тем, что процесс внедрения шёл одновременно с переписыванием большей части модулей (для удовлетворения требований «платформенности»).

Главной идеей при проектировании web-интерфейсов Инквизиторa была возможность для пользователей (а это, прежде всего, sales-менеджеры и руководитель производства) в любой момент посмотреть, в каком состоянии находится конкретный заказ или конкретный компьютер (компьютеры). Поэтому практически на всех экранах web-интерфейса присутствует «линейка» из последовательности стадий производства для отображения прогресса — будь то в рамках всего производства в целом, конкретного заказа или конкретного компьютера. Разумеется, время начала и окончания каждой стадии фиксируется.

Первая стадия — Ordering. Заказы изначально формируются в торговой системе и попадают в Inquisitor при достижении ими в торговой системе определённого статуса. Перенос заказов осуществляет специальный скрипт каждые 20 минут.

Вторая стадия — Warehouse. На этой стадии склад подготавливает необходимые для производство заказа комплектующие.

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

Четвёртая стадия — Assembling. На этой стадии из комплектующих собираются готовые изделия — серверы, рабочие станции, ПК. Моменты начала и окончания сборки каждого компьютера фиксируется сборщиком путём сканирования серийного номера компьютера и своего индивидуального номера с помощью сканера штрих-кода.

Пятая стадия — Testing. Стадия начинается с момента постановки компьютера на тестирование в Inquisitor, весь процесс тестирования можно досконально смотреть в соответствующем web-интерфейсе.

Шестая стадия — Checking. На этой стадии высококвалифицированные сотрудники проводят полный осмотр протестированного изделия с целью обнаружения дефектов сборки, которые не выявились на тестировании, но могут проявить себя после транспортировки и при дальнейшей эксплуатации. Также проверяется внешний вид изделия, правильность наклейки этикеток, комплектность и т.п.

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

Хочется обратить внимание на некоторые интересные технологические решения, реализованные в ETegro Technologies, которые могут быть полезны тем, кто собирается внедрять подобную систему у себя:

• Входная интеграция с ERP-системами: модуль, которые осуществляет интеграцию с существующей ERP-системой (складской учет) — регулярно или по наступлению каких-либо событий осуществляют подгрузку данных о новых заказах/заданиях на производство.
• Выходная интеграция с инфобазой и специальной частью веб-сайта компании: существует модуль, которые осуществляет выгрузку всех накопленных в базе Inquisitor данных во внешнюю информационную базу. Данные из этой информационной базы могут быть доступны в специальной части web-сайта компании, где партнёры и заказчики компании могут получить расширенную информацию об определённых экземплярах продукции ETegro.

Сетевая инфраструктура

Тестировочный стенд представляет собой стандартные стойки для серверного оборудования, соединённые вместе таким образом, что образуется массив из 45 ячеек на каждом стенде. К каждой ячейке подведено 4 кабеля электропитания и от 6 до 8 Ethernet-кабелей, в ячейку можно установить серверное оборудование высотой до 8U. Схема стенда и тестируемые компьютеры отображаются в интерфейсе, с которым работает оператор тестирования. Одной из важных задач была такая организация процесса тестирования, чтобы тестируемый компьютер отображался в интерфейсе именно на той полке, на которую он поставлен.

Эта задача решается путём использования управляемых коммутаторов второго уровня и организации с их помощью VLAN'ов.

Подведённые к полке стенда кабели приходят от одной VLAN'ы. IP адреса в каждой VLAN'е представляют собой отдельную IP-подсеть. Выдачей IP-адресов занимается DHCP-сервер, в котором указана принадлежность IP-подсети конкретной VLAN'е, а стало быть, и конкретной ячейке. Таким образом, после того, как компьютер загрузился по сети, по выданным IP-адресам становится ясно, на какой полке он находится.

Кроме этого, разделение сети на VLAN решает и проблему управления сетью в целом. Дело в том, что к каждой ячейке подводится не менее 6 Ethernet-кабелей (для тестирования многопортовых компьютеров). Поскольку в целом ячеек более 160 штук, это предполагает наличие не менее чем 1000 Ethernet-портов на стеке коммутаторов, а функционирование сети с таким количеством портов без сегментирования невозможно. Также, такая организация сети позволяет достаточно гибко управлять доступом к отдельным тестируемым компьютерам, в частности — внешним доступом из Internet.

Автоматические прошивки

Кроме основного процесса тестирования как такового, важным моментом в производстве компьютеров является возможность автоматического обновления firmware системной платы и дополнительных компонент (например, контроллеров).

В идеале, процесс прошивки должен быть максимально автономным — система сама должна определять, требует ли обновления firmware тестируемого компьютера, при необходимости выполнять обновление и проверять итоговую успешность процесса.

Система обновления firmware в Инквизиторе основывается на уже существующих с самого начала разработки модулях. Благодаря их гибкости и гибкости всей системы в целом удалось реализовать значительно отличающийся от детектов и тестов функционал, причём достаточно просто и красиво.

Всё, что необходимо сейчас сделать для обновления firmware, это указать в web-интерфейсе Inquisitor:

• модель комплектующей (дискового контроллера, материнской платы, BMC, NIC, и т.д.);
• путь к файлу с прошивкой;
• требуемую версию (для проверки успешности процесса).

Благодаря такой системе удалось избежать потери большого количества времени на рутинные операции, в которых к тому же невозможно исключить человеческий фактор, поэтому внедрение модуля обновления firmware в Инкивизиторе — очень важный для автоматизации производства в ETegro шаг.

Заливки через torrents

При производстве больших партий серверного оборудования частым требованием заказчика является предустановка некоторого образа с программным обеспечением. Развёртывать образ одновременно на большое количество компьютеров кажется достаточно тривиальной задачей, но на практике получается, что при одновременной установке уже на 20 компьютеров стандартный сервер испытывает очень большие нагрузки на дисковую и сетевую подсистемы (имеется в виду ситуация, когда образ для установки находится на файловом ресурсе, например, NFS). Ещё одним вариантом является организация пула файловых серверов с некоторым балансировщиком нагрузки, однако, линейная зависимость количества серверов от количества тестируемых компьютеров ведёт к существенному повышению стоимости владения системой. При поиске путей решения рассматривалась возможность организации установки в режиме multicаst по протоколу UDP. Однако, при мультикастинге существует требование синхронизации начала копирования между клиентами. Это требование практически невозможно выполнить при потоковом производстве сотен единиц техники. Достаточно неожиданной идеей стала организация peer-to-peer обмена между тестируемыми компьютерами посредством протокола BitTorrent. Но, как показала практическая реализация этой идеи, получившийся вариант является наиболее приемлемым — обеспечивается установка образов на любое количество тестируемых компьютеров. Именно этот способ используется в компании при массовом производстве.

Заключение

В заключение несколько слов тем, кто думает о возможности внедрения Inquisitor или подобной системы у себя на предприятии.

Внедряемое решение должно быть комплексным — иначе предприятие очень быстро столкнётся с проблемами из-за нестыковок в организации работы. Такое решение должно включать в себя, как минимум:

• программную часть — комплекс тестирования, сходный с тем, что можно построить на базе Inquisitor;
• аппаратную часть — серверы, сканеры, принтеры этикеток, управляемые коммутаторы, правильно спроектированные полки, удобная система нумерации и расположения этих полок, продуманный «конвейер» передачи продукции по всем стадиям;
• организационную часть — пожалуй, самую сложную — полное описание и формализацию бизнес-логики работы предприятия: описание всех ролей людей, порождаемых документов, действий, матрицы прав на совершения этих действий, эффективную организацию труда внутри производственных отделов (приёмка, сборка, тестирование, выходной контроль, отгрузка).

В целом, компаниям, думающим о внедрении производственной системы, можно посоветовать не «изобретать велосипед», а использовать в качестве основы открытую платформу. Те наработки, которые могут быть полезны всем — например, новые тесты — имеет смысл опубликовывать и распространять под лицензией GPL, с тем, чтобы они могли в дальнейшем совершенствоваться силами сообщества, а относящиеся к конкретной реализации бизнес-части системы могут быть оформлены в качестве отдельных закрытых дополнений.

Андрей Сапронов, asapronov@etegro.com, 23.04.2009