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

Где же искать ответ? В книге ITIL Service Design в главе про управление доступностью есть любопытный раздел «Expanded incident lifecycle». Это метод, описывающий основные этапы решения инцидента с целью последующего анализа, за счёт чего можно сократить время обработки на каждом из этапов – быстрее выявлять инцидент, быстрее выполнять диагностику и так далее. Кроме того, в ITIL Service Operations конечно говорится о том, что косвенное влияние на сокращение времени решения инцидентов оказывает управление проблемами – за счёт определения наиболее эффективных обходных решений повторяющихся инцидентов. Но, как мне кажется, влияние управления проблемами на скорость решения инцидентов весьма недооценено.

Вот иллюстрация. Пусть у нас есть инженер второй линии поддержки, который в среднем тратит на решение одного инцидента 20 минут. Для простоты предположим, что он в основном занят именно устранением инцидентов. Тогда за 8 рабочих часов он теоретически может решить до 24 инцидентов. И если бы они поступали равномерно и последовательно, то при количестве инцидентов от 1 до 24 среднее время решения оставалось бы равным 20 минутам, что очень хорошо. Но дело в том, что они поступают неравномерно (вспомните стохастические отклонения у Голдратта). Распределение инцидентов по времени дня обычно имеет вид кривой с одним или двумя пиками (отчего она называется верблюдом) с большей нагрузкой в первой половине дня. Это значит, что вновь поступающие инциденты будут попадать в очередь и ждать, пока инженер разрешит инциденты, открытые ранее. В наихудшем случае (если все инциденты пришли одновременно утром) это приведёт к среднему времени решения … 4 часа 10 минут. Те же самые 24 инцидента! А если бы инцидентов за день приходило не 24, а 12? Тогда с теми же показателями производительности (в наихудшем предположении, что все инциденты пришли одновременно) среднее время решения будет только 2 часа 10 минут. То есть в два раза меньше.

Отсюда вывод, что из-за неравномерности поступления инцидентов, их среднее время решения зависит не только от производительности персонала (а значит эффективности выявления, диагностики и так далее), но и от общего количества инцидентов. Я не знаю, как управлять равномерностью поступления инцидентов. Но знаю, как сокращать их количество – за счёт организации и исполнения процесса управления проблемами.

Да, это непростой процесс. Прежде всего, по двум причинам:

• триггер для запуска процесса находится внутри ИТ-подразделения (то есть пока не захотим, он исполняться не начнёт);
• многие проблемы для диагностики и решения требуют не просто поочерёдной работы нескольких команд (как в случае решения инцидента), а скоординированной, совместной работы, например разработчиков, прикладников, сетевиков и группы, отвечающей за сервера. Это не так-то просто организовать.

Но это очень важный процесс. В нашей проектной практике мы обычно рекомендуем закладывать его основы сразу при организации управления инцидентами, не дожидаясь накопления «волшебной» статистики по инцидентам за год. Ценность такой статистики для выявления проблем, по-моему, сильно преувеличена. А вот влияние процесса управления проблемами на скорость решения инцидентов – напротив – недооценено.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую