Что показывать на статус-странице: компоненты, метрики и история инцидентов

Статус-страницу легко завести и так же легко сделать бесполезной. Самая частая причина бесполезности — неправильное содержание: либо на странице слишком мало информации, чтобы клиент получил ответ, либо слишком много, чтобы в ней разобраться. И то и другое приводит к одному результату — клиент закрывает страницу и идёт писать в поддержку.

Правильный набор содержимого статус-страницы — это баланс между полнотой и понятностью. В этой статье разберём, что именно стоит показывать: как выбирать и группировать компоненты, какие метрики действительно помогают, как вести историю инцидентов и плановых работ, и где проходит граница между информативностью и информационным шумом.

Компоненты: основа статус-страницы

Компоненты — это логические части сервиса, состояние которых отслеживается отдельно. Именно они отвечают на главный вопрос клиента: «Что конкретно не работает?»

Как выбирать компоненты

Главный принцип — компоненты должны отражать то, как клиент воспринимает ваш сервис, а не то, как он устроен внутри. Клиенту не важно, что у вас 40 микросервисов и три кластера Kubernetes. Ему важно, работают ли вещи, которыми он пользуется.

Хорошие компоненты для типичного SaaS:

• Веб-приложение (личный кабинет)
• API
• Мобильные приложения (iOS, Android)
• Платежи и биллинг
• Авторизация и вход
• Email и уведомления
• Загрузка и обработка файлов

Плохие компоненты — это внутренняя кухня: «Kafka-кластер #2», «Redis-реплика», «Сервис нормализации данных». Эти названия ничего не говорят клиенту и только пугают.

Группировка компонентов

Когда компонентов много, их стоит группировать. Например, по продуктам, по регионам или по функциональным областям. Группировка позволяет свернуть детали и показать клиенту сначала общую картину, а потом — детали по запросу.

Пример группировки по регионам:

• Регион EU → API, Веб-приложение, Платежи
• Регион US → API, Веб-приложение, Платежи
• Регион Asia → API, Веб-приложение, Платежи

Так клиент из Европы сразу видит состояние своего региона, не путаясь в чужих.

Статусы компонентов

Стандартный набор статусов:

• Работает (Operational) — всё в норме.
• Деградация производительности (Degraded Performance) — работает, но медленно или с ошибками у части пользователей.
• Частичный сбой (Partial Outage) — часть функциональности недоступна.
• Крупный сбой (Major Outage) — компонент полностью недоступен.
• Технические работы (Under Maintenance) — плановое обслуживание.

Важно использовать промежуточные статусы, а не только «работает/не работает». Реальность чаще всего находится между этими полюсами, и честное «деградация» точнее, чем ложное «всё хорошо» или паническое «всё упало».

Инциденты и их хронология

Что показывать в активном инциденте

Активный инцидент должен отвечать на четыре вопроса клиента:

1. Что сломалось? — какие компоненты затронуты.
2. Когда это началось? — временная метка.
3. Что вы делаете? — текущий статус работ.
4. Когда ждать обновления? — следующая контрольная точка.

Жизненный цикл инцидента

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

• Investigating (расследуем) — проблема замечена, ищем причину.
• Identified (причина найдена) — поняли, в чём дело.
• Monitoring (наблюдаем) — исправление применено, проверяем стабильность.
• Resolved (решено) — инцидент закрыт.

Эта хронология ценна не только в моменте, но и постфактум: она показывает, как быстро вы реагируете и насколько структурно работаете с проблемами.

История инцидентов

Архив прошлых инцидентов — важная часть страницы. Он показывает:

• Что сбои случаются, но решаются (это нормально и честно).
• Как часто они происходят (паттерн надёжности).
• Насколько подробно и профессионально вы коммуницируете.

Не стоит удалять историю или прятать прошлые инциденты — это выглядит как попытка что-то скрыть. Честный архив работает на доверие сильнее, чем стерильная пустая страница.

Плановые технические работы

Отдельный тип записей — анонсы планового обслуживания. Они превращают потенциальный «внезапный сбой» в ожидаемое событие.

Хороший анонс плановых работ содержит:

• Когда — дата и время начала и окончания, с указанием часового пояса.
• Что затронуто — какие компоненты будут недоступны или деградируют.
• Какое влияние — полная недоступность или частичная деградация.
• Зачем — кратко, почему работы нужны (опционально, но повышает доверие).

Анонсировать значимые работы стоит заранее — за несколько дней, чтобы клиенты успели подготовиться. Подписчики при этом получают уведомление автоматически.

Метрики доступности

Uptime по компонентам

Процент времени, когда компонент работал штатно, обычно показывается за период (30, 90 дней или год) в виде полосы или числа. Это даёт клиенту количественную картину надёжности.

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

Метрики производительности

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

Плюс: разработчик-клиент видит реальную картину производительности.
Минус: графики метрик могут пугать или вводить в заблуждение тех, кто не умеет их читать, и раскрывать больше, чем нужно.

Рекомендация: показывайте метрики производительности, если ваша аудитория преимущественно техническая (например, API-сервис), и держите их простыми. Для массовой аудитории достаточно статусов компонентов и uptime.

Чего не стоит показывать

• Сырые внутренние метрики инфраструктуры (нагрузка на CPU серверов, состояние очередей).
• Детальные графики, которые раскрывают архитектуру.
• Метрики, которые вы не понимаете сами и не можете объяснить клиенту.

Где граница между информативностью и шумом

Главная ловушка — желание показать всё. Чем больше элементов на странице, тем сложнее клиенту найти ответ на простой вопрос «работает или нет».

Признаки информационного шума:

• Десятки компонентов с техническими названиями.
• Графики, которые требуют экспертизы для интерпретации.
• Избыточная детализация в описаниях инцидентов.

Тест на полезность простой: представьте встревоженного клиента, у которого что-то не работает. Открыв страницу, найдёт ли он ответ за 10 секунд? Если да — баланс выдержан. Если он тонет в деталях — нужно упрощать.

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

Лучшие практики

• Называйте компоненты на языке клиента. «Платежи», а не «Биллинг-сервис v2».
• Используйте промежуточные статусы. Честная «деградация» точнее, чем бинарное «работает/упало».
• Группируйте компоненты при их большом числе. По регионам, продуктам или функциям.
• Ведите честную историю. Не удаляйте прошлые инциденты.
• Анонсируйте плановые работы заранее. За несколько дней для значимых окон.
• Показывайте uptime. Это количественный аргумент в пользу вашей надёжности.
• Регулярно ревизуйте состав компонентов. Сервис меняется — страница должна за ним поспевать.

Частые ошибки

• Технические названия компонентов. «Redis-кластер» вместо «Кэш» сбивает клиента с толку.
• Слишком много компонентов. Список из 50 элементов прячет важное за неважным.
• Только бинарные статусы. Отсутствие «деградации» вынуждает выбирать между ложным «всё хорошо» и паническим «всё упало».
• Удаление истории. Пустой архив выглядит подозрительно, как будто инциденты скрывают.
• Метрики без контекста. График latency без объяснения скорее пугает, чем информирует.
• Заброшенные плановые работы. Анонс работ, которые давно прошли, висит и путает.
• Нет указания часового пояса. Время инцидента или работ без таймзоны бесполезно для глобальной аудитории.

Часто задаваемые вопросы

Сколько компонентов оптимально показывать?
Столько, сколько нужно, чтобы клиент понял, что именно затронуто, но не больше. Для большинства сервисов это 5–15 компонентов. Если их больше, группируйте.

Нужно ли показывать метрики производительности?
Для технической аудитории (API-сервисы, инфраструктура) — да, в простом виде. Для массовой аудитории достаточно статусов компонентов и uptime.

Стоит ли удалять старые инциденты?
Нет. Честная история инцидентов работает на доверие. Удаление выглядит как сокрытие проблем.

Как показывать uptime?
Обычно в виде процента за период (30/90 дней, год) и/или цветной полосы по дням. Полоса нагляднее всего демонстрирует историю надёжности.

Какие статусы компонентов использовать?
Минимум: работает, деградация, частичный сбой, крупный сбой, технические работы. Промежуточные статусы важны — реальность редко бывает чёрно-белой.

За сколько анонсировать плановые работы?
Значимые работы — за несколько дней, чтобы клиенты успели подготовиться. Мелкие — хотя бы за несколько часов. Подписчики получат уведомление автоматически.

Можно ли показывать разное содержимое разным клиентам?
Да, через группировку (например, по регионам) или приватные страницы с детализацией под конкретного корпоративного клиента.

Заключение

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

Главный принцип при выборе содержания — думать о встревоженном клиенте, который хочет за десять секунд понять, что происходит. Всё, что помогает ему получить этот ответ, оставляйте. Всё, что заставляет его тонуть в технических деталях, убирайте. Регулярно пересматривайте состав страницы вслед за изменениями сервиса — и она останется тем, чем должна быть: быстрым и честным ответом на вопрос «что сейчас происходит».