Na základe diskusie v chate
V poslednej dobe zúri skutočný boj o definíciu DevOps a SRE.
Aj keď sa mnohé diskusie na túto tému stali nudnými, vrátane mňa, rozhodol som sa podeliť o svoj pohľad na vec s komunitou Habr. Záujemcovia, vitajte nižšie. A nech sa všetko začne odznova!
pravek
Takže v minulosti existoval samostatný tím vývojárov softvéru a správcov serverov. Prvý s radosťou písal kód, druhý, vyslovujúc rôzne vrúcne a láskavé slová smerom k prvému, konfiguroval servery, pravidelne navštevoval vývojárov a v odpovedi dostával vyčerpávajúce „všetko na mojom počítači funguje“. Firmy čakali na softvér, všetko bolo nečinné, periodicky padalo, všetci boli nervózni. Najmä tí, ktorí za všetok tento neporiadok platili. Slávna éra elektrónok. No, už viete, odkiaľ pochádza DevOps.
Zrod DevOps postupov
Potom prišli nejakí seriózni chlapi a povedali: „Toto nie je odvetvie, takto sa nedá pracovať.“ A predstavili modely životného cyklu. Vezmime si napríklad model V.
Takže, čo vidíme? Firma príde s konceptom, architekti navrhnú riešenia, vývojári napíšu kód a potom – zlyhanie. Niekto nejako otestuje produkt, niekto ho nejako doručí koncovému používateľovi a niekde na konci tohto zázračného modelu sedí osamelý obchodný klient a čaká na sľúbený úspech. Dospeli sme k záveru, že potrebujeme metódy na zefektívnenie tohto procesu. A tak sme sa rozhodli vytvoriť postupy, ktoré by ich implementovali.
Lyrická odbočka na tému, čo je prax
Pod pojmom prax mám na mysli kombináciu technológie a disciplíny. Príkladom je prax opisu infraštruktúry pomocou kódu Terraform. Disciplína spočíva v tom, ako opísať infraštruktúru v kóde; je to v hlave vývojára a technológia je samotný Terraform.
A rozhodli sa ich nazvať DevOps postupy – myslím, že mysleli od vývoja po prevádzku. Vymysleli všelijaké vychytávky – postupy CI/CD, postupy založené na princípe IaC, tisíce ich. A ideme na to: vývojári píšu kód, DevOps inžinieri transformujú popis systému v kóde na funkčné systémy (áno, kód je, žiaľ, len popis, nie stelesnenie systému), dodávka sa víri a tak ďalej. Včerajší administrátori, ktorí zvládli tieto nové postupy, sa hrdo preškolili na DevOps inžinierov a všetko sa rozbehlo. A bol večer a bolo ráno... prepáčte, nie z tohto smeru.
Zase nie je všetko v poriadku
Práve keď sa veci upokojili a rôzni šikovní „metodológovia“ začali písať hrubé knihy o DevOps praktikách a potichu sa rozhoreli debaty o tom, kto presne je ten notoricky známy DevOps inžinier a či je DevOps produkčná kultúra, opäť sa začala vynárať nespokojnosť. Zrazu sa ukázalo, že dodávanie softvéru je úplne netriviálna úloha. Každá vývojová infraštruktúra má svoj vlastný stack, niekde treba zostaviť, niekde treba nasadiť prostredie, tu potrebujeme Tomcat, tu potrebujeme sofistikovanú metódu spúšťania – skrátka, je to ohromujúce. A problém sa, napodiv, ukázal byť predovšetkým v organizácii procesov – táto funkcia dodávania, ako úzke hrdlo, začala blokovať procesy. Navyše, nikto neodstránil prevádzku. Vo V-modeli je neviditeľná a vpravo je celý životný cyklus. V dôsledku toho treba nejako udržiavať infraštruktúru, monitorovať ju, riešiť incidenty a dokonca aj zaoberať sa dodávaním. Inými slovami, stráviť jednu nohu vo vývoji aj v prevádzke – a zrazu tu máme túto vec „Vývoj a prevádzka“. A potom prišla šialenstvo mikroslužieb. A s tým sa vývoj začal presúvať z lokálnych počítačov do cloudu – skúste niečo ladiť lokálne, keď existujú desiatky alebo stovky mikroslužieb, nepretržité dodávanie sa stáva prostriedkom na prežitie. Pre „malú, skromnú spoločnosť“ to nie je až také zlé, ale aj tak? Čo Google?
SRE od spoločnosti Google
Prišiel Google, zjedol najväčšie kaktusy a rozhodol sa: toto nepotrebujeme, potrebujeme spoľahlivosť. A spoľahlivosť treba riadiť. A tak sa rozhodli: potrebujeme špecialistov, ktorí budú riadiť spoľahlivosť. Nazvali ich SRE a povedali, nech to tak je, robte to dobre, ako vždy. Tu je váš SLI, tu je váš SLO, tu je váš monitoring. A strkali nosy do prevádzky. A svoj „spoľahlivý DevOps“ nazvali SRE. Všetko sa zdá byť v poriadku, ale existuje jeden špinavý trik, ktorý si Google mohol dovoliť: na pozície SRE najímať ľudí, ktorí mali kvalifikáciu vývojára a tiež si urobili malú domácu úlohu, rozumeli fungovaniu živých systémov. Samotný Google má problémy s najímaním takýchto ľudí, hlavne preto, že súťaží sám so sebou – koniec koncov potrebuje niekoho, kto opíše obchodnú logiku. Dodávka je delegovaná na release inžinierov, zatiaľ čo SR inžinieri riadia spoľahlivosť (samozrejme nie priamo, ale ovplyvňovaním infraštruktúry, zmenou architektúry, monitorovaním zmien a metrík a riešením incidentov). Paráda, môžete. Čo ak však nie ste používateľom Googlu, ale spoľahlivosť je stále problémom?
Rozvoj nápadov DevOps
Tu prišiel na rad Docker, ktorý vyrástol z LXC, nasledovali ho rôzne orchestračné systémy ako Docker Swarm a Kubernetes a DevOps inžinieri si vydýchli – zjednotenie postupov zjednodušilo doručovanie. Zjednodušilo veci do takej miery, že bolo možné dokonca delegovať doručovanie na vývojárov – čo je s deployment.yaml? Kontajnerizácia rieši problém. A vyspelosť CI/CD systémov je teraz na úrovni, kde napíšete jeden súbor a všetko je spustené – vývojári si to zvládnu sami. A potom sa začneme rozprávať o tom, ako si nastaviť vlastné SRE s... no, s kýmkoľvek.
SRE nie je v spoločnosti Google
Dobre, dosiahli sme cieľ, zdá sa, že si môžeme vydýchnuť a vrátiť sa do starých dobrých čias, keď administrátori monitorovali zaťaženie CPU, ladili systémy a v pokoji a tichu popíjali z hrnčekov niečo nezrozumiteľné... Počkajte. Preto sme to celé nezačali (škoda!). Zrazu sa ukazuje, že si môžeme ľahko osvojiť vynikajúce postupy z prístupu Googlu – nezáleží na zaťažení CPU, ani na tom, ako často vymieňame disky, ani na tom, či optimalizujeme náklady na cloud, ale na obchodných metrikách – tých istých neslávne známych SLx. A stále majú správu infraštruktúry, riešenie incidentov, pravidelné zmeny v službe a vo všeobecnosti prehľad o obchodných procesoch. A chlapci, začnite už trochu programovať na dobrej úrovni – Google na vás čaká.
Aby som to zhrnul. Je to prekvapujúce, ale už vás unavuje čítanie a neviete sa dočkať, kedy autorovi napíšete komentár. DevOps ako spôsob realizácie vždy bol, je a vždy bude. A nikam sa nehne. SRE ako súbor prevádzkových postupov robí práve tento spôsob realizácie úspešným.
Zdroj: hab.com
