Окна обслуживания

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 окно превращается из «страшного времени простоев» в рутинный механизм улучшений без сюрпризов для пользователей и партнеров.