Данило Микула из Medidata Solutions провел переход от ручных процессов к декларативным рабочим процессам, сократив время развертывания кластера на 97%
Для многих корпоративных инженерных команд Kubernetes давно прошел стадию инноваций и занял место повседневной критической инфраструктуры. Однако эффективное обслуживание этой инфраструктуры — особенно в нескольких кластерах и средах — остается проблемой, которая замедляет поставку функций и увеличивает операционные риски.
В Medidata Solutions, ведущем поставщике SaaS-решений и решений для аналитики данных, поддерживающих клинические исследования, эта проблема была особенно острой. Управление гибридной инфраструктурой в локальных и облачных средах — включая около десятка кластеров Kubernetes и тысячи виртуальных машин — развертывание готового к работе кластера было длительным процессом, который мог занять недели скоординированных усилий, включая ручную настройку, распределенную между несколькими командами. Обновления приложений инфраструктуры часто откладывались, потому что истории конфигураций не были централизованы, что создавало задержки и, временами, пробелы в безопасности.
Это изменилось, когда Данило Микула, DevOps и архитектор инфраструктуры с более чем десятилетним опытом работы в регулируемых отраслях, присоединился к команде инженеров платформы в конце 2023 года и начал пересматривать способ управления инфраструктурой. Задача, как описывает ее Данило, была обманчиво простой.
"Цель заключалась не в том, чтобы внедрить новые инструменты ради модернизации. Задача состояла в том, чтобы сделать существующую инфраструктуру более простой в эксплуатации, обслуживании и масштабировании — без увеличения штата или сложности."
– Данило Микула, DevOps и архитектор инфраструктуры, Medidata Solutions
От ручных шагов к декларативным рабочим процессам
Суть трансформации заключалась в консолидации фрагментированных процессов в модель на основе GitOps. Вместо того чтобы инженеры вручную применяли конфигурации к каждому кластеру, развертывания переместились в репозитории с контролем версий, а Argo CD обрабатывал синхронизацию.
Узкие места, с которыми он столкнулся, существовали на каждом этапе. Сетевые подключения контейнеров требовали координации между командами инженеров платформы и сетевыми командами, при этом конфигурация была разбросана по рабочим станциям отдельных инженеров. Приложения инфраструктуры развертывались вручную, файлы значений хранились на локальных машинах. Управление секретами следовало традиционным ручным подходам, а процессы развертывания эволюционировали органически со временем без централизованной координации. Объединив каждый этап в Helm-чарты с контролем версий и переопределениями для конкретных сред, Данило сократил время на каждый этап с дней до минут.
Архитектура, созданная Данило, следовала философии "определи один раз, разверни везде". Центральный репозиторий содержал общие определения сервисов, которые автоматически генерировали развертывания для конкретных кластеров, в то время как каждая среда поддерживала только свои уникальные переопределения. "Вместо копирования файлов конфигурации по десятку кластеров," объясняет Данило, "мы создали систему, где добавление новой услуги означало написание одного определения и позволяло автоматизации справиться с остальным." Этот подход охватывал десятки компонентов инфраструктуры — от хранилищ данных и систем обмена сообщениями до инструментов безопасности и мониторинга — одновременно резко снижая риск расхождения конфигураций.
Распространение секретов следовало тому же принципу: вместо ручного внедрения для каждого кластера интеграция Vault через Vault Secrets Operator автоматизировала синхронизацию, обеспечивая прохождение изменений через контролируемый процесс с соответствующими журналами аудита.
Результатом стал фундаментальный сдвиг в управлении инфраструктурой. Время развертывания сократилось примерно до 30 минут — улучшение эффективности на 97,6%. Обновления стали согласованными и повторяемыми, а адаптация новых инженеров требовала меньше знаний племени.
"У нас было несколько команд, работающих в одних и тех же средах, и согласованность всегда была проблемой. Работа помогла нам перейти к предсказуемому процессу с общим источником истины. Улучшения были не только техническими — они облегчили совместную работу."
– Моник Ганди, директор, облачные вычисления
Человеческий фактор в техническом изменении
Коллеги отмечают, что успех перехода был не чисто техническим. GitOps не был знаком всем в начале, и часть усилий заключалась в том, чтобы сделать подход понятным и пригодным для инженеров, которые годами работали в императивных рабочих процессах.
"Архитектура была сильной, но выделялось то, как было обеспечено принятие. Потратив время на то, чтобы провести инженеров через модель, означало, что теперь любой в команде мог развернуть или изменить инфраструктуру без необходимости накапливать годы контекста. Люди поняли не только 'как', но и 'почему'."
– Лабхеш Потдар, менеджер, облачные вычисления
В результате обновления инфраструктуры — ранее рассматриваемые как рискованные — стали рутинными. Команды приобрели уверенность в выполнении запланированных обновлений, потому что истории развертывания были видимыми и воспроизводимыми.
Безопасность как побочный эффект
Улучшения безопасности были столь же значительными. Ранее поддержание согласованных графиков исправлений было сложным, потому что конфигурации развертывания были распределены по организации, а не централизованы. Переходы команд естественным образом усложняли преемственность конфигураций.
Теперь, когда все конфигурации находятся под контролем версий, команда наконец могла поддерживать согласованные графики обновлений и точно отслеживать, что и где работает. Интеграция с HashiCorp Vault обеспечила согласованное управление секретами по всей инфраструктуре с надлежащей ротацией и контролем доступа — критически важное для компании SaaS в здравоохранении, работающей в регулируемых средах.
Ключевые уроки для инженерных лидеров
Технические шаблоны, использованные в трансформации, сами по себе не являются новыми — Helm, Argo CD и Vault являются хорошо известными инструментами. По словам Данило, эффект исходил из того, как они были структурированы и внедрены: постепенно, с вниманием к опыту разработчиков и организационным привычкам.
Для других инженерных лидеров, рассматривающих аналогичный переход, Данило выделяет три урока:
Начните с дизайна репозитория. Структура папок и соглашения об именовании влияют на долгосрочную поддерживаемость. Правильная настройка с самого начала экономит значительный рефакторинг позже.
Автоматизируйте только то, что команды могут понять и поддерживать. Принятие важнее изощренности. Более простая система, которую инженеры действительно используют, более ценна, чем элегантная, которую они избегают.
Оставьте место для постепенного перехода. Перемещение всего сразу редко бывает устойчивым. Постепенное принятие позволяет командам укрепить уверенность и выявить проблемы до их усугубления.
Взгляд в будущее
Работа позиционировала платформенную команду Medidata для масштабирования инфраструктуры без пропорционального увеличения ручных усилий. По мере роста количества кластеров и приложений декларативная модель становится более ценной — не только для скорости, но и для аудита, адаптации и долгосрочной согласованности.
Теперь, говорит Данило, фокус направлен на распространение того же декларативного подхода на наблюдаемость — создание измеримых SLI и автоматизированных оповещений, которые делают надежность объективной практикой, а не вопросом интуиции.
"GitOps не решил все проблемы — но он сделал рутинные части инфраструктуры менее хрупкими и более предсказуемыми. В крупных инженерных организациях одно это может разблокировать значимую эффективность."
– Данило Микула
Данило Микула — DevOps и архитектор инфраструктуры в Medidata Solutions с более чем десятилетним опытом предоставления решений для облачных вычислений и платформенной инженерии в регулируемых отраслях. Его работа фокусируется на переводе принципов DevOps в измеримые, повторяемые практики надежности, делая акцент на декларативных рабочих процессах, инфраструктуре как коде и управлении на основе наблюдаемости. Он внес вклад в исследования паттернов принятия GitOps на международных научных конференциях. Больше о его проектах и технической работе можно найти на его личном сайте, демонстрирующем его практический опыт и подход к разработке продуктов.
