Данило Мікула з 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 на міжнародних наукових конференціях. Більше про його проєкти та технічну роботу можна знайти на його особистому сайті, де демонструється його практичний досвід та підхід до розробки продуктів.
