Player Unknown’s Bug : peut-on progresser en consignant les problèmes dont on ignore la cause ?
(engineering.ab180.co)Je voudrais partager comment une page d’incident créée par hasard a permis d’augmenter le sentiment de sécurité psychologique au sein de l’équipe et de favoriser le partage d’informations, pour construire une organisation et des services plus solides.
Quand on développe, on finit souvent par rencontrer des problèmes dont la cause est inconnue.
Le web front-end, en particulier, est influencé non seulement par l’état du serveur, mais aussi par d’innombrables facteurs externes comme le type ou la version du navigateur, ou encore les extensions Chrome.
Si l’on ne connaît pas la cause du problème, ou si cette cause ne nous incombe pas, je me suis soudain demandé si les seuls postmortems suffisaient vraiment à bâtir une structure robuste (n’était-ce pas insuffisant ?).
Déclencheur
Un jour, il m’a fallu 9 heures pour recevoir le signalement d’un problème dont la cause était inconnue et le clôturer.
Ce n’est qu’après avoir consacré 4 heures au débogage que j’ai découvert que la cause ne se trouvait ni dans notre code interne ni dans notre infrastructure, mais dans un bug d’une extension Chrome de l’utilisateur.
Il était déjà difficile d’identifier où se situait la cause du problème, mais je me suis surtout reproché qu’il ait fallu pas moins de 4 à 5 heures pour comprendre qu’elle était externe.
J’ai créé dans Notion une page intitulée « Player Unknown’s Bug (PUB) » et j’y ai consigné, avec ma frustration, ce que j’avais tenté pendant la gestion de l’incident, ce qui m’avait laissé des regrets, et ce qui méritait d’être amélioré.
Adoption comme culture, puis évolution
En revenant sur l’incident, nous avons parlé de sa cause, de ce que nous avions appris au passage en enquêtant, ainsi que des points sur lesquels nous nous étions trompés. Les membres de l’équipe ont soulevé leurs questions et les aspects à améliorer, puis nous avons rassemblé ces éléments pour formaliser un processus de réponse aux incidents.
Ce qui a été positif dans ce processus, c’est que l’équipe a compris les difficultés ressenties pendant la gestion de l’incident, et qu’il y avait aussi un vrai plaisir à partager ce que nous venions d’apprendre. De plus, nous avons créé une checklist afin de pouvoir identifier plus rapidement les problèmes dans des situations similaires. Après en avoir parlé avec l’équipe, cela a été adopté comme pratique officielle.
L’organisation de développement d’AB180 mène déjà des « postmortems » de manière systématique. Si, en interne, les postmortems sont centrés sur la résolution et les action items, le PUB a pour objectif de mettre en avant les leçons apprises, de renforcer le sentiment de sécurité psychologique autour de la gestion des incidents, et de répertorier les éléments à vérifier en priorité face à des problèmes inconnus.
Une culture de partage spontané de l’information
À mesure que cette pratique s’est installée dans l’équipe, les incidents traités par d’autres membres ont eux aussi commencé à s’accumuler peu à peu.
Avec ces rétrospectives, le temps passé à évoquer ce que nous ne savions pas encore et à creuser davantage a commencé à fonctionner, modestement mais spontanément, comme une sorte de « session de partage de connaissances ».
Pour faire grandir un peu plus cette culture, nous gérons aussi un canal Slack où nous partageons régulièrement ce que nous avons appris et découvert. Jusqu’à présent, cela fonctionne bien.
Leçons apprises
- Il faut renforcer le sentiment de sécurité psychologique de toute l’équipe qui a géré l’incident, et pour cela il faut échanger davantage.
- Sinon, les problèmes se répètent, et l’idée que « problème = quelque chose dont il ne faut pas parler » finit par s’ancrer dans l’organisation.
- Le partage d’informations permet de créer, et même de renforcer, la sécurité psychologique au sein de l’organisation.
- Et une telle culture du partage d’informations peut peut-être commencer par quelque chose de plus simple qu’on ne l’imagine.
5 commentaires
À l’inverse, je suis sorti du travail aujourd’hui après avoir passé la journée à subir un incident dont la cause semblait pourtant très clairement liée à un facteur externe précis, mais que, pour des raisons internes, on pensait impossible à corriger facilement, au point de tourner en rond — alors qu’en réalité il suffisait de modifier une seule ligne dans le fichier de configuration pour le résoudre. En lisant ce billet, je le trouve vraiment utile.
Vous avez vraiment bien travaillé aujourd’hui aussi. Heureusement, vous avez quand même réussi à résoudre le problème. Il m’arrive encore parfois de repenser aux problèmes que j’avais mentionnés dans le texte ci-dessus. À l’époque, c’était difficile, mais j’ai l’impression que je peux maintenant les accueillir avec le sourire.
Peut-être que les moments difficiles que vous avez traversés aujourd’hui, kunggom, pourront eux aussi vous faire sourire avec le temps ? haha
Merci d’avoir lu mon modeste texte.
En vérité, ni avant ni maintenant, je n’ai jamais trouvé agréable de devoir gérer des incidents.
Par exemple, l’incident traité aujourd’hui s’est justement produit sur un produit pour lequel, dans notre équipe, l’accès direct au serveur de production était bloqué. À part la phase initiale, quand nous avons détecté l’incident et commencé à analyser les symptômes, puis la phase finale, après avoir réussi tant bien que mal à obtenir les droits d’accès au serveur, nous ne pouvions qu’être relativement impuissants. Chaque fois que notre équipe demandait que telle ou telle mesure soit prise, l’équipe d’exploitation des serveurs refusait en invoquant ses propres contraintes. Il est difficile d’accueillir sereinement un tel sentiment d’impuissance.
Ainsi, en rédigeant le document de post-mortem avant de quitter le bureau, j’ai eu le sentiment que cela se rapprochait plutôt de : « Même par dégoût, je ne referai plus ce genre d’erreur la prochaine fois ! »
En entendant ce que vous avez raconté, je me dis que cela a dû être vraiment éprouvant pour vous. Comme vous l’avez dit, en évitant de refaire les mêmes erreurs, on ne peut qu’avancer petit à petit... snif
En réalité, ce produit est un ancien produit legacy, et cela ne faisait pas longtemps que j’en avais repris la responsabilité. Dès la reprise, une demande de modification fonctionnelle est arrivée, si bien que j’avais récemment modifié le code, mais sur une partie qui n’avait absolument rien à voir avec l’incident survenu aujourd’hui. Ainsi, la partie qui a réellement posé problème n’était pas quelque chose que j’avais écrit moi-même. Cela dit, si j’avais connu ce produit plus en profondeur, j’aurais sans doute pu résoudre le problème plus rapidement. C’est vraiment regrettable.
Et puis, au départ, après avoir constaté la panne généralisée, l’hypothèse sur la cause dont j’étais d’abord persuadé n’était en fait correcte qu’à moitié. Je pense que c’est précisément cette certitude dans cette hypothèse qui a été la véritable erreur d’aujourd’hui.