Будущее управления ИТ-инцидентами, реагирования на них и способов их предотвращения

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

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

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

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

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

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

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

• Уменьшилось ли время, необходимое для восстановления?
• С какими преградами культурного характера столкнулась команда?
• Какие инструменты этой команде предоставила ИТ-команда?
• Какие процессы потребовалось передать?
• Повысилось ли качество обновлений системы, производимых этой командой?
• Уменьшилось ли количество инцидентов?
• Если потребуется провести такую децентрализацию для других команд, какие выводы нужно будет учесть из этого первичного эксперимента?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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