Soutien en réponse aux incidents AWS : qui répond vraiment quand la production plante à 2 h du matin

Quand la production plante à 2 h du matin, « soutien en réponse aux incidents AWS » veut dire trois choses différentes, et les confondre est la façon dont une panne de quelques minutes s’étire en heures. AWS Support répond pour l’infrastructure AWS — un hôte dégradé, une panne d’API, un volume coincé — et seulement à une vitesse utile à partir du plan Business. Personne chez AWS ne redémarrera votre application, n’annulera votre déploiement ni ne remarquera que votre base de données est pleine. Cette partie appartient à qui porte votre téléavertisseur : votre propre rotation de garde, ou un partenaire d’exploitation payé pour être réveillé. La décision que vous prenez vraiment, c’est qui possède les quinze premières minutes de vos incidents.

Ce que vous décidez

Trois questions distinctes se cachent sous « réponse aux incidents », et chacune a sa propre réponse.

Premièrement : que couvre AWS lui-même? Les plans AWS Support, décrits sur aws.amazon.com/premiumsupport, varient selon le temps de réponse et la portée. Le plan Developer, c’est les heures de bureau et des conseils généraux — inutile pour une panne de production la nuit. Le plan Business donne un accès 24/7 à des ingénieurs avec une cible de moins d’une heure pour un système de production hors service. Enterprise On-Ramp et Enterprise resserrent à 30 et 15 minutes pour les cas critiques et ajoutent un Technical Account Manager. Le prix est un pourcentage de votre dépense AWS mensuelle avec des minimums par plan, donc le coût suit le compte. Mais la portée s’arrête à la ligne de responsabilité partagée d’AWS : leur matériel, leurs services gérés, leurs API. « Mon panier lance des 500 » est votre incident, sauf si vous pouvez démontrer qu’un service AWS l’a causé.

Deuxièmement : qui détecte l’incident? Les plans de soutien répondent aux billets; ils n’en ouvrent pas. Sans alarmes branchées sur un chemin de garde — le sujet de la base d’alarmes CloudWatch — la panne de 2 h du matin est découverte à 8 h 45 par un client.

Troisièmement : qui répond pour votre charge de travail? Une vraie rotation interne exige au moins quatre personnes capables chacune de diagnostiquer la pile seules, sinon la rotation épuise la seule personne qui le peut. Les équipes plus petites choisissent entre un partenaire d’exploitation et de l’héroïsme non structuré, qu’elles l’admettent ou non.

Quoi vérifier en premier

• Le plan AWS Support du compte : Support Center > Support plans dans la console. Beaucoup de comptes de production sont encore sur Basic, qui n’offre aucun soutien technique par billet.
• Si un chemin de garde existe — pas un canal Slack, un chemin qui fait sonner un téléphone — et qui est au bout du fil ce soir.
• Si la personne appelée peut réellement entrer à 2 h du matin : identifiants IAM fonctionnels, appareil MFA sous la main, accès VPN, et emplacement du guide d’intervention connu.
• Si quelqu’un surveille AWS Health pour les événements côté AWS, afin de distinguer « on l’a cassé » de « AWS l’a cassé » dans les cinq premières minutes.

Comment vérifier

Confirmez ce que le plan de soutien débloque vraiment :

# Fonctionne seulement sur Business, Enterprise On-Ramp ou Enterprise —
# une erreur ici signifie que le compte n'a aucun soutien technique 24/7
aws support describe-severity-levels --language en

# L'API AWS Health a la même exigence de plan
aws health describe-events \
  --filter eventStatusCodes=open,upcoming --region us-east-1

Vérifiez ensuite le chemin humain avec un exercice, parce que c’est la partie qui pourrit :

aws cloudwatch set-alarm-state --alarm-name prod-alb-5xx-rate \
  --state-value ALARM --state-reason "2am readiness drill"

Chronométrez trois choses : de l’alerte à la prise en charge, de la prise en charge à connecté-et-en-train-de-regarder, et de connecté au premier constat de diagnostic. Ces trois nombres sont votre vraie capacité de réponse aux incidents; le reste, c’est de la paperasse.

L’approche

1. Définir les sévérités avant l’incident. Deux niveaux suffisent pour commencer : SEV1, les clients sont touchés et quelqu’un est réveillé; SEV2, dégradé ou à risque, et ça attend au matin. Débattez des définitions en plein jour, une seule fois.
2. Ajuster le plan AWS Support au rayon d’impact. Le plan Business est le plancher honnête pour tout compte où l’indisponibilité coûte de l’argent réel — c’est l’assurance la moins chère de la pile. Les paliers Enterprise ont du sens quand une réponse en 15 minutes et un TAM changent l’issue — une question de dépense et de criticité, pas d’orgueil.
3. Bâtir la couche de détection. Alarmes basées sur les symptômes, deux sujets SNS (garde contre billet), un exercice trimestriel. La détection est en amont de toutes les décisions de réponse et coûte moins cher que chacune.
4. Écrire le guide des quinze premières minutes. Une page : comment vérifier AWS Health, où sont les tableaux de bord, comment annuler le dernier déploiement, quand ouvrir un cas Sev-1 chez AWS, qui escalader. À 2 h du matin, personne ne réfléchit; on suit la page ou on s’agite.
5. Choisir entre bâtir et acheter la rotation, honnêtement. Quatre ingénieurs capables ou plus qui acceptent le téléavertisseur : bâtissez-la, payez-la, et tournez équitablement. Moins que ça : un partenaire de surveillance et d’intervention n’est pas un aveu d’échec, c’est de l’arithmétique.
6. Fermer la boucle après chaque incident. Un compte rendu sans blâme avec un élément d’action qui élimine la classe de panne. La qualité de la réponse ne se cumule que si le même incident ne peut pas arriver deux fois.

Quand c’est la mauvaise approche

Si le même incident revient chaque mois, vous avez un problème de fiabilité déguisé en problème de réponse aux incidents — corrigez l’architecture au lieu d’optimiser l’ambulance. Si la charge de travail peut honnêtement tolérer une nuit d’arrêt, payer pour du soutien Enterprise ou une garde 24/7, c’est dépenser pour ne rien protéger. Et aucun plan de soutien ne compense un point de défaillance unique que vous connaissez déjà; des ingénieurs AWS qui répondent en 15 minutes ne peuvent pas dé-perdre les données du seul volume non répliqué.

Erreurs fréquentes

• Croire qu’AWS Support déboguera le code applicatif. Le modèle de responsabilité partagée trace la ligne bien au-dessus de vos traces d’erreur.
• Acheter le plan Business et ne pas bâtir la détection, si bien que les ingénieurs 24/7 ne sont jamais appelés parce que personne ne sait que c’est en panne.
• Une « rotation » d’un seul volontaire, qui fonctionne jusqu’à la semaine où il est dans un avion, et produit une lettre de démission tôt ou tard.
• Découvrir pendant la panne que les identifiants de la personne de garde sont expirés, que l’appareil MFA est au bureau, ou que le guide vit dans un wiki derrière le VPN qui est aussi en panne.

Garder le contrôle

• Faites l’exercice de 2 h du matin chaque trimestre et suivez les trois chronos; une régression là est un incident en soi.
• Révisez le plan de soutien annuellement contre la dépense et la criticité actuelles — les comptes dépassent leur plan sans bruit.
• Gardez le guide des quinze premières minutes épinglé dans le sujet du canal d’incident, pas seulement dans un wiki.
• Faites tourner la personne qui mène l’exercice pour que le savoir ne se concentre pas dans une seule tête.
• Réinjectez la chronologie de chaque incident réel dans le guide dans la semaine, pendant qu’elle est encore vraie.

Le plan, le téléavertisseur et le guide ne comptent que si un humain compétent est à l’autre bout quand l’alerte sonne. Si les alertes sonnent dans une pièce vide après les heures, c’est exactement l’écart que ferme la Surveillance et intervention 24/7 — planifiez une revue de surveillance.