Прогнозирование инцидентов производительности на основе цепей Маркова (версия 16.3)⁠⁠

Оригинал — на основном техническом канале (Возможны правки и дополнения).

Экспериментальное исследование прогностической способности марковской модели на синтетических данных, имитирующих нагрузку тестовой СУБД, с анализом временной динамики, калибровочных характеристик и чувствительности, а также оценкой полноты обнаружения инцидентов и рекомендациями по адаптации для промышленной эксплуатации.

Период анализа: 2026-07-19 15:54 – 2026-08-19 12:53

Конфигурация сигнала: режим WEIGHTED (вес JS=0.9, вес риска=0.1), порог JS=0.2, порог риска=0.8, мин. длительность сигнала=3 минуты

Всего инцидентов (уникальных): 338 (исключено 71 серийный, т.е. продолжающих предыдущий)

1. Эффективность обнаружения (Recall)

• ✅Сигнал сработал перед инцидентом в 84% случаев (284 из 338).

• ✅Среднее время упреждения – 58.7 минут (почти час), что даёт достаточный задел для реакции.

• ✅Медианное время до инцидента (по деталям) – также близко к 60 минутам (большинство сигналов возникают ровно за час).

📋Вывод: модель обладает высокой чувствительностью и обеспечивает своевременное предупреждение. Однако 16% инцидентов происходят без сигнала – это потенциальная зона для улучшения.

2. Распределение последних статусов перед инцидентом

CRITICAL: 207 инцидентов (61.2%) – более 60% инцидентов происходят сразу после статуса CRITICAL, что ожидаемо и подтверждает, что критические отклонения часто предшествуют сбоям.

NORMAL: 106 инцидентов (31.4%) : почти треть инцидентов случаются после статуса NORMAL, т.е. система не подавала предупреждений. Это указывает на:

• недостаточную чувствительность порогов (возможно, JS-порог 0.2 или риск-порог 0.8 слишком высоки для некоторых сценариев);

• наличие инцидентов, которые развиваются слишком быстро (менее чем за 3 минуты – минимальная длительность сигнала);

• необходимость введения дополнительных предикторов (например, скорости изменения метрик).

INCIDENT: 24 инцидента (7.1%) – это продолжения серий, которые были исключены, но в данном контексте означают, что сразу после инцидента начинается новый.

WARNING: 1 инцидент (0.3%) – единичный случай, статистически незначим.

3. Качество прогнозов риска (по данным prediction_log)

• ROC-AUC = 0.8636 – отличная дискриминационная способность (модель хорошо разделяет инцидентные и безынцидентные окна).

• Brier score = 0.1138 – приемлемое значение (чем меньше, тем лучше; обычно <0.25 считается хорошим).

Калибровочная кривая (риск vs. фактическая частота) в виде списка бинов:

• Бин [0.0–0.1]: предсказано 0.023, фактически 0.052

• Бин [0.1–0.2]: предсказано 0.158, фактически 0.274

• Бин [0.2–0.3]: предсказано 0.277, фактически 0.282

• Бин [0.3–0.4]: предсказано 0.381, фактически 0.416

• Бин [0.4–0.5]: предсказано 0.450, фактически 0.417

• Бин [0.5–0.6]: предсказано 0.580, фактически 0.618

• Бин [0.6–0.7]: предсказано 0.603, фактически 0.562

• Бин [0.7–0.8]: предсказано 0.718, фактически 0.662

• Бин [0.8–0.9]: предсказано 0.884, фактически 0.400

• Бин [1.0–1.1]: предсказано 1.000, фактически 0.600

Наблюдение: систематическая переоценка риска в верхнем диапазоне – для бинов 0.8–0.9 и 1.0–1.1 фактические частоты значительно ниже предсказанных.

📋Рекомендация: скорректировать вероятности с помощью калибровки (например, изотоническая регрессия или Platt scaling) или пересмотреть пороги для высоких рисков, чтобы уменьшить ложные срабатывания.

4. Характеристики профилей перед инцидентами

• ℹ️Средняя JS-дивергенция за час до инцидента = 0.3548 (высокое значение, указывает на значительные изменения в распределении состояний).

• ℹ️Средний предсказанный риск за час до инцидента = 0.1621 (относительно низкий, но в момент сигнала риск часто достигает 1.0 – см. детали).

• ℹ️Тренд риска перед инцидентом: в большинстве случаев РОСТ (что логично), реже – СНИЖЕНИЕ или СТАБИЛЬНО.

📋Вывод: профиль нагрузки перед инцидентами существенно отклоняется от эталона, и риск имеет тенденцию к росту. Это подтверждает правильность выбора JS-дивергенции как ключевого предиктора.

5. Совпадения с пред-инцидентными профилями

• 0 инцидентов (0%) имели совпадение с библиотекой pre_incident_profiles (шаблон ID = NULL).

• ℹ️Это означает, что либо библиотека шаблонов недостаточно полна, либо порог совпадения (0.05 JS) слишком строгий, либо текущие сценарии инцидентов не повторяют ранее зафиксированные.

📋Рекомендация: расширить библиотеку, используя автоматический сбор профилей для всех инцидентов (функция collect_pre_incident_profiles), и поэкспериментировать с более мягким порогом (0.1–0.15) для увеличения числа совпадений.

6. Временное распределение инцидентов

• По часам суток: пики приходятся на 19:00–20:00 (18 инцидентов) и 04:00–05:00 (17 инцидентов). Это может указывать на периоды пиковой нагрузки или выполнения плановых задач (бэкапы, отчёты).

• По дням недели: наибольшее число инцидентов во вторник (около 60), наименьшее – в воскресенье (около 36).

Рекомендация: усилить мониторинг в часы пик и во вторник, возможно, увеличить чувствительность сигнала в эти периоды.

7. Общая оценка и рекомендации

✅Сильные стороны:

• Высокая чувствительность (84% recall) и большое время упреждения (~1 час).

• Отличная дискриминация (ROC-AUC > 0.86).

• Система успешно улавливает большинство инцидентов через изменения профиля нагрузки.

Слабые стороны и точки роста:

1. 16% пропущенных инцидентов – необходимо проанализировать их сценарии и, возможно, снизить порог риска или JS для отдельных типов.

2. 31% инцидентов после статуса NORMAL – это «внезапные» события, которые могут быть связаны с резкими скачками нагрузки. Стоит добавить детектор резких изменений (например, производную JS или риска).

3. Переоценка риска в верхнем диапазоне – калибровка вероятностей повысит точность прогнозов и уменьшит число ложных тревог.

4. Отсутствие совпадений с пред-инцидентными профилями – расширить библиотеку и настроить порог совпадения.

5. Временные паттерны – можно внедрить адаптивные пороги, зависящие от времени суток и дня недели.

Приоритетные действия:

• Провести анализ 54 инцидентов без сигнала (16%) – выделить общие признаки и дополнить правила их обнаружения.

• Откалибровать прогнозы риска (возможно, через биннинг или логистическую регрессию).

• Запустить сбор пред-инцидентных профилей для всех новых инцидентов и пересмотреть порог совпадения.

• Настроить автоматическое оповещение при переходе в статус CRITICAL, а также при резком росте JS или риска даже при статусе NORMAL.

📋Итоговый вердикт

ℹ️Система прогнозирования инцидентов демонстрирует высокую эффективность и пригодна для эксплуатации.

Основные метрики (recall, ROC-AUC, время упреждения) находятся на хорошем уровне.

ℹ️Выявленные недостатки носят уточняющий характер и могут быть устранены путём калибровки, расширения библиотеки шаблонов и адаптации порогов к временным паттернам.