Завершение работы финтех-монолита на этапе развертывания — зона финансового риска. Большинство P1-инцидентов происходит не при запуске, а при остановке системы.

Сбои в работе финтех-продуктов начинаются не с запуска и не с плохого кода. Они начинаются с самой обычной кнопки развертывания (Deploy Button), нажатой кем-то, кто предположил, что остановка сервиса — безобидное действие.

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

Сегодня это важнее, чем когда-либо, потому что финтех-монолиты по-прежнему обрабатывают реальные деньги, управляют реальными графиками и порождают реальные побочные эффекты. Хотя индустрия продолжает делать вид, что все ПО состоит из микросервисов и основано на stateless-архитектуре (с обработкой транзакций, независимой от состояния приложения).

Почему некорректное завершение работы в монолитных финтех-системах  — угроза бизнесу, а не техническая проблема

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

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

Останавливая финтех-систему, наивный разработчик обычно «убивает» JVM (виртуальную Java-машину), опустошает модуль pod или перезапускает виртуальную машину, не понимая, какая именно задача в данный момент находится в процессе выполнения. Результат — наполовину проведенные транзакции, «осиротевшие» выполнения планировщика и повторные попытки, которые дублируют логику движения денег. Так безобидные перезапуски незаметно превращаются в инциденты P1.

Самое неприятное заключается в том, что ничего не «вылетает». Все выглядит нормально, пока бизнес-команды не начинают сверять цифры.

Когда понимаешь, что остановить сервис опаснее, чем запустить его

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

Запланированные задания так и не были выполнены. Записи о платежах застряли в промежуточном состоянии. Сработал механизм повторных попыток и продублировал вызов к внешнему сервису. Ни один стек трассировки не указывал на первопричину, потому что сбой произошел во время завершения работы, а не во время выполнения.

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

Как безопасно остановить монолитную финтех-систему без потери текущих запросов или денег

Безопасное завершение работы начинается с принятия одного неудобного ограничения: нельзя остановить все сразу. Нужно обеспечить последовательное завершение работы, учитывая обязанности системы.

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

// Пример Spring Boot: корректная обработка запросов
@Bean
public GracefulShutdown gracefulShutdown() {
    return new GracefulShutdown(); // отслеживает активные HTTP-запросы
}


// Сервер ожидает, пока количество активных запросов не достигнет нуля

Именно так HTTP-потоки могут завершаться естественным образом, а не прерываться в середине транзакции. Это предотвращает частичную фиксацию записей в базе данных и несогласованность состояний ответов.

Второе правило заключается в явном управлении планировщиками. Плановые задачи (cron jobs) и фоновые процессы должны прекратить ставить в очередь новые задания, позволяя при этом завершиться уже запущенным. Если этим правилом пренебречь, задача может начаться прямо во время остановки и так и не дойти до финальной фиксации данных (commit).

@PreDestroy
public void shutdownSchedulers() {
    scheduler.pauseAll();   // останавливаем новые триггеры
    scheduler.shutdown(true); // ждем завершения выполняющихся задач
}

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

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

Что меняется, если рассматривать завершение работы как часть архитектуры системы

До исправления поведения при завершении работы наши метрики развертывания выглядели обманчиво нормальными. Пики нагрузки на процессор оставались низкими, время запуска — небольшим, уровень ошибок — неизменным. Тем не менее, бизнес-инциденты продолжали возникать после каждого релиза.

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

До: ████████████████████

• P1-инцидентов в квартал: 4;

• Проблемы со сверкой после деплоя: 4.

После: ████

• P1-инцидентов в квартал: 0;

• Проблемы со сверкой после деплоя: 0.

Система не стала работать быстрее. Она стала предсказуемой. И именно эта предсказуемость — то, что сохраняет доверие к финтех-системам.

Трудные уроки, которые бэкенд-разработчики усваивают только после сбоя в производстве

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

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

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

Корректное завершение работы финтех-монолита — это уважение к работе, которая находится в процессе выполнения

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

Когда бэкенд-разработчики рассматривают остановку как часть системного дизайна, инциденты P1 сами собой исчезают. Не потому, что система стала идеальной, а потому, что ей наконец-то позволили завершить то, что она начала.

Читайте также:

• Топ-10 антипаттернов при использовании микросервисов
• Как перейти от монолитной системы к событийной
• Эффективные шаблоны архитектуры программного обеспечения

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи CodersWorld: 80% of Backend Engineers Stop Fintech Monoliths Wrong — and Trigger P1 Incidents