Comment Éliminer l'Anxiété, Réduire Temps de Résolution des Incidents (MTTR) et Respecter le Budget lors de la Gestion des Incidents Depuis mon entrée dans le monde de la technologie en 1992, j'ai souvent été confronté à l'obligation de "faire plus avec moins". Que ce soit en offrant plus de fonctionnalités avec une équipe réduite ou en travaillant avec des ressources matérielles limitées, cette approche a toujours été prévalente. Un exemple marquant est mon rôle d'architecte backend sur un projet de modernisation cloud, où le besoin de réduire les coûts nous a forcé à minimiser ou à éliminer totalement les journaux de service, essentiels pour le débogage et l'analyse des incidents. Cette décision était motivée par le coût élevé de l'ingestion de journaux sur notre plateforme de surveillance. Nous Avions Vraiment Besoin de Ces Journaux ! Un jour, comme c'était inévitable, un problème imprévu s'est manifesté, et nous avons eu besoin de ces journaux absents. En effet, ils étaient les seuls moyens de localiser la cause première. Sans eux, des heures passèrent sans solution, l'incertitude augmenta et l'anxiété gagna l'ensemble de l'équipe. Un simple journal structuré, comme celui ci-dessous, aurait pu être filtré avec une requête de journal basique. json { "timestamp": "2025-03-21T14:05:03Z", "service": "preference-engine", "level": "ERROR", "message": "Worker queue overflow: unable to dispatch to worker pool", "requestId": "abc123", "userId": "admin_42" } Cette requête : sql _sourceCategory=prod/preference-engine "Worker queue overflow" | count by userId, requestId aurait permis de comprendre, de diagnostiquer et de corriger le problème rapidement. Mais sans les journaux, nous avions perdu notre principale assurance. Lean Ne Doit Pas Signifier une Pénurie de Ressources L'idée de "faire plus avec moins" n'est pas intrinsèquement mauvaise. De nombreuses startups réussissent en se concentrant sur leurs priorités clés et en utilisant des logiciels légers et efficaces. Un design minimaliste peut conduire à une meilleure qualité, à condition que les outils essentiels soient maintenus. Cependant, dans notre cas, cette approche était déroutante et notre deadline pour le passage au cloud était intransigeante. Nous devions réécrire des services en design natif cloud, coordonner avec les équipes clients et travailler sous pression, sans avoir le temps d'une couverture de tests complète ou d'intégrations profondes en matière d'observabilité. Au fil du développement, nous insérions les journaux nécessaires pour chaque méthode, mais quand il a fallu réduire drastiquement les journaux, l'équipe a été exposée. Notre filet de sécurité principal avait disparu. Cause Première Sans Filet de Sécurité Les tests internes se sont déroulés sans encombre. En approche de la production, nous étions confiants dans notre nouvelle architecture cloud. Nous avions résolu les problèmes connus en test et respecté notre calendrier. Mais très vite, cette confiance s'est révélée mal placée et nos tests n'étaient pas assez complets. Lorsque les vrais utilisateurs ont commencé à utiliser le platform, des cas marginaux non anticipés sont apparus. Sans détails sur les journaux ni une observabilité suffisante, il nous était impossible d'enquêter sur ces problèmes. Les données limitées ne nous donnaient pas l'information nécessaire pour déterminer ce qui s'était passé. Si nous avions eu les journaux pour les tests backend et les utilisateurs frontend, nous aurions su quoi faire et informé immédiatement l'équipe et les utilisateurs. Une requête de journal comme celle-ci aurait été utile : sql _sourceCategory=prod/preference-engine OR prod/frontend error | join ( _sourceCategory=prod/tester-feedback “queue error” ) on requestId | fields requestId, _sourceCategory, message Mais sans les journaux, la reproduction des incidents localement était presque impossible. Il y avait simplement trop de variabilités dans les cas d'utilisation réels. Nous avons tenté de réactiver une partie des journaux, mais cela a conduit à des coûts d'ingestion élevés, sans fournir de véritables insights opérationnels. Dans certains cas, nous n'avons même pas pu identifier la cause première, ce qui a engendré un sentiment de dépit et d'impuissance. MTTR versus Qualité des Signaux Un autre problème majeur était que, lors des retrospectives d'incidents, le temps moyen de résolution des incidents (MTTR) était considéré comme une métrique clé. Pourtant, nous avons constaté que le MTTR n'était souvent qu'un symptôme, pas une cause. Les statistiques de l'industrie montrent que les équipes élites atteignent un MTTR inférieur à une heure. Mais nous avons compris que la vitesse n'est pas seulement une question d'automation. C'est aussi une question de signaux de haute fidélité. Les erreurs génériques (comme les erreurs 500) ou les alertes tardives provenant de métriques agrégées ne sont pas vraiment utiles. Elles introduisent plutôt l'ambiguïté et gaspillent des ressources précieuses (comme le temps de triage et le budget pour les journaux). En revanche, des signaux détaillés et contextualisés, tels que des journaux structurés avec des identifiants utilisateur, des identifiants de requête et des traces de service, permettent de cibler directement la cause première. Les plateformes d'observabilité peuvent réduire le MTTR, mais seulement si les données ingérées sont actionnables. Si vos journaux ne répondent pas à ces questions, votre MTTR n'est pas une mesure de la rapidité de l'équipe, mais plutôt une indication de la clarté des signaux. Comment le Modèle de Sumo Logic Aurait Pu Sauver la Situation Que nous aurait apporté un meilleur model pour ma gestion des incidents lors du projet de modernisation cloud ? Nous aurions eu besoin d'une analyse plus poussée des journaux et d'une surveillance de performance des applications (APM). Avec cet APM, la gestion des journaux, les moniteurs de service, les alertes et des métriques définies en corrélation avec le succès ou l'échec fonctionnel auraient été au rendez-vous. Pour chaque nouvelle fonctionnalité, j'aurais disposé d'une métrique associée à son succès. Je veux récupérer mes journaux ! Dans mon précédent article, "DevSecOps : Il est Temps de Payez pour votre Demande, Pas pour l'Ingestion", j'ai exploré comment Sumo Logic a perturbé le secteur de l'observabilité en proposant un modèle de paiement par analyse. Les journaux peuvent être ingérés de manière continue, mais vous ne payez que lorsque vous avez besoin de les interroger ou de les analyser. Avec une ingestion zéro-coût, les équipes peuvent enregistrer autant de données qu'elles le souhaitent sans crainte. Et en cas d'incident, l'analyse peut être lancée à la demande, au coût justifié et directement lié à l'impact client ou à la continuité du business. Ainsi, les responsables budgétaires et les équipes sont contentes. Ce modèle permet de restaurer le contrôle et de diminuer l'anxiété, car les équipes sont habilités à enquêter en profondeur aux moments cruciaux. L'Étape Supplémentaire : Une Traçabilité Assistée par la Machine Mais il y a encore un autre élément crucial. L'observabilité moderne n'est pas seulement une question de posséder de superbes données de journal, mais aussi de savoir où chercher dans cette masse de données. Avec une ingestion illimitée, vous avez d'énormes volumes de données. Or, quand vous cherchez des informations, vous avez besoin d'un point de départ. Sumo Logic offre des outils de tri assisté par la machine qui regroupent automatiquement les comportements anormaux, détectent les valeurs aberrantes et présentent des signaux corrélés entre les services, avant même que vous n'écriviez la moindre requête. Derrière le rideau, Sumo Logic utilise des algorithmes statistiques et l'apprentissage automatique pour accomplir cela. Par exemple, une commande comme la suivante : sql _sourceCategory=prod/* error | logreduce clusterise les données bruyantes des journaux en catégories d'actions concrètes : Error: Worker queue overflow **Error: Auth token expired for user *** **Error: Timeout in service *** Une fois regroupées, les équipes peuvent pivoter vers des contextes plus détaillés : sql | where message matches "Auth token expired*" | count by userId, region Résultats : Moins de recherches aveugles, des chemins de décision plus rapides et moins d'anxiété lors d'un incident. Conclusion La philosophie de "faire plus avec moins" ne doit pas placer les équipes d'ingénierie en situation défavorable. Elle doit être accompagnée des bons outils. Sans eux, même les meilleures équipes peuvent naviguer à vue lors d'un incident, causant frustration et stress. Mes lecteurs se souviendront de ma déclaration personnelle, applicable à tout professionnel des TI : "Concentrez votre temps sur la livraison de fonctionnalités qui maximisent la valeur de votre propriété intellectuelle. Utilisez des frameworks, des produits et des services pour tout le reste." — J. Vester Dans cet article, nous avons vu comment un modèle d'ingestion zéro-coût aligne cette mission. Il aide les équipes à identifier rapidement les causes premières, à réduire le temps d'arrêt et à diminuer le niveau de stress, tout cela sans exorbiter le budget. Gardons donc ces journaux ! Évaluation de l’Événement par des Professionnels de l’Industrie et Profil de l’Entreprise Évaluation de l’Evénement : Des professionnels de l'industrie soulignent que l'exemple presented illustre parfaitement le dilemme entre optimisation budgétaire et efficacité technique. Une approche équilibrée, intégrant des solutions d'observabilité comme celle de Sumo Logic, est essentielle pour maintenir la compétitivité et la satisfaction client. Le modèle de paiement par analyse est particulièrement apprécié pour sa flexibilité et sa capacité à réduire les coûts tout en améliorant l'efficacité opérationnelle. Profil de l’Entreprise : Sumo Logic est une entreprise leader dans le domaine de l'observabilité, reconnue pour ses solutions de gestion des journaux, de surveillance des performances des applications et d'analyse des données. Elle propose un modèle de tarification basé sur l'usage, permettant aux équipes technologiques de conserver de détaillées et actionnables sans contrainte de coût excessive. Sumo Logic vise à rendre les équipes plus agiles et plus efficaces, tout en offrant des outils intelligents pour la traçabilité et l'analyse des incidents.