Математическое моделирование процессов

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

На конец 2024 года у нас есть два проекта, и в обоих случаях роль нетривиальной математики играет теория вероятности.

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

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

Стандартный способ мониторинга трафика — каждую минуту смотреть на количество запросов, которые завершились с ошибкой, и сравнивать его с порогом p (обычно p = 1% от общего числа запросов). Этот способ хорошо работает в нормальных условиях, но при низкой нагрузке на сервисы он приводит к частым ложным срабатываниям.

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

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

Более формально: если в минуту t пришло Nₜ запросов, из которых Xₜ завершилось с ошибкой, то мера сбойности будет равна Wₜ = max (0, W_t-1 + X_t – pN_t) 

Если мера сбойности превысила некоторый порог h, метод выдает сигнал об ошибке.

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

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

Wₜ = min (M, max(0, W_t-1 + X_t – pN_t))

В рамках инструментов, которые использует Т-Банк, проблематично считать CUSUM, потому что он при вычислениях неявно использует всю историю запросов.

Мы провели вычислительные эксперименты и обнаружили, что можно считать приближение CUSUM по небольшой (~10 минут) предыстории практически без потери качества.

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

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

Мы поставили перед собой цель — по имеющимся данным о компонентах научиться делать выводы и отвечать на разные важные вопросы:

1. Какова надежность всей системы из компонентов? Ответ нужен, чтобы понимать, чего можно ожидать от каждого конкретного сервиса и требует ли он изменений для выполнения требований по надежности.
2. Какие компоненты и части системы оказываются узким местом и наиболее критичны для функционирования системы? Иначе говоря, изменения в надежности каких компонентов сильнее повлияют на общую надежность системы? Ответ позволит концентрировать внимание на действительно важных частях системы и более рационально тратить ресурсы на повышение надежности.
3. Какие изменения могут повысить надежность системы? Например, перенос компонентов из одной зоны в другую или их репликация. Важный класс достаточно дешевых изменений, которые могут сильно повлиять на надежность, — перенос компонента из одной вычислительной зоны в другую. На примере видно, как такой перенос может повысить надежность системы практически на два порядка: с 99,9% до 99,998%:

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

Другой интересный тип изменений — «репликация» компонентов, создание копии какого-либо компонента, которая может заменить поломанный «оригинал»

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