Во время любой аварии происходит одно и то же. Сервис лежит, инженеры разбираются, а поддержка захлёбывается в одинаковых сообщениях: «у вас что-то не работает?», «это только у меня?», «когда почините?». Каждое требует ответа, каждый ответ отвлекает, и через двадцать минут кто-то из технической команды переключается с починки на объяснения — потому что поддержка не знает, что писать.
Публичная страница статуса решает ровно эту задачу. Она превращает десятки индивидуальных разговоров в одно сообщение, которое клиенты читают сами. Но она же может сделать хуже — если врёт, показывает зелёное во время аварии или не обновляется часами.
Разберём, как сделать её полезной.
Что она даёт на самом деле
Первый и самый очевидный эффект — снижение нагрузки на поддержку. Компании, которые заводят статус-страницу и учат клиентов ей пользоваться, отмечают заметное падение числа обращений в момент инцидента. Не потому, что клиенты перестают волноваться, а потому, что им есть куда посмотреть.
Второй эффект тоньше и важнее: страница меняет тон разговора. Клиент, который узнаёт об аварии из вашего же сообщения с указанием времени начала и статуса работ, воспринимает ситуацию как контролируемую. Клиент, который сам обнаружил проблему, написал в поддержку и получил ответ через сорок минут, воспринимает вас как компанию, которая не знает, что у неё происходит. Технически это одна и та же авария.
Третий эффект — доказательство. История инцидентов и цифры доступности за период — это то, что предъявляется при разговорах об SLA, при тендерах, при спорах о качестве услуг. Причём работает в обе стороны: аргумент «у вас постоянно всё падает» разбивается фактами, а не ощущениями.
И четвёртый, про который редко думают: страница статуса дисциплинирует внутрь. Когда инциденты приходится публично фиксировать и описывать, их перестают замалчивать. Практика «перезапустил и никому не сказал» умирает сама собой, и это оздоравливает процесс.
Чего показывать нельзя
Здесь ошибаются чаще всего. Соблазн выложить на публичную страницу как можно больше данных велик, но публичная страница — это внешний контур, и всё, что на ней есть, видят в том числе те, кому не следует.
Не показывайте внутренние имена серверов и их адреса. «Сервер db-prod-02 недоступен» — это подарок для того, кто изучает вашу инфраструктуру. Клиенту достаточно знать, что затронут сервис «Личный кабинет».
Не показывайте технические подробности сбоя. «Переполнение диска на ноде, отвалился репликационный слейв» — это внутренняя информация. Наружу — «наблюдаются задержки при загрузке отчётов».
Не показывайте метрики загрузки, версии ПО и структуру системы. Всё это либо помогает атакующему, либо вызывает вопросы у тех, кто не должен их задавать.
И отдельная тонкость: если у вас мультитенантная система, страница статуса ни в коем случае не должна раскрывать, у какого именно клиента проблема. Это не только вопрос безопасности, но и вопрос доверия — никто не хочет узнать из публичной страницы, что сервис у конкретного контрагента сегодня лежал.
Иными словами, на публичной странице живут сервисы в терминах клиента, их состояние и текст сообщения. Всё остальное — во внутренней панели.
Из чего состоит хорошая страница
Список сервисов — тот, что понятен клиенту. Не «API-шлюз» и «воркер очередей», а «Сайт», «Личный кабинет», «Мобильное приложение», «Приём заказов», «Выгрузка документов». Название должно совпадать с тем, как клиент называет то, чем пользуется. Если вы напишете «Сервис аутентификации», человек не поймёт, что это про «не могу войти».
Текущее состояние каждого сервиса. Достаточно трёх-четырёх градаций: работает, есть проблемы, недоступен, ведутся работы. Больше — только запутает.
Активные инциденты с хронологией. Ключевое здесь — не факт, а лента обновлений с временными метками. Одно сообщение «мы всё ещё чиним» через час после начала — хуже, чем три коротких обновления с интервалом в двадцать минут.
История за период. Календарь доступности за последние девяносто дней и список прошлых инцидентов. Это то, что превращает страницу из аварийного объявления в инструмент доверия.
Плановые работы — заранее. Регламентные работы, объявленные за неделю, воспринимаются совершенно иначе, чем неожиданная недоступность.
Подписка на уведомления, если есть возможность. Клиент, который сам подписался на обновления, — это клиент, который не напишет в поддержку.
Самое важное техническое требование
Страница статуса не должна жить в той же инфраструктуре, что и продукт.
Это звучит очевидно, но нарушается постоянно. Статус-страница на том же сервере, за тем же балансировщиком, на том же домене — становится недоступной ровно тогда, когда она нужна. Отдельный сервер, отдельный домен или поддомен с отдельной DNS-записью, в идеале — другой провайдер.
Проверка простая: представьте, что дата-центр с вашим продакшеном полностью недоступен. Открывается ли ваша страница статуса? Если нет — это не страница статуса, а её имитация.
Второе техническое требование — она должна быть максимально простой. Никаких тяжёлых фронтендов, зависимостей от вашего основного API, авторизации. В момент аварии страницу открывают все клиенты сразу — она обязана выдержать этот наплыв на минимальных ресурсах.
Кто пишет сообщения и как
Это организационная часть, и она важнее технической.
Первое правило: у обновления статуса должен быть ответственный, и это не тот человек, который в этот момент чинит. Инженер, который одновременно поднимает базу и пишет публичные сообщения, будет делать плохо и то, и другое. Обычно это роль дежурного или руководителя поддержки: он получает информацию от технической команды и переводит её на язык клиента.
Второе правило: первое сообщение публикуется быстро, даже если непонятно, что случилось. «Мы видим проблему с доступом к личному кабинету, разбираемся» через пять минут после начала — это лучшее, что можно сделать. Ждать полной ясности означает публиковать через час, когда клиенты уже написали всё, что думают.
Третье: заранее заготовьте шаблоны. Три-четыре формулировки на типовые ситуации — обнаружили, локализовали, чиним, восстановили. В момент аварии никто не пишет хорошие тексты с нуля.
Четвёртое: фиксируйте окончание и подводите итог. Инцидент, который просто исчез со страницы, оставляет неприятный осадок. Короткое финальное сообщение с указанием времени восстановления и, если уместно, причины — закрывает историю.
Формулировки: что работает, а что злит
Честно и без технического жаргона — базовое правило. Но есть несколько конкретных вещей, которые стоит знать.
Не используйте слова, которые преуменьшают проблему, если она серьёзная. «Незначительные задержки» при полной недоступности сервиса — быстрый способ потерять доверие. Клиент видит своими глазами, что ничего не работает, и ваша формулировка выглядит как попытка обмануть.
Не обещайте сроков, в которых не уверены. «Восстановим в течение получаса» и последующие два часа простоя наносят больше репутационного ущерба, чем сам простой. Честнее: «работаем над устранением, следующее обновление через 30 минут» — обещание, которое вы точно сдержите.
Не оправдывайтесь и не перекладывайте вину. «Проблемы на стороне провайдера» — фраза, которая не помогает клиенту вообще: он платит вам, а не провайдеру. Указать причину можно, но после того, как сказано, что вы делаете.
Хороший тон — сообщать, что делать клиенту прямо сейчас, если есть обходной путь. «Оформление заказов временно недоступно на сайте, заказы принимаются по телефону» — сообщение, за которое скажут спасибо.
Как это устроено в COSCIO
Публичная страница статуса — часть платформы. Внутри вы работаете с реальной инфраструктурой: серверы, сайты, контейнеры, интеграции, метрики и инциденты. Наружу отдаётся только то, что вы явно выбрали показывать: список сервисов вашими словами, их состояние, текущие инциденты с хронологией и история доступности.
Разделение здесь принципиальное и сделано намеренно. Публичный интерфейс не имеет доступа к данным других рабочих пространств — если администратор не указал, чьи сервисы показывать, страница не отдаёт ничего вообще, вместо того чтобы показать всё подряд. Это тот случай, когда безопасное поведение по умолчанию важнее удобства.
Инциденты, которые вы ведёте внутри, могут публиковаться наружу — так лента для клиентов ведётся не отдельно вручную, а вырастает из той же работы, которую команда и так делает во время аварии. Это снимает главную причину, по которой статус-страницы протухают: необходимость дублировать одну и ту же информацию в двух местах.
Проверка на честность
Закончу простым тестом, который стоит провести после запуска.
Дождитесь первого реального инцидента и посмотрите на три вещи. Сколько минут прошло от начала проблемы до первой публикации. Сколько обращений в поддержку пришло по сравнению с прошлым разом. И совпадает ли то, что было написано на странице, с тем, что происходило на самом деле.
Если первое число больше пятнадцати минут — процесс не отлажен, вопрос организационный, а не технический. Если второе не изменилось — клиенты не знают о существовании страницы, её нужно показать: ссылка в подвале сайта, в письмах поддержки, в личном кабинете. Если третье расходится — это самое опасное, потому что страница статуса, которой не верят, хуже, чем её отсутствие: она создаёт у вас иллюзию, что вы коммуницируете, а у клиента — уверенность, что вы скрываете.