Старі 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-рядків. Зафіксуйте дедлайн drain у runbook до cutover, щоб ніхто не «закрив» старий endpoint у чаті.

Інвентар 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-звіт із ledger за UTC, а також обов'язково виконати post-cut runway check ще до того, як суттєво зросте Live-обсяг трафіку.