SRE (Site Reliability Engineering) este o abordare pentru a face proiectele web accesibile. Este considerat un cadru pentru DevOps și spune cum să reușiți în aplicarea practicilor DevOps. Acest articol se traduce carti de la Google. Am pregătit eu această traducere și m-am bazat pe propria mea experiență în înțelegerea proceselor de monitorizare. Pe canalul Telegram и De asemenea, am postat un link către o traducere a capitolului 4 din aceeași carte despre Obiectivele nivelului de serviciu.
Traducere prin cat. Bucură-te de lectură!
Echipele Google SRE au principii de bază și cele mai bune practici pentru construirea de sisteme de monitorizare și notificare de succes. Acest capitol oferă recomandări cu privire la problemele pe care le poate întâmpina un vizitator al unei pagini web și cum să rezolve problemele care îngreunează afișarea paginilor web.
defini
Nu există un vocabular unic folosit pentru a discuta subiecte legate de monitorizare. Chiar și pe Google, termenii de mai jos nu sunt folosiți în mod obișnuit, dar vom enumera cele mai comune interpretări.
monitorizarea
Colectarea, prelucrarea, agregarea și afișarea datelor cantitative în timp real despre sistem: numărul de solicitări și tipurile de solicitări, numărul de erori și tipurile de erori, timpul de procesare a cererilor și timpul de funcționare a serverului.
Monitorizare cutie albă
Monitorizare bazată pe valorile afișate de membrii sistemului intern, inclusiv jurnalele, valorile de profilare JVM sau HTTP care generează statistici interne.
Monitorizare cutie neagră
Testarea comportamentului aplicației din punctul de vedere al utilizatorului.
Tabloul de bord (tablourile de bord)
O interfață (de obicei o interfață web) care oferă o imagine de ansamblu asupra indicatorilor cheie de sănătate ai serviciilor. Tabloul de bord poate avea filtre, capacitatea de a selecta ce valori să se afișeze și așa mai departe. Interfața este concepută pentru a identifica cele mai importante valori pentru utilizatori. Tabloul de bord poate afișa și informații pentru personalul de asistență tehnică: o coadă de solicitare, o listă de erori cu prioritate ridicată, un inginer desemnat pentru o anumită zonă de responsabilitate.
Alertă (notificare)
Notificări destinate să fie primite de o persoană prin e-mail sau altfel, care pot fi declanșate ca urmare a erorilor sau a creșterii cozii de solicitare. Notificările sunt clasificate ca: bilete, alerte prin e-mail și mesaje messenger.
Cauza principală (cauza principală)
Un defect software sau o eroare umană care, atunci când este corectată, nu ar trebui să apară din nou. Problema poate avea mai multe motive principale: automatizare insuficientă a procesului, defect software, studiu insuficient al logicii aplicației. Fiecare dintre acești factori poate fi cauza principală și fiecare dintre ei trebuie eliminat.
Nod și mașină (nod și mașină)
Termeni interschimbabili pentru a se referi la o singură instanță a unei aplicații care rulează pe un server fizic, mașină virtuală sau container. Pot exista mai multe servicii pe o singură mașină. Serviciile pot fi:
- legate între ele: de exemplu, un server cache și un server web;
- servicii necorelate pe același hardware: de exemplu, un depozit de coduri și un vrăjitor pentru un sistem de configurare, cum ar fi sau .
Împinge
Orice modificare a configurației software.
De ce este nevoie de monitorizare
Există mai multe motive pentru care aplicațiile ar trebui monitorizate:
Analiza tendințelor pe termen lung
Cât de mare este baza de date și cât de repede crește? Cum se modifică numărul zilnic de utilizatori?
Comparație de performanță
Interogările sunt mai rapide pe Acme Bucket of Bytes 2.72 decât Ajax DB 3.14? Cât de bine sunt cererile stocate în cache după apariția unui nod suplimentar? Site-ul a devenit mai lent decât săptămâna trecută?
Alerte (notificări)
Ceva este stricat și cineva trebuie să-l repare. Sau ceva se va rupe în curând și cineva trebuie să verifice în curând.
Crearea tablourilor de bord
Tablourile de bord ar trebui să răspundă la întrebări de bază și să includă ceva din - întârzieri (latență), trafic (trafic), erori (erori) și valoare de încărcare (saturație).
Efectuarea analizei retrospective (depanare)
Latența de procesare a cererilor a crescut, ce s-a mai întâmplat în același timp?
Sistemele de monitorizare sunt utile ca sursă de date pentru sistemele de business intelligence și pentru a facilita analiza incidentelor de securitate. Deoarece această carte se concentrează pe domeniile de inginerie în care SRE-urile au experiență, nu vom discuta aici despre tehnicile de monitorizare.
Monitorizarea și alertele permit sistemului să spună când s-a rupt sau este pe cale să se rupă. Când un sistem nu se poate repara automat, dorim ca un om să analizeze alerta, să stabilească dacă problema este încă prezentă, să o rezolve și să-i determine cauza principală. Dacă nu auditați componentele sistemului, nu veți primi niciodată o alertă doar pentru că „ceva pare puțin ciudat”.
Încărcarea alertelor umane este o utilizare destul de costisitoare a timpului angajatului. Dacă angajatul lucrează, alerta întrerupe fluxul de lucru. Dacă angajatul este acasă, alerta întrerupe timpul personal și eventual somnul. Atunci când alertele apar prea des, angajații trec, întârzie sau ignoră alertele primite. Din când în când ei ignoră adevărata alertă, care este mascata de evenimente de zgomot. Întreruperile serviciului pot dura mult timp, deoarece evenimentele de zgomot împiedică diagnosticarea și rezolvarea rapidă a problemelor. Sistemele eficiente de adresare publică au un raport semnal-zgomot bun.
Determinarea așteptărilor rezonabile de la sistemul de monitorizare
Configurarea monitorizării pentru o aplicație complexă este o sarcină de inginerie complexă în sine. Chiar și cu o infrastructură semnificativă de instrumente de colectare, afișare și alertă, o echipă Google SRE formată din 10-12 membri include de obicei una sau două persoane al căror scop principal este construirea și întreținerea sistemelor de monitorizare. Acest număr a scăzut de-a lungul timpului pe măsură ce generalizăm și centralizăm infrastructura de monitorizare, dar fiecare echipă SRE are de obicei cel puțin un membru al personalului de monitorizare. Trebuie spus că, deși este destul de interesant să urmăriți tablourile de bord ale sistemului de monitorizare, echipele SRE evită cu atenție situațiile care necesită ca cineva să se uite la ecran pentru a monitoriza problemele.
În general, Google a trecut la sisteme de monitorizare simple și rapide, cu instrumente optime de analiză post-fact. Evităm sistemele „magice” care încearcă să prezică praguri sau să descopere automat cauza principală. Senzorii care detectează conținut neintenționat în solicitările utilizatorilor finali sunt singurul contraexemplu; atâta timp cât acești senzori rămân simpli, ei pot detecta rapid cauzele anomaliilor grave. Alte formate de utilizare a datelor de monitorizare, cum ar fi planificarea capacității sau prognoza traficului, sunt mai provocatoare. O observație pe o perioadă foarte lungă de timp (luni sau ani) la o rată de eșantionare scăzută (ore sau zile) va dezvălui o tendință pe termen lung.
Echipa Google SRE a lucrat cu diferite grade de succes cu ierarhii complexe de dependență. Rareori folosim reguli precum „dacă aflu că baza de date a devenit lentă, primesc o alertă de încetinire a bazei de date, altfel primesc o alertă de site lent”. Regulile bazate pe dependență se referă de obicei la părțile neschimbate ale sistemului nostru, cum ar fi sistemul de filtrare a traficului utilizatorilor către centrul de date. De exemplu, „dacă este configurată filtrarea traficului din centrul de date, nu mă avertizați despre întârzierile în procesarea solicitărilor utilizatorilor” este o regulă comună pentru alertele din centrele de date. Puține echipe de la Google acceptă ierarhii complexe de dependență, deoarece infrastructura noastră are o rată constantă de refactorizare continuă.
Unele dintre ideile prezentate în acest capitol sunt încă valabile: există întotdeauna o modalitate de a trece mai repede de la simptom la cauza principală, în special în sistemele în continuă schimbare. Prin urmare, în timp ce acest capitol subliniază unele obiective pentru sistemele de monitorizare și modul de realizare a acestor obiective, este important ca sistemele de monitorizare să fie simple și ușor de înțeles pentru toată lumea din echipă.
De asemenea, pentru a menține nivelul de zgomot scăzut și nivelul semnalului ridicat, abordările de monitorizare a obiectelor care sunt alertate trebuie să fie foarte simple și fiabile. Regulile care generează avertismente pentru oameni ar trebui să fie ușor de înțeles și să prezinte o problemă clară.
Simptome versus cauze
Sistemul dumneavoastră de monitorizare ar trebui să răspundă la două întrebări: „ce este stricat” și „de ce este stricat”.
„Ce s-a rupt” se referă la simptom, iar „de ce s-a rupt” se referă la cauză. Tabelul de mai jos prezintă exemple de astfel de legături.
Un simptom
Provoca
Se primește eroarea HTTP 500 sau 404
Serverele de baze de date refuză conexiunile
Răspunsuri lente ale serverului
Utilizare ridicată a procesorului sau cablu Ethernet deteriorat
Utilizatorii din Antarctica nu primesc GIF-uri pentru pisici
CDN-ul tău urăște oamenii de știință și felinele, așa că unele IP-uri sunt pe lista neagră
Conținutul privat este disponibil peste tot
Lansarea unei noi versiuni de software a făcut ca firewall-ul să uite toate ACL-urile și să permită tuturor să intre
„Ce” și „de ce” sunt unul dintre cele mai importante blocuri pentru crearea unui sistem de monitorizare bun, cu semnal maxim și zgomot minim.
Cutie neagră vs. Cutie albă
Combinăm monitorizarea extinsă a casetei albe cu monitorizarea modestă a casetei negre pentru valori critice. Cel mai simplu mod de a compara Black-box cu White-box este că Black-box este concentrat pe simptome și este mai degrabă reactiv decât monitorizare proactivă: „sistemul nu funcționează corect în acest moment”. Cutia albă depinde de capacitățile de verificare internă ale sistemelor: jurnalele de evenimente sau serverele web. Astfel, White-box vă permite să detectați probleme viitoare, defecțiuni care arată ca o retransmitere a unei solicitări etc.
Rețineți că într-un sistem cu mai multe straturi, un simptom în zona de responsabilitate a unui inginer este un simptom în zona de responsabilitate a altui inginer. De exemplu, performanța bazei de date a scăzut. Citirile lente ale bazei de date sunt un simptom al bazei de date SRE care le detectează. Cu toate acestea, pentru un SRE front-end care urmărește un site web lent, motivul pentru aceeași citire lentă a bazei de date este că baza de date este lentă. Prin urmare, monitorizarea cutiei albe se concentrează uneori pe simptome și alteori pe cauze, în funcție de cât de extinsă este.
Când colectați telemetria pentru depanare, este necesară monitorizarea cutiei albe. Dacă serverele web răspund lent la interogările bazei de date, trebuie să știți cât de repede comunică serverul web cu baza de date și cât de repede răspunde. În caz contrar, nu veți putea face diferența dintre un server de baze de date lent și o problemă de rețea între serverul web și baza de date.
Monitorizarea cutie neagră are un avantaj cheie atunci când trimiteți alerte: declanșați o notificare către destinatar atunci când problema a provocat deja simptome reale. Pe de altă parte, pentru problema cutiei negre care încă nu a apărut, dar cea viitoare, monitorizarea este inutilă.
Patru semnale de aur
Cele patru semnale de monitorizare de aur sunt latența, traficul, erorile și saturația. Dacă puteți măsura doar patru valori ale sistemului de utilizator, concentrați-vă pe cele patru.
Întârziere
Timpul necesar procesării cererii. Este important să se facă distincția între latența cererilor reușite și nereușite. De exemplu, o eroare HTTP 500 cauzată de o conexiune pierdută la o bază de date sau un alt backend poate fi diagnosticată foarte rapid, cu toate acestea, o eroare HTTP 500 poate indica o solicitare eșuată. Găsirea impactului unei erori 500 asupra latenței generale poate duce la concluzii eronate. Pe de altă parte, o eroare lentă este chiar o eroare rapidă! Prin urmare, este important să urmăriți latența erorilor, mai degrabă decât doar filtrarea erorilor.
trafic
Numărul de solicitări către sistemul dvs., măsurat în valori de sistem de nivel înalt. Pentru un serviciu web, această măsurare reprezintă de obicei numărul de solicitări HTTP pe secundă împărțit la natura solicitărilor (de exemplu, conținut static sau dinamic). Pentru un sistem de streaming audio, această măsurătoare poate fi centrată pe rata I/O rețelei sau pe numărul de sesiuni concurente. Pentru un sistem de stocare cheie-valoare, această măsurătoare ar putea fi tranzacții sau căutări pe secundă.
Erori
Aceasta este rata solicitărilor eșuate, fie în mod explicit (de exemplu, HTTP 500), implicit (de exemplu, HTTP 200, dar combinate cu conținut prost), fie în funcție de politică (de exemplu, „Dacă captați un răspuns într-o secundă, orice o secundă este o eroare"). Dacă nu există suficiente coduri de răspuns HTTP pentru a exprima toate condițiile de eșec, pot fi necesare protocoale secundare (interne) pentru a detecta eșecul parțial. Monitorizarea tuturor acestor solicitări eronate poate fi neinformativă, în timp ce testele de sistem end-to-end vă pot ajuta să descoperiți că procesați conținut greșit.
Saturare
Valoarea arată cât de intens este utilizat serviciul dvs. Aceasta este o măsură de monitorizare a sistemului care identifică resursele care sunt cele mai limitate (de exemplu, într-un sistem cu memorie limitată, arată memoria, într-un sistem cu I/O limitată, arată numărul de I/O). Rețineți că multe sisteme se degradează înainte de a ajunge la 100% utilizare, așa că este esențial să aveți o țintă de utilizare.
În sistemele complexe, saturația poate fi suplimentată de măsurarea sarcinii de nivel superior: poate serviciul dumneavoastră să gestioneze în mod corespunzător traficul dublu, să gestioneze doar cu 10% mai mult trafic sau să gestioneze chiar mai puțin trafic decât poate în prezent? Pentru serviciile simple care nu au parametri care modifică complexitatea solicitării (de exemplu, „Dă-mi nimic” sau „Vreau un singur întreg monoton unic”) care modifică rareori configurația, o valoare de test de încărcare statică poate fi adecvată. Cu toate acestea, după cum sa discutat în paragraful anterior, majoritatea serviciilor ar trebui să utilizeze semnale indirecte, cum ar fi utilizarea CPU sau lățimea de bandă a rețelei, care au o limită superioară cunoscută. Creșterea latenței este adesea principalul indicator al saturației. Măsurarea timpului de răspuns al percentilei 99 într-o fereastră mică (de exemplu, un minut) poate da un semnal de saturație foarte timpuriu.
În cele din urmă, saturația este, de asemenea, asociată cu predicții privind saturația iminentă, cum ar fi: „Se pare că baza de date vă va umple hard diskul în 4 ore”.
Dacă măsori toate cele patru semnale de aur și când apare o problemă cu una dintre metrici (sau, în caz de saturație, aproape o problemă), anunți persoana, serviciul tău va fi mai mult sau mai puțin acoperit de monitorizare.
Vă faceți griji pentru coadă (sau instrumentare și performanță)
Când construiți un sistem de monitorizare de la zero, este tentant să dezvoltați un sistem bazat pe medii: latența medie, utilizarea medie a procesorului nodului sau ocuparea medie a bazei de date. Pericolul ultimelor două exemple este evident: procesoarele și bazele de date sunt eliminate într-un mod foarte imprevizibil. Același lucru este valabil și pentru întârziere. Dacă rulați un serviciu web cu o latență medie de 100 ms la 1000 de solicitări pe secundă, 1% dintre solicitări poate dura 5 secunde. Dacă utilizatorii depind de mai multe astfel de servicii web, percentila 99 a unui singur backend poate deveni cu ușurință timpul mediu de răspuns al interfeței.
Cel mai simplu mod de a distinge între o medie lentă și o coadă foarte lentă a cererilor este de a colecta măsurători ale cererilor exprimate în statistici (histogramele sunt un instrument potrivit pentru afișare), mai degrabă decât întârzierile reale: câte cereri au fost deservite de serviciul care a preluat între 0 ms și 10ms, între 10ms și 30ms, între 30ms și 100ms, între 100ms și 300ms etc. Extinderea limitelor histogramei aproximativ exponențial (cu un factor de aproximativ 3) este adesea o modalitate ușoară de a vizualiza distribuția cererilor.
Alegerea granularității potrivite pentru măsurători
Diferitele elemente ale sistemului ar trebui măsurate cu diferite niveluri de detaliu. De exemplu:
- Urmărirea utilizării CPU pe o perioadă de timp nu va arăta vârfuri lungi care au ca rezultat latențe mari.
- Pe de altă parte, pentru un serviciu web care vizează cel mult 9 ore de oprire pe an (99,9% timp de funcționare anual), verificarea unui răspuns HTTP 200 de mai multe ori sau de două ori pe minut ar fi probabil inutil de frecventă.
- În mod similar, verificarea spațiului liber pe hard disk pentru o disponibilitate de 99,9% de mai multe ori la fiecare 1-2 minute este probabil inutilă.
Aveți grijă cum structurați granularitatea dimensiunilor. O rată de utilizare a procesorului de 1 pe secundă poate oferi date interesante, dar astfel de măsurători frecvente pot fi foarte costisitoare de colectat, stocat și analizat. Dacă obiectivul dvs. de monitorizare necesită o granularitate ridicată și nu necesită o capacitate de răspuns ridicată, puteți reduce aceste costuri prin configurarea colectării de valori pe server și apoi configurarea unui sistem extern pentru a colecta și agrega acele valori. Ai putea:
- Măsurați utilizarea procesorului în fiecare secundă.
- Reduceți detaliile la 5%.
- Valori agregate în fiecare minut.
Această strategie vă va permite să colectați date extrem de granulare fără a experimenta costuri generale mari pentru analiză și stocare.
Cât de simplu posibil, dar nu mai ușor
Stivuirea diferitelor cerințe una peste alta poate duce la un sistem de monitorizare foarte complex. De exemplu, sistemul dumneavoastră poate avea următoarele elemente complicate:
- Alerte în funcție de diferite praguri pentru latența solicitărilor, în diferite percentile, pentru toate tipurile de valori diferite.
- Scrierea unui cod suplimentar pentru a detecta și identifica cauzele posibile.
- Creați tablouri de bord conexe pentru fiecare dintre posibilele cauze ale problemelor.
Sursele potențialelor complicații nu se termină niciodată. Ca toate sistemele software, monitorizarea poate deveni atât de complexă încât devine fragilă, dificil de schimbat și întreținut.
Prin urmare, proiectați-vă sistemul de monitorizare pentru a-l simplifica cât mai mult posibil. Când alegeți ce să urmăriți, țineți cont de următoarele:
- Regulile care surprind cel mai adesea incidente reale ar trebui să fie cât mai simple, previzibile și de încredere posibil.
- Configurația pentru colectarea datelor, agregarea și alertele care se efectuează rar (de exemplu, mai puțin de trimestrial pentru unele echipe SRE) ar trebui eliminată.
- Valorile care sunt colectate, dar care nu sunt afișate în niciun panou de previzualizare sau utilizate de nicio alertă sunt candidate pentru ștergere.
La Google, colectarea și agregarea de bază a valorilor, combinate cu alerte și tablouri de bord, funcționează bine ca un sistem relativ autonom (sistemul de monitorizare Google este de fapt împărțit în mai multe subsisteme, dar de obicei oamenii sunt conștienți de toate aspectele acestor subsisteme). Poate fi tentant să combinați monitorizarea cu alte metode de testare a sistemelor complexe: profilarea detaliată a sistemului, depanarea procesului, urmărirea excepțiilor sau detaliile defecțiunilor, testarea încărcării, colectarea și analiza jurnalelor sau inspecția traficului. În timp ce majoritatea acestor lucruri au puncte comune cu monitorizarea de bază, amestecarea lor va duce la prea multe rezultate și va crea un sistem complex și fragil. Ca și în cazul multor alte aspecte ale dezvoltării software, susținerea diferitelor sisteme cu puncte de integrare clare, simple, slab cuplate este cea mai bună strategie (de exemplu, utilizarea unui API web pentru a prelua date rezumate într-un format care poate rămâne constant pe o perioadă lungă de timp ).
Legarea principiilor între ele
Principiile discutate în acest capitol pot fi combinate într-o filozofie de monitorizare și alertă care este susținută și urmată de echipele Google SRE. Aderarea la această filozofie de monitorizare este de dorit, este un bun punct de plecare pentru crearea sau revizuirea unei metodologii de alertă și vă poate ajuta să adresați întrebările potrivite operațiunilor, indiferent de dimensiunea organizației dumneavoastră sau de complexitatea serviciului sau a sistemului.
Atunci când creați reguli de monitorizare și alertă, adresarea următoarelor întrebări vă poate ajuta să evitați falsele pozitive și alertele inutile:
- Detectează această regulă o stare a sistemului, altfel nedetectabilă, care este urgentă, chemează la acțiune și afectează în mod inevitabil utilizatorul?
- Pot ignora acest avertisment știind că este benign? Când și de ce pot ignora acest avertisment și cum pot evita acest scenariu?
- Această alertă înseamnă că utilizatorii sunt afectați negativ? Există situații în care utilizatorii nu sunt afectați negativ, de exemplu, din cauza filtrării traficului sau când se folosesc sisteme de testare, alerte pe care ar trebui filtrate?
- Pot lua măsuri ca răspuns la această alertă? Sunt aceste măsuri urgente sau pot aștepta până dimineața? Este sigur să automatizezi acțiunea? Va fi această acțiune o soluție pe termen lung sau o soluție pe termen scurt?
- Unii oameni primesc mai multe alerte pentru această problemă, deci este posibil să se reducă numărul?
Aceste întrebări reflectă filozofia fundamentală privind alertele și sistemele de alertă:
- De fiecare dată când vine o alertă, trebuie să reacționez urgent. Pot să mă grăbesc de câteva ori pe zi înainte să obosesc.
- Fiecare alertă trebuie să fie actualizată.
- Fiecare răspuns la o alertă trebuie să necesite intervenția umană. Dacă notificarea poate fi procesată automat, nu ar trebui să vină.
- Alertele ar trebui să fie despre o problemă nouă sau un eveniment care nu s-a întâmplat înainte.
Această abordare estompează anumite distincții: dacă o alertă îndeplinește cele patru condiții anterioare, nu contează dacă alerta este trimisă dintr-un sistem de monitorizare White-box sau Black-Box. Această abordare întărește și anumite diferențe: este mai bine să depuneți mult mai mult efort pentru identificarea simptomelor decât pe cauze; când vine vorba de cauze, trebuie să vă faceți griji doar cu privire la cauzele inevitabile.
Monitorizare pe termen lung
În mediile de producție actuale, sistemele de monitorizare monitorizează un sistem de producție în continuă evoluție, cu arhitectură software, caracteristici de încărcare și obiective de performanță în schimbare. Alertele, care în prezent sunt greu de automatizat, pot deveni comune, poate chiar meritând să fie abordate. În acest moment, cineva trebuie să găsească și să remedieze cauzele principale ale problemei; dacă o astfel de rezolvare nu este posibilă, reacția la alertă necesită o automatizare completă.
Este important ca deciziile de monitorizare să fie luate având în vedere obiective pe termen lung. Fiecare alertă care rulează astăzi îndepărtează o persoană de a îmbunătăți sistemul de mâine, astfel încât există adesea o scădere a disponibilității sau performanței unui sistem productiv pentru timpul necesar pentru îmbunătățirea sistemului de monitorizare pe termen lung. Să ne uităm la două exemple care ilustrează acest fenomen.
Bigtable SRE: O poveste despre supra-alerta
Infrastructura internă Google este de obicei furnizată și măsurată în termeni de nivel de serviciu (SLO). Cu ani în urmă, SLO-ul serviciului Bigtable se baza pe performanța medie a unei tranzacții sintetice care simulează un client care rulează. Din cauza problemelor din Bigtable și a nivelurilor inferioare ale stivei de stocare, performanța medie a fost determinată de o coadă „mare”: cele mai proaste 5% dintre interogări au fost adesea semnificativ mai lente decât restul.
Notificări prin e-mail au fost trimise pe măsură ce pragul SLO a fost apropiat, iar alertele de mesagerie au fost trimise când SLO a fost depășit. Ambele tipuri de alerte au fost trimise destul de frecvent, consumând cantități inacceptabile de timp de inginerie: echipa a petrecut o perioadă semnificativă de timp analizând alertele pentru a găsi câteva care erau de fapt relevante. Am omis adesea o problemă care a afectat de fapt utilizatorii, deoarece doar câteva dintre alerte erau pentru acea problemă anume. Multe dintre alerte au fost neurgente din cauza unor probleme de infrastructură ușor de înțeles și au fost gestionate într-un mod standard sau nu au fost gestionate deloc.
Pentru a remedia situația, echipa a folosit o abordare pe trei direcții: în timp ce lucrăm din greu pentru a îmbunătăți performanța Bigtable, am stabilit temporar percentila 75 pentru întârzierea răspunsului la interogare ca obiectiv SLO. De asemenea, am dezactivat alertele prin e-mail, deoarece erau atât de multe încât era imposibil să pierzi timpul diagnosticându-le.
Această strategie ne-a permis să începem să remediem problemele pe termen lung în Bigtable și în straturile inferioare ale stivei de stocare, mai degrabă decât să remediem în mod constant problemele tactice. Inginerii puteau să-și facă treaba atunci când nu erau bombardați cu alerte tot timpul. În cele din urmă, întârzierea temporară în procesarea alertelor ne-a permis să îmbunătățim calitatea serviciului.
Gmail: răspunsuri umane previzibile, algoritmice
La început, Gmail a fost construit pe un sistem de control al procesului Workqueue modificat, care a fost creat pentru a procesa în loturi bucăți de index de căutare. Workqueue a fost adaptat proceselor de lungă durată și ulterior aplicat Gmail, dar unele erori din codul opac de planificare s-au dovedit foarte greu de remediat.
La acea vreme, monitorizarea Gmail era structurată astfel încât alertele să se declanșeze atunci când sarcinile individuale erau anulate folosind Workqueue. Această abordare nu a fost ideală, deoarece chiar și în acel moment Gmail a efectuat multe mii de sarcini, fiecare dintre ele fiind dată unor fracțiuni de procent din utilizatorii noștri. Am avut mare grijă să ne asigurăm că utilizatorii Gmail au o experiență bună de utilizare, dar gestionarea atâtor alerte a fost exclusă.
Pentru a rezolva această problemă, Gmail SRE a creat un instrument pentru a ajuta la depanarea programatorului cât mai bine posibil, pentru a minimiza impactul asupra utilizatorilor. Echipa a avut mai multe discuții despre dacă să automatizeze pur și simplu întregul ciclu de la găsirea problemei până la remedierea acesteia până când se găsește o soluție pe termen lung, dar unii erau îngrijorați că o astfel de soluție ar întârzia rezolvarea efectivă a problemei.
O astfel de tensiune era obișnuită în cadrul echipei și reflecta adesea o neîncredere în autodisciplină: în timp ce unii membri ai echipei doresc să acorde timp pentru o remediere adecvată, alții se îngrijorează că soluția finală va fi uitată și soluția temporară va dura pentru totdeauna. Această problemă merită atenție, deoarece este prea ușor să remediați problemele temporar, în loc să faceți o remediere permanentă. Managerii și personalul tehnic joacă un rol cheie în implementarea remediilor pe termen lung prin sprijinirea și prioritizarea remediilor pe termen lung potențial pe termen lung, chiar și atunci când durerea inițială dispare.
Alertele periodice recurente și reacțiile algoritmice ar trebui să fie un semnal roșu. Reticența echipei dvs. de a automatiza aceste alerte înseamnă că echipa nu are încredere că poate avea încredere în algoritmi. Aceasta este o problemă serioasă care trebuie rezolvată.
Termen lung
O temă comună leagă exemplele Bigtable și Gmail: concurența dintre disponibilitatea pe termen scurt și pe termen lung. Adesea, un efort puternic poate ajuta un sistem fragil să atingă o disponibilitate ridicată, dar această cale este de obicei de scurtă durată, plină de epuizare a echipei și dependență de un număr mic de membri ai aceleiași echipe eroice.
O scădere controlată, pe termen scurt, a disponibilității este adesea dureroasă, dar importantă din punct de vedere strategic pentru stabilitatea pe termen lung a sistemului. Este important să nu luăm în considerare fiecare alertă în mod izolat, ci să luăm în considerare dacă rata generală a alertelor conduce la un sistem sănătos, accesibil corespunzător, cu o echipă viabilă și un prognostic favorabil. Analizăm statisticile ratei de alertă (exprimate de obicei ca incidente pe tură, unde un incident poate consta din mai multe incidente conexe) în rapoarte trimestriale cu managementul, permițând factorilor de decizie să prezinte continuu încărcarea sistemului de alertă și starea generală a echipei.
Concluzie
Calea către monitorizarea și alertele sănătoase este simplă și directă. Se concentrează pe simptomele problemei pentru care sunt generate alerte, iar monitorizarea cauzei servește ca ajutor la depanarea problemelor. Monitorizarea simptomelor este mai ușoară cu cât sunteți mai sus în stiva pe care o controlați, deși încărcarea bazei de date și monitorizarea performanței ar trebui făcute direct pe baza de date în sine. Notificările prin e-mail sunt de o utilizare foarte limitată și tind să se transforme cu ușurință în zgomot; în schimb, ar trebui să utilizați un tablou de bord care monitorizează toate problemele curente care sunt alertate prin e-mail. Tabloul de bord poate fi asociat și cu un jurnal de evenimente pentru a analiza corelațiile istorice.
Pe termen lung, trebuie realizată o alternanță cu succes între alertele de simptome și problemele reale iminente și obiectivele adaptate pentru a se asigura că monitorizarea susține diagnosticarea rapidă.
Vă mulțumesc că ați citit traducerea până la sfârșit. Abonați-vă la canalul meu Telegram despre monitorizare и .
Sursa: www.habr.com