Okna konserwacyjne

1) Co to jest „okno konserwacji” i dlaczego jest potrzebne

Okno konserwacji - Wstępnie uzgodnione ramy czasowe dla działań, które mogą mieć wpływ na dostępność/wydajność. Celem są kontrolowane zmiany z przewidywalnym ryzykiem, przejrzystą komunikacją i sprawozdawczością opartą na dowodach.

• Planowane: wydania, migracje, certyfikaty/rotacje kluczy, aktualizacje bazy danych/brokera.
• Nagły wypadek: pilne poprawki bezpieczeństwa/wałki awaryjne.
• Silent/Zero-impact: brak wpływu użytkownika (ukryte kanary, repliki, wejście równoległe).
• Dostawca-led: okna zewnętrznych dostawców (PSP/KYC/CDN/Cloud).

2) Zasady

SLO-first: decyzja w sprawie czasu/formatu okna jest podejmowana w zależności od wpływu na SLI i budżetów błędów.
Minimalny promień wybuchu: kanaryjski → krok po kroku → pełne włączenie.
Odwracalność: Każda operacja ma plan awaryjny i sprawdzony zwrot.
Pojedyncze źródło prawdy: kalendarz okien + bilet/RFC z pełnym pakietem danych.
Dowody: zbiór dowodów (dzienniki, wykresy, zrzuty ekranu, hashes artefakt).
Komunikacja SLA: z wyprzedzeniem, podczas prac, po zakończeniu.

3) Planowanie: Czas i zasięg

Wybór okna: niski ruch, minimalny wpływ na kluczowe kohorty (regiony/VIP/partnerzy).
Strefy czasowe: rekord czasu UTC + czasu lokalnego (na przykład Europa/Kijów).
Okresy blackout: zakaz pracy w szczytowych sezonach/wydarzeniach (mecze, sprzedaż, zwolnienie „okien śmierci”).
Promień wybuchu: jasno określić, kto zostanie dotknięty (usługi, regiony, dostawcy).

4) Proces negocjacyjny (RFC/CAB lite)

1. Inicjator tworzy bilet/RFC z analizą ryzyka i planem (patrz szablon poniżej).
2. Ocena ryzyka (Low/Med/High) i zatwierdzenie przez właściciela usługi + SRE/security.

3. Kalendarz: rezerwacja gniazd; Sprawdzanie konfliktów (inne okna/dostawcy)

4. Plan Comm: wstępnie uzgodnione powiadomienia i strona statusu.
5. Go/No-Go-meeting (w 24-48 godzin) dla zmian wysokiego ryzyka.

5) Prep: Bramy bezpieczeństwa

Kontrole wstępne: udane testy etapowe, podpisane artefakty, całkowite ryzyko ≤ dopuszczalne.
Kanaryjski: 1% → 5% → 25% według kohorty/regionu; automatyczne szyny SLO i auto-rollback.
Flagi degradacji i limity są gotowe.
Plan rollback/backout sprawdzony w piaskownicy; polecenia rollback są udokumentowane.
Tłumienie wpisów: tylko dla oczekiwanego szumu, sygnały SLO nie są tłumione.
Dostęp: rachunki JIT/JEA za operacje, obowiązkowy audyt.

6) Komunikacja (czas i treść)

T-14/7/2 dni (planowane): informacje dla klientów/zespołów wewnętrznych (co/kiedy/impact/contacts).
T-60/30/15 minut: przypomnienia wewnątrz i na stronie stanu.
Podczas pracy: aktualizacje co 15-30 minut (zależne od SEV) według szablonu: Impact → Stage → Następna aktualizacja.
Po: końcowy „Zakończony/Częściowo zakończony/zwinięty z powrotem”, lista zmian, sprawdzenie SLO.

7) Wykonanie robót (scenariusz referencyjny)

1. Zamrozić niepowiązane wydania.
2. Przejście do kanaryjskiej (ograniczona kohorta) → obserwować SLI/p95/p99 metryki.
3. Stopniowy wzrost udziału w zielonych szynach ogrodniczych.
4. Weryfikacja business SLI (konwersja, sukces płatności/rejestracji).
5. Sprawdź sprawdzanie funkcjonalności listy (szczęśliwa ścieżka + krytyczne scenariusze).
6. Rozwiązanie Release/No-Release (właściciel usługi IC/SRE/service).
7. Usunięcie tłumienia, powrót polityki ostrzegawczej.

8) Po oknie: weryfikacja i raportowanie

Okno obserwacyjne (na przykład 1-24 godziny): śledzenie SLO i błędów.
Raport z okien: co zostało zrobione, metryki, odchylenia, dowody, suma.
Jeśli były problemy: AAR → RCA → CAPA (naprawić zasady, testy, dokumentacja).
Archiwum: bilet, artefakty, podpisy, czeki.

9) Koordynacja z zewnętrznymi dostawcami

Potwierdzone sloty i kontakty dostawców; okno w ich systemie statusu.
Folback/routing do alternatywnego dostawcy na okres pracy.
Pojedynczy pokój wojenny z dostawcą (czat/most) i aktualizacje SLA.

10) Metryka dojrzałości procesu

Wskaźnik czasu:% okien rozpoczętych/ukończonych na czas.
Zmiana wskaźnika awarii:% okien z rolkami/uderzeniem w SLO.
Incydent-during-MW: incydenty, które miały miejsce podczas okna.
Komunikat SLA: udział aktualizacji w odpowiednim czasie.
Kompletność dowodów:% okien z pełnym pakietem dowodów.
Wpływ klienta: reklamacje/bilety na 1 okno, trend.
Po 7/30 dniach: stabilność SLO i brak nawrotów.

11) Listy kontrolne

Przed oknem

• RFC/bilet jest pełny; zakończona ocena ryzyka; przypisany właściciel.
• Sprawdzono plan kanaryjski i wycofania; testowane polecenia rollback.
• Wydany dostęp do JIT; alerty są konfigurowane (SLO nie są zablokowane).
• Przygotowano stronę kalendarza/statusu i powiadomienia.
• Wersje/Konkurencyjne Windows - zamrożone/przesunięte.
• Dostawcy potwierdzili; kontakty i SLA są rejestrowane.

Podczas

• Aktualizacje harmonogramu; Sala wojenna jest aktywna.
• Szanowane są szyny ogrodnicze dotyczące błędów SLO/szczytowych; w przypadku naruszenia - auto-rollback.
• Zbierane są dowody (zrzuty ekranu, przed/po wykresach, dziennik akcji).

Po

• SLO w zielonym obszarze podczas okna obserwacyjnego.
• Sprawozdanie końcowe z dowodami; aktualizowana strona statusu.
• wydawane są urzędy CAPA (jeżeli wystąpiły odchylenia); dokumentacja zaktualizowana.

12) Szablony

Szablon RFC na okno konserwacji

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

Szablon powiadomienia klienta (krótki)

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

Zasady tłumienia (pomysł)

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) Cechy domen regulowanych

Dziennik audytu niezmienny: kto zatwierdził, kto wykonał, jakie polecenia, hashes artefaktów.
PII/Finance: maskowanie dowodów, ograniczony dostęp do raportów.
Warunki powiadomień do klientów i partnerów - zgodnie z umowami.
Okna dostawcy - udokumentowane zewnętrznymi SLA i kontaktami.

14) Anty-wzory

Okno bez planu kopii zapasowej i zweryfikowanego wstecznego.
Zagłuszanie sygnałów SLO „na wszelki wypadek”.
Konkurencyjne okna w tej samej domenie/regionie.
Cisza: brak przed/podczas/po aktualizacji.
Ręczne edycje produktu bez audytu i skryptów.
„Nieskończone” okna ze względu na niepewne kryteria sukcesu.
Brak dowodów - nic nie potwierdza jakości.

15) Plan działania na rzecz realizacji (4-6 tygodni)

1. Ned. 1-Enter jednym kalendarzu i szablonie RFC zdefiniować okresy zaciemnienia.
2. Ned. 2: standaryzować bramy (kanaryjskie, SLO-gardrails, backout).
3. Ned. 3: automatyczne tłumienie/uwalnianie adnotacji i strony stanu.
4. Ned. 4: wskaźniki sprawozdawczości i zapadalności; tygodniowy przegląd MW.
5. Ned. 5-6: integracja z dostawcami i archiwum audytu; Symulacja okien wysokiego ryzyka.

16) Sedno sprawy

Prawidłowo zorganizowane okna serwisowe są zarządzalne, odwracalne i sprawdzają się w sposób bezpieczny. Dzięki SLO-gardrails, kanarkom, ścisłej komunikacji i pełnemu zestawowi dowodów okno zamienia się z „strasznego przestoju” w rutynowy mechanizm ulepszeń bez niespodzianek dla użytkowników i partnerów.