Как создать страницу статуса, которой клиенты действительно доверяют

Страницы статуса есть у большинства. Доверяют немногим из них. Страница, которая всегда зелёная во время сбоев, хуже, чем её отсутствие, поскольку приучает клиентов перестать на неё смотреть. У страницы статуса, которой доверяют, четыре свойства: она честно показывает, что сломано, она быстро признаёт инциденты, она аккуратно ограничивает охват воздействия и отвечает на вопрос «затрагивает ли это меня?», не заставляя читателя искать. Это руководство о том, как такую страницу спроектировать.

Что клиенты на самом деле хотят увидеть на странице статуса

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

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

Четыре свойства страницы, заслуживающей доверия

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

• Честность. Если что-то сломано, это отображается как сломанное. Если вы пока не знаете, страница сообщает: расследуется. Зелёный статус во время реального инцидента уничтожает доверие навсегда.
• Скорость. Инциденты публикуются в течение минут после обнаружения. Обновление статуса, отстающее от реальных сбоев на час, воспринимается как маркетинговый текст.
• Ясность охвата. Клиент за секунды может понять, затрагивает ли инцидент то, чем он пользуется. Регион, область продукта и серьёзность — три измерения, которые стоит маркировать.
• Простой язык. Обновления написаны тем же языком, которым вы объяснили бы инцидент другу, а не в страдательном залоге корпоративной прозы.

Обновления об инцидентах, которые работают

Большинство шаблонов страниц статуса по умолчанию используют пассивный, осторожный тон. «Мы расследуем сообщения о повышенной задержке». Это читается как уход от ответственности. Подход, формирующий доверие, обратный: назовите, что сломано, назовите воздействие на пользователя, назовите, что вы с этим делаете.

Хорошее первое обновление выглядит так: «Вход в систему не работает примерно у 30% клиентов в регионах ЕС. Идёт переключение базы данных, ожидаемое время — 10 минут». Хорошее обновление о решении выглядит так: «Вход в систему восстановлен. Корневая причина — застрявший скрипт переключения. Мы добавили сторожевой механизм, чтобы это больше не могло молча зависнуть». Оба коротки. Оба называют воздействие, действие и последующие шаги.

Правильное определение охвата воздействия

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

• Разделите страницу по компонентам: API, дашборд, приём данных, биллинг и так далее. Показывайте статус по каждому компоненту, а не один общий индикатор.
• Добавьте измерение региона или окружения там, где это применимо. Во время инцидентов явно отмечайте затронутый регион.
• Показывайте инциденты за последние 90 дней под текущим статусом. Именно по исторической сводке посетители решают, достаточно ли вы надёжны, чтобы на вас полагаться.
• Если у вас есть такая возможность, предоставляйте RSS- или JSON-канал, чтобы заинтересованные клиенты могли подписаться через свои собственные инструменты.

Запланированное обслуживание без молчания

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

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

Надёжность самой страницы статуса

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