Tangani insiden dan tinjau rancangan

Pertanyaan

Saat layanan rusak, apa yang dilakukan dulu, siapa memutuskan apa, dan apa yang diubah setelahnya supaya kejadian yang sama nggak terulang?

Setelah baca ini, kamu bisa menjalankan respons insiden yang terstruktur, menjaga bukti sambil memulihkan, dan menulis tinjauan yang menghasilkan perubahan rancangan, bukan daftar nama yang disalahkan.

Prasyarat dan contoh

Lesson ini menutup M16 dan memakai semuanya: SLI dan burn rate (M16.01), saklar degradasi (M16.02), batas rollback (M16.03), pemulihan terukur (M16.04), dan batas keamanan (M16.05).

Contoh: pukul 14:02 alert burn rate berbunyi. Error checkout 12%. Tiga orang membuka tiga dashboard, dua orang mulai menebak penyebab, satu orang mem-restart database tanpa memberi tahu siapa pun. Restart itu menghapus data diagnostik di memori dan mengubah gejala. Tiga puluh menit kemudian tim masih belum tahu apakah restart membantu atau memperburuk.

Mekanisme

Peran yang jelas. Satu incident commander yang mengoordinasi dan memutuskan (bukan orang yang paling jago teknis). Satu atau lebih penyelidik yang bekerja di sistem. Satu pencatat dan juru komunikasi yang menulis lini masa dan memberi kabar. Insiden kecil boleh dirangkap, tapi ketiga fungsi tetap ada.

Triase. Tentukan keparahan dari dampak ke user, bukan dari kerumitan teknis: berapa persen user, alur mana, berapa cepat anggaran error terbakar. Contoh skala: SEV1 (alur inti turun, burn rate di atas 14), SEV2 (degradasi besar), SEV3 (dampak kecil). Keparahan menentukan siapa dipanggil dan seberapa sering kabar diberikan.

Mitigasi dulu, akar masalah nanti. Tujuan pertama adalah menghentikan dampak: rollback, matikan feature flag, aktifkan mode degradasi, alihkan trafik, tambah kapasitas. Mencari penyebab terdalam saat user masih terdampak adalah prioritas yang salah. Mitigasi yang paling cepat biasanya yang sudah disiapkan dan diuji sebelumnya.

Penjagaan bukti. Sebelum mengubah apa pun yang menghapus jejak (restart, redeploy, rotasi log), ambil data: simpan log dan metrik, tangkap heap atau thread dump, catat versi dan konfigurasi yang jalan, tandai waktu di grafik. Tuliskan tiap tindakan beserta jamnya di lini masa bersama. Untuk insiden keamanan, pertahankan rantai bukti dan batasi siapa yang boleh mengakses.

Komunikasi. Pembaruan berkala dengan format tetap: apa dampaknya, apa yang diketahui, apa yang sedang dikerjakan, kapan kabar berikutnya. Untuk SEV1, misalnya tiap 30 menit meski isinya "belum ada perubahan". Jangan menebak penyebab ke luar. Pisahkan kanal koordinasi internal dan halaman status publik.

Verifikasi pemulihan. "Alert berhenti" belum berarti pulih. Periksa SLI dari sisi user kembali normal selama jendela yang disepakati (mis. 30 menit), antrean yang menumpuk terkuras, data yang tidak konsisten terdeteksi, dan klien yang retry sudah mereda. Kalau pemulihan melibatkan restore data, jalankan pemeriksaan integritas dari M16.04.

Tinjauan tanpa menyalahkan. Tanya "kenapa sistem membuat tindakan itu terasa masuk akal", bukan "siapa yang salah". Isi: lini masa, dampak (menit, jumlah request, anggaran error terpakai), faktor penyumbang (bukan satu akar tunggal), apa yang berjalan baik, apa yang beruntung, dan tindakan tindak lanjut dengan pemilik dan tenggat.

Menilai ulang rancangan. Tiap tindak lanjut punya biaya. Tambah circuit breaker, replika, atau kontrol baru juga menambah kompleksitas dan titik kegagalan baru. Bandingkan: berapa kali kejadian ini mungkin terulang, berapa dampak per kejadian, dan berapa biaya perbaikannya (bangun, jalankan, pelihara). Kadang jawabannya adalah menyederhanakan, atau menerima risikonya secara eksplisit.

Saat rancangan ini gagal

• Semua orang menyelidiki, tidak ada yang memimpin. Tindakan bertabrakan dan tidak tercatat.
• Mengejar akar masalah sebelum mitigasi. Dampak berlangsung lebih lama dari perlu.
• Perubahan yang menghapus bukti. Restart cepat memulihkan, tapi penyebab tidak pernah diketahui dan insiden berulang.
• Komunikasi tidak teratur. Pemangku kepentingan bertanya terus-menerus ke penyelidik dan memperlambat kerja.
• Tinjauan yang menyalahkan individu. Orang berhenti melaporkan kesalahan, dan masalah sistemik tetap ada.
• Tindak lanjut tanpa pemilik atau tenggat. Daftar panjang, nol yang selesai.
• Overkorreksi. Satu insiden mendorong lapisan proses dan kontrol baru yang menambah beban melebihi risikonya.
• Runbook usang. Perintah yang sudah tidak ada atau dashboard yang berubah nama. Latih lewat simulasi (game day) secara berkala.

Contoh tandingan: tidak semua insiden butuh tinjauan formal. Gangguan 3 menit yang dampaknya sudah ditangani otomatis oleh fallback cukup dicatat singkat. Tinjauan penuh dicadangkan untuk insiden yang melampaui ambang dampak yang disepakati.

Latihan

Simulasi: setelah rilis pukul 10:00, p99 checkout naik dari 400 ms ke 6 detik, error rate 8%. SLO 99,9% per 30 hari, trafik checkout 20 juta request/bulan (anggaran 20.000 gagal). Laju rata-rata sekitar 460 request/menit. Rollback tersedia dan diuji. Ada sebuah thread dump yang belum diambil.

1. Urutkan lima tindakan pertama.
2. Berapa anggaran error yang terbakar jika 8% error bertahan 20 menit?
3. Tulis dua tindak lanjut yang baik dari tinjauan.

Lihat pembahasan+

1. Urutan yang masuk akal:
   1. Umumkan insiden, tetapkan commander dan pencatat, dan tetapkan SEV1 karena alur inti terdampak.
   2. Catat korelasi: error naik tepat setelah rilis 10:00.
   3. Ambil bukti singkat dari satu instance yang bermasalah (thread dump, log sampel, versi) tanpa menunda lebih dari beberapa menit.
   4. Mitigasi: rollback rilis atau matikan flag, karena rollback sudah teruji dan batas rollback belum terlewati (tidak ada migrasi destruktif).
   5. Verifikasi: p99 dan error rate kembali normal selama 30 menit, dan antrean terkuras. Kirim pembaruan ke pemangku kepentingan.
2. 460 request/menit × 20 menit = 9.200 request, × 8% ≈ 736 gagal, sekitar 3,7% dari anggaran (736 / 20.000). Kalau terjadi pada jam puncak yang beberapa kali lebih ramai, persentasenya kelipatan itu. Burn rate saat insiden: 8% / 0,1% = 80, jauh di atas ambang page.
3. Tindak lanjut yang baik: (a) "Canary 5% dengan rollback otomatis kalau p99 lebih dari 2× baseline selama 10 menit, pemilik: tim platform, tenggat: 30 hari, diuji dengan rilis sengaja lambat di staging". (b) "Tambah tes beban pada query checkout yang berubah di rilis ini ke CI, dengan ambang p99 800 ms, pemilik: tim checkout, tenggat: 2 minggu". Hindari "tinjau lebih hati-hati".

Perhatikan bahwa kedua tindak lanjut menyasar sistem, bukan individu yang membuat rilis.

Terkait

• M16.01 Ukur perjalanan pengguna memberi SLI, burn rate, dan trace untuk triase.
• M16.03 Deploy dan migrasikan dengan aman menentukan apakah rollback masih opsi.
• M16.04 Lakukan pemulihan, bukan sekadar berasumsi menyediakan prosedur restore yang sudah diukur.

Catatan

• Asumsi: trafik dianggap seragam di latihan, dan rollback tidak melibatkan perubahan data.
• Struktur peran dan tingkat keparahan adalah contoh yang lazim. Sesuaikan dengan ukuran tim.
• Yang nggak dibahas: pengaturan on-call dan kelelahan, aspek hukum pelaporan insiden, dan forensik keamanan mendalam.
• Terakhir ditinjau: 26 Oktober 2026.