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

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

 

Shannon Winter Shannon Winter
Browse topics

Методы 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 Desk, Twitter и т. д.). Лучшие компании мира понимают, что клиенты ожидают ответа на свои сообщения и хотят быть причастными к разработке усовершенствований продукта и реагированию на инцидент. Клиенты ценят и, как видно из следующих твитов, не стесняются обращаться за разъяснениями и сочувствием:

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

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

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

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

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

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

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

Подсказка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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