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

Введем определения и сделаем несколько оговорок.

1. Процесс устранения инцидентов достаточно нагружен. Он получает на вход порядка 1000 инцидентов в день.
2. За поддержку каждой ИТ-услуги (в том числе и за устранение инцидентов) отвечает выделенная группа поддержки постоянной численности.
3. Алгоритм устранения каждого вида инцидентов заранее известен (иначе мы считаем, что столкнулись с проблемой, которая обрабатывается отдельным бизнес-процессом и время ее трансформации в известную ошибку предсказать довольно сложно).
4. Каждая из работ в рамках устранения инцидента описана и нормирована по времени.
5. ИТ-услуга обеспечивается несколькими поддерживающими услугами, за каждую из которых отвечает своя группа поддержки постоянной численности.
6. В зависимости от того, в какой поддерживающей услуге кроется причина инцидента в ИТ-услуге, к решению инцидента привлекается соответствующая группа поддержки.
7. Работы внутри группы поддержки оформляются нарядами на работу. У наряда на работу есть фиксированная трудоемкость (см. пункт 3).
8. Обращение пользователя в ИТ, а также обращения сотрудников одной группы поддержки в другую с требованием выполнения определенной работы оформляются обращениями. У обращения есть крайний срок.

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

1. Инцидент регистрируется, классифицируется (ИТ-услуга, симптомы) и попадает в очередь инцидентов группы поддержки ИТ-услуги в виде наряда на работу по анализу симптомов инцидента (для простоты не будем учитывать такую важную функцию, как приоритезация).
2. Анализируются симптомы инцидента и определяется возможность устранения силами группы поддержки ИТ-услуги.
3. Если устранение силами группы поддержки ИТ-услуги невозможно (т.е. причина инцидента связана с какой-либо поддерживающей услугой), то регистрируется инцидент по поддерживающей услуге и процесс рекурсивно повторяется.
4. Между подразделениями существуют договоренности (OLA), касающиеся в том числе и сроков устранения инцидентов.
5. Если инцидент устраняется силами группы поддержки ИТ-услуги, то работы по его устранению оформляются в виде нарядов (одного или нескольких, создаваемых последовательно).

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

Осталось вычислить время реакции. Остановимся подробнее на алгоритме расчета.

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

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

Разобьем сутки на I равных интервала таким образом, чтобы изменением скоростей поступления и выполнения нарядов внутри i-го интервала можно было пренебречь. Обозначим скорость поступления нарядов внутри i-го интервала за vi, скорость выполнения нарядов внутри i-го интервала — за v’i, а длину интервала за T. Скорость измеряется в человеко-часах (ч-ч) в единицу времени.

Зафиксируем момент времени в начале i-го интервала и обозначим длину очереди нарядов через Li. Тогда время, через которое будет выполнен последний наряд в данной очереди вычисляется, как Ri = Li/v’i.

Ri — это время реакции на наряд в i-ом интервале времени. Кстати, Li = L(i-1) + vi х T — v’i х T, таким образом, для того, чтобы очередь нарядов не возрастала от интервала к интервалу, необходимо обеспечить равенство скорости выполнения нарядов скорости поступления. А вообще, заняться уменьшением скорости поступления нарядов, вызванных инцидентами путем устранения проблем.

Нет коментариев