Supervision et SLA

Tout schéma de ce sujet suppose que vous en soyez informé

Redondance multi-AZ, vérifications de santé d'Auto Scaling, plan de reprise après sinistre testé : chaque schéma couvert jusqu'ici dans ce sujet suppose silencieusement quelque chose. Il suppose que vous découvrez qu'une panne est en train de se produire, idéalement avant un utilisateur, et que quelqu'un peut dire ensuite, avec des chiffres précis, à quel point le système a réellement été fiable. Cette leçon couvre les 2 volets : la supervision, qui est la façon dont vous êtes informé, et les SLA, qui sont la promesse documentée sur la fréquence à laquelle vous n'auriez pas dû l'être.

La supervision : métriques, journaux et alarmes

3 briques couvrent presque tout ce que fait une configuration de supervision. Une métrique est un nombre suivi dans le temps, l'utilisation moyenne du CPU, les requêtes par seconde, le taux d'erreur. Un journal est l'enregistrement d'un événement précis, une ligne indiquant exactement ce qui s'est passé et quand, utile pour enquêter après coup plutôt que pour observer une tendance. Une alarme surveille une métrique par rapport à un seuil et déclenche une action une fois ce seuil franchi pendant une durée définie.

Amazon CloudWatch est l'implémentation AWS de ces 3 briques : il collecte automatiquement des métriques depuis la plupart des services AWS, stocke et permet d'interroger des journaux, et permet de définir des alarmes par-dessus l'un ou l'autre. Un exemple concret : une alarme surveille l'utilisation moyenne du CPU sur des périodes de 5 minutes, et si elle reste au-dessus de 80 % pendant 3 périodes consécutives, l'alarme se déclenche, ce qui peut alerter une personne d'astreinte ou, en écho à la leçon précédente, alimenter directement une politique de suivi de cible d'Auto Scaling qui lance davantage de capacité. Azure Monitor et Google Cloud Operations jouent le même rôle sur leurs propres plateformes ; le vocabulaire change légèrement, mais métriques, journaux et alarmes restent les 3 mêmes briques partout.

SLI, SLO, SLA : mesurer, cibler, promettre

Ces 3 termes s'utilisent presque comme des synonymes dans une conversation informelle, et la frontière que teste l'examen entre eux mérite d'être apprise précisément.

Un Service Level Indicator (SLI) est une mesure quantitative de la performance réelle d'un service, comme le pourcentage de requêtes réussies. Un Service Level Objective (SLO) est la cible interne qu'une équipe fixe pour ce SLI, comme « nous visons 99,95 % de requêtes réussies ». Un Service Level Agreement (SLA) en est la version externe et contractuelle : une promesse faite aux clients qui, si elle n'est pas tenue, entraîne des conséquences financières, typiquement un crédit de service.

Pensez à un SLI comme au relevé du compteur de vitesse d'une voiture, à un SLO comme à la limite de vitesse que le conducteur s'engage en privé à respecter, et à un SLA comme à la promesse faite à un passager que le trajet ne dépassera pas une certaine vitesse, garantie par un remboursement si c'est le cas. La comparaison tient pour la relation entre mesurer, cibler et promettre, mais elle se brise sur 1 point : un SLI n'est généralement pas une lecture instantanée comme un compteur de vitesse, il est typiquement agrégé sur une fenêtre de temps, une heure ou un mois, pas un simple coup d'œil au tableau de bord.

Les fournisseurs fixent volontairement le SLO plus strict que le SLA. Si un SLA public promet 99,9 % de disponibilité, le SLO interne qui pilote les opérations quotidiennes pourrait être de 99,95 %, donnant à l'équipe une marge pour remarquer et réagir avant qu'une cible interne manquée ne devienne une promesse externe manquée et compensable.

Les neufs : ce que coûte un pourcentage de disponibilité en temps d'arrêt réel

Les chiffres de disponibilité se comparent souvent à la légère, « on est à 4 neufs », sans toujours mesurer ce que cela signifie réellement en heures. Chaque neuf supplémentaire divise le temps d'arrêt autorisé par environ 10, ce qui explique pourquoi le saut de 99,9 % à 99,99 % représente un engagement d'ingénierie bien plus lourd que ce que les chiffres seuls laissent penser.

La plupart des produits SaaS et des API visent 3 neufs. 5 neufs est réservé aux systèmes où même quelques minutes de temps d'arrêt annuel entraînent de réelles conséquences financières ou de sécurité, et cela coûte proportionnellement plus cher à concevoir.

Exemple chiffré : lire un vrai SLA

Le SLA d'Amazon EC2 constitue un cas concret utile. Il s'engage sur un pourcentage de disponibilité mensuelle au niveau région d'au moins 99,99 %, et séparément sur un pourcentage de disponibilité au niveau instance d'au moins 99,5 % pour les instances individuelles. Si la disponibilité réelle au niveau région tombe en dessous sur un mois donné, les paliers de crédit sont de 10 % pour 99,0 % jusqu'à (mais sans l'atteindre) 99,99 %, 30 % pour 95,0 % jusqu'à (mais sans l'atteindre) 99,0 %, et 100 % en dessous de 95,0 %.

Concrètement : si la disponibilité EC2 au niveau région atteint 98,5 % sur un mois, cela tombe dans la tranche de 95,0 % à moins de 99,0 %, et le client a droit à un crédit de 30 % sur la facture de ce service pour le mois, appliqué automatiquement ou sur demande selon le fournisseur, pas un remboursement en espèces et pas une compensation pour les revenus que la panne a pu coûter à l'activité du client.

Ce qu'un SLA promet, et ce qu'il ne promet pas

Il est tentant de traiter « garanti par un SLA » comme « ceci ne tombera jamais en panne » ou comme une assurance contre les pertes commerciales. Ni l'un ni l'autre n'est vrai. Un SLA est un mécanisme de compensation pour le manquement du fournisseur à son propre engagement publié, versé sous forme de crédit sur les factures futures. Il exclut couramment les fenêtres de maintenance planifiée et les facteurs hors du contrôle du fournisseur, et, tout comme le modèle de responsabilité partagée vu plus tôt dans ce domaine, il ne couvre jamais que le propre service du fournisseur. Une panne causée par un bug dans le propre code applicatif du client reste son problème de fiabilité à superviser et corriger ; aucun SLA de fournisseur n'a jamais été écrit pour la couvrir.

Frontière : enchaîner des services rend le chiffre global pire, pas meilleur

Une charge de travail dépend rarement d'1 seul service. Enchaînez 3 services avec des disponibilités individuelles de 99,99 %, 99,95 % et 99,9 %, et il est tentant de supposer que le plus fort tire la moyenne vers le haut. Ce n'est pas le cas : la disponibilité composite multiplie les probabilités individuelles plutôt que de les moyenner, donc 99,99 % multiplié par 99,95 % multiplié par 99,9 % donne environ 99,84 %, moins bon que n'importe quel composant seul de la chaîne. Chaque dépendance ajoutée est une taxe sur la fiabilité globale, ce qui explique exactement pourquoi les architectes comptent combien de services touche réellement un chemin de requête critique, pas seulement la fiabilité de chacun pris isolément.

Repères d'examen : faire correspondre un scénario au bon terme

Où cela vous mène

Un SLA est un contrat de compensation fixé à un plancher en dessous de ce que le fournisseur vise en privé pour lui-même, jamais une garantie que rien ne tombera en panne, et la supervision est ce qui vous dit réellement, en temps réel, si aujourd'hui est l'un des jours où ce plancher est testé. Cela clôt Sécurité et fiabilité : vous savez désormais nommer qui porte quelle tâche de sécurité, comment les systèmes restent en ligne malgré une panne, comment ils récupèrent d'une panne plus grande que ce que la redondance pouvait absorber, et ce qu'une promesse de disponibilité signifie vraiment quand elle n'est pas tenue. Le prochain domaine passe de ce que vous savez à où cela vous mène : les carrières dans le cloud et le parcours de certification vers lequel ce cours construit depuis le début.