Soutien aux opérations AWS : qui possède les incidents, les correctifs, la mise à l'échelle et les sauvegardes

Le soutien aux opérations AWS se résume à quatre tâches récurrentes — incidents, correctifs, mise à l’échelle et sauvegardes — et chacune a besoin d’exactement un responsable nommé, que ce nom appartienne à un employé ou à un fournisseur. AWS lui-même n’en possède aucune au-dessus de l’hyperviseur : sous le modèle de responsabilité partagée, le système d’exploitation, la réponse, le plan de capacité et le test de restauration sont tous à vous. Les environnements n’échouent pas parce que ces tâches sont difficiles; ils échouent parce que chaque partie supposait qu’une autre les avait.

Ce que vous êtes en train de décider

Vous dessinez une carte de propriété sans cellule vide. Pour chaque tâche, trois rôles doivent être assignés : qui agit (fait le travail), qui approuve (autorise les actions perturbatrices), et qui vérifie (confirme que c’est réellement arrivé). La colonne vérifier est celle que tout le monde saute, et c’est là que la carte gagne sa vie — des sauvegardes qui roulent mais n’ont jamais été restaurées, des correctifs « automatisés » sur des instances qui sont discrètement sorties de l’automatisation, une mise à l’échelle automatique configurée sur une métrique qui a cessé d’être représentative deux lancements de produit passés.

Les quatre tâches, concrètement :

Incidents — détection, accusé de réception, atténuation, communication, post-mortem. La propriété inclut les heures de nuit ou une déclaration explicite que la nuit n’est pas couverte.
Correctifs — paquets du système sur EC2, versions mineures de moteur sur RDS, mises à jour d’exécution sur Lambda et conteneurs, et les AMI depuis lesquelles votre mise à l’échelle lance. Chaque couche peut avoir un responsable différent; chaque couche en a besoin d’un.
Mise à l’échelle — planification de capacité, ajustement des politiques d’autoscaling, et la décision manuelle de capacité pendant un événement de trafic. Aussi la moitié coût : quelqu’un possède le rétrécissement des choses.
Sauvegardes — configuration, politique de rétention, tests de restauration, et la procédure de récupération avec de vrais temps mesurés.

Un fournisseur géré prend typiquement la colonne agir pour les quatre et partage approuver avec vous; vérifier devrait toujours vous inclure, parce que la vérification est la façon dont vous savez que le contrat est exécuté.

Quoi vérifier en premier

Demandez à quatre personnes « qui possède les correctifs? » Si vous obtenez deux réponses, vous avez zéro responsable avec des étapes en plus.
Trouvez le dernier test de restauration. Une date et une durée, écrites. L’absence est votre cellule vide la plus dangereuse.
Sortez la chronologie du dernier incident. Qui a détecté, combien de temps jusqu’à un humain, qui a décidé l’atténuation. Les trous ici sont des répétitions pour une pire nuit.
Vérifiez si la mise à l’échelle a été touchée depuis le lancement. Des politiques ajustées une fois puis oubliées dérivent hors d’alignement avec le trafic réel.

Comment vérifier

Chaque tâche a une commande qui sépare la propriété déclarée de la propriété exercée :

# CORRECTIFS : état de conformité du parc (SSM Patch Manager)
aws ssm list-resource-compliance-summaries \
  --query 'ResourceComplianceSummaryItems[].[ResourceId,Status,NonCompliantSummary.NonCompliantCount]'

# SAUVEGARDES : les travaux ont-ils vraiment réussi récemment?
aws backup list-backup-jobs --by-state COMPLETED --max-results 10 \
  --query 'BackupJobs[].[ResourceArn,CompletionDate]'
aws backup list-backup-jobs --by-state FAILED --max-results 10

# MISE À L'ÉCHELLE : des politiques sont-elles attachées, et quand ont-elles agi?
aws autoscaling describe-policies --auto-scaling-group-name prod-asg \
  --query 'ScalingPolicies[].[PolicyName,PolicyType]'
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name prod-asg --max-records 10

# INCIDENTS : quelles alarmes existent et où elles téléavertissent
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' --output table

Équivalents console : Systems Manager > Patch Manager > Compliance reporting pour la vérité des correctifs, AWS Backup > Jobs pour les résultats de sauvegarde, EC2 > Auto Scaling groups > Activity pour l’historique de mise à l’échelle. Pour la moitié AWS des incidents — est-ce nous ou eux — la vue du compte à https://health.aws.amazon.com/ est le premier arrêt, et la documentation Systems Manager à https://docs.aws.amazon.com/systems-manager/ couvre ce que l’automatisation des correctifs peut voir et ne pas voir.

La marche à suivre

Écrivez le tableau quatre-par-trois cette semaine. Quatre tâches, trois rôles, douze cellules, aucun vide et aucun comité — une cellule contenant un nom d’équipe au lieu d’une personne ou d’une partie contractuelle est un vide déguisé. Publiez-le là où la garde peut le trouver à 3 h.
Donnez aux incidents une échelle de sévérité et un chemin de téléavertissement. La détection passe par des alarmes qui notifient une rotation, pas une boîte de réception. L’ensemble d’alarmes lui-même doit correspondre à de vrais modes d’échec — partez de la base d’alarmes CloudWatch et élaguez vers ce sur quoi quelqu’un agirait la nuit.
Automatisez les correctifs, puis possédez les exceptions. SSM Patch Manager avec fenêtres de maintenance pour le parc, mises à niveau mineures automatiques de RDS dans une fenêtre définie, rafraîchissement des AMI sur un horaire. Le vrai travail du responsable est le rapport de ce qui n’a pas été corrigé et pourquoi.
Faites en sorte que les sauvegardes fassent leurs preuves chaque trimestre. Un test de restauration avec la durée notée convertit une case à cocher en capacité. Les décisions de protection inter-région et leurs compromis sont couverts dans AWS Backup inter-région, et la mécanique de restauration ponctuelle des bases dans la stratégie PITR et instantanés RDS.
Révisez la mise à l’échelle chaque trimestre contre le trafic réel. Comparez les seuils des politiques aux vraies pointes du dernier trimestre, et redimensionnez vers le bas aussi délibérément que vous montez — la propriété de la capacité inclut la facture.

Quand c’est le mauvais choix

Si votre charge de travail est un site statique sur S3 et CloudFront, la majeure partie de cette carte s’effondre en sauvegardes du dépôt source — ne bâtissez pas de cérémonie pour des tâches qui n’existent pas. Si vous êtes entièrement sur du serverless géré (Lambda, DynamoDB, aucune instance), les correctifs se déplacent largement vers AWS et votre carte devrait le refléter honnêtement plutôt que d’inventer du travail. Et si l’organisation s’apprête à migrer de plateforme, stabilisez la propriété de l’environnement actuel au niveau minimal viable au lieu de perfectionner une carte que vous allez redessiner.

Erreurs courantes

Confondre automatisation et propriété. L’automatisation exécute la tâche; le responsable surveille l’automatisation. L’automatisation sans propriétaire échoue en silence pendant des mois.
Laisser le responsable des incidents être aussi le seul approbateur. À 3 h, la personne qui agit a besoin d’atténuations préautorisées, pas d’une chaîne téléphonique.
Tout sauvegarder, ne rien restaurer. Les politiques de rétention se font auditer; la capacité de restauration gagne les incidents.
Assigner la propriété sans heures. Un nom dans une cellule sans budget de temps est une décoration — la tâche perd encore contre le sprint.

Garder le contrôle

Révisez le tableau de propriété chaque trimestre et à chaque départ ou changement de fournisseur — le jour même, pas au prochain sprint.
Suivez quatre chiffres : pourcentage de conformité des correctifs, âge du dernier test de restauration, délai d’accusé de réception, âge des politiques de mise à l’échelle.
Gardez les procédures à côté du code, versionnées, avec la date du dernier test dans l’en-tête.
Quand un fournisseur tient la colonne agir, gardez la colonne vérifier à l’interne en permanence — c’est tout le modèle de supervision en une règle.

Une carte de propriété avec douze cellules remplies est ennuyante, et l’ennui est précisément ce à quoi les opérations de production devraient ressembler. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.