Ferestre de întreținere

1) Care este „fereastra de întreținere” și de ce este necesar

Fereastră de întreținere - Interval de timp convenit anterior pentru activități care ar putea afecta disponibilitatea/performanța. Scopul este de a controla schimbările cu risc previzibil, comunicare transparentă și raportare bazată pe dovezi.

• Planificat: versiuni, migrații, rotații certificat/cheie, baze de date/broker upgrade-uri.
• Urgență: remedieri de siguranță urgente/rollback incident.
• Silent/Zero-impact: fără impact asupra utilizatorului (canare ascunse, replici, intrare paralelă).
• Furnizor-condus: ferestre ale furnizorilor externi (PSP/KYC/CDN/Cloud).

2) Principii

SLO-first: decizia privind ora/formatul ferestrei se face în funcție de impactul asupra SLI și a bugetelor de eroare.
Raza explozivă minimă: canar → pas cu pas → includere completă.
Reversibilitate: Fiecare operațiune are un plan de backout și un rollback dovedit.
Sursă unică de adevăr: calendar de ferestre + bilet/RFC cu pachet complet de date.
Dovezi: colectarea probelor (busteni, grafice, capturi de ecran, hashes artefact).
Comunicații SLA: în avans, în timpul lucrărilor, la finalizare.

3) Planificare: Calendarul și acoperirea

Selectarea ferestrelor: trafic redus, impact minim pentru cohortele cheie (regiuni/VIP/parteneri).
Fusuri orare: înregistrați în UTC + ora locală (de exemplu, Europa/Kiev).
Perioade de blackout: interzicerea muncii în timpul sezoanelor/evenimentelor de vârf (meciuri, vânzări, lansare „ferestre ale morții”).
Raza exploziei: definiți în mod clar cine va fi afectat (servicii, regiuni, furnizori).

4) Procesul de negociere (RFC/CAB lite)

1. Inițiatorul creează un bilet/RFC cu analiză de risc și plan (vezi șablonul de mai jos).
2. Evaluarea riscurilor (Low/Med/High) și aprobarea de către proprietarul serviciului + SRE/securitate.

3. Calendar: rezervare sloturi; Verificarea conflictelor (alte ferestre/furnizori)

4. Planul de comunicații: notificări pre-agreate și pagina de stare.
5. Go/No-Go-întâlnire (în 24-48 de ore) pentru modificări cu risc ridicat.

5) Prep: Porti de securitate

Verificări înainte de lansare: teste de succes, artefacte semnate, riscuri totale ≤ acceptabile.
Canar: 1%→5%→25% după cohortă/regiune; automată SLO-gardrails și auto-rollback.
Steagurile de degradare şi limitele sunt gata.
Planul Rollback/backout verificat în sandbox; comenzile rollback sunt documentate.
Suprimarea alertelor: numai pentru zgomotul așteptat, semnalele SLO nu sunt înăbușite.
Accesări: conturi JIT/JEA pentru operațiuni, audit obligatoriu.

6) Comunicații (calendarul și conținutul)

T-14/7/2 zile (planificate): heads-up pentru clienți/echipe interne (ce/când/impact/contacte).
T-60/30/15 minute: memento-uri în interiorul și pe pagina de stare.
În timpul lucrului: actualizări la fiecare 15-30 minute (SEV- dependent) în conformitate cu șablonul: Impact → Etapa → Următoarea actualizare.
După: final „Finalizat/Parțial completat/Laminat înapoi”, lista de modificări, verificare SLO.

7) Executarea lucrărilor (scenariu de referință)

1. Blocați eliberările fără legătură.
2. Tranziția la canar (cohortă restricționată) → a observa metrica SLI/p95/p99.
3. Creșterea treptată a cotei cu gardrails verzi.
4. Verificarea SLI de afaceri (conversie, succesul plăților/înregistrărilor).
5. Verificați verificarea funcționalității listei (traseu fericit + scenarii critice).
6. Soluție de eliberare/No-release (IC/SRE/service owner).
7. Eliminarea suprimării, returnarea politicilor de alertă.

8) După fereastră: verificare și raportare

Fereastra de observare (de exemplu, 1-24 ore): urmărirea SLO și erori.
Raport de fereastră: ce s-a făcut, măsurători, abateri, dovezi, total.
Dacă au existat probleme: AAR→RCA→CAPA (fixați reguli, teste, documentație).
Arhiva: bilet, artefacte, semnături, sume de control.

9) Coordonarea cu furnizorii externi

sloturi confirmate și contacte furnizor; fereastră în sistemul lor de stare.
Folback/rutare către un furnizor alternativ pentru perioada de lucru.
O singură cameră de război cu un furnizor (chat/bridge) și actualizări SLA.

10) Măsurători ale maturității procesului

Rata la timp:% din ferestrele pornite/finalizate la timp.
Modificarea ratei de defectare:% din ferestre cu rollback/impact asupra SLO.
Incident în timpul MW: incidente care au avut loc în timpul ferestrei.
Comunicarea SLA: ponderea actualizărilor în timp util.
Exhaustivitatea dovezilor:% din ferestrele cu pachet complet de dovezi.
Impactul clientului: reclamații/bilete pentru 1 fereastră, tendință.
După 7/30 zile: stabilitate SLO și fără recidive.

11) Liste de verificare

Înainte de fereastră

• RFC/bilet este plin; evaluarea riscurilor finalizată; proprietar atribuit.
• Planul canar și backout verificat; comenzi rollback testate.
• Accesele JIT emise; alertele sunt configurate (SLO-urile nu sunt blocate).
• Calendarul/pagina de stare și notificările sunt pregătite.
• Versiuni/Windows concurente - congelate/schimbate.
• Furnizorii au confirmat; contactele și SLA-urile sunt înregistrate.

În timpul

• Actualizări în grafic; Camera de război este activă.
• Gardrails pe SLO/erori de vârf sunt respectate; în caz de încălcare - auto-rollback.
• Dovezile sunt colectate (capturi de ecran, înainte/după grafice, jurnal de acțiune).

După

• SLO în zona verde în timpul ferestrei de observare.
• Raport final cu dovezi; pagina de stare actualizată.
• CAPA-urile sunt emise (dacă au existat abateri); documentația actualizată.

12) Șabloane

Şablon RFC pe fereastră de întreţinere

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

Șablon de notificare a clientului (scurt)

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

Reguli de suprimare (idee)

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) Caracteristici pentru domenii reglementate

Jurnal de audit de neschimbat: cine a aprobat, cine a executat, ce comenzi, hash-uri de artefacte.
PII/Finanțe: mascare în probe, acces limitat la rapoarte.
Termenii notificărilor către clienți și parteneri - în conformitate cu contractele.
Ferestre furnizor - documentate cu SLA-uri externe și contacte.

14) Anti-modele

Fereastră fără plan de backout și rollback verificat.
Bruierea semnalelor SLO „pentru orice eventualitate”.
Ferestre concurente în același domeniu/regiune.
Comm silence: nu înainte/în timpul/după actualizări.
Editări manuale în produs fără audit și scripturi.
Ferestre „infinite” din cauza criteriilor incerte de succes.
Lipsa de dovezi - nimic pentru a confirma calitatea.

15) Foaie de parcurs de implementare (4-6 săptămâni)

1. Ned. 1-Enter un singur calendar și șablonul RFC definesc perioadele de blackout.
2. Ned. 2: standardizarea porților (canar, gardrails SLO, backout).
3. Ned. 3: automatizarea adnotărilor de suprimare/eliberare și pagina de stare.
4. Ned. 4: indicatori de raportare și maturitate; săptămânal MW-review.
5. Ned. 5-6: integrarea cu furnizorii și arhiva de audit; Simulare de ferestre cu risc ridicat.

16) Linia de jos

Ferestrele de service organizate în mod corespunzător sunt gestionabile, reversibile și dovedesc modificări sigure. Cu SLO-gardrails, rasps canar, comunicații stricte și un set complet de dovezi, fereastra se transformă dintr-un „downtime teribil” într-un mecanism de rutină de îmbunătățiri, fără surprize pentru utilizatori și parteneri.