Ops-runbook failover, когда volume уже Live

Failover после Live — ops-инцидент с деньгами и доверием клиента. Назовите трёх владельцев до пейджера: кто может flip порядка rail, кто смотрит burn и stop-lines, кто владеет тем, что видит покупатель, пока rails переключаются.

IOSOR — white-label prepaid. USD 20 — пол пилота; soft review около USD 1 000/мес — когда хаотичные flip дорожают. Пререквизиты: Сбой primary rail: упорядоченный backup без двойного списания, Гейты failover до любого бейджа Live, Частичный failover без двойного списания.

Роли до звонка пейджера

Пишите роли, пока коридор спокоен. Назовите владельца порядка rail, владельца burn и владельца статуса для UI и webhook-copy. Шляпы могут пересекаться в маленькой команде; на бумаге они разделены, чтобы инцидент в 02:00 не изобретал оргструктуру.

Кто может менять порядок rail на volume

Только названный владелец порядка (или заранее делегированный backup) меняет живую последовательность: обновить путь, при возможности smoke нового backup под pilot-ключами, затем cutover — не fan-out и не путь в чате.

Burn watch и стоп-линии кошелька

Штормы failover жгут prepaid быстрее стабильного primary. Владелец burn смотрит стоп-линии кошелька до production-трафика и контроль prepaid-расходов. Stop-lines ставят паузу или shed до опустошения пилотного кошелька — не после soft USD 1 000/мес.

Ownership клиентского статуса во время switch

Покупатель видит один честный trail IOSOR: accepted, pending, delivered, failed, needs attention. Владелец статуса обновляет copy и support-макросы, чтобы mid-flight hop не выглядел как дубль или выдуманный Delivered. Ops-логи могут назвать rail; клиентские поверхности — нет. Лаг latency ≠ автоматический failover; масштаб routing — у SMS ops.

Чеклист buyer / ops на живом volume

1. Владельцы порядка rail, burn и статуса названы до Live volume?
2. Только названный владелец может reorder — с тикетом и export?
3. Stop-lines кошелька и потолки расхода активны в инциденте?
4. Клиентский статус white-label без утечки брендов во время switch?
5. Mid-flight money identity доказана (один debit на intent) до всплеска?
6. После: export ledger, timeline, решение вернуть порядок primary?

Начните с IOSOR

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

Итог IOSOR

Runbook на объёме — это названные владельцы и стоп-линии, не формула задержки.

Делайте: запишите, кто может перевернуть рельсы и кто говорит с покупателем, пока объём уже Live.

Не делайте: давать первому пейджеру выдумать порядок рельсов или прятать второе списание за «мы переключились».