Сообщение о сбое и страница статуса

Понедельник, 9:12. Дилерский портал заказов не открывается. За девять минут в поддержку падает четырнадцать сообщений с одним и тем же вопросом. Из команды уходит три разных ответа: через пятнадцать минут заработает, у нас всё в порядке, разбираемся. Инженеры чинят за сорок минут. Но за эти сорок минут поддержка не закрывает больше ничего, двое клиентов спрашивают публично, а к вечеру двое дилеров придерживают заказы, потому что не знают, что сказать своим покупателям. Сбой длился сорок минут, ущерб — два дня.

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

1Обнаружение2Публикация3Обновления4Устранено5Отчёт

Что решает страница статуса, а что нет?

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

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

В какой момент публиковать первое сообщение?

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

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

Что пишут в сообщении о сбое?

Сообщение о сбое — это сводка состояния, а не письмо с извинениями. Оно короткое и сухое: его сканируют, а не читают. Семь блоков ниже задают одинаковый каркас и первому сообщению, и каждому следующему обновлению.

• Что не работает: формулировка глазами пользователя — не входит в систему, заказ не сохраняется, отчёт не открывается.
• Охват: кого затронуло — всех, один регион, один модуль. Пропущенный охват обходится дороже всех остальных пропусков.
• Что продолжает работать: незатронутые части. Одна эта строка удерживает от заявок тех, у кого всё в порядке.
• Обходной путь: если он есть — мобильное приложение работает, загрузку файла можно отложить.
• Текущее состояние: изучаем, причина найдена, применяем исправление, наблюдаем. Четыре слова, которые всем означают одно и то же.
• Чего делать не нужно: не отправляйте заказ повторно, не повторяйте оплату. Без этой строки после восстановления вы разбираете дубли.
• Следующее обновление: со временем. В названный час вы напишете, даже если новостей не будет.

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

Как задать ритм обновлений?

Самая дорогая опция во время аварии — молчание. Промежуток между сообщением в 10:20 и следующим в 11:45 и есть то место, где рождается вся гора заявок. Ритм задаётся обязательством, а не событиями: в каждом сообщении вы называете время следующего и это время соблюдаете.

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

Что писать, когда новостей нет?

Пустых обновлений не бывает, бывают плохо написанные. Даже без прогресса можно сказать три вещи: что вы исключили, кто и над чем работает прямо сейчас и когда будет следующее сообщение. Фраза «работы продолжаются» не говорит ни одного из них. Фраза «базу данных исключили, сейчас работаем с платёжным провайдером» несёт информацию без всякого прогресса.

Как определить уровни серьёзности?

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

Уровень	Что означает	Куда сообщаем и кто подключается
Полный сбой	Основной сервис не работает ни у кого	Страница, письмо, звонки ключевым клиентам; дежурная смена и руководитель
Частичный сбой	Не работает модуль или регион	Страница и письмо затронутым клиентам; дежурная смена
Деградация	Работает, но медленно; ошибки время от времени	Отметка о компоненте на странице; внутренний канал
Плановые работы	Заранее объявленное окно	Письмо заранее и календарь на странице; ответственный за работы
Единичный случай	Затронут один клиент	На страницу не выносится; обычная заявка в поддержку

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

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

Где должна жить страница статуса?

Это самая частая и самая тихо наказуемая ошибка: разместить страницу статуса на той же системе, о статусе которой она сообщает. Упало приложение — вместе с ним ушла и страница на тех же серверах; задет DNS вашего домена — поддомен со страницей тоже не открывается. Независимость здесь не техническая деталь, а весь смысл существования страницы.

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

Кто пишет и кто согласовывает?

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

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

Сообщать всем или только затронутым?

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

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

Настоящая цена аварии — не минуты простоя, а то, что в эти минуты ваш клиент не знает, что сказать своему клиенту.

Где заканчивается прозрачность?

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

Обратная ошибка опаснее. Компания, которая не выносит настоящие сбои ради зелёной истории, показывает клиенту, сидящему в этом самом сбое, надпись «все системы работают», и ценность страницы обнуляется в ту же секунду. Проверка простая: заметили клиенты — значит, публикуем. Страница статуса не табель успеваемости. Инциденты безопасности живут по отдельным правилам: публикуйте только подтверждённое, а если затронуты персональные данные, по обязанностям уведомления советуйтесь со своим юристом с учётом вашей конкретной ситуации.

Что происходит после устранения?

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

Тон задаёт понимание того, кто это читает. Отчёт пишется не для ваших инженеров, а для ИТ-руководителя и закупщика на той стороне: он ложится в досье поставщика и достаётся оттуда при следующем продлении. Поэтому дата и ответственный по каждой мере важнее технических подробностей, а вместо обещания, что это больше не повторится, стоит написать, что именно изменилось. Насколько клиент сможет справиться сам во время аварии, зависит от того, что описано в базе знаний и самообслуживании.

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

С чего начать

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

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