Incident Response
Proses dan langkah-langkah menangani insiden secara efektif dari deteksi hingga resolusi
Fase Incident Response
1. Deteksi
- Alert dari monitoring system
- Laporan dari pengguna atau customer support
- Observasi langsung oleh engineer
Hal pertama yang dilakukan: tentukan apakah ini benar-benar insiden dan severity-nya.
2. Deklarasi
- Buka incident channel (misal: Slack
#incident-2024-01-15) - Tetapkan Incident Commander
- Notifikasikan stakeholder yang relevan sesuai severity
3. Mitigasi
- Prioritas: kurangi dampak ke pengguna, bukan langsung root cause
- Opsi cepat: rollback deployment, feature flag off, reroute traffic
- Jangan menunggu root cause untuk melakukan mitigasi
4. Resolusi
- Setelah dampak berkurang, cari dan perbaiki root cause
- Verifikasi sistem kembali normal
- Deklarasikan insiden selesai
5. Follow-up
- Buat post-mortem dalam 48-72 jam
- Identifikasi dan tindaklanjuti action items
Peran dalam Incident Response
Incident Commander (IC)
- Memimpin respons, bukan mengeksekusi perbaikan teknis
- Membuat keputusan tentang prioritas dan eskalasi
- Menjaga fokus tim: "Kita cari root cause atau mitigasi dulu?"
- Bisa merupakan EM, tech lead, atau engineer senior
Tech Lead on Call
- Mengeksekusi perubahan teknis
- Menginvestigasi penyebab masalah
- Memberikan update teknis ke IC
Communications Lead
- Update ke stakeholder internal (product, bisnis, leadership)
- Tulis status page update untuk pengguna eksternal
- Contoh template: "Kami sedang menginvestigasi [masalah]. Dampak: [X]. Update berikutnya: [waktu]."
Scribe
- Dokumentasikan timeline: jam berapa apa terjadi
- Catat keputusan yang diambil dan alasannya
- Sangat membantu untuk post-mortem
Komunikasi Selama Insiden
Internal
- Update singkat setiap 15-30 menit di incident channel
- Format: "Status update [HH:MM]: [kondisi saat ini], [yang sedang dilakukan], [update berikutnya kapan]"
- Jangan biarkan stakeholder di-hang tanpa update
Eksternal (Status Page)
- Komunikasikan bahwa kalian aware dan sedang menangani
- Jangan over-promise timeline pemulihan yang belum pasti
- Contoh level komunikasi:
- "Kami sedang menginvestigasi laporan masalah"
- "Kami mengidentifikasi penyebab dan sedang menerapkan perbaikan"
- "Masalah telah diselesaikan. Kami akan publikasikan post-mortem."
Runbook
Dokumen langkah demi langkah untuk menangani insiden yang umum terjadi:
Judul: [nama insiden / gejala]
Gejala: [apa yang terlihat di monitoring/alert]
Langkah 1: Verifikasi — cek X untuk konfirmasi ini insiden Y
Langkah 2: Mitigasi cepat — lakukan A untuk kurangi dampak
Langkah 3: Investigasi — cek log di B, lihat metrik C
Langkah 4: Perbaikan — jalankan perintah D atau restart service E
Langkah 5: Verifikasi perbaikan — cek metrik F kembali normal
Eskalasi: jika langkah di atas tidak berhasil dalam 30 menit, hubungi [nama/team]Kesalahan Umum dalam Incident Response
- Terlalu banyak orang di bridge: 5-6 orang lebih efektif dari 20 orang yang bicara bersamaan
- Langsung cari root cause: prioritaskan mitigasi dulu, root cause bisa diselidiki setelah dampak berkurang
- Tidak ada IC yang jelas: tanpa koordinator, respons jadi kacau
- Komunikasi yang tidak teratur: stakeholder yang tidak dapat update akan panik dan mengganggu respons
Praktik Terbaik
- Latih proses incident response saat tidak ada insiden — game day atau tabletop exercise
- Buat template dan checklist yang bisa diikuti saat stres
- Dokumentasikan setiap insiden, bahkan yang minor
- Review waktu respons (MTTA, MTTR) secara berkala dan set target perbaikan