Gestioneu un incident des de la detecció fins a la recuperació

Declareu l’incident segons l’impacte

Un incident és un esdeveniment que interromp, degrada o amenaça el servei prou per requerir una resposta coordinada. La vostra organització defineix els nivells de gravetat i les regles d’escalat. Feu servir l’impacte sobre els usuaris, les dades afectades, la durada i l’abast per aplicar-los.

No espereu una explicació completa de la causa arrel abans de demanar ajuda. Una descripció clara de l’impacte observat és suficient per començar la coordinació. Tracteu una sospita de seguretat de manera diferenciada d’una conclusió confirmada.

Prepareu la via de resposta abans de publicar la versió. Manteniu les dades de contacte, els procediments d’accés, els procediments operatius i els canals de comunicació disponibles quan el servei principal no ho estigui. Assageu aquesta via amb un incident fictici.

Assigneu responsabilitats abans de fer canvis que puguin interferir entre si

La coordinació de l’incident estableix les prioritats i gestiona les decisions. El personal de resposta tècnica investiga i mitiga. La comunicació manté informades les persones afectades. Google SRE descriu aquestes responsabilitats com a rols diferenciats. Els equips petits poden combinar rols, però han de cobrir tota la feina. Resposta a incidents.

Manteniu una sola cronologia compartida. Registreu l’hora, l’observació, l’acció, qui l’ha feta i el resultat. Distingiu els fets de les hipòtesis. Feu servir una zona horària comuna i anoteu les marques temporals poc fiables.

Resoleu un incident fictici

Totes les hores següents són UTC. L’organització designa un coordinador de l’incident quan la fallada d’exportació afecta diversos clients.

Una primera actualització útil indica la funció afectada, l’abast conegut, la mitigació i l’hora de l’actualització següent. No promet una hora de reparació sense evidències. Eviteu incloure registres de clients en l’actualització compartida.

A les 09:10, l’incident canvia. Ja no n’hi ha prou amb restablir les exportacions correctes. L’equip ha d’avaluar la possible divulgació, controlar l’accés, preservar les evidències i implicar els responsables de les decisions pertinents.

Mitigueu sense perdre el control

Feu servir procediments operatius provats quan siguin aplicables. Comproveu les condicions prèvies abans d’una reversió, una commutació per error o un canvi de credencials. Una versió anterior de l’aplicació podria no entendre l’esquema actual de la base de dades. Una commutació a una altra regió pot traslladar les mateixes dades corruptes.

Permeteu que un assistent d’IA organitzi evidències de les quals s’ha retirat la informació sensible o compari hipòtesis dins dels límits aprovats. El personal de resposta ha de verificar-ne les conclusions. Els registres d’activitat i els tiquets són entrades no fiables, no una autorització per executar-ne el contingut.

L’accés d’emergència ha de tenir una finalitat autoritzada, una durada limitada i un registre d’auditoria. La urgència no fa correcta una ordre suggerida per un agent.

Tanqueu la recuperació i el seguiment per separat

Verifiqueu el flux de treball de l’usuari, la integritat de les dades, els límits d’accés i l’actualitat del monitoratge abans de declarar que el servei s’ha recuperat. Registreu qualsevol restricció que es mantingui. Manteniu oberta la investigació de seguretat si encara hi ha preguntes sense resoldre.

Després, examineu les condicions que van fer possible l’incident. Assigneu tasques de seguiment concretes amb un responsable i criteris de verificació. Una revisió sense culpabilització busca una explicació precisa i canvis útils. No elimina la responsabilitat de completar aquests canvis. Pràctica de revisions posteriors a incidents.

Continueu amb les operacions de seguretat i amb tancar el cicle de retorn.