За 364 дня в журнале зафиксировано 1383 инцидента. Находок сверх обычного ритма службы - 7, крупнейшие - ниже.
Находки отсортированы по размеру: сколько инцидентов или времени каждая даёт сверх обычного ритма службы. Первыми идут те, где разбор может сэкономить больше всего времени.
Полоса - доля всех инцидентов или суммарной длительности инцидентов сверх обычного ритма службы. Справа - сколько это за период.
Почему важно. Вероятно, время инцидентов касс набирается из частых коротких инцидентов, поэтому разбор их повторяющихся причин может дать больше, чем разбор самых долгих аварий.
При ровном распределении на них пришлось бы 23%. Больше всего - у «Кассы магазинов»: 19д 14ч 50м суммарной длительности инцидентов.
Полоса - доля сервиса в суммарной длительности инцидентов. Справа - накопленная доля, скобка - группа, о которой говорит находка. Пунктир - доля каждого при ровном распределении.
Большая часть времени инцидентов приходится на немногие сервисы, и это больше, чем дал бы случай. Подробный разбор этих сервисов может дать больше, чем одинаковое внимание ко всей инфраструктуре.
В первую очередь исследовать сервисы с наибольшим вкладом: 3 из 13. По «Кассы магазинов» - собрать инциденты в одну выборку и искать общую причину, а не причину каждого.
Откройте три любых инцидента «Кассы магазинов» за последний месяц. Если причины разные, общей проблемы, скорее всего, нет: сервис просто нагружен сильнее других. Если причина одна, это проблема, которую стоит вести отдельно до устранения.
Распределение инцидентов и их суммарной длительности по 13 сервисам, а также повторы.
Строки журнала: самые долгие инциденты «Кассы магазинов»
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| INC026059 | 10.09.2025 09:52 | Кассы магазинов | Магазин №9 | 8ч 08м |
| INC026162 | 28.09.2025 15:39 | Кассы магазинов | Магазин №34 | 7ч 58м |
| INC026236 | 09.10.2025 11:08 | Кассы магазинов | Магазин №40 | 7ч 33м |
| INC026098 | 18.09.2025 15:41 | Кассы магазинов | Магазин №6 | 5ч 38м |
| INC026400 | 08.11.2025 08:34 | Кассы магазинов | Магазин №5 | 4ч 55м |
Почему важно. Инцидентов стало больше, и частота не вернулась к прежнему уровню, поэтому причину стоит искать в изменениях этого окна.
Было 3,2 инцидента в сутки, стало 4,9. Новый уровень держится 122 дн.
Частота инцидентов выросла: с 3,2 в сутки в начале периода до 5,1 в конце. Ступенька это или постепенный рост, по данным не отличить. Если ступенька - она пришлась на 13.08.2025-24.09.2025, вероятнее всего около 01.09.2025: было 3,2 в сутки, стало 4,9. Если рост шёл постепенно, единой даты нет. С 01.09.2025 новый уровень держится уже 122 дн.
Точка - неделя. Пунктир - прежний уровень, линия - новый, полоса - где могла быть ступенька. Справа - прогноз на 30 дней с вероятным диапазоном.
Журнал не говорит, что произошло: в нём нет поля причины. Варианты: больше пользователей или точек, релиз или миграция, смена подрядчика, новые правила регистрации - например, мониторинг начал сам открывать заявки. Различить поможет журнал изменений за эти недели и колонка «кем зарегистрировано» (человек или мониторинг).
Найти, что изменилось в эти недели. Если это рост бизнеса - пересчитать дежурную смену под новый уровень. Если релиз или подрядчик - вернуть вопрос тому, кто внёс изменение.
Посмотрите, что вы делали с 13.08.2025 по 24.09.2025: релизы, переключения, новые договоры, настройка мониторинга.
Распределение инцидентов по часам и дням недели, а также изменение частоты во времени.
Почему важно. Названы конкретные объекты, поэтому разбор можно начать с них и с описаний их заявок.
«ERP-01» - 49 сбоев при 22 у типичного объекта системы; «Магазин №17» - 29 сбоев при 9 у типичного объекта системы.
Строка - объект, отметка - сбой. Красная точка - сбой в течение 7 дней после починки прошлого, тёмная черта - после перерыва. Справа - сколько сбоев на объекте и сколько у типичного объекта той же системы, или сколько сбоев вернулись.
Через квартал прислать журнал снова: на «ERP-01» должно стать меньше сбоев и возвратов в течение недели.
Распределение инцидентов и их суммарной длительности по 13 сервисам, а также повторы.
Строки журнала: сбои на «ERP-01»
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| INC026352 | 31.10.2025 16:15 | 1С:ERP | ERP-01 | 2ч 21м |
| INC026506 | 27.11.2025 10:25 | 1С:ERP | ERP-01 | 4ч 56м |
| INC026509 | 27.11.2025 16:21 | 1С:ERP | ERP-01 | 1ч 36м |
| INC026516 | 28.11.2025 12:40 | 1С:ERP | ERP-01 | 3ч 34м |
| INC026720 | 31.12.2025 13:15 | 1С:ERP | ERP-01 | 1ч 20м |
Почему важно. Если связь подтвердится, один инцидент каналов связи затрагивает и оплату, и кассы: такие инциденты стоит восстанавливать в первую очередь.
После 71 сбоев «Каналы связи магазинов» в первые 15 минут открылись 34 заявки других систем.
После сбоя «Каналы связи магазинов» в течение 15 минут открываются заявки и по другим системам: «Wi-Fi в магазинах» 14 раз из 71, «Кассы магазинов» 11 раз из 71, «Платёжный шлюз» 9 раз из 71. Случайно, при собственном ритме этих систем, совпало бы не больше 0,7 раза за весь период на каждую систему, по всем вместе - меньше 2.
Стрелка - после сбоя первой системы в течение 15 минут открывалась заявка по второй. Число у стрелки - сколько раз из всех её сбоев, «случайно» - сколько дал бы обычный ритм; чем толще стрелка, тем чаще. Связь во времени подтверждена, общая причина - гипотеза.
Заявки по «Wi-Fi в магазинах» в первые минуты после сбоя «Каналы связи магазинов» - скорее следствие, чем отдельная беда. Так бывает по трём причинам: «Wi-Fi в магазинах» работает через «Каналы связи магазинов»; обе зависят от третьего - питания, общего узла, площадки; или одну аварию завели две группы. Различит их колонка объекта (магазин, узел, площадка): совпадает объект у пары заявок - это одна авария.
Заявки по «Wi-Fi в магазинах», открытые в первые 15 минут после сбоя «Каналы связи магазинов», привязывать к её заявке как дочерние. Тогда сбои перестанут двоиться в отчётах, а чинить будут одну причину. Если «Wi-Fi в магазинах» работает через «Каналы связи магазинов», резерв нужен у «Каналы связи магазинов».
Откройте три последние аварии «Каналы связи магазинов» и заявки по «Wi-Fi в магазинах» за следующие 15 минут: тот ли это объект и закрылись ли они вместе с аварией.
Какие системы сбоят вместе: после сбоя одной в течение 15 минут открывается заявка по другой чаще, чем совпало бы случайно.
Строки журнала: «Каналы связи магазинов» и следом «Wi-Fi в магазинах»
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| INC026575 | 08.12.2025 06:20 | Каналы связи магазинов | Магазин №44 | 2ч 41м |
| INC026577 | 08.12.2025 06:31 | Wi-Fi в магазинах | Магазин №44 | 2ч 33м |
| INC026706 | 29.12.2025 21:00 | Каналы связи магазинов | Магазин №30 | 13 мин |
| INC026708 | 29.12.2025 21:10 | Wi-Fi в магазинах | Магазин №30 | 17 мин |
Почему важно. Час известен заранее, поэтому задание можно найти по расписанию и перенести или разнести по времени.
Сбои в этот час были в 31 из 52 недель; 28 из 34 - Складская система.
Чем темнее клетка, тем больше инцидентов. Справа - сумма по дню, снизу - по часу. Красная рамка - час, который выбивается из обычного ритма.
Сбои, привязанные к одному часу, обычно связаны с расписанием: ночная задача (обмен, выгрузка, резервная копия), окно релизов, плановые работы подрядчика или проверка, которая записывает найденное в своё время. Сам журнал не позволяет выбрать одно из этих объяснений.
Найдите, что запускается в это время: расписание заданий, окно релизов, работы подрядчиков. Если это задача - перенесите её или добавьте проверку перед запуском; если релизы - проверку сразу после выката.
Откройте заявки за Чт 02:00-03:00: если в них одна система и похожий текст, это одна повторяющаяся причина. Время взято как в выгрузке. Если ваша система пишет время по Гринвичу (UTC), сдвиньте часы на свой пояс.
Распределение инцидентов по часам и дням недели.
Строки журнала: инциденты в выделенный час
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| INC026389 | 06.11.2025 02:21 | Складская система | WMS-01 | 1ч 59м |
| INC026467 | 20.11.2025 02:15 | Складская система | WMS-01 | 1ч 03м |
| INC026505 | 27.11.2025 02:23 | Складская система | WMS-01 | 2ч 04м |
| INC026633 | 18.12.2025 02:04 | Складская система | WMS-01 | 1ч 34м |
| INC026634 | 18.12.2025 02:25 | Платёжный шлюз | PAY-01 | 1ч 19м |
Сбойных дней в эти даты - 22, обычный ритм дал бы около 7.
1С:ERP: сбои в последние три дня месяца - в 11 из 12 месяцев. Сбойных дней в эти даты 22, а обычный ритм дал бы около 7. Последний раз - 30.12.2025. Если ничего не менять, следующий по циклу - 29.01.2026-31.01.2026.
Каждый кружок - день цикла: красный - в этот день система сбоила, пустой - день прошёл тихо. Штрихи - сбои в другие дни. Пустой красный кружок после конца выгрузки - следующий день по циклу, если ничего не менять.
Сбои, которые возвращаются через равные промежутки, обычно связаны с расписанием или накоплением: задание раз в несколько дней, закрытие месяца и отчётность, место или память, которые заканчиваются к одному сроку, сертификат или пароль со сроком действия. Какое из объяснений верно, по журналу не определить.
Сверьте эти даты с календарём закрытия месяца, отчётности и выплат: что нагружает систему в эти дни. Дайте ей ресурс заранее и назначьте на эти даты дежурного, который знает систему.
Откройте заявки по системе 1С:ERP за даты цикла (29.09.2025, 29.10.2025, 28.11.2025, 30.12.2025): если текст один и тот же, это одна причина. Если систему между сбоями перезапускали, цикл может быть сроком, за который заканчивается ресурс.
Распределение инцидентов по часам и дням недели.
Строки журнала: сбои «1С:ERP» в дни цикла
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| INC026174 | 29.09.2025 16:54 | 1С:ERP | ERP-01 | 1ч 54м |
| INC026338 | 29.10.2025 19:44 | 1С:ERP | ERP-03 | 21 мин |
| INC026516 | 28.11.2025 12:40 | 1С:ERP | ERP-01 | 3ч 34м |
| INC026711 | 30.12.2025 09:47 | 1С:ERP | ERP-01 | 4ч 28м |
| INC026716 | 30.12.2025 15:04 | 1С:ERP | ERP-01 | 4ч 14м |
5 самых частых текстов - 33% заявок с описанием: «Касса не печатает чек, магазин №N» - 122 раза; «Касса зависает при сканировании, магазин №N» - 104 раза; «Не проходит оплата картой на кассе, магазин №N» - 95 раз; «Нет связи с ОФД, магазин №N» - 86 раз; «Ошибка при приёмке поставки» - 48 раз.
Повторяющийся текст - это симптом или сигнал мониторинга, а не причина. Если одна тревога приходит десятки раз, за ней либо одна неустранённая причина, либо порог срабатывания стоит не там.
По тексту «Касса не печатает чек, магазин №N» - проверить, чем кончаются такие заявки: закрывают без работ - поправить порог тревоги; чинят - завести одну проблему на всю серию.
Через квартал: сколько раз пришёл текст «Касса не печатает чек, магазин №N».
Какие описания в колонке «Описание» повторяются: числа и адреса не учитываются, одинаковые тексты сложены.
Столбик - сколько инцидентов закрылось за такое время (шкала логарифмическая). Красная зона - 5% самых долгих.
Рассмотреть отдельную процедуру для инцидентов, не восстановленных за 4ч 41м: по истечении этого срока - эскалация к инженеру, который вправе привлечь вендора. Порог стоит согласовать с критичностью сервисов и действующими сроками восстановления, а не переносить из статистики.
Поднимите три последних инцидента длиннее 4ч 41м и посмотрите, сколько времени ушло на диагностику, а сколько на сам ремонт. Если больше половины на диагностику - узкое место в мониторинге, а не в руках инженеров.
Строки журнала: самые долгие инциденты
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| INC025311 | 15.03.2025 22:10 | 1С:ERP | ERP-01 | 19ч 30м |
| INC026498 | 26.11.2025 06:05 | Складская система | WMS-01 | 15ч 00м |
| INC025788 | 08.07.2025 14:42 | Интернет-магазин | WEB-01 | 13ч 15м |
| INC025807 | 13.07.2025 13:43 | Wi-Fi в магазинах | Магазин №33 | 11ч 48м |
| INC025315 | 16.03.2025 19:09 | Резервное копирование | BACKUP-01 | 10ч 20м |
Сколько раз в месяц инцидент длится дольше порога. Порог дольше самого долгого инцидента в журнале - оценка по модели.
Такой случай бывает около раза в месяц. Это ваш собственный результат, а не отраслевая норма: он посчитан по вашим же инцидентам.
Написать порядок действий на инцидент дольше 6 ч и один раз провести по нему учение: кто принимает решение о переключении на резерв, кто говорит с клиентами, кто с регулятором.
Проверьте, записан ли порядок действий на случай, если сервис не восстановлен за 3 ч: кто принимает решение и кого привлекают. Если порядок эскалации заранее не определён, время восстановления может увеличиться.
Распределение самых долгих инцидентов и текущий темп появления инцидентов.
Главные сервисы восстанавливаются не медленнее остальных.
Для «Кассы магазинов» - закрепить срок восстановления, который уже держится, и следить за ним отдельно.
Через квартал: суммарная длительность инцидентов и время восстановления «Кассы магазинов».
Главные для вас сервисы, которые вы назвали: «Кассы магазинов», «Платёжный шлюз», «Интернет-магазин».
Клетка - день. Красная - день цикла, когда сбой вероятнее; рамка - день, в который есть час риска. Ожидаемое число инцидентов за эти дни - около 156 (128-185).
Действия идут в порядке размера находок. Каждое опирается на находку выше; результат виден в следующем отчёте по журналу за квартал.
Поле причины при закрытии инцидента - коротким списком
Журнал изменений за эти недели и колонка «кем зарегистрировано» (человек или мониторинг)
Описание и способ закрытия заявок, журнал проблем
Колонка объекта (магазин, узел, площадка) у заявок обеих систем
Расписание заданий, окна релизов и работ подрядчиков
Календарь закрытия периода, отчётности и регламентных заданий
Причина при закрытии - обязательным полем, коротким списком
Чего нам не хватило
Это вопросы, которые помогут разобраться, что можно предпринять в качестве дальнейших шагов.
Вы снимаете загрузку ресурсов, потери, задержки или время ответа? Выгрузки метрик мы не получили.
Повторяющиеся причины вы ведёте отдельно, как проблемы?
У вас ведётся журнал изменений? Нужны дата и время каждого изменения.
Это оценка практик, а не измерение сбоев: ступень говорит, что служба уже делает и какой шаг к следующей ступени ближайший.
Ступень 2 из 5 - «Регистрируем»
Аварии записываются. По такой истории уже видно, сколько длится восстановление, где копится время инцидентов и каких аварий ждать дальше.
Ступень посчитана только по журналу. Функции, которых в журнале не видно, пока не засчитаны. Поэтому сейчас результат - на нижней границе ступени.
Подтверждено данными: 1 из 1 ключевых функций до ступени 2 включительно.
Это то, чего не было видно в журнале и что мы попросили вас добавить. Если что-то из этого у вас уже есть, просто не попало в выгрузку, ваша ступень выше, и эти советы можно пропустить.
| Ступень | Функция | Практика ITIL 4 | Статус |
|---|---|---|---|
| 2 | Каждая авария записана | Incident management | подтверждено данными |
| 3 | У главных услуг есть владельцы | Service level management | подтверждено данными |
| 3 | Приоритет ставится по влиянию и срочности | Incident management | подтверждено данными |
| 3 | Обещаны сроки восстановления | Service level management | не видно в данных |
| 3 | Дежурство и порядок передачи аварии | Service desk | не видно в данных |
| 4 | Повторы разбираются до причины | Problem management | не видно в данных |
| 4 | Изменения записываются с типом и результатом | Change enablement | не видно в данных |
| 4 | Об аварии узнают раньше потребителя | Monitoring and event management | не видно в данных |
| 5 | У улучшений есть владелец и измеренный эффект | Continual improvement | не видно в данных |
| 5 | Показатели разбираются с потребителем | Measurement and reporting | не видно в данных |
| 5 | Известны зависимости услуг от оборудования | Service configuration management | не видно в данных |
Схема оценки - как в формальной оценке процессов (ISO/IEC 33000, метод оценки CMMI): слова людей и рабочие записи. Ответ даёт статус «заявлено», выгрузка - «подтверждено», расхождение - «спорно».
Функция подтверждена данными, если журнал не короче 90 дней и 30 записей, начало, окончание и объект аварии заполнены в 95% записей, поле самой функции (услуга, приоритет) - в 80%, и одно значение стоит не больше чем у 95% записей.
Практики и их названия - ITIL 4. Лестница опирается на ITIL 4, CMMI и ISO/IEC 33000; это не сертификация и не оценка аккредитованного оценщика.
Отчёт построен только на источниках:
| Источник | Что в нём было |
|---|---|
| Журнал инцидентов | Выгрузка из вашей системы заявок за период 364 дня, 1728 записей. Поля: время регистрации, время закрытия, сервис или узел, приоритет, описание или причина. |
| Перечень критичных сервисов | Со слов заказчика: Кассы магазинов, Платёжный шлюз, Интернет-магазин. |
| Метрические выгрузки | Не загружены. Нужны: загрузка процессора, памяти и каналов, задержка передачи пакетов, доля потерянных пакетов, вариация задержки, успешность резервного копирования и сроки сертификатов - время измерения и колонка значений по каждому показателю. (см. карту проверки ниже) |
| Журнал изменений | В журнале инцидентов 25 записей с типом «изменение» или «плановые работы». Инцидентов после изменений не больше, чем в те же часы без изменений. |
| Данные первой линии | Не загружены. Нужны: группа решения или линия поддержки по каждой заявке, признак эскалации, признак переоткрытия. (см. карту проверки ниже) |
Каждое число отчёта посчитано на одной из этих ступеней: частота и связи - по сбоям вместе с незакрытыми, время и простой - по закрытым, повторы - по сбоям на объектах.
Что смотрели. 1728 записей журнала за 364 дня.
Что это значит. Если считать все заявки подряд, сбоев выходит на 25% больше, чем было, а время восстановления смешивается со сроком выполнения запросов. Отчёт руководству по всем заявкам показывает больше аварий, чем было на самом деле.
Что делать. Считать показатели сбоев только по записям с типом инцидента в колонке «Категория» и следить, чтобы тип заполнялся всегда.
Проверьте у себя.* Отфильтруйте выгрузку по колонке «Категория»: записей с типом запроса, изменения или проблемы должно выйти 300.
Примеры строк журнала, которые были убраны
| Номер | Начало | Тип или описание |
|---|---|---|
| INC025000 | 01.01.2025 08:54:09 | Запрос на обслуживание |
| INC025002 | 01.01.2025 12:51:31 | Запрос на обслуживание |
| INC025012 | 03.01.2025 11:41:38 | Запрос на обслуживание |
| INC025062 | 17.01.2025 10:02:51 | Разблокировать учётную запись после отпуска |
| INC025076 | 20.01.2025 16:48:40 | Установить ПО для работы с электронной подписью |
Что смотрели. Полноту и связность самого журнала.
Что получили. Оценка качества данных - B (из A, B, C, D). Заполненность полей:
Что делать. Сделать поле причины обязательным при закрытии и заполнять его из короткого списка значений, а не свободным текстом: короткий классификатор причин упрощает единообразное заполнение и последующий анализ. Через квартал можно будет посчитать долю инцидентов с установленной первопричиной - сейчас данных для этого нет.
Проверьте у себя.* Откройте вашу систему заявок и посмотрите, какие поля обязательны при закрытии. Если причина не обязательна - вот почему её нет в этом отчёте.
| Поле | Заполнено |
|---|---|
| Время регистрации | 100% |
| Время закрытия | 99% |
| Сервис или узел | 100% |
| Приоритет | 100% |
| Описание или причина | 100% |
Карта содержит все виды предлагаемых на настоящий момент проверок. Для этого может потребоваться ввод дополнительных данных (см. «Подробнее» в строке).
| Покрытие | Что это даёт |
|---|---|
| Рассчитано по журналу | 7 находок и 6 показателей службы - всё, что выше и ниже в отчёте. |
| Можно уточнить вашими полями и целями | Ещё 11 показателей: коэффициент доступности по критичным сервисам, израсходованный бюджет ошибок, фактическое время восстановления против целевого, время обнаружения, время реакции и ещё 6. |
| Нужны другие источники | Ещё 3 показателя: метрика перед сбоем, доля аварийных изменений, ёмкость и здоровье. |
| Держит ли инфраструктура обещанный уровень - 1/4 | |
Простой (время, когда шёл хотя бы один инцидент)ПодробнееЧто это. Сколько всего времени ваши сервисы были недоступны за период журнала. Как считаем. Складываем длительности всех инцидентов, но параллельные интервалы склеиваем: два инцидента, шедших одновременно с 10:00 до 11:00, дают час простоя, а не два. Без склейки цифра завышается тем сильнее, чем крупнее инфраструктура. Откуда определение. Наш расчёт. Понятие простоя - от availability в глоссарии ITIL 4: способность сервиса выполнять согласованную функцию, когда она нужна. Что нужно от вас. Уже посчитано - число в строке. Если строка янтарная: нужно поле со временем закрытия инцидента, иначе длительности не существует. |
69д 12ч 24м |
Коэффициент доступности по критичным сервисамПодробнееЧто это. Доля времени, когда сервис работал, от всего времени наблюдения. Это то самое число, которое произносят как «три девятки». Как считаем. Время работы / (Время работы + Простой). По каждому названному вами сервису отдельно. Инцидент, задевший три сервиса, засчитывается каждому из трёх целиком: с точки зрения одного сервиса он лежал всё это время. Откуда определение. Формула - Google SRE Book, гл. 3 «Embracing Risk», дословно. Понятие availability - глоссарий ITIL 4. Что нужно от вас. Отметьте критичные сервисы в списке и укажите целевой уровень (например 99,9%). Считаем сразу после ответа, отчёт перезагружать не нужно. |
выберите критичные сервисы и целевой уровень |
Израсходованный бюджет ошибокПодробнееЧто это. Цель вроде 99,9% сама разрешает какое-то время простоя. Это разрешённое время и есть бюджет. Показатель говорит, сколько бюджета вы уже потратили. Как считаем. Допустимый простой = длина вашего периода x (1 - цель). Израсходовано = фактический простой / допустимый простой x 100%. Период берём фактический - ровно столько дней, сколько в вашем журнале, без округления до месяца. Значение выше 100% значит, что бюджет исчерпан и цель за период не выполнена. Откуда определение. Google SRE Book, гл. 3: бюджет - это разница между целью и фактическим временем работы, остаток «ненадёжности» на период. Что нужно от вас. Одну цифру - целевую доступность. Без цели показателя не существует: бюджет отсчитывается от обещания, а не от данных. |
определите цель - без неё показателя не существует |
Фактическое время восстановления против целевогоПодробнееЧто это. RTO - срок, за который сервис обязан вернуться в строй после аварии. Показатель отвечает, в какой доле случаев вы в этот срок уложились. Как считаем. Доля инцидентов с длительностью не больше вашей цели, плюс худший случай за период - самый долгий инцидент. Худший случай важнее средних: план непрерывности проверяется на плохом дне, а не на обычном. Откуда определение. ISO 22300:2021 (словарь к ISO 22301): RTO - «период времени после инцидента, в течение которого продукт, услуга или деятельность возобновляются, а ресурсы восстанавливаются». Стандарт платный, номер пункта мы не подтверждали и поэтому на него не ссылаемся. Что нужно от вас. Целевое время восстановления в часах. Если оно разное для разных сервисов - назовите цель для самого критичного. |
определите цель - без неё показателя не существует |
| Как быстро вы чините - 1/6 | |
Время восстановления сервисаПодробнееЧто это. Сколько времени проходит от регистрации инцидента до его закрытия. Как считаем. Даём три числа сразу: медиану, среднее и P95. Медиана - обычный день: половина инцидентов чинится быстрее. Среднее тянут вверх редкие долгие случаи. P95 - «хвост»: дольше него только каждый двадцатый инцидент. Одно среднее без хвоста скрывает именно те случаи, из-за которых вам звонит бизнес. Откуда определение. ITIL 4 называет это MTRS, mean time to restore service: «показатель того, как быстро сервис восстанавливается после отказа». В словаре надёжности IEC 60050-192 то же число зовётся MTTR (термин 192-07-23). Что нужно от вас. Уже посчитано. Если строка янтарная: нужно поле со временем закрытия инцидента. |
54 мин / 1ч 28м / 4ч 41м - медиана / среднее / P95 |
Время обнаруженияПодробнееЧто это. Сколько инцидент шёл до того, как вы о нём узнали. Это слепая зона: сервис уже лежит, а заявки ещё нет. Как считаем. Фактическое начало инцидента минус время регистрации в системе. Из одного времени регистрации это не выводится ни при каких допущениях: журнал знает момент, когда о проблеме сообщили, а не момент, когда она началась. Откуда определение. Стандарта нет. MTTD - устоявшаяся практика управления инцидентами, и мы говорим об этом прямо, а не выдаём практику за норму. Что нужно от вас. Целью не лечится - нужен экспорт с отдельным полем «фактическое начало» (в системах его зовут по-разному: start time, occurred at, время возникновения). Догрузите такой экспорт по той же ссылке, и строка посчитается. |
нужно заполненное поле «фактическое начало отдельно от времени регистрации» в базе |
Время реакцииПодробнееЧто это. Сколько заявка ждала, пока за неё возьмётся человек. Показывает работу очереди и дежурной смены, а не сложность самой поломки. Как считаем. Время принятия в работу минус время регистрации. Откуда определение. Стандарта нет. MTTA - практика сервис-деска. Что нужно от вас. Нужен экспорт с полем «время принятия в работу» (взят в работу, назначен, acknowledged - смотря как называется у вас). |
нужно заполненное поле «время принятия в работу» в базе |
Доля закрытых в срокПодробнееЧто это. Какая часть инцидентов уложилась в согласованные с бизнесом сроки. Как считаем. По каждому приоритету отдельно: сколько инцидентов этого приоритета закрыто не позже вашего норматива. Сводить приоритеты в одно число нельзя - норматив у них разный, и общая цифра скрыла бы просрочку по критичным. Считаем, только если приоритет заполнен не менее чем у 80% записей; ниже этого порога цифра говорит о качестве заполнения журнала, а не о работе службы. Откуда определение. ITIL 4: service level - метрики ожидаемого или достигнутого качества; SLA - документированное соглашение о требуемых услугах и ожидаемом уровне обслуживания. Что нужно от вас. Целевые сроки по каждому приоритету в минутах (например: критичный - 60 мин, высокий - 240 мин, обычный - 1440 мин). Если приоритет в журнале не ведётся или заполнен реже, чем у 80% записей: сначала нужен экспорт с этим полем - цель без приоритета применить не к чему. |
определите цель - без неё показателя не существует |
Доля решённых с первого разаПодробнееЧто это. Какая часть инцидентов после закрытия не открылась заново. Прямая мера качества починки: заявку закрыли или проблему решили. Как считаем. Доля инцидентов, у которых нет признака переоткрытия. Откуда определение. Стандарта нет, это практика сервис-деска. Что нужно от вас. Нужен экспорт с полем «переоткрыт» либо с историей смены статусов - по истории мы восстановим факт возврата в работу сами. |
нужно заполненное поле «переоткрыт» в базе |
Доля решённых на первой линииПодробнееЧто это. Какая часть инцидентов закрыта без передачи специалистам. Показывает, сколько работы уходит наверх и насколько загружены дорогие руки. Как считаем. Доля инцидентов, закрытых той же группой, что их приняла. Откуда определение. Стандарта нет. ITIL 4 определяет только escalation и service desk; самой метрики в глоссарии нет. Что нужно от вас. Нужен экспорт с полем «группа решения» или «линия поддержки». |
нужно заполненное поле «группа решения» в базе |
| Как часто и что именно ломается - 4/9 | |
Как часто случаются инциденты и как часто отказывает сервисПодробнееЧто это. Как часто что-то ломается во всей компании и как часто отказывает каждый из самых частых сервисов. Как считаем. Период, делённый на число инцидентов: для всей компании - общая частота, для сервиса - наработка на отказ. Считаем отказы услуги, а не паспортную надёжность оборудования. Откуда определение. ITIL 4, MTBF: «показатель того, как часто сервис или иной конфигурационный элемент отказывает». IEC 60050-192, термин 192-05-13, mean operating time between failures. Что нужно от вас. Уже посчитано. |
Инцидентов: 1369, в среднем один раз в 6ч 23м. Чаще всего: Кассы магазинов - раз в 21ч 29м; Интернет-магазин - раз в 2д 05ч 38м; Мобильное приложение - раз в 2д 23ч 04м |
Концентрация длительности инцидентов по сервисамПодробнееЧто это. Отвечает, собрана ли длительность ваших инцидентов в нескольких точках или распределена ровно. Если собран - работа по короткому списку даёт непропорционально большой эффект. Как считаем. Сортируем сервисы по вкладу в суммарную длительность инцидентов и смотрим, какую долю дают верхние. Дополнительно считаем коэффициент Джини - меру неравенства вклада: 0 значит «все сервисы вносят поровну», ближе к 1 - «почти всё приходится на единицы». Откуда определение. Наш расчёт (анализ Парето). Заимствованных норм нет: сравниваем вашу инфраструктуру с ней же, а не с чужим средним. Что нужно от вас. Уже посчитано. Если строка янтарная: нужно поле «сервис или узел» - без него длительность инцидентов не к чему привязать. Если серо-синяя: расчёт доступен в расширенном разборе. |
3 сервиса из 13 - 53% суммарной длительности инцидентов |
Возвраты на тот же объектПодробнееЧто это. Какая часть сбоев вернулась на тот же объект - сервер, КЕ, магазин - в течение недели после починки, и больше ли это, чем дал бы случай. Как считаем. Ключ - объект вместе с системой: «касса магазина 12», а не «кассы». Заявки одной аварии на объекте (открыта, пока идёт прошлая, или в течение часа после её закрытия) считаем одним сбоем. Возврат - сбой в течение 7 суток после конца прошлого. Рядом - доля, которую дал бы случай, если бы все объекты системы ломались одинаково. Объект называем, если он ломается чаще остальных объектов своей системы или сбои идут сериями чаще, чем дал бы ритм остальных; обе проверки - с поправкой на число объектов. Тот же объект - ещё не та же причина: в ITIL 4 повтор указывает на проблему, «причину или потенциальную причину одного или нескольких инцидентов». Откуда определение. Наш расчёт; трактовка - ITIL 4, problem. Что нужно от вас. Уже посчитано. Если строка янтарная: нужна колонка объекта - сервер, КЕ или магазин, заполненная хотя бы у пятой части заявок. Если серо-синяя: доступно в расширенном разборе. |
34% сбоев вернулись на тот же объект в течение 7 дней после починки; если бы объекты ломались одинаково - около 33% |
Метрика перед сбоемПодробнееЧто это. Какая метрика мониторинга - загрузка процессора, память, трафик, диск - заранее отклоняется от обычного перед сбоями, и примерно за сколько до них. Как считаем. Журнал и выгрузку метрик ставим на одну ось времени. «Обычное» для метрики - её уровень в тот же час суток, будни и выходные отдельно. Смотрим окна 15 мин - 1 ч, 1-6 ч и 6-24 ч до заявки и сравниваем, как часто метрика была выше или ниже обычного перед сбоями и в те же часы других дней. Находка - только если перед сбоями это бывает заметно чаще, в разные дни и с поправкой на число рядов. Заявку, которую открыла тревога по той же метрике, предвестником не считаем. Откуда определение. Наш расчёт; проверен на искусственных месяцах и годах мониторинга с известным ответом. Что нужно от вас. Уже посчитано. Если строка серая: пришлите вместе с журналом выгрузку метрик мониторинга за тот же период. Если янтарная: общего периода или сбоев в нём мало - нужно от 14 дней и от 8 сбоев. |
нужен другой источник данных: выгрузка метрик мониторинга за тот же период (Zabbix, Grafana, Prometheus) |
| Что стоит за сбоями | нужно заполненное поле «причина сбоя (короткий список)» в базе |
Разбивка по приоритетамПодробнееЧто это. Как инциденты распределены по классам важности. Как считаем. Считаем долю каждого приоритета, но только если поле заполнено не менее чем у 80% записей. При меньшем заполнении разбивка описывает дисциплину заполнения журнала, а не реальную картину поломок, и мы её не печатаем. Смотреть надо на две вещи. Первая - доля высших приоритетов: если критичных больше четверти потока, приоритет ставят не по влиянию на бизнес, а по громкости заявителя, и срочный маршрут перестаёт быть срочным. Вторая - совпадает ли она с разделом «как быстро вы чините»: критичные, которые чинятся не быстрее обычных, означают, что приоритет в журнале есть, а в работе смены его нет. Откуда определение. ITIL 4, incident: незапланированное прерывание услуги или снижение её качества. Шкалы приоритетов стандарт не задаёт - берём вашу. Что нужно от вас. Уже посчитано. Если строка янтарная: нужен экспорт с полем «приоритет» либо его заполнение. |
1 - КРИТИЧЕСКИЙ - 53 (4%); 2 - ВЫСОКИЙ - 270 (20%); 3 - СРЕДНИЙ - 667 (48%); 4 - НИЗКИЙ - 393 (28%) |
Доля инцидентов с установленной первопричинойПодробнееЧто это. Какая часть инцидентов разобрана до причины, а не просто закрыта после восстановления сервиса. Как считаем. Доля записей с заполненной первопричиной или со связью с проблемой. Откуда определение. ITIL 4: problem - причина или потенциальная причина инцидентов; known error - проблема, которая проанализирована, но не устранена (наличие обходного решения при этом не обязательно). Что нужно от вас. Поле в вашем журнале не ведётся. Само по себе это уже вывод: повторяющиеся инциденты закрываются без разбора причины, значит они вернутся. Чтобы увидеть число - нужен экспорт с полем «первопричина» или со связью инцидентов с проблемами. |
поле не ведётся - вероятно, повторяющиеся инциденты закрываются без разбора причины |
Доля аварийных измененийПодробнееЧто это. Какая часть изменений вносится в режиме «надо было вчера», без обычного согласования. Высокая доля означает, что плановый процесс не поспевает за реальностью. Как считаем. Доля аварийных изменений от всех изменений за период. Откуда определение. ITIL 4: emergency change - изменение, которое «должно быть внедрено как можно скорее»; standard change - заранее авторизованное изменение с низким риском. Что нужно от вас. Полем в журнале инцидентов это не лечится: знаменатель здесь - изменения, а не инциденты. Нужна выгрузка из журнала изменений за тот же период. Она же уточнит строку «доля инцидентов со следом изменения» - сейчас там нижняя оценка по тексту описаний. |
нужен другой источник данных: журнал изменений |
Доля инцидентов по вине внешних поставщиковПодробнееЧто это. Какая часть поломок пришла извне вашего периметра - от провайдера, вендора, подрядчика. Это цифра для разговора с поставщиком, а не с вашей командой. Как считаем. Доля инцидентов с указанием внешней виновной стороны. Откуда определение. ITIL 4, практика управления поставщиками (supplier management practice). Что нужно от вас. Нужен экспорт с полем «виновная сторона» или «поставщик». |
нужно заполненное поле «виновная сторона» в базе |
| Ёмкость и здоровье | |
| Здесь должны быть показатели состояния ресурсов: загрузка, задержка и потери в сети, резервное копирование, сроки сертификатов, устаревшие компоненты. В журнале инцидентов их нет - нужна отдельная выгрузка метрик за тот же период: время измерения и колонка значений по каждому показателю. | |
Обозначения: посчитанонужно ваше поле/цельнужен другой источник данныхдоступно в расширенном разборе
Итого: 6 показателей посчитано, 11 ждут вашего решения или заполненного поля, 8 требуют других данных.
Каждая строка со статусом «нужно ваше поле/цель» - это возможность улучшить отчёт. Это конкретное имя поля где-то в вашей базе.
В основном тексте отчёта названий методов мы не показывали намеренно - чтобы не перегружать.
| Что в отчёте | Как посчитано |
|---|---|
| Простой | Время, когда шёл хотя бы один инцидент: пересекающиеся интервалы объединяются перед суммированием, иначе параллельные инциденты считаются дважды |
| Время восстановления сервиса | Медиана, среднее и 95-й перцентиль длительностей. ITIL 4 называет этот показатель MTRS (mean time to restore service); в словаре надёжности IEC 60050-192 то же число зовётся MTTR |
| Наработка на отказ | Для всей компании - период, делённый на число инцидентов: как часто что-то ломается. Для сервиса - период, делённый на его инциденты: это и есть наработка на отказ (ITIL 4: MTBF). Считаем отказы услуги, а не паспортную надёжность оборудования |
| Концентрация длительности инцидентов | Суммирование длительности инцидентов по сервисам. Отдельно - коэффициент Джини: насколько по-разному длятся сами инциденты. У вас 0,53: 0 - все инциденты длятся одинаково, выше 0,6 - основную длительность дают немногие |
| Возвраты на тот же объект | Тот же объект той же системы в течение 7 суток после починки; заявки одной аварии - один сбой; сравнение со случаем, где объекты системы ломаются одинаково |
| Доля запросов на обслуживание | По колонке типа заявки, где она есть и заполнена; иначе по фразам штатного обслуживания в описании (выдать доступ, сбросить пароль, завести учётную запись), если рядом нет слов о поломке. Найденные записи убраны из всех расчётов; найденное по словам - оценка снизу |
| Связи между системами | Заявка другой системы в течение 15 минут после сбоя - против её собственного ритма (уровень за соседние недели, день недели, час); поправка на число проверенных пар (247); связь держится без двух самых загруженных дней, дни общих бурь исключены |
| Что стоит за сбоями | Подсчёт по вашей колонке причин: случаи и сумма длительностей по каждой причине; пустые, «прочее» и «не выяснена» в счёт не идут. Описания: числа и адреса не учитываются, одинаковые тексты сложены; тексты с почтой, телефоном и подписью не показываются |
| Смена частоты 01.09.2025 | Сравнение средних по неделям до и после каждой возможной даты с поправкой на разброс неделя к неделе; сила сигнала 5,4 при пороге 3,3 (на обычных годах порог превышается примерно в 3-5% случаев) |
| Вероятность долгого инцидента | Обобщённое распределение Парето по превышениям порога (Peaks-Over-Threshold). Параметр формы ξ = +0.12, 95% доверительный интервал [-0.07, +0.27]; 137 превышений порога 3.4 ч |
| Прогноз частоты | Средняя частота текущего режима, без продления тренда; интервал предсказания по разбросу ваших недель и месяцев (Пуассон или, если сбои идут волнами, отрицательное биномиальное) |
| Оценка качества данных | Заполненность обязательных полей, связность времён, доля исключённых записей |
Код проверил, что числа и даты текста взяты из расчёта движка, а отдельный второй проход ИИ сверил, что каждое число относится к тому же показателю; расхождений не найдено.
Кривая заметно отклонилась от прямой - подтверждение того, что инциденты длятся по-разному: 41,5% из них дают 80% суммарной длительности (Gini=0,534). Прямая линия означала бы, что все инциденты длятся одинаково.
Формулировки - по официальному глоссарию ITIL 4.
| Термин | Значение |
|---|---|
| Событие | Любое изменение состояния, значимое для управления услугой |
| Инцидент | Незапланированное прерывание услуги или снижение её качества |
| Проблема | Причина или потенциальная причина одного или нескольких инцидентов |
| Известная ошибка | Проблема, которая проанализирована, но не устранена |
| Обходное решение | Решение, снижающее или устраняющее влияние инцидента, пока полного нет |
| Изменение | Добавление, правка или удаление чего-либо, что может повлиять на услуги |
| Запрос на обслуживание | Запрос пользователя на действие, согласованное как штатная часть услуги. Не инцидент |
| Время восстановления сервиса | Насколько быстро услуга восстанавливается после отказа |
| Длительность инцидента | Время от открытия до закрытия одного инцидента. Типичное значение (медиана) - время восстановления |
| Суммарная длительность инцидентов | Длительности всех инцидентов, сложенные вместе; одновременные посчитаны каждый. По ней считаются доли сервисов и причин |
| Простой | Время, когда шёл хотя бы один инцидент; одновременные посчитаны один раз |
* Эти задачи могут быть сделаны точнее и качественнее при нашем участии.
Что ещё можем сделать: разобрать этот отчёт вместе с вами, провести health-check службы (разовый аудит: где простой, что изменилось, чего ждать дальше) или глубже исследовать ваши данные под ваш вопрос. Это платная работа инженера OpsLab, по договорённости; напишите на hello@opslab.consulting.