Status pages

Назначение status page

Status page — публичный или ограниченный канал, где пользователи видят текущее состояние сервиса и историю инцидентов. Она снижает число повторных обращений в поддержку и задаёт единый источник информации вместо противоречивых сообщений в разных каналах.

Страница не заменяет мониторинг и управление инцидентами: она показывает согласованную коммуникацию команды, а не обязательно каждую техническую метрику.

Компоненты и состояния

Сервис разбивают на понятные пользователю компоненты: сайт, API, checkout, личный кабинет, фоновая обработка. Не следует выводить внутренние pod и VM как отдельные элементы.

Типовые состояния:

• operational;
• degraded performance;
• partial outage;
• major outage;
• maintenance.

Названия и критерии заранее согласуют с severity. Если один компонент затронут, страница не должна без необходимости показывать отказ всего продукта.

Возможности

• кастомный поддомен status.example.com и узнаваемое оформление;
• активный инцидент с влиянием и хронологией обновлений;
• подписки на email/webhook или другие каналы, в том числе по компонентам;
• запланированные maintenance windows;
• история и, при необходимости, показатели времени ответа;
• переводы для аудитории;
• публичный доступ или SSO/password/IP-ограничение для внутренней страницы.

Графики не должны раскрывать чувствительную нагрузку или вводить пользователя в заблуждение синтетической «зелёностью» во время подтверждённого сбоя.

Независимость и обновление

Status page размещают независимо от наблюдаемого production: другой провайдер, регион и по возможности DNS/инфраструктурный контур. Если страница падает вместе с сайтом, канал коммуникации исчезает в самый нужный момент.

Автоматика может открыть инцидент по подтверждённому сигналу, но текст и статус требуют владельца. Communication lead обновляет страницу регулярно, даже если первопричина ещё исследуется.

Пример сообщения:

Оформление заказа у части пользователей завершается ошибкой.
Просматривать каталог можно. Исследуем влияние и причину.
Следующее обновление — в 15:30 UTC.

После восстановления отдельно подтверждают результат и закрывают инцидент. Не обещают ETA, если оно не обосновано.

Публичная или приватная страница

Публичная подходит клиентам SaaS и внешним пользователям. Приватная нужна для внутренних систем, партнёров или данных, которые нельзя раскрывать. Доступ к ней ограничивают, но сохраняют независимость и понятные обновления.

Минимальный сценарий внедрения

1. Выбрать пользовательские компоненты и критерии состояний.
2. Настроить независимый хостинг и кастомный домен.
3. Назначить владельца обновлений и шаблоны сообщений.
4. Подключить subscriptions и проверить их доставку.
5. Провести учебный инцидент: открытие, два обновления, закрытие.
6. Проверить страницу при недоступности основного production.

Связанные инструменты

• Better Stack — status pages в связке с monitoring и incidents.
• Atlassian Statuspage — управляемые публичные и приватные страницы.
• OpenStatus — открытая платформа статуса и проверок.

Связанные материалы

• Управление инцидентами — роли Communication lead и IC.
• Uptime monitoring — источник сигнала, а не готовый текст пользователю.
• Postmortem — последующий разбор после коммуникации и восстановления.

Материалы и источники

• Better Stack: Status page — кастомный домен, подписки, компоненты и обновления.
• Atlassian Statuspage: Support — настройка страниц, компонентов и уведомлений.
• Google SRE: Managing Incidents — коммуникационная роль и регулярные обновления.