Хабр, привет! Меня зовут Игорь Сомов, я работаю инженером по внедрению в компании «Базис». До этого почти 20 лет работал в ИТ — начинал монтажником, был эникеем на заводах, системным администратором в разных компаниях. Даже уходил из ИТ на какое-то время, но в итоге вернулся в профессию. В «Базис» пришел пару лет назад, в создающуюся команду внедрения, вместе с которой делал первые шаги в автоматизации разворачивания платформы Basis Dynamix. Сейчас выбранный нами подход выглядит немного наивным, но тогда это был существенный результат, который позволил нам создать базу для дальнейшей работы. О том, как это было, я и хочу рассказать.
Это обновленная версия статьи, предыдущую было проще распубликовать, чем в реальном времени устранять все прокравшиеся в нее исторические неточности.
Мы начинаем начинать
Когда в 2022 году меня позвали в «Базис», я ничего не знал о Basis Dynamix. На собеседовании мне рассказали про отечественную платформу виртуализации и предложили принять участие в налаживании процессов ее внедрения. У меня за плечами уже был разнообразный опыт работы с инфраструктурой, задача выглядела интересно, поэтому вызов я принял.
Объем работ стал примерно понятен уже с порога: отдел внедрения только формировался, процессы и документация были сырыми, а развертывание продукта у заказчиков занимало недели из-за ручных операций и неочевидных зависимостей.
Первым делом приступил к обучению: читал имеющуюся документацию, смотрел записи вебинаров по предыдущей версии платформы (тогда она еще называлась DECORT), готовился к внутренней аттестации. У коллег уже было понимание, что программа обучения нуждается в серьезной доработке, и моей первой задачей было дать обратную связь — какой именно информации не хватает и для чего. Все исправления и дополнения обсуждали с коллегами, переносили в Confluence. Помимо этого, записали девятичасовое видео реальной инсталляции, в котором подробно разбирались все этапы процесса. Чуть позже обновили вопросы для аттестации.
Далее от теории я перешел к суровой практике – принял участие в реальном внедрении Basis Dynamix. Посмотрел процесс изнутри, вместе с командой собрал типовые проблемы и описал их решения, что в дальнейшем помогло подготовить материалы для обучения будущих инженеров. Тогда же стало понятно, какие процессы нужно улучшать. Точнее, нам стало понятно, что нужно переосмыслить весь сложившийся подход к развертыванию платформы виртуализации.
Измеряем глубину кроличьей норы
После первого знакомства с процессом внедрения стало ясно, что многие проблемы были системными. В разумный срок было невозможно решить их все, поэтому мы выделили основные:
Процесс инсталляции был частично ручным, частично автоматизированным, с большим количеством legacy-компонентов. Все это работало на Ubuntu 18 — даже на тот момент не самой свежей ОС. А инструкция, пусть и довольно подробная, представляла собой простой документ Word.
Заказчикам давали для заполнения Excel-файл с надписью «техландшафт» для описания инфраструктуры, но не объясняли ни то, как его правильно заполнять, ни его важность для планируемых работ. По сути, этот документ существовал только для наших инженеров внедрения, но даже им он в текущем виде не особо помогал.
На каждом объекте возникали одни и те же сложности при эксплуатации. Например, одинаковый product_uuid на всех узлах мешал миграции виртуальных машин. Windows не видела диски. Возникали ошибки при подключении CD-привода к виртуальным машинам. Решения этих проблем существовали, но не были документированы.
Когда платформа работала в закрытом контуре, возникали сложности с доставкой необходимых пакетов и зависимостей. Не было единого подхода к работе в изолированной среде.
Все это приводило к тому, что длительность процесса внедрения становилась непредсказуемой, что расстраивало и заказчика, и нас самих.
Пораскинув мозгами, решили, что надо, во-первых, сделать процесс более прозрачным для заказчиков — чтобы они понимали, как подготовить инфраструктуру и что от них требуется. Во-вторых, автоматизировать рутинные операции и документировать решения типовых проблем. В-третьих, разработать подход к работе с закрытыми контурами.
Решаем проблемы по порядку
Команда и техландшафт
Когда я начинал работу в компании, в отделе внедрения было всего два инженера и заместитель генерального по внедрению. Постепенно команда росла: появились руководитель внедрения, техлид, тимлид, архитектор внедрения и новые инженеры. Сейчас — когда заказчиков стало больше и проекты стали сложнее — только над внедрением и поддержкой работают уже полсотни человек, а на 2025 год запланирован значительный рост команды.
Однако в 2022 году нас было еще слишком мало, поэтому принялись решать проблемы по порядку. Первым делом мы взялись за техландшафт — ключевой документ, определяющий конфигурацию будущей инсталляции, — и сделали его более понятным и содержательным. В новой версии появились:
подробные описания для каждого пункта;
примеры заполнения;
схемы, иллюстрирующие архитектуру;
детальные инструкции по подготовке инфраструктуры.
Ключевую роль в этой работе сыграл наш архитектор внедрения. Он несколько месяцев собирал информацию от заказчиков, разработчиков и команды внедрения, чтобы сделать документ максимально содержательным. В результате техландшафт стал не просто формой для заполнения, а полноценным руководством по архитектуре решения.
Формат документа менять не стали, он устраивал и нас, и заказчиков, плюс, давал определенные преимущества, о которых расскажу далее. А вот инструкцию по инсталляции продукта из Word`а в Confluence, разумеется, перенесли.
И еще немного примеров
Автоматизация развертывания
С автоматизацией процесса инсталляции у нас на тот момент сложился классический замкнутый круг: на автоматизацию не хватало времени, потому что оно уходило на ручные манипуляции, избавиться от которых помогла бы автоматизация.
Найти выход из этого круга взялся один из моих коллег. Благодаря ему в компании появился центр компетенций, куда я и другие инженеры внедрения стали передавать компетенции и хотелки. В ответ мы получали варианты решения поставленных задач, пробовали их и возвращались с обратной связью. Собранные данные быстро помогли нам понять, куда и как нужно двигаться.
Начать решили с процесса внедрения платформы, разбили его на три основных этапа и принялись последовательно оптимизировать каждый из них. Первым делом взялись за установку операционных систем. Изначально мы работали только с Ubuntu 18, но вскоре от заказчиков появились запросы на Astra Linux, а затем и на «Альт».
Сложности были с доставкой скриптов настройки на серверы без настроенной сети. При небольшом количестве серверов можно было собрать ISO и подключить его как media-CD через IPMI, но это решение очень плохо масштабировалось — попробуйте проделать такую операцию на 150 машинах.
Решением проблем стал скрипт для сборки кастомизированного дистрибутива из оригинального образа. В дистрибутив добавили все необходимые компоненты: скрипты автоматической настройки сетей, утилиты для развертывания локальных репозиториев (особенно важно для Astra Linux), предустановленные пакеты для работы с системами хранения (iSCSI, LVM) и виртуальными сетями (Open vSwitch).
Кроме того, упростили и ускорили процесс инсталляции. Вместо десятка вопросов дистрибутив стал задавать всего один: как размечать диск? Причем для удобства уже были подготовлены «варианты ответов» — схемы разметки под разные типы узлов (управляющие и вычислительные). Раньше инженер мог параллельно устанавливать не более пяти серверов. После наших доработок только за счет того, что у инженера освободилось время на запуск новых инсталляций, количество параллельных установок увеличилось до 10 и более серверов. Мне лично удавалось администрировать такое количество установок параллельно.
Впрочем, процесс все еще требовал улучшения — оставалась ручная работа по разметке дисков, да и подключение к IPMI-консоли никуда не делось. Поэтому продолжили работу над дальнейшей оптимизацией. Кроме того, «Базис» уже вел разработку собственного гипервизора первого типа vCore. Его использование упрощало решение таких проблем, как установка антивирусного ПО, различия в версиях программных пакетов или необходимость корректировки кода продукта под операционную систему: разные ОС могут возвращать разные значения при выполнении одних и тех же команд, из-за чего наше ПО получает некорректные данные и требуется вмешательство разработчиков.
Следующим важным этапом стала автоматизация конфигурации 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, а самое главное, существенно сократили время внедрения и количество ручного труда инженера. Если перечислить все по пунктам, то:
заказчики стали лучше понимать архитектуру решения еще до начала внедрения благодаря переработанному техландшафту;
время на подготовку сократилось в несколько раз за счет автоматизации конфигурации;
появилась возможность параллельной установки на большое количество серверов благодаря автоматизации процесса инсталляции;
решена проблема работы в закрытых контурах через локальные репозитории;
автоматические проверки помогли выявлять проблемы на ранних этапах.
Совместными усилиями мы превратили длительный и непредсказуемый процесс в понятную, документированную и во многом автоматизированную процедуру. Что приятно, многие из разработанных нами решений уже стали стандартной практикой в компании и используются другими командами. Например, нашу «доску плача» для сбора и анализа проблем коллеги переименовали в «доску эволюции» и теперь используют на своих проектах. А наш опыт работы с закрытыми контурами помог выработать типовой подход к таким внедрениям.
Я не случайно написал «во многом» — у нас еще оставались задачи, над которыми предстояло работать. Например, процесс инсталляции ОС по-прежнему требовал некоторых ручных действий, сохранялось строгое требование к корректности заполнения техландшафта. Поэтому мы продолжили двигаться дальше, в сторону более сложных технически, но удобных в использовании инсталляторов. Благо, на рынке были и есть хорошие примеры.
Вместо постскриптума
На основе опыта нашей команды я бы выделил несколько рекомендаций для тех, кто планирует улучшать процессы внедрения сложных инфраструктурных решений.
Начните с документации
Если заказчики не понимают, что и как нужно подготовить, любая автоматизация даст лишь частичный эффект.
Документация должна быть понятна не только вашей команде, но и клиентам. Покажите документацию, например, своим джунам или стажерам, и посмотрите на результат.
Добавляйте схемы, примеры и пояснения к каждому важному пункту — люди любят глазами, а инженеры тоже люди.
Разбейте процесс на этапы
Выделите независимые части процесса внедрения.
Автоматизируйте каждый этап отдельно.
Добавьте проверки между этапами, чтобы проблемы не «проваливались» дальше по цепочке.
Автоматизируйте постепенно
Начните с операций, которые отнимают больше всего времени, закон Парето тут вполне применим.
Автоматизируйте «от простого к сложному» — мы начали со скриптов установки, а потом перешли к более сложным материям.
Не отметайте сразу простые решения, которые экономят вам время и ресурсы здесь и сейчас (тот же парсинг Excel здорово сэкономил нам время).
Думайте о масштабировании
Решения должны одинаково хорошо работать как с пятью серверами, так и с пятьюдесятью.
Учитывайте особенности закрытых контуров.
Делайте инструменты, которыми не стыдно поделиться с другими командами.
Собирайте обратную связь
Документируйте все проблемы и их решения, которые вы нашли, — как минимум, коллеги будут благодарны.
Регулярно обсуждайте с командой, что можно улучшить (тут и пригодится документирование).
Привлекайте заказчиков к обсуждению процесса внедрения продукта — они знают свою инфраструктуру.