Visualiser, Faire dialoguer, Anticiper – partie 2

(précédement …)

Tableau 4

Dans lequel l’information remonte difficilement à la surface

Kanya : DSI
Mohammed : Chef de projet sur le projet TITAN
Paulette : PO sur le projet TITAN
Thomas : Tech Lead sur l’application TITAN
Pierrick : Ops/Administrateur système

Kanya : Excusez pour le retard. Tout le monde est là ?

Mohammed : On t’attendait.

Regards circonspects

Kanya : Je suppose que tu as présenté le but de la réunion ?

Mohammed : J’allais le faire. Donc: suite à l’incident TITAN-382 du début de semaine, nous allons rétro-analyser ce qu’il s’est passé, afin de trouver une façon d’éviter des incidents de ce type à l’avenir.

Kanya : Merci d’être venu vous prêter à cet exercice. Est-ce qu’on pourrait chacun se présenter, histoire de comprendre notre rôle en général, et au cours de cet incident. Je suis Kanya, votre nouvelle DSI. J’ai été informée de l’incident assez rapidement, mais je manquais d’informations.

Mohammed : Voilà, je suis le chef de projet de TITAN, j’ai suivi l’incident depuis sa création… Je veux dire depuis son apparition.

Paulette : Je suis PO, je m’occupe des évolutions du projet, je ne suis pas sûre de vous être bien utile, mais j’étais là le jour de l’incident.

Thomas : Je suis Tech Lead sur l’appli TITAN. Sandrine et Pierrick m’ont appelé dans l’heure qui a suivi, principalement pour me demander des détails sur le traitement qui était en cause.

Pierrick : Je suis Ops sur le projet TITAN et sur d’autres. J’ai découvert le problème en suivant la log des alimentations qui semblait se répéter en boucle avec toujours le même message, et j’ai appelé Sandrine.

Kanya : Elle développe sur le projet, c’est bien ça ?

Thomas : Oui c’est bien ça, mais elle n’a pas pu se libérer pour cette réunion.

Kanya : Merci pour ces introductions. Ma première question : Qu’est-ce qui s’est manifesté qui vous a permis de détecter l’incident ? Quels étaient les symptômes.

Pierrick : Eh bien, un affichage de log dans lequel le message se répète en boucle.

Kanya : Pourquoi la log affiche le même message en boucle ?

Thomas : Parce que le programme échoue à ouvrir une ressource, et qu’il recommence sans arrêt, et qu’il est conçu pour logguer ses opérations d’accès aux ressources.

Kanya : Pourquoi recommence-t-il sans arrêt à essayer d’ouvrir la ressource ?

Thomas : Euh. C’est un défaut de la librairie qu’on utilise dans cette partie de TITAN pour la version 6.

Mohammed : En fait, on l’utilise dans toutes les versions. On utilise cette librairie depuis la version 2 de TITAN.

Thomas : Peut-être, mais en tout cas pas de cette façon. En tout cas, on n’a pas touché à ce programme, ou bien pas récemment.

Mohammed : Je ne sais même pas qui a modifié le programme.

Kanya : Ce n’est pas la question qui se pose. On est tous à faire de notre mieux ici, avec la situation qui nous est donnée. Je ne cherche pas un responsable, ce qui m’intéresse c’est le processus qui a produit cette situation.

Tous : …

Kanya : Donc: Si on utilise la librairie depuis plusieurs versions de TITAN, pourquoi ce comportement arrive dans la version 6 et pas les précédentes ?

Thomas : Dans la version 6, on utilise GetExtendedResource, alors que dans les versions précédentes on appelait GetResource.

Mohammed : Pourquoi est-ce qu’on n’a pas vu ce problème avant qu’il apparaisse en production ?

Thomas : Je ne sais pas, moi, demande à Sandrine.

Kanya : Est-ce qu’on pourrait lui demander de passer si c’est possible ?

Mohammed : Je l’appelle …

Arrive Sandrine : développeuse sur le projet TITAN

Mohammed : Merci d’avoir pu te libérer. Nous sommes en pleine rétro-analyse de l’incident 382. Peux-tu te présenter, car c’est la première fois que tu rencontres Kanya je pense…

Kanya : Bonjour.

Sandrine : Je suis développeuse, je travaille sur TITAN depuis 6 mois. Pierrick m’a appelé et on a regardé ensemble la trace de la log, et ensuite j’ai appelé le chargé de compte pour le prévenir. C’est alors qu’il m’a dit que des clients commençaient à l’appeler.

Mohammed : On a déterminé que l’incident était dû à un essai en boucle de la librairie SQUEAK d’ouvrir une ressource étendue.

Sandrine : En effet, c’est le problème. On n’utilisait pas cette fonction jusqu’ici, mais en fait elle n’est pas compatible avec d’autres librairies qu’on a depuis la version 5 de TITAN.

Mohammed : On se demandait : qu’est-ce qui a fait que cette incompatibilité soit détectée seulement en production ?

Sandrine : Euh, la version 6, ça été un peu le rush, et on a pas forcément pris le temps de faire tous les tests.

Kanya : OK, c’est le temps qui manque. Mais le temps qui manque, c’est vague… Quel est le process de vérification d’une nouvelle version avant livraison en prod ?

Thomas : Euh. Disons qu’on teste les nouvelles évolutions, en vérifiant en local la conformité aux exigences fonctionnelles. Et ensuite on fait quelques TNR.

Paulette : TNR ?

Thomas : Test de non régression. Disons qu’on essaie des fonctionnalités connectées à la partie que l’on a modifié pour voir si tout va bien.

Mohammed : Qu’est-ce qui fait que cette fois-ci les TNR ne détectent pas ce problème ?

Thomas : En fait on n’est pas censé tester nous mêmes, on manque de testeurs.

Mohammed : Et pourquoi est-ce qu’on manque de testeurs ?

Thomas : Bah je sais pas, c’est une question de management…

Kanya : En effet, on manque de testeurs, mais cela ne nous dit pas pourquoi vos TNR sont effectués d’habitude, et pas cette fois-ci.

Sandrine : En fait, on fait nos TNR à la main, et selon des scénarios fonctionnels. Et ce problème d’accès aux ressources, ce n’est pas fonctionnel, mais technique. Et nos scénarios n’en parlent pas.

Mohammed : Et donc on n’a pas de vérification automatique en intégration pour les mécanismes d’appels aux ressources.

Thomas : Non.

Kanya : Donc, la question devient : pourquoi pas de vérification automatique de ces appels ?

Thomas : C’est pas qu’on veut pas en faire de la vérification…

Mohammed : Disons : qu’est-ce qui fait que sur cette partie du système on ne peut pas en faire ?

Kanya : Voilà. Bonne question. Excusez-moi, je vais vous laisser, j’ai un comité dans 15 minutes, et il faudrait que je le prépare…

Tableau 5

Dans lequel il est décidé de ne plus jamais jouer au chicken planning

Kanya : DSI
Mohammed : Chef de projet sur le projet TITAN
Paulette : PO sur le projet TITAN
Thomas : Tech Lead sur l’application TITAN

Au cœur d’une nouvelle réunion de crise

Thomas : Je vous l’avais dit : n’attendons pas la validation métier pour faire des vérifs. Et je vous avais dit : si les problèmes arrivent en aval il sera trop tard, et à l’époque vous m’avez dit meuh non, ça se passera bien.

Kanya : Oui, en effet c’est peut être un problème de visibilité…

Paulette : Qu’est-ce que tu veux dire ?

Kanya : Mon fils joue à un jeu de stratégie dans lequel il y a un “brouillard de guerre” : ça empêche les joueurs de voir ce qu’il se passe là où ils n’ont pas encore de troupes; toute la stratégie du début de partie consiste à réduire le brouillard de guerre, à l’aide de sorts ou bien d’éclaireurs..

Paulette : Mais quel est le rapport ?

Kanya : On ne peut pas lancer une action stratégique – comme par exemple une recette utilisateur – sans s’enquérir du terrain.

Thomas : Voilà.

Mohammed : D’accord, mais “réduire le brouillard de guerre” ça prend du temps, du temps qu’on n’a pas.

Thomas : Et maintenant on a le temps bien sûr de corriger la version qui a planté en recette, d’expliquer au métier ce qui a pu se produire, de contourner avec un patch pendant qu’on rectifie les programmes, bien sûr, et de faire une réunion pour comprendre ce qui s’est passé.

Mohammed : On a toujours raison après la bataille, bien sûr.

Thomas : Je préfèrerais avoir tort. Là, c’est indiscutable qu’il y a un problème : on a le nez dessus !

Kanya : OK. Est-ce qu’on peut cesser de se disputer sur des modèles et revenir à ce qui nous préoccupe ?

Thomas : Il faut trouver un moyen de bloquer le travail dès qu’on voit qu’il y a un problème potentiel

Mohammed : Eh bien, arrêter le travail, c’est entièrement à ta main : pourquoi tu ne l’as pas fait ?

Thomas garde le silence

Mohammed : Pourquoi ?

Thomas : J’ai insisté une fois ou deux, puis je me suis dit que le métier aurait un problème de disponibilité de toutes façons, et que les gars de KALAMAR avec qui ce module s’interface ne seraient jamais prêts à temps; c’est pour ça que j’ai laissé tomber, et que je m’en suis remis à votre philosophie : on verra bien quand ça arrivera…

Mohammed : En n’insistant pas, tu nous as laissé croire que la version passerait les vérifs sans problème lors de la recette métier.

Thomas : Je ne peux pas te laisser dire ça.

Kanya : OK. Stop. Je pense qu’on a au moins deux contre-mesures : un, si on doit bloquer le travail et déclarer un défaut en avance de la recette, on le fait sans hésiter, et ça déclenchera une repriorisation s’il le faut ; deux : j’aimerais qu’on ait un point sur le statut du produit chaque semaine avec des informations à jour et factuelles, plutôt qu’un statut fabriqué en fonction de ce que vous estimez que les autres sont en train de faire.

Mohammed : Mais si on apporte une mauvaise nouvelle, est-ce que tu nous garantis qu’il n’y aura pas de conséquence ?

Kanya : Au contraire : il y aura des conséquences pour ceux qui gardent l’information pour eux. Il faut qu’on se donne les moyens de réfléchir et de réagir à temps, et ensemble. Si on est tous en train de se cacher la réalité, ou de se cacher les uns derrière les autres, on va tous échouer.

Thomas : OK. J’entends. La prochaine fois, j’insisterai.

Kanya : Tu arrêtes ce que tu fais, tu préviens les autres et tu traites le problème, sans demander d’autorisation.

Tableau 6

Dans lequel on se demande comment on aurait pu savoir ce qu’on ne pouvait savoir

Kanya : DSI
Mohammed : Chef de projet sur le projet TITAN
Paulette : PO sur le projet TITAN
Pierre-René : Architecte transverse
Thomas : Tech Lead sur l’application TITAN

Lors d’une nouvelle réunion de crise

Kanya : Mohammed, explique-nous ce que nous faisons ici.

Mohammed : Tu nous as demandé de nous arrêter en cas de problème pour signaler ces problèmes et les traiter. Or il y a un problème.

Kanya : Parfait.

Mohammed : J’ai fait venir Pierre-René parce qu’il a aidé Thomas sur le diagnostic, et il a des préconisations à faire pour résoudre le problème.

Pierre-René : Bonjour ! Pierre-René, architecte transverse depuis 2017.

Kanya : Est-ce qu’on peut formuler le problème ? J’ai vu passer des emails, mais je n’ai pas suivi toute la discussion.

Mohammed : Donc : le traitement batch de facturation s’est arrêté dans la nuit du 17 au 18. La cause : plus d’espace disque. Donc je veux commander du volume supplémentaire.

Pierre-René : Et la cause de la cause : vos logs sont trop verbeux.

Thomas : Mais on a besoin de ce niveau de détail de log.

Kanya : On en a besoin pour quoi faire ?

Thomas : C’est le moyen de tracer les problèmes de qualité du code.

Kanya : Donc tu me dis que l’outil qui trace les problèmes de qualité a un problème de qualité ?

Mohammed : Tu avais promis que tu ne punirais pas les messagers…

Kanya : Ok reprenons. On a un processus qui trace les opérations, et qui les trace en détail; et on a besoin de ce niveau de détail.

Thomas : Oui, parce que c’est le seul moyen de savoir si un traitement se déroule correctement ou bien comporte des erreurs.

Kanya : Pourquoi pas des tests ?

Thomas : Franchement c’est assez difficile de poser des tests sur toutes les conditions qui pourraient se produire dans l’environnement de production; donc on préfère inspecter a posteriori et reprendre.

Pierre-René : Ça n’empêche que vous avez besoin de passer à SpeleoLogguer, pour gérer la verbosité.

Kanya : Notre problème n’est pas de gérer la verbosité dans l’immédiat. On a besoin d’anticiper les situations de batch avant qu’elles ne se produisent en live. Qu’est-ce qui nous empêche de créer des conditions de test dans l’environnement de recette ?

Mohammed : C’est une bonne idée, mais on n’a tout simplement pas le temps de faire cela dans les délais prévus pour la recette.

Kanya : Qu’est-ce qui prend actuellement le plus de temps dans la recette ?

Paulette : Souvent, c’est d’attendre un correctif, qui prend le plus de temps.

Kanya : Comment cela : attendre un correctif ?

Paulette : Eh bien oui, constater un problème, écrire un ticket, attendre le correctif, tout en testant d’autres fonctionnalités bien sûr.

Kanya : Est-ce qu’on pourrait examiner le type des problèmes constatés lors de la dernière recette ?

Paulette : On pourrait, et peut être que je ne décris pas correctement les problèmes rencontrés en rédigeant les tickets, mais je suis ouverte à vos retours sur ce sujet. De toutes façons, pour moi au niveau de la validation métier, on est clairement débordés.

Kanya (se tourne vers Thomas et Mohammed) : Comment est-ce qu’on pourrait aider Paulette ?

Mohammed : Franchement, on n’a pas le temps non plus.

Kanya : En gros vous me dites qu’il faut que j’aille décrocher un budget…

Mohammed : Voilà.

 
(à suivre)

Leave a Reply

Your email address will not be published.


This form is protected by Google Recaptcha