Post-mortem

Après une panne, il faut écrire ce qui s'est passé : pour l'équipe, pour un client, pour la prochaine fois. PostShip a déjà la chronologie — le premier échec, les confirmations, le déploiement qui précède, le retour au vert — et une cause probable. Le post-mortem les met dans un document en Markdown, à coller dans un wiki ou un ticket, ou à partager par un lien non listé que vous pouvez retirer. Ce que le client lit est exactement ce que l'équipe a lu.

Ce que le document contient

Heures en UTC, annoncées dans l'en-tête de la chronologie, parce que ce sont celles des journaux qu'on ira lire. Pas d'emoji : ce document est lu à froid.

• L'en-tête : « Post-mortem — » suivi du résumé de l'incident ; le projet et son adresse ; début, fin (ou « en cours ») et durée.
• Impact : l'URL touchée, l'erreur relevée, et les autres cibles au même moment — « aucune des 7 autres en échec, la panne est propre à cette page » ou « 3 sur 7 en échec au même moment ».
• Chronologie (UTC) : une ligne par événement, avec l'heure, le délai relatif au début (« 3 min avant », « au moment de la panne », « 1 h 12 min après ») et le texte : premier échec, déploiement précédent, prise en charge, escalade, retour au vert.
• Cause probable : l'hypothèse principale en gras avec son niveau de confiance (forte, moyenne, faible) et ses preuves, puis les autres hypothèses retenues. Les causes possibles : Déploiement, Fournisseur en incident, Changement DNS, Certificat, Réseau régional, Script tiers, Saturation, Panne du site entier, Maintenance annoncée, Cause inconnue. Les règles qui les départagent sont sur la page Cause probable.
• Ce que PostShip n'a pas vu : la réserve, toujours. PostShip observe depuis l'extérieur ; les journaux du serveur, les métriques internes et les changements de configuration hors déploiement ne sont pas dans cette chronologie. Quand la confiance est faible ou la cause inconnue, le document le dit en toutes lettres : ce qui précède est une corrélation faible, pas une explication.
• Prise en charge : qui a pris l'incident, combien de temps après le début, et l'escalade à toute l'équipe si elle a eu lieu — ou « Personne n'a pris en charge cet incident. »

Régler

Projet → Incidents → l'incident. Sous la chronologie, la carte Post-mortem :

1. Copier : le bouton copie le Markdown entier (la carte affiche son nombre de lignes). Collez-le dans votre wiki, votre ticket, votre canal.
2. Partager par un lien : cochez la case, puis Enregistrer. Le lien postship.fr/pm/<jeton> apparaît avec un bouton de copie. La page publique porte le même contenu, le titre « Post-mortem · nom du projet », et « Généré par PostShip · heures en UTC » en pied.
3. Retirer : décochez, Enregistrer. Le lien répond désormais « introuvable ».

Un jeton neuf à chaque partage : retirer puis remettre change le lien, et l'ancien ne rouvre pas. C'est le contraire de la carte de ship, dont le lien est fait pour durer — un post-mortem partagé à un client pour une panne donnée n'a pas vocation à rester ouvert. La page est interdite aux robots.

Un membre en lecture seule peut copier le Markdown mais ne peut pas partager ni retirer le lien.

Ce qui déclenche une alerte

Rien : le post-mortem est un document, il ne surveille pas. Ce qui le nourrit : l'incident lui-même, l'acquittement, l'escalade, et les signaux que la cause probable a relevés.

Limites et plans

Disponible sur tous les plans, pour chaque incident. Les signaux relus pour la cause probable viennent de l'historique du projet, donc de la fenêtre de rétention du plan.

Dépannage

Pourquoi la cause probable est-elle « inconnue » ?

Aucun signal décisif autour du début de la panne : pas de déploiement récent, pas de dérive DNS, pas de fournisseur en incident, pas d'autre cible en échec. Le document dit alors que les journaux du serveur autour de l'heure du début en diront plus. C'est une réponse honnête, pas un défaut.

Pourquoi le lien partagé ne fonctionne-t-il plus ?

Quelqu'un a décoché « Partager par un lien », ou a décoché puis recoché : le jeton change à chaque partage. Copiez le lien affiché maintenant sur la page de l'incident.

Pourquoi les heures du document ne sont-elles pas les miennes ?

Le Markdown et la page publique sont en UTC, pour correspondre aux journaux de votre serveur et de votre hébergeur. Dans l'application, la chronologie de l'incident est affichée dans votre fuseau.