Сколько в журнале не сбоев, а запросов
Руководитель ИТ приносит на совещание годовой отчёт: почти 1 500 инцидентов и больше 4 000 часов простоя. Коммерческий директор хватается за голову. Инженеры недоумевают: «Какие четыре тысячи часов? Касса поднимается за 20 минут». Знакомо?
Часть этих «инцидентов» - просьбы выдать доступ, сбросить пароль, поставить программу. Они живут в той же очереди, выполняются днями и тянут вверх все показатели. Прежде чем считать сбои, нужно убрать из журнала то, что сбоем не является.
Задача метода
До любых расчётов система отвечает на три вопроса:
- Какая часть журнала - не сбои? Запросы на обслуживание, изменения, плановые работы.
- Насколько они искажают цифры? Число сбоев, время восстановления, суммарный простой.
- Как посчитать всё остальное честно? Все разделы отчёта считаются уже без них.
Как это считается
- 1. Колонка типа заявки
Если в выгрузке есть колонка, где написано «Инцидент», «Запрос на обслуживание», «Изменение», система берёт её. Колонку узнаёт по содержимому, а не по названию: у одних она «Тип», у других «Категория» или «Issue Type».
- 2. Слова в описании
Колонки нет или тип не заполнен - система читает описание: «сбросить пароль», «выдать доступ», «новый сотрудник», «установить программу». Это оценка снизу: запрос, написанный другими словами, останется среди сбоев.
- 3. Слова о поломке важнее
«Сброс пароля не работает» или «не работает доступ к сайту» - это авария, хоть и со словами запроса. Если в тексте есть «не работает», «ошибка», «недоступен», запись остаётся сбоем. Выбросить из отчёта настоящую аварию хуже, чем оставить в нём один запрос.
- 4. Убрать из всех расчётов
Найденные записи исключаются до любых подсчётов: время восстановления, частота, Парето, прогноз считаются только по сбоям. В первом разделе отчёта сказано, сколько записей убрано и по какому признаку, с примерами - чтобы вы могли проверить.
Что бывает в живых выгрузках
Журналы пишут по-разному, и метод к этому готов:
- Тип называется «Категория» или «Issue Type»Находится по значениям. Колонка услуги при этом не путается с типом.
- Тип заполнен не вездеГде пусто, решают слова в описании, и отчёт называет эту часть оценкой.
- Изменения, проблемы, плановые работыТоже не сбои: убираются вместе с запросами и называются отдельно.
- Запрос без узнаваемых слов«Переезд рабочего места в другой кабинет» останется среди сбоев. Поэтому доля по словам всегда «не меньше».
- Сбой со словами запроса«VPN-доступ не работает у новых сотрудников» остаётся сбоем.
- Три языкаРусский, английский и сербский журналы читаются одинаково.
Проверено на пяти журналах торговой сети за год на трёх языках: в каждом около 1 450 записей и 320 подмешанных запросов. По колонке типа убраны все запросы, изменения и проблемы до единого. По словам - все запросы с узнаваемыми словами; без таких слов осталась примерно каждая седьмая просьба. Ни один из 36 сбоев со словами «доступ», «пароль», «установить» не убран. После очистки число сбоев и время восстановления совпадают с ручным подсчётом по таблице без запросов.
Что делать с результатом
| Картина в журнале | Возможные причины | Как проверить | Что делать |
|---|---|---|---|
| Запросов много (например, каждая пятая заявка - просьба о доступе) | Одна очередь на всё, отдельного типа заявки нет | Разметить руками 20 последних заявок | Завести тип «Запрос на обслуживание», показатели сбоев считать только по инцидентам |
| Тип есть, но у части заявок пуст | Поле необязательное, заполняют по настроению | Отфильтровать выгрузку по пустому типу | Сделать поле обязательным при закрытии заявки |
| Запросы висят днями | Ждут согласования, закупки, выхода сотрудника | Сравнить сроки запросов и сбоев в выгрузке | Разные сроки (SLA) для запросов и сбоев; в отчёт об авариях запросы не включать |
| Доля по словам мала, а ощущение «заваливают просьбами» есть | Запросы пишут своими словами | Сверить примеры из отчёта с 20 своими заявками | Завести тип заявки: тогда разделение точное, а не оценка |
Пример. «Тонем в авариях»
Вводные: торговая сеть, 47 магазинов, около 1 470 записей в журнале за год. Тип заявки - в колонке «Категория», но у части запросов он не заполнен.
Ситуация: руководство считает, что ИТ «тонет в авариях»: по отчёту за год почти 1 500 инцидентов и больше 4 000 часов простоя.
Что показал отчёт:
- 320 записей (22%) - запросы на обслуживание, ещё 25 - плановые работы. 47 запросов без типа найдены по словам в описании.
- Без них сбоев за год около 1 100, а не почти 1 500.
- Половина сбоев чинится быстрее 50 минут, а не 72.
- Суммарное время по заявкам - около 1 500 часов вместо 4 300: почти две трети «простоя» давали просьбы, которые выполнялись днями.
В чём польза такого результата:
- Честный отчёт руководству. Аварий на четверть меньше, простоя - почти втрое. Разговор о бюджете идёт о настоящих проблемах, а не о раздутой цифре.
- Правильные цели для инженеров. Дежурных оценивают по времени восстановления сбоев, а не по сроку выдачи ноутбука.
- Штат и дежурства. Видно, сколько работы первой линии - плановая. Её можно перенести в дневную смену или автоматизировать: сброс пароля, выдача типовых доступов.
- Точность остальных разделов. Парето, прогноз, часы сбоев считаются по настоящим авариям.
Серая полоса - показатель по всем заявкам подряд, тёмная - только по сбоям. Справа - на сколько процентов показатель был завышен.