Как провести анализ причин после серьезного инцидента

Основная бизнес-система терпит фиаско второй раз за несколько недель, запросы пользователей не выполняются, а процесс восстановления не укладывается в заданные сроки. Знакомо?

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

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

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

В данной статье приводится проверенная на практике стратегия развития и внедрения процесса анализа инцидентов:

Исследование Сопутствующих Причин

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

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

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

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

Грамотное совещание по анализу причин ставит на повестку дня такие вопросы как:

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

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

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

    Структура процесса постанализа инцидента

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

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

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

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

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

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

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

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

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

    Фокусирование на процессе анализа инцидента

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

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

    Регистрация хронологии инцидента

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

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

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

    Построение плана действий

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

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

    Постанализ в культуре управления сервисом

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

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

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

    Брайн Коррингтон- президент и главный исполнительный директор консалтинговой компании ИТ Codesic Consulting, штабквартира которой находится в Кирклэнде, штат Вашингтон, США. Более 20 лет Коррингтон руководит производственными ИТ проектами, разрабатывает технологические практики и стратегические взаимоотношения с заказчиками

    Brian Corrington, 7 ноября 2005. Перевод Виталия Фролова
    URL: http://www.itsmwatch.com/itil/article.php/3562136

  • Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

    Комментарии закрыты.