Сбой у PSP: как перейти на резерв и вернуться без дублей

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

Разберите переключение на условном примере

У платформы заранее подключены маршруты A и B для одного разрешённого вида оплаты. В 14:05 по A растут тайм-ауты. Команда ограничивает новые обращения к A и проверяет пригодность B. Заказ R-902 уже отправлен через A, но ответа нет: он остаётся на сверке. Заказ R-903 ещё не отправлялся: после обычных проверок его можно направить через B, если параметры подходят этому маршруту.

Для R-902 нельзя просто скопировать ключ идемпотентности в B и считать защиту общей. В предлагаемой архитектуре существует единый внутренний журнал попыток, а разрешение на новое финансовое действие выдаётся только после установленного исхода предыдущего или предусмотренного провайдером безопасного процесса. Поддержка видит причину ожидания и не предлагает клиенту бесконтрольно повторять оплату.

Сначала классифицируйте проблему

Техническая недоступность, ошибка запроса, требование дополнительной аутентификации и ограничение операции требуют разных решений. Код HTTP сам по себе не всегда описывает бизнес-исход. Например, Stripe рекомендует считать результат операции с ответом 500 неопределённым и выяснять судьбу исходного запроса до попытки с новым ключом. Ответ с ошибкой не равен доказательству отсутствия финансового эффекта.

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

Резервный путь должен быть готов заранее

До инцидента составьте паспорт каждого маршрута: юридическое лицо, подключённый аккаунт, разрешённые виды операций, методы, валюты, география, ограничения суммы, порядок возвратов и контакты поддержки. Уточните, какие клиентские согласия и проверки обязательны. Если резерв ещё не подключён или его условия не подходят конкретной операции, считайте его недоступным.

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

Справочник отказов Adyen различает недоступность эмитента, ошибки аутентификации, подозрение на мошенничество и запрещённую операцию. Это конкретный пример того, почему единое правило «любой отказ отправить дальше» слишком грубо. Резервирование не должно обходить требования AML/KYC, санкционные ограничения, антифрод или решение о недопустимости операции. Спорную причину передавайте ответственному специалисту.

Ограничьте нагрузку при восстановлении

Переключение не отменяет лимитов резервного канала. Укажите максимальную долю нового потока, допустимую очередь и условие остановки. Выбирайте значения по договорным ограничениям и результатам согласованных проверок мощности. Сначала переведите ограниченный объём разрешённых новых операций, посмотрите на результаты и только затем увеличивайте нагрузку.

AWS объясняет, как повторы усиливают перегрузку и почему полезны увеличивающиеся интервалы с небольшим случайным разбросом, известным как jitter. Для платёжного сервиса это аргумент против синхронного массового повтора всей очереди. Назначьте одно место, управляющее повторными попытками, и проверьте, не добавляют ли SDK собственные незаметные повторы.

Возвращение на основной маршрут тоже требует контроля. Запишите, кто разрешает возврат, какие признаки восстановления нужны и как остановить переключение обратно. Выясните общие зависимости A и B: два разных договора сами по себе не доказывают независимость инфраструктуры. Сопоставляйте доступность с внутренними метриками, а не только с зелёным индикатором внешнего статуса.

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

В предлагаемой проверке резерв оценивается по всему жизненному циклу. Кто обработает возврат по старой операции? Как поддержка найдёт маршрут, если покупатель знает только номер заказа? В какую сверку попадёт платёж, пришедший с задержкой? Если эти ответы зависят от памяти одного инженера, второй PSP добавляет интеграцию, но ещё не даёт управляемой устойчивости.

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

Возвращение на основной маршрут тоже релиз

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

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

В отчёте об учении оставьте три числа: новые операции, прошедшие по резерву; прежние операции с неустановленным исходом; подтверждённые повторные финансовые эффекты. Даже при высокой конверсии второе число требует владельцев, а ненулевое третье требует разбора причины.