Fenêtres de maintenance

1) Qu'est-ce qu'une « fenêtre de service » et pourquoi il est nécessaire

La fenêtre de service est un laps de temps convenu à l'avance pour les travaux qui peuvent affecter la disponibilité/performance. L'objectif est un changement contrôlé avec un risque prévisible, une communication transparente et des rapports factuels.

• Planned (planned) : versions, migrations, rotations de certificats/clés, mises à niveau OBD/courtiers.
• Emergency (urgence) : fiches de sécurité urgentes/retours d'incident.
• Silent/Zero-impact : pas d'influence personnalisée (canaris cachés, répliques, entrée parallèle).
• Provider-led : fenêtres de fournisseurs externes (PSP/KYC/CDN/Cloud).

2) Principes

SLO-first : la décision sur l'heure/le format de la fenêtre est prise en fonction de l'impact sur le SLI et les budgets d'erreurs.
Rayon d'explosion minimum : Canaris → marche → allumage complet.
Réversibilité : chaque opération a un plan backout et un retour en arrière éprouvé.
Source unique de vérité : calendrier des fenêtres + tiquet/RFC avec un paquet de données complet.
Preuve : collecte d'evidence (logs, graphiques, captures d'écran, hachages d'artefacts).
Communications sur les SLA : à l'avance, au cours des travaux, à la fin.

3) Planification : Choix du temps et de la portée

Choix de la fenêtre : faible trafic, impact minimal pour les cohortes clés (régions/VIP/partenaires).
Fuseaux horaires : fixez l'heure UTC + locale (par exemple, Europe/Kyiv).
Périodes de blacklout : interdiction de travailler pendant les saisons de pointe/événements (matchs, soldes, fenêtres de libération de la mort).
Blast radius : définir clairement qui sera affecté (services, régions, fournisseurs).

4) Processus d'harmonisation (RFC/BOU lite)

1. L'initiateur crée un tiquet/RFC avec une analyse de risque et un plan (voir le modèle ci-dessous).
2. Évaluation des risques (Low/Med/High) et approbation par le propriétaire du service + SRE/sécurité.
3. Calendrier : réservation de slot ; vérification des conflits (autres fenêtres/fournisseurs).
4. Plan d'action : Avis et page de statut négociés à l'avance.
5. Rendez-vous Go/No-Go (24-48 h) pour les changements de risque élevé.

5) Préparation : Gates de sécurité

Contrôles avant le départ : tests réussis sur le steadge, artefacts signés, risques totaux ≤ acceptables.
Canaris : 1%→5%→25 % par cohorte/région ; Garde automatique SLO et retour automatique.
Les drapeaux de dégradation et les limites sont prêts.
Rollback/plan backout vérifié dans le bac à sable ; les commandes de retour sont documentées.
Alertes de suppression : seulement pour le bruit attendu, les signaux SLO ne sont pas silencieux.
Accès : Comptes JIT/JEA pour les opérations, vérification du mandat.

6) Communications (timing et contenu)

T-14/7/2 jours (prévus) : heads-up pour les clients/équipes internes (quoi/quand/impact/contacts).
T-60/30/15 minutes : rappels à l'intérieur et sur la page de statut.
Pendant les travaux : Apdates toutes les 15 à 30 minutes (SEV-dépendant) par modèle : Impact → Étape → Prochaine mise à jour.
Après : « Completed/Partially completed/Rolled back » final, liste des changements, vérification SLO.

7) Exécution des travaux (scénario de référence)

1. Freeze de sorties non liées.
2. La transition dans le canary (cohorte restreinte) est → observée par l'ISS/métriques p95/p99.
3. Augmentation étape par étape de la part dans les gardes verts.
4. Validation du SLI d'entreprise (conversion, succès des paiements/inscriptions).
5. Vérification de la fonctionnalité par checklist (happy path + scripts critiques).
6. Release/No-release decision (IC/SRE/propriétaire du service).
7. Suppression de la suppression, retour de la stratégie alert.

8) Après la fenêtre : vérification et rapports

Fenêtre d'observation (par exemple, 1-24 h) : suivi des SLO et des erreurs.
Rapport par fenêtre : ce qu'on faisait, métriques, écarts, évidence, total.
S'il y avait des problèmes : AAR→RCA→CAPA (fix des règles, des tests, de la documentation).
Archives : tiquette, artefacts, signatures, montants de contrôle.

9) Coordination avec les fournisseurs externes

Slots confirmés et contacts du fournisseur ; une fenêtre sur leur système de statut.
Folback/routage vers un fournisseur alternatif pendant la durée des travaux.
Une seule salle de guerre avec un fournisseur (chat/bridge) et des updates SLA.

10) Métriques de maturité du processus

Taux en temps réel :% des fenêtres commencées/terminées à temps.
Change failure rate :% des fenêtres avec un retour/impact sur SLO.
Incident-during-MW : incidents survenus pendant la fenêtre.
Communication SLA : proportion d'apdates opportunes.
Evidence completeness :% des fenêtres avec un paquet complet de preuves.
Impact client : plaintes/tickets sur 1 fenêtre, tendance.
Après 7/30 jours : stabilité du SLO et pas de rechutes.

11) Chèques-feuilles

Devant la fenêtre

• RFC/tiquet rempli ; évaluation des risques effectuée ; le propriétaire est désigné.
• Plan canarien et backout vérifié ; les commandes de retour ont été testées.
• Accès JIT émis ; les alertes sont personnalisées (les SLO ne se brouillent pas).
• Calendrier/état de la page et notifications préparés.
• Sorties/fenêtres concurrentes - gelées/décalées.
• Les fournisseurs sont confirmés ; contacts et SLA enregistrés.

Pendant

• Apdates selon le calendrier ; war-room est actif.
• Les gardes selon SLO/pic d'erreur sont respectés ; En cas de violation, auto-retour.
• Evidence est recueilli (captures d'écran, graphiques avant/après, journal des actions).

Après

• SLO dans la zone verte pendant la fenêtre d'observation.
• Rapport final avec evidence ; la page d'état a été mise à jour.
• Les ACPA sont formalisées (s'il y a eu des écarts) ; documentation mise à jour.

12) Modèles

Modèle RFC par fenêtre de service

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

Modèle de notification client (brièvement)

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

Règles de suppression (idée)

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13) Caractéristiques pour les domaines réglementés

L'audit-journal est immuable : qui a approuvé, qui a exécuté, quelles commandes, les hachages d'artefacts.
PII/finance : masquage dans l'evidence, accès limité aux rapports.
Délais de notification aux clients et partenaires - conformément aux contrats.
Fenêtres du fournisseur - documentées avec des SLA et des contacts externes.

14) Anti-modèles

Fenêtre sans plan backout et retour vérifié.
Brouillage des signaux SLO « juste au cas où ».
Fenêtres concurrentes dans le même domaine/région.
Comm- silence : pas d'updates « avant/pendant/après ».
Modifications manuelles dans la vente sans audit ni scripts.
Fenêtres « infinies » en raison de critères de succès incertains.
L'absence d'evidence n'a rien à confirmer sur la qualité.

15) Feuille de route pour la mise en œuvre (4-6 semaines)

1. Ned. 1 : entrez un calendrier unique et un modèle RFC ; déterminer les périodes de blacklout.
2. Ned. 2 : standardiser les gates (canari, SLO-gardrails, backout).
3. Ned. 3 : automatiser les suppressions/annotations de version et la page de statut.
4. Ned. 4 : rapports et mesures de maturité ; MW-review hebdomadaire.
5. Ned. 5-6 : intégration avec les fournisseurs et audit-archives ; simulation de fenêtre à risque élevé.

16) Résultat

Les fenêtres de service correctement organisées sont gérables, réversibles et sûres. Avec les jardins SLO, les canaries, les communications rigoureuses et l'ensemble complet d'evidence, la fenêtre passe d'un « temps d'arrêt effrayant » à un mécanisme d'amélioration de routine sans surprises pour les utilisateurs et les partenaires.