Major / Critical Incident Management: важная темная область. Инцидент это менеджмент


всё об ITIL, COBIT, PRINCE2 и DevOps

Во многих ITSM-проектах менеджером процесса управления инцидентами назначают начальника отдела поддержки пользователей (Service Desk). Такой вариант обладает рядом понятных минусов. Основной – риск вытеснения функций менеджера сквозного процесса функциями руководителя отдела поддержки. Как следствие, сложности во взаимодействии со второй линией, риск появления изолированных самостийных видов поддержки, с поступлением обращений мимо первой линии, без регистрации в системе автоматизации.

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

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

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

Что более всего интересно в такой схеме – кто тогда будет менеджером процесса управления проблемами? 😉

realitsm.ru

всё об ITIL, COBIT, PRINCE2 и DevOps

Уже давно бродит эта тема. А последней каплей стало то, что за последние 2-3 недели я обсуждал её 3 (!) раза с разными людьми. И так, вопрос: «Насколько осмысленно (или в каких случаях) выделять обработку сервисных запросов и управление инцидентами в отдельные процессы»?

За:

  • Соответствие ITIL v3. Строго говоря, тут надо учесть, что понятие «процесс» в ITIL v3 используется довольно неоднозначно. Но средства автоматизации ITSM-процессов «меряются» количеством процессов, а значит для вендоров – это плюс.
  • И раз уж заговорили про вендоров ITSM-продуктов, надо упомянуть, что такое деление (на инциденты и сервисные запросы) стимулируется рядом программных продуктов, в которых сервисные запросы и инциденты – это не просто разные категории одного объекта, а просто-таки разные объекты (с весьма различными возможностями по обработке).

Видимо, отсюда песня и пошла в народ. Но рассмотрим также и …

Против:

  • Рациональность организации управления. О чём, кстати, говорится в ITIL v2: «A request for new or additional service (i.e. software or hardware) is often not regarded as an Incident but as a Request for change (RFC). However, practice shows that handling of both failures in the infrastructure and of service requests are similar, and both are therefore included in the definition and scope of the process of Incident Management.». И в самом деле, зачем выделять отдельный процесс, который будет заниматься практически тем же, чем уже занимается управление инцидентами?
  • Устранение вероятных конфликтов. На практике (в проектах) граница между инцидентом и сервисным запросом вызывает массу вопросов. Обычно они выливаются в дискуссии типа «А замена картриджа принтера? А сброс забытого пароля?» и так далее. Логично предположить, что путаются не только «идеологи», но и специалисты при исполнении процесса. А значит должна быть возможность переклассификации. Но если сервисный запрос и инцидент теперь принадлежат к разным процессам управления (и не дай Бог, эти процессы управляются разными менеджерами), вопрос «что это – инцидент или сервисный запрос» превращается в вопрос «кто за это отвечает». И это не на пользу.
  • Рациональность автоматизации. В моей практике разница в обработке инцидента, поданного пользователем, и запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя (тут и разная классификация, и разные процедуры выявления / регистрации, и разные процедуры закрытия). То есть деление, выполненное в HP OpenView Service Desk, мне кажется гораздо более разумным, чем деление, например, в HP SM или в BMC Remedy ITSM Suite. Это конечно тема смежная, поскольку декомпозиция объектов в модели данных ITSM-продукта может не иметь никакого отношения к декомпозиции процессов управления. ... но всё же 🙂

Выводы делаем сами. Ну и спорим, естественно.

P.S. Хотя меня конечно так и подмывает закончить известным «Никто не сказал ни слова, выводы были ясны». © БГ.

realitsm.ru

всё об ITIL, COBIT, PRINCE2 и DevOps

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

Во-первых, годное определение значительного инцидента не так-то просто найти в литературе. Например, словарь ITIL говорит, что 

Major Incident - The highest category of impact for an incident. A major incident results in significant disruption to the business.(Значительный инцидент - Наивысшая категория влияния, применяемая инцидента. Значительный инцидент вызывает существенные потери для бизнеса.)

Если Critical или Major — действительно лишь значение параметра "Impact", то не вполне понятно, зачем ITIL рекомендует обрабатывать такие инциденты по некой специальной процедуре, а стандарт требует (ISO/IEC 20000:2011, раздел 8.1):

The service provider shall document and agree with the customer the definition of a major incident. Majorincidents shall be classified and managed according to a documented procedure. Top management shall beinformed of major incidents. Top management shall ensure that a designated individual responsible formanaging the major incident is appointed. After the agreed service has been restored, major incidents shall be reviewed to identify opportunities for improvement.

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

То есть высокая степень влияния — необходимый, но не достаточный признак для обработки инцидента как значительного. Видимо, дело здесь именно в неэффективности обычных процедур управления инцидентами и потребности в других, необычных процедурах. Этому предположению можно найти подтверждение в специализированных документах, разработанных различными государственными, городскими и другими  подобными службами, откуда, как я подозреваю, авторы ITIL и позаимствовали когда-то и само определение, и процедуры, с ним связанные. Вот, например, что говорится в Major Incident Procedure Manual, разработанном London Emergency Services Liason Panel: 

A major incident is any emergency that requires the implementation of special arrangements by one or more of the emergency services and will generally include the involvement, either directly or indirectly, of large numbers of people.

For example: 

  • The rescue and transportation of a large number of casualties; 
  • The large scale combined resources of Police, London Fire Brigade and London Ambulance Service; 
  • The mobilisation and organisation of the emergency services and support services, for example local authority, to cater for the threat of death, serious injury or homelessness to a large number of people; and 
  • The handling of a large number of enquiries likely to be generated both from the pubic and the news media usually made to the police.

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

  • Восстановление работы большого числа пользователей
  • Масштабные совместные действия Отдела ИТ, Административного отдела, Отдела ИБ, Отдела связи
  • Мобилизация и организация аварийных служб и служб поддержки, например, предоставление большого числа подменных рабочих мест, организация резервных каналов связи и электропитания и т.п. 
  • Обработка большого числа обращений со стороны пользователей и других интересующихся, обычно — через Service Desk. 

Итак, выходит, что признаками Major Incident'ов являются:

  • Существенный ущерб (тут применяются обычные критерии, те же, что при оценке ущерба от обычных инцидентов: влияние на Vital Business Functions, число и статус жертв, финансовые потери, имиджевые потери, влияние на исполнение внешних требований...)
  • Сложность и масштаб работ по управлению инцидентом (необходимость координации множества участников, часто — из смежных подразделений, а также обработка большого числа обращений, выполнение работ с множеством компонентов инфраструктуры...)

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

A major incident can be declared by any member of the emergency services which considers that any of the criteria outlined above has been satisfied. In certain circumstances such as flooding the local authority may declare a major incident.Despite the fact that what is a major incident to one of the emergency services may not be so to another, each of the other emergency services will attend with an appropriate predetermined response. This is so even if they are to be employed in a standby capacity and not directly involved in the incident.

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

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

Характерно, что "an investigation into the cause of the incident, together with the attendant hearings, may be superimposed onto the whole structure" (раздел 2.3.2 того же документа). То есть расследование причин может выполняться одновременно с инцидентом, но параллельно, не являясь частью процедуры управления самим инцидентом. Здравcтвуй, реактивное управление проблемами по ITIL. 

Вот такие наблюдения и аналогии. А что вы делаете со своими значительными инцидентами? В частности, 

  • как вы их определяете?
  • кого вы назначаете ответственным за управление каждым из них?
  • как организуете совместную работу команд?
  • как проводите Major incident review? 

 

realitsm.ru

ITIL Incident Management Software | ITSM Incident Management Software

Система управления инцидентами Freshservice - это облачное решение для обработки инцидентов внутри вашей организации. Под инцидентами понимаются все виды ошибок или перебоев в работе ИТ-службы, связанные с активами или элементами конфигураций. Важнейшей задачей в такой ситуации является восстановление нормальной работы службы, снижение последствий для бизнеса и обеспечение максимально возможного соответствия согласованному уровню обслуживания (SLA). Понимание причин возникновения крупных инцидентов является обязательным и может потребовать дополнительного анализа причин возникновения для принятия решений о дальнейших действиях. Необходимо также обладать средствами быстрого решения с возможным использованием временных обходных путей для скорейшего возобновления обслуживания.

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

Как работает инструмент управления ИТ-инцидентами Freshservice

Регистрация, отслеживание и управление инцидентами

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

Расстановка приоритетов и упорядочивание инцидентов

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

Разделение инцидентов на категории

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

База знаний известных ошибок

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

Автоматизация управления инцидентами

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

Диагностика инцидентов

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

Эскалация инцидентов

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

Разрешение инцидентов

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

Опросы удовлетворённости пользователей

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

Что ещё может система управления инцидентами

ru.freshservice.com

ИТ инцидент. Что это такое IT инцидент

ИТ инцидент что это такое

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

Комплекс мероприятий, направленный на максимально быстрое возобновление рабочего состояния системы после инцидента, называется Incident Management или IM —управление инцидентами.

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

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

  • Формирование и постоянное обновление базы данных всех инцидентов с непременной фиксацией всего пути процесса реакции.
  • Создание базы со всей доступной информацией о методах разрешения и нейтрализации инцидентов и сбоев. В структуре ITIL данный массив имеет обозначение CMDB.
  • Формирование и внедрение в структуру, созданную с целью реакции на инциденты, четкого протокола или свода правил для фиксации и обработки даных.
  • Определение с помощью инструкций SLA-механизмов, позволяющих в максимальной степени управлять влиянием инцидента на процессы в бизнес-структуре.
  • Создание и отработка на практике конкретной модели поведения всех участников информационного процесса, при возникновении так называемого главного инцидента — события, максимально критичного по масштабам и последствиям. Суть данного пункта, в определении глубины ресурсов, имеющих возможность быть задействованными в процессе реакции и нейтрализации инцидента.
  • Разработка и практическое применение механизмов своевременного информирования об этапах и статусе работ по нейтрализации инцидента всех заинтересованных субъектов. Клиенты, пользователи и персонал должны четко ориентироваться в процессе восстановительных работ и иметь четкое представление о его временных рамках.

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

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

www.stekspb.ru

Управление инцидентами | HelpIT.me

ITSM – Процесс управления инцидентами (Incident Management)

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

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

Процесс управления инцидентами (Incident Management)

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

Управление инцидентами и проблемами — понятия и принципы

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

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

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

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

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

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

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

Управление событиями и инцидентами в рамках эксплуатации услуг

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

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

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

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

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

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

Описание ключевых процессов управления ИТ-услугами

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

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

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

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

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

Что представляет собой управление инцидентами (Incident Management) по ITIL

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

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

Частью процесса управления инцидентами являются обращения пользователей в службу поддержки Service Desk. Поэтому в процесс управления инцидентами также включается обработка запросов, обеспечивающих качественное обслуживание. Это может быть изменение права доступа, предоставление различных данных, установка или же настройка стандартного ПО и многое другое. Если же обращения пользователей не входят в состав стандартного набора ИТ услуг, то они проходят обработку в рамках процесса управления изменениями.

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

Системы управления инцидентами

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

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

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

Обзор общепризнанных практик по управлению инцидентами

В настоящее время международная практика имеет достаточное количество различных нормативных документов, которые позволяют регламентировать процесс управления инцидентами в сфере информационной безопасности. При этом нужно понимать, что управление инцидентами – это не только область информационной безопасности, но и весь объем ИТ услуг, который может предоставить компания. Международные стандарты ISO 20000:2005  описывают требования к организации процесса управления инцидентами, которые происходят в ИТ инфраструктуре. В соответствии  с такими стандартами инцидент представляет собой такое событие, которое не является частью нормальной работы службы поддержки.

Для специфических вопросов службы поддержки существуют специально разработанные международные стандарты, на основе которых должны предоставлять услуги компании в области ИТ инфраструктуры. Так, ISO/IEC 27001:2005 выдвигает требования к самой системе построения управления информационной безопасности, в том числе этого могут быть требования к системе управления инцидентами. Стандарт ISO/IEC TR 18044 описывает саму инфраструктуру управления инцидентами, но только в рамках PDCA. Для этого представлены специальные спецификации для всех стадий планирования. Также такой стандарт предоставляет подробные рекомендации, которые связанны с определенными процедурами. Стандарт CMU/SEI-2004-TR-015 предлагает методологию по планированию, внедрению, модернизации и оценке процессов, связанных с управлением инцидентами. Кроме того, такой стандарт подразумевает использование критериев, которые позволяют оценивать эффективность сервисов. Также для компаний доступные подробные карты по каждому отдельному процессу. Еще один стандарт - NIST SP 800-61, он представляет собой целый сборник лучших мировых практик, которые обеспечивают эффективное построение процесса управления инцидентами.

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

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

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

Планирование и подготовка

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

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

Автоматизация процессов управления инцидентами

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

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

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

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

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

helpit.me

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

5 августа, 2013, BIS Journal №3(10)/2013

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

руководитель отдела аудита и консалтинга, CISM (ЗАО «Практика Безопасности»)

С чего начать, как организовать и чем определять эффективность менеджмента

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

 

ФУНДАМЕНТ

Сразу оговоримся: в данной статье речь идёт именно об инцидентах информационной безопасности. Сообщения (в контексте ITIL), которые принимает единый центр (ServiceDesk, Help Desk и т.д.) и которые ещё надо классифицировать, мы оставим за рамками данной статьи.

Таким образом, инцидент – любое событие, которое не является частью стандартных операций сервиса и вызывает или может вызвать прерывание обслуживания или снижение качества сервиса (Схема 1).

Схема 1.

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

Существует множество стандартов и «лучших практик» управления инцидентами. Среди них мы отметим следующие: • ISO/IEC 27001:2013 Information security management system. Requirements. В рамках данного стандарта выдвигаются общие требования построения системы управления информационной безопасности, относящиеся в том числе и к процессам управления инцидентами.

  • ISO/IEC TR 18044 Information security incident management. Данный документ описывает инфраструктуру управления инцидентами в рамках циклической модели PDCA. Даются подробные спецификации стадий планирования, эксплуатации, анализа и улучшения процесса. Рассматриваются вопросы обеспечения нормативно-распорядительной документацией, ресурсами, даются подробные рекомендации по необходимым процедурам.
  • CMU/SEI-2004-TR-015 Defining incident management processes for CISRT. Этот документ описывает методологию планирования, внедрения, оценки и улучшения процессов управления инцидентами. Основной упор делается на организацию работы CISRT (Critical Incident Stress Response Team) – группы или подразделения, обеспечивающего сервис и поддержку предотвращения, обработку и реагирование на инциденты информационной безопасности. Вводится ряд критериев, на основании которых можно оценивать эффективность данных сервисов, приводятся подробные процессные карты.
  • NIST SP 800-61 Computer security incident handling guide. Это сборник «лучших практик» построения процессов управления инцидентами и реагирования на них. Подробно разбираются вопросы реагирования на разные типы угроз, такие как распространение вредоносного программного обеспечения, несанкционированный доступ и другие.
  • ГОСТ Р ИСО/МЭК 18044 Менеджмент инцидентов информационной безопасности. Стандарт устанавливает рекомендации для менеджмента инцидентов информационной безопасности руководителям подразделений информационной безопасности, информационных систем, сервисов и сетей.

ПРОБЛЕМАТИКА

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

Схема 2.

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

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

Схема 3.

Ключевые цели данных процессов изложены на Схеме 4.

Схема 4.

С ЧЕГО НАЧАТЬ?

Прежде всего, необходимо чётко определить ответственное лицо, которое будет курировать процесс управления инцидентами. Как правило, это руководитель службы информационной безопасности (Менеджер ИБ).

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

Схема 5.

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

ОПРЕДЕЛЕНИЕ ОБЯЗАННОСТЕЙ

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

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

Должность

Роль

Обязанности

Комитет по информационной безопасности

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

  1. Ответственность за стратегию управления инцидентами.
  2. Утверждение плана управления инцидентами.
  3. Согласование исключений и отклонений.
  4. Принятие окончательных решений.

Менеджер по информационной безопасности

Руководитель группы по управлению инцидентами и связующее звено с Комитетом по ИБ

  1. Разработка, внедрение планов по управлению инцидентами.
  2. Эффективное управление рисками и инцидентами.
  3. Выполняет проактивные и активные меры по контролю уровня информационного риска.

Менеджер по реагированию на инциденты (зачастую, является Менеджером по ИБ)

Руководитель группы реагирования на инциденты

  1. Руководство реагированием на инциденты.
  2. Координация персонала для эффективного реагирования на инциденты
  3. Несёт ответственность за успешное исполнение планов по реагированию на инциденты.
  4. Презентация отчета о реагировании на инциденты Комитету по ИБ.

Член ГРИГУИ

Участие в работе группы

  1. Выполняет задачи по минимизации ущерба от инцидента.
  2. Документирует шаги, выполняемые в процессе реагирования на инцидент.
  3. Сохраняет цепочку доказательств и ведет наблюдение за процессом обработки инцидента в случае судебных разбирательств.
  4. Написание отчёта о реагировании на инцидент.

Следователь

Член ГРИГУИ

  1. Осуществляет расследование инцидента.
  2. Находит причину инцидента.
  3. Готовит отчет о расследовании.

ИТ специалист по безопасности

Член ГРИГУИ, независимый эксперт по ИБ

  1. Осуществляет комплексный анализ инцидента с точки зрения ИТ безопасности
  2. Осуществляет аудит и самооценку как проактивную меру и часть процесса управления уязвимостями.

Руководители бизнес подразделений

Владельцы бизнес процессов, активов, информационных систем

  1. Принимают решения касательно процессов/ресурсов/систем в случае наступления инцидента на основании рекомендаций ГРИГУИ.
  2. Проводят первичную оценку влияния угроз на бизнес процессы и определяют приоритет восстановления своих активов.

ИТ специалист

Сотрудник ИТ подразделения

  1. Предоставляет помощь ГРИГУИ в процессе устранения инцидента.
  2. Поддерживает информационные системы компании в соответствии с принятыми политиками и правилами.

Юрист

Сотрудник юридического подразделения

Предоставляет помощь в управлении/реагировании/расследовании инцидента при необходимости.

Сотрудник

кадровой

службы

Специалист по управлению персоналом

  1. Предоставляет помощь в управлении/реагировании/расследовании инцидента, когда сотрудник подозревается в его реализации.
  2. Встраивает в политику по управлению персоналом аспекты, касающиеся управления инцидентом (санкции для сотрудников, подозреваемых в нарушении политик либо вовлечённых в инцидент).

Пресс-секретарь

Специалист по работе со СМИ и общественностью

Предоставляет подготовленную и необходимую информацию об инциденте акционерам, СМИ и другим с целью сохранения репутации компании и сохранения бренда.

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

Сотрудник службы ИБ, внутреннего контроля либо управления рисками

  1. Вплотную работает с руководителями бизнес подразделений и руководством организации для определения рисков и управления ими.
  2. Предоставляет исходные данные (BIA, стратегию по управлению рисками) руководству ГРИГУИ.

 

Таблица 1. Должности и обязанности.

 

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

ЧТО ДАЛЬШЕ?

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

Схема 6.

НА ЧТО ОБРАТИТЬ ВНИМАНИЕ?

Для любого процесса управления существуют свои краеугольные камни – проблемы, которые коренным образом влияют на успех его реализации и эффективность работы. Исходя из опыта, мы выделили следующие проблемы, которые надо принимать во внимание при разработке и внедрении процесса управления инцидентами (Схема 7).

Схема 7.

ЗАКЛЮЧЕНИЕ

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

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

  1. Безопасность сотрудников и посетителей;
  2. Сдерживание инцидента и минимизация ущерба;
  3. Безопасность активов организации;
  4. Безопасность информационных ресурсов;
  5. Восстановление в соответствии с требованиями бизнеса;
  6. Расследование инцидента;
  7. Принятие мер по недопущению повторения инцидента.

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

journal.ib-bank.ru