Webinarul are un sunet slab, așa că l-am transcris.
Numele meu este Medvedev Eduard. Astăzi voi vorbi despre ce este SRE, cum a apărut SRE, ce criterii de lucru au inginerii SRE, puțin despre criteriile de fiabilitate, puțin despre monitorizarea acestuia. Vom merge pe vârfuri, pentru că nu puteți spune multe într-o oră, dar voi oferi materiale pentru revizuire suplimentară și vă așteptăm cu toții pe . la Moscova la sfârşitul lunii ianuarie.
În primul rând, să vorbim despre ce este SRE - Site Reliability Engineering. Și cum a apărut ca o poziție separată, ca o direcție separată. Totul a început cu faptul că în cercurile tradiționale de dezvoltare, Dev și Ops sunt două echipe complet diferite, de obicei cu două obiective complet diferite. Scopul echipei de dezvoltare este să lanseze noi funcții și să răspundă nevoilor afacerii. Scopul echipei de operațiuni este să se asigure că totul funcționează și nimic nu se sparge. Evident, aceste obiective se contrazic direct: pentru ca totul să funcționeze și să nu se spargă nimic, lansați noi funcții cât mai puțin posibil. Din această cauză, există multe conflicte interne pe care metodologia care se numește acum DevOps încearcă să le rezolve.
Problema este că nu avem o definiție clară a DevOps și o implementare clară a DevOps. Am vorbit la o conferință la Ekaterinburg în urmă cu 2 ani, iar până acum secțiunea DevOps a început cu raportul „Ce este DevOps”. În 2017, Devops are aproape 10 ani, dar încă ne certăm despre ce este vorba. Și aceasta este o situație foarte ciudată pe care Google a încercat să o rezolve acum câțiva ani.
În 2016, Google a lansat o carte numită Site Reliability Engineering. Și de fapt, cu această carte a început mișcarea SRE. SRE este o implementare specifică a paradigmei DevOps într-o anumită companie. Inginerii SRE se angajează să se asigure că sistemele funcționează în mod fiabil. Ei provin în mare parte de la dezvoltatori, uneori de la administratori cu un fundal puternic de dezvoltare. Și fac ceea ce făceau administratorii de sistem, dar un fundal puternic în dezvoltarea și cunoașterea sistemului în ceea ce privește codul duce la faptul că acești oameni nu sunt înclinați spre activități administrative de rutină, ci sunt înclinați spre automatizare.
Se dovedește că paradigma DevOps în echipele SRE este implementată de faptul că există ingineri SRE care rezolvă probleme structurale. Iată, aceeași legătură între Dev și Ops despre care oamenii vorbesc de 8 ani. Rolul unui SRE este similar cu cel al unui arhitect, prin aceea că noii veniți nu devin SRE. Oamenii de la începutul carierei nu au încă nicio experiență, nu au cunoștințele necesare. Pentru că SRE necesită o cunoaștere foarte subtilă a exact ce și când exact poate merge prost. Prin urmare, aici este nevoie de ceva experiență, de regulă, atât în interiorul companiei, cât și în exterior.
Ei întreabă dacă diferența dintre SRE și devops va fi descrisă. Ea tocmai a fost descrisă. Putem vorbi despre locul SRE în organizație. Spre deosebire de această abordare clasică DevOps, în care Ops este încă un departament separat, SRE face parte din echipa de dezvoltare. Sunt implicați în dezvoltarea produsului. Există chiar și o abordare în care SRE este un rol care trece de la un dezvoltator la altul. Ei participă la recenzii de cod în același mod ca, de exemplu, designerii UX, dezvoltatorii înșiși, uneori managerii de produs. SRE-urile funcționează la același nivel. Trebuie să le aprobăm, trebuie să le revizuim, astfel încât pentru fiecare implementare SRE să spună: „Bine, această implementare, acest produs nu va afecta negativ fiabilitatea. Și dacă o face, atunci în anumite limite acceptabile. Vom vorbi și despre asta.
În consecință, SRE are drept de veto pentru a schimba codul. Și, în general, acest lucru duce și la un fel de mic conflict dacă SRE este implementat incorect. În aceeași carte despre Site Reliability Engineering, multe părți, nici măcar una, spun cum să evitați aceste conflicte.
Ei întreabă cum se raportează SRE la securitatea informațiilor. SRE nu este direct implicat în securitatea informațiilor. Practic, în companiile mari, acest lucru este făcut de persoane fizice, testeri, analiști. Dar SRE interacționează și cu aceștia în sensul că unele operațiuni, unele commit-uri, unele implementări care afectează securitatea pot afecta și disponibilitatea produsului. Prin urmare, SRE în ansamblu are interacțiune cu orice echipă, inclusiv cu echipele de securitate, inclusiv cu analiștii. Prin urmare, SRE-urile sunt necesare în principal atunci când încearcă să implementeze DevOps, dar, în același timp, povara pentru dezvoltatori devine prea mare. Adică, echipa de dezvoltare în sine nu mai poate face față faptului că acum trebuie să fie și ei responsabili pentru Ops. Și există un rol separat. Acest rol este planificat în buget. Uneori, acest rol este stabilit în dimensiunea echipei, apare o persoană separată, uneori devine unul dintre dezvoltatori. Așa apare primul SRE din echipă.
Complexitatea sistemului care este afectat de SRE, complexitatea care afectează fiabilitatea operațiunii, este necesară și accidentală. Complexitatea necesară este atunci când complexitatea unui produs crește în măsura cerută de noile caracteristici ale produsului. Complexitatea aleatorie este atunci când complexitatea sistemului crește, dar caracteristicile produsului și cerințele de afaceri nu afectează în mod direct acest lucru. Se dovedește că fie dezvoltatorul a greșit undeva, fie algoritmul nu este optim, fie sunt introduse niște interese suplimentare care cresc complexitatea produsului fără nevoie specială. Un SRE bun ar trebui să oprească întotdeauna această situație. Adică, orice comitere, orice desfășurare, orice cerere de extragere, în care dificultatea este crescută din cauza adăugării aleatorii, ar trebui blocate.
Întrebarea este de ce să nu angajezi un inginer, un administrator de sistem cu multe cunoștințe în echipă. Un dezvoltator în rolul unui inginer, ni se spune, nu este cea mai bună soluție de personal. Un dezvoltator în rolul unui inginer nu este întotdeauna cea mai bună soluție de angajare, dar ideea aici este că un dezvoltator care este angajat în operațiuni are puțin mai multă dorință de automatizare, are puțin mai multe cunoștințe și un set de abilități pentru a implementa această automatizare. Și, în consecință, reducem nu doar timpul pentru anumite operațiuni specifice, nu doar rutina, ci și parametri de afaceri atât de importanți precum MTTR (Mean Time To Recovery, timp de recuperare). Astfel, și despre asta vom vorbi puțin mai târziu, economisim bani pentru organizație.
Acum să vorbim despre criteriile de funcționare a SRE. Și în primul rând despre fiabilitate. În companiile mici, startup-uri, se întâmplă adesea ca oamenii să presupună că, dacă serviciul este scris bine, dacă produsul este scris bine și corect, va funcționa, nu se va rupe. Gata, scriem cod bun, deci nu este nimic de spart. Codul este foarte simplu, nu există nimic de spart. Sunt cam aceiași oameni care spun că nu avem nevoie de teste, pentru că, uite, acestea sunt cele trei metode VPI, de ce să spargem aici.
Toate acestea sunt greșite, desigur. Și acești oameni sunt foarte des mușcați de un astfel de cod în practică, pentru că lucrurile se rup. Lucrurile se sparg uneori în cele mai imprevizibile moduri. Uneori oamenii spun că nu, nu se va întâmpla niciodată. Și se întâmplă tot timpul. Se întâmplă destul de des. Și de aceea nimeni nu se străduiește niciodată pentru disponibilitate 100%, pentru că disponibilitatea 100% nu se întâmplă niciodată. Aceasta este norma. Și, prin urmare, când vorbim despre disponibilitatea unui serviciu, vorbim întotdeauna despre nouă. 2 nouă, 3 nouă, 4 nouă, 5 nouă. Dacă traducem acest lucru în timp de nefuncționare, atunci, de exemplu, 5 nouă, atunci acesta este puțin mai mult de 5 minute de oprire pe an, 2 nouă este de 3,5 zile de nefuncționare.
Dar este evident că la un moment dat are loc o scădere a POI, rentabilitatea investiției. Trecerea de la doi nouă la trei nouă înseamnă mai puțin timp de nefuncționare cu mai mult de 3 zile. Trecerea de la patru nouă la cinci reduce timpul de nefuncționare cu 47 de minute pe an. Și se dovedește că pentru afaceri poate să nu fie critic. Și, în general, fiabilitatea necesară nu este o problemă tehnică, în primul rând, este o problemă de afaceri, este o problemă de produs. Ce nivel de oprire este acceptabil pentru utilizatorii produsului, la ce se așteaptă, cât plătesc, de exemplu, câți bani pierd, câți bani pierde sistemul.
O întrebare importantă aici este care este fiabilitatea componentelor rămase. Pentru că diferența dintre 4 și 5 nouă nu va fi vizibilă pe un smartphone cu 2 nouă de fiabilitate. Aproximativ vorbind, dacă ceva se defectează pe un smartphone din serviciul dvs. de 10 ori pe an, cel mai probabil de 8 ori defecțiunea a avut loc pe partea sistemului de operare. Utilizatorul este obișnuit cu acest lucru și nu va mai acorda atenție o dată pe an. Este necesar să se coreleze prețul creșterii fiabilității și creșterii profiturilor.
Doar în cartea despre SRE există un exemplu bun de creștere la 4 nouă de la 3 nouă. Rezultă că creșterea disponibilității este puțin mai mică de 0,1%. Și dacă venitul serviciului este de 1 milion de dolari pe an, atunci creșterea veniturilor este de 900 de dolari. Dacă ne costă mai puțin de 900 de dolari pe an să creștem accesibilitatea cu nouă, creșterea are sens financiar. Dacă costă peste 900 de dolari pe an, nu mai are sens, deoarece creșterea veniturilor pur și simplu nu compensează costurile cu forța de muncă, costurile cu resursele. Și 3 nouă ne vor fi de ajuns.
Acesta este, desigur, un exemplu simplificat în care toate cererile sunt egale. Și trecerea de la 3 nouă la 4 nouă este destul de ușor, dar în același timp, de exemplu, trecerea de la 2 nouă la 3, aceasta este deja o economie de 9 mii de dolari, poate avea sens financiar. Desigur, în realitate, eșecul cererii de înregistrare este mai grav decât neafișarea paginii, solicitările au ponderi diferite. Ele pot avea un criteriu complet diferit din punct de vedere al afacerii, dar oricum, de regulă, dacă nu vorbim despre unele servicii specifice, aceasta este o aproximare destul de sigură.
Am primit o întrebare dacă SRE este unul dintre coordonatorii la alegerea unei soluții arhitecturale pentru serviciu. Să zicem din punct de vedere al integrării în infrastructura existentă, astfel încât să nu existe pierderi în stabilitatea acesteia. Da, SRE-urile, în același mod în care solicitările pull, commit-urile, lansările afectează arhitectura, introducerea de noi servicii, microservicii, implementarea de noi soluții. De ce am spus înainte că este nevoie de experiență, de calificări. De fapt, SRE este una dintre vocile blocante din orice soluție arhitecturală și software. În consecință, un SRE ca inginer trebuie, în primul rând, nu numai să înțeleagă, ci și să înțeleagă modul în care anumite decizii specifice vor afecta fiabilitatea, stabilitatea și să înțeleagă modul în care acestea se raportează la nevoile afacerii și din ce punct de vedere poate fi acceptabil și acceptabil. care nu.
Prin urmare, acum putem vorbi doar despre criteriile de fiabilitate, care sunt definite în mod tradițional în SRE ca SLA (Service Level Agreement). Cel mai probabil un termen familiar. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement este poate un termen simbolic, mai ales dacă ați lucrat cu rețele, cu furnizori, cu hosting. Acesta este un acord general care descrie performanța întregului serviciu, penalități, unele penalități pentru erori, valori, criterii. Și SLI este măsura de disponibilitate în sine. Adică ce poate fi SLI: timpul de răspuns de la serviciu, numărul de erori ca procent. Ar putea fi lățimea de bandă dacă este un fel de găzduire de fișiere. Când vine vorba de algoritmi de recunoaștere, indicatorul poate fi, de exemplu, chiar corectitudinea răspunsului. SLO (Service Level Objective) este, respectiv, o combinație a indicatorului SLI, valoarea și perioada acestuia.
Să presupunem că SLA ar putea fi așa. Serviciul este disponibil 99,95% din timp pe tot parcursul anului. Sau 99 de bilete de asistență critică vor fi închise în 3 ore pe trimestru. Sau 85% dintre interogări vor primi răspunsuri în 1,5 secunde în fiecare lună. Adică ajungem treptat să înțelegem că erorile și eșecurile sunt destul de normale. Aceasta este o situație acceptabilă, o plănuim, chiar mizăm pe ea într-o oarecare măsură. Adică SRE construiește sisteme care pot greși, care trebuie să răspundă normal erorilor, care trebuie să țină cont de ele. Și ori de câte ori este posibil, ar trebui să gestioneze erorile în așa fel încât utilizatorul fie să nu le observe, fie să le observe, dar există un fel de soluție, datorită căreia totul nu va cădea complet.
De exemplu, dacă încărcați un videoclip pe YouTube și YouTube nu îl poate converti imediat, dacă videoclipul este prea mare, dacă formatul nu este optim, atunci cererea nu va eșua în mod natural cu un timeout, YouTube nu va da o eroare 502 , YouTube va spune: „Am creat totul, videoclipul tău este în curs de procesare. Va fi gata în aproximativ 10 minute.” Acesta este principiul degradării grațioase, care este familiar, de exemplu, din dezvoltarea front-end, dacă ați făcut vreodată acest lucru.
Următorii termeni despre care vom vorbi, foarte importanți pentru lucrul cu fiabilitate, cu erori, cu așteptări, sunt MTBF și MTTR. MTBF este timpul mediu dintre eșecuri. MTTR Mean Time To Recovery, timpul mediu până la recuperare. Adică cât timp a trecut din momentul în care eroarea a fost descoperită, din momentul în care a apărut eroarea până în momentul în care serviciul a fost restabilit la funcționarea normală completă. MTBF este fixat în principal prin munca la calitatea codului. Adică faptul că SRE-urile pot spune „nu”. Și ai nevoie de o înțelegere a întregii echipe că atunci când SRE spune „nu”, o spune nu pentru că ar fi dăunător, nu pentru că ar fi rău, ci pentru că altfel toți vor suferi.
Din nou, există o mulțime de articole, o mulțime de metode, o mulțime de moduri chiar și în cartea la care mă refer atât de des, cum să mă asigur că alți dezvoltatori nu încep să urască SRE. MTTR, pe de altă parte, se referă la lucrul la SLO-urile tale (Service Level Objective). Și este mai ales automatizare. Pentru că, de exemplu, SLO-ul nostru este un timp de funcționare de 4 nouă pe trimestru. Aceasta înseamnă că în 3 luni putem permite 13 minute de oprire. Și se dovedește că MTTR nu poate fi mai mare de 13 minute. Dacă răspundem la cel puțin 13 oprire în 1 minute, asta înseamnă că am epuizat deja întregul buget pentru trimestrul. Încălcăm SLO. 13 minute pentru a reacționa și a repara un accident este mult pentru o mașină, dar foarte scurt pentru un om. Pentru că până când o persoană primește o alertă, până reacționează, până când înțelege eroarea, sunt deja câteva minute. Până când o persoană înțelege cum să o repare, ce anume să repare, ce să facă, atunci mai sunt câteva minute. Și, de fapt, chiar dacă trebuie doar să reporniți serverul, după cum se dovedește, sau să ridicați un nou nod, atunci manual MTTR este deja de aproximativ 7-8 minute. La automatizarea procesului, MTTR ajunge foarte des la o secundă, uneori milisecunde. Google vorbește de obicei despre milisecunde, dar în realitate, desigur, totul nu este atât de bine.
În mod ideal, SRE ar trebui să-și automatizeze activitatea aproape complet, deoarece acest lucru afectează direct MTTR-ul, valorile sale, SLO-ul întregului serviciu și, în consecință, profitul afacerii. Dacă timpul este depășit, suntem întrebați dacă SRE este de vină. Din fericire, nimeni nu este de vină. Și aceasta este o cultură separată numită postmortem fără balsam, despre care nu vom vorbi astăzi, dar o vom analiza pe Slurm. Acesta este un subiect foarte interesant despre care se poate vorbi mult. Aproximativ, dacă se depășește timpul alocat pe trimestru, atunci puțin din toată lumea este de vină, ceea ce înseamnă că a da vina pe toată lumea nu este productiv, să dăm în schimb, poate, să nu dăm vina pe nimeni, ci corectăm situația și lucrăm cu ceea ce avem. Din experiența mea, această abordare este puțin străină pentru majoritatea echipelor, mai ales în Rusia, dar are sens și funcționează foarte bine. Prin urmare, vă voi recomanda la sfârșitul articolului și literaturii pe care le puteți citi pe această temă. Sau vino la Slurm SRE.
Lasă-mă să explic. Dacă se depășește timpul SLO pe trimestru, dacă timpul de nefuncționare nu a fost de 13 minute, ci de 15, cine poate fi de vină pentru asta? Desigur, SRE poate fi de vină, pentru că în mod clar a făcut un fel de comitere proastă sau desfășurare. Administratorul centrului de date s-ar putea să fie de vină pentru acest lucru, deoarece s-ar putea să fi efectuat un fel de întreținere neprogramată. Dacă administratorul centrului de date este de vină pentru asta, atunci de vină este cel de la Ops, care nu a calculat întreținerea atunci când a coordonat SLO. Managerul, directorul tehnic sau cineva care a semnat contractul centrului de date și nu a acordat atenție faptului că SLA-ul centrului de date nu este conceput pentru timpul de nefuncționare necesar este de vină pentru asta. În consecință, toți încetul cu încetul în această situație sunt de vină. Și înseamnă că nu are rost să dai vina pe cineva în această situație. Dar, desigur, trebuie corectat. De aceea există autopsie. Și dacă citiți, de exemplu, autopsie GitHub, iar aceasta este întotdeauna o poveste foarte interesantă, mică și neașteptată în fiecare caz specific, puteți înlocui că nimeni nu spune vreodată că această persoană anume ar fi de vină. Vina este întotdeauna pusă pe anumite procese imperfecte.
Să trecem la următoarea întrebare. Automatizare. Când vorbesc despre automatizare în alte contexte, mă refer adesea la un tabel care vă spune cât timp puteți lucra la automatizarea unei sarcini fără să vă luați mai mult timp pentru ao automatiza decât salvați de fapt. Există o problemă. Problema este că atunci când SRE automatizează o sarcină, nu numai că economisesc timp, ci și bani, deoarece automatizarea afectează direct MTTR. Ele salvează, ca să spunem așa, moralul angajaților și dezvoltatorilor, care este și o resursă epuizabilă. Ele reduc rutina. Și toate acestea au un efect pozitiv asupra muncii și, drept urmare, asupra afacerii, chiar dacă se pare că automatizarea nu are sens în ceea ce privește costurile de timp.
De fapt, aproape întotdeauna a făcut-o și sunt foarte puține cazuri în care ceva nu ar trebui automatizat în rolul SRE. În continuare vom vorbi despre ceea ce se numește bugetul de erori, bugetul pentru erori. De fapt, se dovedește că, dacă totul este mult mai bun pentru tine decât SLO-ul pe care ți l-ai stabilit, nici acesta nu este foarte bun. Acest lucru este destul de rău, deoarece SLO funcționează nu numai ca limită inferioară, ci și ca limită superioară aproximativă. Când îți stabilești un SLO de disponibilitate de 99% și, de fapt, ai 99,99%, se dovedește că ai ceva spațiu pentru experimente care nu vor dăuna deloc afacerii, pentru că tu însuți ai determinat acest lucru împreună și ești acest spațiu nu folosiți. Ai un buget pentru greseli, care in cazul tau nu se consuma.
Ce facem cu el. Îl folosim literalmente pentru orice. Pentru testare în condiții de producție, pentru lansarea de noi funcții care pot afecta performanța, pentru lansări, pentru întreținere, pentru perioadele de nefuncționare planificate. Se aplică și regula inversă: dacă bugetul este epuizat, nu putem elibera nimic nou, pentru că altfel vom depăși SLO. Bugetul a fost deja epuizat, am lansat ceva dacă afectează negativ performanța, adică dacă acesta nu este un fel de remediere care în sine crește direct SLO, atunci trecem dincolo de buget și aceasta este o situație proastă. , trebuie analizat, post-mortem și, eventual, unele remedieri ale procesului.
Adică, se dovedește că, dacă serviciul în sine nu funcționează bine, iar SLO este cheltuit și bugetul este cheltuit nu pentru experimente, nu pentru unele versiuni, ci de la sine, atunci în loc de unele remedieri interesante, în loc de caracteristici interesante, în loc de lansări interesante. În loc de orice muncă creativă, va trebui să te confrunți cu remedieri stupide pentru a readuce bugetul în ordine, sau edita SLO, iar acesta este, de asemenea, un proces care nu ar trebui să se întâmple prea des.
Prin urmare, se dovedește că într-o situație în care avem mai mult buget pentru erori, toată lumea este interesată: atât SRE, cât și dezvoltatori. Pentru dezvoltatori, un buget mare pentru bug-uri înseamnă că vă puteți ocupa de lansări, teste, experimente. Pentru SRE, un buget pentru erori și introducerea acelui buget înseamnă că își fac direct treaba bine. Și acest lucru afectează motivația unui fel de muncă comună. Dacă vă ascultați SRE-urile ca dezvoltatori, veți avea mai mult spațiu pentru munca bună și mult mai puțină rutină.
Se pare că experimentele în producție sunt o parte destul de importantă și aproape integrantă a SRE în echipele mari. Și de obicei se numește inginerie haos, care vine de la echipa de la Netflix care a lansat un utilitar numit Chaos Monkey.
Chaos Monkey se conectează la conducta CI/CD și blochează aleatoriu serverul în producție. Din nou, în structura SRE, vorbim despre faptul că un server doborât nu este rău în sine, este de așteptat. Și dacă este în buget, este acceptabil și nu dăunează afacerii. Desigur, Netflix are destule servere redundante, suficientă replicare, pentru ca toate acestea să poată fi reparate, și pentru ca utilizatorul în ansamblu să nu observe nici măcar, și cu atât mai mult, nimeni nu lasă un server pentru orice buget.
Netflix a avut o suită întreagă de astfel de utilități pentru o perioadă, dintre care una, Chaos Gorilla, închide complet una dintre zonele de disponibilitate ale Amazon. Și astfel de lucruri ajută la dezvăluirea, în primul rând, a dependențelor ascunse, atunci când nu este complet clar ce afectează ce, ce depinde de ce. Și asta, dacă lucrați cu un microserviciu, iar documentația nu este perfectă, acest lucru vă poate fi familiar. Și, din nou, acest lucru ajută foarte mult la prinderea erorilor din cod pe care nu le puteți prinde la punere în scenă, deoarece orice punere în scenă nu este tocmai o simulare exactă, datorită faptului că scara de încărcare este diferită, modelul de încărcare este diferit, echipamentul este diferit. de asemenea, cel mai probabil, altele. Sarcinile de vârf pot fi, de asemenea, neașteptate și imprevizibile. Iar astfel de testare, care din nou nu depășește bugetul, ajută foarte bine la surprinderea erorilor din infrastructură pe care nu le vor prinde niciodată staging, autotests, CI/CD pipeline. Și atâta timp cât totul este inclus în bugetul tău, nu contează că serviciul tău a scăzut acolo, deși s-ar părea foarte înfricoșător, serverul a căzut, ce coșmar. Nu, asta e normal, asta e bine, asta ajută la prinderea insectelor. Dacă ai un buget, îl poți cheltui.
Î: Ce literatură pot recomanda? Lista la final. Există multă literatură, voi sfătui câteva rapoarte. Cum funcționează și SRE funcționează în companii fără propriul produs software sau cu dezvoltare minimă. De exemplu, într-o întreprindere în care activitatea principală nu este software-ul. Într-o întreprindere, în care activitatea principală nu este software-ul, SRE funcționează exact la fel ca peste tot, deoarece într-o întreprindere trebuie să utilizați și produse software, chiar dacă nu sunt dezvoltate, trebuie să lansați actualizări, trebuie să schimbați infrastructura, trebuie să crești, trebuie să te extinzi. Și SRE ajută la identificarea și prezicerea posibilelor probleme în aceste procese și le controlează după ce începe o anumită creștere și nevoile afacerii se schimbă. Pentru că nu este absolut necesar să fii implicat în dezvoltarea de software pentru a avea un SRE dacă ai măcar câteva servere și se așteaptă să ai măcar o oarecare creștere.
Același lucru este valabil și pentru proiectele mici, organizațiile mici, pentru că marile companii au buget și spațiu pentru a experimenta. Dar, în același timp, toate aceste fructe ale experimentelor pot fi folosite oriunde, adică SRE, desigur, a apărut în Google, în Netflix, în Dropbox. Dar, în același timp, companiile mici și startup-urile pot deja să citească material condensat, să citească cărți, să urmărească rapoarte. Încep să audă despre asta mai des, se uită la exemple concrete, cred că e în regulă, poate fi cu adevărat util, avem nevoie și de asta, este grozav.
Adică, toată munca principală privind standardizarea acestor procese a fost deja făcută pentru dvs. Rămâne să stabiliți rolul SRE în mod specific în compania dumneavoastră și să începeți să implementați efectiv toate aceste practici, care, din nou, au fost deja descrise. Adică, din principii utile pentru companiile mici, aceasta este întotdeauna definiția SLA, SLI, SLO. Dacă nu sunteți implicat în software, atunci acestea vor fi SLA-uri interne și SLO-uri interne, un buget intern pentru erori. Acest lucru duce aproape întotdeauna la niște discuții interesante în cadrul echipei și în cadrul afacerii, deoarece se poate dovedi că cheltuiți pe infrastructură, pe un fel de organizare a proceselor ideale, pipeline-ul ideal este mult mai mult decât necesar. Și aceste 4 nouă pe care le ai în departamentul IT, nu prea ai nevoie de ele acum. Dar, în același timp, ai putea petrece timp, cheltui bugetul pentru greșeli pe altceva.
În consecință, monitorizarea și organizarea monitorizării sunt utile pentru o companie de orice dimensiune. Și în general, acest mod de a gândi, unde greșelile sunt ceva acceptabil, unde există buget, unde sunt Obiective, este din nou util unei companii de orice dimensiune, începând de la startup-uri de 3 persoane.
Ultima dintre nuanțele tehnice despre care să vorbim este monitorizarea. Pentru că dacă vorbim de SLA, SLI, SLO, nu putem înțelege fără a monitoriza dacă ne încadram în buget, dacă ne respectăm Obiectivele și cum influențăm SLA-ul final. Am văzut de atâtea ori că monitorizarea se întâmplă astfel: există o anumită valoare, de exemplu, timpul unei solicitări către server, timpul mediu sau numărul de solicitări către baza de date. Are un standard stabilit de un inginer. Dacă metrica se abate de la normă, atunci sosește un e-mail. Toate acestea sunt absolut inutile, de regulă, pentru că duce la o astfel de exces de alerte, de mesaje de monitorizare, atunci când o persoană, în primul rând, trebuie să le interpreteze de fiecare dată, adică să determine dacă valoarea metricului înseamnă nevoia unei acțiuni. Și în al doilea rând, pur și simplu nu mai observă toate aceste alerte, când practic nu este necesară nicio acțiune din partea lui. Aceasta este o regulă bună de monitorizare și prima regulă atunci când SRE este implementată este că notificarea ar trebui să vină numai atunci când este necesară acțiunea.
În cazul standard, există 3 niveluri de evenimente. Sunt alerte, sunt bilete, sunt jurnalele. Alertele sunt orice lucru care vă cere să luați măsuri imediate. Adică totul este stricat, trebuie să-l repari chiar acum. Biletele sunt cele care necesită o acțiune întârziată. Da, trebuie să faci ceva, trebuie să faci ceva manual, automatizarea a eșuat, dar nu trebuie să o faci în următoarele câteva minute. Jurnalele sunt orice lucru care nu necesită acțiune și, în general, dacă lucrurile merg bine, nimeni nu le va citi vreodată. Va trebui să citiți jurnalele doar când, retrospectiv, s-a dovedit că ceva s-a stricat de ceva timp, nu știam despre asta. Sau trebuie să faci niște cercetări. Dar, în general, tot ceea ce nu necesită nicio acțiune merge la jurnalele.
Ca efect secundar al tuturor acestor lucruri, dacă am definit ce evenimente necesită acțiuni și am descris bine care ar trebui să fie aceste acțiuni, aceasta înseamnă că acțiunea poate fi automatizată. Adică ce se întâmplă. Trecem din alertă. Să trecem la acțiune. Trecem la descrierea acestei acțiuni. Și apoi trecem la automatizare. Adică, orice automatizare începe cu o reacție la un eveniment.
De la monitorizare, trecem la un termen numit Observabilitate. De asemenea, a existat un pic de hype în jurul acestui cuvânt în ultimii ani. Și puțini oameni înțeleg ce înseamnă în afara contextului. Dar punctul principal este că observabilitatea este o măsură pentru transparența sistemului. Dacă ceva a mers prost, cât de repede puteți determina ce anume a mers prost și care era starea sistemului în acel moment. În ceea ce privește codul: ce funcție a eșuat, ce serviciu a eșuat. Care a fost starea, de exemplu, a variabilelor interne, a configurației. În ceea ce privește infrastructura, aceasta este în ce zonă de disponibilitate a avut loc eșecul și, dacă aveți vreun Kubernetes, atunci în ce pod a avut loc eșecul, care a fost starea podului. Și, în consecință, Observability are o relație directă cu MTTR. Cu cât este mai mare Observabilitatea serviciului, cu atât este mai ușor să identificați eroarea, cu atât mai ușor este să remediați eroarea, cu atât mai ușor este să automatizați eroarea, cu atât MTTR-ul este mai mic.
Trecând din nou la companiile mici, este foarte obișnuit să ne întrebăm, chiar și acum, cum să facem față dimensiunii echipei și dacă o echipă mică trebuie să angajeze un SRE separat. Am vorbit deja despre asta puțin mai devreme. La primele etape de dezvoltare a unui startup sau, de exemplu, a unei echipe, acest lucru nu este deloc necesar, deoarece SRE poate fi făcut un rol tranzitoriu. Și asta va învia puțin echipa, pentru că există măcar o oarecare diversitate. Și în plus îi va pregăti pe oameni pentru faptul că odată cu creșterea, în general, responsabilitățile SRE se vor schimba foarte semnificativ. Dacă angajezi o persoană, atunci, desigur, are câteva așteptări. Și aceste așteptări nu se vor schimba în timp, dar cerințele se vor schimba foarte mult. Prin urmare, cum să angajezi un SRE este destul de dificil în primele etape. Creșterea proprie este mult mai ușor. Dar merită să ne gândim.
Singura excepție, poate, este atunci când există cerințe de creștere foarte stricte și bine definite. Adică, în cazul unui startup, aceasta poate fi un fel de presiune din partea investitorilor, un fel de prognoză de creștere de mai multe ori simultan. Atunci angajarea unui SRE este în principiu justificată pentru că poate fi justificată. Avem cerințe de creștere, avem nevoie de o persoană care să fie responsabilă pentru faptul că cu o astfel de creștere nimic nu se va sparge.
Inca o intrebare. Ce trebuie să faceți când dezvoltatorii tăi de mai multe ori o caracteristică care trece testele, dar întrerupe producția, încarcă baza, rupe alte caracteristici, ce proces să implementeze. În consecință, în acest caz, bugetul pentru erori este cel care se introduce. Și unele dintre servicii, unele dintre caracteristici sunt deja testate în producție. Poate fi canar, atunci când doar un număr mic de utilizatori, dar deja în producție, o caracteristică este implementată, dar deja cu așteptarea că, dacă ceva se rupe, de exemplu, pentru jumătate la sută din toți utilizatorii, va îndeplini în continuare buget pentru erori. În consecință, da, va exista o eroare, pentru unii utilizatori totul se va rupe, dar am spus deja că acest lucru este normal.
A fost o întrebare despre instrumentele SRE. Adică, există ceva în special pe care SRE-urile l-ar folosi pe care toți ceilalți nu l-ar folosi. De fapt, există niște utilități foarte specializate, există un fel de software care, de exemplu, simulează încărcături sau este angajat în testarea A/B canar. Dar, practic, setul de instrumente SRE este ceea ce dezvoltatorii dvs. folosesc deja. Pentru că SRE interacționează direct cu echipa de dezvoltare. Și dacă aveți instrumente diferite, se va dovedi că este nevoie de timp pentru a sincroniza. Mai ales dacă SRE-urile lucrează în echipe mari, în companii mari unde pot fi mai multe echipe, este standardizarea la nivel de companie care va ajuta foarte mult aici, pentru că dacă se folosesc 50 de utilități diferite în 50 de echipe, asta înseamnă că SRE trebuie să le cunoască. toate. Și, desigur, acest lucru nu se va întâmpla niciodată. Iar calitatea muncii, calitatea controlului măcar a unora dintre echipe va scădea semnificativ.
Webinarul nostru se apropie de final. Am reușit să spun câteva lucruri de bază. Desigur, nimic despre SRE nu poate fi spus și înțeles într-o oră. Dar sper că am reușit să transmit acest mod de a gândi, principalele puncte cheie. Și atunci va fi posibil, dacă ești interesat, să aprofundezi subiectul, să înveți pe cont propriu, să privești cum este implementat de alți oameni, în alte companii. Și în consecință, la începutul lunii februarie, vino la noi la Slurm SRE.
Slurm SRE este un curs intensiv de trei zile care va vorbi despre ceea ce vorbesc acum, dar cu mult mai multă profunzime, cu cazuri reale, cu practică, întregul intensiv vizează munca practică. Oamenii vor fi împărțiți în echipe. Cu toții veți lucra la cazuri reale. În consecință, avem instructorii Booking.com Ivan Kruglov și Ben Tyler. Avem un Eugene Barabbas minunat de la Google, din San Francisco. Și îți voi spune ceva. Așa că asigurați-vă că ne vizitați.
Deci, bibliografia. Există referințe despre SRE. pe aceeași carte, sau mai degrabă pe 2 cărți despre SRE, scrise de Google. Încă unul , unde termenii și aplicarea lor sunt puțin mai detaliate. Următoarele 3 sunt rapoarte despre SRE în diferite companii. În primul rând - , aceasta este o intervenție principală de la Ben Trainer de la Google. Al doilea - . Al treilea este din nou . Al patrulea raport de la , care are doar 5 angajați cheie SRE în 190 de țări. Este foarte interesant să privim toate acestea, pentru că la fel cum DevOps înseamnă lucruri foarte diferite pentru diferite companii și chiar pentru diferite echipe, SRE are responsabilități foarte diferite, chiar și în companii de dimensiuni similare.
Încă 2 link-uri despre principiile ingineriei haosului: , . Iar la final sunt 3 liste din seria Awesome Lists despre , despre și despre . Lista pe SRE este incredibil de uriașă, nu este necesar să parcurgeți totul, sunt aproximativ 200 de articole. Recomand cu căldură articole de acolo despre planificarea capacității și despre postmortem fără vină.
Articol interesant:
Vă mulțumesc că m-ați ascultat în tot acest timp. Sper că ai învățat ceva. Sper că aveți suficient material pentru a afla și mai multe. Si ne mai vedem. Sper că în februarie.
Webinarul a fost găzduit de Eduard Medvedev.
PS: pentru cei cărora le place să citească, Eduard a dat o listă de referințe. Cei care preferă să înțeleagă în practică sunt bineveniți .
Sursa: www.habr.com