Există un moment, în aproape orice organizație care a instalat un sistem de monitorizare, în care alertele încetează să mai fie citite. Nimeni nu ia decizia și nimeni nu o anunță. Canalul în care ajung notificările primește, într-o zi obișnuită, câteva zeci de mesaje, dintre care niciunul nu cere o intervenție imediată, iar echipa învață corect că nu merită deschis. Când apare, în sfârșit, mesajul care conta, acesta arată exact ca toate celelalte.
Problema nu se rezolvă prin schimbarea instrumentului. Se rezolvă prin reducerea drastică a numărului de alerte și prin schimbarea criteriului după care sunt create.
Cum se ajunge la alerte ignorate
Patru mecanisme produc, împreună, aproape tot zgomotul.
Alertarea pe cauze, nu pe simptome. Un sistem poate ceda în zeci de moduri, însă utilizatorii resimt doar câteva: serviciul răspunde cu erori, răspunde lent sau nu răspunde deloc. O regulă pentru fiecare cauză imaginabilă produce un set care crește la nesfârșit și care ratează exact defecțiunile la care nimeni nu s-a gândit dinainte.
Praguri preluate din configurația implicită. Valorile prestabilite ale unui produs de monitorizare sunt alese ca să pară rezonabile oriunde, ceea ce înseamnă că nu sunt potrivite nicăieri. Un server de baze de date care rulează constant la optzeci la sută din memorie face exact ce i s-a cerut să facă, iar alerta care se declanșează la șaptezeci descrie decizia producătorului, nu starea sistemului dumneavoastră.
Alerte pe care nu le deține nimeni. O regulă adăugată în urma unui incident de acum trei ani, de către un coleg care între timp a plecat, rămâne activă pentru că nimeni nu se simte îndreptățit să o șteargă. Fiecare alertă are nevoie de un proprietar declarat, iar dacă nu se găsește nimeni care să și-o asume, aceasta este deja concluzia.
Rutarea către un canal, nu către o persoană. Un mesaj adresat tuturor nu este adresat nimănui. Într-o echipă de patru oameni, alerta ajunsă pe un canal comun este văzută de patru persoane care presupun, fiecare în parte, că se ocupă altcineva.
Testul pe care trebuie să îl treacă orice alertă
Înainte de a adăuga o regulă nouă, merită puse trei întrebări.
Este urgentă? Dacă situația poate aștepta până a doua zi dimineață fără consecințe reale, nu este o alertă, ci o sarcină de lucru.
Este acționabilă? Dacă persoana notificată nu are nici informația, nici drepturile necesare pentru a schimba ceva, notificarea produce doar stres.
Necesită un om? Dacă răspunsul corect este de fiecare dată același, acesta poate fi automatizat, iar alerta rămâne utilă doar pentru cazul în care automatizarea eșuează.
O regulă care nu trece toate cele trei întrebări nu ar trebui să întrerupă pe nimeni. Asta nu înseamnă că informația se pierde, ci că ajunge în altă parte.
Discul la optzeci la sută nu este un incident
Un disc ocupat în proporție de optzeci la sută este o observație, nu o urgență. Ceea ce contează este panta: dacă spațiul liber scade cu un procent pe zi, aveți douăzeci de zile, iar asta este o sarcină pentru săptămâna aceasta. Dacă scade cu zece procente pe oră, aveți două ore, și abia acum este o alertă. Alertarea pe proiecția momentului în care resursa se epuizează, nu pe un procent fix, elimină o categorie întreagă de notificări inutile.
În schimb, o creștere a ratei de erori la finalizarea comenzilor este un incident din prima secundă, indiferent de cât spațiu liber există pe discuri. Utilizatorii nu percep utilizarea procesorului, ci faptul că nu pot plăti.
SLI, SLO și SLA nu sunt același lucru
Cei trei termeni sunt folosiți alternativ în discuții și înseamnă lucruri diferite.
Un SLI este o măsurătoare: proporția cererilor tratate cu succes, proporția celor servite sub o anumită durată, proporția verificărilor de disponibilitate reușite. Este un număr colectat automat.
Un SLO este ținta internă pentru acel număr, stabilită împreună cu partea de business: 99,9% dintre cereri finalizate cu succes într-o lună calendaristică.
Un SLA este angajamentul contractual, cu penalități atașate. Se stabilește mai relaxat decât SLO, tocmai pentru ca echipa să afle că are o problemă înainte ca aceasta să devină o problemă juridică.
Fereastra de măsurare schimbă complet cifra. O disponibilitate de 99,9% calculată pe o lună de treizeci de zile permite 43,2 minute de indisponibilitate. Aceeași cifră, calculată doar pe programul de lucru, adică opt ore pe zi timp de douăzeci și două de zile lucrătoare, permite 10,56 minute. Al doilea obiectiv este de patru ori mai strict, deși pe hârtie arată identic. Pentru un ERP intern, un SLO de 99,5% pe programul de lucru este adesea mai onest și mai ușor de susținut decât 99,9% declarat pe întreaga lună.
Media ascunde, percentila arată
Timpul mediu de răspuns este cea mai liniștitoare metrică dintr-un panou și cea mai puțin utilă. Dacă nouăzeci și cinci la sută dintre cereri se rezolvă în șaptezeci de milisecunde și cinci la sută în șase secunde, media rămâne sub patru sute de milisecunde, deși una din douăzeci de interacțiuni este inacceptabilă. Percentila 95 și percentila 99 arată exact utilizatorii pe care media îi diluează, iar aceștia sunt, de regulă, clienții cu cele mai multe date și cu cel mai mare volum de comenzi.
Bugetul de eroare transformă discuția
Un SLO de 99,5% pe o lună de treizeci de zile înseamnă că sunt permise 216 minute de indisponibilitate, adică trei ore și treizeci și șase de minute. Acesta este bugetul de eroare, iar utilitatea lui reală este că mută o discuție de opinie într-una aritmetică.
Când din buget au fost consumate zece minute, o migrare riscantă poate fi programată. Când au fost consumate două ore, prioritatea se schimbă de la funcționalități noi la stabilitate. Un buget consumat integral este un motiv obiectiv de a îngheța schimbările, iar un buget rămas neatins luni la rând arată că obiectivul a fost stabilit prea jos și că se cheltuiesc bani pe o fiabilitate pe care nimeni nu o cere.
Rata de consum și cele două ferestre
Alertarea utilă nu se face pe încălcarea SLO, pentru că atunci este deja târziu. Se face pe viteza cu care se consumă bugetul.
Din cele 216 minute lunare, o fereastră rapidă de o oră care consumă 2% din buget, adică aproximativ 4,3 minute, indică o defecțiune gravă în desfășurare și justifică o notificare imediată. O fereastră lentă de șase ore care consumă 5%, adică aproape 11 minute, indică o degradare lentă care nu cere trezirea nimănui noaptea, dar care va epuiza bugetul înainte de sfârșitul lunii dacă nu este tratată.
Două reguli de acest fel înlocuiesc, în practică, câteva zeci de alerte pe praguri.
Ce faceți cu tot ce nu trebuie să sune
Reducerea alertelor nu înseamnă renunțarea la informație. Înseamnă rutarea ei corectă.
Ceea ce este util pentru diagnostic, dar nu cere o acțiune imediată, ajunge pe un panou consultat în timpul unui incident. Ceea ce trebuie rezolvat, dar nu astăzi, devine un tichet cu responsabil și termen. Ceea ce arată o tendință se discută într-o revizuire săptămânală de treizeci de minute, unde se citesc consumul bugetului de eroare, alertele care s-au declanșat fals și cele care nu s-au declanșat niciodată. Primele se corectează, celelalte se șterg.
Gardă într-o echipă care nu are gardă formală
În multe companii din România, infrastructura este ținută de două sau trei persoane, iar noaptea nu este nimeni oficial de serviciu. Situația nu se rezolvă printr-o politică ambițioasă, ci prin trei decizii mici.
Prima: pentru fiecare săptămână există o singură persoană nominalizată care primește notificarea pe telefon, nu pe canalul comun, și o a doua persoană care este apelată automat dacă prima nu confirmă în cincisprezece minute. O rotație de o săptămână este suportabilă tocmai pentru că setul de alerte a fost redus la ce este cu adevărat urgent.
A doua: fiecare notificare conține un link către procedura corespunzătoare. O alertă fără procedură atașată este o alertă pe care persoana de gardă o va tăcea la a treia declanșare. Procedura nu trebuie să fie elegantă, ci să răspundă la trei lucruri: ce înseamnă, cum se verifică în două minute dacă este reală și care este primul pas de intervenție.
A treia: predarea între persoane se face în scris, chiar și când sunt doi colegi în aceeași încăpere. Trei rânduri sunt suficiente: ce s-a declanșat, ce a rămas nerezolvat și ce este programat în perioada următoare.
Analiza de după incident
Analiza care caută vinovatul produce doar oameni care raportează mai puțin. Documentul util răspunde la ce s-a întâmplat, cronologic, cât a durat detectarea, cât a durat diagnosticarea și ce anume din sistem a permis ca greșeala să aibă efect. Rezultatul nu este o promisiune de atenție sporită, ci una sau două modificări concrete, cu responsabil și termen. O singură măsură implementată valorează mai mult decât zece recomandări scrise.
Cardinalitate, retenție și date personale
Există două limite practice în ceea ce puteți măsura.
Prima este cardinalitatea. O metrică de tip contor cu trei etichete, să spunem trei sute de rute, douăsprezece coduri de stare și opt instanțe, generează 28 800 de serii temporale distincte. Adăugarea unei etichete cu identificatorul clientului, pentru două mii de clienți, duce numărul la peste cincizeci și șapte de milioane și oprește sistemul de monitorizare. Identificatorii unici aparțin jurnalelor sau trasării, nu etichetelor unei metrici.
A doua este retenția. Patruzeci de gigaocteți de jurnale pe zi, păstrați nouăzeci de zile în stocare rapidă, înseamnă 3,6 teraocteți care se plătesc lunar. Retenția diferențiată, cu câteva zile în stocare rapidă și restul în arhivă ieftină, rezolvă cazul obișnuit fără să compromită cerințele de jurnalizare.
Un aspect tratat prea rar ca fiind al echipei tehnice: jurnalele conțin aproape întotdeauna date cu caracter personal. Adrese IP, identificatori de utilizator, adrese de e-mail apărute în parametrii unei cereri, uneori conținut trimis prin formulare. Din perspectiva GDPR, acestea sunt date personale prelucrate fără ca cineva să fi decis explicit acest lucru. Perioada de păstrare trebuie stabilită și documentată, accesul la platforma de jurnale trebuie limitat la persoanele care au nevoie de el, iar câmpurile sensibile merită eliminate la colectare, nu căutate ulterior.
Ce puteți face săptămâna aceasta
Exportați lista alertelor declanșate în ultimele treizeci de zile și marcați, pentru fiecare, dacă cineva a făcut efectiv ceva. Regulile care nu au produs nicio acțiune se dezactivează în aceeași zi. Apoi alegeți un singur serviciu important, stabiliți-i un SLI și un SLO pe programul de lucru și înlocuiți alertele lui pe praguri cu două reguli de rată de consum.
Proiectăm și calibrăm astfel de seturi de alerte în cadrul serviciului de monitorizare și observabilitate. Dacă cineva trebuie să răspundă efectiv la trei dimineața, aceasta este partea de servicii administrate, iar distincția merită făcută explicit înainte de a semna un SLA.