Close

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

Просмотр тем

Управление инцидентами в эпоху DevOps

Применение принципов открытого общения без поиска виноватых в командах по управлению инцидентами

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

В своем знаменательном выступлении «Более 10 развертываний в день: сотрудничество команды по разработке и операционной команды во Flickr» в 2009 году Джон Олспоу и Пол Хаммонд изложили видение мира, где команды разработчиков и ИТ-команды ведут совместную работу и выполняют частую поставку. В течение следующего десятилетия это видение сложилось в движение DevOps.

По своей природе DevOps зависит от новых способов реагирования на инциденты. Неудивительно, что в выступлении Олспоу и Хаммонда управлению инцидентами было уделено столько внимания.

«Важно понимать, что сбой будет, — сказал в своем выступлении Хаммонд. — Вопрос не в том, будет ли, а в том, когда».

В отличие от таких методик, как ITIL, у команд DevOps нет официального документа с рекомендациями. Но в целом можно согласиться, что по сути практика DevOps призвана повысить ценность бизнеса путем преодоления организационной разрозненности, повышения прозрачности и стимулирования открытого общения между командами разработчиков и операционными ИТ-командами».

Та же культура прозрачности, наглядности и быстрого обучения распространяется на управление инцидентами.

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

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

С другой стороны, ITIL представляет собой фиксированный набор из 26 процессов, процедур, заданий и списков задач, предназначенных для улучшения конкретных практик управления ИТ-услугами. ITIL фокусируется на качестве и единообразии обслуживания, а также повышении устойчивости систем.

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

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

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

Процесс управления инцидентами в DevOps

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

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

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

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

4. Анализ
Команды DevOps по управлению инцидентами закрывают инцидент с помощью процесса ретроспективы без поиска виноватых. Они собираются вместе, чтобы поделиться информацией, показателями и полученным опытом для непрерывного повышения устойчивости своих систем, а также быстрого и эффективного разрешения будущих инцидентов.

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

Рекомендации по эффективному управлению инцидентами для команд DevOps

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

Автоматизация процессов и рабочих процессов
Интегрируйте свои инструменты для службы поддержки, мониторинга, системы заявок, CMDB / управления ресурсами и чата, чтобы упростить процесс оповещения об ИТ-инцидентах и рабочие процессы, а также предоставить соответствующим специалистам информацию, необходимую для работы над разрешением проблемы. Настройте перечни процедур с заранее определенными рабочими процессами, чтобы люди могли с ходу приступить к делу в случае возникновения инцидента.

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

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

Выявление финансовых показателей бизнеса и упор на них
Реакция на инциденты по DevOps — это не просто средство для улучшения коммуникации, это способ организовать совместную работу команды разработчиков и операционной команды для обеспечения реальной коммерческой ценности. Отслеживайте такие показатели, как среднее время до обнаружения (MTTD), среднее время исправления (MTTR) и средняя наработка на отказ (MTBF), чтобы понять темпы улучшения вашей команды.

Использование графика дежурств для позиционирования разработчиков и системных администратор в качестве SRE
В командах DevOps границы между разработчиком и системным администратором начинают размываться, и специалисты, занимающиеся реагированием на инциденты, часто становятся инженерами по техническому обеспечению надежности сайта (SRE). Тем не менее эти люди, как правило, имеют специализированные знания либо о коде приложения, либо о коде инфраструктуры. Настройте расписание дежурств таким образом, чтобы гарантировать доступность подходящего сочетания экспертных знаний для реагирования на инциденты.

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