Modul 13Penggal 4 · Operasi production8 item poster

Pemulihan Bencana dan Pengurusan Insiden

Log masuk untuk menyimpan kemajuan anda merentas peranti. Sehingga itu, ia disimpan dalam pelayar ini.

Mengapa ini penting

Setiap sistem akhirnya akan mengalami hari yang buruk: gangguan penyedia, migration yang salah, pangkalan data yang terpadam, kunci yang bocor. Enterprise dan pengawal selia tidak bertanya sama ada anda akan mengalami insiden. Mereka bertanya seberapa pantas anda mengesannya, bagaimana anda berkomunikasi, berapa banyak data yang anda boleh hilang, dan seberapa pantas anda pulih.

Hasil pembelajaran

  1. Takrifkan RPO dan RTO bagi setiap sistem dan reka backup untuk memenuhinya.
  2. Buktikan backup dengan memulihkannya.
  3. Rancang failover dan fahami bila multi-region berbaloi.
  4. Kendalikan insiden dengan peranan dan komunikasi yang jelas.
  5. Wujudkan on-call yang mampan.
  6. Tulis postmortem tanpa menyalahkan yang menghasilkan pembaikan sebenar.
  7. Jalankan eksperimen chaos yang terkawal.

Pelajaran

13.1 RPO dan RTO (83)

  • RPO (Recovery Point Objective): berapa banyak data yang anda mampu hilang (cth. 5 minit).
  • RTO (Recovery Time Objective): berapa lama anda boleh down (cth. 1 jam).
  • Tetapkannya bagi setiap sistem bersama pihak perniagaan. Lejar memerlukan RPO hampir sifar; cache analitik boleh dibina semula.

13.2 Backup (84)

  • Peraturan 3-2-1: 3 salinan, 2 media/servis berbeza, 1 di luar tapak (akaun/penyedia berbeza).
  • Point-in-time recovery (PITR) untuk pangkalan data primary.
  • Backup mesti immutable dan dalam akaun berasingan supaya admin yang dikompromi atau ejen liar tidak boleh memadamnya. (Ejen dan penyerang memadam backup bersama production ialah corak insiden yang berulang.)
  • Backup lebih daripada DB: object storage, secret/konfigurasi (melalui IaC), data pihak ketiga yang anda tidak boleh jana semula.
  • Backup yang belum pernah anda pulihkan hanyalah harapan. Jadualkan latihan pemulihan; ukur RTO sebenar.

13.3 Failover dan multi-region (85, 86)

  • Failover (85): naikkan standby (replica, rantau sekunder, penyedia kedua). Failover automatik memerlukan pengesanan kesihatan yang boleh diharap untuk mengelakkan flapping atau split-brain.
  • Multi-region (86): mengurangkan latency untuk pengguna global dan bertahan daripada gangguan serantau, dengan kos kerumitan, cabaran konsistensi data dan wang. Kebanyakan startup memerlukan multi-zone dalam satu rantau, serta backup di luar rantau, bukan multi-region active-active.
  • Pertimbangkan data residency sebelum mereplikasi data peribadi merentas sempadan.
  • Dependency penyedia tunggal (satu vendor LLM, satu gerbang SMS): rancang penyedia sekunder.

13.4 Tindak balas insiden (109)

Tahap keterukan (contoh): SEV1 gangguan atau pelanggaran data / pergerakan wang yang salah; SEV2 ciri utama down; SEV3 prestasi merosot, ada jalan penyelesaian sementara. Peranan: Incident Commander (menyelaras, membuat keputusan), Ops/Tech lead (membaiki), Comms lead (halaman status, pelanggan, pengawal selia), Scribe (garis masa). Dalam syarikat satu orang, anda memainkan keempat-empat peranan; tulis senarai semak lebih awal supaya anda tidak perlu berfikir semasa kecemasan. Jujukan: kesan → isytihar → mitigasi dahulu (rollback, matikan flag, failover) → berkomunikasi awal dan kerap → selesaikan → susulan. Bagi pelanggaran data, jam undang-undang mula berdetik: cth. PDPA Singapura mewajibkan pemberitahuan kepada PDPC dalam tempoh 3 hari kalendar selepas menilai sesuatu pelanggaran sebagai wajib dilaporkan (lihat 14 · Pematuhan, Tadbir Urus dan Audit).

13.5 On-call (110)

Giliran yang jelas, laluan eskalasi, runbook untuk setiap amaran, semakan kualiti amaran, pampasan/rehat selepas di-page. Versi pengasas solo: alat paging di telefon anda, kontraktor yang dipercayai sebagai sandaran, dan kebersihan amaran yang tegas.

13.6 Postmortem (111)

Tanpa menyalahkan: fokus pada bagaimana sistem membenarkan kegagalan itu, bukan siapa yang tersilap. Templat: ringkasan, impak (pengguna, tempoh, wang), garis masa, punca utama dan faktor penyumbang (5 whys), apa yang berjalan baik, apa yang berjalan buruk, di mana kita bernasib baik, item tindakan dengan pemilik dan tarikh akhir. Jejaki item tindakan sehingga selesai.

13.7 Chaos engineering (87)

Bentuk hipotesis ("jika penyedia LLM gagal, pengguna melihat fallback dan tiada apa-apa lagi yang rosak"), hadkan blast radius, jalankan di staging dahulu, kemudian dengan berhati-hati di production semasa game day, ukur, baiki. Mulakan dengan latihan tabletop sebelum menyuntik kerosakan sebenar.

Makmal 13: Game day

  1. Tulis RPO/RTO untuk setiap stor data; konfigurasikan PITR dan backup immutable di luar akaun.
  2. Latihan pemulihan: pulihkan backup production ke dalam persekitaran baharu; sahkan data; rekodkan RTO sebenar.
  3. Game day: pengajar merosakkan sistem (deploy buruk, kunci bocor, gangguan penyedia, jadual terpadam) tanpa amaran. Pelajar mengendalikan insiden dengan peranan, halaman status dan komunikasi.
  4. Tulis postmortem dalam masa 48 jam.

Definition of Done

Pek prompt AI

  • "Tulis runbook insiden untuk 'pangkalan data primary tidak tersedia' bagi seni bina ini, termasuk langkah pengesanan, mitigasi, komunikasi dan pemulihan."
  • "Tukarkan garis masa insiden ini kepada postmortem tanpa menyalahkan dengan 5-whys dan item tindakan yang konkrit."