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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эмпатия

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

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

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

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