Rapports uptime et audit SLA

1) Pourquoi avez-vous besoin d'un processus formel uptime-reporting

La confiance des clients et la transparence contractuelle sont une méthode de mesure unique, des calculs répétables.
Gestion des erreurs de SLO et de budget - un lien de disponibilité avec les versions et les incidents.
Les crédits SLA corrects sont des formules objectives, des paiements/crédits prévisibles.
Durabilité juridique - base de données probantes, audit indépendant, Legal Hold.

2) Termes et limites

SLI Availability - Proportion de vérifications/transactions réussies par période.
SLO est une cible interne (p. ex. 99. 95 % en 28 jours).
SLA est une obligation extérieure (p. ex. 99. 9 %/mois + services-crédits).
La fenêtre de mesure est le mois civil (SLA) et les fenêtres rolling (SLO).
Scope - Quels sont les composants inclus dans le calcul (edge, API, paiements) et lesquels ne sont pas (admin portal, non-prod).

3) Sources de vérité (et quand quelle est la principale)

1. Synthétique (blackbox/headless) est le SLI primaire pour « l'accessibilité par les yeux de l'utilisateur ».
2. Logs/métriques - confirment l'ampleur et la nature de la défaillance.
3. Événements commerciaux - « succès de la transaction » (par exemple, paiement autorisé).
4. Page de statut - communication publique ; vérifie les faits no 1-3.

En cas de divergences : priorité aux synthétiques avec un quorum correct de ≥2 régions.

4) Méthode de calcul de la disponibilité

4. 1 Formule de base

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 Quorum multirégional

L'incident est compté si les ≥N des régions indépendantes/ASN enregistrent simultanément une défaillance.
Recommandé : N = 2 sur 3 (EU/NA/APAC).

4. 3 Types de SLI

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Activité SLI : transactions réussies/toutes les tentatives (à l'exception des abandons clients).

4. 4 Exceptions (documentées)

Fenêtres de maintenance planifiées annoncées à l'avance N heures et respectées.
Force majeure de la SLA (par exemple, fournisseur de secours IX) - seulement si vous avez des preuves et un avis public.
Erreurs/contraintes du client (quota exceeded, 4xx).

5) Politique de maintenance des fenêtres

Créneaux horaires négociés dans le contrat (par exemple, 02 : 00-04 : 00 UTC + 0).
Les marqueurs 'maintenance = true' dans les alertes/panneaux → une exception à SLI.
Seuil de préavis : 5 jours ouvrables au moins (ou comme dans le contrat).
En dehors de la fenêtre, l'influence SLA est considérée.

6) Conditions d'utilisation et règles d'arrondi

Brownout (détérioration partielle) : compter la proportion de défaillances (weighted downtime) plutôt que « 0/1 ».
Flapping : unité de compte minimale - intervalle d'échantillonnage (par exemple, 30-60 secondes) + hysteresis (pour : 2-5 min).
Clock drift : tout le temps à UTC et ISO-8601 ; synchronisation NTP.

7) Exemples BouQL (synthétique → aptame)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) Exemples SQL (agrégations de rapports)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) Modèle de rapport mensuel (Customer-friendly)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) Crédits SLA : calcul et application

Tableau des crédits : par exemple, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0 % → 10 %, etc.
Vrai-up : le crédit est appliqué en tant que note de credit au compte suivant.
Automatisation : règle "si 'measured _ availability <SLA' →' credit _ note. create()`».
Vitrine pour le client : carte de portail « SLA credits balance ».

11) Audit, preuves et Legal Hold

Audit-trail : qui/quoi/quand a calculé, version de la méthode, montants de contrôle.
Les données raw sont immuables (append-only) ; ajustements - par des enregistrements distincts.
Legal Hold : gel de la gamme de données (échantillons, logs, cartes d'incident, alertes).
Réplique des archives : stockage indépendant (WORM/S3 Object Lock).

12) Rapprochement avec la page de statut public

L'incident sur la page de statut doit avoir un délai et des composants.
Une incohérence temps/échelle de → est créée par discrepancy-record et exécutée par RCA.
Le résultat du rapport contient la section « Notes de reconnaissance ».

13) Incidents et rapports

Chaque fenêtre du centre-ville correspond à une carte INC (ID, SEV, propriétaire, RCA, CAPA).
Dans le rapport : lien vers l'INC, court root cause, statut de l'ACPA.
Pour les SEV-1 : l'après-midi ≤ 48h de la fermeture.

14) Contrôle de la qualité des données

Hygiène des échantillons :> 99 % des agents scraps réussis, pas de passes> 5 minutes.
Anti-bruit : quorum + multi-window, debounce.
Le samplage des pistes/logs est enregistré et documenté.
Tests de méthodologie : tests unitaires de calcul, fichiers golden sur les données historiques.

15) Sécurité et vie privée

TLS/mTLS pour ingest, signature de paquet (HMAC).
Édition PII dans les logs/rapports ; Le rapport SLA ne doit pas divulguer de données personnelles.
RBAC/ABAC pour les rapports ; les traces d'accès sont écrites dans le journal d'audit.

16) Dashboards et widgets SLO (que montrer)

Overall disponibilité par service par mois/trimestre.
Downtime Windows avec severity et une chaîne de détails.
Error budget burn (fast/slow) et tendances.
Releases overlay est une annotation de mise en page.
SLA credits forecast - à la tendance actuelle.

17) Plan de mise en oeuvre (3 itérations)

1. Modèle et données (2 semaines) : fixer le SLI/SLO/SLA, inclure le quorum synthétique, collecter les « matières premières » dans le DWH.
2. Calcul et rapport (2-3 semaines) : formules, SQL/BouQL, modèles YAML/PDF, portail client, auto-crédits.
3. Audit et automatisation (3-4 semaines) : Legal Hold, reconciliation avec page de statut, webhooks signés, règles de dispute.

18) Chèque qualité du rapport

• Défini par scope, SLI, technique et fenêtre de mesure.
• Il y a quorum et multi-window ; flapping est supprimé.
• Les exceptions (maintenance/force majeure) sont documentées.
• Chaque fenêtre downtime est associée à l'INC et à la RCA.
• Les crédits SLA sont comptabilisés et comptabilisés dans la facturation.
• Le rapport est reproduit (versions formules/données).
• Audit-trail et Legal Hold inclus.
• La page de statut public est harmonisée.

19) Mini-FAQ

Pourquoi la synthétique est-elle la principale source ?
Il est le plus proche du chemin utilisateur et inclut un périmètre (DNS/CDN/WAF). Métriques/logs - précisent la cause.

Comment compter les dégradations partielles ?
Downtime pondéré : la proportion d'échecs × la durée de la fenêtre, pas « tout ou rien ».

Dois-je garder les contrôles « bruts » ?
Oui, oui. Pour l'audit et le rééchelonnement en cas de litige - raw est nécessaire.

Total

Les rapports uptime et l'audit SLA ne sont pas un « chiffre de fin de mois », mais un système reproductible de mesures, de règles et de preuves : SLI correct, contrôles quorum, formules transparentes, combinaison d'incidents et de facturation, contrôle des exceptions et Legal Hold. Fixez la méthode, automatisez le calcul et les crédits, gardez l'audit-trail - et vos SLA deviendront gérables, compréhensibles et sécurisés.