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

Страница статуса в одном месте сообщает пользователям, работает ли ваш сервис. Чтобы её создать, нужны список компонентов (сайт, API, платежи, отправка писем), текущий статус каждого, инциденты с отметками времени в обновлениях, история прошлых сбоев и, по желанию, подписки, чтобы люди узнавали о проблемах, не заходя на страницу. Сама страница проста. Главное решение — где она работает: страница статуса должна оставаться доступной, когда ваше приложение недоступно, поэтому она не должна делить хостинг, базу данных или конвейер деплоя с тем, о чём сообщает.

Для чего нужна страница статуса

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

Это не журнал изменений. Новые функции идут в журнал изменений, а сбои и плановые работы — сюда.

Что нужно странице

Данные

Статусы компонентов обычно берутся из короткого фиксированного списка: Работает, Снижена производительность, Частичный сбой, Полный сбой, Плановые работы.

Страницы

• Публичная страница статуса: общий баннер («Все системы работают» или самый серьёзный текущий статус), каждый компонент с его статусом, активный инцидент с обновлениями, ближайшие плановые работы и полоса истории за 90 дней, если есть данные проверок.
• Страница инцидента: полная хронология обновлений одного инцидента с собственным адресом, чтобы поддержка могла на него ссылаться.
• История: прошлые инциденты по месяцам.
• Подписка: регистрация по email с подтверждением и настройкой по компонентам.
• Админка: создание инцидента, публикация обновлений, смена статусов компонентов, планирование работ.

Права доступа

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

Ключевое решение: сделать её независимой

Здесь чаще всего ломаются самодельные страницы статуса. Если ваша страница статуса:

• работает на том же сервере или в том же хостинг-аккаунте, что и приложение,
• читает ту же базу данных,
• стоит за той же настройкой домена или CDN,
• или деплоится тем же конвейером,

то многие сбои уронят и её — именно тогда, когда люди больше всего в ней нуждаются. Практические шаги:

• Отдельный хостинг. Другой проект или провайдер, не тот, что у основного приложения.
• Собственный поддомен, например status.example.com, настроенный отдельно в DNS. См. как работают домены и DNS.
• Собственные данные. Инциденты хранятся в собственном хранилище страницы статуса, а не в базе приложения.
• Статичный запасной вариант. Некоторые команды делают публичную страницу статичной и пересобирают её при каждом обновлении, поэтому ломаться почти нечему.

Ручные обновления или автоматические проверки

Вручную (с этого стоит начать)

Команда публикует инциденты и меняет статусы компонентов вручную из админки. На практике так работает большинство страниц статуса: человеческая оценка («оплата медленно проходит для некоторых типов карт») полезнее автоматической красной точки.

Чтобы быстро узнавать о проблемах, используйте внешний монитор доступности, который проверяет приложение примерно раз в минуту и присылает оповещение по email, SMS или в мессенджер. У многих сервисов мониторинга есть бесплатные тарифы.

Автоматически

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

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

Автоматические изменения могут мигать (работает, не работает, работает) при медленной сети. Требуйте две-три неудачные проверки перед сменой статуса и дайте человеку подтвердить серьёзный сбой, прежде чем объявлять о нём.

Как писать обновления об инцидентах

• Публикуйте рано. «Расследуем сообщения о сбоях входа» через несколько минут лучше, чем идеальный текст через час.
• Пишите, что заметят пользователи, а не что сломалось внутри.
• Обещайте время следующего обновления и держите слово.
• Закрывайте коротким итогом после устранения: что случилось, сколько длилось, что вы меняете.

Первый промпт, который работает

Создай отдельную страницу статуса для нашего приложения Parcelio, размещённую отдельно по адресу status.parcelio.com. Компоненты: Сайт, API отслеживания, Уведомления, Платежи; у каждого статус: Работает, Снижена производительность, Частичный сбой, Полный сбой или Плановые работы. Публичная страница показывает общий баннер по самому серьёзному текущему статусу, каждый компонент с его статусом, активные инциденты с обновлениями с отметками времени (сначала новые), ближайшие плановые работы и список прошлых инцидентов по месяцам. У каждого инцидента своя страница. Добавь админку под паролем для создания инцидентов (заголовок, влияние, затронутые компоненты), публикации обновлений (текст и статус: Расследуем, Определили причину, Наблюдаем, Устранено), смены статусов компонентов и планирования работ. Добавь эндпоинт POST /api/check-result, который принимает название компонента и up/down от внешнего монитора и защищён секретным токеном; компонент переходит в статус «Снижена производительность» только после трёх подряд неудачных проверок. Храни всё в собственной базе данных приложения. Простой, спокойный дизайн, быстро загружается на телефонах.

Этапы сборки

1. Публичная страница и админка с ручными инцидентами. Этого уже достаточно для рабочей страницы статуса.
2. Разместите её отдельно и направьте на неё поддомен.
3. Страницы инцидентов и история.
4. Плановые работы.
5. Подписки. Регистрация по email с двойным подтверждением и уведомления о новых инцидентах и обновлениях. Для писем нужен провайдер; см. как отправлять письма из приложения.
6. Вебхук монитора, если нужны автоматические изменения статусов.
7. Проведите учебную тревогу. Создайте вымышленный инцидент, опубликуйте обновления, закройте его, проверьте письма, затем удалите.

Типичные ошибки

• Размещение вместе с приложением. Самая частая и самая серьёзная ошибка.
• Страница, которая всегда говорит «Все системы работают». Если она никогда не показывает проблем, пользователи перестают ей доверять.
• Нет отметок времени или часового пояса. Всегда показывайте время с указанием пояса.
• Вход в админку через вход основного приложения.
• Тишина между обновлениями. «Изменений нет, всё ещё работаем» — вполне достойное обновление.
• Мигающие автоматические статусы. Требуйте повторных сбоев перед сменой статуса.

Когда лучше готовый сервис страницы статуса

Сервисы хостируемых страниц статуса решают проблему независимости: они работают на отдельной инфраструктуре, рассылают уведомления подписчикам по email и SMS, часто включают мониторинг и интеграции с инструментами для инцидентов. Если аптайм входит в то, за что платят клиенты, или у вас есть договорные обязательства сообщать об инцидентах, выделенный сервис обычно стоит своих денег. Многие предлагают бесплатные или недорогие тарифы для небольших команд, так что проверьте, прежде чем строить своё.

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

Как это сделать в Mythex

В Mythex страницу статуса можно создать как отдельный проект, отдельный от основного приложения, — так у неё будет свой хостинг и собственная база данных. Опишите её в чате, проверьте в живом превью, затем опубликуйте и подключите поддомен вроде status.yourdomain.com (собственные домены доступны на тарифе Pro). Учтите, что опубликованные приложения Mythex и их базы данных засыпают при простое и просыпаются при следующем визите, поэтому первая загрузка после затишья может быть медленнее; простая и лёгкая страница помогает.

В Mythex не описаны запланированные задачи, поэтому для автоматических проверок используйте внешний монитор доступности, который вызывает эндпоинт вебхука на вашей странице статуса (см. рецепт с вебхуками). Email-оповещения подписчикам отправляются через ваш собственный провайдер, а ключ хранится как секрет проекта (рецепт отправки письма).

Вопросы