Сообщение о сбое сервиса: шаблоны для пользователей

Из чего состоит полезное уведомление

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

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

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

Первое сообщение о сбое

С 10:20 МСК часть сотрудников не может открыть корпоративный портал: страница возвращает ошибку. Поддержка проверяет масштаб и работает над восстановлением. Если заявка срочная, используйте согласованный резервный канал поддержки. Следующее обновление опубликуем до 10:50 МСК, даже если проверка ещё продолжается.

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

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

Обновление, когда новых данных мало

Обновление на 10:50 МСК. Ошибка входа на портал сохраняется. Подтверждено влияние на офисы А и Б; обработка ранее созданных заявок продолжается. Команда проверяет восстановление доступа. Подтверждённого срока завершения пока нет. Следующее сообщение — до 11:20 МСК.

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

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

Сообщение о восстановлении

Доступ к порталу восстановлен в 11:05 МСК. Проверены вход и создание заявки из затронутых офисов. Если ошибка остаётся, сообщите время попытки и текст ошибки в поддержку. Команда продолжает наблюдение; разбор причин ведётся отдельно.

Пишите «восстановлено» после проверки пользовательского сценария, а не только после зелёного индикатора сервера. Если восстановлена часть функций, перечислите оставшиеся ограничения. Отдельно скажите, нужно ли повторять неудачную операцию и как избежать дублей.

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

Как избежать противоречий между каналами

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

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

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

Источники и границы рекомендаций

Материал подготовлен 23 сентября 2026 года. Приведённые шаблоны и примеры предлагаются для адаптации под вашу службу поддержки; это не обязательные требования стандарта.

• Google SRE: Managing Incidents — роли, журнал и передача ответственности