Graph-based remediation меняет подход к восстановлению MongoDB-инфраструктуры. Вместо runbook-сценариев система сама находит корректные пути восстановления и снижает нагрузку на on-call.
В распределённой базе данных деградация редко бывает линейной. В случае Stripe проблема проявилась в масштабе: шардированные кластеры MongoDB регулярно попадали в частично неконсистентные состояния. Старый подход опирался на жёстко закодированные плагины и runbook-последовательности. Он ломался на комбинациях сбоев, зависел от конкретного layout и не учитывал промежуточные состояния. Это приводило к частым pager alerts и ручному вмешательству. За полгода система срабатывала 124 раза из-за некорректных конфигураций шардов и ещё 32 раза при деградации узлов с дополнительными проблемами. Даже плановые операции, такие как билд индексов, блокировались примерно на час.
Решение сместило фокус с сценариев на модель. Stripe представил инфраструктуру как граф: узлы — это компоненты, рёбра — их связи, а атрибуты описывают текущее состояние. Вместо фиксированных шагов система использует graph search для поиска допустимых путей восстановления. Это позволяет одной и той же логике работать с разными топологиями. Изначально применяли BFS, но позже перешли на алгоритм Дейкстры. Причина — необходимость учитывать «стоимость» операций и избегать лишних действий. Такой выбор — компромисс: выше вычислительная сложность, но лучше контроль над побочными эффектами и более предсказуемое поведение системы.
Ключевой архитектурный сдвиг — переход от процедур к декларативной модели. Восстановление описывается как набор правил и состояний (state machine), а не как жёсткий workflow. Планировщик динамически комбинирует операции, исходя из текущего состояния графа. Это важно для систем с высокой вариативностью: заранее перечислить все сценарии невозможно. Алгоритм ищет путь не только к целевому состоянию, но и к «наименее плохому», если полный recovery недостижим. Это снижает blast radius и позволяет частично стабилизировать систему без ожидания идеального решения. Реализация требует аккуратного моделирования состояний и переходов: ошибка в модели приведёт к неверным планам, даже если алгоритм корректен.
Результаты показывают практическую ценность подхода. Количество database-related pager alerts снизилось примерно на 30%, что эквивалентно около 200 инцидентов в год. Также устранено около 12 дней нездоровых состояний шардов ежегодно. Важно, что система адаптируется к изменениям инфраструктуры без переписывания логики. Метрики latency или throughput не раскрываются, но косвенный эффект — снижение времени блокировки операций и уменьшение ручного вмешательства. Это указывает на улучшение операционной устойчивости (resilience), а не только на оптимизацию recovery.
С инженерной точки зрения, это пример эволюционного перехода от runbook-driven операций к model-driven управлению. Runbooks хорошо работают для известных сценариев, но плохо масштабируются при росте сложности. State machine + graph search позволяют системе «исследовать» пространство состояний, а не следовать заранее заданному пути. Цена — более сложная модель и необходимость вычислений в рантайме. Но на масштабе глобальной инфраструктуры этот trade-off выглядит прагматичным.
Интересно, что Stripe планирует расширить подход за пределы реактивного восстановления. В roadmap — автоматизация изменений топологии и blue-green деплоев, а также объединение планового обслуживания с self-healing. Это логичное продолжение: если система уже умеет находить корректные переходы между состояниями, она может применять это не только при сбоях, но и при эволюции инфраструктуры.
В индустрии виден схожий тренд. Другие компании также инвестируют в self-healing и декларативные платформы. Общий вектор — снижение нагрузки на инженеров и уход от ручного управления сложными системами. В условиях, где деградация — это норма, задача уже не в том, чтобы избегать сбоев, а в том, чтобы корректно и быстро из них выходить без выгорания on-call команд.