De la disponibilité à l’expérience : la transition pilotée par l’IA dans l’observabilité moderne

En 2001, IBM a rédigé un manifeste d’informatique autonome. La vision de l’informatique autonome a décomposé l’auto‑gestion en quatre piliers : l’auto‑optimisation, l’auto‑guérison, l’auto‑configuration et l’auto‑protection. J’étais chez Microsoft lorsque IBM a présenté cette vision informatique. Nous avons réagi en proposant des idées technologiques telles que le centre de données autonome, mais en fin de compte, c’était un rêve bien en avance sur son temps. Il n’existait aucun moyen pratique de concrétiser cette vision.

Pendant mes années chez Microsoft, j’ai fait partie de l’équipe derrière Clippy. Bien que l’assistant animé en forme de trombone fût tristement intrusif, l’idée sous‑jacente était solide : les ordinateurs doivent aider activement les humains à accomplir leur travail. Nous n’avions tout simplement pas la puissance de calcul ni l’IA nécessaires pour le rendre possible. 25 ans plus tard, nous le pouvons enfin.

Du niveau de service au niveau d’expérience

Le concept d’observabilité n’est pas né dans l’informatique. En 1960, l’ingénieur et mathématicien hungaro‑américain Rudolf E. Kálmán a introduit le terme « observabilité » pour décrire la précision avec laquelle un système peut être mesuré par ses sorties. Puis, en 2013, Twitter a adopté le terme dans une série d’articles de blog, affirmant en fait que la surveillance traditionnelle, à travers tous les outils commerciaux disponibles, était conçue pour une époque technologique différente et ne fonctionnait pas dans les architectures à l’échelle des microservices.

Imaginez cela comme un médecin examinant un patient. Il peut vérifier son pouls, prendre sa tension artérielle et observer d’autres caractéristiques externes afin d’évaluer indirectement la santé interne du patient. En informatique, nous devons faire de même. Lorsqu’il y a une fluctuation du pouls du patient, nous devons savoir si cela indique un problème au niveau du rein ou du foie. À l’échelle et à la complexité des opérations que Twitter gérait il y a même 20 ans (l’entreprise ne servait alors que 100 millions d’utilisateurs avec des tweets et flux en temps réel), l’observabilité nécessitait des outils et une approche de surveillance différents.

Les systèmes d’aujourd’hui sont devenus encore plus grands et plus complexes, avec des dépendances aux réseaux de diffusion de contenu, à la mise en cache et à la distribution de bitmaps, de polices, de fichiers JavaScript, etc., partout dans le monde. Comprendre réellement les performances des applications en conditions réelles n’est pas une tâche aisée.

Lorsque l’informatique reçoit une alerte à 4 heures du matin, quelqu’un doit sortir du lit et déterminer si le problème provient d’un secteur défectueux sur un disque dur ou d’un acteur malveillant tentant de pénétrer et de semer le chaos dans l’infrastructure. Peu importe lequel : en fin de compte, leur travail consiste à maintenir tous les systèmes en fonctionnement. Heureusement, pour évaluer la santé des applications aujourd’hui, nous pouvons exploiter toutes les télémétries disponibles : chaque dispositif réseau, chaque application, des milliers d’intégrations prêtes à l’emploi, le flux de tickets via JIRA ou Atlassian, et tant d’autres signaux.

C’est ici que les objectifs de niveau d’expérience (XLO) entrent en jeu. Vous avez probablement entendu parler des accords de niveau de service (SLA) et des objectifs de niveau de service (SLO), mais les XLO franchissent l’étape suivante en mesurant si vos clients et employés obtiennent le niveau d’expérience qu’ils souhaitent. Il s’agit de qualité, pas seulement de disponibilité. D’un point de vue technique, la seule façon d’atteindre les XLO est d’avoir une visibilité depuis la carte réseau (NIC) jusqu’au dispositif de l’utilisateur final.

En octobre dernier, AWS US‑EAST‑1 a connu une panne. Catchpoint a détecté le problème 16 minutes avant qu’Amazon ne le reconnaisse publiquement. Les clients disposant de cette visibilité ont pu réagir avant que leurs utilisateurs ne ressentent les conséquences de la panne.

La promesse de l’observabilité est comparable à Smokey Bear : détecter la présence de fumée avant qu’il n’y ait un incendie. Bien mise en œuvre, l’observabilité vous permet d’éteindre un feu de prairie avant qu’il ne devienne une conflagration qui ravage les Palisades en Californie. Smokey est le système d’alerte précoce capable de détecter ces petites volutes de fumée, quel que soit leur origine : un problème AWS, un problème Oracle, un problème GCP, un problème Microsoft Azure ou un dysfonctionnement dans votre infrastructure.

L’IA met à l’échelle les systèmes de sécurité

Aucun opérateur humain ne peut suivre les systèmes d’infrastructure d’aujourd’hui. La seule façon de surveiller les systèmes à grande échelle, en ingérant des pétaoctets de données de journalisation et des billions de métriques par jour, est d’utiliser l’IA.

Par exemple, supposons que vous souhaitiez suivre les performances de lecture/écriture d’un disque ou les dépassements de tampon d’entrée/sortie ou de paquets dans votre environnement réseau. Vous pouvez utiliser un seuil dynamique pour définir ce à quoi ressemble la normale, ou une méthode déterministe pour examiner les séries chronologiques sur la semaine, le mois, l’année passée, ou toute période que vous choisissez, et établir des seuils de performance normaux. Une fois cette analyse statistique réalisée, vous pouvez définir des niveaux à deux écarts‑type de la moyenne, de sorte que lorsqu’un événement se produit en dehors de cette plage, vous recevez une alerte indiquant que la performance est potentiellement anormale.

Cependant, les systèmes très complexes peuvent recevoir des milliers d’alertes par jour. Les tableaux de bord commencent à clignoter et les équipes sont sollicitées. Passer au crible toutes ces alertes n’est pas une utilisation judicieuse du temps des humains. En effet, Vectra estime que les organisations reçoivent en moyenne 2 992 alertes de sécurité par jour, dont 63 % restent non traitées.

Les outils d’IA peuvent réduire ces milliers d’alertes quotidiennes à seulement quelques dizaines. Je me souviens d’un cas où un problème unique sur une seule carte réseau d’une seule machine a généré 2 000 alertes en aval. Grâce à l’IA, le client a pu effectuer une corrélation des alertes et parvenir à une analyse de la cause première beaucoup plus rapide, qui a conclu qu’un seul problème à ce moment précis faisait passer l’ensemble du tableau de bord de l’entreprise au rouge.

L’IA rend l’informatique passionnante à nouveau

J’ai pris du temps après que Cisco a acquis Splunk en 2023. Au cours des deux années suivantes, j’ai vu mes amis et anciens collègues créer des entreprises pour exploiter l’IA de manières qui n’étaient pas possibles il y a même cinq ans. (Rappelez‑vous que si ChatGPT était un enfant humain, il aurait trois ans).

Les équipes informatiques ont besoin d’aide pour détecter la fumée avant que l’alarme ne se déclenche, pas de plus de tableaux de bord à contempler. Ils. D’une certaine façon, c’est le même problème que IBM, Twitter et même Microsoft avec Clippy essaient tous de résoudre.

C’est la raison pour laquelle j’ai décidé de replonger. La technologie a enfin atteint un point où nous pouvons tenir la promesse initiale d’observabilité et d’informatique autonome.