Розничная сеть · Отчёт · 2026-10-01 10:10 UTC
Конфиденциально
Отчёт построен только на источниках:
| Источник | Что в нём было |
|---|---|
| Журнал инцидентов | Выгрузка из вашей системы заявок за период 364 дня, 1728 записей. Поля: время регистрации, время закрытия, сервис или узел, приоритет, описание или причина. |
| Перечень критичных сервисов | Со слов заказчика: Кассы магазинов, Платёжный шлюз, Интернет-магазин. |
| Метрические выгрузки | Не загружены. Нужны: загрузка процессора, памяти и каналов, задержка передачи пакетов, доля потерянных пакетов, вариация задержки, успешность резервного копирования и сроки сертификатов - время измерения и колонка значений по каждому показателю. (см. карту проверки ниже) |
| Журнал изменений | Не загружен. Нужны: дата и время изменения, тип (штатное или аварийное), затронутый сервис, результат. (см. карту проверки ниже) |
| Данные первой линии | Не загружены. Нужны: группа решения или линия поддержки по каждой заявке, признак эскалации, признак переоткрытия. (см. карту проверки ниже) |
За 364 дня суммарное время недоступности составило 1668.4 часа.
С середины сентября средний темп инцидентов вырос с 3.23 до 4.91 в день (+52.2%) и держится. если темп сохранится, за следующие 30 дней ожидается около 155 инцидентов (128-185).
Наибольшая срочность - регулярные инциденты 1С:ERP в последние 3 дня месяца: следующий риск - 29-31 января 2026 года.
Карта содержит все виды предлагаемых нами проверок. Их наполнение зависит от ряда показателей, которые можно добавить.
Обозначения: посчитанонужно ваше поле или ваша цельнужен другой источник данныхдоступно в расширенном разборе
| Держит ли инфраструктура обещанный уровень - 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/8 | |
Как часто случаются инциденты и как часто отказывает сервисПодробнееЧто это. Как часто что-то ломается во всей компании и как часто отказывает каждый из самых частых сервисов. Как считаем. Период, делённый на число инцидентов: для всей компании - общая частота, для сервиса - наработка на отказ. Считаем отказы услуги, а не паспортную надёжность оборудования. Откуда определение. 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: незапланированное прерывание услуги или снижение её качества. Шкалы приоритетов стандарт не задаёт - берём вашу. Что нужно от вас. Уже посчитано. Если строка янтарная: нужен экспорт с полем «приоритет» либо его заполнение. |
3 - СРЕДНИЙ - 667 (48%); 4 - НИЗКИЙ - 393 (28%); 2 - ВЫСОКИЙ - 270 (20%); 1 - КРИТИЧЕСКИЙ - 53 (4%) |
Доля инцидентов с установленной первопричинойПодробнееЧто это. Какая часть инцидентов разобрана до причины, а не просто закрыта после восстановления сервиса. Как считаем. Доля записей с заполненной первопричиной или со связью с проблемой. Откуда определение. ITIL 4: problem - причина или потенциальная причина инцидентов; known error - проблема, которая проанализирована, но не устранена (наличие обходного решения при этом не обязательно). Что нужно от вас. Поле в вашем журнале не ведётся. Само по себе это уже вывод: повторяющиеся инциденты закрываются без разбора причины, значит они вернутся. Чтобы увидеть число - нужен экспорт с полем «первопричина» или со связью инцидентов с проблемами. |
поле не ведётся - значит повторяющиеся инциденты закрываются без разбора причины |
Доля аварийных измененийПодробнееЧто это. Какая часть изменений вносится в режиме «надо было вчера», без обычного согласования. Высокая доля означает, что плановый процесс не поспевает за реальностью. Как считаем. Доля аварийных изменений от всех изменений за период. Откуда определение. ITIL 4: emergency change - изменение, которое «должно быть внедрено как можно скорее»; standard change - заранее авторизованное изменение с низким риском. Что нужно от вас. Полем в журнале инцидентов это не лечится: знаменатель здесь - изменения, а не инциденты. Нужна выгрузка из журнала изменений за тот же период. Она же уточнит строку «доля инцидентов со следом изменения» - сейчас там нижняя оценка по тексту описаний. |
нужен другой источник данных: журнал изменений |
Доля инцидентов по вине внешних поставщиковПодробнееЧто это. Какая часть поломок пришла извне вашего периметра - от провайдера, вендора, подрядчика. Это цифра для разговора с поставщиком, а не с вашей командой. Как считаем. Доля инцидентов с указанием внешней виновной стороны. Откуда определение. ITIL 4, практика управления поставщиками (supplier management practice). Что нужно от вас. Нужен экспорт с полем «виновная сторона» или «поставщик». |
нужно заполненное поле «виновная сторона» в базе |
| Ёмкость и здоровье | |
| Здесь должны быть показатели состояния ресурсов: загрузка, задержка и потери в сети, резервное копирование, сроки сертификатов, устаревшие компоненты. В журнале инцидентов их нет - нужна отдельная выгрузка метрик за тот же период: время измерения и колонка значений по каждому показателю. | |
Итого: 6 показателей посчитано, 10 ждут вашего решения или заполненного поля, 8 требуют других данных.
Каждая строка со статусом «нужно ваше поле или ваша цель» - это не наш предел, а конкретное имя поля в вашей базе. Пришлите поле «время принятия в работу» - получите время реакции отдельно от времени ремонта, и станет видно, где вы теряете больше: пока диспетчер ищет свободного инженера или пока инженер чинит.
Чего нам не хватило
Ниже - то, что закрыло бы больше всего строк карты. Ответ ни к чему вас не обязывает.
Выгрузки метрик мы не получили. Вы снимаете загрузку ресурсов, потери, задержки или время ответа?
Причина в записях не указана. Повторяющиеся причины вы ведёте отдельно, как проблемы?
Журнала изменений в присланных данных не было. Он у вас ведётся, с датой и временем каждого изменения?
Ступень 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; это не сертификация и не оценка аккредитованного оценщика.
Что смотрели. 1728 записей журнала за 364 дня.
Что получили. Из 1728 записей журнала 320 (18%) по колонке «Категория» - запросы на обслуживание, а не сбои; у 45 из этих запросов тип не заполнен, их мы узнали по словам в описании - это оценка; ещё 25 - изменения, проблемы или плановые работы. Мы убрали все эти записи из всех расчётов отчёта: ниже разобраны 1369 инцидентов, это 3.8 в сутки. Суммарно сервисы были недоступны или работали хуже нормы 69д 12ч 24м - это сумма по всем объектам, а не время, когда лежало всё сразу.
Полоса - сколько записей журнала каждого рода. Оранжевые мы убрали из всех расчётов отчёта: это не сбои, и срок их выполнения не попадает во время восстановления.
Строки журнала, которые мы убрали
| Номер | Начало | Тип или описание |
|---|---|---|
| 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 | Установить ПО для работы с электронной подписью |
Что это значит. Если считать все заявки подряд, сбоев выходит на 25% больше, чем было, а время восстановления смешивается со сроком выполнения запросов. Отчёт руководству по всем заявкам показывает больше аварий, чем было на самом деле. Отдельно про простой: если бы мы складывали длительности подряд, вышло бы 83д 06ч 19м. Разница в 13д 17ч 54м - это инциденты, которые шли одновременно. Считать их дважды значит завысить простой.
Что делать. Считать показатели сбоев только по записям с типом инцидента в колонке «Категория» и следить, чтобы тип заполнялся всегда.
Проверьте у себя.* Отфильтруйте выгрузку по колонке «Категория»: записей с типом запроса, изменения или проблемы должно выйти 300.
Что смотрели. Время от регистрации инцидента до восстановления по 1369 инцидентам. Время календарное: ночи и выходные входят в него целиком. Не закрыты 14 заявок: их окончание неизвестно, в расчёт они не вошли. С приоритетом 1-2 среди них 2, самая давняя открыта с 22.12.2025. Если это идущая авария, она крупнее любого числа выше.
Что получили. Половина инцидентов закрывается быстрее 54 мин. Среднее - 1ч 28м. Худшие 5% тянутся дольше 4ч 41м, самый долгий - 19ч 30м. Эти 69 инцидентов дают 24% всего простоя.
Половина инцидентов закрывается быстрее 54 мин, среднее - 1ч 28м. 5% самых долгих (правее 4ч 41м) дают 24% простоя.
Крупнейшие инциденты (топ-3) дают 2.4% всего простоя - основной простой набирается из массы обычных сбоев, а не из нескольких аварий.
Строки журнала: самые долгие инциденты
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| 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м |
Что это значит. Среднее (1ч 28м) выше медианы (54 мин) - обычное дело для ремонтов: немногие долгие случаи тянут среднее вверх. Класса тяжёлых инцидентов нет: 5% самых долгих дают только 24% простоя. Для отчёта берите медиану - она показывает обычный инцидент.
Что делать. Завести отдельную процедуру для инцидентов, которые не закрылись за 4ч 41м. Не «усилить контроль», а конкретно: по истечении этого срока - эскалация к инженеру, который имеет право звать вендора. Сегодня такие инциденты идут в общей очереди.
Проверьте у себя.* Поднимите три последних инцидента длиннее 4ч 41м и посмотрите, сколько времени ушло на диагностику, а сколько на сам ремонт. Если больше половины на диагностику - узкое место в мониторинге, а не в руках инженеров.
Что смотрели. Распределение инцидентов и простоя по 13 объектам, а также повторы.
Что получили. 3 объекта из 13 держат 53% всего простоя. Худший - «Кассы магазинов»: 407 инцидентов, 19д 14ч 50м простоя. При ровном распределении было бы 23%. У «Кассы магазинов» 77% простоя дают заявки 3-4 приоритета. Это время заявки, а не обязательно простой бизнеса: проверьте, стоял ли сервис на самом деле. Заявки, закрытые таймером или разбором очереди, и незакрытые в простой не вошли (подробнее - в разделе 2). 34% сбоев на объектах (435 из 1296) вернулись на тот же объект той же системы в течение 7 дней после починки. Если бы все объекты каждой системы ломались одинаково, было бы около 33%. Заявки одной аварии на одном объекте посчитаны одним сбоем: таких заявок 87. «ERP-01» в системе «1С:ERP»: 49 сбоев за период, у типичного объекта этой системы - 22: ломается чаще других, и случайно так не выходит. «Магазин №17» в системе «Кассы магазинов»: 29 сбоев за период, у типичного объекта этой системы - 9: ломается чаще других, и случайно так не выходит.
Полоса - доля всего простоя; пунктир - сколько было бы у каждого, если бы простой делился поровну. Оранжевым - те, о ком говорит раздел.
Строка - объект, отметка - сбой. Красная точка - сбой в течение 7 дней после починки прошлого, тёмная черта - после перерыва. Справа - сколько сбоев на объекте и сколько у типичного объекта той же системы, или сколько сбоев вернулись.
Строки журнала: самые долгие инциденты «Кассы магазинов»
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| 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м |
Строки журнала: сбои на «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м |
Что это значит. Простой держат немногие объекты, и это сверх того, что дал бы случай. Люди и разбор, направленные туда, вернут больше всего времени. Названные объекты ломаются снова и снова. Тот же объект - ещё не та же причина, и по журналу её не видно. Возможные причины: причину не устранили - чинили перезапуском или обходом; объект изношен или перегружен; на объекте больше оборудования или людей, чем на соседних; одну аварию заводят заново через время. Различат их описание и способ закрытия этих заявок, запись в журнале проблем и число единиц оборудования на объекте.
Что делать. Начать не с 13 объектов, а с 3. По «Кассы магазинов» - разобрать его инциденты вместе, одним разбором, и искать общую причину, а не причину каждого. Разобрать сбои «ERP-01» вместе, одним разбором: сравнить описания и что делали при закрытии. Одна причина и чинили перезапуском - завести проблему и искать причину. Причины разные, а объект больше соседних - сравнивать его с объектами того же размера. Одну аварию завели заново - договориться, что повторную заявку привязывают к первой.
Проверьте у себя.* Откройте три любых инцидента с «Кассы магазинов» за последний месяц. Если в них разные причины - мы ошиблись, и объект просто перегружен. Если причина одна и та же - у вас есть проблема, которую никто не ведёт. Через квартал прислать журнал снова: на «ERP-01» должно стать меньше сбоев и возвратов в течение недели.
Что смотрели. Какие системы сбоят вместе: после сбоя одной в течение 15 минут открывается заявка по другой чаще, чем совпало бы случайно.
Что получили. После сбоя «Каналы связи магазинов» в течение 15 минут открываются заявки и по другим системам: «Wi-Fi в магазинах» 14 раз из 71, «Кассы магазинов» 11 раз из 71, «Платёжный шлюз» 9 раз из 71. Случайно, при собственном ритме этих систем, совпало бы не больше 0,7 раза за весь период. 80 заявок из 1383 открыты в первые 15 минут уже идущей аварии: это её продолжение или та же авария, заведённая повторно. Число сбоев и время между ними в отчёте посчитаны по заявкам и поэтому завышены примерно на 6%; в списке крупнейших инцидентов такая авария считается одной.
Полоса - сколько раз после сбоя первой системы в течение 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 мин |
Что это значит. Заявки по «Wi-Fi в магазинах» в первые минуты после сбоя «Каналы связи магазинов» - скорее следствие, чем отдельная беда. Так бывает по трём причинам: «Wi-Fi в магазинах» работает через «Каналы связи магазинов»; обе зависят от третьего - питания, общего узла, площадки; или одну аварию завели две группы. Различит их колонка объекта (магазин, узел, площадка): совпадает объект у пары заявок - это одна авария.
Что делать. Заявки по «Wi-Fi в магазинах», открытые в первые 15 минут после сбоя «Каналы связи магазинов», привязывать к её заявке как дочерние. Тогда сбои перестанут двоиться в отчётах, а чинить будут одну причину. Если «Wi-Fi в магазинах» работает через «Каналы связи магазинов», резерв нужен у «Каналы связи магазинов».
Проверьте у себя.* Откройте три последние аварии «Каналы связи магазинов» и заявки по «Wi-Fi в магазинах» за следующие 15 минут: тот ли это объект и закрылись ли они вместе с аварией.
Что смотрели. Распределение инцидентов по часам и дням недели, а также изменение частоты во времени.
Что получили. По времени недели: в будни с 9 до 18 - 46% инцидентов (это 27% часов недели), вечером и ночью в будни - 28%, в выходные - 27%. Чт 02:00-03:00: 34 инцидентов, а обычный ритм дал бы здесь около 4. Сбои в этот час повторялись в 31 из 52 недель. Чаще всего это Складская система (28 из 34). 1С:ERP: сбои в последние три дня месяца - в 11 из 12 месяцев. Сбойных дней в эти даты 22, а обычный ритм дал бы около 7. Последний раз - 30.12.2025. Если ничего не менять, следующий по циклу - 29.01.2026-31.01.2026. Частота инцидентов выросла: с 3,2 в сутки в начале периода до 5,1 в конце. Ступенька это или постепенный рост, по данным не отличить. Если ступенька - она пришлась на 13.08.2025-24.09.2025, вероятнее всего около 01.09.2025: было 3,2 в сутки, стало 4,9. Если рост шёл постепенно, единой даты нет. Новый уровень держится уже 122 дн.
Чем темнее клетка, тем больше инцидентов. Будни с 9 до 18 (пунктирная рамка) - 46%, вечер, ночь и выходные - 54%. Красная рамка - час, который выбивается из вашего обычного ритма; число - его инциденты.
Каждый кружок - день цикла: красный - в этот день система сбоила, пустой - день прошёл тихо. Штрихи - сбои в другие дни. Пустой красный кружок после конца выгрузки - следующий день по циклу, если ничего не менять.
Строки журнала: инциденты в выделенный час
| Номер | Начало | Сервис | Объект | Длительность |
|---|---|---|---|---|
| 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м |
Строки журнала: сбои «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м |
Что это значит. Сбой, привязанный к часу, почти всегда связан с расписанием: ночная задача (обмен, выгрузка, резервная копия), окно релизов, плановые работы подрядчика или проверка, которая записывает найденное в своё время. Случайные поломки так не собираются. Сбой, который возвращается через равные промежутки, почти всегда связан с расписанием или накоплением: задание раз в несколько дней, закрытие месяца и отчётность, место или память, которые заканчиваются к одному сроку, сертификат или пароль со сроком действия. Случайные поломки так не повторяются. Журнал не говорит, что произошло: в нём нет поля причины. Варианты: больше пользователей или точек, релиз или миграция, смена подрядчика, новые правила регистрации - например, мониторинг начал сам открывать заявки. Различить поможет журнал изменений за эти недели и колонка «кем зарегистрировано» (человек или мониторинг).
Что делать. Найдите, что запускается в это время: расписание заданий, окно релизов, работы подрядчиков. Если это задача - перенесите её или добавьте проверку перед запуском; если релизы - проверку сразу после выката. Сверьте эти даты с календарём закрытия месяца, отчётности и выплат: что нагружает систему в эти дни. Дайте ей ресурс заранее и назначьте на эти даты дежурного, который знает систему. Найти, что изменилось в эти недели. Если это рост бизнеса - пересчитать дежурную смену под новый уровень. Если релиз или подрядчик - вернуть вопрос тому, кто внёс изменение.
Проверьте у себя.* Откройте заявки за Чт 02:00-03:00: если в них одна система и похожий текст, это одна повторяющаяся причина. Время взято как в выгрузке. Если ваша система пишет время по Гринвичу (UTC), сдвиньте часы на свой пояс. Откройте заявки по системе 1С:ERP за даты цикла (29.09.2025, 29.10.2025, 28.11.2025, 30.12.2025): если текст один и тот же, это одна причина. Если систему между сбоями перезапускали, цикл может быть сроком, за который заканчивается ресурс. Посмотрите, что вы делали с 13.08.2025 по 24.09.2025: релизы, переключения, новые договоры, настройка мониторинга.
Что смотрели. Распределение самых длинных простоев и текущий темп появления инцидентов.
Что получили. 2,7% инцидентов длятся дольше 6 ч - примерно каждый 37-й. При вашей частоте это около 3 раза в месяц. Простоев дольше 6 ч по критичным и высоким инцидентам (приоритеты 1-2): 3,4% таких инцидентов, примерно раз в 2 месяца. Незакрытых заявок в выгрузке: 14, из них дольше 6 ч открыты 13. Их окончание ещё неизвестно, в подсчёт долгих они не вошли. С приоритетом 1-2 среди них: 2, самая давняя открыта с 22.12.2025. Проверьте, идёт ли простой сейчас или заявку забыли закрыть. Если частота сохранится, в ближайшие 7 дней ожидается около 36 инцидентов (вероятный диапазон 22-53), за 30 дней - около 156 (128-185). Оценка построена по вашей же частоте инцидентов за наблюдаемый период - расчёт по последним 60 дням: частота за период менялась.
Частота сменилась: было 3,2 в сутки, стало 4,9. Ступенька или постепенный рост - по данным не отличить; полоса - где могла быть ступенька. Следующие 30 дней: около 156 инцидентов (128-185).
Что это значит. Такой случай бывает примерно раз в 2 месяца. Это ваш собственный результат, а не отраслевая норма: он посчитан по вашим же инцидентам.
Что делать. Написать и один раз проиграть порядок действий на простой длиннее 6 ч: кто принимает решение о переключении на резерв, кто говорит с клиентами, кто с регулятором.
Проверьте у себя.* Спросите дежурного инженера, что он сделает, если сервис не поднимется за 3 ч. Если ответ начинается со слов «позвоню руководителю» - плана нет.
Что смотрели. Полноту и связность самого журнала.
Что получили. Оценка качества данных - B (из A, B, C, D). Заполненность полей:
Что это значит. Поля время регистрации, время закрытия, сервис или узел, приоритет, описание или причина заполнены хорошо - значит всё, что мы сказали, опираясь на них, надёжно. Записи без времени закрытия мы исключили из расчёта длительностей, а не подставили им среднее.
Что делать. Сделать поле причины обязательным при закрытии, но с коротким списком значений, а не свободным текстом. Свободный текст заполняют плохо, список из семи пунктов - хорошо. Через квартал вы получите долю инцидентов с установленной первопричиной - показатель, который сегодня посчитать не на чем.
Проверьте у себя.* Откройте вашу систему заявок и посмотрите, какие поля обязательны при закрытии. Если причина не обязательна - вот почему её нет в этом отчёте.
| Поле | Заполнено |
|---|---|
| Время регистрации | 100% |
| Время закрытия | 99% |
| Сервис или узел | 100% |
| Приоритет | 100% |
| Описание или причина | 100% |
В основном тексте отчёта названий методов мы не показывали намеренно - чтобы не перегружать.
| Что в отчёте | Как посчитано |
|---|---|
| Суммарное время простоя | Объединение пересекающихся интервалов перед суммированием - без этого параллельные инциденты считаются дважды |
| Время восстановления сервиса | Медиана, среднее и 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.
| Термин | Значение |
|---|---|
| Событие | Любое изменение состояния, значимое для управления услугой |
| Инцидент | Незапланированное прерывание услуги или снижение её качества |
| Проблема | Причина или потенциальная причина одного или нескольких инцидентов |
| Известная ошибка | Проблема, которая проанализирована, но не устранена |
| Обходное решение | Решение, снижающее или устраняющее влияние инцидента, пока полного нет |
| Изменение | Добавление, правка или удаление чего-либо, что может повлиять на услуги |
| Запрос на обслуживание | Запрос пользователя на действие, согласованное как штатная часть услуги. Не инцидент |
| Время восстановления сервиса | Насколько быстро услуга восстанавливается после отказа |
* Эти задачи могут быть сделаны точнее и качественнее при нашем участии.