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 page décrit ce qui reste à votre charge au quotidien, les événements imposés qu'il faut anticiper, et les trois pièges d'exploitation propres au cloud : les quotas, le coût de l'observabilité et les sauvegardes rangées au mauvais endroit.
Ce que vous allez apprendre
Section intitulée « 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.
- Placer vos sauvegardes hors d'atteinte d'une compromission de compte.
- Réagir à une panne dont l'origine est chez le fournisseur.
Cette page ne redéfinit ni les SLI et SLO, 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.
Qui exploite quoi, exactement ?
Section intitulée « 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.
| 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 |
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
Section intitulée « 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 |
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.
Pourquoi une montée de version managée se prépare
Section intitulée « 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 :
-
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.
-
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.
-
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
Section intitulée « 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 d'instances de la région 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é.
Deux réflexes règlent l'essentiel. Le premier consiste à surveiller les quotas comme des métriques, avec une alerte au trois quarts de la limite, et non à les découvrir quand ils bloquent. Le second consiste à demander les augmentations à froid, en particulier sur la région de secours : un relèvement de quota passe par une demande au support, dont le délai se compte en heures ou en jours, ce qui est incompatible avec un plan de reprise.
Combien coûte votre observabilité ?
Section intitulée « 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. 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 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.
Où placer une sauvegarde pour qu'elle survive ?
Section intitulée « Où placer une sauvegarde pour qu'elle survive ? »Une sauvegarde qui vit dans le compte qu'elle protège ne protège pas contre ce qui menace ce compte. C'est le défaut de conception le plus répandu, et il ne se voit pas tant que rien n'arrive : les instantanés d'un disque sont, par défaut, des objets du même compte et de la même région que le disque.
Trois scénarios rendent cette configuration inutile :
| Ce qui arrive | Effet sur une sauvegarde dans le même compte |
|---|---|
| Identifiants d'administration compromis | l'attaquant supprime les instantanés avant de chiffrer ou d'effacer |
| Suppression accidentelle du compte ou du projet | les instantanés partent avec le reste |
| Panne majeure d'une région | la sauvegarde est indisponible en même temps que la production |
La parade tient en trois propriétés, à vérifier une par une sur votre configuration actuelle plutôt qu'à supposer acquises :
-
Une copie dans un autre compte, dont les identifiants ne sont pas ceux de la production. C'est ce qui neutralise le premier scénario, de loin le plus fréquent depuis la généralisation des rançongiciels visant les environnements cloud.
-
Une copie dans une autre région, ce qui neutralise le troisième. La page sur la résilience détaille ce que cette copie coûte en transfert sortant et ce qu'elle apporte réellement.
-
Une immuabilité vérifiée, via le verrouillage d'objet quand votre fournisseur le propose sur le stockage objet. Une sauvegarde que le compte de sauvegarde peut lui-même effacer garde une faiblesse de moins, mais elle en garde une.
Corriger une vulnérabilité : remplacer plutôt que rustiner
Section intitulée « Corriger une vulnérabilité : remplacer plutôt que rustiner »Dans le cloud, la façon la plus fiable de corriger une machine est de la remplacer par une neuve déjà corrigée. Appliquer un correctif sur une instance en service fonctionne, mais laisse chaque machine dériver de sa voisine, et personne ne sait plus au bout d'un an ce qui tourne réellement.
Le cycle à installer est simple et se prête entièrement à l'automatisation :
-
Construisez une image système à intervalle régulier, correctifs appliqués et agents installés, avec un numéro de version.
-
Déployez les nouvelles instances depuis cette image, en remplaçant progressivement les anciennes plutôt qu'en les modifiant.
-
Retirez les images périmées, sans quoi une image vulnérable de l'an dernier reste disponible et finira par être utilisée par erreur.
Ce cycle a un effet secondaire précieux : il valide en continu votre capacité à remplacer une machine. Une équipe qui reconstruit ses instances toutes les deux semaines sait qu'une maintenance imposée par le fournisseur ne lui posera aucun problème, parce qu'elle vient de faire l'opération quatorze fois.
Pourquoi l'infrastructure ne ressemble plus à son code
Section intitulée « Pourquoi l'infrastructure ne ressemble plus à son code »La dérive de configuration, c'est l'écart entre ce que décrit votre code d'infrastructure et ce qui tourne réellement. Elle s'installe toujours de la même façon : un incident un vendredi soir, une règle de pare-feu élargie à la main pour rétablir le service, et personne ne reporte la modification dans le dépôt. Six mois plus tard, un déploiement routinier referme la règle et reproduit la panne d'origine.
Le mécanisme est d'autant plus pernicieux que le code paraît faire autorité alors qu'il ne décrit plus la réalité. L'équipe le lit pour comprendre l'architecture, et prend des décisions sur une carte périmée.
La détecter avant qu'elle ne coûte quelque chose
Section intitulée « La détecter avant qu'elle ne coûte quelque chose »Votre outil d'infrastructure sait déjà répondre à la question : il compare l'état réel à l'état décrit et vous liste les écarts. Ce qui manque le plus souvent, c'est de poser cette comparaison en tâche planifiée plutôt que de la lancer au moment où l'on veut déployer, c'est-à-dire au pire moment pour découvrir une surprise.
-
Lancez une comparaison quotidienne sur chaque environnement, en mode lecture seule, et publiez le résultat là où l'équipe le voit.
-
Traitez chaque écart dans les jours qui suivent, dans un sens ou dans l'autre : soit la modification manuelle était légitime et rejoint le code, soit elle ne l'était pas et le code la corrige.
-
Cherchez la cause quand un écart revient au même endroit. Un écart récurrent ne signale pas de l'indiscipline, il signale que le code ne permet pas de faire quelque chose de nécessaire.
Le garde-fou complémentaire est de rendre la modification manuelle difficile. Retirer les droits d'écriture en production aux humains, et ne les laisser qu'au compte de la chaîne de déploiement, supprime la dérive à la source. Prévoyez alors une procédure d'accès d'urgence, tracée et limitée dans le temps, sans quoi la première panne fera sauter la règle définitivement.
Le certificat qui expire un dimanche
Section intitulée « Le certificat qui expire un dimanche »L'expiration d'un certificat est une panne totale, parfaitement prévisible, et elle continue pourtant de faire tomber des services chaque année. La cause est toujours la même : le certificat a été installé à la main par quelqu'un qui a depuis changé de poste, et l'alerte de renouvellement partait sur son adresse.
Trois règles suffisent à fermer le sujet.
Automatisez l'émission et le renouvellement. Les services de certificats des fournisseurs cloud renouvellent seuls les certificats qu'ils ont émis, tant qu'ils gardent la main sur la validation. Pour ce qui vit hors de ces services, un client du protocole d'émission automatisée fait le même travail. Un certificat renouvelé à la main est un incident programmé.
Surveillez la date d'expiration depuis l'extérieur, pas depuis votre inventaire. Une sonde qui se connecte au service public et lit la date du certificat présenté détecte aussi le cas où le renouvellement a réussi mais où le service n'a pas rechargé le nouveau fichier, panne classique et déroutante puisque tous les tableaux de bord internes affichent alors un certificat valide.
Alertez sur une adresse d'équipe, jamais sur une personne, et suffisamment tôt pour qu'un renouvellement manqué laisse le temps d'intervenir.
Prévoir la capacité quand on n'achète plus de matériel
Section intitulée « 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 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.
Le jour où la panne vient du fournisseur
Section intitulée « Le jour où la panne vient du fournisseur »Votre supervision ne vous dira pas que le problème n'est pas chez vous. Elle montrera des délais de réponse anormaux, des erreurs sur un service managé, une zone qui ne répond plus, et vos équipes chercheront la cause dans le dernier déploiement. Savoir écarter rapidement cette piste fait gagner un temps considérable.
Deux sources d'information existent, et elles ne se valent pas :
- La page de statut publique, celle que tout le monde consulte, est structurellement en retard : elle est mise à jour après confirmation interne, souvent bien après que vos utilisateurs aient vu le problème. Un statut « tous les services opérationnels » n'est pas une preuve que tout va bien.
- Le tableau de bord de santé personnalisé de votre compte est nettement plus rapide, parce qu'il signale les événements affectant vos ressources précises. C'est celui qu'il faut brancher sur votre canal d'alerte, et il reste sous-utilisé.
Ce que vous pouvez faire pendant une panne fournisseur est limité, ce qui rend la préparation décisive. Le seul levier réel est celui prévu à l'avance : basculer vers une autre zone si l'architecture le permet, dégrader une fonctionnalité proprement, ou afficher un message honnête. Une page d'attente lisible vaut mieux qu'un délai d'expiration, et elle se prépare quand tout va bien.
Après coup, réclamez le rapport d'incident du fournisseur et lisez-le. Il indique presque toujours une condition de déclenchement que vous pouvez rendre inoffensive de votre côté, et c'est la seule partie exploitable de l'exercice. Le crédit de service prévu par le contrat, lui, ne couvrira jamais votre perte réelle : le rapport entre SLA affiché et disponibilité vécue mérite d'être compris avant d'en dépendre.
À retenir
Section intitulée « À 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. Les quotas se surveillent, et se relèvent à froid sur la région de secours.
- 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.
- Une sauvegarde dans le compte qu'elle protège ne protège de presque rien. Autre compte, autre région, immuabilité vérifiée.
- Une restauration chronométrée est le seul contrôle qui prouve quelque chose, et le cloud a retiré la dernière excuse pour ne pas la faire.
- Remplacer une machine vaut mieux que la rustiner, et entretient au passage votre capacité à encaisser une maintenance imposée.
- La page de statut publique est en retard sur la réalité. Le tableau de bord de santé de votre compte est la source à brancher sur vos alertes.