O suită fiabilă de observabilitate DevOps ajută echipa să detecteze incidentele, să înțeleagă ce a eșuat și să ia decizii clare în timpul serviciului de gardă. Utilizați această listă de verificare pentru a analiza colectarea datelor de telemetrie, corelarea semnalelor, tablourile de bord, alertele, păstrarea datelor, accesul, instrumentarea și costurile asociate în întregul mediu.
Cuprins
1. Confirmați scopul fiecărui semnal
Telemetria reprezintă datele operaționale colectate din sisteme și aplicații. Principalele semnale din această listă de verificare sunt metricile, jurnalele și urmele. Acestea răspund la întrebări diferite, așa că auditul ar trebui să arate de unde provine fiecare semnal, unde este stocat și cine îl utilizează în timpul unui incident.
- Indicatori: confirmă faptul că comportamentul important al serviciilor și infrastructurii este măsurat în timp.
- Jurnale: confirmă faptul că evenimentele aplicațiilor și ale sistemului pot fi analizate cu suficient context pentru a sprijini analiza defecțiunilor.
- Urmăriri: confirmă faptul că o solicitare poate fi urmărită prin toate părțile sistemului care o procesează.
- Alerte: confirmă faptul că echipa este notificată atunci când un eveniment necesită o acțiune, în loc să primească un mesaj pentru fiecare modificare.
OpenTelemetry și Prometheus răspund unor nevoi de observabilitate conexe, dar diferite. Alegerea depinde de faptul dacă echipa are nevoie de colectarea datelor de telemetrie, de metrici, de trasee sau de o combinație a acestor capacități. Menționați această distincție în raportul de audit, în loc să tratați toate instrumentele de observabilitate ca fiind interschimbabile. Comparația realizată de mybox între OpenTelemetry și Prometheus oferă distincția relevantă.
2. Verificați colectarea datelor de telemetrie și instrumentarea
Pentru fiecare serviciu critic, înregistrați dacă există instrumentare și ce semnale produce aceasta. Rezultatul ar trebui să permită identificarea serviciului, a mediului său și a componentei care a emis datele.
- Enumerați fiecare aplicație și componentă de infrastructură care ar trebui să producă date de telemetrie.
- Indicați dacă pentru fiecare componentă se colectează metrici, jurnale și urme.
- Înregistrați metoda de colectare și instrumentul responsabil de aceasta.
- Verificați dacă în datele colectate apar cereri importante, sarcini de fundal și dependențe.
- Identificați serviciile care generează date, dar nu sunt conectate la un tablou de bord sau la un sistem de alerte.
Includeți Prometheus, Grafana, Loki, OpenTelemetry și Jaeger în inventarul de instrumente atunci când acestea fac parte din stivă. Pentru fiecare dintre acestea, documentați rolul său real, semnalele pe care le gestionează, proprietarul său și utilizatorii din aval. Acest lucru previne o configurare fragmentată în care un instrument este implementat, dar nicio echipă nu este responsabilă pentru rezultat.
3. Testați corelația dintre semnale
Detectarea și diagnosticarea necesită mai mult decât baze de date separate. Inginerul de gardă ar trebui să poată trece de la o alertă la serviciul, jurnalele și detaliile cererii asociate, fără a fi nevoit să ghicească ce identificatori sau interval de timp să utilizeze.
- Începeți cu o alertă reală și înregistrați pașii necesari pentru a ajunge la metricile, jurnalele și urmele asociate.
- Verificați dacă numele serviciilor, numele mediilor și informațiile temporale utilizează valori consecvente în toate instrumentele.
- Confirmați că același incident poate fi investigat pe baza mai multor semnale.
- Înregistrați unde se întrerupe calea, cum ar fi un nume de serviciu lipsă sau un semnal stocat fără un context util.
O stivă care colectează toate cele trei semnale, dar nu le poate conecta, lasă în continuare o lacună în diagnosticare. Tratați corelația ca o cerință de audit separată, nu ca un rezultat automat al instalării mai multor instrumente.
4. Analizați tablourile de bord pentru luarea deciziilor
Tablourile de bord ar trebui să susțină o decizie operațională specifică. Creați un inventar care să includă numele tabloului de bord, utilizatorul vizat, serviciul, semnalul și acțiunea pe care o susține.
- Păstrați o vizualizare la nivel de serviciu pentru a detecta o schimbare a stării de sănătate.
- Mențineți o perspectivă la nivel de componentă pentru a restrânge zona afectată.
- Afișați aceleași etichete de serviciu și mediu utilizate de alerte.
- Eliminați panourile care nu sunt utilizate în timpul detectării, diagnosticării sau recuperării.
- Desemnați un responsabil care să verifice tabloul de bord atunci când serviciul suferă modificări.
Monitorizarea disponibilității ar trebui să acopere și cauzele externe ale perioadelor de nefuncționare. Problemele legate de DNS, domeniile expirate și conflictele dintre pluginuri pot duce la scoaterea unui site web din funcțiune, chiar și atunci când mediul de găzduire este disponibil. Prezentarea generală a monitorizării disponibilității site-urilor web realizată de mybox identifică aceste elemente ca factori care trebuie incluși în analiză.
5. Auditarea calității alertelor și a responsabilității de gardă
Pentru fiecare alertă, notați condiția, serviciul afectat, gravitatea, persoana responsabilă de răspuns și acțiunea următoare. O alertă trece auditul atunci când persoana de gardă poate decide ce măsuri să ia pe baza alertei și a contextului asociat acesteia.
- Separați alertele care necesită acțiune imediată de evenimentele care necesită doar analiză.
- Verificați dacă alertele repetate sunt grupate într-un singur incident.
- Confirmați că fiecare alertă critică are un responsabil actual și o cale de escaladare.
- Analizați alertele care nu au nicio acțiune înregistrată sau care se închid în mod repetat fără a fi investigate.
- Testați alertele în timpul unei revizuiri planificate, astfel încât echipa să știe că notificarea și responsabilitatea funcționează în continuare.
Monitorizarea infrastructurii ar trebui să susțină verificările de disponibilitate, performanță și securitate, problemele fiind identificate înainte de a afecta utilizatorii. Acestea sunt obiectivele principale de monitorizare descrise în prezentarea generală a Nagios realizată de mybox.
6. Verificați perioada de păstrare, accesul și responsabilitatea pentru costuri
Perioada de păstrare definește cât timp rămâne disponibil fiecare semnal pentru investigare. Înregistrați setările de păstrare pentru metrici, jurnale, trasee și istoricul alertelor, apoi comparați-le cu perioada necesară pentru analiza incidentelor și raportarea operațională.
- Documentați cine poate citi, modifica și șterge fiecare tip de date de telemetrie.
- Utilizați grupuri de acces care corespund responsabilităților operaționale.
- Verificați dacă datele sensibile sau cu volum mare sunt disponibile pentru mai multe persoane decât este necesar.
- Înregistrați responsabilul pentru stocare, preluare, tablouri de bord, reguli de alertă și operațiuni de gardă.
- Urmăriți care servicii generează cel mai mult volum de date de telemetrie și care echipe sunt responsabile de această utilizare.
- Verificați dacă colectarea duplicată sau datele de telemetrie neutilizate cresc costurile fără a îmbunătăți detectarea sau diagnosticul.
Responsabilitatea privind costurile trebuie să fie vizibilă la nivel de serviciu și de echipă. Atunci când nicio echipă nu își asumă responsabilitatea pentru volumul de date de telemetrie, perioada de păstrare sau utilizarea interogărilor, datele în exces pot rămâne în stivă fără un factor de decizie clar. Atunci când responsabilitatea este împărțită între echipe, înregistrați punctele de predare și persoana responsabilă de rezolvarea lacunelor.
Rezultatul final al auditului
Marcați fiecare cerință ca fiind îndeplinită, parțial îndeplinită sau necesitând acțiune. O înregistrare finală utilă menționează semnalul, instrumentul, serviciul, responsabilul, tabloul de bord, alerta, setarea de păstrare, grupul de acces și responsabilul pentru costuri. Acordați prioritate mai întâi elementelor care împiedică detectarea, apoi celor care încetinesc diagnosticarea sau fac ca deciziile luate în timpul serviciului de gardă să fie neclare.