Коммуникация во время аварийных ситуаций: как общаться с клиентами и друг с другом?

Cloud Server, General | Amber | 1 Comment

Начать работу над планом коммуникации во время ликвидации неполадок приложения никогда не рано. Делать это во время первого серьезного сбоя – однозначно слишком поздно. Незапланированный простой может привести к оттоку клиентов и огромному количеству входящих сообщений на техподдержку. Всего один час незапланированного простоя может стоить организациям шестизначных сумм, а согласно последнему ежегодному обзору Information Technology Intelligence Consulting Research – зачастую и намного больше.

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

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

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

До аварии

Определите особо важные ошибки

Иногда трудно понять, что именно является «аварийной ситуацией». Вот набор рекомендаций, которые используют SRE Google; событие считается аварией, если соблюдается хотя бы одно из следующих условий:

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

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

Примечание: Еще один полезный ресурс для определения степени опасности ошибки – это руководство от VMware.

«Я просто быстро исправлю это, прежде чем кто-нибудь заметит», – это скользкая дорожка. Играя в подобные азартные игры, вы можете выиграть в первый раз, но достаточно скоро вы сильно прогорите.

Роли в команде

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

Руководитель работ по устранению аварии

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

Коммуникатор

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

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

Подготовка шаблонов

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

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

Например, сообщение на странице состояния может выглядеть так:

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

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

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

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

Во время аварии

В аварийной ситуации мы рекомендуем вам придерживаться этих трех золотых правил.

1. Сообщите о проблеме как можно раньше. Если вы обнаружили сбой, который оказывает влияние на клиентов, сообщите о нем как можно раньше. Он не должен быть совершенным. Это сообщение поможет убедить пользователей в том, что вы знаете об этой проблеме и активно работаете над ее устранением. Это также замедлит поток билетов техподдержки и входящих сообщений, которые вы обязательно получите во время аварии.
2. Чаще обновляйте информацию. Когда вы не поднимая головы работаете над устранением ошибки, вы можете забыть выгрузить какие-то промежуточные данные об ошибке. Однако если промежутки между обновлениями длинные, это может вызвать у клиентов неуверенность и беспокойство. Они будут ожидать худшего. Публикуйте обновления и отчеты, даже если вы собираетесь просто сообщить, что все еще работаете над проблемой – это намного лучше, чем вообще ничего. Держите клиентов в курсе. Особенно хорошо было бы написать, когда вы планируете опубликовать следующий отчет о работе (и своевременно опубликовать его).
3. В сообщениях во время аварии публикуйте как можно более точную информацию. Не нужно предположений и примерных ответов. Вместо «Кажется, мы знаем в чем дело, но нам нужно больше времени» напишите «Мы все еще ищем первопричину». Вместо «Похоже, проблема связана с базой данных» попробуйте «Мы продолжаем изучение этой проблемы». На первый взгляд второй пример может показаться нелогичным. Почему нельзя написать, что проблема может быть связана с базой данных? Потому что пока в этом никто не уверен. Избегайте фраз типа «мы думаем». Не говорите, что вы «думаете», что нашли основную причину. Вы либо нашли ее, либо нет. Когда вы будете точно знать, в чем причина аварии, предоставьте клиентам как можно больше данных об этом. Например:

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

После аварии

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

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

• Сопереживание. Извинитесь перед клиентами за неудобства, поблагодарите за их терпение и убедите, что вы работаете над исправлением неполадки.
• Персонализация. Команды часто деперсонализируют себя, пытаясь казаться профессиональными и официальными. В результате получается холодный, отрешенный тон, а это не создает доверия. Используйте активный залог и местоимение «мы». Избегайте академизмов и бюрократизмов. Вместо «Работы по восстановлению новых конфигураций балансировки нагрузки завершены» попробуйте использовать «Мы закончили конфигурацию новых балансировщиков нагрузки».
• Подробности внушают доверие. Много слов и никакой конкретики – и ваш заключительный отчет выглядит, как пускание пыли в глаза клиентов. Даже если вы не уверены, что всем вашим читателям понадобятся технические подробности проблемы, предоставьте их. Те клиенты, которые заинтересованы в такой информации, оценят это. Остальные по крайней мере увидят, что вы предоставляете много деталей, чтобы объяснить, что произошло. Часто техподдержка беспокоится о том, что сообщение написано слишком «техническим» языком, и в результате отправляет пользователям смягченную версию без подробностей. Так лучше не делать.
• Заключительный послеаварийный отчет – это отличный шанс оставить за собой последнее слово. Четко изложите читателям, что вы делаете, чтобы сбой не повторился. Конкретно изложите, что пошло не так и что команда делает, чтобы проблема не повторялась.

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