Хабр, привет! Меня зовут Игорь Сомов, я работаю инженером по внедрению в компании «Базис». До этого почти 20 лет работал в ИТ — начинал монтажником, был эникеем на заводах, системным администратором в разных компаниях. Даже уходил из ИТ на какое-то время, но в итоге вернулся в профессию.

Когда в 2022 году меня позвали в «Базис», я ничего не знал о Basis Dynamix (как и многие ИТ-специалисты тогда). На собеседовании мне рассказали про отечественную платформу виртуализации и предложили участвовать в налаживании процессов внедрения. Это показалось интересным вызовом — тем более что за плечами был разнообразный опыт работы с инфраструктурой.

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

Мое знакомство с Basis Dynamix началось с обучения: читал имеющуюся документацию, смотрел записи вебинаров по предыдущей версии платформы (тогда она еще называлась DECORT), готовился к внутренней аттестации. У коллег уже было понимание, что программа обучения нуждается в серьезной доработке, и моей задачей было дать обратную связь — какой именно информации не хватает и для чего.

Документацию по обучению составляли самостоятельно, фиксируя замечания и дополняя материал по мере прохождения программы. Недостающая информация собиралась и валидировалась с коллегами, после чего материалы переносили в Confluence. Помимо этого записали девятичасовое видео реальной инсталляции, в котором подробно разбирались все этапы процесса. Чуть позже обновили вопросы для аттестации. Сейчас эти материалы уже устарели, а сам подход выглядит немного наивным, но тогда это был существенный результат. Со временем коллеги пересняли видео, адаптировав его под актуальную версию платформы, но это совсем другая история.

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

Выделяем основные проблемы

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

1. Процесс инсталляции был частично ручным, частично автоматизированным, с большим количеством legacy-компонентов. Все это работало на Ubuntu 18 — не самой на тот момент свежей ОС. А инструкция, пусть и довольно подробная, представляла собой простой документ Word.  

2. Заказчики плохо понимали архитектуру решения. Им давали для заполнения Excel-файл с надписью «техландшафт», но не объясняли его важность для планируемых работ. В результате заказчики заполняли файл левой пяткой формально, просто потому, что не понимали, как и зачем это делать правильно. По сути, этот документ существовал только для инженеров внедрения, чтобы по нему установить Basis Dynamix, но даже им он в текущем виде не особо помогал.

3. У каждого заказчика возникали одни и те же сложности при эксплуатации. Например, одинаковый product_uuid на всех узлах мешал миграции виртуальных машин. Windows не видела диски. Возникали ошибки при подключении CD-привода к виртуальным машинам. Решения этих проблем существовали, но не были документированы.

4. Когда платформа работала в закрытом контуре, возникали сложности с доставкой необходимых пакетов и зависимостей. Не было единого подхода к работе в изолированной среде.

Все это приводило к тому, что длительность процесса внедрения становилась непредсказуемой. Мы не могли точно сказать заказчику, сколько времени займет установка, а любая нестандартная ситуация «подвешивала» проект на неопределенный срок.

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

Приступаем к решению

Формирование команды

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

Переработка архитектуры внедрения 

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

• подробные описания для каждого пункта;

• примеры заполнения;

• схемы, иллюстрирующие архитектуру;

• понятные инструкции по подготовке инфраструктуры.

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

Ну и, разумеется, перенесли инструкцию из Word`а в Confluence.

И еще несколько примеров

Автоматизация развертывания

Здесь у нас был классический замкнутый круг: на автоматизацию процесса инсталляции не хватало времени, потому что оно уходило на ручные манипуляции, избавиться от которых помогла бы автоматизация процесса. 

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

Автоматизацию начали с процесса внедрения платформы. Мы разбили его на три основных этапа и принялись последовательно оптимизировать каждый из них.

Первым делом взялись за установку операционных систем. Изначально мы работали только с Ubuntu 18, но вскоре от заказчиков появились запросы на Astra Linux, а затем и на «Альт». Сейчас поддерживаем все три системы, кроме того, ведем разработку собственного гипервизора первого типа vCore. Он должен упростить решение таких проблем, как установка антивирусного ПО, различия в версиях программных пакетов или необходимость корректировки кода продукта под разные ОС: разные операционные системы могут возвращать разные значения при выполнении одних и тех же команд, из-за чего наше ПО получает некорректные данные и требуется вмешательство разработчиков.

Сложности были с доставкой скриптов настройки на серверы без настроенной сети. При небольшом количестве серверов можно было собрать ISO и подключить его как media-CD через IPMI, но это решение очень плохо масштабировалось — попробуйте проделать такую операцию на 150 машинах.

Мы написали скрипт для сборки кастомизированного дистрибутива из оригинального образа. В дистрибутив добавили все необходимые компоненты: скрипты автоматической настройки сетей, утилиты для развертывания локальных репозиториев (особенно важно для Astra Linux), предустановленные пакеты для работы с системами хранения (iSCSI, LVM) и виртуальными сетями (Open vSwitch).

Кроме того, упростили и ускорили процесс инсталляции. Теперь дистрибутив задает всего один вопрос: как размечать диск? Причем для удобства уже подготовлены «варианты ответов» — схемы разметки под разные типы узлов (управляющие и вычислительные). Раньше инженер мог параллельно устанавливать не более пяти серверов, так как приходилось постоянно отвечать на вопросы установщика. После наших доработок только за счет того, что у инженера освободилось время на запуск новых инсталляций, количество параллельных установок увеличилось до 10 и более серверов. Мне лично удавалось администрировать такое количество установок параллельно. Впрочем, процесс все еще требует доработки — остается ручная работа по разметке дисков, да и подключение к IPMI-консоли пока никуда не делось.

Следующим важным этапом стала автоматизация конфигурации Basis Dynamix. В центре процесса установки находится system-config — YAML-файл, который определяет всю конфигурацию системы и потом используется самим стендом. Он огромный, заполнять его долго, муторно и очень легко ошибиться. После долгих обсуждений решили автоматизировать его создание, написав скрипт для парсинга техландшафта. 

Изначально это был скрипт в Docker со всеми зависимостями, но позже мы упростили его до обычного скрипта на Python, который берет данные из техландшафта и помещает их в нужные места system-config.yaml. Да, парсить Excel — не самое элегантное решение, но оно работает: время подготовки конфигурации сократилось с нескольких часов до нескольких минут. Фактически, проверка конфига занимает больше времени, чем его создание.

Затем мы автоматизировали процесс подготовки операционных систем на серверах. Раньше много времени уходило на ручную работу: установку пакетов, настройку iptables, сетей, синхронизацию времени… Серверы имели разные роли, и для каждой требовались свои настройки — даже такие базовые вещи, как имя сервера и IP-адрес, нужно было назначать индивидуально.

Мы написали еще один Python-скрипт, который брал на себя всю эту рутину, используя данные из созданного ранее system-config, и интегрировали его в дистрибутив ОС, чтобы он был доступен сразу после установки. Итог: подготовка сотни серверов сократилась с нескольких дней до одного часа.

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

Работа с закрытыми контурами

Чтобы упростить развертывание платформы Basis Dynamix внутри закрытых контуров, мы применили подход с локальным репозиторием. На первом контроллере (управляющем узле Dynamix) разворачивается зеркало официального репозитория (около 30 ГБ), которое затем становится доступно всем узлам в инфраструктуре. Процесс полностью автоматизирован: на контроллере разворачивается веб-сервер, и все узлы настраиваются на работу с локальным репозиторием.

 Что это дает:

• обеспечивает доступность всех необходимых пакетов;

• позволяет проводить инсталляцию и обновления Basis Dynamix без внешнего доступа;

• упрощает траблшутинг в изолированной среде.

Системы контроля качества

Наконец, мы добавили автоматические проверки на всех этапах внедрения:

• валидация заполнения техландшафта;

• проверка готовности инфраструктуры;

• тестирование настроек ОС и сетевой связности;

• верификация конфигурации перед установкой Dynamix.

Все проверки реализованы в виде Python-скриптов, которые выводят результаты в понятном формате с подсветкой проблем.

Результаты работы

Оцениваем результаты

После внедрения всех перечисленных изменений мы получили предсказуемый и масштабируемый процесс развертывания Basis Dynamix. Главное достижение — существенное сокращение времени внедрения и повышение его качества, а именно:

• заказчики стали лучше понимать архитектуру решения еще до начала внедрения благодаря переработанному техландшафту;

• время на подготовку сократилось в несколько раз за счет автоматизации конфигурации;

• появилась возможность параллельной установки на большое количество серверов благодаря автоматизации процесса инсталляции;

• решена проблема работы в закрытых контурах через локальные репозитории;

• автоматические проверки помогают выявлять проблемы на ранних этапах.

В целом нам удалось превратить длительный и непредсказуемый процесс в понятную, документированную и во многом автоматизированную процедуру. Что приятно, многие из разработанных нами решений уже стали стандартной практикой в компании и используются другими командами. Например, нашу «доску плача» для сбора и анализа проблем коллеги переименовали в «доску эволюции» и теперь используют на своих проектах. А наш опыт работы с закрытыми контурами помог выработать типовой подход к таким внедрениям.

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

Несколько рекомендаций

На основе нашего опыта с Basis Dynamix я бы выделил несколько ключевых рекомендаций для тех, кто планирует улучшать процессы внедрения сложных инфраструктурных решений.

1. Начните с документации

   • Если заказчики не понимают, что и как нужно подготовить, любая автоматизация даст лишь частичный эффект.

   • Документация должна быть понятна не только вашей команде, но и клиентам, в том числе слабо разбирающимся в вопросе. Покажите документацию, например, своим джунам или стажерам, и посмотрите на результат.

   • Добавляйте схемы, примеры и пояснения к каждому важному пункту — люди любят глазами, а инженеры тоже люди.

2. Разбейте процесс на этапы

   • Выделите независимые части процесса внедрения.

   • Автоматизируйте каждый этап отдельно.

   • Добавьте проверки между этапами, чтобы проблемы не «проваливались» дальше по цепочке.

3. Автоматизируйте постепенно

   • Начните с операций, которые отнимают больше всего времени, закон Парето тут вполне применим.

   • Автоматизируйте «от простого к сложному» — мы начали со скриптов установки, а потом перешли к более сложным материям.

   • Не отметайте сразу «простые» решения (тот же парсинг «техландшафта» из Excel здорово сэкономил нам время). 

4. Думайте о масштабировании

   • Решения должны одинаково хорошо работать как с пятью серверами, так и с пятьюдесятью.

   • Учитывайте особенности закрытых контуров.

   • Делайте инструменты, которыми не стыдно поделиться с другими командами.

5. Собирайте обратную связь

   • Документируйте все проблемы и их решения, которые вы нашли, — как минимум, коллеги будут благодарны.

   • Регулярно обсуждайте с командой, что можно улучшить (тут и пригодится документирование).

   • Привлекайте заказчиков к обсуждению процесса внедрения продукта — они знают свою инфраструктуру.