Реагирование на инцеденты

Agile для случаев, когда что-то идет не так: недостающий фрагмент вашего плана реагирования на инциденты

Адаптируя значения, содержащиеся в Agile Manifesto, вы можете подавить реакцию на инцидент и повысить доверие пользователей.

Гибкие методологии все чаще используются за пределами традиционной сферы разработки программного обеспечения во всех областях бизнеса - даже в маркетинге! Итак, мы подумали, как выглядит agile в мире управления инцидентами? В Atlassian мы определяем agile как структурированный и итеративный подход к управлению проектами и разработке продуктов. Agile дает вашей команде возможность реагировать на изменения, не сходя с пути.

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

Применение agile ценностей к реагированию на инциденты

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

Многие из вас, вероятно, уже знакомы с четырьмя ключевыми значениями agile  манифеста: 1) отдельные лица и взаимодействия над процессами и инструментами, 2) работа программного обеспечения над исчерпывающей документацией, 3) взаимодействие с заказчиком через переговоры по контракту и 4) реагирование на изменения следуя плану. Давайте углубимся в каждое из них и посмотрим, как их можно использовать для более гибкого сотрудничества об инцидентах.

Принцип сообщения о происшествии: ориентированное на человека общение об инциденте

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

 

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

Во время инцидента затронутые пользователи, скорее всего, испытывают разочарование - если не прямо изнурительные – ошибки и должны знать, что случилось, как можно скорее. Многие уже будут отправлять по электронной почте, твиттере и / или регистрировать билеты по этой проблеме, поэтому в интересах всех, чтобы быстро разобраться в ситуации с сообщением, которое показывает, что вы знаете, что что-то не так, и ищете как исправить. В Atlassian мы используем Statuspage для связи с внутренними и внешними заинтересованными сторонами во время простоя и думаем, что вы тоже быстро найдете это значение, пытаясь быстро и масштабируемо передавать информацию об инцидентах своим пользователям. Фактически, Statuspage помог пользователям увеличить скорость их связи с инцидентами на целых 50%.

ХОТИТЕ ПОПРОБОВАТЬ?

Зарегистрируйтесь или войдите на страницу статуса >>

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

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

Но независимо от того, какой инструмент вы используете, чтобы дать своим клиентам 4-1-1, общение с людьми будет иметь большое значение. С другой стороны проблемы есть реальные люди, которые полагаются на ваш сервис и полагаются на вас, чтобы держать их в курсе, когда что-то не так. Хотя шаблоны идеальны в идеальном мире, вам понадобятся люди, способные создавать четкие, лаконичные, чуткие и актуальные сообщения, чтобы завоевать доверие клиентов даже в самые худшие времена. Взять хотя бы Дина. У них был огромный сбой во время одной из крупнейших DDoS-атак в истории, но пользователи по-прежнему благодарили их за откровенность, проявленную ими в эти часы прерванного обслуживания:

Как сказал Вернер Фогельс, технический директор AWS, при обсуждении большого сбоя AWS S3 в феврале 2017 года:

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

 

Принцип взаимодействия с инцидентами: создание безбарьерной страницы и обновление инцидентов

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

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

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

Готовы создать свою собственную страницу статуса? Зарегистрируйтесь или войдите на страницу статуса >>

 

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

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

 

 Принцип связи с инцидентами: прозрачная коммуникация во время инцидентов и за их пределами

Эта agile ценность сотрудничества с заказчиками по сравнению с переговорами по контракту сводится к работе с вашими клиентами для обеспечения наилучшего продукта и опыта. Для нас это означает, что необходимо настроить надлежащие каналы обратной связи, чтобы клиенты могли озвучивать проблемы и предупреждать вас о любой проблеме, которую они имеют (используя такие инструменты, как Jira Service Desk, Twitter и т. Д.). Компании мирового уровня понимают, что клиенты ожидают ответа на свои отзывы и хотят участвовать, когда дело доходит до улучшения вашего продукта и вашего процесса реагирования на инциденты. Некоторое сочувствие и объяснение имеют большое значение - и клиенты не боятся просить об этом - как показано в этих твитах:

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

Принцип связи с инцидентами: Agile ретроспектива

Даже самые продуманные планы ... ну, ты знаешь все остальное. Мы напоминаем о ценности agile. Отвечая на изменения в соответствии с планом, мы знаем, что даже самые тщательно продуманные планы неизбежно должны будут измениться как во время, так и после инцидента. Agile - это возможность поворачиваться на мгновение и получать быструю и постоянную обратную связь, которая улучшает ваш продукт и культуру.

Wistia, компания, предоставляющая интернет-видео и аналитику, поняла, насколько важно оставаться agile во время неожиданного инцидента в 2013 году, который привел к остановке инфраструктуры статистики. Они не были готовы, оставив их заботы билетами поддержки от недовольных клиентов. Их первой опорой было создание собственной страницы статуса, чтобы помочь облегчить им жизнь в подобных ситуациях. Но, создав собственный инструмент информирования о статусе, они теперь поддерживали новый продукт в дополнение к своему основному продукту. Стало ясно, что это была стоимость, которую их команда из 20 человек в то время не могла себе позволить. Второй опорой было вызвать их доморощенные решения и перейти на страницу состояния.

Джордан Мансон (Jordan Munson), специалист службы поддержки Wistia, описал этот шаг: «После нескольких месяцев легкого разочарования по поводу нашего почти безликого, но полезного решения для дома, мы решили, что нам нужно что-то большее, что не требует особого ухода. Ввести страницу статуса. Перенесемся через пару лет в наше время, и наш процесс выглядит более плавным. Люди получают обновления от нас напрямую, когда происходит сбой, они знают, где искать обновления, а обновления, сделанные на нашей странице состояния, ведут прямо в несколько мест ».

Команда Мансона по-настоящему взяла лимоны (отключение в 2013 году) и сделала лимонад (новый и улучшенный - и масштабируемый - процесс взаимодействия с инцидентами). Это agile ответ на изменения в лучшем виде.

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

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

Язык людей	Язык продукта
Предположения, надежды и страхи	Задачи, проблемы и действия
Мотивации, недоразумения и поведение	Источники, эпики, рассказы и релизы
Предпочтения, отношения и уважение	Вехи, зависимости и даты
Роли и ответственности	Встречи, календари, электронные письма и файлы

 

Не забывайте  о доверии

Мы много говорим о доверии к agile, и в этом случае он ничем не отличается. Эффективное информирование об инцидентах требует доверия и расширения прав и возможностей. Команды во всей организации должны чувствовать себя уполномоченными с одобрением и знаниями, необходимыми для общения с пользователями по поводу инцидентов. Люди также должны быть в состоянии доверять тому, что каждый будет выполнять назначенную им обязанность во время реагирования на инцидент, и не будут смущаться переходить и принимать перерыв в процессе, когда происходит непредвиденное. Доверие ваших команд к эффективному общению вокруг инцидентов позволит клиентам быстрее получать информацию и, в свою очередь, повысит доверие пользователей и лояльность к вашему сервису (67% клиентов Statuspage говорят, что Statuspage помогла повысить доверие их пользователей!) беспроигрышная.

По материалам Agile Coach "Incident response"