Veel kord DevOps'i ja SRE kohta

Kohas põhinev arutelu vestluses AWS Minsk Community

Viimasel ajal käivad tõelised lahingud DevOpsi ja SRE mõiste määratlemise üle.
Kuigi see teema on paljudele juba tuntud ja väsitav, otsustasin siiski tuua selle Habr kogukonna arutlusele ja jagada oma seisukohta. Kõik, kes on huvitatud, olete teretulnud allapoole lugema. Las kõik algab uuesti!

Eellugu

Nii oli kunagi kauges minevikus eraldi tarkvaraarendajate ja serverihaldurite meeskond. Esimesed kirjutasid koodi, teised, kasutades erinevaid soojaid ja sõbralikke väljendeid esimate aadressil, seadistasid servereid, külastades arendajaid ja saades vastuseks ammendavat "minu masina peal töötab kõik". Äri ootas tarkvara, kõik seisis, aeg-ajalt purunes, kõik olid närvilised. Eriti see, kes selle kogu kaose eest maksis. Suurepärane, nostalgiline aeg. Tõenäoliselt te juba teate, kust on DevOps pärit.

DevOps praktika sünd

Siis tulid tõsised mehed ja ütlesid — see ei ole tööstus, nii töötada ei saa. Ja tõid kaasa elutsükli mudelid. Näiteks V-mudel.

Nii et, mida me näeme? Äri tuleb kontseptsiooniga, arhitektid projekteerivad lahendusi, arendajad kirjutavad koodi, edasi — ebaõnnestumine. Keegi testib toodet kuidagi, keegi toimetab selle lõpptarbijale ja kuskil selle imemudeli väljundis istub üksi äri tellija ja ootab lubatud ilmadelt. Jõuti järeldusele — on vaja meetodeid, mis aitaksid selle protsessi korraldada. Otsustati luua praktika, mis need meetodid ellu viiks.

Lühiülevaade, mis on praktika
Praktikaga mõistan ma tehnoloogia ja distsipliini ühendust. Näide — infrastruktuuri kodeerimise praktika terraformis. Distsipliin on see, kuidas infrastruktuuri koodiga kirjeldada, see on arendaja peas, ja tehnoloogia on tegelikult terraform.

Nad olid otsustanud nimetada neid DevOps praktikuteks — arvan, et nad mõtlesid alates arendamisest kuni rakendamiseni. Nad leiutasid erinevaid keerulisi asju — CI/CD praktikad, praktikad, mis põhinevad IaC põhimõttel, tuhandeid neist. Ja läks lahti, arendajad kirjutavad koodi, DevOps insenerid muudavad süsteemi kirjelduse koodiks töötavateks süsteemideks (jah, kahjuks on kood vaid kirjeldus, mitte süsteemi teostus), tarned käivad, ja nii edasi. Eelnevad administraatorid, kes olid omandanud uusi praktikaid, uhkelt ümber õpetanud DevOps insenerideks, ja kõik läks liikvele. Ja oli õhtu, ja oli hommik… vabandage, vale koht.

Kõik ei ole jälle hästi.

Alles see toimus, kui erinevad nutikad „meetodoloogid“ hakkasid kirjutama paksu raamatuid DevOps praktikate kohta, tekkisid vaikselt vaidlused, kes on see kuulus DevOps insener ja mis on DevOps — kultuur tootmises, rahulolematus lõi taas välja. Ühtäkki selgus, et tarkvara tarnimine on täiesti mittetriviaalne ülesanne. Igal arendusinfrastruktuuril on oma tehnoloogiad, aeg-ajalt tuleb midagi koguda, aeg-ajalt käivitada keskkond, siin on vajalik tomcat, seal on veel keeruline viis käivitamiseks — kokkuvõttes on pea plahvatusohtlik. Ja veel probleem, nagu mitte üllatavalt, osutus kõigepealt seotud protsesside korraldamisega — see tarnefunktsioon, nagu pudeļkael, hakkas blokeerima protsesse. Lisaks ei ole keegi opereerimist (Operations) tühistanud. Seda ei ole V-mudelis näha, samas kui seal on veel kogu elutsükkel paremal. Kokkuvõttes peab toetama infrastruktuuri, jälgima monitooringut, lahendama intsidente ja tegelema veel tarnimisega. St peab olema ühe jalaga nii arenduses kui ka halduses — ja äkki saime sellise Development & Operations. Ja siis tuli veel mikroteenuste suur buum. Ja koos nendega hakkas arendus kohalikelt masinatelt pilve üle minema — proovi midagi kohapeal siluda, kui mikroteenuseid on kümneid ja sadu, siis muutub pidev tarnimine ellujäämise vahendiks. „Väikesele tagasihoidlikule ettevõttele“ pole see veel probleem, aga ikkagi? Aga Google?

Google'i SRE

Google tuli, sõi kõige suuremad kaktused ja otsustas — me ei vaja seda, me vajame usaldusväärsust. Ja usaldusväärsust tuleb hallata. Otsustas, et on vaja spetsialiste, kes usaldusväärsust haldavad. Nimed nad SR-insenerideks ja ütlesid: siin on kõik, tehke nagu tavaliselt hästi. Siin on SLI, siin on SLO, siin on jälgimine. Ja suunas nad operations'i poole. Ja nimetas oma "usaldusväärse DevOpi" SRE-ks. Kõik näib hea, aga on üks räpane trik, mille Google endale lubada sai — SR-inseneride ametikohtadele palgata inimesi, kellel oli arendaja kvalifikatsioon ja kes natuke tundsid töötavate süsteemide toimimist. Pealegi on Google'il endal nende inimeste palkamisega probleeme — peamiselt seetõttu, et ta konkureerib iseendaga — peab ju ka äriloogikat kellelegi kirjeldama. Toimetuse jättis välja väljaandetehnilistele inseneridele, SR-insenerid haldavad usaldusväärsust (loomulikult mitte otseselt, vaid mõjutades infrastruktuuri, muutes arhitektuuri, jälgides muudatusi ja näitajaid, tegeledes intsidentidega). Ilus, eks? raamatuid kirjutama. Ja mis siis, kui te ei ole Google, aga usaldusväärsus siiski muret tekitab?

DevOpi ideede areng

Siin tuli just õigel ajal Docker, mis kasvas välja lxc-st, seejärel erinevad orkestreerimissüsteemid, nagu Docker Swarm ja Kubernetes, ja DevOps insenerid hingasid kergendatult — praktika unifikatsioon lihtsustas toimetust. Lihtsustas sedavõrd, et oli võimalik isegi anda toimetamine arendajatele — mis seal deployment.yaml. Konteinerisus lahendab probleemi. Ja CI/CD süsteemide küpsus on juba sellisel tasemel, et ühe faili kirjutamine ja kõik on käes — arendajad saavad ise hakkama. Ja nüüd hakkame rääkima, kuidas teha oma SRE, olgu see… kellegi kõrval.

SRE ei ole Google'is

Noh, me oleme tellimise üle andnud, näib, et saame hingata ja naasta vanade headeni aegadesse, mil adminnid jälgisid protsessorite koormust, lihvisid süsteeme ja vaikselt jõid tassidest midagi arusaamatut vaikuses ja rahus... Oota. Me ei hakanud seda kõike tegema selle pärast (kahju!). Üks hetk selgub, et Google'i lähenemisviisis saame täiesti võtta suurepäraseid praktikaid — mitte protsessorite koormus ei ole oluline, mitte see, kui sageli me seal kettaid vahetame, või pilves kulusid optimeerime, vaid äri-metriigid — kõik need ühed ja samad kuulsad SLx. Ja infrastruktuuri juhtimist ei ole kellestki keegi maha võtnud, ja juhtumeid tuleb lahendada, ja regulaarselt tuleb kohal olla, ja üldiselt on äri-protsessidest teadlik olla. Ja poisid, hakake juba tasapisi korralikult programmeerima, Google ootab teid juba.

Kokkuvõttes. Üks hetk, aga te olete juba väsinud lugemisest ja teil on tung kirjutada autorile artikli kommentaariumis. DevOps kui tarnimise praktika, oli, on ja jääb. Ja kuhugi ei kao. SRE kui praktikate kogum muudab selle tarnimise edukaks.

Allikas: habr.com