Apa yang anda lakukan untuk mengelakkan jenis incident yang sama daripada berlaku kali kedua?

Question

Accepted Answer

Jalankan **postmortem tanpa salah-menyalah** yang mencari punca sistemik, kemudian tukarkannya menjadi item tindakan yang **konkrit, dimiliki, dan dijejak** — dan sahkan ia benar-benar dihantar. Matlamatnya bukan mencari siapa untuk dipersalahkan; ia adalah mengubah sistem supaya kelas kegagalan yang sama menjadi mustahil atau boleh mengesan sendiri.

## Gelung teras

1. **Postmortem tanpa salah-menyalah.** Bina garis masa yang jujur: apa yang berlaku, bila kita mengesannya, bagaimana kita bertindak balas, apakah impaknya. Salah-menyalah membunuh kebenaran yang anda perlukan.
2. **Gali ke punca sistemik**, bukan pencetus. "Seorang jurutera menolak config yang buruk" ialah pencetus; "tiada validasi atau rollout berperingkat untuk config" ialah puncanya. Gunakan **Five Whys** tetapi berhenti pada sistem, jangan sekali-kali pada seorang individu.
3. **Hasilkan lapisan pencegahan**, bukan pembaikan tunggal:
   - **Cegah** — jadikan kegagalan mustahil (validasi, jenis, guardrail).
   - **Kesan** — tangkap ia lebih awal (alert, SLO, semakan sintetik).
   - **Mitigasi** — hadkan radius letupan (rollback, flag, circuit breaker).
4. **Tetapkan pemilik dan tarikh akhir.** Item tindakan tanpa pemilik ialah satu harapan. Jejak ia seperti kerja sebenar dalam backlog.
5. **Sahkan dan tutup gelung.** Adakah pembaikan dihantar? Adakah ia akan menangkap yang asal? Adakah MTTR dan pengesanan benar-benar bertambah baik?

## Trade-off dan perangkap

- **Postmortem yang menghasilkan dokumen, bukan perubahan** — kegagalan paling biasa. Tiada tindakan susulan bermakna anda akan bertemu incident yang sama lagi.
- **Membetulkan secara berlebihan gejala spesifik** sementara kelas pepijat itu kekal terbuka. Betulkan kategori, bukan sekadar contoh ini.
- **Keletihan alert** kerana menimbun pengesanan tanpa penalaan; alert yang bising diabaikan dan incident seterusnya terlepas.
- **Budaya salah-menyalah** memandu pelaporan ke bawah tanah; anda kehilangan nyaris-terlepas yang merupakan pengajaran paling murah anda.
- Anggap **incident berulang sebagai isyarat kegagalan proses**, bukan nasib malang — jejak keberulangan sebagai satu metrik.

## Mengapa ia penting

Incident ialah yuran yang anda sudah bayar; satu-satunya pembaziran ialah tidak belajar daripadanya. Pasukan yang secara sistematik mengelakkan keberulangan menjadi lebih boleh dipercayai setiap suku tahun, manakala pasukan yang hanya memadam api mengalami semula outage yang sama selama-lamanya. Membina gelung pembelajaran ini — dan keselamatan untuk jujur di dalamnya — adalah salah satu perkara paling tahan lama yang boleh ditinggalkan oleh seorang Tech Lead.