Incident SaaS B2B: ce treci în runbook pentru primele 60 de minute

Un runbook pentru un incident SaaS B2B trebuie să spună cine preia coordonarea, cum se confirmă impactul asupra clienților și cine publică următoarea actualizare. Dacă documentul începe cu o listă lungă de comenzi, dar nimeni nu știe cine poate opri un deploy sau cine răspunde unui client afectat, echipa va pierde timp exact când are nevoie de decizii rapide. Primele 60 de minute sunt un cadru de exercițiu pentru echipă, nu o promisiune că orice serviciu poate fi reparat într-o oră.

Înainte de incident: nume, acces și praguri

Scrie pe o singură pagină cine este de gardă, cine îl poate înlocui și unde se află accesul la monitorizare, infrastructură și canalul de comunicare cu clienții. Nu pune parole în runbook. Notează doar mecanismul aprobat prin care persoana autorizată obține accesul. Pentru o echipă de trei oameni, același coleg poate avea mai multe roluri; este totuși util să numești explicit cine conduce și cine trimite mesajele.

Google SRE descrie trei responsabilități distincte în răspunsul la incident: coordonare, comunicare și operare tehnică. Atlassian își atribuie un responsabil al incidentului și folosește un tichet, un canal de conversație și un document de stare pentru a păstra aceeași versiune a faptelor. Un startup nu are nevoie de toate instrumentele Atlassian; are nevoie ca fiecare persoană să găsească rapid aceleași informații.

Definește în document și ce declanșează procedura: de exemplu, fluxul central al produsului eșuează pentru clienți, datele nu pot fi accesate sau o integrare critică nu mai răspunde. O alertă izolată poate fi falsă. Confirmă cu un test al fluxului real și cu semnalele din monitorizare înainte de a declara impactul. Dacă situația ar putea implica expunerea datelor, activează separat procedura de securitate și obligațiile contractuale aplicabile; runbookul operațional singur nu le rezolvă.

Minutele 0–15: stabilește ce este afectat

Persoana care observă problema deschide o înregistrare cu ora, simptomul și sursa sesizării. Coordonatorul preia incidentul, indică un canal unic de lucru și cere un răspuns la întrebări concrete: ce funcție nu merge, pentru ce organizații, de când, în ce mediu și ce dovezi există? Un ecran de autentificare indisponibil pentru toți utilizatorii cere altă prioritate decât o eroare limitată la exportul unui singur cont.

Atlassian își evaluează incidentele după experiența clientului, amploarea afectării și momentul în care a început impactul. Folosește aceleași întrebări ca schelet de evaluare, dar stabilește propriile niveluri de severitate după produs și contracte. Nu transforma presupunerea „probabil sunt toți clienții” într-un mesaj public. Dacă numărul nu este cunoscut, notează-l ca necunoscut și verifică-l.

Minutele 15–30: alege o remediere controlată

Responsabilul tehnic compară primele erori cu ultimele schimbări: deploy, configurație, chei, integrare sau furnizor extern. Notează ipotezele separat de observații. Dacă există o revenire testată la versiunea anterioară, decide cine o autorizează și cum se verifică rezultatul. Nu schimba simultan mai multe componente fără să înregistrezi acțiunile; altfel, după restabilire nu vei ști ce a avut efect.

Runbookul ar trebui să indice linkuri către procedurile tehnice specifice, nu să copieze în el comenzi care pot deveni învechite. Pentru o integrare cu plăți, de pildă, include locul în care verifici starea furnizorului și ce operațiuni pot fi reluate fără dublare. Pentru un produs care procesează documente, verifică dacă sarcinile rămase în coadă pot fi executate din nou. Aceste verificări diferă de la un serviciu la altul și trebuie probate înaintea unui incident real.

Minutele 30–60: informează clientul și verifică revenirea

Când incidentul este confirmat, mesajul către client trebuie să spună ce funcție este afectată, ce se investighează și când urmează actualizarea. Nu promite o oră de restabilire dacă echipa nu o poate fundamenta. Procedura Atlassian recomandă să exprimi necunoscutele și să precizezi următoarea comunicare; mesajele externe sunt scurte și centrate pe impact. Dacă doar unele organizații sunt afectate, contactează-le direct prin canalul convenit și păstrează o evidență a notificărilor.

După intervenție, verifică funcția afectată din perspectiva utilizatorului și confirmă dacă datele introduse în perioada incidentului au fost procesate corect. Un grafic care a revenit la normal nu dovedește singur că fiecare client poate termina operațiunea întreruptă. Marchează separat ora la care impactul s-a încheiat și lucrările de curățare rămase. Leagă mesajul final de nivelul de serviciu promis clienților, fără să presupui că un SLA acoperă toate tipurile de incidente.

După restabilire: cronologie și măsuri verificabile

Păstrează o cronologie cu detectarea, confirmarea impactului, deciziile, mesajele și momentul restabilirii. Google SRE arată că o analiză utilă descrie impactul și cauzele, apoi atribuie acțiunilor corective un responsabil și o stare verificabilă. „Să fim mai atenți” nu este o acțiune care poate fi testată; „adăugăm alertă pentru eroarea fluxului X și verificăm-o în mediul de test” este.

Repetă exercițiul pe un scenariu plauzibil: un deploy care blochează aprobarea facturilor sau o integrare externă care întârzie sincronizarea. Măsoară timpul necesar pentru a găsi responsabilul, pentru a confirma clientul afectat și pentru a publica un mesaj corect. Când procesul de onboarding al unui client nou include un flux critic, folosește acel flux drept probă în exercițiu. Revizuiește runbookul după fiecare schimbare de produs, echipă sau contract.