Symptôme visible
L’état opérationnel devient incomplet; ce composant ne prévient encore aucun humain à lui seul.
État réel:lab hostile 23/23runtime-lab intégré 12/12deadman stale 180 sSQLite borné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
Conserver l’état des alertes. C’est une partie distincte de Navy Phone.
À quoi ça sert
Reconnaître les copies d’une même alerte et suivre si le problème est actif ou résolu.
Qui en bénéficie
Les personnes qui appellent et l’équipe chargée de détecter puis traiter les pannes.
Situation déclenchante
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois.
Exemple concret
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois. Une seule situation cohérente est conservée pour l’exploitation.
Voir l’exemple technique précis
Deux copies de la même génération ne créent qu’un état, même avec un EndsAt provisoire ou résolu différent.
Résultat observable
Une seule situation cohérente est conservée pour l’exploitation.
Ce dont il dépend
Des bilans de santé récents, du réseau privé et des étapes voisines de la chaîne d’alerte.
Que se passe-t-il en panne?
L’état opérationnel devient incomplet; ce composant ne prévient encore aucun humain à lui seul.
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é: Receiver privé durable d’alertes.
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois.
Reconnaître les copies d’une même alerte et suivre si le problème est actif ou résolu.
Une seule situation cohérente est conservée pour l’exploitation.
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: Une seule situation cohérente est conservée pour l’exploitation.
En cas de panne: L’état opérationnel devient incomplet; ce composant ne prévient encore aucun humain à lui seul.
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
- Receiver
- terminaison de notification
- Deadman
- battement attestant que la supervision fonctionne
- EndsAt
- fin déclarée d’une alerte
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.
État durable, séquence et modes dégradés
Owner: SRE/astreinte. Non-rôle: aucune alerte sortante, aucun ticket, aucun appel téléphonique et aucune décision carrier.
| Nominal | État / données | Panne / reprise | Observabilité / SLO |
|---|---|---|---|
Valide le webhook, ouvre BEGIN IMMEDIATE, classe nouveau/duplicate/resolved/ignoré, met à jour SQLite puis remplace atomiquement le snapshot. | Digests de fingerprint/payload, code revu, enum d’état, timestamps bornés et compteurs; rétention 7 jours, 10 000 lignes max, fichiers 0600. | Retry identique dédupliqué; firing après resolved ignoré; génération obsolète ignorée. Pas de réplication, backup/restauration ni bascule. | Snapshot rafraîchi toutes les 30 s; deadman stale après 180 s. Aucun SLO de livraison ou d’acquittement. |
Déplier ou replier les détails d’architecture
Interfaces, dépendances et déploiement
Le receiver est la terminaison de notification, distincte du collecteur de telemetry et des Alertmanager.
| Entrées | Sorties | Dépendances | Configuration |
|---|---|---|---|
POST /v1/alerts avec schéma webhook v4, maximum 16 alertes et truncatedAlerts=0; POST /v1/deadman avec exactement un firing deadman. | Réponse JSON bornée, SQLite receiver.sqlite3 et snapshot.json; aucun appel réseau sortant. | Alertmanager A/B, CA notification dédiée, horloge et stockage local systemd. | Bind cible 10.72.40.60:9444, 8 workers + 16 requêtes en file, timeout 5 s, service non privilégié et réseau privé. Aucun module cloud. |
Sources dépôt: infra/telephony/edge-health-receiver/receiver.py, unité systemd, config exacte, README et lab/run.py. Preuve: registre des preuves.
Déplier ou replier les détails de sécurité et de preuve
Contrat mTLS, sécurité et preuve hostile
Le serveur lie simultanément certificat, SAN, EKU et adresse source au rôle Alertmanager attendu.
| Identité / trust boundary | Garde applicative | Preuve locale | Blockers |
|---|---|---|---|
CA notification dédiée; SAN client exact A ou B lié à 10.72.41.20/32 ou 10.72.42.20/32; SAN serveur operations-alerts.monitoring.navy.invalid. | JSON sans clés dupliquées, méthode/route/content-type/content-length exacts, labels et annotations fermés; aucun payload, certificat, numéro, transcript ou donnée SIP loggé. | Le lab isolé 23/23 refuse les schémas legacy/affaibli, le snapshot obsolète et l’EKU client hostile; il vérifie firing et resolved idempotents et le watchdog deadman actif. Le lab intégré 12/12 ajoute deux Alertmanager réels, panne receiver puis retry, doublons de partition dédupliqués et deadman stale à 180 s. | Déploiement souverain, réplication receiver, sauvegarde/restauration, livraison humaine, acquittement, escalade et SLO. |