Symptôme visible
La chaîne humaine future ne peut plus savoir de manière fiable ce qui a déjà été livré ou acquitté.
État réel:Candidat + lab synthétiquepage 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
Suivre la livraison et l’acquittement des alertes. C’est une partie distincte de Navy Phone.
À quoi ça sert
Conserver sans doublon les étapes entre une alerte reçue, livrée, acquittée ou escaladée.
Qui en bénéficie
Les personnes qui appellent et l’équipe chargée de détecter puis traiter les pannes.
Situation déclenchante
Une alerte doit produire un effet d’exploitation malgré un redémarrage ou une nouvelle tentative.
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.
Résultat observable
Les équipes peuvent distinguer ce qui a été reçu, tenté, livré et confirmé.
Ce dont il dépend
Du receiver qui fournira les alertes, d’une base disponible et des services autorisés à livrer puis acquitter les événements.
Que se passe-t-il en panne?
La chaîne humaine future ne peut plus savoir de manière fiable ce qui a déjà été livré ou acquitté.
Repli et intervention manuelle
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.
Responsable au quotidien
L’équipe d’exploitation téléphonique surveille ce composant et décide du repli.
Statut réel
Des essais limités sur une machine ont réussi. Ils ne prouvent pas que le service fonctionne dans le cloud, sur le réseau téléphonique réel ou en production. 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é: PostgreSQL des opérations edge-health.
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: 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: 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: 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
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.
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
- 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: promotion NO-GO, pas de mise en production. Des essais limités sur une machine ont réussi. Ils ne prouvent pas que le service fonctionne dans le cloud, sur le réseau téléphonique réel ou en production. Ce qui manque: Il reste à le déployer, à tester de vraies pannes, à mesurer sa fiabilité et à vérifier les services externes.
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, aucune fausse reclassification en 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 passe ensuite 5/5 avec 22 contrôles par passage, cleanup vrai et aucune nouvelle unique_violation. Cette preuve reste locale. Le sink synthétique persiste ses révisions sur disque par fichier temporaire, fsync du fichier, renommage atomique puis fsync du dossier. Son état navy-phone.synthetic-operator-sink-state.v1 est strictement versionné: clés attendues, listes SHA-256 et révisions entières positives sont contrôlées. Le JSON corrompu et le JSON syntaxiquement valide mais incomplet comme {} sont refusés. pg_dump/pg_restore préserve l’owner. Aucun PostgreSQL HA, receiver intégré ou humain réel. | Le niveau de preuve est Candidat + lab synthétique. 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 |
|---|---|---|---|
| Futur adaptateur du receiver edge-health, non intégré aujourd’hui. | Dispatchers d’exploitation et sink mTLS persistant synthétiques du lab; sink réel de production et processus d’acquittement humain restent des cibles non intégrées. | 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. 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é dont l’effet a déjà été appliqué reste accepted sans rejouer l’effet; une clé déjà écarté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: Candidat local non intégré et non déployé; aucun PostgreSQL HA, login opérateur, réseau souverain ou liaison d’identité runtime de production n’est acquis. |
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 son lab local synthétique existent, mais ils ne sont intégrés ni au receiver réel, ni à un humain, ni à un déploiement souverain. Fiche PostgreSQL opérations. Issue terminale, suppression stale, validation stricte de l’état et verrou par génération sont prouvés dans le candidat local seulement. Promotion NO-GO. Sink réel de production, identités runtime, dead-letter queue, nombre maximal de retries, receiver et humain restent non intégrés. Vue d’autorité du domaine · Entrée du catalogue | NO-GO: Adaptateur receiver, sink réel de production appliquant le contrat de révision, identités runtime, PostgreSQL HA, sauvegarde/restauration souveraines, dead-letter queue, nombre maximal de retries, notification humaine, SLO et approbation restent à prouver. | Consulter les définitions de cette fiche |