Lorsque la personne responsable d’une application change, il ne suffit pas de transmettre une liste de tâches ou d’envoyer des liens dans un canal de discussion. La personne qui prend l’astreinte doit comprendre quel service est touché, quelles décisions restent en suspens, ce qu’elle peut faire et comment confirmer qu’une intervention a fonctionné. Sans ce contexte, l’équipe perd du temps à reconstituer les faits et risque de répéter des actions ou de laisser des risques sans réponse.
Le passage de relais d’astreinte technique pour des applications PHP doit prendre la forme d’un résumé opérationnel, à jour et orienté vers la prochaine action. Il ne remplace ni le système de gestion des incidents, ni le gestionnaire de tâches, ni les runbooks : il relie ces ressources et explique comment les interpréter pendant la période de responsabilité à venir.
Définir ce qui doit être transmis à la personne qui prend l’astreinte
Avant de convenir d’un format, déterminez quelles décisions la personne d’astreinte peut prendre et quelles situations nécessitent de faire appel à une autre fonction. Le périmètre peut inclure la surveillance des alertes, le diagnostic initial, une mesure d’atténuation réversible et la coordination d’un rétablissement. Les changements destructifs, les migrations de données ou les décisions relatives à la communication externe peuvent nécessiter une autorisation explicite.
Le passage de relais doit rendre visibles au minimum cinq éléments : le service concerné, son état actuel, l’impact connu, la personne responsable de la prochaine action et le critère de vérification du résultat. Si l’un de ces éléments manque, la personne qui prend l’astreinte peut savoir qu’il y a un problème, sans pour autant savoir comment avancer.
Il convient également de préciser quand le document est mis à jour, quel fuseau horaire l’équipe utilise et par quel canal une urgence est signalée. L’heure de la dernière observation compte : une métrique ou un état d’incident sans horodatage peut inciter à intervenir sur une situation déjà résolue.
Consigner les incidents et les tâches sans dupliquer le suivi
Le registre de passage de relais ne doit pas devenir une autre file de travail. Conservez chaque incident dans le système qui le gère déjà et indiquez dans le résumé son identifiant, son lien, son état et la prochaine étape. Cela évite que deux copies divergent lorsqu’une personne met à jour l’une d’elles et oublie l’autre.
Pour un incident ouvert, résumez les faits nécessaires à sa prise en charge :
- Service et environnement : application PHP, composant touché et indication précisant si le problème survient en production, en staging ou dans un autre environnement.
- Impact observé : fonctionnalité dégradée, utilisateurs touchés si cette information est connue et périmètre qui reste à confirmer.
- État et chronologie : heure de début approximative, changements importants et dernière vérification, avec le fuseau horaire.
- Actions effectuées : changements réalisés et résultats observés ; distinguez les faits des hypothèses.
- Prochaine action et responsable : tâche précise, personne ou rôle responsable et moment de la vérification.
- Escalade : condition nécessitant de prévenir une autre personne ou équipe.
Pour les tâches en attente qui ne sont pas des incidents, le ticket peut suffire. Ne les mentionnez dans le passage de relais que si elles concernent la personne qui prend l’astreinte : par exemple, si elles ont une échéance pendant son tour ou conditionnent une intervention opérationnelle.
Associer les runbooks à des conditions et à des vérifications
Un lien vers un runbook n’explique ni quand l’utiliser ni quel résultat attendre. Ajoutez une phrase décrivant le signal qui déclenche la procédure et les limites de son application. Par exemple : « À utiliser si les vérifications d’état échouent en production ; ne redémarrez pas le processus avant d’avoir confirmé qu’aucune migration n’est en cours. » Les détails doivent correspondre au système réel de l’équipe, et non reposer sur une supposition.
La procédure doit indiquer les autorisations nécessaires, les étapes de diagnostic, l’action sûre, la méthode de validation du rétablissement et la voie d’escalade si la vérification échoue. Dans une application PHP, elle peut faire référence aux journaux d’erreurs, à l’état des processus, aux métriques, aux files d’attente ou aux dépendances externes, à condition que ces signaux existent et soient accessibles à la personne d’astreinte.
Si une instruction dépend d’une configuration, d’une version ou d’une infrastructure précise, documentez cette limite. N’incluez pas d’identifiants ni de secrets dans le passage de relais : renvoyez vers les mécanismes autorisés pour obtenir l’accès. Un runbook obsolète ou exigeant des autorisations que personne ne possède est un risque, pas une aide.
Expliciter les risques, les dépendances et les limites du rétablissement
Consignez les risques connus susceptibles de modifier la réponse : une dépendance dégradée, une tâche planifiée suspendue, une solution temporaire ou un changement récent encore sous surveillance. Pour chaque risque, indiquez quel signal le confirmerait et quelle action entreprendre. Si la cause n’est pas établie, qualifiez-la d’hypothèse ; ne présentez pas une corrélation comme un diagnostic définitif.
Les limites du rétablissement doivent également être claires. Quelles actions sont réversibles ? Quelle opération risque d’affecter les données ? Existe-t-il une sauvegarde dont la restauration a été vérifiée, ou seulement une politique de sauvegarde ? Qui autorise une restauration ou un changement de configuration ? Distinguer une capacité documentée d’une capacité vérifiée évite de susciter une confiance injustifiée.
Dans les systèmes composés de plusieurs éléments, indiquez les dépendances et les équipes à contacter, avec les références internes pertinentes. Ne partez pas du principe que la personne qui prend l’astreinte sait si une panne d’API externe, de base de données ou de file d’attente explique le symptôme observé.
Utiliser un gabarit concis et vérifier qu’il permet d’agir
Le gabarit doit être assez concis pour être tenu à jour pendant un tour d’astreinte et assez précis pour guider une décision. Un exemple hypothétique peut illustrer le format, mais les champs doivent être remplis avec des données observées pour chaque service.
Service et environnement : [application / composant / environnement] Période d’astreinte : [début et fin, avec fuseau horaire] État actuel : [normal / dégradé / incident ouvert] Impact observé : [faits et périmètre connu] Incidents : [identifiant, état et référence] Dernière vérification : [heure, signal et résultat] Actions effectuées : [changements et résultat observé] Prochaine action : [étape précise, responsable et délai] Risques ou hypothèses : [signal, limite et moyen de les distinguer] Runbook applicable : [référence et condition d’utilisation] Escalade : [à qui et sous quelle condition] Décisions en suspens : [décision, responsable et date de vérification]
Par exemple, une équipe pourrait noter qu’une alerte de file d’attente reste active, renvoyer vers l’incident existant et confier la vérification de son évolution au rôle entrant. Elle doit indiquer l’heure de la dernière observation et le seuil ou le signal qui confirmerait le retour à la normale. Il n’est pas nécessaire de recopier chaque événement du ticket : il faut indiquer le point de départ et la prochaine vérification.
Vérifier le passage de relais du point de vue de la personne qui prend l’astreinte
Un document complet ne garantit pas qu’il soit exploitable. Le test pratique consiste à vérifier que la personne qui prend l’astreinte peut expliquer l’état de la situation, trouver la source à jour, identifier sa première action et savoir comment en vérifier le résultat, sans dépendre de la mémoire de la personne qui transmet. Si elle doit demander à plusieurs reprises des précisions sur les mêmes points, le format ou le runbook ne répond pas au besoin.
Examinez régulièrement les passages de relais pour repérer les champs vides, les liens rompus, les responsabilités ambiguës ou les instructions que personne n’a validées. Après un incident, intégrez les enseignements au runbook ou au processus adapté, plutôt que de transformer chaque passage de relais en archive historique difficile à consulter.
Le critère final est opérationnel : les informations distinguent les faits des hypothèses, indiquent si elles sont toujours d’actualité, attribuent une prochaine action et définissent comment escalader et vérifier. Ainsi, le changement d’astreinte préserve le contexte sans créer un système parallèle de documentation ou de suivi.
