Ce que vous voyez
La future notification humaine n’obtient plus de nouvelle alerte; cette fonction ne contacte elle-même aucun humain.
État d’avancement:Essai localfiche de référencemise en service interdite pour l’instantÉtat réel:Candidat + lab 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
Conserver les alertes pour leur prise en charge.
Recevoir les alertes transmises, écarter les versions dépassées et préparer leur future prise en charge humaine.
Une comparaison utile
Comme un guichet final: il conserve une seule version valable.
Ce qui entre
Le service d’acheminement présente une alerte signée.
Qui en bénéficie et quel résultat attendre
Le suivi des opérations conserve l’alerte une seule fois et indique si elle est retenue ou devenue trop ancienne.
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 future notification humaine n’obtient plus de nouvelle alerte; cette fonction ne contacte elle-même aucun humain.
Responsable
Responsable du registre des alertes opérateur. Autorité de décision: Responsable des opérations.
Décision suivante
Autoriser le registre quand il conserve l’effet avant de répondre et refuse les versions anciennes ou incohérentes.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Le service d’acheminement présente une alerte signée.
Ce dont il dépend
Du service privé d’acheminement, de sa base dédiée et d’un futur service de notification humaine qui n’existe pas encore.
Comment le service continue
Les événements déjà engagés restent dans la base. L’astreinte doit utiliser une procédure manuelle séparée, car aucun canal humain n’est branché.
En cas de panne et pour vos données
Ce registre final garde chaque alerte une seule fois et écarte les versions trop anciennes, même si elles arrivent en retard. Les écritures déjà faites restent en base après une panne. Tout reste dans le réseau privé; le moyen de prévenir une personne n’existe pas encore et reste à construire.
Preuve attendue avant la prochaine étape
Essais sur vraie base couvrant délai total, abandon du client, pause pendant validation, reprise et arrêt de plusieurs demandes.
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 en double ont été vus, puis ce registre n’a conservé qu’un début de problème et une résolution, sans écriture tardive. Les deux copies se sont ensuite retrouvées. Le service n’est pas mis en service et aucune personne n’est notifiée. Il reste à mettre en service la base et le réseau privés, à conserver les preuves de restauration dans un lieu indépendant et à construire puis tester le canal qui préviendra réellement un humain.
Exemple concret
Le service d’acheminement présente une alerte signée. Le suivi des opérations conserve l’alerte une seule fois et indique si elle est retenue ou devenue trop ancienne.
Voir l’exemple technique précis
Une ancienne alerte firing arrive après sa résolution. Le sink conserve un reçu suppressed, n’ajoute aucune nouvelle obligation et renvoie le même résultat lors du retry.
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 en double ont été vus, puis ce registre n’a conservé qu’un début de problème et une résolution, sans écriture tardive. Les deux copies se sont ensuite retrouvées. Le service n’est pas mis en service et aucune personne n’est notifiée. Autoriser le registre quand il conserve l’effet avant de répondre et refuse les versions anciennes ou incohérentes. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Recevoir les alertes transmises, écarter les versions dépassées et préparer leur future prise en charge humaine. Le suivi des opérations conserve l’alerte une seule fois et indique si elle est retenue ou devenue trop ancienne. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Du service privé d’acheminement, de sa base dédiée et d’un futur service de notification humaine qui n’existe pas encore. Il reste à mettre en service la base et le réseau privés, à conserver les preuves de restauration dans un lieu indépendant et à construire puis tester le canal qui préviendra réellement un humain. Preuve attendue: Essais sur vraie base couvrant délai total, abandon du client, pause pendant validation, reprise et arrêt de plusieurs demandes. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Recevoir les alertes transmises, écarter les versions dépassées et préparer leur future prise en charge humaine. 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 en double ont été vus, puis ce registre n’a conservé qu’un début de problème et une résolution, sans écriture tardive. Les deux copies se sont ensuite retrouvées. Le service n’est pas mis en service et aucune personne n’est notifiée. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable du registre des alertes opérateur. Autorité de décision: Responsable des opérations. 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: Conserver les alertes pour leur prise en charge.
Le service d’acheminement présente une alerte signée.
Recevoir les alertes transmises, écarter les versions dépassées et préparer leur future prise en charge humaine.
Le suivi des opérations conserve l’alerte une seule fois et indique si elle est retenue ou devenue trop ancienne.
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: Le service d’acheminement présente une alerte signée.
Impact utile: Le suivi des opérations conserve l’alerte une seule fois et indique si elle est retenue ou devenue trop ancienne.
En cas de panne: La future notification humaine n’obtient plus de nouvelle alerte; cette fonction ne contacte elle-même aucun humain.
Responsable: Responsable du registre des alertes opérateur. Autorité de décision: Responsable des opérations.
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
Les événements déjà engagés restent dans la base. L’astreinte doit utiliser une procédure manuelle séparée, car aucun canal humain n’est branché.
Qui prévenir et où lire les preuves
Responsable du registre des alertes opérateur. Autorité de décision: Responsable des opérations. 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
- Sink
- service destinataire qui engage durablement un événement
- Accepted
- événement reçu et retenu
- Suppressed
- événement reçu mais écarté car obsolète
- Watermark
- compteur durable qui aide à détecter une ancienne restauration
- Obligation
- travail enregistré pour un futur canal, pas une notification déjà livrée
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 en double ont été vus, puis ce registre n’a conservé qu’un début de problème et une résolution, sans écriture tardive. Les deux copies se sont ensuite retrouvées. Le service n’est pas mis en service et aucune personne n’est notifiée. Ce qui reste à faire: Il reste à mettre en service la base et le réseau privés, à conserver les preuves de restauration dans un lieu indépendant et à construire puis tester le canal qui préviendra réellement un humain.Décision actuelle: promotion NO-GO, pas de mise en production. Le candidat passe 79 tests statiques et trois exécutions du lab PostgreSQL 18.6/mTLS. Deux exécutions indépendantes et identiques sont GREEN. Chacune 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 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 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. Les pauses au COMMIT, abandons client et drains ne produisent aucun reçu tardif. Autres partitions, répétitions, Prometheus réel, sink déployé, PostgreSQL HA, humain, systemd, restauration, charge et SLO ne sont pas prouvés. Blockers: Déploiement privé, PostgreSQL HA, ancrage externe epoch/watermark, restauration coordonnée, consumer de canal, notification humaine, idempotence fournisseur, 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 |
|---|---|---|---|
| Engage les reçus opérateur, écarte les révisions dépassées et crée une obligation durable non consommée. Owner cible: SRE opérations et plateforme données. Non-rôle: N’envoie aucun SMS, appel, email, push ou acquittement humain et ne contacte ni carrier, ni PSTN, ni fournisseur externe. | Une ancienne alerte firing arrive après sa résolution. Le sink conserve un reçu suppressed, n’ajoute aucune nouvelle obligation et renvoie le même résultat lors du retry. | Le lab local couvre concurrence, crash après commit, restauration ancienne, changement d’epoch et révisions obsolètes. Les budgets PostgreSQL restent sous le timeout fermé à 5 secondes; pause pendant le commit, abandon client et drain de huit requêtes ne créent aucun reçu tardif. Aucun PostgreSQL HA ou restauration managée. | Le niveau de preuve est Candidat + lab 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 |
|---|---|---|
| Les reçus idempotents, l’inbox et les obligations durables vivent dans la base dédiée; les événements engagés y restent. Le lab couvre crash après commit, restauration ancienne et révisions obsolètes. Aucune restauration managée ni base HA n’existe; les preuves de restauration doivent encore être conservées dans un lieu indépendant, action humaine non définie. | Existent: 79 tests statiques et trois exécutions du lab PostgreSQL 18.6 en mTLS, avec budgets sous le timeout de cinq secondes. N’existent pas: métriques de production ni SLO. Avant promotion, mesurer taux de suppressed, délai total d’engagement, rejets de révision et comportement en restauration ancienne. |
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 |
|---|---|---|---|
| Dispatcher A/B privé avec certificat et adresse source attendus. | PostgreSQL dédié, inbox opérateur et obligation operator-primary non consommée; aucun canal humain n’est branché. | HTTPS mTLS privé TCP/9445 avec identité SAN et adresse source A/B, JSON canonique fermé et PostgreSQL dédié. | Reçus idempotents, tête de révision par génération, watermark global, inbox et obligations de canal annulables. Déploiement: Candidat local non déployé; base HA, PKI opérée, réseau souverain et consumer operator-primary restent absents. |
Frontière de confiance: Privée, terminaison du flux opérateur: le sink n’accepte que le dispatcher A/B en HTTPS mTLS sur TCP/9445, avec SAN et adresse source exacts et un JSON canonique fermé. Il écrit dans sa base dédiée; aucun canal humain, carrier ou fournisseur externe n’est contacté à cette frontière.
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 |
|---|---|---|---|
| HTTPS mTLS privé TCP/9445 avec identité SAN et adresse source A/B, JSON canonique fermé et PostgreSQL dédié. | Niveau de preuve: Le candidat passe 79 tests statiques et trois exécutions du lab PostgreSQL 18.6/mTLS. Deux exécutions indépendantes et identiques sont GREEN. Chacune 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 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 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. Les pauses au COMMIT, abandons client et drains ne produisent aucun reçu tardif. Autres partitions, répétitions, Prometheus réel, sink déployé, PostgreSQL HA, humain, systemd, restauration, charge et SLO ne sont pas prouvés. Vérificateur bijectif, 79 tests statiques et lab PostgreSQL acquis. La preuve finale ajoute deux pannes puis une partition gossip isolée. Les doublons physiques convergent vers un firing et un resolved durables dans le sink. Aucune garantie générale de notification unique; autres partitions, répétitions, production et humain restent hors preuve. L’obligation operator-primary n’est pas consommée. Promotion NO-GO.Vue d’autorité du domaine · Entrée du catalogue | NO-GO: Déploiement privé, PostgreSQL HA, ancrage externe epoch/watermark, restauration coordonnée, consumer de canal, notification humaine, idempotence fournisseur, charge, SLO et approbation restent à prouver. | Consulter les définitions de cette fiche |
| Données et souveraineté UE | Le sink conserve reçus, inbox et obligations de canal annulables, tous content-free et sans contenu d’appel, dans une base dédiée locale au plan privé. Aucune sortie vers un tiers n’existe; le futur canal humain n’est pas construit. Résidence UE et réseau souverain restent non prouvés. | ||