7 techniques de débogage pour accélérer le dépannage en production

Fournir un support de production à une application est l'un des aspects les plus difficiles du développement logiciel. Les développeurs sont affectés à l'équipe de maintenance et travaillent à corriger les bogues de l'application. Ils sont cependant également disponibles sur appel en cas d'arrêt de production, auquel cas ils s'efforcent de remettre l'application sur les rails le plus rapidement possible.

Cet article vise à fournir un ensemble de recommandations organisées afin que vous puissiez prévenir les bogues en production et trouver les problèmes beaucoup plus rapidement. La gestion de ces applications en production est une tâche compliquée : souvent, aucune documentation n'est disponible, l'application a été écrite dans une pile technologique héritée, ou les deux. Il y a très peu de formations, et il est courant d'être appelé pour apporter du support sur une application que l'on connaît peu.

De nombreux développeurs n'ont pas d'expérience dans la gestion d'une application en production. Il existe un éventail de problèmes qui se produisent dans les environnements de production et qui provoquent des bogues et des pannes, entraînant généralement des milliers, voire des millions de dollars de perte de revenus pour l'entreprise. De plus, comme la majorité des développeurs ne sont pas exposés à l'environnement, ils continuent de commettre des erreurs qui, à leur tour, causeront ces problèmes. Cette liste de conseils devrait rendre votre travail moins pénible en enseignant à partir de l'expérience de production.

Conseil n° 1 : supprimez ou automatisez toute la configuration nécessaire à l'exécution de l'application.

Quel est le niveau de configuration requis pour installer le logiciel sur un nouveau serveur ? Dans le passé, cela pouvait parfois prendre trois jours à chaque fois qu'il y avait un nouveau développeur dans l'équipe. L'installation de l'application nécessiterait de nombreuses étapes qui doivent être effectuées manuellement. Au fil du temps, les logiciels évoluent vers de nouvelles versions qui deviennent incompatibles avec ces instructions, et bien sûr, les instructions ne sont généralement pas mises à jour. Du coup, vous passez beaucoup plus de temps que nécessaire simplement pour que l'application soit opérationnelle.

Avec l'avènement de la conteneurisation, il est devenu beaucoup plus facile de fournir un moyen de rendre une application opérationnelle en un rien de temps, sans aucune configuration et avec l'avantage supplémentaire que, puisque l'image Docker est autonome, vous exécutez un beaucoup plus faible risque de rencontrer des problèmes avec différentes versions du système d'exploitation, des langages et des frameworks utilisés.

De même, simplifiez la configuration du développeur, afin qu'il ne prenne pas beaucoup de temps pour être opérationnel, y compris la configuration de l'IDE. Un développeur devrait pouvoir passer de zéro à héros en moins de 30 minutes.

Lorsqu'un problème de production survient, il se peut que vos meilleurs experts ne soient parfois pas disponibles (par exemple, en vacances ou en cas de maladie) et vous souhaitez que la personne à qui vous confiez le problème puisse le résoudre, et rapidement.

Astuce #2 : Ne tombez pas dans le piège à soupe de la pile technologique.

Moins il y a de technologies utilisées, mieux c'est. Bien sûr, parfois, vous devez utiliser le bon outil pour le travail. Attention toutefois à ne pas surcharger les « bons outils ». Même l'eau potable peut entraîner de graves problèmes de santé si vous en faites trop. Chaque nouveau langage et cadre ajouté à la pile technologique doit passer par un processus de prise de décision clairement défini avec une attention particulière aux impacts.

• N'ajoutez pas une nouvelle dépendance de framework simplement parce que vous avez besoin d'une classe StringUtils .
• N'ajoutez pas une langue complètement nouvelle simplement parce que vous avez besoin d'écrire un script rapide pour déplacer des fichiers.

Un gros tas de dépendances peut vous rendre la vie misérable lorsque les bibliothèques deviennent incompatibles ou lorsque des menaces de sécurité se trouvent soit sur les frameworks eux-mêmes, soit sur leurs dépendances transitives.

De plus, n'oubliez pas que les complexités supplémentaires de la pile rendent difficile la recherche et la formation de nouveaux développeurs pour l'équipe. Les gens passent à de nouveaux rôles dans d'autres entreprises, et vous devez en trouver de nouveaux. Le roulement est très élevé dans les équipes d'ingénieurs, même dans les entreprises reconnues pour leurs avantages et leur équilibre travail-vie personnelle. Vous voulez trouver le nouveau membre de l'équipe le plus rapidement possible. Chaque nouvelle technologie ajoutée au-dessus de la pile technologique augmente le temps nécessaire pour trouver un nouveau candidat et a le potentiel de rendre les nouvelles embauches de plus en plus coûteuses.

Astuce n°3 : La journalisation doit vous guider pour trouver le problème, pas vous noyer avec des détails inutiles.

La journalisation est très similaire aux commentaires. Il est nécessaire de documenter toutes les décisions critiques prises ainsi que toutes les informations à utiliser dans vos techniques de débogage. Ce n'est pas simple, mais avec un peu d'expérience, il est possible de tracer quelques scénarios possibles d'arrêts de production, puis de mettre en place la journalisation nécessaire pour résoudre au moins cela. Bien sûr, la journalisation évolue avec la base de code en fonction du type de problèmes qui se présentent. De manière générale, vous devriez avoir 80 % de votre journalisation sur les 20 % les plus importants de votre code, la partie qui sera la plus utilisée. Les informations importantes, par exemple, sont les valeurs des arguments transmis à une méthode, les types d'exécution des classes enfants et les décisions importantes prises par le logiciel, c'est-à-dire l'heure à laquelle il était à la croisée des chemins et il a choisi la gauche ou la droite.

Conseil n° 4 : gérez les situations inattendues.

Définissez très clairement les hypothèses du code. Si une certaine variable doit toujours contenir les valeurs 2, 5 ou 7, assurez-vous qu'elle est de type enum et non int. La principale source d'arrêts de production importants est l'échec d'une certaine hypothèse. Tout le monde cherche le problème au mauvais endroit parce qu'ils tiennent certaines choses pour acquises.

Les hypothèses doivent être documentées explicitement, et tout échec de ces hypothèses doit déclencher suffisamment d'alarmes pour que l'équipe de support de production puisse rapidement rectifier la situation. Il devrait également y avoir un code pour empêcher les données d'entrer dans un état invalide, ou au moins de créer une sorte d'alerte dans ce cas. Si certaines informations doivent être stockées dans un seul enregistrement et qu'il y a soudainement deux enregistrements, un avertissement doit être déclenché.

Conseil n° 5 : Il doit être simple de reproduire un problème survenu à un client.

L'une des étapes les plus difficiles consiste toujours à reproduire le problème rencontré par le client. Plusieurs fois, vous passerez 95 % du temps à essayer de reproduire le problème, puis dès que vous pourrez le répliquer, il ne vous faudra que quelques minutes pour corriger, tester et déployer. En tant que tel, l'architecte d'application doit s'assurer qu'il est extrêmement simple et rapide de reproduire les problèmes. Cela se produit en grande partie parce que, pour arriver à la même situation que celle dans laquelle se trouve le client, le développeur doit effectuer une quantité importante de configuration de l'application. Il existe de nombreux enregistrements stockés qui, ensemble, aggravent la situation dans laquelle se trouve le client. Le problème étant que vous, en tant que développeur, devez deviner exactement ce que le client a fait. Et parfois, ils ont effectué une séquence d'étapes, dont ils ne retiennent que la dernière.

De plus, le client expliquera le problème en termes commerciaux, que le développeur devra ensuite traduire en termes techniques. Et si le développeur a moins d'expérience avec l'application, il ne saura pas demander les détails manquants, puisqu'il ne connaît même pas encore les détails manquants. Copier l'intégralité de la base de données de production sur votre machine est impossible. Il devrait donc y avoir un outil pour importer rapidement de la base de données de production uniquement les quelques enregistrements nécessaires pour simuler la situation.

Supposons que le client rencontre un problème avec l'écran Commandes. Vous devrez peut-être importer quelques-unes de leurs commandes, leur dossier client, certains enregistrements de détails de commande, des enregistrements de configuration de commande, etc. Ensuite, vous pouvez exporter cela dans une base de données au sein d'une instance Docker, lancer cette instance, et juste comme ça, vous êtes voir la même chose que le client voit. Tout cela, bien sûr, doit être fait avec le soin approprié pour s'assurer qu'aucun développeur n'a accès aux données sensibles.

Conseil n° 6 : l'emplacement des points d'arrêt dans l'application doit être évident.

Si vous avez un écran Client, il devrait y avoir un objet Client où vous pouvez placer les points d'arrêt pour déboguer un problème sur cet écran. Parfois, les développeurs tombent dans la fièvre de l'abstraction et proposent des concepts incroyablement intelligents sur la façon de gérer les événements de l'interface utilisateur. Au lieu de cela, nous devrions toujours nous fier au principe KISS (Keep it Simple, St— er, Silly) et avoir une méthode facilement localisable par événement d'interface utilisateur. De même, pour les tâches de traitement par lots et les tâches planifiées, il devrait y avoir un moyen simple de repérer où se situent les points d'arrêt pour évaluer si ce code fonctionne ou non.

Astuce #7 : Assurez-vous que toutes les dépendances externes sont explicitement documentées.

Idéalement, faites-le dans le fichier README du système de contrôle de source afin que la documentation ne puisse pas être perdue. Documentez tous les systèmes, bases de données ou ressources externes qui doivent être disponibles pour que l'application s'exécute correctement. Notez également ceux qui sont facultatifs et ajoutez des instructions sur la façon de les gérer lorsqu'ils sont facultatifs et non disponibles.

Au-delà des techniques de débogage

Une fois ces recommandations suivies lors de la création de nouvelles fonctionnalités ou de la maintenance d'un système, le support de production deviendra beaucoup plus facile et votre entreprise passera beaucoup moins de temps (et d'argent). Comme vous le savez déjà, le temps est compté lors du dépannage des bogues et des plantages de production - chaque minute qui peut être économisée fait une grande différence sur le résultat net. Bon codage !