Les 6 principaux défis de la surveillance du cloud dans les environnements hybrides et multiclouds

Les notions d'hybride et de multicloud semblent simples : exécuter certaines charges de travail dans le cloud public, en conserver d'autres sur site et connecter le tout. Mais en pratique, vous devez gérer des dépendances entre équipes et systèmes, des outils qui ne partagent pas le contexte et des incidents qui refusent de rester au même endroit.

La plupart des patrimoines mélangent des VM, des conteneurs, des services gérés et des dépendances SaaS sur site et dans un ou plusieurs nuages. Chacun d'entre eux connaît des défaillances différentes et a souvent un propriétaire différent.

L'accès, la conservation et la propriété deviennent de plus en plus difficiles à mesure que les anciens systèmes et les nouveaux services en nuage et SaaS sont soumis à des règles différentes et sont gérés par des équipes différentes. Et les incidents ne sont pas rares : Analyse annuelle des pannes par l'Uptime Institute suit les tendances des pannes et montre que les défaillances se produisent toujours, avec des coûts réels et des perturbations lorsque les équipes perdent la visibilité.

Lorsque la surveillance ne suit pas, vous perdez du temps lors d'incidents majeurs, de mises en production de routine et de conversations de planification où personne ne fait suffisamment confiance aux données pour prendre une décision que tout le monde peut soutenir.

Ces six défis liés à la surveillance de l'informatique en nuage sont omniprésents. Si vous en avez rencontré quelques-uns, vous êtes en bonne compagnie.

1) Des données de surveillance dispersées

Les environnements hybrides et multiclouds accumulent les outils de surveillance au fur et à mesure qu'ils se développent. La plupart des équipes finissent par répartir la visibilité sur plusieurs plateformes d'observabilité, ce qui rend plus difficile le maintien d'une vue partagée de ce qui se passe.

Tout d'abord, il y a les grands fournisseurs de services en nuage - Amazon CloudWatch, Azure, Google Cloud, Oracle Cloud Infrastructure - et, avec eux, leurs outils de surveillance natifs : Amazon CloudWatch, Azure Monitor, Google Cloud Monitoring, Oracle Cloud Infrastructure Monitoring. Prometheus s'exécute sur le cluster Kubernetes. L'équipe chargée des applications vit dans un outil APM, tandis que la mise en réseau dispose toujours de son propre système. Chaque outil a eu du sens lorsqu'il a été ajouté.

Cela signifie également plus d'endroits pour gérer les autorisations et la rétention, ce qui devient rapidement compliqué lorsque la surveillance couvre les fournisseurs, Kubernetes, SaaS et sur site, et que différentes équipes possèdent différents éléments. Le problème apparaît lorsque quelque chose se casse et que vous devez voir comment ils sont connectés.

Si vous avez déjà été de garde dans un domaine mixte, vous avez déjà vu cela. Les journaux d'application indiquent des erreurs à partir de 10:14, mais le tableau de bord de l'équipe de la base de données montre un pic à 10:11. Le graphique du réseau affiche également un pic à 10 h 09. Vous devez maintenant naviguer entre trois consoles différentes, en essayant d'aligner les horodatages, de déterminer quel pic a provoqué quel symptôme, et de décider si tout cela est lié au déploiement qui a eu lieu à 10:00.

Quelqu'un fait une capture d'écran de sa vue et la colle dans Slack. Quelqu'un d'autre dit : “Ce n'est pas ce que je vois”. Vingt minutes après le début de l'incident, vous êtes toujours en train d'établir une chronologie au lieu de tester un correctif, car chaque incident commence par la même taxe de réconciliation : faire correspondre les horodatages, traduire la terminologie et assembler un récit à partir de fragments qui n'ont jamais été conçus pour être connectés. Et si l'un de ces systèmes conserve les données pendant sept jours alors qu'un autre les conserve pendant trente jours, vous pouvez perdre le fil même après avoir trouvé la bonne chronologie.

La perte de temps est prévisible : vous passez la première partie de l'incident à corréler les données au lieu d'enquêter sur la défaillance.

Lorsque la surveillance fonctionne bien dans un environnement distribué, cette taxe disparaît en grande partie. Vous pouvez voir ce qui est lié sans ouvrir cinq onglets. La chronologie est déjà construite lorsque vous arrivez. Les erreurs d'application, la latence de la base de données et la congestion du réseau apparaissent toutes dans la même vue avec la même horloge, ce qui vous permet de consacrer votre temps à enquêter plutôt qu'à établir des corrélations. Un peu d'automatisation est utile, mais le véritable avantage réside dans le partage du contexte.

2) Surveillance des composants sans contexte de service

Un service orienté client est rarement une seule chose. Prenons un flux de connexion ou de paiement : il peut appeler un fournisseur d'identité (souvent dans un autre cloud ou en SaaS), exploiter une base de données, écrire dans une file d'attente, déclencher une fonction sans serveur et s'appuyer sur une API tierce. N'importe lequel de ces éléments peut se dégrader discrètement alors que le reste semble correct dans les tableaux de bord en temps réel.

Cependant, la plupart des contrôles sont organisés par couches d'infrastructure (serveurs, conteneurs, bases de données, réseaux), et non par le service que le client essaie d'utiliser. Cette lacune apparaît le plus clairement lorsque vous essayez de répondre à la seule question qui compte lors d'un incident : quel service en contact avec le client est touché, et à quel point.

Lorsque les alertes commencent à se déclencher, vous obtenez une liste : CPU élevée sur trois nœuds, temps de requête élevé sur la base de données, taux d'erreur accru sur la passerelle API. Tous ces signaux sont réels, mais aucun d'entre eux ne vous indique si les utilisateurs peuvent réellement se connecter ou effectuer un achat.

Le canal d'incident se transforme alors en un débat sur les priorités. Le pic de CPU est-il à l'origine du ralentissement de la base de données, ou une requête lente est-elle à l'origine du CPU ? Faut-il adapter les nœuds ou régler la requête ? Quelqu'un suggère de vérifier l'API tierce, mais personne n'est sûr qu'elle soit surveillée, et même si elle l'est, elle vit ailleurs. C'est là que de simples vérifications externes peuvent s'avérer utiles : si une connexion de base ou un chemin d'accès échoue, vous le saurez avant d'avoir lu la dixième alerte relative à l'infrastructure.

Lorsque vous confirmez l'impact sur les clients, ceux-ci l'ont déjà confirmé pour vous.

La confusion est de mise : les alertes sur les composants décrivent les symptômes, mais ne permettent pas de savoir avec certitude ce qui est menacé. La surveillance axée sur les services inverse l'ordre des choses. Vous commencez par un petit ensemble de signaux qui décrivent si le service est sain (latence, erreurs et disponibilité par rapport à la cible qui vous intéresse), puis vous reliez ces signaux aux dépendances sur lesquelles le service s'appuie. Si la caisse ralentit, vous pouvez voir immédiatement l'impact sur le client, et vous pouvez également voir si le coupable probable est l'identité, la latence de la base de données, l'arriéré de la file d'attente ou une API tierce.

Lorsque la surveillance prend en compte les services, le point de départ change. Vous pouvez voir que “la latence d'extraction augmente” et quelles dépendances sont impliquées, de sorte que l'équipe dispose d'une priorité claire et d'un chemin plus court vers la cause première. La surveillance des composants est toujours importante, mais elle prend en charge la vue des services au lieu de forcer chaque incident à commencer par un travail de détective.

3) Bruit d'alerte et triage lent

Les incidents inter-environnements mobilisent rapidement plusieurs équipes. L'équipe chargée de l'application voit des erreurs tandis que l'équipe chargée de la plateforme voit des redémarrages de pods. L'équipe de la base de données remarque l'épuisement du pool de connexions. L'équipe réseau détecte des pertes de paquets intermittentes. Les pagers se déclenchent à quelques minutes d'intervalle, et le rayon d'action n'est pas encore évident entre les fournisseurs, les clusters et les installations sur site.

Vous avez maintenant un canal Slack avec huit personnes. Trois d'entre elles étudient le même symptôme sous différents angles sans s'en rendre compte. Deux attendent que quelqu'un confirme qu'il s'agit bien de leur problème. L'un d'entre eux demande s'il est lié au déploiement d'hier. Les alertes continuent d'affluer et la conversation dérive parce que personne n'a une vision commune de ce qui est connu et de ce qui n'est que du bruit. La situation s'aggrave lorsque plusieurs outils de surveillance collectent les mêmes signaux, ou lorsqu'une surveillance trop bavarde transforme des blips de routine en un bourdonnement de fond constant.

Cela tient en grande partie à la manière dont les alertes arrivent : sous la forme d'un flux plat de notifications indépendantes. Vous pouvez recevoir des dizaines de pages sur plusieurs systèmes, toutes déclenchées par un problème sous-jacent, sans regroupement ni hiérarchisation. La première phase de l'incident consiste en un triage manuel - triage, déduplication et détermination de la personne qui devrait être présente dans la salle.

C'est pourquoi même les pannes “simples” peuvent sembler lentes. Avant de réparer quoi que ce soit, vous devez reconstituer le contexte.

Ce retard se répercute dans tous les domaines qui vous intéressent : temps plus long pour rétablir le service, impact plus important sur les clients et risque accru de ne pas respecter un accord de niveau de service simplement parce que l'équipe a passé les premières minutes à trier le bruit au lieu d'identifier la cause du problème. Les gens s'épuisent également. Lorsque le pager se déclenche constamment et que la moitié des alertes n'ont pas d'importance, les ingénieurs cessent de faire confiance au signal, même si la page suivante est réelle.

Le problème est le manque de structure autour de ces alertes. Les équipes sont également plus performantes lorsque les alertes reflètent l'impact sur le client, et pas seulement les seuils des composants, de sorte que vous n'êtes pas en train d'appeler huit personnes pour quelque chose qui semble seulement effrayant. Lorsque l'alerte fonctionne bien, elle se comporte davantage comme un flux d'incidents que comme un flot de notifications. Les symptômes connexes sont regroupés en un seul incident. Les nouveaux signaux mettent à jour le même fil au lieu de créer un nouveau bruit. L'équipe peut voir ce qui est cassé, ce qui est touché et ce qui a déjà été vérifié. La responsabilité est également plus claire : les alertes sont acheminées en fonction du service dégradé, et pas seulement de l'infrastructure qui crie le plus fort. C'est là que l'automatisation porte rapidement ses fruits.

4) Pics de coûts et faibles boucles de rétroaction

Le coût de l'informatique dématérialisée est un signal opérationnel. Dans un monde où l'on paie à l'usage (et même avec des contraintes de capacité sur site), les petites erreurs s'accumulent rapidement. Une politique de mise à l'échelle est mise à jour et n'est jamais annulée. Le volume de journalisation double du jour au lendemain. Un environnement de test continue de fonctionner parce que personne ne l'a arrêté. Une charge de travail commence à se comporter de manière inefficace et consomme tranquillement de l'espace de calcul. Parfois, l'augmentation des coûts est due à la surveillance elle-même (journaux volumineux, agents dupliqués ou collecte de données qui s'est développée discrètement au fil du temps parmi les fournisseurs et les environnements).

Le problème est que le coût et la performance vivent souvent dans des mondes différents. L'ingénierie surveille les tableaux de bord et les alertes. Les finances s'intéressent à la facturation. Lorsque les deux ne sont pas reliés, la boucle de rétroaction est rompue.

Un schéma courant se présente comme suit : une augmentation significative des coûts est signalée plusieurs semaines plus tard. Votre console de facturation indique un pic dans les dépenses de calcul dans une région. Quelqu'un commence à fouiller dans l'historique des déploiements et des changements de configuration pour trouver un indice. L'ingénieur qui a effectué le changement est difficile à retrouver, la raison du changement est enfouie dans un ticket, et le système fonctionne surdimensionné depuis suffisamment longtemps pour que l'argent ait déjà disparu, en particulier lorsque le pic est lié au trafic de sortie, d'interconnexion ou interrégional - des coûts qui apparaissent loin du service qui les a déclenchés.

L'autre modèle est celui de la capacité “au cas où”. Les équipes conservent des instances plus importantes et une marge de manœuvre supplémentaire parce que personne ne peut prouver qu'il est sûr de réduire la capacité. Les anciens environnements restent en place parce que le démantèlement semble risqué en l'absence de preuves que plus rien ne dépend d'eux. Au fil du temps, le coût devient le résultat par défaut de l'incertitude.

La gestion des coûts fonctionne mieux lorsqu'elle suit la même cadence que les opérations. Les dépenses doivent être visibles au moment où elles changent, et il doit être facile de relier ce changement à quelque chose de concret : un déploiement, un événement de mise à l'échelle, une modification de la journalisation ou un environnement qui n'a jamais été arrêté. Quelques garde-fous simples font une grande différence : des budgets par environnement, des alertes lorsque les dépenses sortent des schémas, et un étiquetage qui associe les coûts à un service ou à un propriétaire afin que l'équipe appropriée puisse agir rapidement.

La connaissance des tendances aide les équipes à anticiper la prochaine surprise. Même une vue élémentaire de l'évolution des dépenses - et de leur évolution probable si rien ne change - rend la budgétisation moins réactive et réduit la course à la fin du mois.

Le rightsizing consiste simplement à faire correspondre ce que vous payez à ce dont la charge de travail a réellement besoin. En pratique, il s'agit d'une boucle régulière : identifier les ressources constamment sous-utilisées, signaler les environnements inactifs ou orphelins, et effectuer un changement sûr avec un plan de retour en arrière - réduire la taille, échelonner les plannings pour les activités non productives, ou arrêter ce qui est vraiment inutilisé. Cette approche est d'autant plus efficace qu'elle est liée à la surveillance, car l'utilisation et l'état des services vous indiquent ce qu'il est prudent de réduire et ce qu'il est risqué de toucher. Bien menée, elle permet d'optimiser les coûts sans sacrifier la fiabilité, et elle favorise l'évolutivité car vous ne transportez pas partout une capacité “juste au cas où”.

Lorsque la visibilité des coûts est associée à l'utilisation et à l'état des services, il est possible de détecter les anomalies au plus près de leur apparition et de les relier à un changement spécifique. Lorsque vous envisagez un redimensionnement, vous pouvez valider l'impact par rapport au comportement réel du service au lieu de vous fier à votre intuition. C'est ce qui transforme le contrôle des coûts d'un projet de nettoyage périodique en une partie normale des opérations.

5) Les angles morts de la pile Internet

Certains des incidents les plus perturbateurs auxquels votre entreprise sera confrontée proviennent de l'extérieur de vos environnements en nuage et sur site. Ils apparaissent quelque part sur le chemin entre un utilisateur et votre service - DNS, comportement du CDN, routage du FAI, politiques SASE, liens privés, ou une API tierce qui commence soudainement à perdre du temps.

Lors d'un incident, vos mesures internes peuvent sembler correctes. Les temps de réponse de la base de données sont normaux. L'unité centrale et la mémoire sont stables. Les taux d'erreur n'augmentent pas dans votre région principale. Pendant ce temps, les utilisateurs du Royaume-Uni signalent des chargements lents, et vous ne pouvez pas les reproduire depuis les États-Unis.
L'équipe fait donc ce qu'elle fait : elle commence à exclure des choses. L'équilibreur de charge est vérifié. Le niveau applicatif semble correct. La base de données ne présente pas de tension évidente. Après cela, la conversation se transforme en “peut-être que c'est le DNS” ou “peut-être le CDN” parce qu'il n'y a pas de visibilité directe sur ces couches. Une version concrète de cette situation : une panne de résolveur DNS public peut donner l'impression que votre service est en panne même si votre pile est saine. Dans le cas d'un Incident 1.1.1.1 de Cloudflare, Une mauvaise configuration a déclenché un retrait de route global, et l'impact s'est manifesté par des échecs soudains d'accessibilité que les tableaux de bord internes de “vos” services n'auraient pas nécessairement expliqués d'eux-mêmes.

Si un service dépend d'une poignée de points de terminaison tiers, il est important de mettre en place des contrôles de santé de base et des voies d'escalade avant un incident.

Quelques heures plus tard, il se peut qu'un prestataire vous réponde qu'il ne voit rien d'anormal. Parfois, le problème disparaît de lui-même et l'autopsie se termine par une vague étiquette “externe” parce que personne ne peut prouver ce qui s'est passé. C'est la différence entre des clients qui ne peuvent pas passer de commandes et qui n'ont aucune idée de la raison, et le fait de savoir d'où vient la défaillance, même si la réponse se trouve en dehors des quatre murs de votre organisation. 

Même une petite visibilité de la pile Internet vous donne un élément concret à partager avec les fournisseurs et les clients, ce qui raccourcit les échanges et empêche l'incident de s'enliser.

Lorsque vous pouvez mesurer l'expérience en dehors de votre environnement, sur l'ensemble de votre pile Internet, vous pouvez voir où la dégradation commence et qui elle affecte. Vous pouvez constater que la latence est élevée à Londres mais normale à Francfort, ou que les défaillances se concentrent autour d'un fournisseur d'accès Internet spécifique. Vous pouvez également garder un œil sur les points de terminaison tiers critiques et détecter les dégradations avant qu'elles ne se transforment en échecs de vérification et en tickets d'assistance. Même lorsque la solution n'est pas entre vos mains, vous pouvez circonscrire l'enquête plus rapidement et communiquer l'impact en toute confiance entre les fournisseurs et les équipes internes.

6) Dérive de la configuration et déclin de la surveillance

Les environnements distribués ne restent pas longtemps sous la même forme. Des comptes, des abonnements et des projets sont ajoutés, des clusters sont reconduits, des services sont remaniés et la propriété change au fur et à mesure que les équipes se réorganisent. Si la surveillance n'évolue pas au même rythme, elle cesse de refléter ce qui est réellement en cours d'exécution. Cela est d'autant plus difficile dans les configurations hybrides et multiclouds que les systèmes hérités ne correspondent pas toujours aux conventions modernes de découverte ou de dénomination, et que la propriété peut être floue lorsque l'équipe d'origine a déménagé.

Ce décalage a tendance à apparaître au milieu d'un incident. Quelqu'un consulte le tableau de bord que l'équipe “utilise toujours” et se rend compte qu'il n'est plus à jour : il manque des dépendances plus récentes, il affiche encore des systèmes qui étaient censés être mis hors service et il n'aide guère à distinguer le signal du bruit.

La dérive se manifeste également en arrière-plan. Une ancienne alerte continue de se déclencher alors que le système sous-jacent a disparu. Un nouveau service est mis en service sans base de référence parce que personne n'était sûr de ce qui devait être mis en place, ou de qui était responsable de la mise en place. Des semaines plus tard, lorsque quelque chose tombe en panne, l'équipe n'a pas d'historique auquel se comparer, ni de seuils reflétant un comportement normal. Si vous ne conservez pas suffisamment d'historique pour savoir à quoi ressemblait la situation “normale” avant un changement, vous perdez l'un des meilleurs outils dont vous disposez lors d'une décision de retour en arrière.

L'exactitude de la surveillance exige une attention constante. Plus ce travail est manuel, plus il dérape, en particulier dans les environnements où les mises à jour sont fréquentes et où l'infrastructure en nuage est constamment remplacée.

La surveillance est plus efficace lorsque la découverte et l'intégration sont intégrées dans le flux de travail. Les nouvelles ressources sont prises en charge automatiquement et sont mises en ligne avec des valeurs par défaut raisonnables. Les lignes de base s'ajustent en fonction de l'évolution du trafic. Les systèmes obsolètes sont retirés des tableaux de bord et des alertes pour éviter de faire perdre du temps à qui que ce soit. Des normes claires sur la signification du terme “surveillé” facilitent grandement les choses, car les gens ne réinventent pas le processus chaque fois que quelque chose est expédié. L'automatisation est ce qui empêche ce flux de travail de s'effondrer au fur et à mesure que l'environnement se développe.

Conclusion

Les domaines hybrides et multi-cloud évoluent rapidement - nouveaux comptes, nouveaux clusters, nouvelles dépendances, nouveaux propriétaires. La surveillance tient le coup lorsqu'elle suit le rythme de ces changements et donne aux équipes un contexte partagé en cas de panne. Cela inclut la couche de service, les dépendances en dehors de votre environnement et les principes opérationnels de base (propriété, rétention et garde-fous) qui garantissent la fiabilité de la surveillance au fil du temps.

Lorsque c'est le cas, les incidents se déroulent plus rapidement car vous n'avez pas à reconstruire le calendrier à partir de zéro. Les mises en service semblent moins risquées car vous pouvez détecter l'impact à temps. Les décisions relatives aux coûts, aux performances et à la fiabilité sont plus faciles à prendre car les données sont suffisamment cohérentes pour qu'on s'y fie.

Un bon test est votre dernier incident majeur : si les 30 premières minutes ont été consacrées à réconcilier les données et à débattre du champ d'application, c'est le signe le plus clair de ce qu'il faut corriger ensuite.

FAQ