Provozní příručka pro failover, když je objem již aktivní

Failover po aktivaci je provozní incident s penězi a důvěrou klientů v sázce. Pojmenujte tři vlastníky před pagerem: kdo může měnit pořadí tras, kdo sleduje čerpání a stop-linky a kdo vlastní to, co kupující vidí, zatímco se trasy přepínají. IOSOR je white-label předplacený. USD 20 financuje pilotní podlahu; měkká kontrola blízko USD 1,000/month je, když se neuspořádané přepínání stává drahým. Předpoklady: Primární trasa selže: objednaná záložní cesta bez dvojitého stržení, Failover brány před jakýmkoli Live odznakem, Částečné failover odeslání bez dvojitého poplatku.

Role před zazvoněním pageru

Napište role, zatímco je koridor klidný. Pojmenujte vlastníka pořadí tras, vlastníka čerpání pro stropy peněženky a vlastníka stavu pro klientské UI a text webhooku. Role se mohou překrývat v malém týmu; udržujte je oddělené na papíře, aby incident ve 02:00 nevymyslel organizační schéma.

Kdo může měnit pořadí tras při objemu

Pouze jmenovaný vlastník pořadí tras (nebo předem delegovaná záloha) může změnit živou sekvenci: aktualizovat písemnou cestu, otestovat novou zálohu pod pilotními klíči, pokud to čas dovolí, a poté přepnout — ne rozesílat na každou trasu nebo vymýšlet cestu v chatu.

Každá změna pořadí při objemu je auditní událost: kdo, kdy, koridor, proč. Identita peněz stále sleduje Částečné failover odeslání bez dvojitého poplatku. Pokud brány Live nebyly nikdy zelené, stáhněte objem nejprve — neopravujte pořadí v produkci.

Sledování čerpání a stop-linky peněženky

Failover bouře čerpají předplacené rychleji než stabilní primární. Vlastník čerpání sleduje hranice zastavení peněženky před produkčním provozem a kontrola prepaid výdajů. Stop-linky pozastaví nebo sníží objem, než se pilotní peněženka vyprázdní — ne až poté, co měkká kontrola blízko USD 1,000/month již bolí.

Exportujte čerpání v incidentu: přepnuté jednotky, vypořádání vs. uvolnění, zasažené koridory. Čerpání bez odpovídajícího objemu klientů je chyba peněz (dvojité vypořádání nebo rozstřik), nikoli šum směrování.

Vlastnictví stavu klienta během přepínání

Kupující vidí jednu čestnou stopu IOSOR: přijato, čeká, doručeno, selhalo, vyžaduje pozornost. Vlastník stavu aktualizuje text a makra podpory, aby se přenosy za letu nejevily jako duplicitní odeslání nebo vymyšlené Doručeno. Provozní protokoly mohou pojmenovat plnící trasu; klientská rozhraní nesmí. Prodleva latence ≠ automatický failover; škálování směrování zůstává u provozu SMS. Zde jeden jmenovaný člověk vlastní to, co klient čte, zatímco se trasy pohybují.

Kontrolní seznam kupujícího / provozu při aktivním objemu

1. Vlastníci pořadí tras, čerpání a stavu jmenováni před aktivním objemem?
2. Pouze jmenovaný vlastník může měnit pořadí — s tiketem a exportem?
3. Stop-linky peněženky a stropy výdajů aktivní v incidentu?
4. White-label stav klienta bez úniku značky během přepínání?
5. Peněžní identita za letu prokázána (jeden debet na záměr) před špičkami?
6. Poté: export účetní knihy, časová osa, rozhodnutí o obnovení primárního pořadí?

Začněte s IOSOR

Jmenujte tři vlastníky než zazvoní pager: kdo smí přerovnat koleje, kdo hlídá spalování a stop-čáry peněženky, kdo vlastní text stavu, který vidí kupující. Zkoušejte přepnutí, když je objem už živý: vynutťte hop, potvrďte jeden debet, potvrďte že stop-čáry drží, potvrďte slova. Bezejmenný runbook při objemu je drahý pager.

Shrnutí IOSOR

Runbook při objemu jsou jmenovaní vlastníci a stop-čáry, ne vzorec zpoždění.

Dělejte: napište, kdo smí otočit koleje a kdo mluví s kupujícím, když je objem už Live.

Nedělejte: nechat první pager vymyslet pořadí kolejí, ani schovat druhý debet za «přepli jsme».