Postgres DBA

Аннотация.

Рассматривается применение программного комплекса pg_expecto, реализующего сбор статистики производительности PostgreSQL и построение цепи Маркова для прогнозирования инцидентов.

Проведён анализ сводного отчёта за 30 дней (октябрь–ноябрь 2026 г.). Показано, что сигнал SICPP обеспечивает покрытие 93,5% инцидентов при precision эпизодов 28,3%, сигнал C-only – покрытие 79,6% при 22 непокрытых инцидентах, преимущественно в зонах восстановления и пересечения с инцидентами. Калибровка вероятностей снижает Brier score на 11,9% без существенного изменения ROC-AUC. Выявлены артефакты агрегации (доли активности сигналов >100%) и расхождения в недельной динамике. Обоснована необходимость углублённого анализа выделенных переходных периодов с привлечением ожиданий, метрик ОС и активности фоновых процессов.

Ключевые слова: PostgreSQL, мониторинг производительности, цепь Маркова, SICPP, C-only, JS-дивергенция, калибровка вероятностей, performance engineering.

Введение.

Задача оперативного обнаружения деградации СУБД требует совместного анализа метрик производительности, ожиданий и профилей нагрузки. Комплекс pg_expecto собирает поминутные данные о скорости, ожиданиях, чтении/записи разделяемых блоков, метриках ОС и параметрах autovacuum. На их основе цепь Маркова формирует дискретное состояние (корреляция скорость–ожидания, тренды скорости и ожиданий), а модуль профилирования сравнивает текущий профиль с эталонным по JS-дивергенции. Сигналы SICPP и C-only предназначены для предупреждения инцидентов.

Цель работы

На примере сводного отчёта за 30 дней оценить эффективность сигналов, качество прогнозов и ограничения текущей реализации.

Методика.

Состояние цепи Маркова определяется как комбинация округлённой корреляции Пирсона (шаг 0,1) и знаков углов наклона линий регрессии для операционной скорости и ожиданий. Переходы фиксируются в transition_log, частоты накапливаются в markov_frequencies с адаптивным забыванием. Критические состояния отбираются по эмпирическому риску инцидента и хранятся в critical_states.

Сигнал SICPP вычисляется по окну window_minutes с порогами js_threshold и risk_threshold; покрытие инцидента определяется пересечением эпизода SICPP с инцидентом, lead time – от episode_started_at до начала инцидента.

Сигнал C-only (операционный индикатор) вычисляется по формуле risk_p90 >= c_p90_min AND js_avg >= c_js_min AND W_score >= c_w_min в окне 20 минут. W_score рассчитывается как (risk_avg / risk_threshold) * weight_risk + (js_avg / js_threshold) * weight_js.

Калибровка вероятностей выполняется по изотонической регрессии с сохранением карты в mchain_calibration_map; для дашбордов рекомендуется calibrated_risk, для алертов – raw (predicted_risk).

Результаты анализа сводного отчёта.

Период анализа: 2026-10-14 10:38 – 2026-11-13 10:37 (+03)

Длительность 30 дней.

• Зафиксировано 108 инцидентов;

• Покрытие SICPP: 101 инцидент (93,5%).

• Покрытие C-only: 86 инцидентов (79,6%); не покрыто 22.

• Распределение последних статусов перед инцидентами: CRITICAL – 59, WARNING – 24, NORMAL – 0, INCIDENT – 13, NO_BASELINE – 0.

• Качество прогнозов: ROC-AUC raw 0,8854, calibrated 0,8848; Brier raw 0,131183, calibrated 0,115541 (улучшение на 11,9%).

• SICPP с lead time: из 101 покрытого инцидента 92 имели lead ≥60 мин (91,1% покрытых; 85,2% от всех инцидентов); средний raw lead – 129,6 мин; 27 инцидентов имели raw lead >180 мин.

• Precision эпизодов SICPP: 28,3% (233 эпизода, 66 TP, 167 FP).

• Непокрытие C-only: in_recovery – 11, profile_incident – 10, threshold_fail – 1 (ID 52); остальные подавлены зонами recovery/profile incident.

• Операционные флаги: c_only_incident_flag – 73 результирующих эпизода из 155 стартов (47,1%); sicpp_incident_flag – 76 из 190 (40,0%); средняя длительность результирующего эпизода: c_only 130,2 мин, sicpp 177,2 мин.

Профиль производительности нестабилен. Суточная средняя JS-дивергенция изменяется от 0,0542 до 0,1894; суточный максимум JS – от 0,2196 до 0,2551; корреляция за день варьирует от -0,109 до 0,943. В периоде доминируют длительные переходные периоды со статусом CRITICAL, преимущественно типа instability и degradation.

Ключевые переходные периоды:

• 2026-10-16 00:00–14:00: degradation, CRITICAL, max JS 0,245, 840 мин.

• 2026-10-19 17:00–2026-10-20 20:00: instability, CRITICAL, max JS 0,255, 1620 мин (самый длительный и максимальный JS).

• 2026-10-22 09:00–20:00: degradation, CRITICAL, max JS 0,244, 660 мин.

• 2026-10-29 20:00–2026-10-30 06:00: instability, CRITICAL, max JS 0,228, 600 мин.

• 2026-10-31 20:00–2026-11-01 10:00: instability, CRITICAL, max JS 0,227, 840 мин.

• 2026-11-05 05:00–18:00: instability, CRITICAL, max JS 0,222, 780 мин.

• 2026-11-07 07:00–2026-11-08 03:00: instability, CRITICAL, max JS 0,250, 1200 мин.

• 2026-11-11 08:00–2026-11-12 07:00: instability, CRITICAL, max JS 0,232, 1380 мин.

• 2026-11-12 13:00–17:00: degradation, WARNING, max JS 0,199, 240 мин.

В почасовой динамике значения SICPP% и C% местами превышают 100% (201,7%, 296,7%, 325,0%, 451,7%). Это артефакт агрегации: длительность активного интервала относится к часу его начала, поэтому длинный интервал даёт вклад больше 3600 с. В почасовой и ежедневной динамике энтропия, доля критических состояний и число аномалий равны нулю на всём периоде, при этом JS-дивергенция и переходные периоды ненулевые. В недельной динамике для полных недель число переходных периодов указано 0, тогда как в списке переходных периодов за эти же недели периоды присутствуют. Вероятная причина – порядок вызова: build_profile_weekly выполняется до detect_transition_periods, поэтому недельные счётчики могут быть от предыдущего запуска.

Обсуждение.

Высокое покрытие SICPP (93,5%) сочетается с низкой precision эпизодов (28,3%), что указывает на значительную долю ложных срабатываний. C-only имеет более высокую конверсию стартов в результирующие эпизоды (47,1% против 40,0% у sicpp_incident_flag) и меньшую среднюю длительность результирующего эпизода (130,2 мин против 177,2 мин). SICPP обеспечивает большее покрытие и больший lead time, но и больше FP. Калибровка улучшает Brier score на 11,9%, ROC-AUC практически не меняется (−0,1%), что согласуется с сохранением дискриминационной способности при коррекции систематического смещения вероятностей.

Ограничения анализа: точные причины переходных периодов не установлены, поскольку в предоставленных отчётах отсутствуют wait_event_type по инцидентам, планы запросов, метрики ОС vmstat/iostat, настройки shared_buffers, work_mem, random_page_cost, effective_cache_size, события autovacuum. Приоритет инцидентов (priority) недоступен, так как markov_chain_performance_incident не содержит этого столбца. Причины нулевых энтропии, критической доли и аномалий, а также нулевых SICPP TP и C-only Prec в ежедневной динамике не установлены; требуется прямая выборка из profile_aggregated, anomaly_log, sicpp_incident_flag_history, c_only_incident_flag_history.

Рекомендации для дальнейшего анализа.

Для каждого выделенного периода целесообразно собрать:

• report_wait_event_type_vmstat и report_vmstat_performance – для связи ожиданий СУБД с метриками ОС.

• report_postgresql_wait_event_type и report_postgresql_cluster_performance – для детализации ожиданий и корреляций.

• report_shared_buffers – для оценки эффективности кеширования.

• report_queryid_for_pareto и pg_stat_statements – для выявления вклада запросов.

• autovacuum_log_events – для проверки влияния фоновых процессов.

• report_vmstat_iostat и report_iostat – для анализа дисковых задержек и загрузки устройств.

Приоритетные периоды:

• 2026-10-19 17:00–2026-10-20 20:00 (максимальный JS и длительность),

• 2026-11-11 08:00–2026-11-12 07:00 (второй по длительности),

• 2026-10-16 00:00–14:00 и 2026-10-22 09:00–20:00 (длительные деградации),

• 2026-11-12 13:00–17:00 (свежий период для проверки восстановления).

Заключение.

Комплекс pg_expecto и цепь Маркова обеспечивают воспроизводимый анализ производительности PostgreSQL с разделением на сигналы SICPP и C-only.

Результаты за 30 дней подтверждают высокое покрытие инцидентов SICPP (93,5%) при умеренной precision эпизодов (28,3%) и улучшение калибровки вероятностей (Brier score снижен на 11,9%).

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

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

Аннотация

Рассматривается опыт применения большой языковой модели DeepSeek в проекте pg_expecto/markov_chain — системе прогнозирования инцидентов производительности СУБД PostgreSQL на основе адаптивной цепи Маркова (версия 26.2.1). Нейросеть использовалась для генерации и рефакторинга PL/pgSQL-кода, формулировки проверяемых гипотез и интерпретации результатов экспериментов. Описаны конкретные задачи, решённые при участии DeepSeek: устранение ошибок типизации (замена REAL на DOUBLE PRECISION в функциях прогноза риска), восстановление пропущенных исторических записей в profile_comparison_log, диагностика систематической ошибки в классификаторе непокрытых инцидентов. Приведены количественные оценки: объём кода превышает 10 000 строк, число итераций для ключевых функций достигает 10, ускорение разработки оценивается в 4–6 раз. Обсуждается модель разделения труда, при которой DBA выполняет роль архитектора и критика, а DeepSeek — высокопроизводительного исполнителя для задач, требующих удержания в контексте сотен строк кода и анализа больших массивов текстовых отчётов.

Ключевые слова: PostgreSQL, цепь Маркова, прогнозирование инцидентов, большие языковые модели, DeepSeek, PL/pgSQL, калибровка вероятностей, анализ производительности.

1. Введение

Задачи анализа производительности СУБД традиционно решаются экспертами-администраторами (DBA) на основе эвристик и интуиции, что затрудняет воспроизводимость результатов и объективную оценку рисков. Проект pg_expecto/markov_chain, развиваемый в открытом репозитории на платформе GitHub, ставит целью формализацию этих задач в терминах вероятностной модели — дискретной цепи Маркова с 189 состояниями, каждое из которых определяется комбинацией корреляции «скорость–ожидания» и знаков трендов этих метрик. Модель обучается в потоковом режиме, ежесекундно обновляя матрицу переходов, и использует механизм адаптивного забывания для учёта нестационарности нагрузки.

Построение подобной системы сопряжено с рядом нетривиальных проблем, выходящих за рамки классической теории цепей Маркова: обеспечение воспроизводимости экспериментов, интерпретация калибровочных кривых, согласование исторических и онлайн-данных, выбор гиперпараметров. Настоящая работа обобщает опыт решения этих проблем с привлечением нейросети DeepSeek, которая выполняла функции генератора кода, поставщика гипотез и аналитика экспериментальных данных. Цель статьи — описать конкретные механизмы взаимодействия DBA и нейросети, оценить эффективность такого симбиоза и сформулировать условия, при которых использование больших языковых моделей в задачах подобного класса даёт значимый эффект.

2. Материалы и методы

2.1. Архитектура системы

К версии 26.2.1 система включает более 80 хранимых функций и процедур на языке PL/pgSQL, организованных в несколько слоёв. Ядро цепи Маркова образуют функции mchain_train_step() (поминутное обучение), update_markov_probabilities() (пересчёт матрицы вероятностей) и mchain_predict_risk_k_v2() (многошаговый прогноз риска). Пространство состояний формируется дискретизацией корреляции (21 уровень от −1.0 до +1.0 с шагом 0.1) и трендов операционной скорости и времени ожиданий (по три уровня), что даёт 189 состояний.

Профилирование нагрузки реализовано через функции calculate_profile_metrics(), compare_profiles_at() и histogram_divergence(). Сравнение текущего окна (обычно 60 минут) с эталонным безынцидентным окном позволяет вычислять JS-дивергенцию гистограмм состояний и присваивать статусы NORMAL, WARNING или CRITICAL. Сигналы предупреждения SICPP и C-only, реализованные в функциях sicpp_calculate_at() и mchain_hybrid_alert_at() соответственно, используют пороги по JS-дивергенции, перцентилю риска (p90) и взвешенной оценке W-score. С версии 26.1.1 введена калибровка вероятностей: сырой риск, выдаваемый цепью Маркова, может быть откалиброван с помощью изотонической регрессии или масштабирования Платта; калибровочная карта хранится в таблице mchain_calibration_map.

2.2. Организация взаимодействия с DeepSeek

Работа с нейросетью строилась по итеративной схеме. DBA формулировал задачу (например, «необходимо выявить причины, по которым часть инцидентов не покрывается сигналом SICPP»), после чего DeepSeek анализировал соответствующие фрагменты кода и данные, предлагал гипотезы и генерировал код для их проверки. Результаты экспериментов (отчёты, логи, метрики) возвращались в диалог для интерпретации. Финальное решение о внедрении изменений принимал DBA. Такая схема позволяла сочетать скорость генерации кода и анализа данных, присущую нейросети, с критической оценкой и предметной экспертизой человека.

3. Результаты

3.1. Разработка исходного кода

Значительная часть PL/pgSQL-кода проекта была создана при участии DeepSeek. Нейросеть генерировала начальные версии сложных хранимых функций объёмом в несколько сотен строк, включая mchain_train_step(), compare_profiles_at(), historical_fill_sicpp() и generate_incident_forecast_report_v2(). В комментариях к функциям сохранились следы итеративной работы: для compare_profiles_at зафиксированы версии v4, v5 и v5-fix1, где v5 содержала критическую ошибку (секции вычисления метрик были заменены заглушкой), а v5-fix1 восстанавливала их. Подобная детализация изменений характерна для кода, прошедшего через несколько циклов генерации и верификации.

Отдельного внимания заслуживает исправление ошибок типизации. В функциях прогноза риска mchain_predict_risk_k_v2() и её варианте с матрицей использование типа REAL для вектора состояний приводило к «антипереполнению» при умножении малых вероятностей. DeepSeek, проанализировав сообщения об ошибках, предложил заменить REAL на DOUBLE PRECISION на всём протяжении вычислений, оставив приведение к REAL только на выходе. Это исправление, задокументированное в комментариях к функциям, позволило повысить точность прогнозов и избежать молчаливого искажения метрик. Аналогичное исправление было перенесено в mchain_predict_risk_k_v2_with_matrix() (версия 17.1.3). Кроме того, в функции evaluate_forgetting_params() зафиксирован переход с сигнатуры REAL на NUMERIC, чтобы вызовы с числовыми литералами не приводили к ошибке «функция не существует».

Целый пласт кода — функции profile_comparison_completeness_report(), diagnose_incidents_without_prior_comparison(), diagnose_profile_comparison_duplicates(), deduplicate_profile_comparison_log() и verify_profile_comparison_dedup() — был написан для решения проблемы рассинхронизации исторических и онлайн-записей в profile_comparison_log. DeepSeek не только сгенерировал код этих функций, но и предложил стратегию идемпотентного дозаполнения с параметром p_skip_existing, что позволило устранить пропуски в данных без перезаписи исторических сигналов.

3.2. Генерация гипотез

Одной из ключевых ролей DeepSeek было порождение гипотез — предложений о том, какие параметры изменить и какие архитектурные решения опробовать. Функция evaluate_forgetting_params() и таблица forgetting_optimization_log предназначены для эмпирического подбора параметров адаптивного забывания (base_alpha, incident_half_life_days, min_alpha, interval_minute). DeepSeek предлагал сетки значений для перебора, а затем анализировал результаты, сохраняемые в лог. В комментариях к функции зафиксировано, что версия 17.1.3 устранила дубликат REAL-сигнатуры, который приводил к вызову не той перегрузки — это пример гипотезы о причине расхождения результатов, которая была проверена и подтверждена.

В конфигурационной таблице incident_forecast_config присутствуют поля hybrid_js_min_threshold, hybrid_p90_min_threshold, hybrid_w_score_min_threshold, а также параметры автоматической настройки (auto_threshold, c_auto_threshold). DeepSeek участвовал в анализе того, какие значения этих порогов обеспечивают наилучший баланс между полнотой и точностью. В комментариях к generate_incident_forecast_report_v2() отмечено, что условие A (PreAlertAdv) было исключено как шумовое (precision 5.9%, recall 17.1%), а условие B не дало уникального вклада — эти выводы были получены в результате серии экспериментов, гипотезы для которых формулировались совместно.

Проблема дублей в profile_comparison_log (одна и та же логическая минута могла быть записана с микросекундами из онлайн-функции и с обнулёнными секундами из исторической) была выявлена при анализе отчётов. DeepSeek предложил разделить метрики на total_rows, recorded_minutes и extra_rows, а также создать функцию diagnose_profile_comparison_duplicates() для детализации. Это позволило не просто констатировать наличие дублей, но и количественно оценить масштаб проблемы и предложить алгоритм дедупликации с сохранением наиболее информативных записей.

3.3. Анализ результатов экспериментов

Третий крупный блок задач — анализ экспериментальных данных. Нейросеть обрабатывала отчёты, содержащие тысячи строк, и выделяла закономерности, которые было бы затруднительно обнаружить вручную. С версии 26.1.1 в системе появились метрики ECE (Expected Calibration Error) и MCE (Maximum Calibration Error). DeepSeek помог сгенерировать код для их расчёта и сформулировать критерии вердикта в функции mchain_calibration_health_report(): GREEN (Brier ≤ raw, ECE ≤ 0.10, MCE для бинов с n ≥ 10 ≤ 0.25), YELLOW (пограничная зона), RED (деградация). В отчёте generate_incident_forecast_report_v2() появилась секция «Качество прогнозов: raw vs calibrated», где для каждой метрики выводится относительное изменение — это позволяет быстро оценить, приносит ли калибровка пользу.

В функции generate_incident_forecast_report_v2() (версия 21.6.6) присутствует секция диагностики C по непокрытым инцидентам, которая классифицирует каждый непокрытый инцидент по причине: in_prev_incident, in_recovery, profile_incident или threshold_fail. DeepSeek участвовал в анализе распределения этих причин и выявлении того, что многие инциденты ошибочно классифицировались как in_incident из-за самодетекции (функция is_ts_inside_incident() для самого инцидента всегда возвращает TRUE). Исправление (проверка пересечения с другим инцидентом, pi2.id <> b.id) было предложено и реализовано в версии 21.6.6. Это пример того, как нейросеть, проанализировав логику классификатора, обнаружила систематическую ошибку и предложила её устранить.

В отчётах generate_incident_forecast_report_v2() присутствуют секции распределения инцидентов по часам и дням недели. DeepSeek использовал эти данные для формулировки гипотез о сезонности нагрузки и о том, какие временные интервалы требуют более агрессивной настройки порогов. Окончательные решения принимались DBA, однако нейросеть обеспечивала первичную фильтрацию и визуализацию, которая ложилась в основу для дальнейшего анализа.

4. Обсуждение

4.1. Модель разделения труда

Опыт проекта подтверждает модель, при которой DeepSeek берёт на себя «черновую» работу, а DBA выполняет стратегические функции. Роль DBA включает постановку целей и ограничений (например, «горизонт прогноза не должен превышать 120 минут», «порог риска для critical_states не увеличивать выше 0.10 без пересмотра эмпирической модели»), критическую оценку гипотез, предложенных нейросетью, принятие финальных решений о внедрении изменений и формулировку «прорывных» идей, которые затем формализовывались с помощью DeepSeek. Роль DeepSeek включает генерацию и рефакторинг SQL-кода объёмом до нескольких сотен строк, анализ экспериментальных данных и подготовку отчётов, выявление скрытых зависимостей и аномалий в логах, документирование кода и ведение истории изменений, а также предложение альтернативных архитектурных решений.

4.2. Оценка эффективности

Количественно оценить вклад DeepSeek можно по следующим показателям. Объём кода превышает 10 000 строк PL/pgSQL, включая определения таблиц, функций, процедур и комментариев. Число итераций развития ключевых функций (судя по комментариям) составляет от 3 до 10, при этом каждая итерация включала генерацию или рефакторинг кода объёмом до нескольких сотен строк. Скорость выполнения этих операций с DeepSeek была в 4–6 раз выше, чем при ручной работе. Качественно нейросеть обеспечила непрерывность документирования (комментарии к каждой версии) и систематичность анализа (регулярные отчёты с фиксированной структурой), что снизило риск потери знаний при переходе между версиями.

По состоянию на версию 26.2.1 достигнуты следующие результаты. Покрытие инцидентов сигналом SICPP составляет 74.6% (50 из 67 инцидентов в тестовом периоде), при этом медианное время упреждения находится в диапазоне 15–60 минут. Качество прогнозов после калибровки: Brier score снижен до 0.0361, ECE (калиброванное) составляет 0.0062, что свидетельствует о высокой надёжности вероятностных оценок. Устранены критические пробелы в исторических данных (патч 26.2.1), что позволило корректно диагностировать причины непокрытия инцидентов и повысить доверие к отчётам.

4.3. Ограничения

Предлагаемый подход имеет ограничения. Во-первых, эффективность DeepSeek существенно зависит от качества постановки задачи: расплывчатые формулировки приводят к генерации нерелевантного кода. Во-вторых, нейросеть склонна к «галлюцинациям» — генерации синтаксически корректных, но семантически неверных конструкций, что требует обязательной верификации человеком. В-третьих, длинные диалоги с нейросетью могут терять контекст, что приводит к повторам и противоречиям. Эти ограничения компенсируются итеративной схемой работы и критической оценкой со стороны DBA.

5. Заключение

Опыт проекта pg_expecto/markov_chain демонстрирует, что синергия DBA и DeepSeek позволяет решать задачи, которые были бы неподъёмны для одного человека в разумные сроки. Нейросеть не заменяет эксперта, а многократно усиливает его возможности, беря на себя рутину и предоставляя материал для критического анализа. Дальнейшее развитие модели связано с автоматизацией выбора гиперпараметров (адаптивное забывание, пороги SICPP и C-only) и расширением набора сигналов предупреждения. Представляется, что описанная модель разделения труда применима не только к анализу производительности СУБД, но и к другим задачам, требующим сочетания предметной экспертизы и масштабной генерации кода.

Представим что база данных PostgreSQL — это большой город. Иногда город работает спокойно: запросы идут ровно, очередей почти нет, ожидания низкие. Иногда «погода» портится: скорость падает, ожидания растут, система начинает вести себя нервно. И в какой-то момент начинается «дождь» — серьёзная проблема производительности.

Задача прогнозирования — не предсказать каждую отдельную каплю и не обещать дождь на сто процентов. Задача скромнее и полезнее: вовремя заметить облака и сказать: «вероятность дождя выросла, стоит приготовиться».

Модель как метеостанция

В основе системы лежит вероятностная модель, которую для простоты можно назвать «моделью переходов». Она каждую минуту смотрит на несколько признаков «погоды» в базе данных: насколько согласованно меняются скорость и ожидания, растёт ли нагрузка, падает ли скорость. Из этих признаков складывается текущее «состояние погоды». Состояний много, но они не бесконечны — как не бесконечны сочетания температуры, ветра и влажности.

Модель запоминает, какие состояния часто сменяют друг друга, а после каких чаще наступает что-то тревожное. Это похоже на опытного синоптика: он не знает будущее, но помнит, что после определённого сочетания облаков и ветра дождь случается чаще. Важная деталь: модель не помнит всё навсегда. Старые наблюдения постепенно «выветриваются», как старые прогнозы погоды, которые уже не помогают сегодня. Есть и особые, «аварийные» состояния: если система в них попала, риск считается реализованным. Прогноз на несколько минут вперёд — это, по сути, вопрос: «какова вероятность хотя бы раз попасть в тревожное состояние в ближайшее время?»

Но самое интересное начинается не с самой модели, а с сигналов-флажков. Для простоты назовём их двумя облаками на небе.

Два облака — два характера

Первое облако — «быстрое». Оно появляется чаще, реагирует оперативнее, но иногда оказывается пустым: облако есть, а дождя нет.

Второе облако — «фоновое». Оно может висеть над горизонтом долго, покрывает более широкую зону, но иногда висит почти целый день без всякого дождя.

Здесь и работает главная метафора: если идёт дождь, то на небе почти всегда есть облако; но если на небе облако, это не значит, что пойдёт дождь. Иными словами, сигналы чувствительны — они часто появляются перед проблемой, — но не всегда точны: часть срабатываний остаётся без последующей проблемы.

По данным наблюдений это видно довольно наглядно. «Быстрое» облако срабатывало чаще и в среднем в четырёх случаях из десяти действительно предвещало проблему. Причём эта доля почти не менялась от месяца к неделе: облако ведёт себя предсказуемо. «Фоновое» облако давало более широкий охват: оно «накрывало» больше проблемных случаев — примерно восемь из десяти. Но его поведение менее стабильно: в одном периоде полезных срабатываний было около трети, в другом — больше половины. И висело оно иногда очень долго: самый длинный период активности продолжался почти восемнадцать часов и повторялся в разных срезах наблюдений.

«Быстрое» облако, наоборот, обычно давало компактные предупреждения: в недельном срезе средняя длительность полезного сигнала была около двух часов, а максимальная — примерно пять часов. «Фоновое» облако в том же срезе было длиннее: в среднем около четырёх часов, а максимум всё тот же — почти восемнадцать часов. Поэтому «быстрое» облако удобнее держать на оперативном экране: оно не висит слишком долго и даёт понятное подтверждение. «Фоновое» облако полезно как широкий ранний фон, но его длительность нужно ограничивать, иначе оно превращается в «облако, которое висит неделю».

В коротком дневном наблюдении картина повторилась. «Быстрое» облако сработало девять раз, и в четырёх случаях после него действительно началась проблема. «Фоновое» — четыре раза, и в двух случаях была проблема. «Быстрое» поймало больше проблем, но и больше пустых облаков. «Фоновое» реже ошивалось, но и реже срабатывало: оно пропустило два случая, которые «быстрое» облако заметило. Среднее время упреждения у обоих — около часа. Это важная цифра: у оператора обычно есть примерно час, а иногда всего десять минут, чтобы подготовиться.

Почему облако не всегда приносит дождь

Потому что сигнал — это не сама проблема, а повышение вероятности. Модель оценивает риск, но риск — не приговор.

В крайних зонах она довольно уверенно говорит «очень тихо» или «очень тревожно». А вот в середине шкалы её оценка «может быть» требует осторожности: средние вероятности менее надёжны, чем крайние. Поэтому нельзя воспринимать каждое облако как гарантию дождя и нельзя считать, что одно универсальное правило «сработает всегда».

Есть и другая тонкость. Часть пропущенных проблем возникала не потому, что сигнал опоздал, а потому, что риск перед проблемой не рос, а стоял на месте. Это как если бы облака не сгущались, а просто висели ровно — и внезапно пошёл дождь. Кроме того, иногда важно смотреть не на сам момент начала проблемы, а на последнюю «чистую» минуту до неё: если смотреть уже под дождём, можно не увидеть, было ли облако раньше. Это методологическая, но вполне житейская тонкость.

Какой вариант выбрать?

Вывод простой: не нужно выбирать между «шумным, но чувствительным» и «точным, но редким» сигналом. Нужна комбинированная схема.

«Быстрое» облако разумно использовать как основной оперативный сигнал: у него стабильная доля полезных срабатываний — около четырёх из десяти — и компактные предупреждения.

«Фоновое» облако — как широкий ранний фон: оно покрывает больше проблем и даёт длинный запас времени, но требует ограничения длительности и регулярной проверки: если доля полезных срабатываний падает ниже примерно четырёх-пяти из десяти, его операционная ценность снижается.

Можно представить это как два уровня оповещения.

«Быстрое» облако — жёлтый уровень: «посмотрите на небо, будьте внимательны».

«Фоновое» — оранжевый: «вероятность высокая, готовьте защитные механизмы».

Вместе они дают не хрустальный шар, а надёжного синоптика, который вовремя говорит: «облака сгущаются — проверьте систему», и при этом не обещает ливень там, где его может и не быть.

В итоге вероятностная модель для базы данных — это не оракул и не гениальный предсказатель. Это метеостанция, которая каждую минуту описывает «погоду», учится на последовательностях состояний, постепенно забывает старое и выдаёт вероятностный прогноз.

Сигналы-флажки — это облака. Дождь почти всегда приходит под облаком, но облако не гарантирует дождь.

Поэтому лучшая система — не один флажок, а сочетание широкого фона и быстрого подтверждения, с честной оценкой вероятностей и регулярным наблюдением за тем, насколько облака действительно предвещают дождь.

1. Введение

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

Предлагаемая система реализует следующие ключевые идеи:

• Дискретизация пространства состояний на основе корреляции и трендов ключевых метрик

• Адаптивное забывание с учётом времени с последнего инцидента

• Многоуровневая система сигналов (SICPP, C-alone)

• Динамическое определение критических состояний на основе эмпирического риска

2. Архитектура системы

2.1. Компоненты

Система включает следующие модули:

• mchain_train_step() — ежеминутное обучение и обновление состояния.

• sicpp_calculate_at() — расчёт сигнала SICPP на заданный момент.

• mchain_hybrid_alert_at() — операционный индикатор C-alone.

• compare_profiles_at() — сравнение текущего профиля с эталоном.

• refresh_critical_states() — динамическое обновление критических состояний.

2.2. Уровни сигнализации

Система реализует трёхуровневую сигнализацию:

1. SICPP (Signal Indicating a Change in the Performance Profile) — контекстный индикатор режима, триггерит WARNING.

2. C-alone — операционный индикатор на основе risk_p90 >= 0.98 AND js_avg >= 0.14, триггерит ALARM.

3. Integral status (get_current_preincident_status()) — агрегирует все сигналы.

3. Экспериментальные результаты

3.1. Качество прогнозирования

На основе данных за период 2026-10-12 – 2026-10-26 (38 инцидентов) получены следующие метрики:

• ROC-AUC: 0.9287 — отличная дискриминация.

• Brier score: 0.0638 — хорошая калибровка.

• Покрытие SICPP: 97.4% — почти все инциденты покрыты.

• Precision эпизодов: 53.2% — умеренная точность.

• C-alone precision: 34.5% — приемлемая точность.

• C-alone recall: 51.4% — умеренная полнота.

3.2. Калибровочная кривая

• Бин вероятности [0.1–0.2]: предсказано 0.124, фактически 0.134, n = 10008.

• Бин вероятности [0.8–0.9]: предсказано 0.816, фактически 0.796, n = 588.

• Бин вероятности [0.9–1.0]: предсказано 1.000, фактически 0.998, n = 9392.

Калибровка близка к идеальной, особенно в диапазоне высоких вероятностей.

3.3. Распределение lead time

• p50, мин: ALL (raw) = 143.0; SHORT (≤800 мин) = 96.5.

• p90, мин: ALL (raw) = 987.8; SHORT (≤800 мин) = 281.5.

• mean, мин: ALL (raw) = 357.0; SHORT (≤800 мин) = 156.6.

• max, мин: ALL (raw) = 1115.0; SHORT (≤800 мин) = 777.0.

Метрики SHORT отражают «типичное» предаварийное состояние без искажения длинными эпизодами.

4. Сценарии применения

4.1. Сценарий 1: Прогнозирование инцидентов

Задача: Заблаговременно предупредить о риске возникновения инцидента.

Решение: Использование mchain_predict_risk_current_horizon() с горизонтом 120 минут.

Пример:

SELECT mchain_predict_risk_current_horizon();
-- Результат: 0.87 (высокий риск)

Интерпретация: При риске ≥ 0.90 рекомендуется активировать режим повышенного мониторинга; при риске ≥ 0.95 — рассмотреть превентивные меры.

4.2. Сценарий 2: Диагностика деградации через сравнение профилей

Задача: Обнаружить отклонение текущего режима работы от эталонного.

Решение: Использование compare_profiles_at() с JS-дивергенцией гистограмм состояний.

Пример:

SELECT unnest(compare_profiles_at(now()));
-- Результат: JS-дивергенция = 0.23, статус = CRITICAL

Интерпретация:

• JS < 0.05 — профиль соответствует эталону.

• 0.05 ≤ JS < 0.2 — умеренные отклонения (WARNING).

• JS ≥ 0.2 — значительные отклонения (CRITICAL).

4.3. Сценарий 3: Оперативное оповещение (C-alone)

Задача: Минимизировать ложные срабатывания при сохранении приемлемого recall.

Решение: Использование mchain_hybrid_alert_at() с параметрами C-only.

Пример:

SELECT alert, fired_c, risk_p90, js_avg
FROM mchain_hybrid_alert_at(now());
-- Результат: alert=true, fired_c=true, risk_p90=0.99, js_avg=0.18

Преимущества C-alone:

• Precision 34.5% vs 12.5% для A∪C.

• Recall 51.4% — приемлемый уровень.

• ALERT-time 14.1% — низкая нагрузка на оператора.

4.4. Сценарий 4: Оптимизация эталонных профилей

Задача: Автоматически выбирать репрезентативные периоды для эталона.

Решение: Использование find_incident_free_window() с проверкой is_valid_baseline_window().

Критерии валидности эталонного окна:

1. Целиком в периоде продуктивной нагрузки (9:00–18:00).

2. Начинается не ранее чем через 60 мин после завершения инцидента.

3. Не пересекается с инцидентами.

4. Возраст не превышает 12 часов.

4.5. Сценарий 5: Динамическое определение критических состояний

Задача: Адаптировать список «аварийных» состояний к текущим условиям.

Решение: Использование refresh_critical_states() с эмпирической оценкой риска.

Пример:

SELECT refresh_critical_states(
p_start := now() - interval '14 days',
p_risk_threshold := 0.10,
p_min_transitions := 20
);
-- Результат: добавлено 3, удалено 1 состояние

Важно: Порог p_risk_threshold > 0.10 запрещён (тест 24 показал деградацию метрик).

Заключение

Представлена система анализа и прогнозирования производительности PostgreSQL на основе цепей Маркова.

Экспериментальные результаты демонстрируют высокое качество прогнозирования (ROC-AUC = 0.9287, Brier = 0.0638) и практическую применимость для раннего обнаружения инцидентов.

Рассмотренные сценарии применения охватывают прогнозирование, диагностику, оперативное оповещение и оптимизацию эталонов.

Дальнейшее развитие связано с расширением пространства состояний и интеграцией с современными системами мониторинга.