Faire une demande d'intervention

Contexte professionnel

Hier, un dev m’a taggé sur un ticket relatif à la prod bleue. Avec « Prod Bleue » indiqué dans le titre et dans les commentaires/tags/whatever.
Il m’a demandé de regarder un problème de connexion. Je regarde et ne trouve rien. Je creuse les logs, les services systèmes, toujours rien. Je l’appelle par skype, on cherche ensemble, j’indique à l’oral toutes les opérations que je fais et sur quels serveurs je regarde, mais je ne trouve rien alors que lui oui. Jusqu’à ce qu’il me dise que son problème était sur un serveur copieprod-jaune, 15-20 minutes plus tard.

Certes ce cas est extrême. Mais il s'est bien produit et n'aurait jamais dû arrivé. Et ce n'était pas la première fois depuis que je suis arrivé à mon poste actuel.
Avec les bonnes informations tout de suite, le problème aurait été résolu en quelques secondes, au lieu de la bonne demi-heure du cas ci-dessus qui a tendance à se reproduire de plus en plus dernièrement.

Cet état de fait me pose problème pour 3 raisons :

• Je perds du temps à faire des choses, alors qu’avec les bonnes informations, ça pourrait être résolu rapidement
• C’est du temps que je ne passe pas à améliorer notre infra/supervision/scripts de déploiement/etc…
• Ça m’énerve (littéralement) que certains gens ne sachent pas ce qui me semblait être la base d’une demande d’intervention

Du coup, j’ai créé une page sur le wiki de l'équipe avec le contenu ci-après.

L’idée derrière tout ça est de formaliser le minimum d'information à me fournir pour toute demande d’intervention (« ça marche pas, tu peux regarder ? »), d’en informer tout le monde, et de renvoyer vers cette page sans vergogne toutes les demandes ne fournissant pas ce dont j’ai besoin pour ne pas perdre du temps¹.

Petite précision : dans mon environnement professionnel actuel, on déploie les appli/BDD/etc... directement sur des VMs, sans utiliser docker.

---

Etant seul pour gérer toute l'administration système (cf métriques Nagios : pas loin de 100 serveurs dont 60 en production et on en rajoute 5-10 chaque mois) et faire du support aux développeurs/testeurs/etc... en plus des développements propres à l'adminsys/devops, j'ai besoin que vous suiviez quelques règles pour que contacter l'adminsys soit rapide et efficace pour vous comme pour moi.

Contexte : Où, Quoi, Pourquoi

La règle d'or

Voici une règle d'or que doit contenir toute demande : un contexte.
C'est obligatoire pour que la demande soit traitée efficacement.

Toute demande sans contexte se verra systématiquement rejetée avec un lien vers cette page

Le plus simple pour me fournir un contexte est de répondre à ces 3 questions : où ?, quoi ?, pourquoi ?

• Où : quel environnement ? prod ou pas prod ? quel serveur ? le plus simple est de fournir son adresse IP ou l'URL sur laquelle apparaît le problème
• Quoi : que se passe-t-il ? que voyez-vous ? quel est le message d'erreur ?
• Pourquoi : Pourquoi est-ce une erreur pour vous ? à quoi vous attendiez-vous ?

Moyen mnémotechnique :

Pour vous rappeler cette règle d'or, dites-vous que l'adminsys est occupé à autre chose avant que vous ne le contactiez.

occupé => OQP => Où, Quoi, Pourquoi

Précision

Parce que le diable se cache dans les détails, il faut s'appliquer à être le plus précis possible.

Précision du Où

"Il y a un problème sur l'environnement fushia" n'est pas précis : quel "fushia" (prod-fushia, test-fushia, uat-fushia) ? Quel serveur (serveur web, serveur bdd) ?

Simple et précis : l'adresse IP

Les serveurs ont cela de facile qu'il dispose d'un identifiant absolument unique qui les caractérise bien plus qu'un nom : une adresse IP. Soyez précis, fournissez l'adresse IP du serveur où vous constatez l'erreur.

Précision du Quoi

Une capture d'écran seule n'est pas suffisante. Par contre, accompagnée d'une explication de ce qu'il faut regarder dessus, avec citation du texte important à lire est bien mieux.
Pour qu'une ligne de log soit précise, elle doit contenir un horodatage (date + heure à la seconde près) et une indication succincte et explicite du problème.

Exemple de ce qu'il ne faut pas faire :
"Bonjour, il y a eu un problème hier sur le serveur 12.34.56.78. Voilà l'erreur : "java.lang.NullPointerException", tu peux regarder au plus vite ?"

Il n'y a pas d'horodatage précis (hier n'est pas précis quand on traite des opérations à la milliseconde près), et indiquer uniquement "java.lang.NullPointerException" ne permet pas d'analyser, donc de corriger le problème au plus vite, ce n'est donc pas une indication succincte et explicite.

Précision du Pourquoi

Une description d'une erreur n'est pas suffisante s'il n'y a pas d'indication de l'état normal.

Exemple :
"Bonjour, quand j'interroge le webservice http://example.com/api/getToto, ça me renvoie {"result": "tata"}, tu pourrais corriger ça ?"

Pour corriger, encore faut-il savoir ce que le webservice aurait dû répondre. D'où la nécessité de l'indiquer pour permettre de corriger le problème au plus vite.

Pourquoi imposer cette règle ?

Trouver et résoudre un problème avec un contexte se fait généralement en quelques minutes, voire en quelques secondes.
Sans contexte, il faut commencer à trouver le contexte, avant même de pouvoir chercher le problème, et cela prend souvent plusieurs dizaines de minutes (10 à 40 minutes).

Juste pour avoir un ordre d'idée :

• 10m : temps de déploiement d'une copie-prod
• 20m : temps de build d'une nouvelle version de l'application
• 40m : temps qu'il faut pour télécharger un nouvel ear sur tous les serveurs en même temps

Et tout ça, sans intervention de l'adminsys.
Si trouver le contexte d'un problème prend plus de temps que de déployer une copie-prod-X, c'est que la demande n'a pas été formulée avec assez de précision.