3 совета по созданию надежного процесса реагирования на инциденты
devops sre incident-management incident-response site-reliability-engineering incident-response-plan incident-io

3 совета по созданию надежного процесса реагирования на инциденты

5 апреля 2022 г.

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


Вот три вещи, которые, по нашему мнению, составляют ключевую часть эффективного процесса.


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


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


1. Определите, что такое инцидент


По словам Джули Эндрюс, это очень хорошее место для начала.


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


Инцидент — это когда происходит что-то неожиданное, что имеет (или может иметь) негативные последствия.


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


С этой целью вам нужно широкое и всеобъемлющее определение инцидента:


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

  • Не возлагайте вину (или другие негативные последствия) на объявление инцидента. Это включает в себя отказ от использования «количества инцидентов» в качестве показателя работоспособности или производительности команды.

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

  • Не ограничивайте определение только проектированием: если вся ваша организация одинаково думает обо всем неожиданном, это означает, что вы сможете лучше сотрудничать (см. раздел 2).

2. Держите всех в курсе


Прозрачность по умолчанию — это действительно важная ценность, которую необходимо внедрить в процесс обработки инцидентов.


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


Упростите информирование заинтересованных сторон о том, что происходит, и используйте инструмент, облегчающий получение информации (будь то электронная почта, Slack или что-то еще).


Используйте предсказуемый формат для обновлений, так как это упрощает их анализ и сканирование, если вы заняты просмотром их уведомлений.


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


Спокойно признайте, что что-то идет не так, как внутри компании, так и (в некоторой степени) за ее пределами с клиентами. Это укрепляет доверие и позволяет людям адаптировать свое поведение, чтобы смягчить воздействие на их сторону (например, если клиент знает, что у вас сбой, он перейдет к другой задаче и вернется завтра вместо того, чтобы яростно обновлять страницу).


3. Помните: это не конец, пока он не закончился


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


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


Однако есть зона Златовласки. Если постинцидентный процесс кажется болезненным, люди вообще перестанут заявлять об инцидентах.


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


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


Резюме: Построение процесса реагирования на инциденты


Когда вы впервые создаете процесс реагирования на инциденты, сосредоточьтесь на нескольких ключевых вещах:


  1. Получите общее понимание того, что такое инцидент, и не делайте его слишком конкретным

  1. Упростите предоставление обновлений как внутренним, так и внешним заинтересованным сторонам

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

После того, как вы прибьете их, вы можете начать накладывать сверху еще что-нибудь. Но не пытайтесь бежать, пока не научитесь ходить.


Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE