Echipa dvs. de ingineri se confruntă cu oboseală alertă? Pune aceste 8 întrebări

Oboseala de alertă este o problemă comună în rândul echipelor de inginerie care se ocupă de operațiuni și întrețin infrastructura.

Problema provine de obicei dintr-o abordare întâmplătoare a scrierii alertelor pe măsură ce echipele cresc și încep să folosească mai multă infrastructură de complexitate crescândă. Acest lucru este destul de normal – pe măsură ce o companie sau o echipă se dezvoltă, adesea este nevoie de timp pentru ca o cultură a observabilității și practici solide de alertă să prindă contur.

Este ușor să creați alerte prea sensibile, prea zgomotoase și prea precaute. La început, totul pare demn de alertă pur și simplu pentru că este mai bine să fii atent și să maximizezi semnalul de producție în fazele incipiente ale unui produs.

„Pe măsură ce numărul și complexitatea caracteristicilor și infrastructurii crește, îmbunătățirea alertelor este de obicei mult mai jos din lista de priorități”

Desigur, această abordare nu se extinde foarte bine, dar pe măsură ce numărul și complexitatea caracteristicilor și infrastructurii cresc, îmbunătățirea alertelor este de obicei foarte jos din lista de priorități. Rezultatul este o mulțime de alerte semi-semnificative, zgomot, schimbare de context și multitasking pentru inginerul de gardă. În cazuri extreme, colegii de echipă se epuizează, alertele sunt ignorate, iar echipa ta de gardă trece de la îmbunătățirea calității serviciului la stingerea constantă a incendiilor, fără un impact semnificativ.

Ca toate companiile, Intercom nu este imun la aceste ineficiențe. Așa că am conceput un proces relativ ușor pentru a combate oboseala alertă.

Cum ne gândim la strategia de alertă

Conceptul de „disciplină de alertă” este esențial pentru obținerea sub control a alertelor. La fel ca funcțiile, alertele și strategia de alertă ar trebui abordate într-o manieră deliberată și structurată. Spre deosebire de funcționarea funcțiilor, însă, nu este ceva care poate fi bine planificat în avans.

La urma urmei, este foarte puțin probabil să poți prezice starea de funcționare și zgomotul noii caracteristici înainte de a o expedia. Trebuie să monitorizați alertele într-un mod regulat, planificat, astfel încât munca de alertare să nu ajungă la niveluri nesustenabile.

8 întrebări de pus atunci când evaluezi alertele echipei tale

Am introdus sesiuni regulate de examinare a alertelor pentru echipele care se confruntă cu alerte frecvente. Acestea au avut loc inițial o dată – sau de mai multe ori – pe ciclu de inginerie de șase săptămâni, dar au devenit mai distanțate pe măsură ce starea alertelor și a monitoarelor s-a îmbunătățit la un nivel mai ușor de gestionat.

Fiecare sesiune de examinare a alertelor începe cu o listă ordonată a alertelor care au fost declanșate în perioada anterioară, ordonate în funcție de frecvența declanșării lor. Folosim platforma PagerDuty ca sursă de alertă, iar funcțiile sale de analiză ne oferă informațiile de care avem nevoie pentru a defalca frecvența alertelor și răspunsul. Alertele care contribuie cel mai mult la zgomotul general (adică focul cel mai frecvent) sunt revizuite mai întâi.

Fiecare alertă este apoi trecută printr-o listă de întrebări:

1. Mai este relevantă alerta?

Orice alerte declanșate de sistemele învechite sau neîntreținute nu ar trebui să deranjeze inginerul de gardă și ar trebui eliminate imediat.

2. Este alerta acționabilă?

Dacă un inginer de gardă primește alerta, poate face ceva chiar acum pentru a remedia sau a îmbunătăți cauza de bază? Dacă alerta nu este acționabilă și utilă, ar trebui eliminată. Un rezumat săptămânal al problemelor sau al degradărilor de performanță ar putea fi un loc mai bun pentru informațiile din alertă.

3. Informațiile din alertă sunt imediat utile chiar dacă nu pot fi acționate?

Putem împărți informațiile de alertă în două categorii mari.

• Semnale: Aceste alerte avertizează că un sistem funcționează la limita sa, dar nu înseamnă neapărat că serviciul este afectat. Un exemplu ar fi unul dintre serverele dvs. care rulează la 100% CPU. Dacă serviciul încă funcționează bine, ar trebui să petreacă timp prețios investigând? La urma urmei, serverul tău funcționează doar la cel mai bun raport lucru-preț!
• Simptome: Aceste alerte se declanșează atunci când experiența clientului este afectată. Un exemplu aici ar fi numărul de erori HTTP 5XX pe care serviciul dvs. le returnează apelanților.

Aceste două categorii funcționează cel mai bine în tandem. O persoană de gardă ar trebui să reacționeze și să depaneze simptomele și să privească semnalele doar ca pe o sursă suplimentară de informații.

4. Dacă alerta poate fi acționată și de paginare, trebuie tratată imediat?

Dacă problema nu trebuie rezolvată imediat, nu ar trebui să trezească pe nimeni în miezul nopții. Echipa ar trebui să decidă modalități alternative de afișare a informațiilor din alertă în aceste situații, de exemplu, o notificare Slack sau un tablou de bord sau o sarcină deschisă într-un mecanism de urmărire a problemelor.

5. Dacă este posibil, există un runbook sau un link de depanare? Sunt pașii suficient de clari pentru a fi urmați de orice inginer din echipă?

Una dintre cele mai proaste experiențe de a fi un inginer de gardă – în special unul nou – este cantitatea de cunoștințe tribale care se acumulează în echipele de inginerie de-a lungul timpului. Este intimidant să sari la un incident de producție de mare severitate doar pentru a realiza că nu ești familiarizat cu acea zonă a sistemului și că nu este bine documentat.

„ Păstrarea informațiilor de depanare a alertelor clare, simple și actualizate contribuie în mare măsură la reducerea timpului mediu pentru atenuarea și recuperarea unui incident ”

Chiar dacă aveți expertiză, este posibil să fi scris codul cu atâta timp în urmă încât nu vă amintiți clar ce ar trebui să facă. Păstrarea informațiilor de depanare a alertelor clare, simple și actualizate contribuie în mare măsură la reducerea timpului mediu pentru atenuarea și recuperarea unui incident (MTTM și MTTR).

6. Dacă este posibil, există o legătură cu tabloul de bord și arată toate cauzele potențiale cunoscute?

Tablourile de bord sunt o modalitate excelentă de a scoate la suprafață cantități mari de informații de sistem simultan, ceea ce înseamnă că inginerii nu trebuie să caute în diferite jurnale, valori și urme pentru a afla cauza unei probleme. Agregarea datelor într-un tablou de bord și furnizarea linkului ca parte a alertei permite o depanare mult mai rapidă.

7. Este alerta prea sensibilă sau nu este suficient de specifică? Ar beneficia de desensibilizare sau de modificarea domeniului de aplicare?

Multe alerte sunt utile, dar calibrate greșit. Ar putea fi fie prea largi și să nu tragă de fiecare dată când ar trebui, fie prea specifici și să tragă de mai multe ori pentru același incident, ceea ce doar adaugă la zgomot.

8. În sfârșit, o ființă umană trebuie să facă remedierea?

Într-un fel, tot codul computerizat automatizează ceva ce poate face un om. Deci, de ce să nu automatizăm remedierea problemelor care declanșează alertele? În timp ce anumite alerte mai complicate ar fi greu de remediat automat, cum ar fi o eroare în cod sau o problemă de performanță în sistem, acțiunile automate pot rezolva multe probleme comune.

Acest lucru este valabil mai ales dacă rulați pe o platformă cloud precum AWS și puteți furniza infrastructură fără a vă face griji cu privire la solicitarea de hardware suplimentar. De exemplu, dacă un nod din clusterul dvs. de căutare arată discuri defectuoase, de ce să nu-l înlocuiți automat? Dacă serviciul are resurse de calcul reduse din cauza creșterii traficului, de ce să nu extindeți și să adăugați VM sau containere suplimentare? Detaliile remedierii pot fi apoi trimise echipei prin canale fără alertă, astfel încât acestea să poată revizui după bunul plac.

Ai răspuns „nu” la vreuna dintre aceste întrebări?

Răspunsul cu „nu” la oricare dintre aceste întrebări ridică o sarcină de mare prioritate pentru echipă de a lucra pentru a îmbunătăți alerta – indiferent dacă aceasta înseamnă oprirea acesteia de la paginare, îmbunătățirea pașilor de depanare, automatizarea acesteia sau pur și simplu remedierea problemei de bază ale sistemului.

Cheia abordării este să faceți acest lucru într-un mod regulat și planificat. Menține nivelurile de zgomot scăzute, iar operațiunile și inginerii de gardă fericiți și productivi. Aceștia se pot concentra pe îmbunătățirea calității și pe furnizarea de impact în loc de stingerea incendiilor.

Ești interesat de modul în care lucrăm la Intercom? Ne-ar plăcea să vorbim cu tine – vezi rolurile noastre deschise de inginerie.