Exploiter un environnement cloud au quotidien

Déployer une infrastructure cloud prend quelques heures ; l'exploiter dure des années, et c'est là que se jouent les mauvaises surprises. Le fournisseur reprend à son compte une partie du travail d'exploitation, mais il décide aussi, à votre place, du moment où votre machine redémarre et de la date à laquelle votre base de données change de version. Cette leçon décrit ce qui reste à votre charge au quotidien, les événements imposés qu'il faut anticiper, et les pièges d'exploitation propres au cloud : les quotas, le coût de l'observabilité (la capacité à comprendre l'état d'un système par ses journaux, ses métriques et ses traces) et la capacité qui se mesure en limites de compte plutôt qu'en matériel.

Ce que vous allez apprendre

• Distinguer ce que le fournisseur exploite de ce qui reste à votre charge.
• Anticiper les redémarrages et montées de version qu'il vous impose.
• Reconnaître un quota atteint, qui se présente comme une panne applicative, et nommer les familles de plafonds et leurs pièges.
• Maîtriser le coût de l'observabilité en agissant sur la rétention et l'émission.
• Prévoir la capacité en projetant la consommation sur les limites du compte.

Prérequis : avoir compris le partage des responsabilités entre fournisseur et client, présenté dans Responsabilités partagées.

Cette leçon ne redéfinit ni les SLI et SLO (indicateurs et objectifs de niveau de service), ni les principes d'une bonne alerte : ces sujets sont traités en profondeur dans SLI, SLO et error budget et Alerting efficace, et ils ne changent pas parce que vous êtes dans le cloud. Ce qui change, c'est ce qui suit. Les journaux, les alertes, la conduite d'un incident et les changements ont leur propre leçon, Exploiter : journaux, alertes, incident et changements.

Qui exploite quoi, exactement ?

Le fournisseur exploite l'infrastructure sous votre service ; vous exploitez tout ce qui se trouve au-dessus. La frontière se déplace selon le type de service, et c'est précisément cette ligne mouvante qui produit les malentendus, comme l'explique la page sur les responsabilités partagées. Le tableau compare trois niveaux de service : une machine virtuelle que vous administrez, une base de données managée (le fournisseur l'exploite, vous l'utilisez) et une fonction serverless (du code exécuté à la demande, sans serveur à gérer).

Tâche d'exploitation	Machine virtuelle	Base de données managée	Fonction serverless
Remplacer un disque défaillant	fournisseur	fournisseur	fournisseur
Appliquer les correctifs du système	vous	fournisseur	fournisseur
Décider de la version du moteur	vous	vous, dans une fenêtre imposée	fournisseur
Surveiller la saturation disque	vous	vous	sans objet
Sauvegarder et vérifier la restauration	vous	vous	vous
Répondre à une alerte à 3 heures du matin	vous	vous	vous

Glissez pour voir

La dernière ligne est la plus importante et la plus souvent oubliée. Aucun modèle de service, pas même le serverless, ne transfère au fournisseur la responsabilité de votre disponibilité applicative. Il garantit son service, pas le vôtre : si votre code appelle une base saturée, personne d'autre que votre équipe ne se lèvera.

Les événements que le fournisseur vous impose

Votre machine virtuelle redémarrera un jour sans que vous l'ayez décidé. Le matériel physique qui l'héberge doit être mis à jour ou remplacé, et les trois grands fournisseurs traitent ce moment différemment. C'est un critère de choix rarement regardé, alors qu'il conditionne votre travail d'exploitation.

Fournisseur	Comportement lors d'une maintenance de l'hôte	Ce que vous devez prévoir
Google Cloud	migration à chaud de la machine, sans interruption pour la plupart des types	peu de préparation, sauf sur les types exclus de la migration
AWS	notification d'un événement planifié, redémarrage ou mise hors service programmée	agir avant la date, ou subir le redémarrage
Azure	maintenance planifiée annoncée, service de métadonnées interrogeable	déclencher soi-même la bascule pendant une fenêtre choisie

Glissez pour voir

Une notification de mise hors service n'est pas une alerte de supervision, et c'est le piège. Elle arrive par courriel sur l'adresse du compte, ou dans un tableau de bord de santé que personne ne consulte. Traitez ce canal comme une source d'alertes à part entière : redirigez-le vers l'équipe technique, pas vers la boîte administrative où il finira non lu.

La conséquence architecturale de cette contrainte

Le redémarrage imposé est la meilleure raison de concevoir des services sans état persistant sur la machine. Si votre application survit à la disparition brutale d'une instance, une maintenance de l'hôte devient un non-événement, et non une opération à planifier un dimanche soir.

C'est le raisonnement développé dans Loose coupling et stateless design : dans le cloud, la machine est jetable par nature, et l'exploitation en tire les conséquences ou les subit.

Pourquoi une montée de version managée se prépare

Un service managé ne vous dispense pas des montées de version, il vous en retire le calendrier. Chaque moteur de base de données a une date de fin de support chez le fournisseur, et à cette date deux issues seulement : vous avez migré, ou le fournisseur migre à votre place pendant une fenêtre de maintenance qu'il choisit. Certains proposent en outre un support étendu payant, dont le surcoût est une bonne façon de découvrir qu'on avait oublié le sujet.

La règle d'exploitation qui en découle tient en trois gestes :

1. Inventoriez les versions de moteur que vous utilisez, avec la date de fin de support annoncée par le fournisseur. Cet inventaire se tient au même endroit que le reste, dans votre outil d'infrastructure as code.

2. Testez la montée sur une copie restaurée, pas sur l'environnement de recette qui a divergé depuis six mois. Restaurer une sauvegarde de production dans un compte isolé coûte quelques euros et une heure.

3. Déclenchez la migration vous-même, dans une fenêtre que vous maîtrisez. Subir la migration automatique, c'est découvrir une incompatibilité applicative à 4 heures du matin sans personne pour la corriger.

Les quotas : la panne qui ne ressemble pas à une panne

Un quota atteint ne se manifeste pas par une facture refusée mais par une création de ressource qui échoue. C'est un mode de panne propre au cloud, et il est particulièrement déroutant : votre code est correct, vos droits sont corrects, et pourtant l'appel échoue.

Les situations où cela se produit sont toujours les mêmes, et toujours au pire moment :

• Une montée en charge automatique bloquée parce que le quota de calcul de la région (en vCPU ou en nombre d'instances selon le fournisseur) est atteint. Le mécanisme d'élasticité s'arrête net, sans que rien ne soit en panne au sens habituel.
• Un basculement en secours qui échoue parce que la région de repli n'a jamais eu les quotas de la région principale. Les quotas sont fixés par région, et une région où vous ne créez rien conserve les valeurs par défaut.
• Un déploiement bloqué par un quota d'adresses IP publiques ou de règles de sécurité, jamais regardé parce qu'il paraissait absurdement élevé.

Cette leçon ne reproduit volontairement aucun tableau de valeurs de quota. Ces plafonds changent sans préavis, diffèrent d'une région à l'autre et dépendent de l'ancienneté et de la vérification du compte : un tableau recopié ici serait faux dans six mois, sans que le lecteur puisse s'en apercevoir. Ce qui reste vrai, ce sont les familles de plafonds et le réflexe qui les accompagne. Un quota limite une ressource ; un rate limit limite un nombre d'appels d'API par seconde. Les deux existent pour empêcher l'abus, et les deux se rencontrent en exploitation.

Famille de plafond	Ce qu'elle limite	Piège classique
Capacité de calcul	selon le fournisseur, un nombre de vCPU (cœurs de processeur virtuels) par région et par famille d'instances, comme chez AWS, ou un nombre d'instances ; l'unité se lit dans la console	dimensionner en « nombre de serveurs » alors que le quota compte des vCPU
Adresses IP publiques	les adresses réservées, y compris détachées	une adresse oubliée consomme le quota et la facture
Débit d'API par objet	un nombre de requêtes par seconde, souvent par préfixe de stockage	concentrer tous les objets sous un même préfixe
Concurrence des fonctions	les exécutions simultanées à l'échelle du compte	une fonction emballée épuise le quota des autres
Objets de sauvegarde	le nombre de snapshots (copies instantanées d'un disque) ou de sauvegardes manuelles	des snapshots jamais purgés, parfois sur une limite dure

Glissez pour voir

Le piège le plus coûteux est l'erreur d'unité. Là où le quota de calcul se compte en vCPU, comme chez AWS, il ne compte pas les machines : avec des instances à 2 vCPU, un même plafond autorise deux fois moins de machines qu'avec des instances à 1 vCPU. Une capacité planifiée en nombre de serveurs se heurte donc à un mur dont le message d'erreur ne parle pas de serveurs.

Le second piège est le moment de la découverte. Un plan de déploiement ne consulte pas les quotas : c'est l'exécution qui échoue, à mi-parcours, avec une partie de l'infrastructure déjà créée et facturée.

Quatre réflexes règlent l'essentiel, et ils ne périment pas :

1. Consulter vos quotas réels dans la console du fournisseur (chez AWS, le service Service Quotas), pour votre compte et votre région, pas dans un tableau lu ailleurs.
2. Surveiller les quotas comme des métriques, avec une alerte au trois quarts de la limite, plutôt que de découvrir le plafond le jour du pic.
3. Demander les augmentations à froid. Certaines sont self-service (vous les obtenez vous-même dans la console) et immédiates, d'autres soumises à validation par le support, dont le délai se compte en heures ou en jours, ce qui est incompatible avec un plan de reprise ; quelques limites sont dures et ne s'augmentent pas.
4. Vérifier la région de secours : un plan de reprise suppose des quotas suffisants là-bas aussi, ce qui n'est jamais automatique. C'est l'oubli qui transforme un exercice de reprise en incident.

Les limites de montée en charge elles-mêmes, comme le temps de démarrage d'une instance ou le plafond d'un service managé, sont traitées dans élasticité et scalabilité.

Combien coûte votre observabilité ?

Dans le cloud, la supervision est un service facturé à l'usage, et le poste qui explose est presque toujours l'ingestion de journaux (leur envoi et leur enregistrement chez le fournisseur). Les métriques coûtent peu, les traces coûtent modérément, les journaux se facturent au gigaoctet ingéré puis au gigaoctet stocké. Une application bavarde passée en mode debug un vendredi soir produit une facture mémorable.

Trois arbitrages suffisent à garder ce poste sous contrôle :

• Séparer la durée de rétention (la durée de conservation) selon l'usage. Les journaux de diagnostic servent quelques jours ; les journaux d'audit doivent survivre des mois pour des raisons réglementaires. Leur appliquer la même rétention revient à payer le prix de l'audit sur tout le volume.
• Filtrer à l'émission, pas à la lecture. Un journal qu'on n'envoie pas ne coûte rien. Un journal envoyé puis exclu d'une recherche a déjà été facturé à l'ingestion.
• Échantillonner les traces. Le principe est stable : garder une fraction des traces nominales suffit à caractériser un comportement, et garder toutes les traces en erreur donne le diagnostic. Le taux, lui, n'a pas de valeur universelle. Il dépend de votre volume de requêtes, de votre taux d'erreur et de la stratégie retenue : un échantillonnage à la tête décide avant de connaître l'issue de la requête, un échantillonnage à la queue décide après et sait donc garder les cas lents ou en échec, un échantillonnage adaptatif ajuste le taux au trafic. Partez d'une fraction basse sur un service à fort trafic, montez-la sur un service peu sollicité où un échantillon trop maigre ne montrerait rien.

Ce poste appartient à la gouvernance des coûts autant qu'à l'exploitation. Il figure rarement dans les revues de facture parce qu'il est réparti sur de petites lignes, alors qu'il dépasse souvent le coût du calcul qu'il observe. La méthode pour le rendre visible est celle de la page gouvernance et coûts : étiqueter, puis mesurer par projet.

La question des sauvegardes, qui vivent par défaut dans le compte qu'elles protègent, a sa propre leçon : Sauvegarder hors du compte et prouver la restauration.

Prévoir la capacité quand on n'achète plus de matériel

Dans le cloud, la planification de capacité ne porte plus sur le matériel à commander, mais sur les limites qu'on va toucher. Le fournisseur a la capacité que vous n'avez plus besoin d'acheter, mais votre compte, lui, est plafonné, et c'est ce plafond qui arrive en premier.

Quatre grandeurs méritent une projection, parce qu'elles évoluent lentement puis bloquent brutalement :

• Les quotas de votre compte, traités plus haut : leur relèvement demande un délai, qui se compte parfois en jours.
• Les plages d'adresses de vos réseaux, dont l'épuisement empêche de créer un sous-réseau au plus mauvais moment. Le sujet est traité dans créer et dimensionner un réseau.
• La disponibilité réelle d'un gabarit (une taille de machine : nombre de vCPU et mémoire) dans votre région, en particulier pour les machines à accélérateur, qui peuvent manquer sans que rien ne l'annonce.
• Les engagements de réservation arrivant à échéance, dont la fin fait remonter la facture d'un coup si personne ne l'a anticipée.

La méthode tient en une habitude : une revue trimestrielle qui projette la consommation des douze mois écoulés sur les douze suivants, et compare le résultat aux limites en vigueur. C'est peu de travail, et cela transforme une panne surprise en demande de relèvement déposée trois mois plus tôt.

Remplacer les machines plutôt que les corriger, détecter la dérive, renouveler les certificats et encaisser une panne du fournisseur forment l'autre moitié de l'exploitation courante. Ces quatre sujets sont traités dans la leçon Remplacer, détecter la dérive, renouveler les certificats, encaisser la panne du fournisseur.

À retenir

• Aucun modèle de service ne transfère votre disponibilité applicative au fournisseur. Il garantit son service, pas le vôtre.
• Votre machine redémarrera un jour sans votre accord. Google Cloud migre à chaud la plupart des types de machines, AWS et Azure notifient et laissent agir.
• Les notifications de maintenance arrivent par courriel, pas dans votre supervision. Ce canal doit être routé vers l'équipe technique.
• Un service managé ne supprime pas les montées de version, il vous en retire le calendrier. Migrez vous-même avant la date imposée.
• Un quota atteint se présente comme une panne applicative, jamais comme un problème de facturation. Il se compte dans l'unité du fournisseur (souvent les vCPU, pas les machines), se surveille comme une métrique, et se relève à froid, région de secours comprise.
• L'ingestion de journaux dépasse souvent le coût du calcul qu'elle observe. Filtrer à l'émission et différencier les rétentions règlent l'essentiel.
• La capacité se projette sur les limites du compte, pas sur du matériel : quotas, plages d'adresses, disponibilité des gabarits et échéances de réservation, revus chaque trimestre.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →