Aucun produit logiciel n’est parfait. Quelle que soit la stabilité de votre application , il y aura forcément des occasions où les choses tourneront mal en production. Pour tirer le meilleur parti de chaque incident et en tirer des enseignements, il est essentiel que les équipes d’ingénierie s’engagent régulièrement à mener des analyses post-mortem.
Cela devient particulièrement important à mesure que les entreprises grandissent et que les équipes adoptent de plus en plus un environnement de travail à distance. Même un problème qui semble mineur peut être analysé et étudié afin de prévenir de futures vulnérabilités.
et d’éviter qu’elles ne soient potentiellement plus graves. Les fournisseurs de technologies ne peuvent pas négliger la mise en place de bonnes pratiques pour mener une analyse post-mortem logicielle à la suite d’un incident.
À lire aussi : Les meilleurs logiciels de gestion de projet
Résoudre les problèmes logiciels : étapes clés
Même s’il n’existe pas de solution universelle adaptée à toutes les équipes, plusieurs étapes fondamentales doivent être suivies pour rendre le processus efficace et faire en sorte que les incidents restent rares.
- Collecter les données pendant l’incident. Il est important de recueillir autant de données que possible en un seul endroit, au fur et à mesure que l’incident se déroule. Il peut s’agir de graphiques des serveurs, d’extraits de journaux et de captures d’écran montrant ce qui se passait à chaque étape de l’incident. Tout ne s’avérera pas forcément utile, mais il est préférable de tout avoir rassemblé lorsque l’enquête détaillée commence.
- Commencer l’enquête immédiatement. Confier à l’un des développeurs ou responsables concernés le rôle d’enquêteur principal : il sera chargé de veiller à ce que l’enquête soit menée à bien, que le document post-mortem soit rempli et que la séance de retour d’expérience soit organisée. La commencer immédiatement permet de ne rien perdre.
- Examiner les résultats dans la semaine. Tant que les faits sont encore frais dans les mémoires, organisez une séance de retour d’expérience pour examiner collectivement le document post-mortem, discuter des actions à mener et effectuer les modifications nécessaires. Il peut s’agir d’une session vidéo de 30 à 60 minutes avec l’équipe impliquée dans l’incident, ainsi qu’avec des représentants d’autres services — principalement l’équipe d’assistance client, mais tous les services concernés doivent y participer.
- Partager les résultats. Dès que la séance de retour d’expérience est terminée, chacun doit pouvoir en tirer des enseignements. Publiez le document à un endroit accessible à toute l’entreprise, par souci de transparence : les incidents ne doivent pas être dissimulés.
À lire aussi : Transformation numérique : définition, types et stratégies
Mesures supplémentaires pour résoudre efficacement les problèmes logiciels
Ces bonnes pratiques aideront les équipes à réussir, mais l’évolution du monde du travail fait émerger de nouveaux défis pour les appliquer.
Par exemple, les entreprises doivent désormais composer avec des employés répartis dans toutes sortes de fuseaux horaires, ainsi qu’avec un mélange d’équipes à distance et d’équipes hybrides , ce qui complique considérablement la planification et la coordination. Plusieurs mesures supplémentaires peuvent contribuer à garantir l’efficacité d’une analyse post-mortem, quel que soit l’environnement :
- Partir du principe que le travail sera asynchrone. Organiser plus rapidement la séance de retour d’expérience signifie qu’il devient plus difficile de trouver un créneau dans l’agenda de chacun. Plutôt que de repousser sans cesse la réunion, effectuez une plus grande partie du travail de manière asynchrone. Veillez à ce que le document se suffise à lui-même et utilisez les canaux de communication les plus rapides pour recueillir les contributions de chacun. Envisagez également d’enregistrer la séance de retour d’expérience — c’est facile avec Zoom — afin que les personnes qui n’ont pas pu y assister puissent la regarder ultérieurement et que personne n’ait à craindre de manquer quelque chose.
- Terminer rapidement l’enquête. Il est important de raccourcir les délais prévus pour l’enquête. Recueillir les données rapidement évite d’avoir plusieurs enquêtes en cours simultanément et permet à toutes les personnes concernées de reprendre plus tôt leur travail de sprint.
- Simplifier le modèle de document d’incident. Envisagez de simplifier le modèle afin de réduire le nombre de sections à remplir et de rendre chacune d’elles aussi simple que possible à compléter. Pour rester exhaustif, ce document doit comporter les sections suivantes :
- Impact et périmètre
- Déclencheur (ce qui a déclenché l’incident)
- Résolution (ce qui a finalement permis de résoudre le problème)
- Chronologie des événements
- Cause racine
- Ce qui s’est bien passé
- Ce qui s’est mal passé
- Actions à mener
- Données et analyse (tous les graphiques)
- Demander immédiatement l’avis des équipes en contact avec les clients. Une équipe de réussite client dispose toujours d’informations précieuses et peut contribuer à combler les lacunes de la chronologie. Sollicitez-la rapidement afin d’avoir le temps d’intégrer ses contributions au document post-mortem avant la séance de retour d’expérience. Attendre cette séance, c’est trop tard !
- Suivre les actions à mener dans les backlogs. Pourquoi suivre l’avancement des actions à mener dans un document d’incident alors qu’il existe déjà un outil standard pour suivre le travail ? Dès que possible, extrayez toutes les actions à mener des post-mortems afin de les affecter aux backlogs et d’éviter qu’elles ne soient oubliées. Il est également utile de configurer des rapports automatisés permettant d’afficher la liste des actions post-mortem en suspens, à partir d’une étiquette post-mortem appliquée aux éléments concernés.
- Prévoir une section « choses à faire si nous avons le temps ». Dans la réalité, toutes les actions à mener ne sont pas réellement réalisables : certaines sont davantage des objectifs à long terme ou des points que chacun devrait garder à l’esprit. Pour clarifier les actions à mener, ajoutez cette section afin d’y placer les éléments que vous jugez importants, mais que vous n’avez pas pu transformer en tâches pouvant être attribuées et suivies. Mieux vaut avoir un ensemble plus restreint d’actions que vous réalisez effectivement qu’une liste interminable de choses que vous aimeriez faire avec un temps illimité.
- Éviter la recherche de coupables. Ce principe n’est pas nouveau, mais il mérite d’être répété ! Intéressez-vous à ce qui s’est passé et à ce que vous allez faire pour y remédier à l’avenir, plutôt que de chercher à désigner des responsables.
Le travail à distance et le développement mené à un rythme soutenu ne doivent pas rendre les incidents complexes. En suivant ces bonnes pratiques, les ingénieurs logiciels et les responsables d’équipe peuvent tirer le meilleur parti d’un post-mortem d’incident et se concentrer sur l’essentiel : en tirer des enseignements et améliorer les choses pour l’avenir.
À lire aussi : 7 tendances de la transformation numérique qui façonnent 2022
À propos de l’auteur :
Jesse van Herk, Senior Manager of Product Engineering, Jobber