Danylo Mikula z Medidata Solutions przeprowadził transformację od procesów manualnych do deklaratywnych przepływów pracy – skracając czas udostępniania klastra o 97%
Dla wielu zespołów inżynieryjnych w przedsiębiorstwach Kubernetes dawno minął etap innowacji i osadził się w kategorii codziennej infrastruktury krytycznej. Jednak efektywne utrzymanie tej infrastruktury – szczególnie w wielu klastrach i środowiskach – pozostaje wyzwaniem, które spowalnia dostarczanie funkcjonalności i zwiększa ryzyko operacyjne.
W Medidata Solutions, wiodącym dostawcy rozwiązań SaaS i analityki danych wspierających badania kliniczne, to wyzwanie było szczególnie dotkliwe. Zarządzanie infrastrukturą hybrydową w środowiskach lokalnych i chmurowych – obejmującą około tuzina klastrów Kubernetes i tysiące maszyn wirtualnych – udostępnianie klastra gotowego do produkcji było długotrwałym procesem, który mógł zająć tygodnie skoordynowanych działań, obejmujących ręczną konfigurację rozproszoną między kilkoma zespołami. Aktualizacje aplikacji infrastrukturalnych były często odkładane, ponieważ historie konfiguracji nie były scentralizowane, co powodowało opóźnienia, a czasami luki w zabezpieczeniach.
To się zmieniło, gdy Danylo Mikula, architekt DevOps i infrastruktury z ponad dziesięcioletnim doświadczeniem w branżach regulowanych, dołączył do zespołu inżynierii platformowej pod koniec 2023 roku i rozpoczął gruntowną przebudowę sposobu zarządzania infrastrukturą. Mandat, jak opisuje go Danylo, był zwodniczo prosty.
„Celem nie było wprowadzanie nowych narzędzi dla samej modernizacji. Chodziło o to, aby istniejącą infrastrukturę było łatwiej obsługiwać, utrzymywać i skalować – bez zwiększania personelu lub złożoności."
– Danylo Mikula, architekt DevOps i infrastruktury, Medidata Solutions
Od manualnych kroków do deklaratywnych przepływów pracy
Rdzeń transformacji koncentrował się na konsolidacji rozdrobnionych procesów w model oparty na GitOps. Zamiast inżynierów aplikujących konfiguracje ręcznie do każdego klastra, wdrożenia przeniesiono do repozytoriów kontrolowanych wersją, a Argo CD obsługiwało synchronizację.
Wąskie gardła, które napotkał, istniały na każdym etapie. Sieć kontenerów wymagała koordynacji między zespołami inżynierii platformowej i sieciowej, z konfiguracją rozproszoną na stacjach roboczych poszczególnych inżynierów. Aplikacje infrastrukturalne były wdrażane ręcznie, z plikami wartości przechowywanymi na lokalnych maszynach. Zarządzanie sekretami podlegało tradycyjnym metodom manualnym, a procesy wdrażania ewoluowały organicznie w czasie bez scentralizowanej koordynacji. Konsolidując każdą fazę w wykresach Helm kontrolowanych wersją z nadpisaniami specyficznymi dla środowiska, Danylo skrócił czas na każdym etapie z dni do minut.
Architektura, którą zbudował Danylo, podążała za filozofią „zdefiniuj raz, wdróż wszędzie". Centralne repozytorium zawierało definicje współdzielonych usług, które automatycznie generowały wdrożenia specyficzne dla klastra, podczas gdy każde środowisko utrzymywało tylko swoje unikalne nadpisania. „Zamiast kopiować pliki konfiguracyjne przez tuzin klastrów," wyjaśnia Danylo, „stworzyliśmy system, w którym dodanie nowej usługi oznaczało napisanie jednej definicji i pozwolenie automatyzacji na resztę." To podejście obejmowało dziesiątki komponentów infrastrukturalnych – od magazynów danych i systemów przesyłania wiadomości po narzędzia bezpieczeństwa i monitorowania – przy jednoczesnym drastycznym zmniejszeniu ryzyka dryfu konfiguracji.
Dystrybucja sekretów podążała za tą samą zasadą: zamiast manualnego wstrzykiwania na klaster, integracja Vault poprzez Vault Secrets Operator automatyzowała synchronizację, zapewniając, że zmiany przepływały przez kontrolowany proces z odpowiednimi ścieżkami audytu.
Wynikiem była fundamentalna zmiana w sposobie zarządzania infrastrukturą. Czas udostępniania spadł do około 30 minut – 97,6% poprawy efektywności. Aktualizacje stały się spójne i powtarzalne, a wdrażanie nowych inżynierów wymagało mniejszej wiedzy plemiennej.
„Mieliśmy wiele zespołów przyczyniających się do tych samych środowisk, a spójność zawsze była problemem. Praca pomogła nam przejść do przewidywalnego procesu ze wspólnym źródłem prawdy. Ulepszenia nie były tylko techniczne – ułatwiły współpracę."
– Monik Gandhi, dyrektor, inżynieria chmury
Czynnik ludzki w zmianie technicznej
Współpracownicy wskazują, że sukces zmiany nie był czysto techniczny. GitOps nie był znany wszystkim na początku, a część wysiłku polegała na uczynieniu podejścia zrozumiałym i użytecznym dla inżynierów, którzy spędzili lata w imperatywnych przepływach pracy.
„Architektura była silna, ale wyróżniało się to, jak umożliwiono adopcję. Poświęcenie czasu na przeprowadzenie inżynierów przez model oznaczało, że każdy w zespole mógł teraz wdrażać lub modyfikować infrastrukturę bez potrzeby lat zgromadzonego kontekstu. Ludzie rozumieli nie tylko 'jak', ale 'dlaczego'."
– Labhesh Potdar, menedżer, inżynieria chmury
W rezultacie aktualizacje infrastruktury – wcześniej traktowane jako ryzykowne – stały się rutynowe. Zespoły zyskały pewność siebie w przeprowadzaniu zaplanowanych aktualizacji, ponieważ historie wdrożeń były widoczne i odtwarzalne.
Bezpieczeństwo jako efekt uboczny
Ulepszenia bezpieczeństwa były równie znaczące. Wcześniej utrzymywanie spójnych harmonogramów łatek było wyzwaniem, ponieważ konfiguracje wdrożeń były rozproszone w całej organizacji, a nie scentralizowane. Przejścia zespołowe naturalnie utrudniały ciągłość konfiguracji.
Przy wszystkich konfiguracjach teraz kontrolowanych wersją, zespół mógł w końcu utrzymywać spójne harmonogramy aktualizacji i śledzić dokładnie, co gdzie działa. Integracja z HashiCorp Vault zapewniła, że sekrety były zarządzane spójnie w całej infrastrukturze z odpowiednią rotacją i kontrolą dostępu – kluczową dla firmy SaaS w opiece zdrowotnej działającej w regulowanych środowiskach.
Kluczowe lekcje dla liderów inżynieryjnych
Wzorce techniczne użyte w transformacji nie są same w sobie nowatorskie – Helm, Argo CD i Vault są dobrze znanymi narzędziami. Według Danylo, wpływ pochodził z tego, jak zostały ustrukturyzowane i wprowadzone: stopniowo, z uwagą na doświadczenie programistów i nawyki organizacyjne.
Dla innych liderów inżynieryjnych rozważających podobną zmianę, Danylo wyróżnia trzy lekcje:
Zacznij od projektu repozytorium. Struktura folderów i konwencje nazewnictwa wpływają na długoterminową łatwość utrzymania. Zrobienie tego dobrze wcześnie oszczędza znaczący refaktoring później.
Automatyzuj tylko to, co zespoły mogą zrozumieć i wspierać. Adopcja ma większe znaczenie niż wyrafinowanie. Prostszy system, którego inżynierowie faktycznie używają, jest bardziej wartościowy niż elegancki, którego unikają.
Zostaw miejsce na stopniowe przejście. Przeniesienie wszystkiego naraz rzadko jest zrównoważone. Stopniowa adopcja pozwala zespołom budować pewność siebie i identyfikować problemy, zanim się skumulują.
Patrząc w przyszłość
Praca umieściła zespół platformowy Medidata w pozycji do skalowania infrastruktury bez proporcjonalnych wzrostów w manualnym wysiłku. W miarę jak liczba klastrów i aplikacji rośnie, model deklaratywny staje się bardziej wartościowy – nie tylko pod względem szybkości, ale także audytowalności, wdrażania i długoterminowej spójności.
Skupienie teraz, mówi Danylo, jest na rozszerzeniu tego samego deklaratywnego podejścia na obserwowalność – budowaniu mierzalnych SLI i zautomatyzowanego alertowania, które czynią niezawodność obiektywną praktyką, a nie kwestią intuicji.
„GitOps nie rozwiązał każdego problemu – ale uczynił rutynowe części infrastruktury mniej kruchymi i bardziej przewidywalnymi. W dużych organizacjach inżynieryjnych samo to może odblokować znaczącą efektywność."
– Danylo Mikula
Danylo Mikula jest architektem DevOps i infrastruktury w Medidata Solutions z ponad dziesięcioletnim doświadczeniem w dostarczaniu rozwiązań inżynierii chmury i platformowej w branżach regulowanych. Jego praca koncentruje się na tłumaczeniu zasad DevOps na mierzalne, powtarzalne praktyki niezawodności, podkreślając deklaratywne przepływy pracy, infrastrukturę jako kod i zarządzanie oparte na obserwowalności. Wniósł badania nad wzorcami adopcji GitOps na międzynarodowe konferencje naukowe. Więcej o jego projektach i pracy technicznej można znaleźć na jego osobistej stronie internetowej, prezentującej jego praktyczne doświadczenie i podejście do rozwoju produktu.
