Управление инцидентами для высокоскоростных команд
Будущее управления ИТ-инцидентами, реагирования на них и способов их предотвращения
Раньше реагированием на технические инциденты почти всегда занималась команда ИТ, а команды в сетевых операционных центрах (NOC) нередко осуществляли мониторинг систем и реагировали на сбои. Программное обеспечение создавали поставщики, однако его развертывание и эксплуатация были обязанностью ИТ-специалистов клиента. Однако сегодня мы наблюдаем распространение облачных сервисов, в условиях которого все эти задачи выполняет сам поставщик ПО.
При этом управление инцидентами по-прежнему остается основной практикой ITSM. ИТ-специалисты уже давно занимаются разработкой руководящих принципов, управлением бюджетами, выполнением полной диагностики, а также исправлением, документированием и предотвращением серьезных инцидентов.
Конечно, в технической сфере прошлое не всегда позволяет предвидеть будущее. Современная практика управления инцидентами переживает изменения, и более активное участие в этом аспекте работы теперь принимают команды DevOps, SecOps, а также команды архитекторов. Процесс управления инцидентами меняется под влиянием новых технологий и взаимосвязанных продуктов. Менталитет, методы работы и структура команд также меняются, чтобы сохранять актуальность.
Как же меняется управление инцидентами и что это означает для будущего наших ролей, продуктов, процессов и команд?
Переход к децентрализации
Если бы пять лет назад вы спросили ИТ-команду, кто отвечает за управление инцидентами, ее участники бы наверняка ответили: «Мы».
Задайте тот же вопрос сейчас, и вам, скорее всего, расскажут не только об ИТ-отделах, но и о командах DevOps, SecOps и архитектурных командах. Многие организации постепенно переходят к концепции «кто разработал, тот и поддерживает».
Очевидные преимущества этого подхода в том, что ответственность ложится на плечи людей, непосредственно знакомых с кодом. Благодаря этому можно разгрузить ИТ-команды, повысить скорость реагирования, сократить время простоя и оптимизировать производительность команды. Кроме того, в рамках этого подхода разработчики стараются обеспечить качество кода. Если вам пришлось проснуться в 3 часа ночи, чтобы устранить баг, скорее всего, вы трижды проверите код перед следующим развертыванием, чтобы ночные звонки больше не повторялись.
Сложность такой концепции в том, что организациям все еще требуется централизация. Руководству нужен доступ к отчетам и документации. Заинтересованные стороны в компании хотят получать новости. Они хотят отслеживать показатели инцидентов, такие как среднее время разрешения и среднее время подтверждения. Им нужны четкие сообщения об инцидентах, отчеты о ретроспективном разборе инцидентов, а также планомерная работа по устранению недостатков.
В контексте компаний, которые эффективно движутся к децентрализации, эту проблему часто можно решить с помощью технологии, которая не только позволяет провести децентрализацию и предоставить командам автономию для ускоренного разрешения инцидентов, но и дает возможность собирать информацию в едином центре, чтобы держать компанию в курсе событий.
Медленный путь к децентрализации
Значительные изменения могут нарушить рабочие процессы и вызвать непредвиденные последствия, поэтому многие организации стараются действовать разумно и проводят децентрализацию маленькими шагами.
Трансформация начинается с выбора команды, которая готова к таким изменениям с точки зрения культуры и уже поддерживает приложение или продукт, лишенные значительных рисков. Затем выбранной команде передается управление инцидентами для этого конкретного приложения или продукта. Проводится обучение команды, создается график дежурств и отслеживается прогресс с течением времени. Для этого задаются вопросы вроде следующих.
- Уменьшилось ли время, необходимое для восстановления?
- С какими преградами культурного характера столкнулась команда?
- Какие инструменты этой команде предоставила ИТ-команда?
- Какие процессы потребовалось передать?
- Повысилось ли качество обновлений системы, производимых этой командой?
- Уменьшилось ли количество инцидентов?
- Если потребуется провести такую децентрализацию для других команд, какие выводы нужно будет учесть из этого первичного эксперимента?
Такие эксперименты должны помочь понять, следует ли внедрять принцип «кто разработал, тот и поддерживает» во всей компании и как реализовать такой принцип среди команд.
Децентрализация означает межкомандное сотрудничество
Для перехода к децентрализации также нужно наладить сотрудничество между командами. Если команда DevOps занимается управлением инцидентами, ей также нужно принимать участие в собраниях по процессам управления ИТ-инцидентами. Если ИТ-специалисты по-прежнему помогают применять принципы управления инцидентами, они должны участвовать в разборах инцидентов с другими командами.
Каждая команда привносит свои сильные стороны в управление инцидентами. ИТ-команды умеют разрабатывать методики и документацию, а также следовать инструкциям. Команды DevOps хорошо справляются с обучением и адаптацией к переменам. Команда SecOps может взглянуть на ситуацию с точки зрения безопасности.
Чтобы стимулировать сотрудничество между командами, успешные компании открыто обмениваются информацией, развивают культуру эмпатии, пресекают межкомандное соперничество, поддерживают связь между командами во время инцидентов с помощью чата, а также стараются предоставить слово всем участникам в ходе разбора инцидентов.
Переход от реактивного подхода к проактивному
Согласно руководящим принципам ITIL, управление инцидентами в основном рассматривается отдельно от предотвращения инцидентов. Обе практики являются важными частями сложной системы ITSM, но они редко работают вместе.
Проблема такого подхода в том, что он ориентирует сотрудников на реактивное управление инцидентами. Дежурным поручено тушить пожары, и как только один пожар гаснет, они ожидают следующего. Единственная цель — это восстановление системы, то есть ее возврат в рабочее состояние.
Однако восстановление — это не панацея. Этот факт понимает все больше ИТ-команд, поэтому к процессу управления инцидентами добавляются процедуры предотвращения. При этом производительность команды оценивается не по среднему времени восстановления, а с помощью таких показателей, как среднее время разрешения.
Этот подход часто называют управлением проблемами. Он помогает сблизить процессы и тем самым гарантировать, что команды не просто «тушат пожары» один за другим — они реагируют на инцидент, восстанавливают работу системы и учатся на этом инциденте. Затем полученные знания можно применить к текущим проблемам, а также к продукту и сервису, которыми управляет команда.
Многие корпоративные ИТ-организации используют собственный подход к управлению проблемами, который обычно рассматривается как отдельный процесс для отдельной команды. Компания Atlassian решила пойти дальше и применить смешанный подход, в котором ИТ-специалисты и команды разработчиков включают практику управления проблемами в управление инцидентами. Благодаря этому становится проще ориентироваться в ситуации на протяжении всего инцидента. Кроме того, появляется уверенность в том, что анализ инцидента будет выполнен вскоре после его возникновения.
В долгосрочной перспективе предотвращать инциденты выгоднее, чем быстро реагировать на них.
Держитесь курса: процесс и документация
Переход к межкомандному сотрудничеству в области управления инцидентами сложен в том числе и тем, что одни команды начинают менее серьезно воспринимать процесс и документацию, чем другие.
ИТ-специалисты могут взять этот аспект под свой контроль и принести значительную пользу, даже если другие команды заняты управлением собственными продуктами. Ведь никто не хочет разбираться с серьезным инцидентом в 3 часа ночи без четкого плана, правда?
При обучении команд управлению инцидентами ИТ-специалисты могут помочь им ответить на основные вопросы, которые будут определять их план. Вот несколько примеров.
- Какова ваша реакция на инциденты?
- Каким принципам вы будете следовать?
- Как вы будете реагировать в случае инцидента?
- Где находится информация, необходимая для обслуживания критически важных систем, которые вы поддерживаете? Если эта информация расположена в нескольких системах, как можно объединить ее и обеспечить к ней удобный доступ для дежурных?
- Доступны ли процесс и документация для изучения и использования всей командой?
Готовы ли вы поменять культуру вашей компании?
Для перехода к децентрализации, совместной работе и сочетанию управления инцидентами и проблемами недостаточно просто перераспределить обязанности и пригласить ИТ-специалиста поучаствовать в ретроспективном разборе инцидента после его разрешения командой DevOps. Ключ к успеху лежит не в технологии и даже не в процессах, а в создании внутренней культуры, которая поддерживает эти изменения.
Многие компании пытаются пропустить этот шаг, лишая себя основы для успешного перехода. Как же выглядит культура, поддерживающая децентрализованное, совместное и прогрессивное управление инцидентами?
В компании Atlassian считают, что такая культура включает следующие основные компоненты.
Открытость и обмен информацией
Если команды не знают и не могут узнать, что делают другие команды, мы теряем те самые моменты истины, которые приводят к улучшению коммуникации, процессов и продуктов.
Клиентоориентированное мышление
Когда мы задаем такие вопросы, как «Что на самом деле лучше для клиента?», иногда наши ответы не сочетаются с тем, что мы делаем. Требуется искренняя клиентоориентированность, чтобы перейти к такому виду коммуникации, процессов и структур, который итоге позволит нам сделать продукт лучше для клиентов.
Регулярные проверки работоспособности
Как дела у каждой команды? Как дела у каждого отдельного участника команды? Что может пойти на пользу команде? В чем она особенно преуспевает? В компании Atlassian есть сборник сценариев для команды, который помогает нам оценить эффективность команд и познакомить их с новыми способами работы.
Эмпатия
Если DevOps показывает пальцем на ИТ-отдел, а ИТ-отдел закатывает глаза на более расслабленный подход DevOps, это не командная работа. Укрепление эмпатии и связей между командами очень важно, если вы хотите, чтобы они ладили, внедряли инновации и работали вместе.
Расширение прав и возможностей
Командам нужно предоставлять такие возможности, чтобы они могли быстро устранять проблемы и как можно чаще принимать самостоятельные решения. Участники этих команд должны понимать, что они могут свободно задавать вопросы, а также озвучивать предложения и опасения вне зависимости от своей позиции в команде или рабочего стажа.
Когда младшие разработчики знают, что можно поднять руку на собрании и рассказать о проблеме (даже если за рассматриваемый код отвечает старший сотрудник), в результате можно получить новаторские идеи, улучшить процессы и обнаружить баги до того, как они попадут в код.
Изучайте информирование об инцидентах с помощью Statuspage
В этом руководстве мы покажем, как использовать шаблоны инцидентов, чтобы наладить эффективную коммуникацию во время разрешения инцидента. Применимо ко многим видам технических сбоев.
Читать учебное руководствоШаблоны и примеры информирования об инцидентах
Во время реагирования на инциденты становится ясна ценность шаблонов сообщений. Загрузите шаблоны, которые использует наша команда, и познакомьтесь с другими примерами распространенных инцидентов.
Читать статью