Aller au contenu

Incidents et post-mortems

Quand le quorum confirme une panne, l’incident s’ouvre, et son début est fixé à la seconde près : celle de la confirmation. À partir de là, chaque événement s’inscrit sur la chronologie, d’abord les votes des régions, puis les notifications, l’acquittement, le rétablissement. C’est cette chronologie unique que lisent votre page de statut et vos preuves SLA.

Tout ce que vos clients remarquent ne vient pas forcément d’une sonde en échec. Vous pouvez donc ouvrir un incident à la main, avec ou sans monitor rattaché, le retravailler, puis le publier délibérément sur les pages de statut de votre choix. Rien ne part tout seul. Inclus à partir de sentinel, comme la conduite d’incident en général.

Le post-mortem s’accroche à l’incident : impact, cause racine, enseignements, plus les actions, chacune avec un responsable. Le passage du brouillon à la publication est un geste délibéré, en interne ou en public. Chaque post-mortem a sa propre adresse dans l’application et peut être lié depuis un ticket ou un rapport.

Les changements apparaissent dans l’historique des versions avec la personne, l’instant et l’action, par exemple enregistrer, publier ou restaurer. Restaurer un état antérieur crée une nouvelle entrée et le journal d’activité indique les champs concernés. Cet historique est attribuable et réversible ; ce n’est pas un stockage immuable ni protégé contre toute manipulation. La durée propre à ces artefacts fait partie de la revue produit et contractuelle en cours ; confirmez-la avant de vous appuyer sur une durée.

Qui acquitte prend l’incident : l’escalade s’arrête, les autres appareils se taisent, et les rappels ne visent plus que cette personne. L’horodatage de l’acquittement fait partie du registre. C’est précisément pour cela que la chaîne d’escalade se termine par un incident acquitté, pas par le silence.