Старые webhook нужно drain до cut ключей

Резать ключи, пока старый webhook ещё держит in-flight DLR, — значит ронять delivery truth в воздухе. Buyer видит «sent» без финального статуса; финансы — открытые hold, которые не закрываются; ops теряет след, который доказывает порядок failover. Сначала drain. Потом cut.

Ротация на IOSOR считает старый endpoint очередью, которая должна затихнуть — не тумблером, который щёлкают, когда новый URL ответил на один smoke. In-flight reports — часть lifecycle сообщения; orphan их — и вы изобретаете неделю ghost-строк.

Инвентарь in-flight DLR на старом endpoint

Выгрузите открытые delivery и pending final-статусы, привязанные к старому webhook URL. Пометьте каждую строку возрастом и message id. Это backlog drain — не смутное «retries как-нибудь доедут».

Отдайте экспорт финансам до любого schedule revoke ключей. Если backlog больше одной тихой смены, продлите drain-окно письменно вместо cut в шторм поздних DLR.

Drain до quiet, затем режьте ключи

Держите старый endpoint Live только для completion-событий, пока inventory не ноль или согласованный residual floor. Не revoke messaging- или webhook-секреты, пока drain-лист ещё показывает свежие arrivals. Quiet — это нет новых finals за измеренное окно, а не «в Slack спокойно».

Когда quiet доказан, revoke старые ключи в том же change window, что и flip sole-owner URL. Частичный revoke с half-live секретом — как поздний DLR приходит на мёртвый путь.

Держите порядок failover честным во время drain

Пока идёт drain, не изобретайте второй Live-путь в обход ordered backup. Failover остаётся primary-then-backup; drain — не разрешение на fan-out. Зафиксируйте, какой путь владеет in-flight строками, чтобы incident week не спорил, какая труба «должна была» ответить.

Если primary падает mid-drain, идите по ordered backup и заново инвентаризируйте — не режьте ключи паникой «упростить».

Снова докажите day-1 runway после cut

После cut ключей прогоните day-1 проверки, которые должны быть зелёными: heartbeat, send proof, webhook finals на новом endpoint, закрытие hold на кошельке. Только потом открывайте пилотный объём. Слитый старый путь плюс красный runway — всё ещё blocked launch.

Выгрузите первый тихий час на новом URL, чтобы ops показал buyer: DLR не исчез вместе со старым секретом.

Связанные пути

• Ротация webhook без потери delivery reports
• Day-1 runway — что должно быть зелёным
• Primary fail, ordered backup path

Начните с IOSOR

Снимите inventory in-flight DLR на старом endpoint, задайте quiet-порог drain и держите порядок failover честным, пока очередь не пуста. Режьте ключи только после зелёного drain-отчёта, затем снова докажите day-1 runway на новом пути.

Итог IOSOR

Сначала drain, потом cut. Резать ключи, пока DLR ещё в полёте, — orphan delivery truth и сломанные тикеты покупателя. Порядок failover во время drain должен быть честным: тихий backup, который никогда не стреляет, — не план.

Не архивируйте старый endpoint до quiet. Опубликуйте drain-отчёт и post-cut runway check до роста Live-объёма.