Runbook operasi failover saat volume sudah aktif

Failover setelah Live adalah insiden operasi dengan uang dan kepercayaan klien yang dipertaruhkan. Sebutkan tiga pemilik sebelum pager berdering: siapa yang boleh membalik urutan jalur, siapa yang mengawasi pengeluaran dan batas penghentian, dan siapa yang bertanggung jawab atas apa yang dilihat pembeli saat jalur beralih. IOSOR adalah prabayar white-label. USD 20 mendanai lantai pilot; tinjauan lunak mendekati USD 1.000/bulan adalah saat pembalikan yang tidak terurut menjadi mahal.

Peran sebelum pager berdering

Tulis peran saat koridor tenang. Sebutkan pemilik urutan jalur, pemilik pengeluaran untuk batas dompet, dan pemilik status untuk UI klien dan salinan webhook. Topi dapat tumpang tindih dalam tim kecil; pisahkan di atas kertas agar insiden pukul 02:00 tidak menciptakan bagan organisasi.

Siapa yang boleh menyusun ulang jalur pada volume

Hanya pemilik urutan jalur yang ditunjuk (atau cadangan yang didelegasikan sebelumnya) yang boleh mengubah urutan langsung: perbarui jalur tertulis, uji cadangan baru di bawah kunci pilot jika waktu memungkinkan, lalu beralih — jangan menyebar ke setiap jalur atau membuat jalur dalam obrolan.

Setiap penyusunan ulang pada volume adalah peristiwa audit: siapa, kapan, koridor, mengapa. Identitas uang masih mengikuti Pengiriman failover parsial tanpa biaya ganda. Jika gerbang Live tidak pernah hijau, tarik volume terlebih dahulu — jangan perbaiki urutan dalam produksi.

Pengawasan pengeluaran dan batas penghentian dompet

Badai failover membakar prabayar lebih cepat daripada jalur utama yang stabil. Pemilik pengeluaran mengawasi batas penghentian dompet sebelum trafik produksi dan kontrol belanja prepaid. Batas penghentian menjeda atau mengurangi sebelum dompet pilot kosong — bukan setelah tinjauan lunak USD 1.000/bulan sudah terasa sakit.

Ekspor pengeluaran dalam insiden: unit yang dialihkan, penyelesaian vs rilis, koridor yang terkena. Pengeluaran tanpa volume klien yang cocok adalah bug uang (penyelesaian ganda atau penyebaran), bukan noise routing.

Kepemilikan status klien selama peralihan

Pembeli melihat satu jejak IOSOR yang jujur: diterima, tertunda, terkirim, gagal, perlu perhatian. Pemilik status memperbarui salinan dan makro dukungan agar lompatan di tengah penerbangan tidak terlihat seperti pengiriman duplikat atau «Terkirim» yang dibuat-buat. Log operasi dapat menyebutkan jalur yang memenuhi; permukaan klien tidak boleh. Keterlambatan latensi ≠ failover otomatis; skala routing tetap dengan operasi SMS. Di sini satu orang yang ditunjuk memiliki apa yang dibaca klien saat jalur bergerak.

Daftar periksa pembeli/operasi pada volume aktif

1. Pemilik urutan jalur, pengeluaran, dan status disebutkan sebelum volume Live?
2. Hanya pemilik yang ditunjuk yang boleh menyusun ulang — dengan tiket dan ekspor?
3. Batas penghentian dompet dan batas pengeluaran aktif dalam insiden?
4. Status klien white-label tanpa kebocoran merek selama peralihan?
5. Identitas uang di tengah penerbangan terbukti (satu debit per niat) sebelum lonjakan?
6. Setelah: ekspor buku besar, garis waktu, keputusan untuk memulihkan urutan primer?

Mulai dengan IOSOR

Namai tiga pemilik sebelum pager berbunyi: siapa boleh menyusun ulang rel, siapa menjaga bakar dan garis henti dompet, siapa punya teks status yang dilihat pembeli. Latih sakelar saat volume sudah hidup: paksa hop, pastikan satu debit, pastikan garis henti menahan, pastikan kata. Buku tanpa nama pada volume adalah pager mahal.

Intisari IOSOR

Buku volume adalah pemilik bernama dan garis henti, bukan rumus latensi.

Lakukan: tulis siapa boleh memutar rel dan siapa bicara ke pembeli saat volume sudah Live.

Jangan: biarkan pager pertama mengarang urutan rel, atau menyembunyikan debit kedua di balik «kami berpindah».