Acheter de la surveillance 24/7 pour un compte AWS, c’est surtout une question de personnes, et cet article vous aide à vérifier que ces personnes sont vraiment là. Imaginez une alarme qui sonne à 3 h 14. Une personne qualifiée doit être réveillée en quelques minutes, ouvrir une procédure (les étapes écrites pour cette alarme) et avoir les accès pour régler le problème. Si elle ne répond pas, une deuxième personne doit être appelée. Un tableau de bord ne fait rien de tout cela à lui seul. Quand un fournisseur offre de la « surveillance 24/7 », questionnez-le sur la rotation, la chaîne d’escalade et son autorité pour agir avant de regarder les graphiques.
Ce qui se passe
La surveillance se divise en trois couches, et les vendeurs adorent vendre la première en laissant entendre la troisième :
- Télémétrie — métriques, journaux et traces collectés. CloudWatch fait ça d’office; c’est la mise de départ, pas un service.
- Alerte — seuils et détection d’anomalies qui transforment la télémétrie en réveils. Une bonne alerte est un vrai travail d’ingénierie (ajustement, déduplication, cartographie de sévérité), mais elle se termine quand même à une notification.
- Réponse — une rotation dotée en personnel qui accuse réception, suit une procédure, atténue et escalade. C’est la seule couche qui raccourcit les pannes.
Une vraie rotation de nuit a des exigences dures, faciles à vérifier et coûteuses à simuler. Il faut au moins deux personnes disponibles à toute heure (primaire et escalade — une seule personne est un point de défaillance unique qui, en plus, dort), et un outil de téléavertissement avec délais d’accusé de réception, pas du courriel ni Slack. Il faut des procédures par alarme pour que le répondant de 3 h exécute au lieu de chercher. Il faut aussi un accès en écriture suffisant pour atténuer (redémarrer un service, basculer une base de données, redimensionner un groupe); et un processus de relève pour que l’équipe de jour sache ce qui s’est passé la nuit. Chaque alerte doit aussi soulever la question à laquelle CloudWatch seul ne répond pas : est-ce nous ou est-ce AWS? — c’est à ça que sert https://health.aws.amazon.com/.
L’économie découle de la dotation. Couvrir un siège en continu prend plusieurs personnes une fois comptés les nuits, les fins de semaine, les vacances et le roulement. C’est le vrai facteur de coût derrière la tarification 24/7, et la raison pour laquelle les offres crédibles coûtent de l’argent réel tandis que « surveillance 24/7 incluse gratuitement » signifie invariablement télémétrie seulement.
Quoi vérifier en premier
- Où vos alarmes notifient-elles en ce moment? Un sujet SNS sans abonnés, un canal Slack en sourdine ou le téléphone personnel d’un seul ingénieur : les trois culs-de-sac classiques.
- Quel est votre délai alarme-accusé de réception la nuit? Si vous ne pouvez pas le mesurer, il n’a jamais été testé.
- Des procédures existent-elles pour vos cinq principales alarmes? Demandez la procédure de retard de réplique; observez ce qui se passe.
- Qui est l’escalade si le primaire dort à travers l’appel? « Personne » est la réponse honnête dans la plupart des boutiques.
- Le répondant de nuit peut-il réellement faire quelque chose? Un accès en lecture seule la nuit signifie que la panne attend le matin de toute façon.
Comment vérifier
Testez le pipeline de bout en bout, pas les morceaux :
# Chaque alarme et où elle notifie
aws cloudwatch describe-alarms \
--query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' --output table
# Le sujet SNS a-t-il des abonnés vivants?
aws sns list-subscriptions-by-topic \
--topic-arn arn:aws:sns:ca-central-1:123456789012:prod-alerts
# Déclencher un exercice contrôlé — l'alarme reprend son état réel
# à la prochaine évaluation de la métrique
aws cloudwatch set-alarm-state \
--alarm-name prod-alb-5xx-rate \
--state-value ALARM \
--state-reason "overnight drill"Lancez l’exercice à 22 h, sans prévenir la rotation (en prévenant la direction). Mesurez les minutes jusqu’à l’accusé de réception et les minutes jusqu’à ce qu’un humain lise la bonne procédure. Dans la console, CloudWatch > Alarms > History montre les transitions d’état horodatées, ce qui vous donne la moitié objective de la mesure. La documentation CloudWatch à https://docs.aws.amazon.com/AmazonCloudWatch/ couvre les états et actions d’alarme si vous construisez vous-même la couche d’alerte.
La marche à suivre
- Réparez l’ensemble d’alarmes avant de doter quoi que ce soit. Une rotation réveillée pour du bruit s’épuise et se met à ignorer les appels; c’est comme ça qu’on dort à travers les vrais incidents. Partez d’une base délibérée comme les alarmes CloudWatch dont un SaaS en production a besoin et supprimez chaque alarme sur laquelle personne n’agirait la nuit.
- Acheminez les appels par un outil avec escalade, accusé de réception et délais. SNS vers courriel, c’est là que les alertes vont mourir la nuit. SNS doit alimenter un système de téléavertissement qui appelle le primaire, attend, puis appelle l’escalade.
- Écrivez la procédure de chaque alarme qui réveille. Symptôme, premières vérifications, étapes d’atténuation avec commandes exactes, retour arrière, et la ligne d’arrêt où le répondant doit escalader plutôt qu’improviser. Une page par alarme; écrite par qui connaît le mieux le système, exécutée par qui est réveillé.
- Donnez à la rotation un accès d’atténuation, délimité. Redémarrer, redimensionner, basculer — via des rôles à moindre privilège, pour que le rayon d’impact de 3 h du matin soit borné. La même discipline que les rôles d’instance bien faits, appliquée aux humains.
- Dotez honnêtement ou achetez. Si vous avez moins d’environ six ingénieurs prêts à porter le téléavertisseur, une rotation 24/7 interne durable est une arithmétique impossible — achetez la couche de nuit d’un fournisseur qui opère une vraie rotation, et vérifiez-la avec le même exercice.
- Exercez chaque trimestre et révisez chaque réveil chaque mois. Chaque appel est soit actionnable (garder), soit du bruit (ajuster ou supprimer), soit un manque (ajouter de la couverture). L’ensemble d’alarmes est un artefact vivant.
Quand c’est le mauvais choix
Si vos clients sont tous dans un fuseau horaire et que vos revenus s’arrêtent à 18 h, payer pour une réponse 24/7, c’est acheter une assurance contre une nuit vide. Une couverture aux heures ouvrables avec un appel de nuit au mieux des efforts est parfois la réponse honnête, tarifée en conséquence. Si votre application plante chaque nuit à cause de fuites de mémoire, une rotation ne fait que documenter la souffrance; réparez l’application d’abord. Et si les alarmes sonnent actuellement des dizaines de fois par jour, doter une rotation avant d’ajuster, c’est payer des gens pour se faire torturer.
Erreurs courantes
- Confondre une pile de surveillance avec une couverture de surveillance. Prometheus, Grafana et les tableaux de bord CloudWatch sont de la télémétrie; personne n’est responsable.
- Un héros en garde informelle permanente. Ça fonctionne jusqu’à ce qu’il s’épuise, parte en vacances ou démissionne — habituellement dans cet ordre.
- Des alarmes ajustées une fois au lancement, jamais revues. Le trafic double, les seuils non; les appels deviennent du bruit; le bruit devient ignoré.
- Aucune autorité la nuit. Un répondant qui doit réveiller le directeur technique pour la permission de redémarrer un service ajoute un saut à chaque incident.
Garder le contrôle
- Suivez deux chiffres chaque mois : le délai médian d’accusé de réception et les réveils par semaine. Le premier doit être en minutes; le second doit tendre vers le bas.
- Gardez les procédures dans le contrôle de version à côté du code d’infrastructure, revues quand l’architecture change.
- Faites tourner l’exercice : alarme différente, heure différente, chaque trimestre.
- Revérifiez les listes d’abonnés après chaque changement de personnel — les numéros morts dans la chaîne d’escalade sont des défaillances silencieuses.
Le tableau de bord est la partie la plus facile de la surveillance 24/7 et la seule que la plupart des vendeurs vous montrent; la rotation derrière est le produit. 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.