> **Issue hors sprint, prérequis : #174 fermée.** Elle construit le contrôle qui surveille > le garde-fou de teardown. La poser avant que ce garde-fou ait tourné une seule fois > serait construire le gardien du gardien en premier. ## Contexte **ADR 031** a remplacé le teardown automatique de 21 h par un détecteur qui prévient : EventBridge Scheduler à 23 h → Lambda `eks:ListClusters` → SNS. Le module est livré (`terraform/modules/teardown-guardrail/`, !335). Ce détecteur a une propriété voulue : **il ne dit rien quand tout va bien.** Aucun cluster debout à 23 h, aucun courriel. C'est ce qui le rend lisible — une alerte qui part chaque nuit devient du décor en une semaine, comme le scan de registre de 8 h (INC-072). ## Le constat **Cette même propriété rend sa panne invisible.** Un détecteur qui ne dit rien parce que tout va bien et un détecteur qui ne dit rien parce qu'il est mort **produisent exactement le même signal** : le silence. Trois pannes plausibles, aucune détectable aujourd'hui : | Panne | Ce qu'on observerait | |---|---| | La Lambda échoue (droit IAM retiré, runtime en fin de support, code cassé) | rien | | Le planning EventBridge est désactivé ou supprimé | rien | | L'abonnement SNS n'a jamais été confirmé, ou a été désabonné depuis | rien | **C'est précisément le reproche que l'ADR 031 fait au schedule GitLab de 21 h** : il ne faisait rien depuis le 06/08, et la seule chose qui le trahissait était un pipeline rouge que personne ne regardait. On vient de reproduire la faille en la déplaçant. Leçon déjà écrite dans le projet, SEC-006 : *une règle qui dépend de la mémoire d'un humain au bon moment est un vœu, pas un contrôle.* ## Le contrôle proposé Une alarme CloudWatch sur la métrique `Invocations` de la fonction, publiant sur **le sujet SNS qui existe déjà** : ```hcl resource "aws_cloudwatch_metric_alarm" "detector_did_not_run" { alarm_name = "${var.project_name}-teardown-guardrail-silencieux" namespace = "AWS/Lambda" metric_name = "Invocations" dimensions = { FunctionName = aws_lambda_function.detector.function_name } statistic = "Sum" period = 86400 evaluation_periods = 1 comparison_operator = "LessThanThreshold" threshold = 1 # LE POINT CENTRAL. Sans lui, une fonction qui ne s'exécute plus du tout ne # publie plus AUCUN point de métrique, l'alarme passe en INSUFFICIENT_DATA et # ne sonne jamais. C'est exactement la panne à couvrir. treat_missing_data = "breaching" alarm_actions = [aws_sns_topic.teardown_guardrail.arn] } ``` **`treat_missing_data = "breaching"` est tout l'intérêt de l'issue.** Une alarme posée sans ce réglage donnerait l'illusion du contrôle en étant aveugle à la panne la plus probable — la fonction qui ne tourne plus. C'est le même piège que celui d'INC-070 : un test négatif mal construit conclut l'inverse de la vérité. ## Ce que ce contrôle ne couvre toujours pas **L'abonnement SNS non confirmé.** Une alarme qui publie sur un sujet dont personne n'est destinataire est aussi silencieuse que le reste. Aucune métrique CloudWatch ne dit « ce sujet a zéro abonné confirmé ». Ce trou est **assumé et documenté**, pas corrigé ici : la vérification de l'abonnement est un geste ponctuel, écrit en **section 13.1 du runbook**, à rejouer après tout `apply` sur la stack `persistent`. Le fermer pour de bon demanderait un troisième mécanisme, et la question « qui garde le gardien du gardien » n'a pas de fin. ## Options écartées | Option | Motif | |---|---| | **Alarme sur `Errors` au lieu d'`Invocations`** | Elle couvre la fonction qui plante, pas celle qui ne démarre plus — or le planning désactivé est la panne la plus probable, et c'est la seule que le projet a déjà vécue (schedule GitLab) | | **Un second sujet SNS pour les alarmes de santé** | Deux canaux à surveiller au lieu d'un, pour la même boîte aux lettres. Le sujet existant convient, le sujet de l'alarme suffit à distinguer les deux messages | | **Ne rien faire, et vérifier à la main** | C'est l'état actuel. Il tient tant que la vérification est jouée, donc il repose sur la mémoire au bon moment — ce que ce projet a déjà mesuré comme insuffisant deux fois | ## Done when - [ ] L'alarme est ajoutée au module `teardown-guardrail`, avec `treat_missing_data = "breaching"` et son motif écrit dans le code - [ ] `terraform fmt`, `validate` et `tfsec --minimum-severity HIGH` verts avant push - [ ] **L'alarme est exercée** : désactiver le planning EventBridge, attendre le cycle, vérifier que le courriel part — puis le réactiver. Une alarme configurée n'est pas une alarme vérifiée (INC-066) - [ ] Le runbook (section 13) gagne le geste de vérification et l'état attendu de l'alarme - [ ] Le trou restant (abonnement SNS non confirmé) est nommé dans la doc, pas laissé implicite ## Hors périmètre - Élargir le détecteur au-delà d'`eks:ListClusters` (NLB orphelin, RDS, NAT Gateway). C'est une limite assumée d'ADR 031, et un autre sujet. - Toute modification du schedule GitLab `4253819`, qui relève de #174. Né de la revue de !335. Décision et arbitrages : **ADR 031**.