Управление инцидентами для высокоскоростных команд
Рекомендации по информированию об инцидентах
Для участников команд ИТ и эксплуатации инциденты всегда были суровой реальностью. Сегодня методы информирования об инцидентах осваивают в том числе команды DevOps и службы поддержки клиентов.
Информирование об инцидентах — это процесс оповещения пользователей о том, что сервис испытывает некоторые перебои в работе или снижение производительности. Это особенно важно для веб-сервисов и сервисов программного обеспечения, от которых ожидается круглосуточная доступность.
Информирование об инциденте в сфере веб-технологий не ограничивается рассылкой электронных сообщений в группе. Каждой целевой аудитории требуется особый подход. Разные обстоятельства требуют определенных сообщений и разных мер по реагированию.
Полностью избежать простоев невозможно, поэтому лучше заранее составить план и подготовить команду.
Далее приведены наши рекомендации по информированию об инцидентах. Из них вы узнаете:
- в чем заключается важность сообщений об инцидентах;
- как подготовиться к информированию об инцидентах;
- как действуют профессионалы в сфере информирования об инцидентах;
- почему процесс информирования не завершается вместе с инцидентом.
Кому нужно информирование об инциденте?
Это нужно вашим клиентам и коллегам, поэтому вам тоже стоит проявить интерес. Если простою не уделить достаточно внимания, могут пострадать ваши клиенты, команды и финансовые показатели. Некоторые клиенты могут испугаться потенциальных разочарований и уйти к конкуренту. Вы потеряете будущих клиентов из-за отсутствия доверия. Это может подорвать моральный дух команды и снизить производительность. Кстати, можете забыть про «сарафанное радио», которое могло бы привести столь многих клиентов.
К счастью, внеплановые простои не должны становиться кошмаром для службы поддержки клиентов. Если держать клиентов в курсе ситуации и сообщать им о том, что вы делаете для устранения проблемы, они проявят понимание и будут гораздо спокойнее реагировать на трудности.
Подготовка к информированию об инцидентах
Правильная подготовка предотвращает плохие последствия. Это правило легко запомнить, поэтому возьмите его за основу своей стратегии информирования об инцидентах. Когда инцидент будет в самом разгаре, вы порадуетесь, что нашли время для информирования об инцидентах.
Ваше понимание инцидента
Чтобы иметь возможность сообщать об инцидентах, сначала нужно дать ему определение. Многие компании в сфере веб-технологий используют классическую четырехуровневую систему оценки опасности. Хороший подход к определению уровней опасности приведен в нашем Справочнике по инцидентам.
Какие бы пороговые значения вы ни установили для каждого уровня опасности инцидента, важно определить четкие критерии (лучше всего с привязкой к измеримому показателю). Если вы присваиваете инциденту уровень опасности 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 можно использовать несколько каналов связи, не опасаясь, что возникнет путаница и вы потеряете доверие клиентов.
Настраивайте оповещения и сообщения с учетом аудитории
Когда возникнет инцидент, вы должны знать, кому и каким образом о нем сообщить и как это сделать максимально быстро и легко, чтобы избежать наплыва запросов в службу поддержки клиентов и перегрузки каналов связи. Лучше всего начать с внутреннего круга, оповестив команду немедленного реагирования, после чего подготовить сообщения для более широкой аудитории с учетом ее особенностей.
Хотя все организации разные, в целом полезно разделить аудиторию на пять групп, с которыми необходимо наладить общение.
- Основная дежурная команда узнает о проблеме первой, практически сразу после ее возникновения (обычно с помощью средств мониторинга и оповещения). Внутренние команды занимаются обнаружением и штурмом инцидентов, а также изучением контекста и устранением проблемы, используя инструменты совместного общения.
- Команда поддержки первого уровня непосредственно отвечает на вопросы и сообщает клиентам оперативную информацию об инциденте. Это невероятно важная роль, поэтому команда должна получать корректную информацию, чтобы передавать ее конечным пользователям.
- Менеджеры и исполнительное руководство должны получить от основной команды информацию о ситуации, потенциальном влиянии на следующие две группы и (желательно) расчетном времени устранения инцидента.
- Остальные сотрудники должны быть в курсе отключения и восстановления работы сервисов, которыми они пользуются. Упреждающее информирование этих пользователей позволит сократить количество вопросов типа «а что с…» и количество дублирующихся заявок в службу ИТ-поддержки, чтобы уделить больше внимания решению возникшей проблемы.
- Внешние клиенты. Если инцидент затрагивает внешних клиентов, вы должны отправить им сообщение, чтобы рассказать о проблеме и сообщить об ожидаемом сроке ее устранения или, по крайней мере, регулярно информировать их о текущей ситуации. Если из-за возникших проблем клиенты пока не могут использовать продукт, рекомендуем отправлять им оперативную информацию хотя бы раз в час. При этом уточняйте, когда можно ожидать очередных новостей. Если инцидент достаточно серьезный (особенно если он связан с безопасностью или потерей данных), придется ускорить взаимодействие с внешними клиентами и привлечь другие необходимые команды (юридическую, кадровую, отдел безопасности и т. д.).
Подготовка шаблонов сообщений об инцидентах и отказах
В разгар инцидента меньше всего хочется думать, как сформулировать объявление о нем. Неправильная формулировка может стать отличной мишенью для менеджеров нетехнического профиля, которые ищут возможность раскритиковать процесс реагирования вашей команды.
Заранее согласуйте объявление с менеджерами и сохраните его в шаблон. Так вы легко дополните его необходимой информацией и сможете выпустить в тот же день, когда произойдет инцидент.
Приведем два шаблона сообщений об инцидентах, которые мы используем для собственной страницы статусов.
- Наблюдается аномально высокая нагрузка на сайт, из-за чего, возможно, снизится скорость загрузки страниц или страницы перестанут отвечать. Мы изучаем причины инцидента и сообщим оперативную информацию в ближайшее время.
- Поставщик нашего хранилища, в котором содержатся данные общедоступных показателей, в настоящее время испытывает проблемы с инфраструктурой. Мы будем сообщать новости по мере развития ситуации или поступления сведений.
С другими примерами можно ознакомиться в нашей библиотеке для шаблонов сообщений об инциденте.
Профессиональное управление общением
Жизненный цикл инцидента обычно включает несколько эпизодов информирования. В оптимальном сценарии процесс реагирования часто имеет трехактную структуру: первое сообщение, обновления во время инцидента, затем объявление о разрешении и отчет о разборе инцидента.
Пролог. Централизованное обсуждение во внутренней команде
Чтобы устранять инциденты, внутренние команды обязательно должны иметь платформу для общения и быть готовы к штурму возникающих проблем.
Централизованная обработка и фильтрация оповещений во всех инструментах мониторинга, ведения журналов и 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.
При такой формулировке клиентам и коллегам будет несложно поверить, что в вашей команде работают здравомыслящие специалисты, которые держат руку на пульсе. Еще несколько идей можно найти в нашем шаблоне для ретроспективы по итогам реакции на инциденты.
Все постоянно работающие сервисы рано или поздно дают сбой. Эффективное общение во время простоя помогает построить доверительные отношения с коллегами и клиентами. Многое зависит от вашей реакции на инцидент. Мы создали простой инструмент, с помощью которого вы сможете быстро составлять эффективные сообщения во время инцидентов.
Рассмотренные продукты
Без труда информируйте пользователей о состоянии дел в режиме реального времени.
Изучайте информирование об инцидентах с помощью Statuspage
В этом руководстве мы покажем, как использовать шаблоны инцидентов, чтобы наладить эффективную коммуникацию во время разрешения инцидента. Применимо ко многим видам технических сбоев.
Читать учебное руководствоШаблоны и примеры информирования об инцидентах
Во время реагирования на инциденты становится ясна ценность шаблонов сообщений. Загрузите шаблоны, которые использует наша команда, и познакомьтесь с другими примерами распространенных инцидентов.
Читать статью