Une alerte arrive pendant que vous êtes loin de votre poste. Vous avez besoin du service concerné, de l'impact et d'une première piste, pas de centaines de lignes de logs. Un agent peut préparer ce diagnostic et vous aider à décider depuis le téléphone, à condition de distinguer alerte, hypothèse et rétablissement vérifié.
Garder le système de supervision comme source
Pacerelle apporte la conversation avec un agent ; il ne remplace pas votre collecteur de métriques, votre système d'alertes ni votre procédure d'astreinte. L'intégration doit recevoir les événements de votre supervision et connaître le responsable, le service et l'environnement concernés.
Commencez par un diagnostic en lecture seule : état du service, derniers déploiements, métriques pertinentes et extrait de logs filtré. Évitez d'envoyer des secrets, des données clients ou un journal complet dans une conversation lorsque quelques lignes contextualisées suffisent.
Transformer l'alerte en dossier de décision
Le premier message devrait contenir un identifiant d'incident stable, l'heure de détection, le symptôme, l'impact connu et le lien vers la source. Ajoutez ce qui est incertain : « cause non confirmée » est une information utile, pas une faiblesse à masquer.
- Fait : le contrôle de disponibilité échoue depuis une heure donnée.
- Contexte : un déploiement a précédé les premières erreurs.
- Hypothèse : ce déploiement peut être impliqué, sans preuve de causalité à ce stade.
- Proposition : lire les erreurs de cette version et comparer avec la précédente.
- Décision attendue : poursuivre le diagnostic ou autoriser une opération définie.
Regroupez les alertes qui concernent le même incident et mettez son état à jour. Un flux de doublons fatigue l'astreinte et favorise les décisions hâtives. À l'inverse, un regroupement trop large peut masquer deux incidents indépendants : gardez les événements d'origine consultables.
Encadrer la remédiation
Un redémarrage ou un rollback doit viser une ressource exacte : projet, service, environnement, version et paramètres. Présentez les effets attendus et les contrôles à faire ensuite. La personne doit pouvoir refuser, demander un diagnostic supplémentaire ou transmettre l'incident à un collègue.
Une confirmation mobile doit être vérifiée au moment d'exécuter l'action, avec les autorisations pour un agent SDK. Si l'état du service ou la version cible a changé entre-temps, l'ancienne décision peut ne plus correspondre. Les privilèges du compte technique doivent également être limités côté infrastructure.
Vérifier le rétablissement
Un appel de redémarrage accepté ne prouve pas que le service fonctionne. Définissez les observations qui ferment l'incident : contrôle de disponibilité réussi, taux d'erreur revenu au niveau attendu sur une période pertinente et parcours utilisateur représentatif à nouveau fonctionnel.
Si une commande dépasse son délai, interrogez son état avant de la répéter. Conservez la trace de qui a autorisé quoi, de l'opération tentée et des mesures observées ensuite. La clôture doit nommer les vérifications effectuées, pas seulement dire « résolu ».
Préparer les cas où l'agent ne peut pas agir
Testez la perte réseau, l'agent arrêté, le refus, l'absence de réponse et deux intervenants simultanés. Une absence de réponse n'autorise pas une action. Prévoyez une escalade par vos canaux d'astreinte existants et un transfert explicite de responsabilité.
Avant la première vraie alerte, répétez ce parcours dans un environnement de test avec une panne connue. Mesurez le temps pour obtenir un diagnostic exploitable et le nombre d'informations manquantes. Le guide de production aide à maintenir le processus ; le runbook de votre service reste la référence pour décider des opérations.
Tester un diagnostic sans remédiation
Connectez un agent en lecture seule et jouez un incident de test avant de lui confier des actions.