Status Page Management

Я регулярно вижу в командах путаницу между двумя разными артефактами: внутренним дашбордом (Grafana или Datadog с метриками сервиса для команды) и публичной страницей статуса (тем, что клиент видит на status.<company>.com). Первый — для дежурного: RED-метрики, объёмы логов, цвета по порогам, нюансы каждого компонента. Вторая — для клиента, и роль у неё совсем другая: дать обещание, что о сбое вы скажете честно, зафиксировать, когда он был, и потом рассказать, что произошло. Команды, которые эти артефакты путают, либо пишут клиентам на инженерном жаргоне («503 spike on api-gw, p99 latency degraded»), либо выкладывают наружу внутренний дашборд и пугают всех подряд. Это уточнение Customer Communications под L1 Incident Management, и граница с родительским листом чёткая: тот про что говорить во время инцидента, этот — про эксплуатацию самой площадки: подписки, политика открытости по аптайму, анонс плановых работ, независимая инфраструктура, связка с мониторингом.

Что должен уметь

Главный навык на уровне L5 — спроектировать состав компонентов. Единственная строка «всё работает / всё лежит» — самая частая ошибка: один компонент врёт, страница светит зелёным, а клиенты пишут в поддержку «у вас зелёное, но ничего не работает». Полсотни строк — другая крайность: клиент не понимает, какие из них вообще про его сценарий. Состав компонентов выводится из того, что клиент умеет назвать, а не из внутренних сервисов, и из матрицы severity: внутренний уровень должен однозначно ложиться на публичный статус — operational / degraded performance / partial outage / major outage.

Знает, где у команды страница статуса и как её видит клиент; отличает её от внутреннего дашборда мониторинга.
Умеет обновлять страницу с дежурства: объявить инцидент, опубликовать обновление по шаблону, закрыть его.
Понимает разницу между статусом компонента (operational / degraded / outage) и статусом инцидента (investigating / identified / monitoring / resolved); знает жизненный цикл из пяти стадий в Atlassian Statuspage и Better Stack.

Связывает мониторинг (Datadog, Grafana, Prometheus) со страницей: критический алерт заводит инцидент в состоянии investigating, а человек может вмешаться и переопределить.
Управляет подписками: почта, SMS, RSS, webhook, уведомления в Slack. Понимает разницу между подпиской на отдельный компонент и на всё сразу и что она означает для клиента.
Анонсирует плановые работы заранее: за неделю для крупных изменений, за сутки для мелких — с конкретным окном и ожидаемым влиянием.

Проектирует состав компонентов: то, чем клиент пользуется, а не внутренние сервисы; соответствие уровня инцидента статусу компонента; баланс детальности, где слишком мало превращается в обман, а слишком много в шум.
Определяет политику подсчёта аптайма: что считается простоем, какое берётся окно (скользящие 30, 60 или 90 дней), кто вправе пересчитать задним числом. По моим наблюдениям, это самое политически чувствительное решение во всей практике.
Держит страницу на инфраструктуре, не связанной с продуктом: другое облако, другой провайдер, статика в CDN. Страница обязана жить ровно тогда, когда прод лежит.
Сводит внутренний ход инцидента с публичным статусом: страница обновляется раньше Twitter и рассылки, а обещанный ритм обновлений записан для каждого уровня.

L6+

Проектирует стратегию на уровне организации: одна страница на весь портфель продуктов или по одной на продукт, локализация для международных клиентов, политика открытости — публичные разборы после крупных инцидентов в духе GitHub, Cloudflare и Stripe или скупые обновления в духе AWS.
Решает стратегические вопросы: брать готовый сервис (Atlassian, Better Stack) или собирать своё (Cachet, Gatus плюс свой интерфейс), и как через страницу выполняются требования регулятора — в финансах и здравоохранении она становится обязательным артефактом.

Материалы

Книги и публикации

Atlassian Incident Management Handbook. Atlassian публикует свой playbook целиком, вместе с дисциплиной ведения страницы статуса. Не академично, зато самое практичное из публичного.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), глава 17 (Crisis Management) — открытость наружу как часть реакции на кризис.

Статьи и публичные case studies

Atlassian — Incident communication best practices и их шаблоны сообщений. Про жизненный цикл (investigating / identified / monitoring / resolved), тон и частоту обновлений. Написано создателями Statuspage, так что местами это ещё и продуктовый маркетинг — но структура сообщений оттуда рабочая.
GitHub — Bringing more transparency to GitHub’s status page + публичный githubstatus.com и история инцидентов. Один из эталонных примеров в индустрии и редкий случай, когда компания публично объясняет, почему поменяла модель компонентов.
Cloudflare Status + Cloudflare incident reports. Образец того, как открытость становится частью бренда: подробные разборы с хронологией и техническими деталями сами по себе работают на доверие.
Stripe Status. Образец правильной детализации: API, дашборд, webhooks и прочее вынесены отдельно, и клиент видит ровно те компоненты, которые влияют на его интеграцию.
Discord Status и разборы крупных отказов в их блоге. Один из современных примеров открытости после крупных отказов: подробный технический разбор постом в блоге и ссылка на него со страницы статуса. Отдельной рубрики под постмортемы у них нет, разборы выходят как обычные посты.

Антипаттерны и industry critique

Критика AWS Health Dashboard — серия публичных инцидентов (отказы US-EAST-1 в 2017, 2020, 2021 и 2023 годах), когда AWS обновлял публичный статус через десятки минут после того, как клиенты уже писали о простое. Отраслевой отрицательный пример: страница статуса как маркетинговый инструмент вместо источника правды. Полезно ровно тем, как делать не надо. Разборы каждого из этих случаев легко находятся в блогах ThousandEyes и в обсуждениях на Hacker News по дате инцидента.

Инструменты

Atlassian Statuspage — доминирующий корпоративный сервис: управление подписками (почта, SMS, Slack, webhook, RSS), плановые работы, жизненный цикл инцидента, свои домены, API для автообновления из мониторинга. По моим наблюдениям, чаще всего его берут в B2B SaaS с базой до тысячи клиентов.
Better Stack Status (бывший Better Uptime) — более свежая альтернатива, к тому же связанная с их же мониторингом доступности; на младших тарифах дешевле Atlassian. Часто берут стартапы.
Instatus — упор на интерфейс, есть виджеты для встраивания, настраивается быстро.
Statuspal — хостится в Европе, что снимает часть вопросов с GDPR; релевантно для европейских компаний.
Status.io — давний игрок с развитой системой подписок.
StatusGator — агрегатор чужих статусов: показывает состояние ваших поставщиков (AWS, Stripe, GitHub, Twilio) на одном экране. Полезен там, где поставщиков много.
incident.io Status — страница статуса внутри incident.io, обновляется прямо из хода инцидента, без отдельной интеграции. Логичный выбор для тех, кто уже там.
FireHydrant — status page встроен в платформу, отдельно не продаётся; логика та же, что у incident.io.
OSS / self-hosted:
- Cachet — на Laravel, самая старая открытая реализация. Возрастная, но живая; встречается там, где уже есть PHP или где всё должно быть своим.
- Gatus — на Go, современный и открытый: конфигурация в YAML, встроенные синтетические проверки. По моим наблюдениям, его чаще берут те, кто готов хостить сам.
- Uptime Kuma — самая популярная открытая страница статуса сейчас (под 90 тысяч звёзд на GitHub, с большим отрывом от остальных): своё размещение, современный интерфейс, много каналов уведомлений.
Минимальный рабочий вариант — для личных проектов и ранних стадий, где отдельная страница статуса избыточна: RSS блога, канал в Telegram (jtprogru_channel — как использую сам), отдельная категория под инциденты в Discourse или GitHub Discussions. Не промышленный уровень, но до сотен клиентов работает.

Best practices

Конкретный антипаттерн — AWS Health Dashboard на серии отказов US-EAST-1. Несколько раз за последнее десятилетие клиенты узнавали о простое первыми — из Reddit, из Twitter, из собственных проверок, — пока публичная страница AWS ещё полчаса-час светила зелёным. Отраслевое восприятие сложилось соответствующее: статус у AWS — маркетинг, настоящий сигнал — Twitter. Это типичный перекос приоритетов. Между «маркетинг не хочет красного на странице» и «инженерам нужен честный сигнал» побеждает маркетинг, а платит доверие. Обратный пример — GitHub, Cloudflare и Stripe: они обновляют статус за десять-пятнадцать минут после обнаружения и ставят investigating до того, как поймут причину. Доверие к их страницам высокое ровно потому, что зелёное там действительно зелёное.

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

Порядок публикации задаётся один раз. В моменте он не обсуждается: сначала страница статуса, потом письмо подписчикам, потом соцсети, потом адресная работа customer success. Твит «у нас что-то сломалось» при зелёной странице статуса рассогласует картину и разрушает доверие сильнее, чем сам инцидент. Это та же мысль, что в Customer Communications сформулирована как «Statuspage — first source of truth для клиентов».

Компоненты собираются от того, что клиент умеет назвать. Он не знает ваш api-gw или user-svc и знать не обязан. Он знает «API», «Dashboard», «Webhooks», «Billing» — вот из этого и складывается список. А соответствие между внутренними сервисами и публичными компонентами остаётся отдельной декларацией, которую в любой момент можно переопределить руками, не трогая ни архитектуру, ни то, что видит клиент.

Отдельная инфраструктура — не пожелание, а требование. Я регулярно вижу команды, которые ставят Cachet в тот же кластер Kubernetes, где живёт основное приложение: дешевле, удобно, катится тем же GitOps. В первый же крупный отказ — упал API кластера, легла сеть, отвалилась зона — страница уходит в темноту вместе с приложением. Клиенту неоткуда узнать, что происходит. Если хостите сами, минимум — другой провайдер или статика в CDN как запасной вариант: CloudFront или Cloudflare Pages с заранее собранным HTML, который обновляется внешним webhook. По моим наблюдениям, команде с серьёзными обязательствами по доступности дешевле взять готовый сервис — Atlassian и Better Stack эту задачу уже решили.

Честная политика подсчёта аптайма — самое политически чувствительное решение. Что считать простоем? Только полный отказ или ещё и частичный, когда лежит десятая часть ручек? Какое брать окно — скользящие 30, 60, 90 дней или год? Засчитывать ли в простой плановые работы (большинство не засчитывает, но это компромисс, а не истина)? Кто имеет право пересчитать, если обновление статуса пропустили? Я регулярно вижу две крайности. Одни считают честно и показывают 99,5% — нормальная цифра, клиенты её уважают. Другие занимаются творческой бухгалтерией, лишь бы не опускать 99,9%, и когда это всплывает наружу, доверие падает ниже, чем было до всякой страницы. Хорошая политика публична — отдельная страница «как мы считаем аптайм» — и применяется автоматически, а не «решает маркетинг раз в квартал».

Крупные плановые работы анонсируются за неделю. Миграция базы, ломающее изменение API, переезд региона — минимум семь дней, с конкретным окном и ожидаемым влиянием. Мелочь вроде перезапуска по кругу или правки конфигурации, которую клиент не заметит, — за сутки. Набор один и тот же: анонс, письмо, запись на странице. Команды, которые «делают работы без анонса, они же короткие», теряют клиентов, у которых в это окно попал критичный процесс. Особенно в B2B SaaS, где интеграция на стороне клиента построена на предположениях о вашей доступности.

Соответствие уровня и публичного статуса задаётся формально, а не «по ощущениям». Внутренний SEV1 — с war room и сводками раз в полчаса — это degraded performance или partial outage? Ответ лежит в матрице severity. Не в голове у IC в моменте. По моим наблюдениям, без явной таблицы инциденты одного и того же внутреннего уровня получают разный публичный статус, клиенты путаются и перестают считать страницу сигналом. Таблица соответствий плюс автообновление из мониторинга и дают ту самую предсказуемость.

Подписка должна доставлять, а не ждать, пока к ней придут. Клиент не будет открывать страницу статуса каждые пятнадцать минут. И правильно сделает. Письмо всем, SMS на критичное, RSS и webhook техническим клиентам, Slack через приложение Atlassian Statuspage. По моим наблюдениям, там, где подписчиков много, во время инцидента заметно меньше обращений в поддержку: клиент уже знает, что вы знаете.

Связанные листья

Customer Communications — родительский лист: что говорим во время инцидента, кому и как часто. Страница статуса — главная его поверхность, но этот лист шире: подписки, политика аптайма, плановые работы.
Severity Classification — соответствие внутреннего уровня публичному статусу задаётся формально, а не «по ощущениям»; там же ритм обновлений для каждого уровня.
Incident Response — за обновление страницы в моменте отвечает IC; это пункт его чеклиста.
War Room Patterns — в war room страницу ведёт Comms Lead, а ритм её обновлений совпадает с ритмом внутренних сводок.
Blameless Postmortem — публичный разбор после крупного инцидента — отдельная практика открытости в духе GitHub, Cloudflare и Stripe; со страницей статуса он связан финальным обновлением, в котором стоит ссылка.
SLI-based Alerting — данные мониторинга обновляют страницу автоматически; нарушение SLO может само заводить инцидент.
Service Ownership — у каждого компонента на странице есть владелец: команда или инженер, отвечающий за уточнение его состояния.
Compliance Frameworks — в регулируемых отраслях, от финансов до здравоохранения, страница статуса становится обязательным артефактом с прописанными требованиями к раскрытию.
ChatOps — /statuspage create-incident <компонент> <уровень> как команда ChatOps; современные платформы (incident.io, FireHydrant) обновляют страницу прямо из чата.

Открытые вопросы

Практика публичных разборов (TBD) — детальные публикации разборов после крупных инцидентов (в духе разбора GitHub за октябрь 2018-го, отказа Cloudflare из-за регулярного выражения в 2019-м, постмортемов Discord). Сейчас тема цепляется к странице статуса только финальным обновлением со ссылкой. Возможно, из неё вырастет отдельный лист — сосед к Blameless Postmortem (внутренняя дисциплина) и к этому листу (внешняя поверхность).

Локализация страницы статуса — многоязычный UI, локализованные подписки по email, часовой пояс в обещаниях по частоте обновлений; для international SaaS это заметный вопрос, а поддержка со стороны инструментов неровная — у Atlassian Statuspage возможностей меньше, у Better Stack больше. Своего опыта здесь у меня нет.

Отдельный вопрос — один общий statuspage на весь портфель продуктов или по странице на продукт. Atlassian держит общий статус Jira / Confluence / Bitbucket, Stripe — отдельные страницы для Stripe / Atlas / Issuing, и компромисс тут между удобством подписки и шумом для клиента, который пользуется одним продуктом из десяти.

Обновления, написанные моделью — направление свежее, incident.io и FireHydrant уже экспериментируют: модель готовит черновик, IC утверждает. Помогает держать ритм в затяжном инциденте, но риск неверной подачи никуда не девается, поэтому каждое обновление проходит через человека.

Я не уверен в оптимальном раскрытии SLA по доступности: публиковать конкретное число (99.9%, 99.95%) или не брать публичных обязательств вовсе. Продажи обычно хотят число в контракте, инженеры боятся юридических последствий. Публичный SLA с явной компенсацией — стандарт для B2B SaaS, но границы ответственности в публичных рекомендациях размыты.