Finestre di manutenzione

1) Cos'è la finestra di servizio e perché è necessario

Finestra di manutenzione - Intervallo di tempo preconfigurato per le operazioni che possono influire sulla disponibilità e sulle prestazioni. L'obiettivo è un cambiamento controllato, con rischi prevedibili, comunicazioni trasparenti e rapporti probatori.

• Planned: rilasci, migrazioni, rotazioni di certificati/chiavi, upgrade di database/broker.
• Emergency (Emergency): registri di sicurezza/incidenti di emergenza.
• Silent/Zero-impatto - Nessuna influenza personalizzata (canarie nascoste, repliche, input parallelo).
• Provider-led: finestre dei provider esterni (PSP/KYC/CDN/Cloud).

2) Principi

SLO-first - La decisione sull'ora/formato della finestra viene presa in base all'impatto su SLI e budget degli errori.
Raggio di esplosione minimo, il canarino è ato.
Reversibilità: ogni operazione ha un piano backout e un check-out collaudato.
Un'unica fonte di verità è il calendario delle finestre + ticket/RFC con un pacchetto completo di dati.
Prova: raccolta di evidence (fogli, grafici, screenshot, hash artefatti).
Comunicazioni SLA: in anticipo, durante i lavori, al termine.

3) Pianificazione: scelta del tempo e della copertura

Selezione della finestra: traffico basso, impatto minimo per le griffe chiave (regioni/VIP/partner).
Fuso orario: fissa in UTC + ora locale (ad esempio Europa/Kyiv).
I periodi Blacklout sono il divieto di lavorare durante le stagioni di picco/evento (partite, vendite, finestre della morte).
Blast radius - Identificare chiaramente chi verrà colpito (servizi, regioni, provider).

4) Processo di negoziazione (RFC/CAV lite)

1. L'iniziatore crea un ticket/RFC con analisi del rischio e piano (vedere il modello seguente).
2. Valutazione dei rischi (Low/Med/High) e approvazione da parte del proprietario del servizio + SRE/sicurezza.
3. Calendario: prenotazione slot; convalida dei conflitti (altre finestre/provider).
4. Piano comm - Notifiche concordate e stato pagina.
5. Riunione Go/No-Go (24-48 ore) per modifiche High-risk.

5) Preparazione: gate di sicurezza

Test prima del lancio: test di sterzo completi, manufatti firmati, rischi totali ≤.
Canario: 1%→5%→25% per coorte/regione; SLO-gardrail automatici e auto-ritorno.
Flag Fiech degrado e limiti pronti.
Il piano Rollback/backout è stato verificato nella cassetta di sabbia; i comandi di ripristino sono documentati.
Supplence alert: solo per il rumore previsto, i segnali SLO non sono silenziosi.
Disponibili: JIT/JEA account per operazioni, controllo del mandato.

6) Comunicazioni (timing e contenuti)

T-14/7/2 giorni (pianificati): heads-up per i clienti/comandi interni (che/quando/impatto/contatti).
T-60/30/15 minuti - avvisi all'interno e alla pagina di stato.
Durante i lavori: update ogni 15-30 minuti (SEV-Dipendente) in base al modello: Impatto Fase Aggiornamento successivo.
Dopo: Completed/Partially completed/Rolled back finale, elenco delle modifiche, controllo SLO.

7) Esecuzione dei lavori (script di riferimento)

1. Rilasci freeze non collegati.
2. Passiamo al canary (coorte limitato) osservando SLI/metriche p95/p99.
3. Aumento passo per passo della quota di gardrel verde.
4. Verifica SLI aziendale (conversione, successo dei pagamenti/iscrizioni).
5. Convalida delle funzioni con un foglio di lavoro (happy path + script critici).
6. Release/No-release soluzione (IC/SRE/proprietario del servizio).
7. Rimozione della supplenza, restituzione dei criteri alert.

8) Dopo la finestra, verifica e reporting

Osservation window (ad esempio 1-24 ore) - Monitoraggio di SLO e errori.
Rapporto della finestra: cosa facevano, metriche, deviazioni, evidence, totale.
Se c'è stato un problema: AAR→RCA→CAPA (fisso di regole, test, documentazione).
Ticket, manufatti, firme, numeri di controllo.

9) Coordinamento con provider esterni

Slot e contatti del provider confermati; finestra dello stato del sistema.
Folback/instradamento su un provider alternativo per il periodo di lavoro.
Un'unica war room con provider (chat/bridge) e update SLA.

10) Metriche di maturità del processo

On-time rate:% finestre iniziate/completate in tempo.
Change failure rate:% delle finestre con ripetizione/impatto SLO.
Invident-during-MW - Incidenti avvenuti durante la finestra.
Comunicazione SLA - Percentuale di update tempestivi.
Evidence completeness:% finestre con pacchetto completo di prove.
Customer impact: lamentele/ticket per 1 finestra, trend.
Dopo 7/30 giorni, stabilità SLO e nessuna ricaduta.

11) Assegno fogli

Prima della finestra

• RFC/ticket è pieno; Valutazione del rischio completata; il proprietario è stato assegnato.
• Il piano canarino e backout sono stati convalidati; i comandi di ripristino sono stati testati.
• JIT disponibili gli alert sono impostati (gli SLO non sono silenziosi).
• Calendario/stato-pagina e notifiche preparate.
• Rilasci/finestre concorrenti - congelati/spostati.
• Provider confermati; contatti e SLA registrati.

Durante

• Update secondo il programma; war room è attiva.
• I gardrail SLO/picco di errori sono rispettati; in caso di violazione - Reimpostazione automatica.
• Evidence viene assemblato (screenshot, grafici prima/dopo, login delle azioni).

Dopo

• SLO nell'area verde durante l'osservation window.
• Rapporto finale con evidence; stato pagina aggiornato.
• CAPE compilati (se ci sono state delle deviazioni); documentazione aggiornata.

12) Modelli

Modello RFC per la finestra di servizio

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

Modello di notifica client (brevemente)

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

Regole di suppressione (idea)

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) Caratteristiche dei domini regolabili

Il login di controllo è invariato: chi ha approvato, chi ha eseguito, quali comandi, gli hash artefatti.
PII/finanza: occultamento in evidence, accesso limitato ai report.
I tempi di notifica per clienti e partner sono conformi ai contratti.
Finestre di provider - Documentati con SLA e contatti esterni.

14) Anti-pattern

Finestra priva di backout e ripristino collaudato.
Silenziamento dei segnali SLO «per sicurezza».
Finestre concorrenti in un unico dominio/regione.
Nessun apdate prima/durante/dopo.
Modifiche manuali in vendita senza controllo e script.
Finestre infinite a causa di criteri di successo non definiti.
Assenza di evidence - non c'è niente da confermare.

15) Road map di implementazione (4-6 settimane)

1. Ned. 1 - Immettere un unico calendario e un modello RFC determinare i periodi blacklout.
2. Ned. 2 - standardizzare i gate (canarino, SLO-gardrail, backout).
3. Ned. 3 - Automatizza l'annotazione di output e lo stato della pagina.
4. Ned. 4 - rapporti e metriche di maturità; MW-review settimanale.
5. Ned. 5-6: integrazione con i provider e l'archivio di verifica simulazione della finestra High-risk.

16) Totale

Le finestre di servizio correttamente organizzate sono modifiche gestite, reversibili e dimostrabili. Con i guardrail SLO, le release canarie, le comunicazioni rigorose e il set completo di evidence, la finestra si trasforma da «tempi di inattività» a un meccanismo di miglioramento di routine senza sorprese per utenti e partner.