Сервис лежит. Пользователи злятся. Что им говорить?

Сервис перестал открываться в 11:03. Через три минуты в поддержку пришло первое сообщение: «У меня оплата прошла, а заказ пропал. Где деньги?» Разработчики ещё ищут причину. Руководитель запрещает публиковать сообщение, пока «не будет ясности». Но пользователи уже видят сбой. Не видят они только одного: занимается ли им кто-нибудь.

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

Возьмём условный сервис для обработки заказов.

У клиента через час отправка товара. Он пытается открыть кабинет, получает ошибку, проверяет интернет. Пишет менеджеру. Тот советует зайти позже.

Когда позже? Что с заказами? Можно ли продолжать работу другим способом?

У компании пока нет технического объяснения. Но уже есть подтверждённая проблема, о которой можно сообщить. Для первого сообщения достаточно описать известные симптомы, действия команды и время следующего обновления. Такой порядок рекомендует Atlassian.[atlassian]

Молчание не делает ситуацию менее серьёзной. Оно оставляет клиента один на один с догадками.

Первое сообщение: скажите, что именно сломалось

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

Так можно написать почти про что угодно. Человек, который не может войти в кабинет, не понимает, о его ли проблеме речь.

Лучше назвать недоступную функцию. Если масштаб сбоя ещё неизвестен, это тоже стоит сказать.

Шаблон первого сообщения

Сейчас [название сервиса / функция] недоступен: [что происходит у пользователя].

Мы подтвердили сбой. Техническая команда выясняет причину и восстанавливает работу.

[Какие функции или пользователи затронуты. Если масштаб неизвестен: «Уточняем, какие ещё функции затронуты».]

Следующее сообщение опубликуем не позднее [время, часовой пояс], даже если к этому моменту причина ещё не будет установлена.

Обновления будут здесь: [ссылка].

Извините, что сейчас вы не можете [конкретное действие].

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

Не обещайте восстановить сервис за десять минут, если команда не подтвердила срок. А советы вроде «повторите оплату» или «переустановите приложение» сначала согласуйте с инженерами. Непроверенная инструкция может добавить клиенту проблем.

Назначили время — вернитесь вовремя

Допустим, вы обещали обновление в 11:30.

В 11:28 разработчики всё ещё проверяют несколько версий. Причина не найдена, срок восстановления неизвестен.

Это не повод пропустить сообщение.

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

Регулярные обновления входят в практику работы с инцидентами Google SRE.[sre]

Шаблон обновления

Статус на [время, часовой пояс].

[Функция] всё ещё недоступна. [Что работает — если проверено.]

Причина пока не установлена. Сейчас команда [подтверждённое действие: проверяет…, восстанавливает…, тестирует…].

[Проверенный способ продолжить работу, если он есть.]

Срок восстановления пока не можем подтвердить. Следующее сообщение — не позднее [время, часовой пояс].

История обновлений: [ссылка].

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

Не пишите «данные не пострадали», пока это не проверено. Если проверка продолжается, так и сообщите.

Кто отвечает за сообщение

В условной компании текст уже готов. Но руководитель просит убрать слово «сбой». Юрист уточняет формулировки. Маркетолог предлагает заменить «недоступен» на «работает нестабильно».

Проходит ещё двадцать минут.

На экране клиента всё та же ошибка.

Чтобы каждое обновление не застревало в переписке, заранее договоритесь:

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

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

Поддержке тоже нужен согласованный текст. Иначе в одном чате клиенту скажут «скоро заработает», в другом — «проблема у вас», а в публичном канале будет тишина.

Сервис заработал. Что дальше?

После проверки восстановления сообщите, какие функции снова доступны, с какого времени и остались ли ограничения.

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

Но и заканчивать всё фразой «Спасибо за понимание» не стоит. Особенно если клиенты потеряли рабочее время или у них зависли операции.

Итоговый разбор должен объяснить произошедшее, последствия, способ восстановления и дальнейшие исправления.

Шаблон итогового разбора

[Дата] с [время] до [время, часовой пояс] в [сервис] произошёл сбой.

Не работали: [функции]. Проблема затронула [подтверждённый масштаб].

Причина: [проверенное объяснение]. [Если часть вопросов ещё изучается — какие именно.]

Для восстановления мы [конкретные действия].

Последствия для пользователей: [задержки, состояние операций и данных — только проверенные сведения].

Уже исправили: [выполненные действия].

Дальше сделаем: [изменение, ответственная команда, срок].

Если у вас осталась проблема с [операция], обратитесь [куда и какие сведения предоставить].

[Условия компенсации, если она утверждена.]

Извините за [конкретное неудобство].

Фраза «такого больше не повторится» ничего не объясняет. Покажите, какие изменения вы внесли и как проверите их работу.

Разбор полезнее строить вокруг условий, которые привели к сбою, а не поиска сотрудника, на которого можно свалить ответственность. Такой подход используют в практике Google SRE.

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

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

В моем Telegram‑канале делюсь фишками и лайфхаками как не слить деньги на бесполезные публикации и сделать PR, который принесет клиентов.