Как сделать публичную страницу статуса для сайта или сервиса
Практика4 минРедакция Innovialabs
Коротко
Страница статуса — это размещённая отдельно страница, где видно состояние каждой части сервиса и обновления по инцидентам; во время сбоя пользователи смотрят туда, а не заваливают поддержку.
Что даёт страница статуса
Страница статуса — публичная страница, обычно по адресу status.вашдомен.uz, где видно, работает ли сейчас каждая часть продукта и что команда делает с проблемами.
Во время сбоя большинство обращений в поддержку об одном: «Это сломалось у всех? Когда починят?» Страница статуса отвечает на этот вопрос один раз и для всех. В итоге:
- Меньше одинаковых тикетов и звонков, пока инженеры чинят проблему.
- Больше доверия: пользователи видят, что вы заметили сбой раньше, чем они о нём написали.
- История инцидентов, на которую могут ссылаться продажи и поддержка.
Что показывать на странице
Страница должна быть понятна клиенту без технического бэкграунда. Показывайте компоненты, которые пользователь узнаёт, а не внутренние серверы.
| Хорошие названия компонентов | Плохие названия компонентов |
|---|---|
| Сайт, Мобильное приложение, Оплата, Вход, API, Уведомления | web-01, redis-cluster, k8s-node-pool |
Для каждого компонента хватит небольшого набора состояний: Работает, Работает медленно, Частичный сбой, Серьёзный сбой, Плановые работы.
Что полезно добавить:
- История доступности за последние 30–90 дней по каждому компоненту.
- График времени ответа сайта или API, если он стабилен и понятен.
- Плановые работы с заблаговременным анонсом.
- Подписка: email, RSS, webhook или Telegram-канал, чтобы получать обновления без перезагрузки страницы.
Не публикуйте всё, что мониторите. Внутренние метрики без контекста рождают больше вопросов, чем ответов.
Размещайте её отдельно от основной инфраструктуры
Страница статуса должна работать, когда продукт лежит. Если она на том же сервере, в том же облачном аккаунте или за тем же балансировщиком, она упадёт вместе со всем остальным.
Чек-лист:
- Другой хостинг: SaaS-сервис статуса, статический сайт у другого провайдера или хотя бы другой регион и аккаунт.
- Независимый DNS: если у основного DNS-провайдера сбой,
status.всё равно должен резолвиться. Подумайте об отдельной зоне или провайдере. - Никакой зависимости от вашей авторизации, базы данных или API.
- Статической или кешируемой страницы достаточно — ей нужно просто открываться.
Hosted или self-hosted
| Hosted (SaaS) | Self-hosted | |
|---|---|---|
| Запуск | Минуты, без серверов | Разворачиваете и поддерживаете сами |
| Независимость | Уже вне вашей инфраструктуры | Только если разместить отдельно |
| Возможности | Подписки, шаблоны, интеграции из коробки | Зависит от инструмента |
| Стоимость | Ежемесячная подписка, растёт с числом подписчиков и функций | Хостинг плюс время команды |
| Контроль | Ограничен вендором | Полный контроль над данными и дизайном |
Среди hosted-сервисов — Atlassian Statuspage, Instatus, Better Stack. Популярные open-source варианты — Uptime Kuma, Gatus, Upptime и Cachet. Небольшой команде обычно проще всего взять hosted-сервис или Upptime, который работает на GitHub Pages и GitHub Actions.
Свяжите её с мониторингом доступности
Страница, которую обновляют только вручную, часто отстаёт от реальности. Подключите мониторинг:
- Настройте внешние проверки (HTTP, TCP, ping, поиск ключевого слова) из нескольких локаций для каждого компонента.
- Меняйте статус только при подтверждении из нескольких локаций или после нескольких неудачных проверок подряд — так меньше ложных тревог.
- Пусть мониторинг автоматически меняет статус компонента или создаёт черновик инцидента, который подтверждает человек.
- Одновременно отправляйте алерт дежурной команде, чтобы страница и люди реагировали вместе.
Автоматическая смена статуса хороша для очевидных сбоев. А текст инцидента лучше писать человеку.
Как писать обновления об инцидентах
Используйте предсказуемую последовательность: Расследуем → Причина найдена → Наблюдаем → Решено.
Правила для каждого обновления:
- Описывайте, что видит пользователь, а не внутреннюю причину: «Часть платежей завершается ошибкой», а не «лаг реплики БД».
- Указывайте масштаб: какой компонент, какой регион или группа пользователей.
- Называйте время следующего обновления: «Следующее обновление через 30 минут» — и выполняйте обещание, даже если ничего не изменилось.
- Не обещайте срок исправления, если не уверены.
- После решения добавьте короткий итог: что случилось, сколько длилось, что вы измените.
Пример:
Расследуем: часть пользователей не может войти в мобильное приложение. Сайт работает в обычном режиме. Ищем причину, следующее обновление — в течение 30 минут.
Частые ошибки
- Страница статуса на том же сервере, что и продукт.
- «Все системы работают», когда пользователи уже жалуются.
- Часы тишины между обновлениями.
- Технический жаргон, который клиент не может понять.
- Удаление старых инцидентов ради красивой картинки.