Résultats pour l'industrie : Les équipes SRE sont excellentes pour répondre aux incidents. Les données qui réduiraient la fréquence des incidents se trouvent dans des journaux et des métriques que personne n'a le temps d'interroger de manière proactive.
par Madelyn Mullen
CAS D'UTILISATION
Intelligence de fiabilité de la plateforme & Métriques d'ingénierie
Les équipes d'ingénierie utilisent les données d'observabilité pour prévenir les incidents en surveillant continuellement les signaux et en interrogeant ces données de manière proactive afin d'identifier les risques qui s'accumulent avant qu'ils ne déclenchent une défaillance côté utilisateur. Les signaux peuvent inclure les tendances des taux d'erreur, les percentiles de latence, la fréquence de déploiement, les taux de consommation des SLO et d'autres éléments pertinents pour votre service. Le passage d'une réponse réactive aux incidents à une intelligence de fiabilité proactive nécessite deux choses : un accès unifié aux données de télémétrie à travers les services, et un moyen d'interroger ces données au rythme des décisions d'ingénierie. Lorsque les leaders de l'ingénierie peuvent demander "quels services approchent de leur seuil de budget d'erreur aux taux de consommation actuels ?" et obtenir une réponse en quelques secondes plutôt qu'en plusieurs jours, ils peuvent prendre des décisions d'atténuation avant que l'incident ne se produise. Les approches proactives protègent à la fois la disponibilité et la capacité de R&D qui serait autrement consacrée à la réponse d'urgence.
Votre organisation d'ingénierie n'est pas réactive par choix. Elle est réactive par architecture. Vous avez les données d'observabilité : métriques, logs, traces, budgets d'erreur, taux de consommation des SLO. Vous avez l'instrumentation. Ce qui vous manque, c'est un moyen de poser des questions à ces données au rythme que les décisions d'ingénierie exigent réellement. Au moment où la question peut être répondue, l'incident est déjà en cours.
Ce n'est pas un problème d'astreinte. C'est un problème d'accès aux données, et c'est la lacune que la plupart des organisations d'ingénierie n'ont pas encore identifiée.
Chaque incident imprévu a un coût commercial : temps d'ingénierie détourné du travail de feuille de route, confiance client érodée, exposition aux SLA et volume de support qui augmente en aval. La fiabilité n'est pas un problème d'hygiène d'ingénierie. C'est un problème de protection des revenus et d'efficacité de la R&D, et il mérite la même rigueur analytique que toute autre fonction commerciale.
Comme le dit Chase Holland, ingénieur logiciel principal chez The Trade Desk : « La partie la plus coûteuse de la création d'un produit n'est plus l'écriture du code anymore... C'est de décider quoi faire. Plus vous obtenez de bonnes données sur ce que vous devriez faire, meilleures et plus rapides seront les décisions que vous pourrez prendre. » Dans un contexte de fiabilité, cela signifie utiliser les données pour décider quel risque atténuer le lundi, afin de ne pas écrire de correctifs d'urgence le samedi.
Les plateformes d'observabilité modernes sont optimisées pour la réponse aux incidents : alerter en cas de violation, diagnostiquer, corriger. Elles ne sont pas conçues pour répondre à la question en amont qu'un VP de l'ingénierie a réellement besoin de voir résolue : quelles parties du système accumulent des risques de fiabilité qui se manifesteront sous forme d'incidents dans les 30 à 60 prochains jours ? Y répondre nécessite d'interroger les tendances des taux d'erreur, les tendances des percentiles de latence et les tendances d'utilisation de la capacité à travers des dizaines de services — sans attendre dans une file d'attente de requêtes de données. Les signaux existent. La capacité du leader de l'ingénierie à les lire de manière proactive n'existe pas.
L'intelligence de fiabilité est la pratique consistant à utiliser les données de télémétrie pour identifier de manière proactive les risques de fiabilité avant qu'ils ne se manifestent sous forme d'incident côté utilisateur. Des éléments tels que les métriques, les logs, les traces, les budgets d'erreur et les enregistrements de déploiement diffèrent de l'observabilité traditionnelle d'une manière critique : l'observabilité vous dit ce qui se passe en ce moment ; l'intelligence de fiabilité vous dit ce qui est susceptible de se produire dans les 7 à 30 prochains jours, en se basant sur l'analyse des tendances de votre portefeuille de services. Une organisation qui pratique l'intelligence de fiabilité n'attend pas une alerte de violation de SLO. Elle identifie qu'un budget d'erreur de service se consume à deux fois le taux normal un mardi matin et décide comment réagir avant que la rotation d'astreinte du week-end ne le ressente.
Les leaders de l'ingénierie dans les systèmes à grande échelle suivent les bonnes métriques : MTTR (temps moyen de résolution), fréquence des incidents, respect des SLO par service. Ces métriques vous disent à quel point votre équipe réagit bien. Elles ne vous disent pas ce qui s'en vient. Ce qui manque structurellement, c'est la question en amont : où le risque de fiabilité s'accumule-t-il avant de devenir une alerte, et combien ce risque coûte-t-il à l'entreprise en temps de développeur, en capacité de feuille de route et en confiance client ?
Les données pour répondre à cette question existent dans votre télémétrie. Elles ne sont pas sous une forme que les leaders de l'ingénierie peuvent interroger sans outils spécialisés ou support d'analyste. Votre équipe SRE est excellente pour réagir. Elle n'a pas les ressources pour interroger de manière proactive les données de tendance de centaines de services sur une base hebdomadaire. Ainsi, les signaux s'accumulent. L'incident se produit. Le MTTR s'améliore parce que votre équipe est entraînée. La fréquence des incidents ne diminue pas parce que l'analyse qui la réduirait n'a jamais été exécutée. Et chaque incident qui n'aurait pas dû se produire représente une capacité de R&D dépensée à éteindre des feux au lieu de livrer.
Le problème de la semaine est que l'une de nos lignes de produits connaît un ralentissement de sa croissance et nous essayons de comprendre pourquoi. Il est très difficile d'obtenir des informations et de savoir si on peut leur faire confiance une fois qu'on les a. — Un VP Produit chez une plateforme AI-Native
Le problème d'accès aux données se transforme en un problème de confiance dans les données. Ce cadre s'applique aux organisations d'ingénierie de toute taille : le diagnostic réactif est la norme car l'interrogation proactive des données de fiabilité est structurellement difficile, car l'analyse en amont qui la réduirait nécessite un accès aux données que les leaders de l'ingénierie n'ont pas à la demande. Et même lorsque vous obtenez une réponse, vous n'êtes pas toujours sûr qu'elle soit correcte. Le MTTR s'améliore. La fréquence des incidents ne diminue pas.
Sans cet accès immédiat, les réunions sur la fiabilité dégénèrent souvent en ce que Holland appelle des « négociations basées sur des opinions ». Lorsque les équipes manquent d'une source de vérité unique et fiable pour leurs données opérationnelles, elles passent des semaines à débattre de la cause d'une tendance plutôt qu'à la corriger. En passant à un modèle en libre-service, un leader mondial de la technologie publicitaire comme The Trade Desk a transformé ces semaines de débat en résolutions rapides et vérifiées, permettant à leurs équipes d'agir avec une intention beaucoup plus élevée.
Databricks Genie permet aux leaders de l'ing énierie d'interroger leurs données de télémétrie opérationnelles en langage naturel. Un VP de l'ingénierie peut demander : « Quels services ont montré des augmentations de latence p99 supérieures à 20 % au cours des 14 derniers jours, et quel est leur chevauchement de dépendance avec les services qui ont eu des incidents au T2 ? » Cette question est extraite de vos données d'ingénierie réelles en quelques secondes, pas en plusieurs jours.
Les questions de suivi deviennent naturelles. « Quels services approchent de leur seuil de budget d'erreur aux taux de consommation actuels, et quand prévoyons-nous une violation ? » Ou : « Quelle est la corrélation entre la fréquence de déploiement et le taux d'incidents sur mes services à plus fort trafic au T3 ? » Cette capacité ne se limite pas à des ensembles de données simples. Pour maintenir la visibilité sur un environnement massif de plus de 10 000 tables, The Trade Desk a construit un « Genie Router » qui dirige automatiquement les questions vers le bon environnement de données. Cela leur permet de maintenir une interface unique pour leurs équipes tout en gérant un niveau de complexité technique qui submergerait un tableau de bord standard. Chaque réponse provient de votre télémétrie réelle, des enregistrements de déploiement et de l'historique des incidents et devient directement interrogeable par tout leader de l'ingénierie, sans avoir à traduire la question pour un analyste au préalable.
Pour un leader de l'ingénierie dont les engagements de fiabilité sont aussi des engagements commerciaux — exposition aux SLA, confiance client et capacité de R&D consommée par les incidents — cette vitesse d'interrogation fait la différence entre une gestion proactive des risques et la résolution réactive des problèmes. Votre budget d'erreur n'est pas seulement une métrique technique ; c'est une ressource commerciale. Genie vous permet de le gérer comme tel. Le signal de fiabilité qui aurait justifié un sprint d'atténuation apparaît avant l'incident, et non pendant.
Étape 1 — Centralisez votre télémétrie. Rassemblez les métriques, les logs, les traces, les enregistrements de déploiement et l'historique des incidents dans un environnement de données unifié. Les outils fragmentés sont la principale raison pour laquelle l'analyse proactive ne se produit pas : les ingénieurs ne peuvent pas répondre à des questions inter-services lorsque les données de chaque service résident dans un système différent.
Étape 2 — Définissez des indicateurs avancés, pas seulement des indicateurs retardés. Le MTTR et la fréquence des incidents mesurent ce qui s'est déjà produit. Les indicateurs avancés mesurent ce qui est sur le point de se produire. Les équipes qui suivent la trajectoire du taux de consommation des SLO, la tendance de la latence p99, le budget d'erreur restant au taux de consommation actuel, ainsi que les indicateurs retardés, peuvent intervenir avant que l'alerte ne se déclenche.
Étape 3 — Activez l'interrogation en libre-service pour les leaders de l'ingénierie. L'analyse qui réduirait la fréquence des incidents est rarement exécutée car elle nécessite le soutien d'un analyste et une attente de 48 heures. Lorsque les leaders de l'ingénierie peuvent interroger leurs propres données de fiabilité en langage naturel — en demandant « quels services présentent la corrélation la plus élevée entre la fréquence de déploiement et le taux d'incidents ce trimestre ? » — la gestion proactive des risques devient une habitude hebdomadaire, et non un exercice trimestriel.
Les organisations d'ingénierie qui maintiennent une haute fiabilité dans des systèmes complexes et à grande échelle sont celles qui peuvent interroger leurs données opérationnelles de manière proactive et trouver les signaux de risque accumulé avant qu'ils ne se manifestent sous forme d'incidents côté utilisateur. Cela nécessite un accès aux données conçu pour le rythme de la prise de décision en ingénierie, et non pour le rythme des files d'attente de requêtes d'analystes.
Le cycle de l'information à l'action en matière de fiabilité de la plateforme se mesure en heures et en jours, et non en cycles de sprint. Lorsqu'une équipe d'ingénierie peut identifier une tendance de latence p99 le lundi matin et décider d'une approche d'atténuation avant le standup, elle opère sur l'intelligence de la fiabilité plutôt que sur la réponse aux incidents. Lorsque cette même question nécessite une demande de données et une attente de 48 heures, l'incident se produit en premier.
Pour les équipes d'ingénierie avec des SLA orientés client, cette rapidité a des conséquences commerciales directes. L'analyse ad hoc est 5 fois plus rapide avec Genie, ce qui signifie que la question de fiabilité qui aurait attendu deux jours pour un analyste est traitée avant le standup.
DATABRICKS GENIE · DIFFÉRENCIATEURS CLÉS
Conçu pour vos données, régi par vos règles, répondant à tout leader de l'ingénierie.
Q : Quelle est la différence entre l'observabilité et la surveillance pour la prévention des incidents ?
Réponse : Il faut distinguer la surveillance réactive (alertes lorsque quelque chose tombe en panne) de l'observabilité (comprendre l'état du système suffisamment bien pour prédire les pannes), en 2-3 phrases.
Q : Quels signaux d'observabilité sont les plus prédictifs des incidents à venir ?
Réponse : Il faut nommer le taux de consommation de SLO, la tendance de latence p99 et le taux d'erreur corrélé au déploiement comme les trois indicateurs avancés les plus exploitables — en 2-3 phrases.
Q : Comment Databricks Genie aide-t-il les équipes SRE à prévenir les incidents ?
Réponse : Il faut relier la capacité d'interrogation en langage naturel de Genie au cas d'utilisation spécifique de l'interrogation proactive des tendances — à partir du brouillon existant.
Q : Combien de temps faut-il pour passer d'une réponse réactive aux incidents à une intelligence de fiabilité proactive ?
Réponse : Il faut être honnête et pratique : la centralisation et l'outillage prennent généralement des semaines ; le changement culturel vers l'interrogation proactive prend 1 à 3 mois avec le bon accès en libre-service.
Q : Quelles métriques DORA les équipes d'ingénierie devraient-elles suivre pour améliorer la fiabilité ?
Réponse : Il faut nommer les quatre métriques DORA (fréquence de déploiement, délai d'exécution, MTTR, taux d'échec des changements) et noter que le taux d'échec des changements et le MTTR sont ensemble les plus forts prédicteurs de fiabilité.
Découvrez ce que Genie peut faire pour votre équipe
Si votre MTTR continue de s'améliorer mais que la fréquence des incidents ne diminue pas, l'écart n'est pas l'exécution — c'est l'accès proactif aux données. La fiabilité est un problème d'efficacité de la R&D. Découvrez comment les leaders de l'ingénierie utilisent AI/BI Genie pour le gérer comme tel.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.