Suivi de l'aptyme

1) Pourquoi surveiller l'aptame

Aptame - une fraction du temps où le service est disponible pour l'utilisateur. C'est la « première ligne » d'observation : remarquer instantanément une indisponibilité, une dégradation sur le réseau, une défaillance DNS/TLS, des problèmes de routage ou de CDN. Pour les systèmes hautement chargés et réglementés (fintech, iGaming), l'aptyme affecte directement les revenus, l'exécution des SLA et les risques de pénalité.

2) Termes et formules

SLI de disponibilité : 'SLI = (vérifications réussies/toutes les vérifications) × 100 %'.
SLO : disponibilité cible par fenêtre (généralement 28-30 jours), par exemple 99. 9%.
SLA : engagement externe ; toujours ≤ un SLO interne.
MTBF/MTR : temps moyen entre les pannes et le temps moyen de récupération.

99. 0 % → ~ 432 min d'indisponibilité

99. 9 % → ~ 43 min

99. 99% → ~4. 3 min

99. 999 % → ~ 26 secondes

3) Quelles vérifications sont nécessaires (boîte noire)

Ils sont lancés à partir de points externes (différentes régions/fournisseurs) pour voir le service avec les « yeux du client ».

1. ICMP (ping) est le réseau de base/disponibilité du nœud. Rapide, mais ne reflète pas le succès de l'entreprise.
2. TCP connect - le port écoute ? Utile pour les courtiers/OBD/SMTP.
3. HTTP/HTTPS est le code d'état, les en-têtes, la taille, les radiés, l'heure jusqu'au premier octet.
4. TLS/certificats - durée de validité, chaîne, algorithmes, SNI, protocoles.
5. DNS - A/AAAA/CNAME, santé NS, distribution, DNSSEC.
6. gRPC - état de l'appel, deadline, métadonnées.
7. WebSocket/SSE - poignée de main, maintien de la connexion, message-écho.
8. Proxy/routage/CDN - différents PoP, hachage de cache, géo-options.
9. Scripts synthétiques transactionnels (clics/formulaires) : « login → recherche → dépôt (bac à sable) ».
10. Heartbeat/cron-monitoring - le service est tenu de « pulser » (crook une fois par N minutes) ; pas de signal - alarme.

• Rapprochez-vous de l'UX réel (par exemple, TTFB ≤ 300 ms, total ≤ 2 s).
• Vérifiez le contenu assert (mot-clé/champ JSON) afin que « 200 OK » avec une erreur ne soit pas considéré comme un succès.
• Dupliquez les vérifications via des fournisseurs et des réseaux indépendants (multi-hop, ASN différents).

4) La boîte blanche et la santé du service

Liveness/Lecture d'échantillons pour orchestrateur (les processus sont-ils vivants ? prêt à accepter le trafic ?).
Santé des dépendances : OBD, cache, courtier d'événements, API externes (paiements/KYC/AML).
Drapeaux de ficha/dégradation : en cas de problèmes, nous coupons doucement les voies non critiques.

Les échantillons blancs ne remplacent pas les contrôles externes : le service peut être « sain à l'intérieur », mais l'utilisateur n'est pas disponible en raison du DNS/TLS/route.

5) Géographie et multirégionalité

Exécutez des synthétiques à partir de régions clés du trafic et à proximité des fournisseurs de dépendances critiques.
Quorum : on enregistre un incident en cas d'échec dans les régions N ≥ (par exemple 2 sur 3) afin de couper les anomalies locales.
Seuil par cohorte : SLI/SLO distincts pour les segments importants (pays, VIP, opérateurs de télécommunications).

6) Politique d'alerte (minimum de bruit)

Multi-région + multi-échantillon : pager uniquement en cas d'échec négocié (par exemple HTTP et TLS simultanément, ≥ 2 régions).
Debounce : N échecs consécutifs ou fenêtre 2-3 minutes avant la page.

• L1 : on-call (services de production).
• L2 : réseau/plateforme/sécurité en fonction de la signature du défaut.
• Auto-fermeture : après des contrôles stables M réussis.
• Heures silencieuses/concessions : pour les services internes non critiques - seulement des tiquets, pas de pager.

7) Statut-page et communication

Page de statut publique (client) et privée (interne).
Incidents automatiques de synthétiques + annotations manuelles.
Modèles de messages : détecté - identifié - impact - contournement - ETA - résolu - post-musem.
Fenêtres planifiées : annoncer à l'avance, tenir compte des exceptions séparément de SLO.

8) Prise en compte des dépendances externes

Pour chaque fournisseur (paiements, KYC, newsletters, CDN, cloud) - leurs vérifications de plusieurs régions.
Itinéraires de failover : Passage automatique à un fournisseur alternatif par signal synthétique.
SLO séparé au niveau du fournisseur et du e2e-SLO intégré.
Négocier un SLA avec les fournisseurs (status webhooks, priorité de support).

9) Dashboards et widgets clés

Carte du monde avec état des vérifications (par type : HTTP, DNS, TLS).
Incidents temporels avec annotations de sortie/drapeaux.
P50/P95/P99 TTFB/TTL/latitude par région.
Disponibilité par cohorte (pays/fournisseur/appareil).
MTTR/MTBF, tendances « minutes d'inactivité » et « burn-down » budget de disponibilité par mois.
Les principales causes des échecs (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) Processus d'incident (scénario rapide)

1. Multi-région/multi-type alert est déclenché.
2. Le préposé confirme, inclut le gel des sorties, avertit les propriétaires.
3. Diagnostic rapide : statut DNS/TLS/CDN, dernières versions, graphique des erreurs.
4. Contournement : changement d'itinéraire, contenu folback/fournisseur, activation du mode de dégradation.
5. Récupération : vérifiez que le trafic synthétique/réel est vert.
6. Communication sur la page de statut ; clôture de l'incident.
7. RCA et items d'action : corrections, tests, alertes, playbooks.

11) Rapports sur les SLA/SLO

Rapports mensuels : aptyme par service/région, minutes d'inactivité, MTR, raisons.
Comparaison avec SLA : crédits/compensations, le cas échéant.
Revues trimestrielles : actualisation des seuils, distribution des synthétiques, liste des dépendances.

12) Modèles de vérification (exemple)

• Méthode : 'GET/healthz/public' (pas de secrets).
• Timaut : 2 s, retry : 1.
• Succès : '2xx', le titre 'X-App-Version' est présent, le champ JSON 'status' : 'ok'.

• Délai> 14 jours, chaîne de validation, protocoles 'TLS 1. 2 + ', SNI correct.

• Temps de réponse ≤ 100 ms, les entrées A/AAAA sont conformes au plan, pas SERVFAIL/REFUSED.

• Webhook '/beat/{ service} 'une fois toutes les 5 minutes ; l'absence de 2 signaux consécutifs est alert L2 (tâches de fond/ETL).

13) Chèque de mise en œuvre

• Vérifications externes multi-régionales (HTTP/TCP/DNS/TLS/scripts profonds).
• Échantillons blancs de lecture/liveness pour orchestrateur.
• Séparation des voies critiques/non critiques, drapeau ficha de dégradation.
• Quorum et débonds en alertes, escalade et auto-fermeture.
• Pages de statut public et interne, modèles de messages.
• Contrôles séparés et SLO pour les fournisseurs externes + failover automatique.
• Dashboards : carte, temporelle, percentiles, minutes d'inactivité, MTTR/MTBF.
• Rapports réguliers sur les SLA/SLO et les RCA post-incidents.

14) Erreurs fréquentes

Seul le ping/port sans NTTR/contenu est « vert » en cas d'indisponibilité réelle.
Un point de contrôle est la conclusion faussement positive/négative.
L'absence de contrôle TLS/DNS est une interruption soudaine due au retard/misconfigh.
Bruit superflu : alertes par échecs isolés d'une même région/type de vérification.
Aucun lien avec les modifications - il n'y a pas d'annotations des versions et des drapeaux dans les dashboards.
Les dépendances non comptabilisées - le fournisseur de paiement a chuté et le statut général « vert ».

15) Résultat

Le suivi de l'aptame n'est pas seulement « piquer l'URL ». C'est un système de contrôles synthétiques des régions réelles, des alertes raisonnables sans bruit, une communication transparente à travers les pages de statut, la prise en compte des dépendances extérieures et un rapport strict. Une surveillance d'aptame correctement construite réduit le MTTR, protège le SLA et préserve la prévisibilité de l'expérience utilisateur.