L’observabilité : une décision de gouvernance avant d’être un projet d’outillage

Un article de notre expert formateur, Vincent BRANGER.

Le terme d’observabilité circule aujourd’hui dans les Directions des Systèmes d’Information sans que son périmètre soit stabilisé. Selon la fonction de celui qui l’emploie, il désigne la capacité à comprendre un incident sans en avoir anticipé la nature, la mesure d’une performance, la maîtrise d’un coût d’exploitation ou la détection d’un comportement anormal. Cette polysémie passe pour un problème de vocabulaire, qui se réglerait par une définition partagée en début de projet.

Elle recouvre en réalité quelque chose de plus embarrassant. Un ensemble de décisions structurantes se prennent chaque jour, dans toutes les organisations disposant d’une production informatique, sans que personne ne les ait formellement rendues. Ces décisions engagent le budget, la capacité d’investigation après incident, la conformité réglementaire et la charge des équipes d’astreinte. Elles sont prises par défaut, par des ingénieurs qui n’en ont ni le mandat ni les éléments, parce qu’elles se présentent sous une apparence technique.

La thèse défendue ici est que l’observabilité relève d’un arbitrage de gouvernance, et que la traiter comme un projet d’outillage explique la plupart des trajectoires décevantes constatées sur le sujet.

Les quatre acceptions du terme sont légitimes. Elles n’appellent pas les mêmes architectures, et cette divergence est mesurable.

Compréhension d’un incident

Répondre à une question que l’on n’avait pas formulée à l’avance suppose des traces distribuées, c’est-à-dire l’enregistrement du parcours d’une requête à travers les services successifs, avec propagation d’un identifiant de corrélation. La granularité doit être fine, la cardinalité élevée — le nombre de valeurs distinctes que peut prendre une étiquette — puisque c’est précisément l’identifiant de la requête défaillante que l’on cherchera. La durée de conservation, en revanche, peut rester courte : on investigue rarement un incident vieux de six mois. L’échantillonnage constitue le compromis habituel sur ce registre, en ne conservant qu’une fraction des parcours ; encore faut-il que la règle d’échantillonnage préserve les parcours en erreur, faute de quoi elle supprime précisément ce que l’on cherchait.

Mesure de performance et de capacité

Le besoin est inverse. Des métriques agrégées suffisent, la granularité peut être grossière, mais la conservation doit être longue pour comparer un exercice au précédent et objectiver une tendance.

Maîtrise des coûts

L’attribution d’une consommation à une application et à une entité budgétaire suppose un étiquetage rigoureux des ressources et un référentiel tenu à jour. Le sujet relève autant de la gestion patrimoniale que de la métrologie.

Détection d’un comportement anormal

La conservation d’événements bruts sur une durée souvent imposée par la réglementation ou par le contrat d’assurance, et la corrélation entre sources hétérogènes, constituent des exigences distinctes des trois précédentes.

Ces quatre besoins entrent en concurrence sur deux paramètres, la granularité et la durée de conservation, qui déterminent l’essentiel du coût. Aucune architecture ne les satisfait simultanément au même prix. Arbitrer entre eux est donc inévitable, et cet arbitrage n’apparaît jamais comme tel. Il se manifeste au moment du choix d’une plateforme, sous la forme d’un désaccord présenté comme technique alors qu’il porte sur l’objectif poursuivi.

Trois arbitrages illustrent ce déplacement. Chacun paraît relever de l’ingénierie ; aucun n’en relève réellement.

La définition du critique

La liste des règles d’alerte d’une organisation constitue la déclaration de fait de ce qu’elle tient pour critique. Cette liste s’est constituée par sédimentation : chaque incident marquant a laissé la sienne, sans que les précédentes soient retirées. Un ordre de grandeur souvent rencontré, donné ici à titre d’illustration, associe quelques personnes d’astreinte à plusieurs centaines de règles héritées dont l’origine s’est perdue. Personne n’a jamais validé cette liste en tant qu’expression des priorités de l’organisation, et pourtant elle en tient lieu : ce qui déclenche une intervention nocturne définit, en pratique, ce que l’organisation considère comme ne pouvant pas attendre. Un critère simple permet de reprendre la main sur ce stock : une alerte doit nommer une action et un délai, faute de quoi elle relève de l’indicateur et non de l’astreinte.

La durée de conservation

La rétention est traitée comme un paramètre de configuration. Elle constitue une décision engageant simultanément trois registres. Le budget, d’abord : les plateformes se facturent, à des degrés divers, sur le volume ingéré, la durée de conservation et le nombre de séries temporelles. Ce dernier point mérite une précision, car il est à l’origine de la plupart des dérives constatées : le nombre de séries résulte du produit des valeurs distinctes de chaque étiquette, de sorte qu’une étiquette contenant un identifiant d’utilisateur ou de requête transforme une série unique en plusieurs centaines de milliers. Le coût se décide donc à l’émission, dans le code et dans les configurations, et non à la signature du contrat. La capacité d’investigation, ensuite : une conservation trop courte interdit l’analyse des incidents récurrents à cycle long. La conformité, enfin, lorsque le secteur d’activité impose une durée minimale.

Le périmètre non couvert

Tout dispositif comporte des angles morts. Les plus fréquents se situent aux frontières : entre les équipes internes et l’infogérance, entre l’hébergement propre et les applications tierces en mode hébergé, entre le traitement synchrone et les files de traitement asynchrone, au niveau des passerelles d’interface applicative. Ces zones ne sont ni documentées ni arbitrées. Elles se découvrent en situation d’incident, au moment où leur existence coûte le plus cher. Elles déterminent par ailleurs ce que l’organisation est en mesure de démontrer devant un régulateur ou un assureur, puisqu’un événement non collecté ne se reconstitue pas après coup.

Si ces décisions restent orphelines, ce n’est pas par négligence. Quatre fonctions ont sur le sujet une revendication fondée, et aucune n’en détient le mandat complet.

• L’exploitation porte la contrainte opérationnelle et la charge d’astreinte ; elle optimise la réduction du bruit.
• L’ingénierie de fiabilité porte la méthode et les objectifs de service ; elle optimise la cohérence du dispositif.
• La sécurité porte une partie des exigences de conservation et de corrélation ; elle optimise la couverture.
• La direction informatique porte le budget et l’engagement pris devant les métiers ; elle optimise le rapport entre la dépense et le service rendu.

Chacune de ces optimisations est rationnelle dans son périmètre. Leur juxtaposition produit un ensemble localement cohérent et globalement incohérent. La prolifération d’outils que l’on impute d’ordinaire à l’immaturité des équipes s’explique bien mieux par ce vide de mandat : lorsqu’une fonction ne peut pas arbitrer, ajouter un outil demeure le seul geste qu’elle puisse poser seule.

La conséquence économique est directe. Une même donnée se retrouve collectée deux fois, par deux dispositifs poursuivant des finalités différentes, et facturée deux fois. La duplication ne résulte d’aucune décision : elle résulte de l’absence de décision. Elle est en outre difficile à corriger a posteriori, car chacun des deux dispositifs est justifié par les besoins de la fonction qui l’a mis en place, et aucune instance n’est fondée à trancher entre les deux.

L’émergence de standards ouverts, au premier rang desquels OpenTelemetry, répond à la fragmentation technique en normalisant l’instrumentation et le transport des données. Elle ne répond pas à la question de gouvernance. Une organisation qui n’a pas tranché ce qu’elle cherche à observer collectera les mêmes données incohérentes, dans un format désormais interopérable.

Une gouvernance explicite ne suppose pas la création d’une instance supplémentaire. Elle repose sur trois éléments.

Un objectif énoncé, d’abord : parmi les quatre registres décrits plus haut, celui sur lequel l’organisation investit en priorité, et la raison de ce choix.

Un propriétaire désigné, ensuite, disposant du pouvoir de refuser une source de données comme on refuse une dépense — un dispositif dont personne ne peut refuser l’extension croît indéfiniment.

Une revue périodique, enfin, portant non sur le fonctionnement du dispositif mais sur ce qu’il déclare implicitement. Trois questions suffisent à la conduire : la liste des alertes correspond-elle encore à ce que l’organisation tient pour critique, les durées de conservation retenues correspondent-elles à un usage constaté, et les zones non couvertes ont-elles été acceptées explicitement ou subies ? Cette revue relève d’un exercice annuel, non d’un comité permanent.

Cette gouvernance dispose d’un instrument technique qui lui correspond exactement. L’alerting fondé sur des objectifs de service consiste à définir un nombre restreint d’engagements, assortis d’un budget d’erreur, et à déclencher l’alerte sur la vitesse de consommation de ce budget plutôt que sur le franchissement d’un seuil isolé. Le nombre de règles diminue fortement, et chacune correspond à un engagement que l’organisation a explicitement décidé de tenir. La décision de gouvernance se traduit alors directement en règle technique, ce qui est la marque d’un arbitrage correctement posé.  La trajectoire qui en découle comporte trois étapes, dans cet ordre :

• Établissement de la situation réelle. Reprendre les incidents et les alertes d’une période récente, sur un périmètre d’astreinte, pour objectiver ce que le dispositif produit effectivement. L’exercice mobilise un tableur et une demi-journée.
• Arbitrage de l’objectif. Trancher le registre prioritaire, la durée de conservation associée et le périmètre accepté comme non couvert. Cette étape relève de la direction informatique et non de l’ingénierie.
• Choix de l’outillage. La question de la plateforme arrive en dernier. Elle devient simple lorsque les deux précédentes ont été traitées, et insoluble dans le cas contraire.

L’inversion habituelle consiste à commencer par la troisième étape, dans l’espoir que l’outil produise l’arbitrage. Il ne le produit pas ; il le fige. Une plateforme configurée sans objectif énoncé reconduit les décisions implicites qui existaient avant elle, avec une capacité d’ingestion supérieure et une facture qui suit.

Ce n’est donc pas l’observabilité qui est complexe. Ce sont les décisions qu’elle rend visibles, et que l’organisation avait jusque-là évité de formuler. Une direction informatique qui sait ce qu’elle veut observer choisit son outillage en quelques semaines. Une direction qui ne le sait pas ne le choisira jamais correctement, quel que soit le produit retenu.

Pour accompagner ces enjeux, Capgemini Institut vous propose le nouveau programme suivant :

Vincent Branger, consultant et animateur de la formation « Observabilité : de la supervision technique à la gouvernance stratégique du système d’information », soutient que les difficultés rencontrées sur ce sujet ne sont pas principalement d’ordre technique. Derrière le choix d’une plateforme se tiennent trois décisions — ce que l’organisation tient pour critique, ce qu’elle conserve et pour combien de temps, ce qu’elle accepte de ne pas voir — que personne ne rend explicitement. Il propose une trajectoire pour les reprendre en main.