Agile для нештатных ситуаций. Недостающий компонент плана реагирования на инциденты

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

 

Shannon Winter Автор: Shannon Winter
Просмотр тем

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

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

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

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

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

Принцип передачи информации об инцидентах: человекоцентричность

Этот принцип основан на ценности Agile, которая гласит: «Люди и взаимодействие важнее процессов и инструментов». Процессы и инструменты играют важную роль в управлении инцидентами, но они ничего не значат в отрыве от людей, которые пытаются их применять, а также сложившейся вокруг них культуры. Что же связывает людей, процессы и инструменты? Разумеется, коммуникация!

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

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

Хотите попробовать?

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

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

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

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

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

Принцип сообщения информации об инцидентах: беспрепятственное создание страниц и сообщение оперативных сведений об инциденте в удобной форме

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

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

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

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

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

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

Ценность Agile, согласно которой «сотрудничество с заказчиком важнее согласования условий контракта», ставит во главу угла сотрудничество с клиентом для поставки лучшего продукта и обеспечения максимального удобства. Нас это побудило организовать надлежащие каналы обратной связи, чтобы клиенты могли озвучить волнующие их вопросы и сообщить о любой проблеме (с помощью таких инструментов, как Jira Service Management, Twitter и т. д.). Лучшие компании мира понимают, что клиенты ожидают ответа на свои сообщения и хотят быть причастными к разработке усовершенствований продукта и реагированию на инцидент. Клиенты ценят и, как видно из следующих твитов, не стесняются обращаться за разъяснениями и сочувствием.

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

Принцип обсуждения инцидентов: agile-ретроспективы

Помните поговорку «раз в год и палка стреляет»? Из ценности Agile следует: «готовность к изменениям важнее следования первоначальному плану». Это значит, что даже самые продуманные планы рано или поздно устаревают и их приходится корректировать во время инцидента или после него. Суть Agile — в умении моментально сменить стратегию и постоянно отслеживать реакцию клиентов, благодаря чему совершенствуется продукт и подходы к работе.

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

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

Команде Мансона удалось превратить свои беды (инцидент 2013 года) в победы (новый, усовершенствованный и масштабируемый процесс передачи сведений об инцидентах). Такая реакция на изменение в полной мере отвечает духу Agile.

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

Подсказка

Попробуйте провести эту игру по ретроспективе из Atlassian Team Playbook и создайте безопасное место, где команда могла бы рефлексировать и обсуждать удачные (и неудачные) моменты для дальнейшего улучшения.

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

Слова пользователей

Описание продукта

Предположения, ожидания и опасения

Задания, задачи и действия

Мотивы, ложные представления и поведение

Спринты, эпики, пользовательские истории и релизы

Предпочтения, отношения и уважение

Контрольные точки, зависимости и сроки

Роль и обязанности

Совещания, календари, электронные письма и файлы

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

В Agile много внимания уделяется доверию, и в рассматриваемом нами сценарии для него тоже есть место. Чтобы передача сведений об инцидентах оказывала нужный эффект, требуются доверие и поддержка. Команды из разных частей организации должны чувствовать за собой поддержку в виде подтверждений и знаний, необходимых для информирования пользователей об инцидентах. Сотрудники также должны быть уверены в том, что все будут исполнять свои обязанности во время реагирования на инцидент и не раздумывая возьмутся устранять брешь в процессе, когда произойдет непредвиденная ситуация. Вера в то, что ваши команды смогут должным образом передавать сведения об инцидентах, позволит быстрее информировать клиентов и укрепит доверие и лояльность пользователей по отношению к вашему сервису (67 % клиентов Statuspage утверждают, что сервис Statuspage помог укрепить доверие их пользователей). От доверия выигрывают обе стороны.

продолжение темы
Continuous integration