Modul 13Term 4 · Operasional produksi8 item poster

Disaster Recovery dan Manajemen Insiden

Masuk untuk menyimpan progres Anda di semua perangkat. Sampai saat itu, progres disimpan di browser ini.

Mengapa ini penting

Setiap sistem pada akhirnya akan mengalami hari buruk: penyedia yang down, migrasi yang salah, database yang terhapus, key yang dibobol. Enterprise dan regulator tidak bertanya apakah Anda akan mengalami insiden. Mereka bertanya seberapa cepat Anda mendeteksi, bagaimana Anda berkomunikasi, berapa banyak data yang bisa hilang, dan seberapa cepat Anda pulih.

Capaian pembelajaran

  1. Mendefinisikan RPO dan RTO per sistem dan merancang backup untuk memenuhinya.
  2. Membuktikan backup dengan melakukan restore.
  3. Merencanakan failover dan memahami kapan multi-region memang beralasan.
  4. Menjalankan penanganan insiden dengan peran dan komunikasi yang jelas.
  5. Menyiapkan on-call yang berkelanjutan.
  6. Menulis postmortem blameless yang menghasilkan perbaikan nyata.
  7. Menjalankan eksperimen chaos yang terkendali.

Materi

13.1 RPO dan RTO (83)

  • RPO (Recovery Point Objective): seberapa banyak data yang sanggup Anda relakan hilang (misalnya 5 menit).
  • RTO (Recovery Time Objective): berapa lama Anda boleh down (misalnya 1 jam).
  • Tetapkan per sistem bersama pihak bisnis. Ledger butuh RPO mendekati nol; cache analitik bisa dibangun ulang.

13.2 Backup (84)

  • Aturan 3-2-1: 3 salinan, 2 media/layanan berbeda, 1 di luar lokasi (akun/penyedia berbeda).
  • Point-in-time recovery (PITR) untuk database primary.
  • Backup bersifat immutable dan berada di akun terpisah sehingga admin yang dibobol atau agen liar tidak bisa menghapusnya. (Agen dan penyerang yang menghapus backup bersamaan dengan production adalah pola insiden yang berulang.)
  • Backup lebih dari sekadar DB: object storage, secret/konfigurasi (lewat IaC), data pihak ketiga yang tidak bisa Anda buat ulang.
  • Backup yang belum pernah Anda restore hanyalah harapan. Jadwalkan latihan restore; ukur RTO yang sebenarnya.

13.3 Failover dan multi-region (85, 86)

  • Failover (85): promosikan standby (replika, region sekunder, penyedia kedua). Failover otomatis butuh deteksi kesehatan yang andal untuk menghindari flapping atau split-brain.
  • Multi-region (86): memperbaiki latensi untuk pengguna global dan bertahan dari gangguan regional, dengan harga berupa kompleksitas, tantangan konsistensi data, dan biaya. Kebanyakan startup butuh multi-zone dalam satu region ditambah backup di luar region, bukan multi-region active-active.
  • Pertimbangkan data residency sebelum mereplikasi data pribadi lintas negara.
  • Dependensi pada satu penyedia (satu vendor LLM, satu SMS gateway): siapkan cadangan.

13.4 Respons insiden (109)

Tingkat keparahan (contoh): SEV1 layanan mati atau kebocoran data / pergerakan uang yang salah; SEV2 fitur utama mati; SEV3 performa menurun, ada solusi sementara. Peran: Incident Commander (mengoordinasikan, memutuskan), Ops/Tech lead (memperbaiki), Comms lead (status page, pelanggan, regulator), Scribe (timeline). Di perusahaan satu orang, Anda memainkan keempatnya; tulis checklist-nya sebelumnya supaya Anda tidak perlu berpikir saat kejadian. Urutan: deteksi → umumkan → mitigasi dulu (rollback, matikan flag, failover) → berkomunikasi sejak awal dan rutin → selesaikan → tindak lanjut. Untuk kebocoran data, jam hukum mulai berjalan: misalnya PDPA Singapura mewajibkan pemberitahuan ke PDPC dalam 3 hari kalender setelah kebocoran dinilai wajib dilaporkan (lihat 14 · Kepatuhan, Tata Kelola, dan Audit).

13.5 On-call (110)

Rotasi yang jelas, jalur eskalasi, runbook untuk setiap alert, tinjauan kualitas alert, kompensasi/istirahat setelah dipanggil. Versi solo founder: tool paging di ponsel Anda, kontraktor tepercaya sebagai cadangan, dan kebersihan alert yang tanpa ampun.

13.6 Postmortem (111)

Blameless: fokus pada bagaimana sistem memungkinkan kegagalan terjadi, bukan siapa yang salah. Template: ringkasan, dampak (pengguna, durasi, uang), timeline, akar masalah dan faktor penyumbang (5 whys), apa yang berjalan baik, apa yang berjalan buruk, di mana kita beruntung, action item dengan penanggung jawab dan tenggat. Pantau action item sampai tuntas.

13.7 Chaos engineering (87)

Susun hipotesis ("jika penyedia LLM gagal, pengguna melihat fallback dan tidak ada hal lain yang rusak"), batasi blast radius, jalankan di staging dulu, lalu dengan hati-hati di production saat game day, ukur, perbaiki. Mulailah dengan latihan tabletop sebelum menyuntikkan kegagalan sungguhan.

Lab 13: Game day

  1. Tulis RPO/RTO untuk setiap penyimpanan data; konfigurasikan PITR dan backup immutable di akun terpisah.
  2. Latihan restore: restore backup production ke environment baru; verifikasi datanya; catat RTO yang sebenarnya.
  3. Game day: instruktur merusak sistem (deploy buruk, key bocor, penyedia down, tabel terhapus) tanpa peringatan. Peserta menangani insidennya dengan peran, status page, dan komunikasi.
  4. Tulis postmortem dalam 48 jam.

Definition of Done

Paket prompt AI

  • "Tulis runbook insiden untuk 'database primary tidak tersedia' pada arsitektur ini, termasuk langkah deteksi, mitigasi, komunikasi, dan pemulihan."
  • "Ubah timeline insiden ini menjadi postmortem blameless dengan 5-whys dan action item yang konkret."