Ce que vous voyez
Les changements attendent ou sont isolés après plusieurs échecs; cette fonction ne prévient personne.
État d’avancement:Essai localfiche de référencemise en service interdite pour l’instantÉtat réel:Code + labs Unix/PGpage 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
Relier les alertes au suivi des opérations.
Transmettre chaque début et résolution au suivi privé sans prétendre prévenir un humain.
Une comparaison utile
Comme un coursier: il transmet sans modifier.
Ce qui entre
Le service de réception accepte une alerte ou sa résolution.
Qui en bénéficie et quel résultat attendre
Le suivi conserve une trace durable du début ou de la fin du problème.
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 changements attendent ou sont isolés après plusieurs échecs; cette fonction ne prévient personne.
Responsable
Responsable du passage des alertes vers les opérations. Autorité de décision: Responsable fiabilité des opérations.
Décision suivante
Autoriser le passage quand chaque début et résolution est transmis durablement sans créer de faux événement tardif.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Le service de réception accepte une alerte ou sa résolution.
Ce dont il dépend
Du service qui reçoit les alertes, d’un passage local protégé désormais testé et de la base privée de suivi. Aucun canal humain n’est encore branché.
Comment le service continue
La mise à niveau est refusée ou annulée tant qu’un incident est actif. La disponibilité du déploiement cède à l’intégrité des alertes: aucun faux début de problème tardif n’est créé. L’astreinte utilise une procédure manuelle séparée, car cette fonction ne la prévient pas.
Preuve attendue avant la prochaine étape
Essais de panne, reprise, changement de version, alertes empoisonnées et arrêt avec incident encore actif.
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 ce relais et tout le suivi 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émarrer les services et les comptes comme en production, à prouver la reprise manuelle des éléments mis de côté, le canal humain, la résistance aux pannes, la restauration, la charge et les délais dans un hébergement réel.
Exemple concret
Le service de réception accepte une alerte ou sa résolution. Le suivi conserve une trace durable du début ou de la fin du problème.
Voir l’exemple technique précis
Le receiver publie une transition via le broker Unix isolé; une instance A ou B l’écrit dans PostgreSQL Operations v2. Les preuves couvrent crash après commit, replay, révocation mTLS en vol, poison et nettoyage sans doubler l’effet.
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 ce relais et tout le suivi 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 le passage quand chaque début et résolution est transmis durablement sans créer de faux événement tardif. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Transmettre chaque début et résolution au suivi privé sans prétendre prévenir un humain. Le suivi conserve une trace durable du début ou de la fin du problème. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Du service qui reçoit les alertes, d’un passage local protégé désormais testé et de la base privée de suivi. Aucun canal humain n’est encore branché. Il reste à relier le vrai détecteur de pannes, à démarrer les services et les comptes comme en production, à prouver la reprise manuelle des éléments mis de côté, le canal humain, la résistance aux pannes, la restauration, la charge et les délais dans un hébergement réel. Preuve attendue: Essais de panne, reprise, changement de version, alertes empoisonnées et arrêt avec incident encore actif. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Transmettre chaque début et résolution au suivi privé sans prétendre prévenir un humain. 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 ce relais et tout le suivi 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 du passage des alertes vers les opérations. 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: Relier les alertes au suivi des opérations.
Le service de réception accepte une alerte ou sa résolution.
Transmettre chaque début et résolution au suivi privé sans prétendre prévenir un humain.
Le suivi conserve une trace durable du début ou de la fin du problème.
Comment lire ce trajet: avancez avec les flèches du clavier ou sélectionnez une étape. Les contrats exacts restent dans la « Vue architecte ».
Étape 1 sur 3: Le service de réception accepte une alerte ou sa résolution.
Impact utile: Le suivi conserve une trace durable du début ou de la fin du problème.
En cas de panne: Les changements attendent ou sont isolés après plusieurs échecs; cette fonction ne prévient personne.
Responsable: Responsable du passage des alertes vers les opérations. 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
La mise à niveau est refusée ou annulée tant qu’un incident est actif. La disponibilité du déploiement cède à l’intégrité des alertes: aucun faux début de problème tardif n’est créé. L’astreinte utilise une procédure manuelle séparée, car cette fonction ne la prévient pas.
Qui prévenir et où lire les preuves
Responsable du passage des alertes vers les opérations. 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
- Bridge
- service qui relie deux étapes sans devenir leur autorité
- Outbox attachée
- file locale écrite dans la même transaction que l’état du receiver
- DLQ
- zone isolant un événement après épuisement des reprises
- Firing
- début ou maintien d’un problème
- Resolved
- fin déclarée du problème
- Deadman
- battement technique traité séparément et exclu de ce bridge
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 ce relais et tout le suivi 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émarrer les services et les comptes comme en production, à prouver la reprise manuelle des éléments mis de côté, le canal humain, la résistance aux pannes, la restauration, la charge et les délais dans un hébergement réel.Décision actuelle: promotion NO-GO, pas de mise en production. Le broker Unix local isolé est implémenté et le bridge A/B utilise des identités mTLS distinctes vers PostgreSQL Operations v2. 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; dans les deux, le receiver résout la même génération avec duplicate_count=0. 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 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. Les comptes bridge de 31 caractères restent résolus après useradd par pwd.getpwnam. Autres partitions, répétitions, Prometheus réel, systemd, récupération DLQ, humain, production, charge, SLO et restauration ne sont pas prouvés. Blockers: Prometheus réel dans le parcours complet, provisioning systemd-sysusers et boot systemd PID1 réels, récupération DLQ locale opérateur, canal humain, déploiement souverain, HA PostgreSQL, restauration coordonnée, 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 |
|---|---|---|---|
Transforme durablement chaque transition firing/resolved des huit alertes d’exploitation en écriture privée vers PostgreSQL Operations. Owner cible: SRE supervision; le runbook et la prise en charge humaine restent séparés.Non-rôle: N’intègre pas le deadman, ne notifie aucun humain, n’acquitte aucune alerte et ne remplace ni le receiver, ni PostgreSQL Operations, ni le futur canal d’astreinte. | Le receiver publie une transition via le broker Unix isolé; une instance A ou B l’écrit dans PostgreSQL Operations v2. Les preuves couvrent crash après commit, replay, révocation mTLS en vol, poison et nettoyage sans doubler l’effet. | Le candidat borne les leases, délais et huit tentatives, puis isole l’événement en DLQ. Crash après commit, replay, révocation mTLS en vol, poison et cleanup sont exercés. Les comptes navy-phone-edge-health-bridge-a et navy-phone-edge-health-bridge-b ont exactement 31 caractères et sont résolus après useradd par pwd.getpwnam. La disponibilité du déploiement cède à l’intégrité des alertes: le service conserve l’ancienne version ou reste arrêté plutôt que d’inventer un état. Le provisioning systemd-sysusers, le boot systemd PID1 réel, la récupération opérateur de la DLQ locale et la HA restent à exercer. | Le niveau de preuve est Code + labs Unix/PG. 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 |
|---|---|---|---|
| Receiver privé propriétaire de ses fichiers, via un broker Unix local borné et isolé. Le bridge A/B ne voit ni la base principale ni l’outbox interne; transitions firing/resolved de huit codes, deadman exclu. | PostgreSQL Operations v2 privé sur TCP/5432 avec rôles mTLS A/B; aucun ticket, SMS, appel, email, push ou acquittement humain. | Le broker Unix local borné et isolé est implémenté et prouvé sous Linux exact: le bridge distinct ne voit ni la base principale ni l’outbox interne. Deux instances A/B visent PostgreSQL Operations v2 sur TCP/5432 avec identités mTLS A/B distinctes. Le deadman est explicitement exclu. | Migration v1 fail-closed: le préflight exige zéro incident firing actif avant bootstrap. Si un incident est actif, l’upgrade est refusé ou rollbacké; aucun rattrapage tardif et aucun faux firing tardif ne sont permis.Déploiement: Candidat local non déployé; vrai boot systemd PID1, récupération opérateur de la DLQ locale, PostgreSQL HA, PKI opérée, réseau privé, sauvegarde et restauration coordonnées, SLO et canal humain restent absents ou non prouvés. |
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 |
|---|---|---|---|
| Le broker Unix local borné et isolé est implémenté et prouvé sous Linux exact: le bridge distinct ne voit ni la base principale ni l’outbox interne. Deux instances A/B visent PostgreSQL Operations v2 sur TCP/5432 avec identités mTLS A/B distinctes. Le deadman est explicitement exclu. | Niveau de preuve: Le broker Unix local isolé est implémenté et le bridge A/B utilise des identités mTLS distinctes vers PostgreSQL Operations v2. 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; dans les deux, le receiver résout la même génération avec duplicate_count=0. 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 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. Les comptes bridge de 31 caractères restent résolus après useradd par pwd.getpwnam. Autres partitions, répétitions, Prometheus réel, systemd, récupération DLQ, humain, production, charge, SLO et restauration ne sont pas prouvés. Les preuves ciblées restent acquises: wrapper avec 40 assertions dans 13 scénarios, receiver avec 2107 assertions dans 27 scénarios et lab PostgreSQL avec 109 assertions sur deux passes. Deux runs indépendants identiques sur 47 fichiers au digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8 ajoutent 3/3, 81/81, 1 425/846/579 et 31 scénarios. passes=2 couvre les pannes; totalRuntimePasses=3 ajoute une partition gossip isolée. Les doublons physiques convergent vers un firing et un resolved durables. Production et humain restent absents. Promotion NO-GO.Vue d’autorité du domaine · Entrée du catalogue | NO-GO: Prometheus réel dans le parcours complet, provisioning systemd-sysusers et boot systemd PID1 réels, récupération DLQ locale opérateur, canal humain, déploiement souverain, HA PostgreSQL, restauration coordonnée, charge, SLO et approbation restent à prouver. | Consulter les définitions de cette fiche |