Symptôme visible
Les événements restent en attente ou finissent en échec contrôlé; aucun humain n’est prévenu par ce composant.
État réel:Candidat + labs locauxpage d’autorité composantpromotion NO-GO
Quel est votre profil?
Comment choisir ma vue?
Direction ou métier: valeur, bénéficiaires, résultat, dépendances, panne et responsabilité. Opérations ou support: symptômes, première action, repli et escalade. Architecte ou ingénieur: protocoles, ports, configuration, données, tests et preuves.
Vue Direction / métier affichée. Ce choix sera repris sur les autres fiches. Les risques et le statut NO-GO restent toujours visibles.
En clair: comprendre en 60 secondes
Aucun bagage technique n’est nécessaire pour lire cette vue.
Ce qu’il faut retenir
Ce que c’est
Acheminer les événements vers le registre opérateur. C’est une partie distincte de Navy Phone.
À quoi ça sert
Prendre chaque élément d’exploitation en attente et le transmettre de façon contrôlée, sans le confondre avec une notification humaine.
Qui en bénéficie
Les personnes qui appellent et l’équipe chargée de détecter puis traiter les pannes.
Situation déclenchante
La base des opérations contient un événement prêt à être transmis.
Exemple concret
La base des opérations contient un événement prêt à être transmis. Le destinataire privé reçoit une seule version cohérente de l’événement, 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.
Résultat observable
Le destinataire privé reçoit une seule version cohérente de l’événement, même après une nouvelle tentative.
Ce dont il dépend
De la base des opérations et du sink privé destinataire. Aucun canal humain ne dépend encore de lui en production.
Que se passe-t-il en panne?
Les événements restent en attente ou finissent en échec contrôlé; aucun humain n’est prévenu par ce composant.
Repli et intervention manuelle
Les événements restent en base pour une reprise bornée. L’astreinte doit utiliser une procédure manuelle séparée, car ce composant ne la prévient pas.
Responsable au quotidien
L’équipe d’exploitation téléphonique surveille ce composant et décide du repli.
Statut réel
Le code, 75 tests avec un destinataire simulé et deux passages successifs d’un laboratoire local avec une vraie base et deux identités existent. Ils ne prouvent ni un déploiement réel, ni une astreinte humaine. Décision actuelle: promotion NO-GO, pas de mise en production.
Lecture métier et trajet simple
Le flux montre ce qui arrive au composant, ce qu’il fait et à qui il transmet. Tout reste lisible sans JavaScript.
Suivre le flux
Composant documenté: Dispatcher privé des événements opérateur edge-health.
La base des opérations contient un événement prêt à être transmis.
Prendre chaque élément d’exploitation en attente et le transmettre de façon contrôlée, sans le confondre avec une notification humaine.
Le destinataire privé reçoit une seule version cohérente de l’événement, même après une nouvelle tentative.
Comment lire ce trajet: un besoin arrive, cette partie du système rend un service précis, puis une personne ou une équipe en bénéficie. Les noms de protocoles restent dans la vue Architecte.
Étape 1 sur 3: le besoin auquel le composant répond.
Impact utile: Le destinataire privé reçoit une seule version cohérente de l’événement, même après une nouvelle tentative.
En cas de panne: Les événements restent en attente ou finissent en échec contrôlé; aucun humain n’est prévenu par ce composant.
Responsable: L’équipe d’exploitation téléphonique surveille ce composant et décide du repli.
Aide Opérations / support
Reconnaître le symptôme, protéger le service et transmettre au bon responsable sans improviser.
Première action sûre
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.
Repli manuel
Les événements restent en base pour une reprise bornée. L’astreinte doit utiliser une procédure manuelle séparée, car ce composant ne la prévient pas.
Escalade et runbook
L’équipe d’exploitation téléphonique surveille ce composant et décide du repli. Le runbook de production reste à valider avant mise en service. Ouvrir le document de référence.
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: promotion NO-GO, pas de mise en production. Le code, 75 tests avec un destinataire simulé et deux passages successifs d’un laboratoire local avec une vraie base et deux identités existent. Ils ne prouvent ni un déploiement réel, ni une astreinte humaine. Ce qui manque: Il reste à déployer une base hautement disponible et le réseau privé, à exploiter les identités, à mesurer la charge et à relier un canal humain approuvé.
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. 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. |
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. |
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, 75 tests HTTPS mTLS avec sink simulé et un lab PostgreSQL 18.6 reproduit deux fois sous Node.js 22.23.2 exact avec authentification mTLS A/B et fonctions operations v2 réelles existent. Aucun déploiement privé, PostgreSQL HA, sink réel ou chemin humain n’est prouvé par cette fiche. Vérificateur contractuel, 75 tests HTTPS mTLS avec sink simulé et lab PostgreSQL 18.6 reproduit deux fois sous Node.js 22.23.2 exact avec certificats A/B, identités session_user et fonctions claim/start/complete réelles. Aucun sink réel déployé, canal de messagerie ou humain notifié. 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 |