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 и Am publicat și o traducere a capitolului 6 din aceeași carte despre obiectivele nivelului de serviciu.
Traducere prin cat. Bucură-te de lectură!
Este imposibil să gestionezi un serviciu dacă nu se înțelege ce indicatori contează de fapt și cum să îi măsoare și să le evaluezi. În acest scop, definim și oferim un anumit nivel de servicii utilizatorilor noștri, indiferent dacă folosesc unul dintre API-urile noastre interne sau un produs public.
Ne folosim intuiția, experiența și înțelegerea dorinței utilizatorilor de a înțelege Indicatorii Nivelului de Serviciu (SLI), Obiectivele Nivelului de Serviciu (SLO) și Acordurile de Nivel de Serviciu (SLA). Aceste dimensiuni descriu principalele metrici pe care dorim să le monitorizăm și la care vom reacționa dacă nu putem oferi calitatea așteptată a serviciului. În cele din urmă, alegerea valorilor potrivite ajută la ghidarea acțiunilor corecte dacă ceva nu merge bine și, de asemenea, oferă echipei SRE încredere în starea de sănătate a serviciului.
Acest capitol descrie abordarea pe care o folosim pentru a combate problemele de modelare metrică, selecție metrică și analiză metrică. Cea mai mare parte a explicației va fi fără exemple, așa că vom folosi serviciul Shakespeare descris în exemplul său de implementare (căutarea lucrărilor lui Shakespeare) pentru a ilustra punctele principale.
Terminologia nivelului de serviciu
Mulți cititori sunt probabil familiarizați cu conceptul de SLA, dar termenii SLI și SLO merită o definiție atentă, deoarece, în general, termenul SLA este supraîncărcat și are o serie de semnificații în funcție de context. Pentru claritate, dorim să separăm aceste valori.
Indicatoare
SLI este un indicator al nivelului de serviciu - o măsură cantitativă atent definită a unui aspect al nivelului de serviciu furnizat.
Pentru majoritatea serviciilor, cheia SLI este considerată a fi latența cererii - cât timp durează pentru a returna un răspuns la o solicitare. Alte SLI obișnuite includ rata de eroare, adesea exprimată ca o fracțiune din toate cererile primite, și debitul sistemului, de obicei măsurat în cereri pe secundă. Măsurătorile sunt adesea agregate: datele brute sunt mai întâi colectate și apoi convertite într-o rată de modificare, medie sau percentilă.
În mod ideal, SLI măsoară în mod direct nivelul de interes al serviciului, dar uneori doar o metrică aferentă este disponibilă pentru măsurare, deoarece cea inițială este dificil de obținut sau interpretat. De exemplu, latența pe partea clientului este adesea o măsură mai adecvată, dar există momente în care latența poate fi măsurată doar pe server.
Un alt tip de SLI care este important pentru SRE este disponibilitatea sau porțiunea de timp în care poate fi utilizat un serviciu. Deseori definită ca rata de cereri de succes, uneori numită randament. (Durata de viață – probabilitatea ca datele să fie păstrate pentru o perioadă lungă de timp – este, de asemenea, importantă pentru sistemele de stocare a datelor.) Deși nu este posibilă disponibilitatea 100%, disponibilitatea aproape de 100% este adesea realizabilă; valorile de disponibilitate sunt exprimate ca numărul de „nouă” » procentul de disponibilitate. De exemplu, disponibilitatea de 99% și 99,999% ar putea fi etichetată ca „2 nouă” și „5 nouă”. Obiectivul actual de disponibilitate declarat al Google Compute Engine este „trei nouă și jumătate” sau 99,95%.
goluri
SLO — это цель уровня обслуживания: целевое значение или диапазон значений для уровня обслуживания, который измеряется SLI. Нормальным значением для SLO является «SLI ≤ целевого значения» или «нижняя граница ≤ SLI ≤ верхняя граница». Например, мы можем решить, что мы вернем результаты поиска по произведениям Шекспира «быстро», приняв в виде SLO значение средней задержки запроса поиска меньшее 100 миллисекунд.
Alegerea SLO-ului potrivit este un proces complex. În primul rând, nu puteți alege întotdeauna o anumită valoare. Pentru solicitările HTTP externe primite către serviciul dvs., valoarea Query Per Second (QPS) este determinată în primul rând de dorința utilizatorilor dvs. de a vă vizita serviciul și nu puteți seta un SLO pentru asta.
Pe de altă parte, puteți spune că doriți ca latența medie pentru fiecare solicitare să fie mai mică de 100 de milisecunde. Setarea unui astfel de obiectiv vă poate obliga să vă scrieți frontend-ul cu o latență scăzută sau să cumpărați echipamente care oferă o astfel de latență. (100 de milisecunde este, evident, un număr arbitrar, dar este mai bine să aveți numere de latență și mai mici. Există dovezi care sugerează că vitezele rapide sunt mai bune decât vitezele mici și că latența în procesarea cererilor utilizatorilor peste anumite valori îi obligă pe oameni să stea departe. din serviciul dumneavoastră.)
Din nou, acest lucru este mai ambiguu decât ar părea la prima vedere: nu ar trebui să excludeți complet QPS din calcul. Faptul este că QPS și latența sunt strâns legate între ele: QPS mai mare duce adesea la latențe mai mari, iar serviciile înregistrează de obicei o scădere bruscă a performanței atunci când ating un anumit prag de încărcare.
Selectarea și publicarea unui SLO stabilește așteptările utilizatorilor cu privire la modul în care va funcționa serviciul. Această strategie poate reduce plângerile nefondate împotriva proprietarului serviciului, cum ar fi performanța lentă. Fără un SLO explicit, utilizatorii își creează adesea propriile așteptări cu privire la performanța dorită, care ar putea să nu aibă nimic de-a face cu opiniile oamenilor care proiectează și gestionează serviciul. Această situație poate duce la așteptări umflate de la serviciu, atunci când utilizatorii cred în mod eronat că serviciul va fi mai accesibil decât este în realitate și poate provoca neîncredere atunci când utilizatorii cred că sistemul este mai puțin fiabil decât este în realitate.
Acorduri
Un acord de nivel de serviciu este un contract explicit sau implicit cu utilizatorii dvs. care include consecințele îndeplinirii (sau neîndeplinirii) SLO-urilor pe care le conțin. Consecințele sunt cel mai ușor de recunoscut atunci când sunt financiare – o reducere sau o amendă – dar pot lua alte forme. O modalitate ușoară de a vorbi despre diferența dintre SLO-uri și SLA-uri este să întrebați „ce se întâmplă dacă SLO-urile nu sunt îndeplinite?” Dacă nu există consecințe clare, aproape sigur vă uitați la un SLO.
De obicei, SRE nu este implicat în crearea SLA-urilor, deoarece SLA-urile sunt strâns legate de deciziile de afaceri și de produse. Cu toate acestea, SRE este implicată în a ajuta la atenuarea consecințelor SLO-urilor eșuate. Ele pot ajuta, de asemenea, la determinarea SLI: în mod evident, trebuie să existe o modalitate obiectivă de a măsura SLO în acord, altfel va exista dezacord.
Căutarea Google este un exemplu de serviciu important care nu are un SLA public: dorim ca toată lumea să folosească Căutarea cât mai eficient posibil, dar nu am semnat un contract cu lumea. Cu toate acestea, există încă consecințe dacă căutarea este indisponibilă - indisponibilitatea duce la o scădere a reputației noastre, precum și la reducerea veniturilor din publicitate. Multe alte servicii Google, cum ar fi Google for Work, au acorduri explicite privind nivelul de servicii cu utilizatorii. Indiferent dacă un anumit serviciu are un SLA, este important să definiți SLI și SLO și să le folosiți pentru a gestiona serviciul.
Atâta teorie - acum de experimentat.
Indicatori în practică
Având în vedere că am ajuns la concluzia că este important să selectăm valorile adecvate pentru a măsura nivelul de serviciu, de unde știți acum ce valori contează pentru un serviciu sau sistem?
О чем вы и ваши пользователи заботитесь
Nu trebuie să utilizați fiecare măsură ca un SLI pe care îl puteți urmări într-un sistem de monitorizare; Înțelegerea ce doresc utilizatorii de la un sistem vă va ajuta să selectați mai multe valori. Alegerea prea multor indicatori face dificilă concentrarea asupra indicatorilor importanți, în timp ce alegerea unui număr mic poate lăsa părți mari din sistem nesupravegheate. De obicei, folosim mai mulți indicatori cheie pentru a evalua și înțelege starea de sănătate a unui sistem.
Serviciile pot fi, în general, împărțite în mai multe părți în ceea ce privește SLI, care sunt relevante pentru acestea:
- Sisteme front-end personalizate, cum ar fi interfețele de căutare pentru serviciul Shakespeare din exemplul nostru. Acestea trebuie să fie disponibile, să nu aibă întârzieri și să aibă o lățime de bandă suficientă. În consecință, se pot pune întrebări: putem răspunde la cerere? Cât timp a durat să răspund la cerere? Câte cereri pot fi procesate?
- Sisteme de depozitare. Ei apreciază latența scăzută de răspuns, disponibilitatea și durabilitatea. Întrebări înrudite: Cât durează citirea sau scrierea datelor? Putem accesa datele la cerere? Sunt datele disponibile atunci când avem nevoie? Consultați Capitolul 26 Integritatea datelor: ceea ce citiți este ceea ce scrieți pentru o discuție detaliată a acestor probleme.
- Sistemele de date mari, cum ar fi conductele de procesare a datelor, se bazează pe randament și pe latența procesării interogărilor. Întrebări înrudite: Câte date sunt procesate? Cât durează până când datele parcurg de la primirea unei solicitări până la emiterea unui răspuns? (Unele părți ale sistemului pot avea, de asemenea, întârzieri în anumite etape.)
Culegere de indicatori
Mulți indicatori de nivel de serviciu sunt colectați în mod natural pe partea serverului, folosind un sistem de monitorizare precum Borgmon (vezi mai jos). ) sau Prometheus, sau pur și simplu analizând periodic jurnalele, identificând răspunsurile HTTP cu starea 500. Cu toate acestea, unele sisteme ar trebui să fie echipate cu colectare de valori la nivelul clientului, deoarece lipsa monitorizării la nivelul clientului poate duce la omiterea unui număr de probleme care afectează utilizatorii, dar nu afectează valorile de pe server. De exemplu, concentrarea asupra latenței răspunsului de backend a aplicației noastre de testare a căutării Shakespeare poate duce la o latență din partea utilizatorului din cauza problemelor JavaScript: în acest caz, măsurarea timpului durează browserul pentru a procesa pagina este o măsură mai bună.
Agregare
Pentru simplitate și ușurință în utilizare, cumulăm adesea măsurătorile brute. Acest lucru trebuie făcut cu atenție.
Unele valori par simple, cum ar fi solicitările pe secundă, dar chiar și această măsurătoare aparent simplă adună implicit datele în timp. Este măsurarea primită în mod specific o dată pe secundă sau măsurarea este mediată pe numărul de solicitări pe minut? Ultima opțiune poate ascunde un număr instantaneu mult mai mare de solicitări care durează doar câteva secunde. Luați în considerare un sistem care deservește 200 de solicitări pe secundă cu numere pare și 0 în restul timpului. O constantă sub forma unei valori medii de 100 de solicitări pe secundă și de două ori sarcina instantanee nu sunt același lucru. În mod similar, media latențelor de interogare poate părea atractivă, dar ascunde un detaliu important: este posibil ca majoritatea interogărilor să fie rapide, dar vor exista multe interogări lente.
Majoritatea indicatorilor sunt priviți mai bine ca distribuții decât ca medii. De exemplu, pentru latența SLI, unele solicitări vor fi procesate rapid, în timp ce unele vor dura întotdeauna mai mult, uneori mult mai mult. O medie simplă poate ascunde aceste întârzieri lungi. Figura arată un exemplu: deși o solicitare tipică durează aproximativ 50 ms pentru a fi servită, 5% dintre solicitări sunt de 20 de ori mai lente! Monitorizarea și alertarea bazate doar pe latența medie nu arată modificări de comportament pe parcursul zilei, când de fapt sunt modificări notabile în timpul de procesare a unor solicitări (linia de sus).
Latența sistemului de 50, 85, 95 și 99 percentile. Axa Y este în format logaritmic.
Utilizarea percentilelor pentru indicatori vă permite să vedeți forma distribuției și caracteristicile acesteia: un nivel de percentilă ridicat, cum ar fi 99 sau 99,9, arată cea mai proastă valoare, în timp ce percentila 50 (cunoscută și sub numele de mediană) arată cea mai frecventă stare de metrica. Cu cât dispersia timpului de răspuns este mai mare, cu atât cererile de lungă durată influențează experiența utilizatorului. Efectul este sporit la sarcină mare și în prezența cozilor. Cercetările privind experiența utilizatorului au arătat că oamenii preferă, în general, un sistem mai lent, cu variație mare a timpului de răspuns, așa că unele echipe SRE se concentrează doar pe scoruri percentile ridicate, pe baza că, dacă comportamentul unei valori la percentila 99,9 este bun, majoritatea utilizatorilor nu vor întâmpina probleme. .
Notă despre erorile statistice
În general, preferăm să lucrăm cu percentile mai degrabă decât cu media (media aritmetică) a unui set de valori. Acest lucru ne permite să luăm în considerare valori mai dispersate, care au adesea caracteristici semnificativ diferite (și mai interesante) decât media. Datorită naturii artificiale a sistemelor de calcul, valorile metrice sunt adesea denaturate, de exemplu, nicio solicitare nu poate primi un răspuns în mai puțin de 0 ms, iar un timeout de 1000 ms înseamnă că nu pot exista răspunsuri de succes cu valori mai mari. decât timeout-ul. Ca urmare, nu putem accepta că media și mediana pot fi la fel sau aproape una de cealaltă!
Fără testare prealabilă și dacă nu sunt valabile anumite ipoteze și aproximări standard, avem grijă să nu concluzionăm că datele noastre sunt distribuite în mod normal. Dacă distribuția nu este conform așteptărilor, procesul de automatizare care rezolvă problema (de exemplu, când vede valori aberante, repornește serverul cu latențe mari de procesare a cererilor) poate să o facă prea des sau să nu fie suficient de des (ambele nu sunt foarte bun).
Стандартизировать индикаторы
Vă recomandăm să standardizați caracteristicile generale pentru SLI, astfel încât să nu fiți nevoit să speculați despre ele de fiecare dată. Orice caracteristică care satisface modele standard poate fi exclusă din specificația unui SLI individual, de exemplu:
- Intervale de agregare: „în medie peste 1 minut”
- Zone de agregare: „Toate sarcinile din cluster”
- Cât de des se fac măsurători: „La fiecare 10 secunde”
- Ce solicitări sunt incluse: „HTTP GET din joburile de monitorizare cutie neagră”
- Cum se obțin datele: „Mulțumită monitorizării noastre măsurate pe server”
- Latența accesului la date: „Timp până la ultimul octet”
Pentru a economisi efort, creați un set de șabloane SLI reutilizabile pentru fiecare valoare comună; de asemenea, fac mai ușor pentru toată lumea să înțeleagă ce înseamnă un anumit SLI.
Goluri în practică
Începeți prin a vă gândi (sau a afla!) la ce le pasă utilizatorilor dvs., nu la ce puteți măsura. Adesea, ceea ce le pasă utilizatorilor tăi este dificil sau imposibil de măsurat, așa că ajungi să te apropii mai mult de nevoile lor. Cu toate acestea, dacă începeți doar cu ceea ce este ușor de măsurat, veți ajunge cu SLO-uri mai puțin utile. Ca urmare, am constatat uneori că identificarea inițială a obiectivelor dorite și apoi lucrul cu indicatori specifici funcționează mai bine decât alegerea indicatorilor și apoi atingerea obiectivelor.
Definiți obiective
Pentru o claritate maximă, ar trebui definit modul în care sunt măsurate SLO-urile și condițiile în care sunt valabile. De exemplu, am putea spune următoarele (a doua linie este aceeași cu prima, dar folosește valorile implicite SLI):
- 99% (în medie peste 1 minut) din apelurile Get RPC se vor finaliza în mai puțin de 100 ms (măsurate pe toate serverele backend).
- 99% din apelurile Get RPC se vor finaliza în mai puțin de 100 ms.
Dacă forma curbelor de performanță este importantă, puteți specifica mai multe SLO-uri:
- 90% din apelurile Obțineți RPC finalizate în mai puțin de 1 ms.
- 99% din apelurile Obțineți RPC finalizate în mai puțin de 10 ms.
- 99.9% din apelurile Obțineți RPC finalizate în mai puțin de 100 ms.
Dacă utilizatorii dvs. generează sarcini de lucru eterogene: procesare în bloc (pentru care debitul este important) și procesare interactivă (pentru care latența este importantă), ar putea fi util să definiți obiective separate pentru fiecare clasă de încărcare:
- 95% din cererile clienților necesită un proces de transfer. Setați numărul apelurilor RPC executate <1 s.
- 99% dintre clienți le pasă de latență. Setați numărul de apeluri RPC cu trafic <1 KB și rulează <10 ms.
Este nerealist și de nedorit să insistăm că SLO-urile vor fi îndeplinite 100% din timp: acest lucru poate reduce ritmul introducerii de noi funcționalități și implementare și necesită soluții costisitoare. În schimb, este mai bine să permiteți un buget de eroare - procentul de nefuncționare a sistemului permis - și să monitorizați această valoare zilnic sau săptămânal. Managementul superior poate dori evaluări lunare sau trimestriale. (Bugetul de eroare este pur și simplu un SLO pentru comparație cu un alt SLO.)
Procentul de încălcări SLO poate fi comparat cu bugetul de eroare (vezi Capitolul 3 și secțiunea ), cu valoarea diferenței utilizată ca intrare în procesul care decide când să implementeze noile versiuni.
Selectarea valorilor țintă
Selectarea valorilor de planificare (SLO) nu este o activitate pur tehnică din cauza intereselor de produs și de afaceri care trebuie să se reflecte în SLI-urile, SLO-urile (și eventual SLA-urile) selectate. De asemenea, poate fi necesar un schimb de informații cu privire la aspecte legate de personal, timpul de lansare pe piață, disponibilitatea echipamentelor și finanțare. SRE ar trebui să facă parte din această conversație și să ajute la înțelegerea riscurilor și viabilității diferitelor opțiuni. Am venit cu câteva întrebări care ar putea ajuta la asigurarea unei discuții mai productive:
Nu alegeți un obiectiv bazat pe performanța actuală.
În timp ce înțelegerea punctelor forte și a limitelor unui sistem este importantă, adaptarea valorilor fără raționament vă poate împiedica să mențineți sistemul: va necesita eforturi eroice pentru a atinge obiective care nu pot fi atinse fără o reproiectare semnificativă.
Fii simplu
Calculele SLI complexe pot ascunde modificările în performanța sistemului și pot face mai dificilă găsirea cauzei problemei.
Evita absolutele
Deși este tentant să existe un sistem care poate face față unei sarcini în creștere nelimitată fără a crește latența, această cerință este nerealistă. Un sistem care se apropie de astfel de idealuri va necesita probabil mult timp pentru proiectare și construcție, va fi costisitor de operat și va fi prea bun pentru așteptările utilizatorilor care ar face cu ceva mai puțin.
Folosiți cât mai puține SLO posibil
Selectați un număr suficient de SLO pentru a asigura o bună acoperire a atributelor sistemului. Protejați SLO-urile pe care le alegeți: dacă nu puteți câștiga niciodată un argument despre priorități specificând un anumit SLO, probabil că nu merită să luați în considerare acel SLO. Cu toate acestea, nu toate atributele sistemului sunt adaptabile SLO-urilor: este dificil să se calculeze nivelul de plăcere a utilizatorului folosind SLO-uri.
Nu urmăriți perfecțiunea
Puteți îmbunătăți oricând definițiile și obiectivele SLO-urilor de-a lungul timpului, pe măsură ce aflați mai multe despre comportamentul sistemului sub încărcare. Este mai bine să începeți cu un obiectiv plutitor pe care îl veți perfecționa în timp decât să alegeți un obiectiv prea strict care trebuie relaxat atunci când veți găsi că este de neatins.
SLO-urile pot și ar trebui să fie un factor cheie în prioritizarea muncii pentru SRE și dezvoltatorii de produse, deoarece reflectă o preocupare pentru utilizatori. Un SLO bun este un instrument de aplicare util pentru o echipă de dezvoltare. Dar un SLO prost proiectat poate duce la muncă irosită dacă echipa face eforturi eroice pentru a obține un SLO prea agresiv sau un produs slab dacă SLO este prea scăzut. SLO este o pârghie puternică, folosiți-o cu înțelepciune.
Controlează-ți măsurătorile
SLI și SLO sunt elemente cheie utilizate pentru gestionarea sistemelor:
- Monitorizați și măsurați sistemele SLI.
- Comparați SLI cu SLO și decideți dacă este nevoie de acțiuni.
- Dacă este necesară acțiune, înțelegeți ce trebuie să se întâmple pentru a atinge obiectivul.
- Finalizați această acțiune.
De exemplu, dacă pasul 2 arată că cererea expiră și va întrerupe SLO în câteva ore dacă nu se face nimic, pasul 3 ar putea implica testarea ipotezei conform căreia serverele sunt legate de CPU și adăugarea mai multor servere va distribui încărcarea . Fără un SLO, nu ați ști dacă (sau când) să luați măsuri.
Setați SLO - apoi așteptările utilizatorilor vor fi setate
Publicarea unui SLO stabilește așteptările utilizatorilor pentru comportamentul sistemului. Utilizatorii (și potențialii utilizatori) doresc adesea să știe la ce să se aștepte de la un serviciu pentru a înțelege dacă este potrivit pentru utilizare. De exemplu, persoanele care doresc să utilizeze un site web de partajare a fotografiilor ar putea dori să evite utilizarea unui serviciu care promite longevitate și costuri reduse în schimbul unei disponibilități ceva mai reduse, chiar dacă același serviciu ar putea fi ideal pentru un sistem de gestionare a înregistrărilor de arhivă.
Pentru a stabili așteptări realiste pentru utilizatorii dvs., utilizați una sau ambele dintre următoarele tactici:
- Păstrați o marjă de siguranță. Utilizați un SLO intern mai strict decât ceea ce este anunțat utilizatorilor. Acest lucru vă va oferi posibilitatea de a reacționa la probleme înainte ca acestea să devină vizibile în exterior. Buffer-ul SLO vă permite, de asemenea, să aveți o marjă de siguranță atunci când instalați versiuni care afectează performanța sistemului și vă asigură că sistemul este ușor de întreținut fără a fi nevoiți să frustrați utilizatorii cu timpul de nefuncționare.
- Nu depășiți așteptările utilizatorilor. Utilizatorii se bazează pe ceea ce oferiți, nu pe ceea ce spuneți. Dacă performanța reală a serviciului dvs. este mult mai bună decât SLO-ul declarat, utilizatorii se vor baza pe performanța actuală. Puteți evita supradependența prin oprirea intenționată a sistemului sau limitarea performanței la sarcini ușoare.
Înțelegerea cât de bine întrunește un sistem așteptările vă ajută să decideți dacă să investiți în accelerarea sistemului și pentru a-l face mai accesibil și mai rezistent. Alternativ, dacă un serviciu funcționează prea bine, o parte din timpul personalului ar trebui să fie alocat altor priorități, cum ar fi achitarea datoriilor tehnice, adăugarea de noi funcții sau introducerea de noi produse.
Acordurile în practică
Crearea unui SLA necesită ca echipele de afaceri și juridice să definească consecințele și sancțiunile pentru încălcarea acestuia. Rolul SRE este de a-i ajuta să înțeleagă provocările probabile în îndeplinirea SLO-urilor cuprinse în SLA. Majoritatea recomandărilor pentru crearea SLO-urilor se aplică și SLA-urilor. Este înțelept să fii conservator în ceea ce promiteți utilizatorilor, deoarece cu cât aveți mai multe, cu atât este mai greu să schimbați sau să eliminați SLA-uri care par nerezonabile sau dificil de respectat.
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