Medidata Solutionsi Danylo Mikula juhtis üleminekut käsitsi protsessidelt deklaratiivsetele töövoogudele – klasteri ettevalmistamise aeg vähenes 97%
Paljude suurte ettevõtete inseneriteamade jaoks on Kubernetes juba ammu läbinud innovatsiooni staadiumi ja muutunud igapäevaseks kriitiliseks infrastruktuuriks. Siiski jääb selle infrastruktuuri tõhus hooldamine – eriti mitmes klasteris ja erinevates keskkondades – probleemiks, mis aeglustab funktsioonide väljatoomist ja suurendab operatsioonilist riski.
Medidata Solutionsis, juhtiva SaaS- ja andmeanalüüsi lahenduste pakkujana kliiniliste uuringute toetamiseks, oli see probleem eriti teravnennud. Hübriidinfrastruktuuri haldamine nii serverites kui ka pilves – sealhulgas umbes kümme Kubernetesi klasterit ja tuhandeid virtuaalmasinaid – nõudis tootmisvalmis klasteri ettevalmistamiseks pikka protsessi, mis võis kesta nädalaid koordineeritud pingutusi, kus konfiguratsioonid oli käsitsi tehtud mitmes erinevas tiimis. Infrastruktuuri rakenduste uuendused lükati sageli edasi, kuna konfiguratsiooniloojad ei olnud tsentraliseeritud, mis põhjustas viivitusi ja mõnikord ka turvaaugusid.
Kõik muutus, kui Danylo Mikula, üle kümne aasta kogemusega reguleeritud valdkondades DevOpsi ja infrastruktuuri arhitekt, astus platvormiinsenerite tiimi 2023. aasta lõpus ja alustas infrastruktuuri haldamise viisi täielikku ümberkujundamist. Tema sõnul oli ülesanne petlikult lihtne.
„Eesmärk ei olnud uute tööriistade tutvustamine moderniseerimise nimel. Eesmärk oli muuta olemasolev infrastruktuur lihtsamaks kasutada, hooldada ja skaalata – ilma personali või keerukuse suurendamiseta.“
– Danylo Mikula, DevOpsi ja infrastruktuuri arhitekt, Medidata Solutions
Käsitsi sammudest deklaratiivsete töövoogudele
Teisenduse tuum oli fragmenteeritud protsesside konsolideerimine GitOpsi põhise mudeli alla. Asemel, et insenerid rakendaksid konfiguratsioone käsitsi igasse klasterisse, liiguti rakenduste paigaldamisel versioonihaldatavatesse repositooriumidesse, kus Argo CD haldas sünkroonimist.
Ta esinevad kitsaskohad olid olemas igas etapis. Konteinerite võrgustamine nõudis platvormiinsenerite ja võrguinsenerite koostööd, kus konfiguratsioonid olid laiali hajutatud üksikute insenerite töökohas. Infrastruktuuri rakendused paigaldati käsitsi, kus väärtusfailid asusid kohalikes masinates. Saladuste haldamine järgis traditsioonilisi käsitsi lähenemisi ja paigaldusprotsessid olid aastate jooksul organiliselt arenenud ilma tsentraliseeritud koordineerimiseta. Kõigi etappide konsolideerimine versioonihaldatavatesse Helm-i diagrammidesse koos keskkonna-spetsiifiliste ülekirjutustega vähendas Danylo iga etapi aega päevadest minutitesse.
Danylo ehitatud arhitektuur järgis „defineeri üks kord, paigalda kõikjal“ filosoofiat. Ühises repositooriumis hoiti jagatud teenuste definitsioone, mis automaatselt genereerisid klasteri-spetsiifilised paigaldused, samas kui iga keskkond säilitas ainult oma unikaalsed ülekirjutused. „Asemel, et kopeerida konfiguratsioonifaile kümne klasteri vahel,“ selgitab Danylo, „loodime süsteemi, kus uue teenuse lisamine tähendas ühe definitsiooni kirjutamist ja automatiseerimise ülejäänud osa tegemist.“ See lähenemine hõlmas kümneid infrastruktuuri komponente – andmebaasidest ja sõnumisüsteemideni kuni turvavahenditeni ja jälgimistööriistadeni – samas kui konfiguratsioonihälbe risk vähenes dramaatiliselt.
Saladuste levitamine järgis sama põhimõtet: asemel, et sisestada neid käsitsi igasse klasterisse, automatiseeris Vault Secrets Operatori integreerimine Vault’i kaudu sünkroonimise, tagades, et muudatused läbisid kontrollitud protsessi koos sobivate audititeekidega.
Tulemuseks oli infrastruktuuri haldamise põhimõtteline muutus. Ettevalmistamise aeg langes umbes 30 minutisse – 97,6% efektiivsuse paranevus. Uuendused said ühtlustatud ja korduvad ning uute insenerite sisseviimine nõudis vähem „tribaalset teadmist“.
„Meil oli mitu tiimi, kes panustasid samadesse keskkondadesse, ja ühtlus oli alati murekohana. Töö aitas meil liikuda etteaimatavasse protsessi ühise tõesalliku poole. Parandused ei olnud lihtsalt tehnilised – nad muutsid koostöö lihtsamaks.“
– Monik Gandhi, Pilveinsenerite direktor
Inimese roll tehnilistes muutustes
Kollegad rõhutavad, et ülemineku edu ei olnud puhtalt tehniline. GitOps ei olnud alguses kõigile tuttav ja osa tööst oli seetõttu seda lähenemist teha mõistetavaks ja kasutatavaks inseneritele, kes olid aastaid töötanud imperatiivsetes töövoogudes.
„Arhitektuur oli tugev, kuid mida silma paistis, oli see, kuidas võimaldati selle kasutuselevõtt. Aeg, mille kulutasime insenerite juhendamisele selle mudeli kaudu, tähendas seda, et nüüd saab iga tiimi liige paigaldada või muuta infrastruktuuri ilma aastakümnete kogutud kontekstita. Inimesed mõistsid mitte ainult ‚kuidas‘, vaid ka ‚miks‘.“
– Labhesh Potdar, Pilveinsenerite juhataja
Selle tulemusena muutusid infrastruktuuri uuendused – varem riskantseteks peetud – tavapäraseks. Tiimid said enamus kindlust tunnistada planeeritud uuenduste käivitamisel, kuna paigalduslooja oli nähtav ja taastatav.
Turvalisus kõrvaltoimena
Turvalisuse parandused olid samuti olulised. Varasemalt oli ühtlaste paranduste ajastuse hooldamine keeruline, kuna paigalduskonfiguratsioonid olid organisatsioonis laialdaselt jaotatud ning ei olnud tsentraliseeritud. Tiimide üleminekud tegid loomulikult konfiguratsioonide pidevuse veelgi raskemaks.
Nüüd, kui kõik konfiguratsioonid on versioonihaldatavad, suutis tiim lõpuks säilitada ühtlasi uuendusgraafikuid ja jälgida täpselt, mis on kusagil käimas. HashiCorp Vault’i integratsioon tagas saladuste ühtse haldamise kogu infrastruktuuris koos korralikku pööratavuse ja ligipääsu juhtimisega – kriitiliselt tähtis tervishoiu SaaS-ettevõttele, kes tegeleb reguleeritud keskkondades.
Peamised õppetunnid insenerijuhtidele
Teisenduses kasutatud tehnilised musterid pole ise omad – Helm, Argo CD ja Vault on hästi teadaolevad tööriistad. Danylo sõnul tulenes mõju nende struktureerimisest ja tutvustamisest: järkjärguliselt, pöörates tähelepanu arendaja kasutajakogemusele ja organisatsioonilistele harjumustele.
Teistele insenerijuhtidele, kes kaaluvad sarnase ülemineku tegemist, tõstab Danylo esile kolm õppetundi:
Alusta repositooriumi disainiga. Kaustastruktuur ja nimetuskonventsioonid mõjutavad pikaajalist hooldatavust. Õige valik varajasel etapis säästab olulisi refaktoreerimisi hiljem.
Automatiseeri ainult seda, millest tiimid saavad aru ja mida nad suudavad toetada. Kasutuselevõtt on tähtsam kui sofistikatsioon. Lihtsam süsteem, mida insenerid tegelikult kasutavad, on väärtuslikum kui elegantne süsteem, mida nad vältivad.
Jäta ruumi järkjärguliselt üleminekule. Kõike korraga üle viimine on harva jätkusuutlik. Järkjärguline kasutuselevõtt võimaldab tiimidel enne probleemide kumulatsiooni kindlustunda ja probleeme tuvastada.
Edaspidi
See töö positsioneeris Medidata platvormi tiimi nii, et infrastruktuuri skaala saab suurendada ilma proportsionaalse kasvu käsitsi pingutustes. Klasterite ja rakenduste arvu kasvades muutub deklaratiivne mudel veelgi väärtuslikumaks – mitte ainult kiiruse, vaid ka auditeeritavuse, sisseviimise ja pikaajalise ühtluse jaoks.
Nüüd, ütleb Danylo, on fookus laiendada sama deklaratiivset lähenemist jälgimisele – ehitada mõõdetavad SLI-d ja automatiseeritud hoiatused, mis muudavad usaldusväärsuse objektiivseks praktikaks, mitte intuitsioonipõhiseks küsimuseks.
„GitOps ei lahendanud kõiki probleeme – kuid ta tegi infrastruktuuri igapäevased osad vähem haavatavaks ja ennustatavamaks. Suurtes inseneriettevõtetes on see iseenda eest juba tähenduslik tõhususe võitmise allikaks.“
– Danylo Mikula
Danylo Mikula on DevOpsi ja infrastruktuuri arhitekt Medidata Solutionsis, kellel on üle kümne aasta kogemuse pilve- ja platvormiinsenerilahenduste pakumisel reguleeritud valdkondades. Tema töö keskendub DevOpsi printsiipide ülekandele mõõdetavatesse, korduvatesse usaldusväärsuse praktikatesse, rõhutades deklaratiivseid töövoogusid, infrastruktuuri koodina (IaC) ja jälgimisega juhitavat valitsemist. Ta on esitanud uurimust GitOpsi kasutuselevõtu musteritest rahvusvahelistel teaduskonverentsidel. Veel teavet tema projektidest ja tehnilisest tööst leiate tema isiklikult veebisaidilt, kus on esitatud tema praktiline kogemus ja tootearenduse lähenemine.
