Вікна обслуговування

1) Що таке «вікно обслуговування» і навіщо воно потрібно

Вікно обслуговування - заздалегідь узгоджений проміжок часу для робіт, які потенційно впливають на доступність/продуктивність. Мета - контрольовані зміни з передбачуваним ризиком, прозорою комунікацією та доказовою звітністю.

• Planned (планові): релізи, міграції, ротації сертифікатів/ключів, апгрейди БД/брокерів.
• Emergency (аварійні): термінові фікси безпеки/інцидентні відкати.
• Silent/Zero-impact: без користувацького впливу (приховані канарки, репліки, паралельне введення).
• Provider-led: вікна зовнішніх провайдерів (PSP/KYC/CDN/Cloud).

2) Принципи

SLO-first: рішення про час/формат вікна приймається за впливом на SLI і бюджети помилок.
Мінімальний вибуховий радіус: канарка → ступінчасто → повне включення.
Оборотність: у кожної операції є backout-план і перевірений відкат.
Єдине джерело істини: календар вікон + тікет/RFC з повним пакетом даних.
Доказовість: збір evidence (логи, графіки, скріншоти, хеші артефактів).
Комунікації по SLA: заздалегідь, в ході робіт, по завершенні.

3) Планування: вибір часу та охоплення

Вибір вікна: низький трафік, мінімальний імпакт для ключових когорт (регіони/VIP/партнери).
Часові пояси: фіксуйте в UTC + місцевий час (наприклад, Europe/Kyiv).
Блеклаут-періоди: заборона на роботи в пікові сезони/події (матчі, розпродажі, релізні «вікна смерті»).
Blast radius: чітко визначити, кого торкнеться (сервіси, регіони, провайдери).

4) Процес узгодження (RFC/CAB lite)

1. Ініціатор створює тікет/RFC з аналізом ризику і планом (див. шаблон нижче).
2. Оцінка ризиків (Low/Med/High) та затвердження власником сервісу + SRE/безпека.
3. Календар: бронювання слота; перевірка конфліктів (інші вікна/провайдери).
4. Комм-план: заздалегідь узгоджені повідомлення і статус-сторінка.
5. Go/No-Go-зустріч (за 24-48 год) для High-risk змін.

5) Підготовка: гейти безпеки

Перевірки до старту: успішні тести на стейджі, артефакти підписані, сумарні ризики ≤ допустимих.
Канарка: 1%→5%→25% по когорті/регіону; автоматичні SLO-гардрейли і авто-відкат.
Фіча-прапори деградації і ліміти готові.
Rollback/backout-план перевірений в пісочниці; команди відкату задокументовані.
Suppression алертів: тільки для очікуваного шуму, SLO-сигнали не глушим.
Доступи: JIT/JEA обліки для операцій, мандатний аудит.

6) Комунікації (таймінг і зміст)

T-14/7/2 днів (планові): heads-up для клієнтів/внутрішніх команд (що/коли/вплив/контакти).
T-60/30/15 хвилин: нагадування всередині і на статус-сторінці.
Під час робіт: апдейти кожні 15-30 хвилин (SEV-залежно) за шаблоном: Імпакт → Етап → Наступне оновлення.
Після: фінальне «Completed/Partially completed/Rolled back», список змін, перевірка SLO.

7) Проведення робіт (референс-сценарій)

1. Freeze незв'язаних релізів.
2. Перехід в canary (обмежена когорта) → спостерігаємо SLI/метрики p95/p99.
3. Покрокове збільшення частки при зелених гардрейлах.
4. Перевірка бізнес-SLI (конверсія, успіх платежів/реєстрацій).
5. Верифікація функціоналу чек-листом (happy path + критичні сценарії).
6. Release/No-release рішення (IC/SRE/власник сервісу).
7. Зняття suppression, повернення алерт-політик.

8) Після вікна: верифікація та звітність

Observation window (наприклад, 1-24 год): стеження за SLO і помилками.
Звіт по вікну: що робили, метрики, відхилення, evidence, підсумок.
Якщо були проблеми: AAR→RCA→CAPA (фікс правил, тестів, документації).
Архів: тікет, артефакти, підписи, контрольні суми.

9) Координація із зовнішніми провайдерами

Підтверджені слоти і контакти провайдера; вікно в їх статус-системі.
Фолбек/маршрутизація на альтернативного провайдера на період робіт.
Єдиний war-room з провайдером (чат/бридж) і SLA апдейтів.

10) Метрики зрілості процесу

On-time rate: % вікон, розпочатих/завершених вчасно.
Change failure rate: % вікон з відкатами/впливом на SLO.
Incident-during-MW: інциденти, що трапилися під час вікна.
Communication SLA: частка своєчасних апдейтів.
Evidence completeness: % вікон з повним пакетом доказів.
Customer impact: скарги/тікети на 1 вікно, тренд.
Через 7/30 днів: стабільність SLO і відсутність рецидивів.

11) Чек-листи

Перед вікном

• RFC/тікет заповнений; ризик-оцінка виконана; власник призначений.
• Канарка і backout-план перевірені; команди відкату протестовані.
• Доступи JIT видані; алерти налаштовані (SLO не глушаться).
• Календар/статус-сторінка і повідомлення підготовлені.
• Релізи/конкуруючі вікна - заморожені/зрушені.
• Провайдери підтверджені; контакти і SLA записані.

Під час

• Апдейти за графіком; war-room активний.
• Гардрейли по SLO/піку помилок дотримуються; при порушенні - авто-відкат.
• Evidence збирається (скріншоти, графіки до/після, лог дій).

Після

• SLO в зеленій зоні протягом observation window.
• Фінальний звіт з evidence; статус-сторінка оновлена.
• CAPA оформлені (якщо були відхилення); документація оновлена.

12) Шаблони

Шаблон RFC на вікно обслуговування

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

Шаблон клієнтського повідомлення (коротко)

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

Правила suppression (ідея)

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) Особливості для регульованих доменів

Аудит-лог незмінний: хто схвалив, хто виконував, які команди, хеші артефактів.
PII/фінанси: маскування в evidence, обмежений доступ до звітів.
Терміни повідомлень клієнтам і партнерам - відповідно до контрактів.
Провайдерські вікна - задокументовані із зовнішніми SLA і контактами.

14) Анти-патерни

Вікно без backout-плану і перевіреного відкату.
Глушіння SLO-сигналів «про всяк випадок».
Конкуруючі вікна в одному домені/регіоні.
Комм-тиша: немає апдейтів «до/під час/після».
Ручні правки в проді без аудиту і скриптів.
«Нескінченні» вікна через невизначені критерії успіху.
Відсутність evidence - нічим підтверджувати якість.

15) Дорожня карта впровадження (4-6 тижнів)

1. Нед. 1: ввести єдиний календар і RFC-шаблон; визначити блеклаут-періоди.
2. Нед. 2: стандартизувати гейти (канарка, SLO-гардрейли, backout).
3. Нед. 3: автоматизувати suppression/анотації релізів і статус-сторінку.
4. Нед. 4: звітність і метрики зрілості; щотижневий MW-review.
5. Нед. 5–6: інтеграція з провайдерами та аудит-архівом; симуляція High-risk вікна.

16) Підсумок

Правильно організовані вікна обслуговування - це керовані, оборотні і доведено безпечні зміни. З SLO-гардрейлами, канарськими розкатами, строгими комунікаціями і повним набором evidence вікно перетворюється з «страшного часу простоїв» в рутинний механізм поліпшень без сюрпризів для користувачів і партнерів.