Na podlagi razprave v klepetu
V zadnjem času so se vnele prave bitke glede definicije DevOps in SRE.
Kljub temu, da so mi razprave na to temo v marsičem že narezale zobe, tudi meni, sem se odločil, da svoj pogled na to temo posredujem na sodišče skupnosti Habra. Kogar zanima, vabljeni na kat. In naj se vse začne znova!
prazgodovina
Tako je v starih časih skupina razvijalcev programske opreme in skrbnikov strežnikov živela ločeno. Prvi je uspešno napisal kodo, drugi je z različnimi toplimi, ljubečimi besedami, naslovljenimi na prvega, vzpostavil strežnike, občasno prišel do razvijalcev in v odgovor prejel izčrpno "na mojem računalniku vse deluje." Posel je čakal na programsko opremo, vse je mirovalo, občasno se je pokvarilo, vsi so bili živčni. Še posebej tisti, ki je plačal vso to zmešnjavo. Slavna doba svetilk. No, že veste, od kod prihaja DevOps.
Rojstvo praks DevOps
Potem so prišli resni fantje in rekli - to ni panoga, tako se ne da delati. In prinesli so modele življenjskega cikla. Tukaj je na primer V-model.
Kaj torej vidimo? Podjetje pride s konceptom, arhitekti oblikujejo rešitve, razvijalci napišejo kodo, potem pa propade. Nekdo izdelek nekako preizkusi, nekdo ga nekako dostavi končnemu uporabniku in nekje na izhodu tega čudežnega modela sedi osamljena poslovna stranka, ki ob morju čaka na obljubljeno vreme. Prišli smo do zaključka, da potrebujemo metode, ki nam bodo omogočile vzpostavitev tega procesa. In odločili smo se, da bomo ustvarili prakse, ki jih bodo izvajale.
Lirična digresija na temo, kaj je praksa
S prakso mislim na kombinacijo tehnologije in discipline. Primer je praksa opisovanja infrastrukture z uporabo teraformne kode. Disciplina je, kako opisati infrastrukturo s kodo, je v glavi razvijalca, tehnologija pa je sama teraforma.
In odločili so se, da jih poimenujejo prakse DevOps – mislim, da so mislili od razvoja do operacij. Prišli smo do različnih pametnih stvari - CI/CD prakse, prakse, ki temeljijo na principu IaC, na tisoče jih je. In gremo, razvijalci napišejo kodo, inženirji DevOps transformirajo opis sistema v obliki kode v delujoče sisteme (ja, koda je na žalost samo opis, ne pa utelešenje sistema), dobava se nadaljuje, in tako naprej. Včerajšnji skrbniki, ki so obvladali nove prakse, so se ponosno prekvalificirali v inženirje DevOps in od tam je šlo vse. In bil je večer in bilo je jutro ... oprostite, ne od tam.
Spet ni vse v redu, hvala bogu
Takoj, ko se je vse umirilo in so razni zviti "metodologi" začeli pisati debele knjige o praksah DevOps, so se tiho razplamteli spori o tem, kdo je razvpiti inženir DevOps in da je DevOps produkcijska kultura, se je spet pojavilo nezadovoljstvo. Nenadoma se je izkazalo, da je dobava programske opreme povsem netrivialna naloga. Vsaka razvojna infrastruktura ima svoj sklad, nekje jo morate sestaviti, nekje morate razmestiti okolje, tukaj potrebujete Tomcat, tukaj potrebujete zvit in zapleten način za zagon - na splošno vam glava razbija. In nenavadno se je izkazalo, da je težava predvsem v organizaciji procesov - ta funkcija dostave je kot ozko grlo začela blokirati procese. Poleg tega nihče ni preklical operacij. Pri V-modelu ni viden, vendar je na desni še vedno celoten življenjski cikel. Posledično je treba nekako vzdrževati infrastrukturo, spremljati nadzor, reševati incidente in se ukvarjati tudi z dostavo. Tisti. sedi z eno nogo tako pri razvoju kot pri delovanju – in nenadoma se je izkazalo, da je to razvoj in operacije. In potem je prišlo do splošnega navdušenja nad mikrostoritvami. In z njimi se je razvoj iz lokalnih strojev začel premikati v oblak - poskusite nekaj odpraviti lokalno, če obstaja na desetine in stotine mikroservisov, potem stalna dostava postane sredstvo za preživetje. Za »majhno skromno podjetje« je bilo vse v redu, a vseeno? Kaj pa Google?
Google SRE
Google je prišel, pojedel največje kaktuse in se odločil - tega ne potrebujemo, potrebujemo zanesljivost. In zanesljivost je treba upravljati. In odločil sem se, da potrebujemo strokovnjake, ki bodo upravljali zanesljivost. Poklical sem jih inženirji SR in rekel, to je to za vas, delajte dobro kot običajno. Tukaj je SLI, tukaj je SLO, tukaj je monitoring. In pomolil nos v operacije. In svoj "zanesljivi DevOps" je imenoval SRE. Zdi se, da je vse v redu, vendar obstaja en umazan vdor, ki bi si ga lahko privoščil Google - za položaj inženirjev SR najeti ljudi, ki so bili usposobljeni razvijalci in so tudi naredili malo domače naloge in razumeli delovanje delujočih sistemov. Še več, Google sam ima težave z zaposlovanjem takšnih ljudi - predvsem zato, ker tukaj tekmuje sam s seboj - nekomu je treba opisati poslovno logiko. Dostava je bila dodeljena inženirjem za izdajo, SR - inženirji upravljajo zanesljivost (seveda ne neposredno, ampak z vplivanjem na infrastrukturo, spreminjanjem arhitekture, sledenjem spremembam in indikatorjem, obravnavo incidentov). Lepo, lahko . Kaj pa, če niste Google, vendar je zanesljivost vseeno nekako zaskrbljujoča?
Razvoj idej DevOps
Ravno takrat je prišel Docker, ki je zrasel iz lxc, nato pa so izdihnili različni sistemi orkestracije, kot sta Docker Swarm in Kubernetes, in inženirji DevOps - poenotenje praks je poenostavilo dostavo. Poenostavil ga je do te mere, da je postalo mogoče celo oddati dostavo razvijalcem – kar je deployment.yaml. Težavo rešuje kontejnerizacija. In zrelost CI/CD sistemov je že na nivoju, da napišemo eno datoteko in gremo - razvijalci se znajdejo sami. In potem se začnemo pogovarjati o tem, kako lahko naredimo svoj SRE, z ... ali vsaj z nekom.
SRE ni na Googlu
No, ok, dostavo smo oddali, zdi se, da si lahko oddahnemo, se vrnemo v dobre stare čase, ko so skrbniki opazovali obremenitev procesorja, nastavljali sisteme in v miru in tišini iz vrčkov tiho srkali nekaj nerazumljivega... Stop. Vsega nismo začeli zaradi tega (kar je škoda!). Nenadoma se izkaže, da lahko v Googlovem pristopu zlahka prevzamemo odlične prakse - ni pomembna obremenitev procesorja in ne to, kako pogosto tam menjamo diske ali optimiziramo stroške v oblaku, ampak so poslovne metrike enake razvpite SLx. In nihče jim ni odstranil upravljanja infrastrukture in morajo reševati incidente, občasno dežurati in na splošno biti na tekočem s poslovnimi procesi. In fantje, začnite malo po malo programirati na dobri ravni, Google vas že čaka.
Povzeti. Nenadoma, vendar ste že utrujeni od branja in komaj čakate, da pljunete in pišete avtorju v komentarju na članek. DevOps kot praksa dostave je vedno bila in bo. In ne gre nikamor. SRE kot nabor operativnih praks omogoča uspešnost te zelo dobre izvedbe.
Vir: www.habr.com