Ce que vous voyez
Les alertes restent en attente ou finissent en échec contrôlé; aucun humain n’est prévenu par cette fonction.
État d’avancement:Essai localfiche de référencemise en service interdite pour l’instantÉtat réel:Candidat + labs locauxpage 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
Transmettre les alertes au suivi des opérations.
Transmettre chaque alerte en attente avec contrôle, sans la confondre avec une notification humaine.
Une comparaison utile
Comme un agent de distribution: il remet le dossier au bon guichet.
Ce qui entre
Le suivi des opérations contient une alerte prête à être transmise.
Qui en bénéficie et quel résultat attendre
Le service privé chargé de la conserver reçoit une seule version cohérente de l’alerte, même après une nouvelle tentative.
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
Les alertes restent en attente ou finissent en échec contrôlé; aucun humain n’est prévenu par cette fonction.
Responsable
Responsable de l’acheminement des alertes opérateur. Autorité de décision: Responsable fiabilité des opérations.
Décision suivante
Autoriser l’acheminement lorsqu’un événement est tenté, transmis et terminé dans la limite de cinq secondes.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Le suivi des opérations contient une alerte prête à être transmise.
Ce dont il dépend
De la base des opérations et du registre privé destinataire. Aucun canal humain ne dépend encore de lui en production.
Comment le service continue
Les événements restent en base pour une reprise bornée. L’astreinte doit utiliser une procédure manuelle séparée, car cette fonction ne la prévient pas.
En cas de panne et pour vos données
Ce service remet chaque alerte en attente au registre final. Si la réponse se perd, il recommence avec la même référence et le registre reconnaît l’envoi déjà reçu. En cas de panne, les alertes attendent une reprise limitée. Tout reste dans le réseau privé et personne n’est prévenu.
Preuve attendue avant la prochaine étape
Essais avec vraie base, liaison chiffrée, deux travailleurs, délais, rejeu, poison et réponse perdue.
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 service et le registre final n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Cela ne prouve ni une mise en service réelle, ni une astreinte humaine. Il reste à relier le vrai détecteur de pannes, à mettre en service une base capable de résister à une panne et le réseau privé, à gérer les accès, à mesurer la charge et à relier un canal humain approuvé.
Exemple concret
Le suivi des opérations contient une alerte prête à être transmise. Le service privé chargé de la conserver reçoit une seule version cohérente de l’alerte, même après une nouvelle tentative.
Voir l’exemple technique précis
Après un effet accepté mais une réponse perdue, le dispatcher rejoue la même clé. Le sink retrouve le reçu initial et la completion en base reste idempotente.
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 service et le registre final n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Cela ne prouve ni une mise en service réelle, ni une astreinte humaine. Autoriser l’acheminement lorsqu’un événement est tenté, transmis et terminé dans la limite de cinq secondes. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Transmettre chaque alerte en attente avec contrôle, sans la confondre avec une notification humaine. Le service privé chargé de la conserver reçoit une seule version cohérente de l’alerte, même après une nouvelle tentative. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: De la base des opérations et du registre privé destinataire. Aucun canal humain ne dépend encore de lui en production. Il reste à relier le vrai détecteur de pannes, à mettre en service une base capable de résister à une panne et le réseau privé, à gérer les accès, à mesurer la charge et à relier un canal humain approuvé. Preuve attendue: Essais avec vraie base, liaison chiffrée, deux travailleurs, délais, rejeu, poison et réponse perdue. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Transmettre chaque alerte en attente avec contrôle, sans la confondre avec une notification 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 service et le registre final n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Cela ne prouve ni une mise en service réelle, ni une astreinte humaine. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable de l’acheminement des alertes opérateur. Autorité de décision: Responsable fiabilité 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: Transmettre les alertes au suivi des opérations.
Le suivi des opérations contient une alerte prête à être transmise.
Transmettre chaque alerte en attente avec contrôle, sans la confondre avec une notification humaine.
Le service privé chargé de la conserver reçoit une seule version cohérente de l’alerte, même après une nouvelle tentative.
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 suivi des opérations contient une alerte prête à être transmise.
Impact utile: Le service privé chargé de la conserver reçoit une seule version cohérente de l’alerte, même après une nouvelle tentative.
En cas de panne: Les alertes restent en attente ou finissent en échec contrôlé; aucun humain n’est prévenu par cette fonction.
Responsable: Responsable de l’acheminement des alertes opérateur. Autorité de décision: Responsable fiabilité 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 restent en base pour une reprise bornée. L’astreinte doit utiliser une procédure manuelle séparée, car cette fonction ne la prévient pas.
Qui prévenir et où lire les preuves
Responsable de l’acheminement des alertes opérateur. Autorité de décision: Responsable fiabilité 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
- Dispatcher
- service qui prend une obligation en attente et la transmet
- Idempotence
- une nouvelle tentative ne répète pas l’effet
- Poison
- événement invalide isolé sans bloquer les suivants
- Lease
- droit temporaire de traiter une obligation
- mTLS
- authentification chiffrée des deux services
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 service et le registre final n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Cela ne prouve ni une mise en service réelle, ni une astreinte humaine. Ce qui reste à faire: Il reste à relier le vrai détecteur de pannes, à mettre en service une base capable de résister à une panne et le réseau privé, à gérer les accès, à mesurer la charge et à relier un canal humain approuvé.Décision actuelle: promotion NO-GO, pas de mise en production. Le candidat, 78 tests HTTPS mTLS et le lab PostgreSQL 18.6 existent. 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. Autres partitions, répétitions, Prometheus réel, déploiement, PostgreSQL HA, humain, systemd, charge et SLO restent absents. Blockers: PKI opérée, PostgreSQL HA, déploiement A/B, charge, SLO, restauration coordonnée, canal humain 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 |
|---|---|---|---|
| Réclame les obligations operations v2, journalise la tentative avant le réseau et transmet chaque événement au sink. Owner cible: SRE opérations. Non-rôle: Ne contacte aucun humain, carrier, PSTN, SMS, email ou fournisseur de messagerie et ne décide pas l’état métier de l’alerte. | Après un effet accepté mais une réponse perdue, le dispatcher rejoue la même clé. Le sink retrouve le reçu initial et la completion en base reste idempotente. | Deux workers, concurrence et délais bornés. Dans la configuration candidate destinée à la production, le timeout vers le sink est fixé à exactement 5 000 ms. Les erreurs temporaires sont rejouées; les réponses invalides sont bloquées sans immobiliser l’événement sain suivant. | Le niveau de preuve est Candidat + labs locaux. 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 |
|---|---|---|
| Le dispatcher ne détient aucun état métier local: tout dépend des leases, témoins epoch et completions idempotentes de la base des opérations; les événements y restent pour une reprise bornée. Les 78 tests HTTPS mTLS et le lab PostgreSQL prouvent rejeu, poison et réponse perdue; la reprise après panne de la base HA reste absente. | Existent: journalisation de chaque tentative avant le réseau, 78 tests et le lab PostgreSQL 18.6. N’existent pas: métriques de production ni SLO. Avant promotion, mesurer délai de bout en bout par événement, taux de rejeu, profondeur d’attente, saturation des deux workers et temps de reprise. |
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 |
|---|---|---|---|
| Outbox PostgreSQL edge_health_operations v2 et deux identités runtime mTLS A/B. | Sink opérateur privé HTTPS mTLS sur TCP/9445; aucun canal humain n’est branché. | PostgreSQL mTLS par identité A/B, puis HTTPS mTLS vers 10.72.40.70:9445. Identités base et sink séparées. | Aucun état métier local. Dépend des leases, témoins epoch/watermark et completions idempotentes de PostgreSQL operations v2. Déploiement: Candidat local non déployé; PostgreSQL HA, pg_hba.conf, PKI opérée, réseau privé et supervision de production restent absents. |
Frontière de confiance: Privée, entre la base des opérations et le sink: le dispatcher réclame les obligations en mTLS avec des identités A/B distinctes, journalise chaque tentative avant le réseau, puis transmet en HTTPS mTLS vers une adresse privée sur TCP/9445. Aucun canal humain, carrier ou fournisseur externe ne participe à 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 |
|---|---|---|---|
PostgreSQL mTLS par identité A/B, puis HTTPS mTLS vers 10.72.40.70:9445. Identités base et sink séparées. | Niveau de preuve: Le candidat, 78 tests HTTPS mTLS et le lab PostgreSQL 18.6 existent. 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. Autres partitions, répétitions, Prometheus réel, déploiement, PostgreSQL HA, humain, systemd, charge et SLO restent absents. Vérificateur contractuel, 78 tests HTTPS mTLS et lab PostgreSQL acquis. La preuve finale ajoute deux pannes puis une partition gossip isolée. Malgré les doublons physiques de A et B, dispatcher et sink ne gardent qu’un firing et un resolved durables. passes=2; totalRuntimePasses=3. Autres partitions, répétitions, Prometheus réel, production et humain restent hors preuve. Promotion NO-GO.Vue d’autorité du domaine · Entrée du catalogue | NO-GO: PKI opérée, PostgreSQL HA, déploiement A/B, charge, SLO, restauration coordonnée, canal humain et approbation restent à prouver. | Consulter les définitions de cette fiche |
| Données et souveraineté UE | Le dispatcher transporte des événements d’alerte content-free entre la base privée et le sink privé, sans contenu d’appel ni donnée personnelle documentée. Aucun tiers n’est contacté: ni SMS, ni email, ni messagerie. Réseau privé réel, PKI opérée et résidence UE restent à prouver. | ||