Walkaway DR — Bagaimana Sebuah Ponsel Membangun Ulang Server yang Mati

Skenario yang Tidak Pernah Direncanakan

Pemulihan bencana dalam perangkat lunak enterprise berarti kluster failover, basis data tereplikasi, dan tim operasi 24/7. Ini mengasumsikan Anda memiliki pusat data, insinyur jaringan, dan anggaran.

Sekarang hilangkan semua itu. Anda menjalankan stasiun medis di sebuah Raspberry Pi di zona bencana. Adaptor daya tertendang. Kartu SD rusak. Perangkat jatuh dari meja lipat saat gempa susulan. Perangkat mati.

Setiap catatan pasien selama 72 jam terakhir ada di perangkat itu. Klasifikasi triase. Log pemberian obat. Rantai pengawasan produk darah. Kasus bedah aktif. Semuanya.

Pemulihan bencana tradisional mengatakan: pulihkan dari cadangan. Tetapi server cadangan adalah perangkat yang sama yang baru saja mati. Tidak ada cloud. Tidak ada pusat data kedua. Tidak ada tim TI.

Yang ada: seorang perawat dengan ponsel yang telah menyinkronkan data di latar belakang setiap lima menit.

Protokol Sekoci

Kami menyebutnya Protokol Sekoci karena metaforanya tepat. Ketika kapal tenggelam, sekoci membawa penumpang. Ketika server mati, ponsel membawa data.

Setiap PWA (Progressive Web App) di armada xGrid menjalankan proses latar belakang yang disebut Lifeboat Client. Setiap lima menit, ia secara diam-diam menarik data baru dari Raspberry Pi dan menyimpannya secara lokal di IndexedDB browser -- basis data persisten yang bertahan melalui restart aplikasi, restart ponsel, dan bahkan mode pesawat.

Cadangan bukan sebuah file. Ini adalah penyimpanan peristiwa terstruktur dengan setiap perubahan yang terjadi di server, ditambah snapshot periodik dari status terkini semua tabel kritis -- catatan pasien, produk darah, kasus bedah, jadwal pengobatan, rencana perawatan.

Ketika server mati, ponsel bahkan tidak langsung mengetahuinya. Saat berikutnya mencoba sinkronisasi, ia menyadari server telah menghilang. Ketika Raspberry Pi baru muncul di jaringan, ponsel mendeteksinya secara otomatis: identitas server telah berubah, dan basis data kosong.

Itu memicu proses pemulihan.

Tiga Menit Menuju Pemulihan Penuh

Alur pemulihan dirancang untuk perawat, bukan insinyur:

Snapshot memulihkan status terkini secara langsung -- dasbor dapat digunakan dalam hitungan detik. Peristiwa memutar ulang seluruh riwayat, memastikan setiap jejak audit tetap utuh.

Mengapa Peristiwa, Bukan Hanya Snapshot

Snapshot memberi tahu Anda di mana posisi saat ini. Peristiwa memberi tahu Anda bagaimana sampai di sana.

Jika Anda hanya memulihkan snapshot, Anda tahu bahwa Pasien A memiliki dua unit darah yang dialokasikan. Tetapi Anda tidak tahu siapa yang mengalokasikannya, kapan, atau mengapa. Anda tidak tahu bahwa alokasi itu adalah override darurat pukul 2 pagi karena pasien mengalami perdarahan dan dokter sedang mengoperasi pasien lain.

xGrid mencatat setiap perubahan status sebagai peristiwa yang tidak dapat diubah: siapa yang melakukannya, kapan, di perangkat mana, dengan justifikasi apa. Penyimpanan peristiwa hanya menambahkan -- peristiwa tidak pernah dihapus atau dimodifikasi. Setiap peristiwa membawa hash kriptografi dari kontennya.

Ketika ponsel memulihkan ke server baru, ia mengirim rantai peristiwa lengkap. Server dapat merekonstruksi bukan hanya status terkini, tetapi seluruh riwayat dari setiap keputusan, setiap override, setiap serah terima.

Verifikasi Chain Hash

Bagaimana Anda tahu data yang dipulihkan lengkap dan tidak dimanipulasi?

Setiap tipe entitas (produk darah, kasus bedah, catatan pasien) memelihara chain hash bergilir:

chain[i] = SHA-256(chain[i-1] + event_id + payload_hash)

Secara konseptual mirip blockchain, tetapi tanpa overhead. Jika server asli memiliki 500 peristiwa produk darah yang menghasilkan chain hash a3f2..., dan server yang dipulihkan memproses 500 peristiwa yang sama, ia harus menghasilkan chain hash identik a3f2....

Jika ada peristiwa yang hilang, dimodifikasi, atau tidak berurutan, chain hash menyimpang. Sistem menandainya. Anda tahu ada masalah sebelum siapa pun mulai menggunakan data.

Idempotensi: Jaring Pengaman untuk Jaringan Tidak Stabil

Apa yang terjadi jika ponsel perawat kehilangan WiFi di tengah proses pemulihan? Dia terhubung kembali dan menekan "Pulihkan" lagi. Apakah semuanya akan terduplikasi?

Tidak. Setiap peristiwa memiliki ID unik dan hash konten. Ketika server menerima peristiwa yang sudah diproses, ia memeriksa:

• ID sama, hash sama: Sudah ada. Lewati. Tidak ada duplikasi.
• ID sama, hash berbeda: Konflik. Tolak dan catat untuk investigasi.
• ID baru: Masukkan secara normal.

Perawat dapat menekan "Pulihkan" sepuluh kali. Hasilnya identik dengan menekannya sekali. Ini bukan fitur kenyamanan -- ini adalah properti keselamatan kritis. Dalam lingkungan yang penuh tekanan dengan konektivitas tidak stabil, orang akan mencoba lagi. Sistem harus menangani percobaan ulang dengan baik.

Apa yang Dipulihkan

Snapshot Lifeboat mencakup 20 tabel kritis:

Setiap tabel yang penting untuk keselamatan pasien tercakup. Jika memengaruhi keputusan klinis, ia bertahan melalui pemulihan.

Realitas Kartu SD

Perangkat Raspberry Pi menggunakan kartu SD untuk penyimpanan. Kartu SD mengalami keausan. Kartu SD tidak dirancang untuk pola penulisan server basis data. Dalam penerapan lapangan yang beroperasi 24/7, kegagalan kartu SD bukan masalah apakah, tetapi kapan.

Inilah mengapa Protokol Sekoci ada. Bukan sebagai polis asuransi untuk kejadian yang tidak mungkin terjadi, tetapi sebagai bagian rutin dari asumsi operasional sistem. Sistem dirancang untuk kegagalan perangkat keras.

Proses pemulihan juga melindungi kartu SD baru. Alih-alih menulis ribuan operasi basis data individual, setiap batch peristiwa diproses dalam satu transaksi tunggal. Lebih sedikit operasi penulisan berarti lebih sedikit keausan kartu SD, memperpanjang umur perangkat pengganti.

Validasi 12 Langkah

Pengujian DR end-to-end kami menjalankan 12 langkah:

1. Mengisi server asli dengan pasien, produk darah, kasus bedah, dan data LSCO
2. Membuat rencana perawatan PFC dengan tanda vital, kartu korban TCCC, dan permintaan MEDEVAC
3. Mengekspor semua peristiwa dan snapshot (berpaginasi, berbasis kursor)
4. Mencatat sidik jari chain hash server asli
5. Memulai server baru dengan basis data kosong
6. Memulihkan batch 1: snapshot + batch peristiwa pertama
7. Memulihkan batch yang tersisa
8. Membandingkan chain hash antara server asli dan yang dipulihkan
9. Mengirim ulang semua peristiwa (uji idempotensi) -- memverifikasi nol duplikasi
10. Memverifikasi semua data LSCO bertahan: rencana PFC, kartu TCCC, permintaan MEDEVAC
11. Memeriksa riwayat pemulihan: nol peristiwa yang ditolak
12. Mengonfirmasi integritas jejak audit lengkap

Semua 12 langkah lulus. Server yang dipulihkan tidak dapat dibedakan dari yang asli -- data sama, riwayat sama, chain hash sama.

Apa Artinya dalam Praktik

Tim rumah sakit lapangan ditempatkan dengan dua perangkat Raspberry Pi dan sekotak suku cadang. Ketika perangkat gagal -- dan itu akan terjadi -- urutan penggantian memakan waktu menit, bukan jam. Tidak perlu insinyur. Tidak perlu akses baris perintah. Tidak perlu pelatihan khusus selain "masukkan PIN ketika ponsel meminta."

Data tidak tinggal di server. Data tinggal di mana-mana -- di setiap ponsel dan tablet yang pernah terhubung ke server. Server bukan sumber kebenaran. Ia adalah titik agregasi yang nyaman. Ponsel-ponsel adalah sekoci, dan mereka selalu siap.

Inilah arti Walkaway dalam praktik. Bukan hanya bahwa pengembang bisa pergi (mereka bisa -- lihat The Walkaway Test). Tetapi perangkat keras juga bisa pergi. Jatuh dari meja. Terinjak. Terbakar saat gempa susulan. Data bertahan karena data tidak pernah hanya di satu tempat.

---

Terkait: The Walkaway Test · SQLite in the Battlefield · Hub-and-Spoke: Network Architecture for Disconnected Operations