Управление ИТ-инцидентами: как меняется эта практика

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

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

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

• Как помогает Jira Service Management: каждая команда может самостоятельно управлять инцидентами в своих службах, при этом оповещения, сроки, ретроспективы и такие показатели, как MTTR, остаются в одном месте и доступны для руководства и заинтересованных лиц.

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

Раньше за реагирование на технологические инциденты почти всегда отвечал ИТ-отдел — часто это был центр администрирования сети (NOC), который отслеживал работу систем, реагировал на сбои, а также развертывал и обслуживал программное обеспечение, созданное поставщиком. С распространением облачных сервисов поставщики теперь сами создают, развертывают и обслуживают ПО, а команды DevOps, SecOps и архитекторы все чаще участвуют в реагировании на инциденты. В этом руководстве рассматривается, как меняется эта практика и что это означает для ролей, процессов и команд.

Переход к децентрализации

Если бы пять лет назад вы спросили ИТ-команду, кто отвечает за управление инцидентами, ее участники бы наверняка ответили: «Мы».

Задайте тот же вопрос сейчас, и вам, скорее всего, расскажут не только об ИТ-отделах, но и о командах DevOps, SecOps и командах архитекторов. Многие организации постепенно переходят к концепции «кто разработал, тот и поддерживает».

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

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

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

Медленный путь к децентрализации

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

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

• Уменьшилось ли время, необходимое для восстановления?

• С какими преградами культурного характера столкнулась команда?

• Какие инструменты этой команде предоставила ИТ-команда?

• Какие процессы потребовалось передать?

• Повысилось ли качество обновлений системы, производимых этой командой?

• Уменьшилось ли количество инцидентов?

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

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

Децентрализация означает межкомандное сотрудничество

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

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

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

Переход от реактивного подхода к проактивному

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

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

Однако восстановление — это не панацея. Этот факт понимает все больше ИТ-команд, поэтому к процессу управления инцидентами добавляются процедуры предотвращения. При этом производительность команды оценивается не по среднему времени восстановления, а с помощью таких показателей, как среднее время разрешения.

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

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

В долгосрочной перспективе предотвращать инциденты выгоднее, чем быстро реагировать на них.

Держитесь курса: процесс и документация

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

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

При обучении команд управлению инцидентами ИТ-специалисты могут помочь им ответить на основные вопросы, которые будут определять их план. Вот несколько примеров.

• Какова ваша реакция на инциденты?

• Каким принципам вы будете следовать?

• Как вы будете реагировать в случае инцидента?

• Где находится информация, необходимая для обслуживания критически важных систем, которые вы поддерживаете? Если эта информация расположена в нескольких системах, как можно объединить ее и обеспечить к ней удобный доступ для дежурных?

• Доступны ли процесс и документация для изучения и использования всей командой?

Готовы ли вы поменять культуру вашей компании?

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

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

В компании Atlassian считают, что такая культура включает следующие основные компоненты.

Открытость и обмен информацией

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

Клиентоориентированное мышление

Когда мы задаем такие вопросы, как «Что на самом деле лучше для клиента?», иногда наши ответы не сочетаются с тем, что мы делаем. Требуется искренняя клиентоориентированность, чтобы перейти к такому виду коммуникации, процессов и структур, который в итоге позволит нам сделать продукт лучше для клиентов.

Регулярные проверки работоспособности

Как дела у каждой команды? Как дела у каждого отдельного участника команды? Что может пойти на пользу команде? В чем она особенно преуспевает? В компании Atlassian есть сборник сценариев для команды, который помогает нам оценить эффективность команд и познакомить их с новыми способами работы.

Эмпатия

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

Расширение прав и возможностей

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

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