Что такое страница статуса и что на ней должно быть

Что должно быть на странице статуса

У страницы статуса три слоя, и большая часть пользы - в первых двух.

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

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

Нижний слой - история: аптайм за последние 30 или 90 дней по каждому компоненту. Это наименее срочная часть и та, которую чаще всего читают люди, оценивающие вас как поставщика.

Публичная или приватная

Публичная страница статуса открыта любому, у кого есть ссылка, и это правильный выбор, когда ваши клиенты - широкая публика или когда вы публикуете SLA. Она также принимает на себя трафик во время сбоя от людей, которые вообще не являются вашими клиентами.

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

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

Как писать инцидент

Запись об инциденте пишется для клиента, а не для инженеров, которые его чинят. Это значит: сначала симптом, причина - позже, если вообще нужна.

1. Откройте инцидент, как только подтвердили проблему, даже если еще не знаете причину. "Мы изучаем сообщения об ошибках при оформлении заказа", опубликованное на второй минуте, стоит больше, чем полное объяснение на девяностой.
2. Скажите, что увидит клиент и что он может с этим сделать, включая обходной путь, если он есть.
3. Обновляйте с заранее заявленной периодичностью и публикуйте обновление, даже когда оно означает "пока без изменений". Молчание читается как отказ от ответственности.
4. Закройте инцидент со временем решения и, для всего длительного или серьезного, короткой заметкой о том, что произошло после.

Сверяйте состояние компонента с инцидентом. Открытый инцидент на компоненте, все еще показывающем зеленый цвет, - самый быстрый способ потерять доверие к странице. Если в основе сбоя лежит сервер, отклоняющий запросы, 503 Service Unavailable - это ответ, который ваши клиенты, скорее всего, будут вам цитировать.

Плановое обслуживание

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

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

Почему это снижает нагрузку на поддержку

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

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

Откуда берется статус

Страница статуса хороша ровно настолько, насколько хорош стоящий за ней мониторинг. Если человеку нужно заметить сбой, прежде чем страница изменится, страница всегда будет отставать от читающих ее клиентов, поэтому состояния компонентов должны приводиться в движение проверками, непрерывно работающими снаружи вашей сети. HostTracker размещает страницы статуса, питаемые собственным мониторингом, который проверяет из 300+ точек в 158 городах по 13 типам мониторов, так что состояние компонента следует за результатами проверок, а не за тем, вспомнил ли кто-то его обновить. О том, как выглядят эти проверки, смотрите руководство по HTTP-проверке, а соседние термины - в остальном разделе о понятиях мониторинга.