Как граф зависимостей превращается в модель надёжности

Практическая проблема начинается с ручной архитектурной схемы: она полезна для разговора, но устаревает быстрее системы и плохо подходит для регулярного расчёта. В работе Красновского модель обнаруживается автоматически. Jaeger показывает наблюдаемые блокирующие вызовы, deployment-данные — число экземпляров, а профиль нагрузки — вес пользовательских операций. Получается версионируемый граф с provenance, который можно пересобирать после изменения топологии. Автоматическое обнаружение не делает граф полной истиной: он отражает только вызовы, попавшие в выбранные трассы и нагрузку. Зато происхождение каждого ребра можно объяснить и обновить, что важнее красивой, но не проверяемой схемы для регулярного анализа изменений.

Далее Monte Carlo многократно выбирает фиксированную долю отказавших контейнеров и проверяет, сохранился ли обязательный путь для каждого endpoint. Модель считает долю успешных запросов, а живой стенд — запросы без 5xx, разрывов соединения и таймаутов. Семантика ребра критична: необязательный или асинхронный вызов нельзя автоматически считать блокирующим, иначе расчёт отвечает уже на другой вопрос. Вес пользовательских операций также влияет на общий показатель: отказ редкого endpoint и отказ основного сценария не должны давать одинаковый вклад. Поэтому до симуляции команда формулирует, что именно считает успешным запросом и для какого профиля нагрузки.

Эксперимент использует Social Network из DeathStarBench: длинные синхронные цепочки, fan-out и три взвешенных сценария — home timeline, user timeline и compose post. Сравнивались режимы без реплик и с тремя экземплярами пяти ключевых сервисов. При доле отказов 0,3 модель и стенд с репликацией дали 0,3054; по десяти точкам расширенной матрицы корреляция составила около 0,992. Репликация меняет вероятность сохранения пути, но не гарантирует линейного улучшения каждого сценария: значение зависит от положения сервиса в графе и fan-out. Именно поэтому структурная модель полезнее простого подсчёта экземпляров — она показывает, где дополнительная копия действительно влияет на пользовательский путь.

Это хорошая способность ранжировать риск, а не сертификат точной доступности. Базовая модель предполагает бинарный fail-stop, независимые отказы и статическую топологию. Она не видит retries, деградацию по latency, backpressure, общую зону размещения, shared control plane или состояние хранилища. Поэтому при малой доле отказов оценка может быть пессимистичной, а при высокой — оптимистичной: знак ошибки меняют реальные механизмы восстановления и каскады. Высокая корреляция подтверждает порядок риска в исследованной матрице, но не калибрует каждую вероятность для другой системы. Практическое применение должно хранить диапазон уверенности и явно помечать допущения, которые ещё не проверены fault injection.

Следующий эксперимент на OpenTelemetry Demo собирает граф уже из отдельных трасс и добавляет асинхронную Kafka-ветку. Её влияние зависит от SLO: для ответа заказа fraud detection не блокирует успех, но станет обязательным, если результат проверки входит в ожидаемый исход. Этот пример показывает, что полнота телеметрии недостаточна без явной семантики пользовательского сценария и границы измеряемого результата. Один и тот же технический граф может поддерживать несколько моделей надёжности, потому что разные SLO заканчиваются в разных точках. Сначала владелец продукта определяет ожидаемый исход, и только затем платформа решает, какие рёбра обязательны для его достижения.

В открытом наборе инструментов Procrustes проверяет, достаточно ли артефактов для модели, Bering обнаруживает граф, а Sheaft симулирует сценарии. Расчёт можно поставить release gate с порогом для endpoint или выводить в runtime-панель при изменении топологии. Начинать предлагается не со всей компании, а с одной критичной операции: собрать доступный срез, задать SLO и вероятности по истории, выбрать три риска и один сравнить с fault injection. Порог выпуска имеет смысл только при известном качестве исходных данных: неполная трассировка не должна выдавать точный зелёный статус. Сначала инструмент может работать как совет и показывать изменения риска, а блокирующим становиться после нескольких подтверждённых сравнений со стендом.