Još jednom o DevOps-u i SRE-u

Na temelju chat rasprave Zajednica AWS Minsk

Nedavno su se rasplamsale prave bitke oko definicije DevOps i SRE.
Unatoč tome što su me rasprave o ovoj temi na mnogo načina već zapekle, pa i mene, odlučio sam svoje viđenje ove teme iznijeti pred sud zajednice Habra. Za one koji su zainteresirani, dobrodošli u cat. I neka sve počne iznova!

prapovijest

Dakle, u davna vremena tim programera softvera i administratora poslužitelja živio je odvojeno. Prvi je uspješno napisao kod, drugi je, koristeći razne tople, nježne riječi upućene prvom, postavio poslužitelje, povremeno dolazeći programerima i primajući kao odgovor opsežan "sve radi na mom stroju". Posao je čekao softver, sve je mirovalo, povremeno se kvario, svi su bili nervozni. Pogotovo onaj koji je platio cijelu ovu zbrku. Slavno doba lampi. Pa, već znate odakle dolazi DevOps.

Rođenje DevOps praksi

Onda su došli ozbiljni momci i rekli - ovo nije industrija, ne može se tako raditi. I donijeli su modele životnog ciklusa. Evo, na primjer, V-modela.

Još jednom o DevOps-u i SRE-u
Dakle, što vidimo? Posao dolazi s konceptom, arhitekti dizajniraju rješenja, programeri pišu kod i onda propadne. Netko nekako testira proizvod, netko ga nekako isporučuje krajnjem korisniku, a negdje na izlazu ovog čudesnog modela sjedi usamljeni poslovni kupac i čeka obećano vrijeme uz more. Došli smo do zaključka da su nam potrebne metode koje će nam omogućiti da uspostavimo ovaj proces. I odlučili smo stvoriti prakse koje će ih implementirati.

Lirska digresija na temu što je praksa
Pod praksom mislim na kombinaciju tehnologije i discipline. Primjer je praksa opisivanja infrastrukture pomoću terraform koda. Disciplina je kako kodom opisati infrastrukturu, ona je u glavi programera, a tehnologija je sama terraforma.

I odlučili su ih nazvati DevOps praksama - mislim da su mislili od razvoja do operacija. Smislili smo razne pametne stvari - CI/CD prakse, prakse temeljene na IaC principu, na tisuće njih. I krećemo, programeri pišu kod, DevOps inženjeri transformiraju opis sustava u obliku koda u radne sustave (da, kod je, nažalost, samo opis, ali ne i utjelovljenje sustava), isporuka se nastavlja, i tako dalje. Dojučerašnji administratori, svladavši nove prakse, ponosno su se prekvalificirali u DevOps inženjere, i sve je krenulo od tamo. I bi večer, i bi jutro... oprostite, ne odande.

Opet nije sve dobro, hvala Bogu

Čim se sve smirilo i razni lukavi “metodolozi” počeli pisati debele knjige o DevOps praksi, tiho su se rasplamsale rasprave o tome tko je ozloglašeni DevOps inženjer i da je DevOps proizvodna kultura, ponovno se pojavilo nezadovoljstvo. Odjednom se pokazalo da je isporuka softvera apsolutno netrivijalan zadatak. Svaka razvojna infrastruktura ima svoj stack, negdje je trebate sastaviti, negdje trebate implementirati okruženje, ovdje vam treba Tomcat, ovdje vam treba lukav i kompliciran način za pokretanje - općenito, glava vam puca. A problem se, začudo, pokazao prvenstveno u organizaciji procesa - ova funkcija isporuke, poput uskog grla, počela je blokirati procese. Osim toga, nitko nije otkazao operacije. U V-modelu se ne vidi, ali je i dalje cijeli životni ciklus desno. Kao rezultat toga, potrebno je nekako održavati infrastrukturu, pratiti nadzor, rješavati incidente, a također se baviti isporukom. Oni. sjediti jednom nogom i u razvoju i u radu - i odjednom se pokazalo da je to Razvoj i operacije. A onda je došlo do opće pompe za mikroservisima. A s njima se razvoj s lokalnih strojeva počeo seliti u oblak - pokušajte ispraviti nešto lokalno, ako postoje deseci i stotine mikroservisa, tada stalna isporuka postaje sredstvo preživljavanja. Za “malu skromnu tvrtku” to je bilo u redu, ali ipak? Što je s Googleom?

SRE od Googlea

Došao je Google, pojeo najveće kaktuse i odlučio - ovo nam ne treba, treba nam pouzdanost. A pouzdanošću se mora upravljati. I odlučio sam da trebamo stručnjake koji će upravljati pouzdanošću. Nazvao sam ih SR inženjerima i rekao, to je to za vas, radite to dobro kao i obično. Ovdje je SLI, ovdje je SLO, ovdje je praćenje. I gurao je nos u operacije. I nazvao je svoj "pouzdani DevOps" SRE. Čini se da je sve u redu, ali postoji jedan prljavi hack koji bi si Google mogao priuštiti - za poziciju SR inženjera zaposliti ljude koji su bili kvalificirani programeri, a uz to su napravili malu zadaću i razumjeli funkcioniranje radnih sustava. Štoviše, Google i sam ima problema sa zapošljavanjem takvih ljudi - uglavnom jer se ovdje natječe sam sa sobom - potrebno je nekome opisati poslovnu logiku. Isporuka je dodijeljena inženjerima izdanja, SR - inženjeri upravljaju pouzdanošću (naravno, ne izravno, već utječući na infrastrukturu, mijenjajući arhitekturu, prateći promjene i indikatore, rješavajući incidente). Lijepo, možeš pisati knjige. Ali što ako niste Google, ali je pouzdanost ipak na neki način zabrinutost?

Razvoj DevOps ideja

Upravo tada je stigao Docker, koji je izrastao iz lxc-a, pa razni orkestracijski sustavi poput Docker Swarma i Kubernetesa, a DevOps inženjeri su izdahnuli – unifikacija praksi pojednostavila je isporuku. To ga je pojednostavilo do te mjere da je postalo moguće čak i outsourcati isporuku programerima - što je deployment.yaml. Kontejnerizacija rješava problem. A zrelost CI/CD sustava je već na razini pisanja jedne datoteke i idemo - programeri to mogu sami riješiti. I onda počnemo razgovarati o tome kako možemo napraviti vlastiti SRE, s... ili barem s nekim.

SRE nije na Googleu

Pa dobro, isporučili smo dostavu, čini se da možemo odahnuti, vratiti se u dobra stara vremena, kada su admini gledali kako se procesori opterećuju, štimali sustave i tiho pijuckali nešto neshvatljivo iz šalica u miru i tišini... Stop. Nismo zbog toga sve pokrenuli (što je šteta!). Odjednom se pokazalo da u Googleovom pristupu lako možemo usvojiti izvrsne prakse - nije važno opterećenje procesora, niti koliko često tamo mijenjamo diskove ili optimiziramo troškove u oblaku, već su poslovne metrike iste notorne SLx. I nitko im nije skinuo upravljanje infrastrukturom, a oni trebaju rješavati incidente, i povremeno dežurati, i općenito pratiti poslovne procese. I dečki, počnite malo po malo programirati na dobroj razini, Google vas već čeka.

Sažeti. Odjednom, ali već ste umorni od čitanja i jedva čekate pljunuti i napisati autoru u komentaru na članak. DevOps kao praksa isporuke uvijek je bio i bit će. I ne ide nikamo. SRE kao skup operativnih praksi upravo ovu isporuku čini uspješnom.

Izvor: www.habr.com

Dodajte komentar