Ce que vous voyez
La chaîne humaine future ne peut plus savoir de manière fiable ce qui a déjà été livré ou acquitté.
État d’avancement:Essai localfiche de référencemise en service interdite pour l’instantÉtat réel:Candidat + E2E localpage d’autorité composantpromotion NO-GO
Choisissez votre lectureCommencez par la vue sans jargon si vous découvrez le sujet.
À qui s’adresse chaque lecture?
Je veux comprendre: direction, équipes métier, communication, achats et première visite. Exploitation: opérateur, support et astreinte. Vue architecte: architecte, ingénieur et sécurité. Tout afficher: revue complète de la fiche.
« Je veux comprendre » affiché. Ce choix sera repris sur les autres fiches. La décision de mise en service et les risques restent toujours visibles.
Comprendre cette fonction en 60 secondes
Le résumé donne le rôle, le trajet, le risque, le responsable et la limite de preuve en moins d’une minute. Les dépendances et exemples restent disponibles juste après, sans jargon imposé.
Résumé essentiel
Ce que c’est et à quoi cela sert
Suivre la livraison et l’acquittement des alertes.
Conserver sans doublon les étapes entre une alerte reçue, livrée, acquittée ou escaladée.
Une comparaison utile
Comme un registre central: il distingue réception, tentative et confirmation.
Ce qui entre
Une alerte doit produire un effet d’exploitation malgré un redémarrage ou une nouvelle tentative.
Qui en bénéficie et quel résultat attendre
Les équipes peuvent distinguer ce qui a été reçu, tenté, livré et confirmé.
L’équipe chargée de détecter et traiter les pannes.
État actuel
Essai local. Trois essais locaux couvrent deux arrêts puis un lien isolé. Le suivi converge sans doublon durable. Production et humain restent à prouver. Mise en service interdite pour l’instant.
Risque principal
La chaîne humaine future ne peut plus savoir de manière fiable ce qui a déjà été livré ou acquitté.
Responsable
Responsable des données d’exploitation. Autorité de décision: Responsable exploitation des données.
Décision suivante
Autoriser la base quand chaque alerte, tentative, livraison et confirmation est conservée sans doublon.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Une alerte doit produire un effet d’exploitation malgré un redémarrage ou une nouvelle tentative.
Ce dont il dépend
Du service qui fournira les alertes, d’une base disponible et des services autorisés à livrer puis confirmer les événements.
Comment le service continue
L’équipe vérifie manuellement les étapes voisines. Les appels continuent seulement si leur chemin est indépendant; aucune notification humaine ne doit être supposée.
En cas de panne et pour vos données
Ce registre note chaque étape d’une alerte: reçue, tentée, livrée, confirmée. Après un arrêt ou une nouvelle tentative, il reconnaît ce qui est déjà fait et ne le refait pas. Tout reste dans une base privée; personne n’est encore prévenu, et la sauvegarde vers un lieu sûr n’est pas prouvée.
Preuve attendue avant la prochaine étape
Essais sur une vraie base avec deux identités, expiration des réservations, tentatives maximales, reprise et restauration.
Statut expliqué
Deux essais ont arrêté la première copie du programme d’alertes, proprement puis brutalement. Un troisième a gardé les deux copies actives mais a coupé leur lien de coordination. Les envois physiques en double ont été vus, puis les étapes de stockage n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. Il reste à relier le vrai détecteur de pannes, à déployer une base résistante aux pannes et le réseau privé, à gérer les accès, à prouver restauration, charge et délais, puis à tester la prise en charge humaine.
Exemple concret
Une alerte doit produire un effet d’exploitation malgré un redémarrage ou une nouvelle tentative. Les équipes peuvent distinguer ce qui a été reçu, tenté, livré et confirmé.
Voir l’exemple technique précis
Une notification a bien produit son effet, mais sa fin d’écriture en base se perd. Après une résolution et un redémarrage, la nouvelle tentative reconnaît la même clé, reste accepted et ne rejoue pas l’effet; une clé déjà suppressed le reste. Le lab exerce aussi ce parcours pour une escalade suivie d’un acquittement.
Voir les questions et réponses selon votre rôle
Les six lectures ci-dessous reprennent les mêmes faits. Elles ne créent pas une seconde source de vérité.
- Direction
- Question: Peut-on compter sur cette fonction aujourd’hui?
Réponse: Deux essais ont arrêté la première copie du programme d’alertes, proprement puis brutalement. Un troisième a gardé les deux copies actives mais a coupé leur lien de coordination. Les envois physiques en double ont été vus, puis les étapes de stockage n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. Autoriser la base quand chaque alerte, tentative, livraison et confirmation est conservée sans doublon. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Conserver sans doublon les étapes entre une alerte reçue, livrée, acquittée ou escaladée. Les équipes peuvent distinguer ce qui a été reçu, tenté, livré et confirmé. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Du service qui fournira les alertes, d’une base disponible et des services autorisés à livrer puis confirmer les événements. Il reste à relier le vrai détecteur de pannes, à déployer une base résistante aux pannes et le réseau privé, à gérer les accès, à prouver restauration, charge et délais, puis à tester la prise en charge humaine. Preuve attendue: Essais sur une vraie base avec deux identités, expiration des réservations, tentatives maximales, reprise et restauration. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Conserver sans doublon les étapes entre une alerte reçue, livrée, acquittée ou escaladée. Ne présentez pas cette fonction comme disponible en production: Deux essais ont arrêté la première copie du programme d’alertes, proprement puis brutalement. Un troisième a gardé les deux copies actives mais a coupé leur lien de coordination. Les envois physiques en double ont été vus, puis les étapes de stockage n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable des données d’exploitation. Autorité de décision: Responsable exploitation des données. Vérifier l’heure du dernier état et les étapes juste avant et après. Un silence de supervision ne signifie jamais que tout va bien. - Technique
- Question: Où sont les contrats exacts?
Réponse: Utilisez la « Vue architecte ». Elle montre les entrées, les sorties, les interfaces, les données, la sécurité et les preuves provenant de la fiche d’autorité.
Trajet simple, de la situation au résultat
Le trajet montre ce qui déclenche cette fonction, le service qu’elle rend et le résultat obtenu. Il reste lisible sans fonction interactive.
Suivre le flux
Partie documentée: Suivre la livraison et l’acquittement des alertes.
Une alerte doit produire un effet d’exploitation malgré un redémarrage ou une nouvelle tentative.
Conserver sans doublon les étapes entre une alerte reçue, livrée, acquittée ou escaladée.
Les équipes peuvent distinguer ce qui a été reçu, tenté, livré et confirmé.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre. Les contrats exacts restent dans la « Vue architecte ».
Étape 1 sur 3: Une alerte doit produire un effet d’exploitation malgré un redémarrage ou une nouvelle tentative.
Impact utile: Les équipes peuvent distinguer ce qui a été reçu, tenté, livré et confirmé.
En cas de panne: La chaîne humaine future ne peut plus savoir de manière fiable ce qui a déjà été livré ou acquitté.
Responsable: Responsable des données d’exploitation. Autorité de décision: Responsable exploitation des données.
Premiers gestes en cas de problème
Reconnaître ce qui se passe, protéger le service et prévenir le bon responsable sans improviser.
Première action sans risque
Vérifier l’heure du dernier état et les étapes juste avant et après. Un silence de supervision ne signifie jamais que tout va bien.
Solution de secours
L’équipe vérifie manuellement les étapes voisines. Les appels continuent seulement si leur chemin est indépendant; aucune notification humaine ne doit être supposée.
Qui prévenir et où lire les preuves
Responsable des données d’exploitation. Autorité de décision: Responsable exploitation des données. La procédure de production reste à créer et valider avant la mise en service. Ouvrir la fiche d’architecture et de preuve du domaine.
Besoin d’un terme technique? Ouvrir les définitions
- Outbox
- file transactionnelle en base
- Lease
- droit temporaire de traiter une obligation, jamais synonyme d’annulation
- Append-only
- historique dont les lignes acquises ne sont ni modifiées ni supprimées
- Tombstone
- marqueur durable de résolution ou d’acquittement
- Accepted
- effet déjà appliqué avec succès
- Suppressed
- message transporté mais écarté avant effet
- Issue terminale
- résultat durable d’une clé d’idempotence, consulté avant la révision
- Révision monotone
- numéro qui ne recule jamais et permet au service destinataire, ou sink, de refuser un effet devenu obsolète
- État strictement versionné
- document dont le schéma, les clés, les listes SHA-256 et les révisions sont contrôlés avant restauration
Décision actuelle: mise en service interdite pour l’instant. Deux essais ont arrêté la première copie du programme d’alertes, proprement puis brutalement. Un troisième a gardé les deux copies actives mais a coupé leur lien de coordination. Les envois physiques en double ont été vus, puis les étapes de stockage n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. Ce qui reste à faire: Il reste à relier le vrai détecteur de pannes, à déployer une base résistante aux pannes et le réseau privé, à gérer les accès, à prouver restauration, charge et délais, puis à tester la prise en charge humaine.Décision actuelle: promotion NO-GO, pas de mise en production. Le contrat additif et ses labs ciblés sont complétés par deux exécutions indépendantes et identiques GREEN. Le fichier schema.sql v2 n’est pas une migration in-place du prototype v1: une base v1 doit être exportée, contrôlée et migrée par un parcours dédié; appliquer directement ce schéma par-dessus v1 n’est pas supporté. Chaque exécution verrouille 47 fichiers au digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8; vérificateur 3/3, mutations 81/81, 1 425 contrôles exécutés, 846 uniques, 579 répétés et 31 scénarios. passes=2 désigne seulement les deux passes nominales, arrêt contrôlé exit 0 et crash SIGKILL exit 137. Une passe runtime isolée supplémentaire porte totalRuntimePasses à 3. Les deux Alertmanager restent vivants mais sans gossip, chacun voit un membre et expose cluster_members=1; A et B notifient firing puis resolved. Le receiver voit les doublons physiques, mais outbox, bridge, PostgreSQL Operations, dispatcher et sink ne conservent qu’une transition durable firing et une resolved. B rejoint avec la même IP, le pairage redevient exactement 2 et cluster_members=2. Deux signaux et un échec enfant laissent zéro résidu. Cette partition gossip isolée et les deux failovers bornés sont prouvés localement, sans garantie générale d’une notification unique. Alertmanager reste at-least-once et fail-open. Le deadman n’a aucun effet aval. Autres partitions, répétitions, Prometheus réel, humain, production, systemd, restauration, charge et SLO ne sont pas prouvés. Blockers: Prometheus réel dans le parcours complet, unités de production, provisioning systemd-sysusers et boot systemd PID1, récupération opérateur de la DLQ, identités runtime opérées, PostgreSQL HA, sauvegarde/restauration souveraines, consumer operator-primary, notification humaine, charge, SLO et approbation restent à prouver.
Opérer le composant
Responsabilité, séquence nominale, panne et niveau de service attendu.
| Owner et rôle | Séquence nominale | Mode dégradé | Observabilité et SLO |
|---|---|---|---|
Journalise transitions, obligations, tentatives, acquittements et escalades. L’owner d’objets navy_phone_edge_health_owner est NOLOGIN, NOSUPERUSER et distinct de l’owner métier cible SRE opérations et plateforme données.Non-rôle: Ne remplace pas le receiver Python, ne contacte aucun humain et ne prend aucune décision carrier. | Une notification a bien produit son effet, mais sa fin d’écriture en base se perd. Après une résolution et un redémarrage, la nouvelle tentative reconnaît la même clé, reste accepted et ne rejoue pas l’effet; une clé déjà suppressed le reste. Le lab exerce aussi ce parcours pour une escalade suivie d’un acquittement. | Le lab exerce les deux permutations firing/resolved et escalation/acknowledged avec perte de completion DB, retry de lease et redémarrage réel: deux requêtes, un seul effet et aucun faux audit suppressed. Un lease en vol n’est jamais présenté comme annulé; une résolution compensatrice et les races résolution/ACK restent auditées dans les deux ordres exercés. Le stress a reproduit trois fois une course intermittente de même génération avant le verrou transactionnel PostgreSQL dérivé de generation_id; la série propre 5/5 confirme 22 contrôles par passage, cleanup vrai et aucune nouvelle unique_violation. Le lab ciblé séparé prouve la persistance du sink synthétique et pg_dump/pg_restore préserve l’owner. Les nouveaux scénarios font converger la résolution du survivor après arrêt contrôlé puis après SIGKILL du sender avec duplicate_count=0. Ils prouvent localement ces deux failovers bornés, pas une partition, une répétition ou une garantie générale de notification unique. | Le niveau de preuve est Candidat + E2E local. Aucun SLO de production n’est acquis; l’owner doit mesurer disponibilité, erreurs, saturation et reprise avant promotion. |
Panne, reprise et surveillance
Modes de panne connus, comportement de reprise et signaux à mesurer avant toute mise en service.
| Modes de panne | Reprise après incident | Signaux à mesurer |
|---|---|---|
| Cinq journaux append-only et une outbox transactionnelle conservent transitions, tentatives, acquittements et escalades. La restauration exige un état strictement versionné; le lab prouve reprise, redémarrage réel et série propre 5/5 après correction de la course. Sauvegarde, restauration hors lab et base résistante aux pannes restent à prouver. | Existent: journaux append-only par tentative avec started puis result, et labs ciblés dont 22 contrôles par passage en série propre. N’existent pas: métriques de production ni SLO. Avant promotion, mesurer conflits d’idempotence, expiration de leases, délais d’écriture et résultats de restauration sur vraie base. |
Déplier ou replier les détails d’architecture
Contrat d’architecture
Entrées, sorties, protocoles, données, dépendances et configuration.
| Amont et entrées | Aval et sorties | Interfaces et trust boundary | État, données et déploiement |
|---|---|---|---|
| Webhook nominal produit par deux Alertmanager 0.33.1 A/B réels et accepté en HTTPS mTLS par receiver.py. Outbox persistante déjà détenue par le receiver, puis broker Unix isolé et bridge A/B avec identités mTLS distinctes. Le client brut reste limité aux tests négatifs et de chaos; Prometheus réel n’est pas lancé. | Dispatcher réel, sink transactionnel réel et PostgreSQL dédié jusqu’à l’obligation durable operator-primary non consommée; aucun canal ni acquittement humain n’est intégré. | PostgreSQL 18.6 avec pgcrypto; rôles NOLOGIN ingest/dispatch/operator/recovery et fonctions bornées dont le search_path place pg_temp en dernière position. Le lab prouve qu’un objet temporaire homonyme ne détourne pas la fonction privilégiée et n’ouvre aucun port hôte. | Cinq journaux append-only et une outbox transactionnelle. schema.sql v2 n’est pas une migration in-place du prototype v1: une base v1 doit suivre un parcours d’export, de contrôle et de migration dédié. Chaque tentative produit started puis result dans la même table; répéter started avec le même lease est idempotent. Le sink consulte d’abord l’issue terminale de l’idempotency key, puis la lifecycle_revision: une clé déjà appliquée reste accepted sans rejouer l’effet; une clé déjà supprimée reste suppressed. La completion inscrit un outcome distinct suppressed pour un effet réellement écarté. Le payload révisé et les tombstones resolved/acknowledged gouvernent les autres effets obsolètes.Déploiement: Intégré uniquement dans les deux parcours E2E locaux et non déployé; aucun PostgreSQL HA, login opérateur, réseau souverain ou liaison d’identité runtime de production n’est acquis. |
Frontière de confiance: Privée, au cœur du plan management: la base n’accepte que des rôles mTLS bornés ingest, dispatch, operator et recovery, tous NOLOGIN, avec des fonctions dont le search_path place pg_temp en dernier. Aucun port hôte n’est ouvert dans le lab; seuls les services autorisés écrivent ou consomment les obligations.
Déplier ou replier les détails de sécurité et de preuve
Sécurité, preuve et décision
Le statut de preuve reste visible quel que soit le profil choisi.
| Sécurité et identité | Preuve et sources | Blockers | Définitions |
|---|---|---|---|
PostgreSQL 18.6 avec pgcrypto; rôles NOLOGIN ingest/dispatch/operator/recovery et fonctions bornées dont le search_path place pg_temp en dernière position. Le lab prouve qu’un objet temporaire homonyme ne détourne pas la fonction privilégiée et n’ouvre aucun port hôte. | Niveau de preuve: Le contrat additif et ses labs ciblés sont complétés par deux exécutions indépendantes et identiques GREEN. Le fichier schema.sql v2 n’est pas une migration in-place du prototype v1: une base v1 doit être exportée, contrôlée et migrée par un parcours dédié; appliquer directement ce schéma par-dessus v1 n’est pas supporté. Chaque exécution verrouille 47 fichiers au digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8; vérificateur 3/3, mutations 81/81, 1 425 contrôles exécutés, 846 uniques, 579 répétés et 31 scénarios. passes=2 désigne seulement les deux passes nominales, arrêt contrôlé exit 0 et crash SIGKILL exit 137. Une passe runtime isolée supplémentaire porte totalRuntimePasses à 3. Les deux Alertmanager restent vivants mais sans gossip, chacun voit un membre et expose cluster_members=1; A et B notifient firing puis resolved. Le receiver voit les doublons physiques, mais outbox, bridge, PostgreSQL Operations, dispatcher et sink ne conservent qu’une transition durable firing et une resolved. B rejoint avec la même IP, le pairage redevient exactement 2 et cluster_members=2. Deux signaux et un échec enfant laissent zéro résidu. Cette partition gossip isolée et les deux failovers bornés sont prouvés localement, sans garantie générale d’une notification unique. Alertmanager reste at-least-once et fail-open. Le deadman n’a aucun effet aval. Autres partitions, répétitions, Prometheus réel, humain, production, systemd, restauration, charge et SLO ne sont pas prouvés. Fiche PostgreSQL opérations. Même preuve finale 3/3, 81/81, 1 425/846/579, 31 scénarios, passes=2 et totalRuntimePasses=3. Pendant la partition, les doublons physiques convergent vers un firing et un resolved durables dans Operations et le sink. Autres partitions, répétitions, production, systemd, humain, charge et SLO restent hors preuve. Promotion NO-GO.Vue d’autorité du domaine · Entrée du catalogue | NO-GO: Prometheus réel dans le parcours complet, unités de production, provisioning systemd-sysusers et boot systemd PID1, récupération opérateur de la DLQ, identités runtime opérées, PostgreSQL HA, sauvegarde/restauration souveraines, consumer operator-primary, notification humaine, charge, SLO et approbation restent à prouver. | Consulter les définitions de cette fiche |
| Données et souveraineté UE | La base conserve des métadonnées d’alertes content-free: transitions, livraisons, acquittements et escalades, sans contenu d’appel. Elle vit en candidat local sur le plan privé; aucune sortie vers un tiers n’existe. Résidence UE, chiffrement au repos opéré et sauvegarde prouvée restent absents. | ||