Quand tu m'appelles pour une panne

Je commence par confirmer exactement ce qui est touché : quel service, quelle machine. Une alerte floue oblige à redemander et fait perdre du temps. Ce que tu gagnes à envoyer dès le départ : le service touché, depuis quand, ce que tu vois et ce que tu as déjà tenté.

Tu reçois un accusé de réception rapide. Aucun délai n'est promis hors garantie souscrite.

Je date le début réel de la panne dans le monitoring et dans les journaux. Il est souvent antérieur au signalement. Sur un incident réel, la panne a commencé à 5h30 et n'a été signalée qu'à 7h21.

Si une coupure chez l'hébergeur ou chez l'opérateur est plausible, je vérifie son état avant de toucher quoi que ce soit.

Je vérifie que la dernière sauvegarde du service a réussi avant de tenter un redémarrage. Ensuite je relève, en lecture seule et avant toute écriture, le journal système, le journal du service, le journal d'accès, l'historique des paquets et des mises à jour récentes. Je ne reprends pas le diagnostic du client tel quel. Je le refais.

Ne redémarre pas tout toi-même avant d'appeler. Un redémarrage fait avant le signalement peut masquer le symptôme d'origine et en ajouter un second. Et cinq redémarrages de services différents à la suite, quand ça repart, personne ne sait lequel a réglé quoi. Si la machine ne répond plus du tout, je passe par un accès hors bande, la console, plutôt que de redémarrer à l'aveugle.

J'isole la cause avant d'agir. Dans un incident, le client a redémarré le serveur web et la base de données, sans effet : la cause se trouvait un niveau plus bas, dans l'isolation du compte.

Le correctif doit être le moins invasif possible. Dans un autre cas, une bibliothèque système a été réparée pendant que le serveur web tournait, sans coupure.

Je contrôle ensuite le reste du parc que j'administre : la même faille est cherchée sur les autres machines. Ailleurs, quatre autres serveurs portaient le même défaut, corrigés avant qu'il ne se déclenche.

Le compte rendu sépare ce qui est mesuré, ce qui est déduit et ce qui reste ouvert. Une hypothèse s'écrit comme une hypothèse, tant qu'elle n'est pas établie.

La clôture est écrite le jour de la résolution. Elle contient le début réel de la panne, la cause en clair, ce qui a été fait, et le résultat du contrôle sur le reste du parc. J'attends ensuite ta confirmation explicite que tout est revenu. Si une prévention a du sens, je la propose à ce moment-là.

Si tu proposes une mauvaise prévention, je la refuse en montrant le risque. Exemple vécu : la suspension des mises à jour automatiques le week-end. Elle a été refusée, parce que ces mêmes mises à jour avaient protégé une partie du parc lors d'une faille critique exploitée un week-end.

Une intervention hors des heures du contrat est annoncée par écrit, avec la mention claire qu'elle est facturée ou non.