Какие инциденты дают больше всего простоя
Сотни, а то и тысячи инцидентов в трекере за год. Чинить всё подряд ресурсов не хватает. С чего начать, чтобы простой снизился быстрее всего?
Какую задачу решаем?
Команда физически не успевает разбирать всё. На первый взгляд кажется, что чинить надо самые частые сбои - но это далеко не всегда те же инциденты, что дают больше всего времени простоя (времени, когда сервис недоступен). Нужен способ отделить немногое важное от большинства, которое можно отложить.
Наши результаты
На реальных данных (банковский процессинг, 802 инцидента за год) движок посчитал вклад каждого инцидента в общий простой:
Практический вывод: заняться этими ~52 инцидентами важнее, чем всей массой сразу. Остальные 93.5% чинить тоже нужно - но простой они почти не двигают, даже если закрыть их все. Экономия сил очевидна и может быть очень большой.
Как это считается
Метод из семейства описательной аналитики - «что у меня происходит?».
- Парето-анализ (правило 80/20). Сортируем инциденты по вкладу в простой и считаем накопленную сумму - до какой точки набегает 80%. Рядом - коэффициент Джини как числовая мера концентрации.
- Связь с критичными сервисами. Если в начале назвать боту ключевые системы (например, «платёжный шлюз»), движок отдельно посчитает простой именно по ним - не абстрактный «топ», а адресный ответ по тому, что важно вам.
Метод считает частоту и долю простоя, но не тяжесть отдельного катастрофического сбоя - поэтому рядом всегда идёт оценка риска долгого простоя (отдельный разбор).
Узнать это про свою инфраструктуру
Загрузите логи (CSV / Excel из Jira, ServiceNow, Zabbix или простой список инцидентов) - движок покажет, какие ваши инциденты реально дают основной простой.
Все данные обрабатываются изолированно и не передаются третьим лицам.