Платформа оценки устойчивости ИТ-систем

PhaseShift

Белая книга продукта

Версия: 0.5

Статус: продуктовая и исследовательская концепция

Дата: 30 августа 2026

Модель поставки: коробочная, внутри контура заказчика

Основной источник данных первой версии: Zabbix

1. Резюме

PhaseShift — платформа поведенческого моделирования ИТ-инфраструктуры.

Она подключается к уже существующей системе мониторинга заказчика, в первой версии — к Zabbix, и строит модель того:

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

Базовая архитектурная идея:

Zabbix
  ↓
Модель состояния PhaseShift
  ↓
Модель отклика PhaseShift
  ↓
Модель дрейфа PhaseShift
  ↓
Модель устойчивости PhaseShift
  ↓
объяснимые выводы и модельные сценарии

Ключевая продуктовая гипотеза PhaseShift состоит не в том, чтобы обнаруживать очередную аномалию отдельной метрики.

PhaseShift должен пытаться восстановить законы наблюдаемого поведения конкретной системы и отслеживать, не изменились ли сами эти законы.

Условно:

обычный мониторинг:
изменился ли Y?

PhaseShift:
изменилась ли функция Y = F(X, контекст)?

Пример:

раньше:
+10 мс задержки PostgreSQL
→ +3 мс API p95

теперь:
+10 мс задержки PostgreSQL
→ +15 мс API p95
→ рост повторных запросов
→ рост очереди

Даже если абсолютные показатели ещё не нарушают SLA, это уже может означать, что система стала чувствительнее и менее способна гасить обычные колебания.

2. Основное позиционирование

PhaseShift не заменяет Zabbix.

PhaseShift не должен конкурировать с существующими средствами мониторинга за функцию сбора телеметрии.

Короткая формула:

Zabbix = наблюдения
PhaseShift = модель

Основное позиционирование:

PhaseShift строит поведенческую модель ИТ-инфраструктуры по эксплуатационной телеметрии и показывает, когда меняются не только показатели, но и сама реакция системы на нагрузку и зависимости.

После того как модель подтверждена экспериментально и способна отвечать на вопросы вида «что будет при изменении X?», её можно корректно называть поведенческим цифровым двойником.

3. Что PhaseShift не является

PhaseShift не является:

• заменой Zabbix;
• классической системой мониторинга;
• APM;
• SIEM;
• очередной системой обнаружения аномалий;
• нагрузочным тестером;
• системой управляемых экспериментов с отказами;
• точной виртуальной копией рабочего контура;
• универсальным предсказателем аварий;
• системой, которая обещает точное время будущего отказа.

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

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

если изменить наблюдаемый вход или внутренний параметр модели, как изменится распределение отклика системы?

4. Главный объект моделирования

Пусть наблюдаемое состояние ИТ-системы в момент времени:

Вектор может включать:

• CPU;
• память;
• дисковую нагрузку;
• сетевые показатели;
• количество соединений;
• задержки;
• ошибки;
• повторные запросы;
• размер очередей;
• показатели БД;
• активные сессии;
• загрузку пулов;
• показатели среды выполнения;
• характеристики графа зависимостей.

Также существует наблюдаемая нагрузка:

Контекст:

и граф системы:

PhaseShift должен восстанавливать зависимость:

Функция $F$ здесь не обязана быть одной аналитической формулой.

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

5. Четыре математических слоя PhaseShift

5.1. Модель состояния

Отвечает:

Что является нормальным состоянием системы при текущих условиях?

Модель состояния учитывает:

• текущую нагрузку;
• время суток;
• день недели;
• сезонность;
• топологию;
• версии приложений;
• фоновые процессы;
• ранее подтверждённые стабильные периоды.

Условно:

Остаток:

Модель состояния нужна для того, чтобы не считать высокой CPU-нагрузкой проблему, если такая нагрузка нормальна при текущем объёме работы.

5.2. Модель отклика

Это центральный слой PhaseShift.

Он отвечает:

Как изменение одного наблюдаемого параметра отражается на других параметрах системы при заданном контексте?

Пример:

вход:
запросов/с +10%

отклик:
задержка API +4%
соединения с БД +7%
CPU +6%

или:

вход:
задержка БД +10 мс

отклик:
API p95 +3 мс
доля повторных запросов +0.2%

Модель отклика фактически описывает передаточные характеристики системы.

Именно этот слой является главным отличием PhaseShift от обычного анализа отдельных показателей.

5.3. Модель дрейфа

Отвечает:

Не изменилась ли модель отклика?

Например:

месяц назад:
+10% нагрузка → +6% CPU

сейчас:
+10% нагрузка → +14% CPU

или:

месяц назад:
БД +10 мс → API +3 мс

сейчас:
БД +10 мс → API +15 мс

Модель дрейфа должна искать изменение:

• коэффициентов чувствительности;
• временных задержек;
• вариативности;
• корреляционной структуры;
• распространения;
• усиления;
• времени затухания.

5.4. Модель устойчивости

Только после модели состояния, отклика и дрейфа появляется модель устойчивости.

Она отвечает:

Есть ли совокупность признаков, указывающих на снижение способности системы сохранять устойчивый рабочий режим?

Первая версия должна показывать компоненты отдельно:

Память
Чувствительность
Изменчивость
Распространение
Усиление
Запас устойчивости
Устойчивость топологии

Единый показатель устойчивости вводится только после лабораторной и полевой валидации.

6. Поведенческий цифровой двойник

Поведенческий цифровой двойник PhaseShift — это не копия серверов.

Он должен представлять:

1. структуру системы;
2. рабочую нагрузку;
3. контекст;
4. условные распределения состояний;
5. статистические зависимости;
6. динамические модели отклика;
7. подтверждённые устойчивые эталоны;
8. изменения модели во времени.

Формально:

Двойник = {
  Модель состояния,
  Модель отклика,
  Модель топологии,
  Модель контекста,
  Устойчивые эталоны,
  Модель динамики
}

7. Критерий, позволяющий честно использовать термин «цифровой двойник»

PhaseShift должен пройти следующий тест.

По накопленной телеметрии модель обучена на зависимости:

X → система → Y

После этого системе задаётся контрфактический вопрос:

если X изменить на ΔX,
каким станет распределение Y?

Прогноз модели сравнивается с контролируемым экспериментом.

Если модель воспроизводимо отвечает на такие вопросы в некоторой области параметров, термин «поведенческий цифровой двойник» имеет техническое основание.

Если продукт умеет только:

• строить топологию;
• рассчитывать базовый уровень;
• находить аномалии;
• показывать дрейф;

его правильнее называть системой поведенческой аналитики, а не цифровым двойником.

8. Zabbix как основной слой наблюдений

Для первой версии PhaseShift основной сценарий:

Рабочий контур
    ↓
Агенты Zabbix
    ↓
Сервер Zabbix
    ↓
Модуль подключения PhaseShift
    ↓
Ядро PhaseShift

Причины такого решения:

• у корпоративного заказчика мониторинг уже существует;
• установка нового неизвестного агента в рабочем контуре создаёт высокий барьер;
• Zabbix имеет длительную историю метрик;
• интеграция может работать в режиме только чтения;
• пробное внедрение не требует вмешательства в рабочий контур;
• PhaseShift может работать полностью внутри контура заказчика.

9. Модуль подключения PhaseShift

Модуль подключения должен импортировать:

• узлы;
• группы узлов;
• шаблоны;
• элементы;
• историю;
• динамику;
• триггеры;
• события;
• метки;
• окна обслуживания;
• метаданные сервисов, где доступно.

Доступ:

только чтение

PhaseShift не изменяет конфигурацию Zabbix автоматически.

10. Модель охвата телеметрии

PhaseShift должен сначала определить, что он вообще способен увидеть.

Пример:

Охват данных: 81%

CPU                   достаточно
Память                достаточно
Диск                  достаточно
Скорость запросов          достаточно
PostgreSQL            достаточно
Очередь                 частично
Сетевые потоки         недоступно
События выпуска     недоступно

Для каждой аналитической задачи должна существовать оценка достаточности данных.

Например:

модель состояния             достаточно
модель отклика                частично
модель распространения        недостаточна
Сравнение выпусков      недостаточно

11. Рекомендации по расширению Zabbix

Если данных недостаточно, PhaseShift должен выдавать конкретные рекомендации.

Например:

Для модели отклика платёжного контура рекомендуется добавить:

- HTTP запросов/с
- PostgreSQL активные соединения
- PostgreSQL скорость транзакций
- RabbitMQ размер очереди

Сначала используются стандартные возможности Zabbix.

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

12. Типовые профили

Чтобы внедрение не превращалось в индивидуальную разработку, PhaseShift должен иметь библиотеку профилей.

Примеры:

Веб-приложение
Интернет-магазин
1C / ERP
PostgreSQL
MS SQL
IIS
Nginx
Redis
RabbitMQ
Kafka
Active Directory
Терминальный сервер
Файловый сервер
Kubernetes
Узел виртуализации
Корпоративная рабочая станция

Профиль задаёт стартовые предположения:

• полезные метрики;
• показатели нагрузки;
• типичные зависимости;
• типовые ограничения;
• вероятные входы и выходы модели отклика.

13. Настройка параметров

Профиль параметризуется телеметрией заказчика.

Типовой профиль
       +
Телеметрия заказчика
       ↓
Настройка параметров
       ↓
Модель заказчика

Модель не должна считать два PostgreSQL-сервера разных организаций одинаковыми только потому, что это PostgreSQL.

Профиль — предварительное знание.

Реальное поведение определяется данными.

14. Модель нагрузки

Нужно определить вход системы.

Для интернет-магазина это могут быть:

• запросов/с;
• активные сессии;
• заказы/мин;
• транзакции/сек;
• число соединений;
• сообщения/сек.

Формируется многомерный вектор нагрузки:

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

Нужно иметь наблюдаемые показатели интенсивности работы.

15. Модель контекста

Контекст включает:

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

Модели состояния и отклика сравниваются только в сопоставимом контексте.

16. Устойчивый эталон

Адаптивный базовый уровень способен привыкнуть к деградации.

Поэтому PhaseShift должен хранить подтверждённые устойчивые эталоны.

Например:

Эталон A:
1–15 июня

Эталон B:
3–17 июля

Текущее поведение сравнивается одновременно с:

• краткосрочным базовым уровнем;
• долгосрочным базовым уровнем;
• устойчивыми эталонами.

17. Память

Память описывает, насколько долго прошлое состояние влияет на настоящее.

Исследуемые показатели:

• автокорреляция;
• затухание автокорреляции;
• время корреляции;
• время восстановления для явно различимых событий.

Увеличение системной памяти может соответствовать более медленному затуханию отклонений.

18. Изменчивость

Исследуются:

• дисперсия;
• MAD;
• IQR;
• p95/p99;
• разброс хвоста;
• волатильность.

Особенно важна ситуация:

среднее почти не изменилось
но распределение стало шире
и хвосты тяжелее

19. Чувствительность

Чувствительность — один из центральных объектов PhaseShift.

Пример:

раньше:
+10% вход
→ +4% отклик

сейчас:
+10% вход
→ +17% отклик

PhaseShift должен измерять не только величину показателя, но и изменение производной:

или её статистического аналога.

20. Распространение

PhaseShift анализирует, как изменение распространяется по графу.

Пример:

PostgreSQL
   ↓
Платёжный API
   ↓
Повторные запросы
   ↓
API заказов
   ↓
Очередь

Показатели:

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

21. Усиление

Отклонение может:

затухать
сохраняться
усиливаться

Особенно важны следующие механизмы:

• усиление повторных запросов;
• усиление очереди;
• петли обратной связи;
• каскадный рост задержки;
• эффекты пула соединений.

PhaseShift должен оценивать, как по цепочке меняется коэффициент передачи возмущения.

22. Модель топологии

PhaseShift должен иметь наблюдаемую структуру:

Узел
→ Процесс / сервис
→ Зависимость
→ Внешняя конечная точка

Само по себе автоматическое обнаружение топологии не является конкурентным преимуществом: крупные платформы наблюдаемости уже строят развитые графы зависимостей.

Для PhaseShift топология — необходимый вход для моделей отклика и распространения.

23. Лаборатория заказчика

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

Назначение лаборатории:

• сценарии «что будет, если…»;
• контролируемые синтетические сценарии;
• проверка модели;
• эксперименты с чувствительностью;
• сравнение версий модели.

24. Сценарий «что будет, если…»

Пример:

Сценарий:
задержка PostgreSQL +20%

Модель:
API p95                         +13%
чувствительность повторных запросов +19%
изменчивость очереди            +31%

Уровень доверия: средний

Результат обязательно маркируется как модельный. Нельзя обещать детерминированный результат в рабочем контуре.

25. Исследовательская лаборатория

Исследовательская лаборатория — внутренняя среда разработки PhaseShift. Она отвечает на фундаментальный вопрос:

можно ли восстановить модель отклика по пассивным наблюдениям?

Эксперимент:

Известный вход X
      ↓
Известная тестовая система
      ↓
Выход Y

PhaseShift видит только телеметрию, доступную через Zabbix, и строит:

После этого лаборатория меняет внутренний параметр:

• задержку БД;
• пул соединений;
• пропускную способность обработчика;
• ограничение CPU;
• политику повторных запросов.

PhaseShift должен увидеть изменение $\hat{F}$.

26. Главный лабораторный критерий

Важно проверять не то, увидел ли PhaseShift высокую загрузку CPU, а следующее:

обнаружил ли PhaseShift изменение модели отклика раньше обычного эксплуатационного нарушения?

27. Сравнение с простыми методами

Каждый эксперимент должен сравниваться с базовыми методами:

• статическим порогом;
• адаптивным порогом;
• динамикой p95/p99;
• скользящим средним;
• обнаружением аномалий;
• дрейфом показателей;
• мониторингом насыщения.

PhaseShift имеет смысл только там, где даёт более ранний сигнал, точнее локализует проблему, лучше объясняет её или позволяет построить сценарий «что будет, если…», недоступный простым методам.

28. Конкурентный рынок

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

Основные ориентиры и конкуренты:

1. Dynatrace;
2. Splunk IT Service Intelligence;
3. ScienceLogic SL1;
4. Forward;
5. NetBrain.

29. Dynatrace

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

Dynatrace Intelligence использует топологию и контекст зависимостей для построения базового уровня, обнаружения аномалий и причинно-следственного анализа. Сезонный базовый уровень строится по историческому временному ряду с доверительным диапазоном. Интеграция Zabbix → Dynatrace импортирует узлы и проблемы Zabbix и обогащает топологию Dynatrace.

Вывод для PhaseShift

Не являются отличительными признаками:

• топология;
• граф зависимостей;
• сезонный базовый уровень;
• обнаружение аномалий;
• связь с изменениями;
• сам факт подключения Zabbix.

PhaseShift должен отличаться моделью отклика и изменением передаточных характеристик, а не только более совершенным базовым уровнем.

30. Splunk IT Service Intelligence

Splunk IT Service Intelligence строит сервисы, сущности, показатели и оценку состояния сервисов. Адаптивные пороги автоматически изменяются по историческому поведению показателей.

Особенно важна функция обнаружения дрейфа показателей: Splunk прямо обнаруживает постепенное или быстрое изменение поведения показателя за длительный период. Поэтому утверждение «мы замечаем медленный дрейф, пока система ещё работает» само по себе не является достаточным отличием PhaseShift.

Граница отличия

Splunk преимущественно анализирует изменение показателя:

Y(t) изменился

PhaseShift должен анализировать:

связь X → Y изменилась

Например:

не:
задержка API растёт

а:
влияние задержки БД на задержку API выросло в 4 раза

Именно это должно стать центром продукта.

31. ScienceLogic SL1

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

Индекс аномалий показывает значение от 0 до 100: насколько реальная метрика отклоняется от нормального режима.

Вывод для PhaseShift

PhaseShift не должен сводиться к схеме:

телеметрия
→ базовый уровень
→ оценка аномальности

Это уже зрелый рыночный класс. Наш объект — не отклонение X, а изменение отношений между X1...Xn.

32. Forward

Forward — важный технологический ориентир для понятия настоящего цифрового двойника. Forward Predict проверяет предлагаемое изменение на математически точном цифровом двойнике рабочей сети до его применения.

Forward моделирует плоскость управления и плоскость данных сети; он позволяет проверять связность, безопасность и соответствие требованиям до внедрения.

Аналогия

Forward:
конфигурация сети
→ цифровой двойник сети
→ будущее состояние сети

PhaseShift:
параметр поведения
→ поведенческий двойник
→ будущее распределение отклика

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

33. NetBrain

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

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

Идея для PhaseShift

У PhaseShift может существовать аналог поведенческого намерения:

Наблюдаемое поведение
        ↓
Поведенческий двойник
        +
Устойчивый эталон
        ↓
Ожидаемое поведение

Устойчивый эталон фактически становится наблюдаемым поведенческим намерением системы.

34. Конкурентная матрица

Примечание: отсутствие публично описанной функции не означает, что соответствующий алгоритм отсутствует во внутренней реализации конкурента. Матрица описывает публичное продуктовое позиционирование и документированные сценарии.

35. Рыночная граница PhaseShift

PhaseShift не должен конкурировать тезисом: «Мы строим топологию и понимаем базовый уровень». Эта территория уже занята.

Также недостаточно утверждать: «Мы видим долгосрочный дрейф». Дрейф показателей уже существует у крупных платформ.

Предлагаемая граница PhaseShift:

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

36. Математическое отличие

Конкурентный объект во многих существующих системах:

Вопрос:

необычен ли Y?
растёт ли Y?
изменился ли базовый уровень Y?

PhaseShift рассматривает:

Вопрос:

не изменилась ли F?

То есть PhaseShift ищет изменение чувствительности:

временных лагов:

и структуры распространения:

37. Пример отличия

Пусть наблюдаются:

задержка PostgreSQL
задержка API
доля повторных запросов
размер очереди

Традиционный анализ может сообщить:

задержка PostgreSQL в пределах нормы
задержка API в пределах нормы
доля повторных запросов в пределах нормы

PhaseShift должен увидеть:

раньше:
PostgreSQL +10 мс
→ API +3 мс
→ повторные запросы +0,1%

теперь:
PostgreSQL +10 мс
→ API +14 мс
→ повторные запросы +1,3%
→ очередь +12%

Вывод:

Передаточная чувствительность платёжного контура к задержке PostgreSQL выросла; эффект теперь распространяется на очередь.

Это и есть желаемый продуктовый результат.

38. Что является настоящим цифровым двойником PhaseShift

Минимальный тест:

1. Есть реальные наблюдения.
2. По ним построена модель отклика.
3. Задаётся изменение входа.
4. Модель прогнозирует распределение отклика.
5. Лаборатория или будущие реальные наблюдения подтверждают прогноз в допустимом диапазоне ошибок.

Только после этого конкретная модель получает статус:

Цифровой двойник подтверждён

До этого:

Поведенческая модель

39. Уровень доверия модели

Каждая модель отклика должна иметь:

Охват данных
Уровень доверия
Ошибка проверки
Применимый диапазон
Последняя проверка

Пример:

Модель:
задержка PostgreSQL → платёжный API p95

Уровень доверия: высокий
Наблюдаемый диапазон: 2–45 мс
Средняя абсолютная ошибка проверки: 3.8 мс
Последняя проверка: 4 дня назад

Нельзя экстраполировать далеко за пределы обучающего диапазона без отдельного предупреждения.

40. Подключение продукта

1. Установить сервер PhaseShift.
2. Подключить Zabbix в режиме только чтения.
3. Импортировать историю.
4. Обнаружить компоненты.
5. Получить отчёт об охвате данных.
6. Классифицировать компоненты.
7. Определить показатели нагрузки.
8. Построить модель состояния.
9. Построить первые модели отклика.
10. Выбрать устойчивый эталон.
11. Включить анализ дрейфа.
12. После проверки включить лабораторию заказчика.

41. Первая рабочая версия

Первая рабочая версия PhaseShift должна включать:

1. модуль подключения к Zabbix;
2. инвентаризацию телеметрии;
3. проверку охвата данных;
4. библиотеку профилей;
5. классификацию компонентов;
6. модель нагрузки;
7. модель контекста;
8. модель состояния;
9. условный базовый уровень;
10. модель отклика для ограниченного класса зависимостей;
11. модель дрейфа отклика;
12. объяснимые выводы;
13. исследовательскую лабораторию;
14. проверку модели;
15. минимальный интерфейс сценариев «что будет, если…».

42. Чего не должно быть в первой версии продукта

Не требуется:

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

Нужно выбрать один хорошо наблюдаемый контур.

Например:

Веб-сервис / API
→ PostgreSQL

или:

API
→ Очередь
→ Обработчик
→ PostgreSQL

43. Первый эксперимент

Система:

Генератор нагрузки
      ↓
API
      ↓
PostgreSQL

Zabbix видит:

• скорость запросов;
• задержку API;
• CPU;
• память;
• задержку БД;
• активные соединения;
• скорость транзакций.

PhaseShift строит модель отклика. Затем лаборатория постепенно меняет задержку БД:

0
10
20
40
80
120 мс

Задачи:

1. восстановить зависимость задержки БД → отклик API;
2. оценить чувствительность;
3. определить задержку реакции;
4. определить диапазон применимости;
5. увидеть изменение модели отклика при скрытом изменении пула соединений или политики повторных запросов;
6. сравнить сигнал с обычными порогами Zabbix.

44. Второй эксперимент

Не менять входное воздействие. Изменить внутреннее свойство:

пул соединений:
100 → 50 → 25

Нагрузка продолжает естественно колебаться. PhaseShift не знает, что изменён пул.

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

45. Третий эксперимент

Создать обратную связь:

задержка нижестоящего сервиса
→ повторные запросы
→ дополнительная нагрузка
→ очередь

Цель:

• модель отклика;
• распространение;
• усиление;
• сравнение с обычным обнаружением аномалий.

46. Фальсифицируемость

PhaseShift должен быть исследовательски честным. Гипотеза считается неподтверждённой для конкретного класса систем, если:

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

47. Предкритическое состояние

Предкритическое состояние вводится только поверх проверенных моделей. Условие может выглядеть как совокупность:

Чувствительность ↑
Сохранение отклонения ↑
Распространение ↑
Усиление ↑

при сохранении:

SLA соблюдается

Предкритическое состояние — не утверждение «авария скоро». Корректный смысл:

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

48. Критическая область

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

49. Безопасность и поставка

PhaseShift работает внутри контура заказчика.

Базовые требования:

• развёртывание в контуре заказчика;
• интеграция с Zabbix только для чтения;
• RBAC;
• аудит;
• шифрование при передаче;
• локальное хранение;
• отсутствие обязательного доступа к интернету;
• настраиваемый срок хранения;
• отсутствие передачи телеметрии рабочего контура производителю по умолчанию.

50. Основные экраны

Охват модели

Что PhaseShift видит и чего не хватает.

Модель состояния

Как выглядит нормальное состояние в текущем контексте.

Карта отклика

Какие наблюдаемые параметры статистически влияют друг на друга.

Дрейф модели отклика

Какие связи отклика изменились.

Анализ устойчивости

Память, чувствительность, изменчивость, распространение, усиление, запас устойчивости и топология.

Лаборатория заказчика

Сценарии «что будет, если…» и уровень доверия.

51. Пример карты отклика

Запросов/с
   │ +0.61
   ▼
CPU API
   │ +0.38
   ▼
Задержка API

Задержка PostgreSQL
   │ +0.74
   ▼
Задержка API
   │ +0.26
   ▼
Повторные запросы

Числа условно представляют нормированный коэффициент отклика.

52. Пример дрейфа модели отклика

Задержка PostgreSQL → задержка API

Коэффициент эталона:
0.31

Текущий коэффициент:
0.72

Изменение:
+132%

Уровень доверия: высокий

Наблюдается: 11 дней

Связанное изменение: выпуск 4.28

53. Главная коммерческая ценность

PhaseShift должен быть полезен инженеру до аварии и даже без аварии.

Примеры вопросов:

• Система стала чувствительнее к нагрузке?
• Как изменилось поведение после выпуска?
• Какая зависимость стала сильнее влиять на нижестоящий сервис?
• Где отклонение перестало нормально затухать?
• Изменился ли эффект очередного роста нагрузки?
• Что модель ожидает при +20% входного потока?
• Какие отношения между компонентами меняются, хотя сами показатели пока зелёные?

54. Основная технологическая компетенция

Пассивное восстановление и непрерывная проверка модели отклика сложной ИТ-системы по эксплуатационной телеметрии.

Второй уровень компетенции:

обнаружение дрейфа этой модели отклика.

Третий:

контрфактическое моделирование и анализ устойчивости.

55. Продуктовая дорожная карта

Модель PhaseShift

• подключение Zabbix;
• модель состояния;
• модель отклика;
• дрейф модели отклика.

Устойчивость PhaseShift

• память;
• чувствительность;
• распространение;
• усиление;
• исследование предкритического состояния.

Лаборатория PhaseShift

• проверенные сценарии «что будет, если…»;
• синтетические сценарии;
• оценка влияния изменений.

Расширения PhaseShift

• Prometheus;
• OpenTelemetry;
• необязательный модуль Zabbix Agent 2;
• собственные датчики только при доказанной необходимости.

56. Конкурентная стратегия

Не пытаться победить Dynatrace, Splunk или ScienceLogic количеством функций наблюдаемости.

Не строить собственные средства мониторинга.

Не пытаться повторить сетевой цифровой двойник Forward или NetBrain.

Стратегия:

1. использовать существующую телеметрию;
2. быть узким аналитическим слоем;
3. решить задачу модели отклика лучше остальных;
4. доказать дрейф отклика;
5. доказать сценарий «что будет, если…»;
6. только после этого расширять платформу.

57. Критерии успеха пилота

Первый пилот успешен, если PhaseShift:

1. подключается к существующему Zabbix только для чтения;
2. импортирует исторические данные;
3. строит модель состояния одного критичного контура;
4. восстанавливает хотя бы одну полезную модель отклика;
5. показывает уровень доверия и область применимости;
6. обнаруживает хотя бы один исторический дрейф модели отклика;
7. связывает дрейф с конкретным участком системы;
8. демонстрирует сценарий «что будет, если…», подтверждаемый историей или контролируемым экспериментом;
9. даёт инженеру вывод, которого нет в обычных панелях и триггерах Zabbix;
10. делает это без установки нового агента в рабочем контуре.

58. Критерий неуспеха

PhaseShift не имеет достаточной продуктовой новизны, если итоговая система сводится к:

история Zabbix
→ базовый уровень
→ обнаружение аномалий
→ красивая панель мониторинга

Такой продукт будет конкурировать на зрелом рынке с гораздо более крупными платформами.

PhaseShift имеет основание существовать как отдельный продукт только в том случае, если модель отклика и её дрейф дают новую измеримую ценность.

59. Короткая формула продукта

Наблюдать
  ↓
Моделировать состояние
  ↓
Моделировать отклик
  ↓
Обнаруживать дрейф модели отклика
  ↓
Оценивать устойчивость
  ↓
Запускать сценарий «что будет, если…»

60. Итог

PhaseShift — не система, которая пытается собрать больше метрик, и не система, которая просто ищет необычные значения.

Её главный объект:

изменение реакции ИТ-системы.

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

После этого становится возможным обнаруживать ситуацию:

показатели всё ещё допустимы, но система уже реагирует на те же воздействия иначе.

Именно изменение модели отклика является потенциальной границей между PhaseShift и существующими продуктами наблюдаемости и интеллектуальной эксплуатации.

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

61. Источники конкурентного анализа

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

Dynatrace

• Smartscape Service dependency graph:

https://docs.dynatrace.com/docs/analyze-explore-automate/smartscape/smartscape-views/service-dependency-graph

• Smartscape views:

https://docs.dynatrace.com/docs/analyze-explore-automate/smartscape/smartscape-views

• Dynatrace Intelligence:

https://docs.dynatrace.com/docs/dynatrace-intelligence

• Seasonal baseline:

https://docs.dynatrace.com/docs/dynatrace-intelligence/reference/ai-models/seasonal-baseline

• Zabbix Integration:

https://www.dynatrace.com/hub/detail/zabbix-integration/

Splunk IT Service Intelligence

• KPI drift detection:

https://help.splunk.com/en/splunk-it-service-intelligence/splunk-it-service-intelligence/visualize-and-assess-service-health/5.0/create-kpis/monitor-kpi-data-drift-in-itsi

• Adaptive KPI thresholds:

https://help.splunk.com/en/splunk-it-service-intelligence/splunk-it-service-intelligence/visualize-and-assess-service-health/5.0/advanced-thresholding/create-adaptive-kpi-thresholds-in-itsi

• Service Insights:

https://help.splunk.com/en/splunk-it-service-intelligence/splunk-it-service-intelligence/visualize-and-assess-service-health/5.0/overview/overview-of-service-insights

ScienceLogic SL1

• AIOps / common data model:

https://sciencelogic.com/articles/aiops

• ML-based anomaly detection:

https://docs.sciencelogic.com/latest/Content/Web_Events_and_Automation/Anomaly_Detection/anomaly_detection_title_page.htm

• Anomaly Index:

https://docs.sciencelogic.com/release_notes_html/Content/12-1-0/12-1-0-2_release_notes.htm

Forward

• Forward Predict:

https://www.forwardnetworks.com/predict/

• Forward Predict launch:

https://www.forwardnetworks.com/blog/press-release/forward-launches-forward-predict-to-unlock-autonomous-networking/

• Technical/product description of network digital twin and Predict:

https://www.forwardnetworks.com/blog/2026/05/19/predict-today-your-network-can-see-its-future/

NetBrain

• Digital Twin / network mapping:

https://www.netbraintech.com/wp-content/uploads/2022/03/NetBrain-Network-Mapping-And-The-Digital-Twin.pdf

• Release 11.1a / intent-based diagnosis and assessment:

https://www.netbraintech.com/docs/R11-1a/NetBrain_Release_Note_R11-1a.pdf

Конкурентный анализ следует пересматривать перед каждым крупным продуктовым этапом.