Un processus d’escalade dit qui tient l’incident, au bout de combien de minutes il le passe, et à qui. Sans ça, tout le monde regarde le même 502 ou personne ne le regarde. Trois niveaux suffisent pour une agence : qualification, correction applicative, hébergeur. Le client n’est pas un niveau technique. Il est informé en parallèle, par une seule personne, aux heures déjà convenues.
Les trois niveaux
| Niveau | Qui | Délai pour agir ou passer | Livrable avant de passer |
|---|---|---|---|
| 1. Qualification | Exploitation, personne d’astreinte ou du matin | 15 minutes après le constat | URL, code, périmètre (une URL ou tout le vhost), dernier déploiement oui ou non |
| 2. Correction | Développeur du site, ou la personne qui a le droit de revenir en arrière | 30 minutes après la passation | Une hypothèse testée, ou un retour arrière lancé |
| 3. Hébergeur | Le compte d’hébergement, via le lien nommé | Dès que le niveau 2 montre que la machine ne répond pas, ou que les journaux sont hors de portée | Ticket avec heure, URL, code, ce qui a été écarté |
Les délais ci-dessus sont un point de départ à écrire dans votre fiche, pas une norme externe. S’ils contredisent le contrat client, c’est le contrat qui gagne : l’escalade interne doit finir avant la fin du délai promis au client, pas après.
Monter d’un cran
On monte dans deux cas seulement. Le délai de la ligne est atteint. Ou la personne actuelle n’a pas le moyen d’agir : pas d’accès SSH, pas le droit de restaurer, pas la compétence sur ce type de panne. Elle le dit dans le ticket en une phrase et elle désigne le nom du niveau suivant. Elle ne reste pas en copie silencieuse en espérant que l’autre a vu.
On ne monte pas parce que le client a rappelé, si la qualification est déjà faite et que le délai interne n’est pas atteint. Le rappel se traite dans le message client. Monter d’un cran à chaque appel disperse les mêmes personnes sur les mêmes gestes.
On ne saute pas du niveau 1 au ticket hébergeur si un déploiement a eu lieu il y a vingt minutes et que personne n’a tenté le retour arrière. L’hébergeur renverra le ticket. Le critère est dans la fiche : déploiement récent d’abord, hébergeur ensuite.
Ce que vous collez dans le ticket hébergeur
L’heure de début avec le fuseau. L’URL. Le code, ou la mention d’un délai sans réponse HTTP. Le résultat d’une deuxième vérification depuis un autre réseau. La phrase sur le déploiement : aucun depuis telle heure, ou un déploiement à telle heure déjà suivi d’un retour arrière qui n’a pas rétabli le 200. Ce que vous ne savez pas, vous ne le comblez pas.
Gardez la référence du ticket hébergeur dans votre ticket. Le niveau 2 reste responsable du suivi tant que le client n’a pas été prévenu que l’horloge dépend maintenant d’un tiers. Cette dépendance doit être dans le contrat, sinon vous escaladez vers quelqu’un dont le délai ne vous protège pas.
Un 503 posé par vous n’est pas une escalade. C’est une maintenance. Le confondre avec une panne envoie l’hébergeur sur une fausse piste. La différence est dans gérer une erreur 503.
La fiche d’escalade
Une page dans le dossier d’équipe : les trois lignes du tableau, les noms du jour (ils tournent), le canal unique vers le client, le lien du support hébergeur par client. Les noms changent plus souvent que le tableau. Mettez-les à jour le lundi, pas au milieu du 502.
Chaque incident de priorité haute se relit le lendemain : est-ce que le passage de niveau a eu lieu à l’heure, est-ce que le ticket hébergeur avait le code, est-ce que deux personnes ont cru tenir le niveau 2. Ces trois questions suffisent. La trace reste dans le ticket, comme indiqué pour documenter un incident.
Le livrable est cette fiche, utilisée. Une escalade qui ne produit pas la ligne de passation dans le ticket n’a pas eu lieu : deux personnes ont travaillé en parallèle. Si les incidents du mois viennent surtout d’un afflux de requêtes plutôt que d’un défaut de passation, la fiche ne se rallonge pas : vous traitez la charge comme dans requêtes HTTP trop nombreuses.