Atténuer les pannes logicielles : déplacer l’observabilité vers la gauche

L’adoption croissante du développement d’applications conteneurisées et cloud natives a considérablement amélioré l’agilité et les pratiques DevOps ainsi que les offres innovantes et évolutives. Les organisations sont en mesure de déployer rapidement leurs logiciels en production et de réduire les dépendances logicielles internes entre les services.

C’est un résultat positif et les organisations ne ralentissent pas ; ils cherchent à améliorer ces pratiques grâce à l’adoption de pratiques GenAI et d’ingénierie de plate-forme.

Les résultats les moins positifs de ces technologies complexes sont souvent le manque de contrôle sur les services de base et centrés sur l’entreprise dès le moment où ils sont déployés en production et utilisés par les clients.

Il existe une déconnexion évidente entre les développeurs et leurs applications actives en production, en raison des processus et outils actuels tels que la performance et la surveillance des applications (APM) et d’autres solutions d’observabilité générale. Ils servent principalement des personnages opérationnels et sont par nature plus lents à tirer parti d’une panne. Il existe un besoin impératif de donner aux développeurs les moyens de prendre le contrôle de leurs applications dans tous les environnements, et cela ne peut être réalisé qu’en déplaçant l’observabilité vers les développeurs.

Causes profondes les plus courantes des pannes logicielles

Les données Lightrun, ainsi que les recherches récentes de Microsoft, mettent en évidence les principales causes des pannes logicielles et des problèmes critiques P1-P2 rencontrés par les entreprises et les groupes de développement d’applications modernes. La liste ci-dessous est classée par ordre de priorité, de la cause première la plus élevée et la plus courante à la plus basse :

• Bogues de code
• Échec de la dépendance
• Problèmes d’infrastructures
• Erreur de déploiement
• Bogue de configuration
• Panne de base de données/réseau
• Échec de l’autorisation
• Autre

Chacune des causes profondes des incidents de production mentionnées ci-dessus nécessite des mesures d’atténuation spécifiques, allant de la restauration des logiciels aux ajustements de l’infrastructure et aux correctifs de configuration. Il est essentiel de comprendre l’impact significatif de ces incidents critiques sur les opérations commerciales et la réputation de la marque.

Prenons par exemple la récente panne qu’a connue Sainsbury’s, la deuxième plus grande chaîne de supermarchés du Royaume-Uni. Cet incident signalé a non seulement perturbé l’expérience client, mais a également porté un coup dur aux revenus de l’entreprise. De même, dans un autre segment de marché, le site Web et l’application d’assurance de State Farm ont été paralysés pendant plusieurs jours, ce qui a gravement entravé sa capacité à servir les clients.

Il est essentiel de reconnaître que la résolution de chacune de ces pannes est un processus long et coûteux, exacerbé par les limites des outils APM actuels et l’approche déconnectée entre les équipes de développement et d’exploitation. Selon les recherches de Microsoft, les pannes résultant de bogues de code entraînent le temps moyen de résolution (MTTR), le temps d’atténuation (TTM) et le temps de détection (TTD) les plus longs.

Déplacement vers la gauche de l’observabilité des développeurs

Le concept fondamental implique d’intégrer l’observabilité dès le début du cycle de vie du développement logiciel (SDLC), mais qu’est-ce que cela signifie en termes pratiques ?

• Accès aux données en direct en temps réel : Les méthodologies de développement existantes traitent souvent l’observabilité comme une procédure statique et réactive. Idéalement, les développeurs devraient avoir un accès en temps réel aux données d’observabilité dans le cadre d’un processus de développement moderne. Dans les implémentations modernes d’ingénierie de plate-forme et de mise en place d’une plate-forme de développement interne (IDP), une plate-forme d’observabilité fera partie intégrante de la pile d’outils des développeurs.
• Données contextualisées : Si les outils d’observabilité traditionnels excellent dans l’agrégation et l’indexation des données, ils sont avant tout adaptés aux besoins des équipes opérationnelles. La plupart des solutions d’observabilité comportent des tableaux de bord complexes inondés d’informations couvrant l’ensemble du système. Cependant, les développeurs ont généralement besoin de données spécifiques au code sur lequel ils travaillent actuellement. En corrélant et en affinant les journaux, les métriques et les traces dans le contexte du code des développeurs, les informations essentielles peuvent être efficacement mises en évidence.
• Approche centrée sur le développeur : De même, les outils d’observabilité doivent s’aligner sur le flux de travail naturel des développeurs. Plutôt que d’obliger les développeurs à passer à un autre tableau de bord, les données doivent être présentées dans un onglet. Cet onglet doit être directement intégré à leur IDE. Même si cela semble mineur, minimiser les changements de contexte est crucial pour maintenir la productivité et rationaliser les opérations.
• Instrumentation dynamique : Enfin, les développeurs doivent posséder la capacité d’incorporer dynamiquement de nouvelles fonctionnalités d’observabilité en temps réel sans nécessiter de modifications de code ni subir le cycle typique de construction et de déploiement. Cela permet non seulement de gagner du temps en termes de déploiement de code, mais également de réduire les coûts, car les développeurs ne sont plus obligés d’ajouter une instrumentation statique de manière préventive.

Les avantages découlant du déplacement de l’observabilité des développeurs vers la gauche peuvent être classés en trois piliers principaux :

1. MTTR réduit (temps moyen de résolution) :

• Protection renforcée des revenus et atténuation des risques
• Efficacité accrue dans la gestion des incidents
• Diminution de la fréquence des incidents critiques P1

2. Productivité améliorée des développeurs :

• Diminution substantielle du temps de débogage des développeurs

3. Réduction des coûts globaux d’observabilité :

• Réduction des dépenses en journaux statiques
• Coût total de possession (TCO) réduit pour les outils APM

Mot de clôture

L’adoption d’une observabilité décalée vers la gauche représente une tendance émergente parmi les équipes d’ingénierie logicielle hautement performantes. Conscientes des limites de l’observabilité statique et réactive, ces équipes ont compris qu’il était impossible de se contenter d’enregistrer davantage de données et de différer la résolution.

En intégrant l’observabilité plus tôt dans le SDLC, ces équipes hautement performantes produisent non seulement un code plus propre et plus efficace, mais atténuent également les défis opérationnels associés au débogage, à la réponse aux incidents et à la gestion d’un volume considérable de mesures d’observabilité. Résoudre les pannes comme celles mentionnées ci-dessus en temps opportun – en quelques minutes ou quelques heures plutôt qu’en jours – ou même prévenir de tels problèmes en premier lieu sont des avantages évidents de cette pratique.

Eran Kinsbruner est responsable mondial du marketing produit et de la stratégie de marque chez Lightrun et auteur à succès. Il a été finaliste évangéliste DevOps de l’année en 2021 pour DevOps.com. Ses livres publiés incluent le best-seller d’Amazon 2016 « The Digital Quality…

Lire la suite de Eran Kinsbruner