Veel räägime DevOps'ist ja SRE'st

Inspireeritud vestlusest vestluses AWS Minsk kogukond

Viimasel ajal käivad tõelised lahingud selle üle, kuidas määratleda DevOps'i ja SRE'd.
Kuigi arutelud sellel teemal on palju korduvad, otsustasin siiski tuua hapra kogukonna ette oma vaate. Huvi korral olete oodatud allpool. Ja laskem kõigel alata uuesti!

Eelalugu

Nii olid ammu-ammu eraldi tarkvaraarendajate ja serverihaldurite tiimid. Esimesed kirjutasid edukalt koodi, teised, kasutades erinevaid sooje ja hellitavaid sõnu esimestele, seadistusid serverid, tulevikus külastades arendajaid ja saades vastuseks põhjaliku "minu masinas kõik töötab". Äri ootas tarkvara, kõik seisab, vahel puruneb, kõik olid närvis. Erakordselt keegi, kes kogu selle segaduse eest maksab. Suur ja soe ajastu. Aga te juba teate, kust DevOps'i juured tulevad.

DevOps'i praktika sünni

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

Nii et, mida me näeme? Äri tuleb ideega, arhitektid kavandavad lahendusi, arendajad kirjutavad koodi, edasi toimub kukkumine. Keegi katsetab toodet mingil moel, keegi toimetab selle lõppkasutajale ja kuskil selle imemudeli väljundis istub üksildane äriklient ja ootab lubatud ilu merest. Oleme jõudnud järeldusele, et on vajalikud meetodid, mis võimaldavad selle protsessi korda saada. Otsustasime luua praktikaid, mis neid ellu viivad.

Lühiülevaade teema kohta, mis on praktika
Praktikaks mõistan ma tehnoloogia ja distsipliini seost. Näide — praktika infrastruktuuri kirjeldamisest koodina terraformis. Distsipliin on see, kuidas infrastruktuuri koodina kirjeldada; see on arendaja peas, ja tehnoloogia on iseenesest terraform.

Nad otsustasid nad nimetada neid DevOps praktikateks — arvan, et nad mõtlesid arendusest operatsioonidele. Loodud on erinevaid keerulisi asju — CI/CD praktikad, praktikad, mis põhinevad IaC põhimõttel, tuhanded neist. Ja kõik hakkas pihta, arendajad kirjutavad koodi, DevOps insenerid muudavad süsteemi kirjelduse koodina töötavateks süsteemideks (jah, kood on kahjuks vaid kirjeldus, mitte süsteemi kehastus), tarne käib, ja nii edasi. Eilsetest administraatoritest, kes olid omandanud uusi praktikaid, said uhkelt DevOps insenerid, ja kõik algas. Ja õhtu sai ja hommik… vabandust, vale koht.

Kõik on taas halvasti

Lõpuks, kui kõik paika loksus, hakkasid erinevad nutikad "metoodikud" kirjutama paksu raamatuid DevOpsi praktikast. Vaikselt süttisid vaidlused selle üle, kes tõeliselt on see kurikuulus DevOps insener ja et DevOps on tootmiskultuur. Rahulolematus kerkis taas päevakorda. Ükskord selgus, et tarkvara kohaletoimetamine on täiesti keeruline ülesanne. Igal arendusstruktuuril on oma tehnoloogiapakk, kuskil tuleb koguda, kuskil tuleb keskkonda käivitada — siin on vaja tomcatit, seal on veel kohandatud käivitamisviisi — kokkuvõttes ajab pea ringi. Ja veel oli probleemiks, nagu mitte üllatavalt, protsesside korraldamine — see kohaletoimetamise funktsioon, nagu pudelikael, hakkas protsesse blokeerima. Lisaks, operatsioonide (Operations) tähtsust ei saa unustada. V-mudelis ei ole seda näha ja seal on terve elutsükkel paremal. Lõpuks tuleb hooldada ka infrastruktuuri, jälgida monitooringut ja lahendada intsidendid, ning veel tegeleda kohaletoimetamisega. St tuleb samal ajal istuda nii arenduses kui ka ekspluateerimises — ja nii sündis Development & Operations. Siis tuli veel ka suur buum mikroteenustele. Nende varal hakkas arendus kohalikelt masinatelt kolima pilve — proovi kohalikke lahendusi testida, kui mikroteenuseid on kümneid ja sadu; pidev kohaletoimetamine muutub ellujäämise meetodiks. "Väikesele ja tagasihoidlikule ettevõttele" on see veel arusaadav, aga kuidas siis? Ja Google?

Google'i SRE

Google tuli, sõi kõige suuremad kaktused ja otsustas — me ei vaja sellist, me vajame usaldusväärsust. Ja usaldusväärsusega peab tegelema. Otsustas — meil on vaja spetsialiste, kes tegeleksid usaldusväärsusega. Ta nimetas neid SR-insenerideks ja ütles, olge head, tehke nagu tavaliselt hästi. Siin on Teile SLI, siin on Teile SLO, siin on Teile jälgimine. Ja näitas operations'i poole. Ja nimetas oma "usaldusväärse DevOpsi" SRE-ks. Kõik näib olevat hästi, kuid on üks must häkk, mida Google endale lubada sai — SR-inseneride kohtadele palgata inimesi, kellel olid arendaja kvalifikatsioon ja kes veel natuke said aru töötavatest süsteemidest. Lisaks on selliste inimeste palkamisega probleeme ka Google’il endal — peamiselt seetõttu, et ta konkureerib iseenda vastu — keegi peab ju ka äriloogikat kirjeldama. Tööülesanded jagati välja väljalasketehnika inseneridele, SR-insenerid juhivad usaldusväärsust (loomulikult mitte otseselt, vaid mõjutades infrastruktuuri, muutes arhitektuuri, jälgides muutusi ja näitajaid ning tegeledes intsidentidega). Ilus, võib raamatuid kirjutada. Aga mida teha, kui te ei ole Google, aga usaldusväärsus ükskõik kuidas häirib?

DevOps'i ideede arendamine

Siin tuli õigeaegselt Docker, mis kasvas välja lxc-st, ning seejärel erinevad orkestreerimissüsteemid nagu Docker Swarm ja Kubernetes, ning DevOps insenerid hingasid kergendusest — praktikate ühtlustamine lihtsustas tarnimist. Lihtsustas nii palju, et arendajad saavad isegi tarnimise enda hooleks võtta — mis see deployment.yaml siis on. Konteineriseerimine lahendab probleemid. Ja CI/CD süsteemide küpsus on juba sellisel tasemel, et piisab ühest failist ja kõik läheb käima — arendajad saavad hakkama. Ja siis hakkame rääkima, kuidas teha oma SRE, kellega... kasvõi kellegagi.

SRE pole Google'is

Noh, kohaletoimetamine on lõpuks korda saadetud, põhimõtteliselt saame hinge hõlbustada ja tagasi minna vanade head aega, mil adminnid jälgisid protsessorite koormust, häälestasid süsteeme ja vaikides jõid midagi arusaamatut rahus ja vaikuses... Oota. Me ei teinud seda kõike sellepärast (kahju!). Ühel hetkel selgub, et Google'i lähenemisviisist on meil täiesti võimalik võtta imetlusväärsed praktikad — mitte protsessorite koormus ei ole oluline, ega see, kui tihti me seal kõvakettasid vahetame, või kuidas me seal pilves kulusid optimeerime, vaid ärimeetmed — kõik need kuulsad SLx. Ja infrastruktuuri haldamine ei ole kedagi ära jäänud, ja intsidendid tuleb lahendada, ja aeg-ajalt peab olema valves, ja üldiselt olema kursis äriprotsessidega. Ja poisid, hakake juba natuke korralikult programmeerima, Google on teid juba oodanud.

Kokkuvõtteks. Ühel hetkel, kuid te olete juba väsinud lugema ja ei suuda oodata, et kirjutada autorile kommentaar artiklisse. DevOps kui tarnimispraktika on olnud, on ja jääb. See ei kao kuhugi. SRE kui praktikateseade teeb selle sama tarnimise edukaks.

Allikas: habr.com