Метрики по ITIL

Метрики по ITIL
Продолжаем собирать знания о подходах к измерению ИТ и ИБ. Как я уже упоминал , "универсальной" методологии не существует (ну, или я не смог ее найти), и предлагал искать здравые идеи и примеры в "лучших практиках". В частности, я уже писал про подходы к измерениям ИБ в следующих документах: ISO 27004 , ITU-T X.1208 , COBIT5 и COBIT5 for Information Security .

А эта заметка будет про ITIL v3. Приступим!

1.Важные термины
ITIL использует следующие термины и их определения:
Метрика - что-то, что измеряется и сообщается для помощи в управлении процессом, ИТ-сервисом или активностью. // Metric (Continual Service Improvement) Something that is measured and reported to help manage a Process, IT Service or Activity. See also "KPI".  
KPI - метрика, которая используется для управления процессом, ИТ-сервисом или активностью. Многие метрики могут быть измеряны, но только самые важные из них являются "KPI". KPI должны выбираться для оценки Рациональности, Результативности и Эффективности. // Key Performance Indicator (Service Design) (Continual Service Improvement) A Metric that is used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed. See also Critical Success Factor.
Критический фактор успеха (CSF) определяет критерий "успешности" Процесса, Проекта, Плана или ИТ-сервиса. KPI используются для измерения достижения CSF. // Critical Success Factor Something that must happen if a Process, Project, Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each CSF. For example a CSF of ‘protect IT Services when making Changes’ could be measured by KPIs such as ‘percentage reduction of unsuccessful Changes’, ‘percentage reduction in Changes causing Incidents’, etc. 

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

2.Примеры метрик
Вообще, если не хочется разбираться с общей методологией ITIL, то самым простым вариантом получения примеров метрия является их поиск по отдельным процессам ITSM в книге Service Operation. Вот подборка основных, полезных для ИБ:

Event Management
  • Number of events by category
  • Number of events by significance 
  • Number and percentage of events that required human intervention and whether this was performed 
  • Number and percentage of events that resulted in incidents or changes 
  • Number and percentage of events caused by existing problems or Known Errors. This may result in a change to the priority of work on that problem or Known Error
  • Number and percentage of repeated or duplicated events. This will help in the tuning of the Correlation Engine to eliminate unnecessary event generation and can also be used to assist in the design of better event generation functionality in new services 
  • Number and percentage of events indicating performance issues (for example, growth in the number of times an application exceeded its transaction thresholds over the past six months)
  • Number and percentage of events indicating potential availability issues (e.g. failovers to alternative devices, or excessive workload swapping)
  • Number and percentage of each type of event per platform or application
  • Number and ratio of events compared with the number of incidents
Incident Management
  • Total numbers of Incidents (as a control measure)
  • Breakdown of incidents at each stage (e.g. logged, work in progress, closed etc)
  • Size of current incident backlog
  • Number and percentage of major incidents
  • Mean elapsed time to achieve incident resolution or circumvention, broken down by impact code
  • Percentage of incidents handled within agreed response time (incident response-time targets may be specified in SLAs, for example, by impact and urgency codes) 
  • Average cost per incident • Number of incidents reopened and as a percentage of the total
  • Number and percentage of incidents incorrectly assigned
  • Number and percentage of incidents incorrectly categorized 
  • Percentage of Incidents closed by the Service Desk without reference to other levels of support (often referred to as ‘first point of contact’)
  • Number and percentage the of incidents processed per Service Desk agent 
  • Number and percentage of incidents resolved remotely, without the need for a visit 
  • Number of incidents handled by each Incident Model 
  • Breakdown of incidents by time of day, to help pinpoint peaks and ensure matching of resources
Problem Management
  • The total number of problems recorded in the period (as a control measure) 
  • The percentage of problems resolved within SLA targets (and the percentage that are not!) 
  • The number and percentage of problems that exceeded their target resolution times 
  • The backlog of outstanding problems and the trend (static, reducing or increasing?) 
  • The average cost of handling a problem
  • The number of major problems (opened and closed and backlog) 
  • The percentage of Major Problem Reviews successfully performed 
  • The number of Known Errors added to the KEDB 
  • The percentage accuracy of the KEDB (from audits of the database) 
  • The percentage of Major Problem Reviews completed successfully and on time
Access Management
  • Number of requests for access (Service Request, RFC, etc.) 
  • Instances of access granted, by service, user, department, etc. 
  • Instances of access granted by department or individual granting rights 
  • Number of incidents requiring a reset of access rights 
  • Number of incidents caused by incorrect access settings

3.Общий подход к измерениям
Больше всего про измерения написано в книге ITIL Continual Service Improvement (CSI), в ней упоминаются 3 типа метрик:
  • Технологические метрики (Technology metrics)– These metrics are often associated with component and application-based metrics such as performance, availability etc. 
  • Метрики процессов (Process metrics) – These metrics are captured in the form of CSFs, KPIs and activity metrics for the service management processes. These metrics can help determine the overall health of a process. Four key questions that KPIs can help answer are around quality, performance, value and compliance of following the process. CSI would use these metrics as input in identifying improvement opportunities for each process. 
  • Метрики сервисов (Service metrics) – These metrics are the results of the end-to-end service. Component metrics are used to compute the service metrics. 

ITIL определяет 4 причины для мониторинга и измерения:
  • Проверка (Validate). Производится для контроля выполнения предыдущего решения.
  • Направление (Direct). Производится для задания направление приложения усилий.
  • Оправдание (Justify). Производится с целью подтверждения того, что изменение/совершенствование необходимо.
  • Вмешательство (Intervene). Производится для определения "точки вмешательства" lzk последующих изменений и корректирующих действий.
По сути, измерять необходимо для того, чтобы своевременно выявлять тенденции и реагировать на них.

Также в ITIL CSI подробно описываются все шаги процесса совершенствования ("7-Step Improvement Process"), построенного именно на сборе и анализе результатов измерений.


Что в итоге?
  1. В ITIL, как и в COBIT5, заложена довольно толковая, на мой взгляд, идея иерархии метрик и их связи с потребностями бизнеса. В COBIT5 это привязка к каскаду целей, а в ITIL связка метрики-KPI-CSF. Кстати, примеров метрик и CSF (разного уровня) в книгах ITIL довольно много...
  2. Большим минусом является то, что процесс работы с метриками "размазан" по книге CSI. Без вдумчивого изучения этого документа разобраться с темой будет не просто. Ну, а примеры метрик, как я уже говорил, стоит искать в книге Service Operation.
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Ваша цифровая безопасность — это пазл, и у нас есть недостающие детали

Подпишитесь, чтобы собрать полную картину

Andrey Prozorov

Информационная безопасность в России и мире