Рекомендации по информированию об инцидентах

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

• Что это: заранее подготовленный набор каналов (страница статуса, электронная почта, чат, SMS, социальные сети), аудиторий, шаблонов сообщений и периодичности обновлений, которым команда пользуется с момента объявления инцидента.

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

• Как помогает Jira Service Management: управляйте инцидентами и связанными с ними коммуникациями в одном месте, синхронизируйте обновления со Slack и Microsoft Teams, публикуйте объявления на портале и подключайтесь к Statuspage для информирования клиентов.

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

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

Далее приведены наши рекомендации по информированию об инцидентах. Из них вы узнаете:

• в чем заключается важность сообщений об инцидентах;

• как подготовиться к информированию об инцидентах;

• как действуют профессионалы в сфере информирования об инцидентах;

• почему процесс информирования не завершается вместе с инцидентом.

Почему важны сообщения об инцидентах

Ваши клиенты неравнодушны. Ваши коллеги неравнодушны. И вы должны быть неравнодушны. Неправильно управляемый простой может стать крайне неприятным опытом для ваших клиентов и команд, что может повлиять на вашу прибыль. Вы потеряете будущих клиентов из-за отсутствия доверия. Моральный дух Team может пострадать, что приведет к снижению производительности.

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

Подготовка к информированию об инцидентах

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

Ваше понимание инцидента

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

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

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

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

Заблаговременно выберите решения и каналы для информирования, а также шаблоны сообщений

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

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

• Специальная страница статусов

• Встроенный статус

• Эл. почта

• Рабочий чат

• Социальные сети

• SMS

Специальная страница статусов

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

Встроенный статус

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

Эл. почта

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

Чат

Избавьте сотрудников и агентов от необходимости переключаться между приложениями и устраните нехватку информации с помощью чата Jira Service Management. Чат Jira Service Management позволяет синхронизировать обсуждения в Slack или Microsoft Teams с заявками. Эффективное взаимодействие между популярными инструментами чата и службой поддержки помогает четко понять контекст проблемы и ускорить ее решение.

Социальные сети

Многие команды для информирования об инциденте используют социальные сети, такие как Twitter. Этот канал рекомендуется включить в стратегию информирования, но не стоит полагаться на него как на единственное средство связи.

SMS

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

Ни один из перечисленных каналов сам по себе не является идеальным решением для информирования об инцидентах. У каждого есть свои преимущества, поэтому гораздо лучше сочетать несколько способов информирования. Компания Atlassian, например, сообщает об инциденте на странице статусов и публикует оперативную информацию в Twitter. Кроме того, объявление об инциденте появляется на портале Jira Service Management. В этих сообщениях содержатся ссылки, по которым можно перейти на страницу статусов и подробнее узнать об инциденте. При управлении инцидентами с помощью Jira Service Management можно использовать несколько каналов связи, не опасаясь, что возникнет путаница и вы потеряете доверие клиентов.

Настраивайте оповещения и сообщения с учетом аудитории

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

Хотя все организации разные, в целом полезно разделить аудиторию на пять групп, с которыми необходимо наладить общение.

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

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

3. Менеджеры и исполнительное руководство должны получить от основной команды информацию о ситуации, потенциальном влиянии на следующие две группы и (желательно) расчетном времени устранения инцидента.

4. Остальные сотрудники должны быть в курсе отключения и восстановления работы сервисов, которыми они пользуются. Упреждающее информирование этих пользователей позволит сократить количество вопросов типа «а что с…» и количество дублирующихся заявок в службу ИТ-поддержки, чтобы уделить больше внимания решению возникшей проблемы.

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

Подготовка шаблонов сообщений об инцидентах и отказах

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

Заранее согласуйте объявление с менеджерами и сохраните его в шаблон. Так вы легко дополните его необходимой информацией и сможете выпустить в тот же день, когда произойдет инцидент.

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

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

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

Управление коммуникацией во время инцидента

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

Пролог. Централизованное обсуждение во внутренней команде

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

Централизованная обработка и фильтрация оповещений во всех инструментах мониторинга, ведения журналов и CI/CD позволяют команде быстро реагировать на инциденты. С такой платформой, как Jira Service Management, команды могут быстро штурмовать инцидент, получать контекстную информацию и оставаться на связи до устранения инцидента.

Часть 1. Первое сообщение

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

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

Часть 2. Регулярные обновления во время инцидента

Крайне важно сообщать информацию в ходе инцидента.

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

Автор книги Google Site Reliability Engineering о роли ведущего специалиста по взаимодействию с клиентами пишет следующее.

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

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

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

Выберите один инструмент в качестве основного средства общения и направляйте туда всех пользователей из других каналов. При управлении сообщениями об инцидентах с помощью Jira Service Management нужные сообщения гарантированно будут доставлены нужным людям.

Часть 3. Разрешение, отчет о разборе инцидента, дальнейшие действия

В 2010 году в работе Facebook произошел сбой продолжительностью 2,5 часа, который затронул полмиллиарда пользователей, как на тот момент составляла аудитория сервиса. Когда все закончилось, инженер Facebook опубликовал в инженерном блоге компании описание инцидента объемом 395 слов.

Приведем выдержку из этой публикации.

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

Костяк отчета о разборе инцидента состоит из следующих простых частей.

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

• Объясните, что пошло не так и почему.

• Объясните, что было сделано для разрешения инцидента и предотвращения повторных инцидентов.

• Признайте наличие проблемы, проявите сочувствие и принесите извинения еще раз.

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

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

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

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