Подробное руководство по управлению серьезными инцидентами в ITIL

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

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

Ставки серьезного инцидента сейчас особенно высоки, и согласно исследованию , проведенному компанией Information Technology Intelligence Consulting, 98 процентов организаций теряют не меньше 100 000 долларов за один час простоя. Это повышает важность подготовки процесса MIM, позволяющего эффективно и оперативно справляться с серьезными инцидентами.

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

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

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

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

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

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

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

1. Определение

Объявление о серьезном инциденте

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

Уведомление участников процесса

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

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

2. Сдерживание

Создание группы реагирования на серьезный инцидент

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

Настройка конференц-связи

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

Подготовка выделенного конференц-зала

Выделенный конференц-зал позволяет всем участникам ГРСИ собираться для поиска решения инцидента. Это улучшает совместную работу и помогает ГРСИ быстрее найти решение.

Создание заявки о проблеме для выявления исходных проблем

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

4. Обслуживание

Выполнение проверки после реализации

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

Оформление четкой документации

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

Измерение показателей

Измерение показателей эффективности службы поддержки помогает оценить эффективность ее работы и процесса MIM. Важно измерять такие показатели, как среднее время до подтверждения (СВДП), среднее время до разрешения (СВДР), общее количество серьезных инцидентов и среднее время простоя, вызванного серьезными инцидентами.

Для работы с серьезным инцидентом и его устранения требуется специальная группа сотрудников. В MIM задействованы следующие роли:

Технические специалисты службы поддержки

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

Менеджер по управлению серьезными инцидентами

Менеджер по управлению серьезными инцидентами несет ответственность за работу над серьезным инцидентом. Его роль включает объявление инцидента серьезным и обеспечение соблюдения процесса MIM и максимально быстрого разрешения инцидента. Он выступает в качестве основного контактного лица для получения любой информации о серьезном инциденте и руководит ГРСИ.

ГРСИ

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

Технический персонал

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

Менеджер по управлению изменениями

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

Менеджер по управлению проблемами

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

Внешние консультанты или сторонние поставщики

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

Рассмотрим 5 распространенных ошибок, снижающих эффективность процесса MIM

1. Сообщение и эскалация вручную

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

2. Неэффективные каналы сообщения о серьезных инцидентах

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

3. Дублирование задач

   Отсутствие организованного подхода к делегированию задач может привести к их дублированию в ГРСИ. Важно четко назначать задачи и держать ГРСИ в курсе того, какая задача назначена каждому из ее участников.

4. Ненадлежащая документация

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

5. Пренебрежение анализом основных причин

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

Предлагаем несколько рекомендаций для повышения эффективности процесса MIM.

1. Предусмотрите несколько каналов сообщения о серьезных инцидентах

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

2. Автоматизируйте процессы службы поддержки

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

3. Стремитесь к оперативному обмену актуальной информацией

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

4. Оформляйте четкую документацию

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

5. Выполните глубокую интеграцию с программным обеспечением ITOM

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

Важно помнить, что не все приоритетные инциденты считаются серьезными. Поскольку процесс MIM предполагает выделение существенного количества ресурсов, например создания отдельной ГРСИ, следует внимательно подходить к классификации серьезных инцидентов.

Источник: https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

Очень хорошим примером серьезного инцидента является выход из строя систем Cloudflare в 2019 году. В этом случае стандартная операционная процедура обновления управляемого правила для брандмауэра веб-приложения (WAF) вызвала скачок использования ресурсов ЦП, выделенных для обслуживания трафика HTTP/HTTPS, почти до 100 процентов на всех серверах сети Cloudflare. Последовавший за этим перебой в работе привел к снижению трафика Cloudflare на 80 процентов и затронул миллионы пользователей Интернета по всему миру.

Влияние: сильное

Этот сбой привел к тому, что при посещении любого домена Cloudflare клиенты Cloudflare (и их клиенты) видели страницу ошибки 502. Ошибки 502 создавались клиентскими веб-серверами Cloudflare, на которых еще оставались свободные ядра ЦП, но которые не могли запустить процессы, обслуживающие трафик HTTP/HTTPS. По оценкам, в течение двадцати семи минут простоя недоступной оказалась по меньшей мере половина всей сети Интернет.

Срочность: высокая

Все веб-сайты Cloudflare стали недоступными, что вызвало нарушения в работе тысяч организаций и миллионов пользователей. Этот сбой повлиял и на внутренние операции Cloudflare, не позволяя сотрудникам Cloudflare получить доступ к различным службам, таким как инструмент управления изменениями и внутренняя панель управления компании. Для восстановления нормальной работы служб необходимо было устранить сбой.

Хронология событий с момента обнаружения до разрешения

Управляемое правило WAF было применено в 13:42; через три минуты инструменты управления сетью Cloudflare начали отмечать падение трафика, многие другие сквозные тесты служб Cloudflare стали выдавать сбои, конечные пользователи замечали различные ошибки 502, и компания Cloudflare получила много отчетов об исчерпании ресурсов ЦП из точек присутствия в разных городах по всему миру.

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

К 14:52 компания Cloudflare была на 100 % удовлетворена выявлением причины перебоя и применила исправление, поэтому WAF были повторно включены по всему миру.

Изменение

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

Управление изменениями

Процесс выполнения изменений с минимальным количеством перебоев и конфликтов.

Эскалация

Процесс передачи ответственности за заявку на основании функциональной или иерархической необходимости.

Событие

Случай, имеющий значение для управления службой или активом.

Ошибка

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

Иерархическая эскалация

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

Влияние:

Мера серьезности инцидента.

Инцидент

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

Управление инцидентами

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

Присвоение приоритета инциденту

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

Серьезный инцидент

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

Менеджер по управлению серьезными инцидентами

Лицо, ответственное за ГРСИ и выполнение процесса MIM.

Среднее время до подтверждения (СВДП)

Мера скорости подтверждения инцидента службой поддержки.

Среднее время до обнаружения (СВДО)

Мера скорости обнаружения потенциальной угрозы службе или элементу конфигурации.

Среднее время между сбоями (СВМС)

Мера частоты сбоев службы или актива.

Среднее время до ремонта/решения/реагирования/разрешения (СВДР)

Мера скорости восстановления службы после сбоя.

Нормальная работа службы

Работа службы в соответствии с соглашением об уровне обслуживания.

Проблема

Причина или потенциальная причина одного или нескольких инцидентов.

Матрица RACI

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

Служба поддержки

Связующее звено между поставщиками услуг и пользователями организации.

Менеджер службы поддержки

Сотрудник, который следит за повседневной деятельностью службы поддержки и несет ответственность за качество ее работы.

Цель оказания услуг (SLO)

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

Соглашение об уровне обслуживания (SLA)

Соглашение между поставщиком услуг и клиентом об ожидаемом уровне услуг и ожидаемом времени их предоставления.

Срочность

Мера необходимой скорости устранения инцидента.