Первый час платёжного инцидента и передача смены

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

Первые 10 минут: назначьте управление и установите масштаб

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

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

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

10–20 минут: остановите увеличение ущерба

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

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

20–40 минут: работайте по списку неизвестных исходов

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

Один специалист восстанавливает обработку, другой ведёт сверку этих 12 операций. Не стирайте запись из списка только потому, что клиент перестал писать. Исключение закрывается при установленном результате и выполненном следующем действии, а не по возрасту обращения.

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

Сообщайте разные детали разным аудиториям

Пример внутреннего обновления: «10:25 UTC. Задержаны подтверждения по маршруту A. Новые отправки приостановлены. Проверяем 12 операций с неизвестным исходом. Технический ответственный проверяет очередь, финансовый оператор сверяет записи. Следующее обновление в 10:40 UTC». Числа и время здесь условные; в реальном сообщении используйте только проверенные данные.

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

Atlassian рекомендует регулярные обновления через основной канал. Назначьте понятный интервал и соблюдайте его даже при отсутствии новой причины. Отделяйте известное влияние от гипотез; не публикуйте реквизиты клиентов, внутренние секреты или неподтверждённые обвинения в адрес партнёра.

40–60 минут: проверьте восстановление и передайте остаток работы

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

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

Две точки завершения вместо одной

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

Во время инцидента считайте не только ошибки, но и денежную экспозицию. Условные 12 неизвестных операций по 10 евро и 12 операций по 10 000 евро требуют разного внимания. Суммы группируйте по валютам и типу обязательства; не складывайте их в красивое число без правил конвертации. Отдельно отметьте операции, для которых уже выдан товар или обещана выплата.

Передача смены как проверка понимания

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

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