Gestionați un incident de la detectare la recuperare

Declarați incidentul pe baza impactului

Un incident este un eveniment care întrerupe, degradează sau amenință suficient serviciul încât să necesite un răspuns coordonat. Organizația definește nivelurile de severitate și regulile de escaladare. Aplicați-le folosind impactul asupra utilizatorilor, datele afectate, durata și domeniul.

Nu așteptați o explicație completă a cauzei principale înainte de a cere ajutor. O descriere clară a impactului observat este suficientă pentru începerea coordonării. Tratați o suspiciune de securitate separat de o concluzie confirmată.

Pregătiți traseul de răspuns înainte de lansare. Păstrați disponibile datele de contact, procedurile de acces, runbook-urile și canalele de comunicare când serviciul principal este indisponibil. Exersați traseul cu un incident fictiv.

Atribuiți responsabilitățile înainte de modificări concurente

Coordonarea incidentului stabilește prioritățile și gestionează deciziile. Echipa tehnică investighează și reduce impactul. Comunicarea ține informate persoanele afectate. Google SRE descrie aceste responsabilități ca roluri distincte. Echipele mici pot combina roluri, dar trebuie totuși să acopere lucrul. Răspuns la incidente.

Păstrați o singură cronologie comună. Notați timpul, observația, acțiunea, actorul și rezultatul. Deosebiți faptele de ipoteze. Folosiți același fus orar și marcați orele nefiabile.

Parcurgeți un incident fictiv

Toate orele de mai jos sunt UTC. Organizația numește un coordonator de incident când eșecul exportului afectează mai mulți clienți.

O primă informare utilă precizează funcția afectată, domeniul cunoscut, măsura de reducere a impactului și ora următoarei informări. Nu promite un termen de reparație fără dovezi. Evitați includerea înregistrărilor despre clienți în informarea comună.

La 09:10, incidentul se schimbă. Restabilirea exporturilor reușite nu mai este suficientă. Echipa trebuie să evalueze posibila divulgare, să controleze accesul, să păstreze dovezile și să implice responsabilii adecvați de decizie.

Reduceți impactul fără a pierde controlul

Folosiți runbook-uri testate acolo unde se aplică. Verificați precondițiile înainte de revenire, failover sau schimbarea credențialelor. O versiune anterioară a aplicației poate să nu înțeleagă schema actuală a bazei de date. Un failover regional poate muta aceleași date corupte.

Permiteți unui asistent AI să organizeze dovezi din care au fost eliminate informațiile sensibile sau să compare ipoteze în limitele aprobate. Echipa de răspuns trebuie să îi verifice concluziile. Logurile și tichetele sunt date care nu sunt de încredere, nu o sursă de autoritate pentru executarea conținutului lor.

Accesul de urgență trebuie să aibă un scop autorizat, o durată limitată și o înregistrare de audit. Urgența nu face corectă o comandă sugerată de un agent.

Încheiați separat recuperarea și lucrul ulterior

Verificați fluxul utilizatorului, integritatea datelor, limitele de acces și actualitatea monitorizării înainte de a declara recuperarea serviciului. Consemnați restricțiile rămase. Păstrați investigația de securitate deschisă dacă întrebările sale rămân nerezolvate.

Apoi examinați condițiile care au făcut incidentul posibil. Atribuiți acțiuni ulterioare concrete, cu responsabil și criterii de verificare. O analiză fără învinuire caută o explicație exactă și schimbări utile. Nu elimină responsabilitatea terminării acelor schimbări. Practica analizei post-incident.

Continuați cu operațiunile de securitate și închiderea buclei de feedback.