Belajar Infrastructure Engineer - Incident Response Infra

#Pendahuluan

Setelah di episode 19 kita mengelola rahasia dan kepatuhan, kini saatnya jujur: incident pasti terjadi. Tidak peduli seberapa baik infrastruktur dirancang — disk penuh, kabel putus, kode yang salah deploy, atau penyerang yang cerdik akan terjadi. Yang membedakan tim profesional bukan mencegahnya, melainkan meresponsnya dengan tenang, cepat, dan terorganisir.

Mengapa topik ini penting? Karena cara tim bereaksi saat incident menentukan durasi dan dampak kerusakan. Tim yang panik dan mengotak-atik tanpa rencana memperpanjang outage; tim dengan prosedur yang jelas memulihkan dalam hitungan menit. Episode ini membangun sistem incident response: proses, runbook, komunikasi, dan budaya post-mortem.

#Siklus Incident Response

#Deteksi

Sebagian besar incident pertama kali "ditemukan" oleh user — itu kegagalan observability (episode 9). Sistem yang baik mendeteksi lebih dulu: alert paging untuk kritis, dasbor untuk tren, dan synthetics yang mensimulasikan user.

#Klasifikasi Severity

Tanpa klasifikasi, semua incident tampak darurat. Standar yang umum:

#Runbook: Playbook yang Benar-Benar Dipakai

Runbook adalah instruksi langkah-demi-langkah untuk menangani situasi tertentu. Beda dengan dokumentasi biasa: runbook ditulis saat sistem dalam kondisi baik, dibaca saat keadaan kacau.

#Struktur Runbook yang Baik

# Judul: situasi spesifik, bukan gejala umum
 
## Gejala (bagaimana mengetahuinya)
- Alert apa yang berbunyi? Query apa yang dipakai?
 
## Dampak (seberapa parah?)
- Siapa yang terdampak? Berapa banyak? Sev berapa?
 
## Diagnosa (langkah cepat)
1. Periksa X
2. Periksa Y
3. Jika Z → segera ke mitigasi
 
## Mitigasi (hentikan kerusakan)
1. Langkah aman yang bisa dilakukan sekarang
 
## Recovery (kembali normal)
1. Urutan langkah kembali ke kondisi sehat
 
## Verifikasi (bukti pulih)
1. Bagaimana memastikan benar-benar pulih?
 
## Kontak (siapa menghubungi siapa)

#Prinsip Runbook

1. Satu runbook per skenario — tidak ada "runbook umum".
2. Langkah yang aman: mitigasi pertama harus yang tidak memperparah.
3. Ditulis dari incident nyata — bukan dari imajinasi.
4. Diupload dan mudah dicari — tempat yang sama, bukan di dokumen tersebar.
5. Di-review berkala — runbook yang basi lebih berbahaya daripada tidak ada.

Contoh runbook singkat untuk "disk penuh":

Gejala   : alert HighDiskUsage, aplikasi mulai gagal tulis
Dampak   : Sev-2 (produksi terdampak)
Diagnosa :
    df -h / ; du -xsh /* 2>/dev/null | sort -h | tail
    journalctl --disk-usage
Mitigasi :
    # bersihkan log dengan aman (JANGAN hapus data aplikasi!)
    journalctl --vacuum-size=200M
    # temukan & komunikasikan file besar sebelum hapus
Recovery :
    pastikan aplikasi bisa tulis lagi; pantau 30 menit
Kontak   : on-call + pemilik aplikasi

#Komunikasi Incident

Saat incident, komunikasi yang buruk memperpanjang outage — orang sibuk bertanya alih-alih bekerja. Sistem yang benar:

#Satu Channel, Satu Sumber Kebenaran

Semua informasi incident di satu tempat (channel khusus / status page), dengan format baku:

[SEV-1] API produksi down
Status   : Mitigasi (rolled back v2.4.1 → v2.4.0)
Dampak   : 30% traffic gagal, checkout terdampak
Durasi   : mulai 14:02 WIB, aktif 18 menit
Pemilik  : @oncall-api
Next     : verifikasi health check 15 menit lagi

Update rutin setiap X menit — bahkan "belum ada kemajuan, masih diagnosa" lebih baik daripada keheningan.

#Peran dalam Incident

• Incident Commander: satu orang pengambil keputusan — tidak ikut debugging, hanya koordinasi.
• Ops lead: yang melakukan tindakan mitigasi.
• Komunikator: yang meng-update stakeholder & status page.
• Scribe: pencatat timeline.

Satu aturan emas: satu orang men-debug pada satu waktu. Dua orang mengubah config bersamaan = tidak ada yang tahu perubahan siapa yang memperbaiki atau merusak.

#Recovery

Recovery bukan "aplikasi jalan lagi" — ia proses yang terkontrol:

1. Stabilisasi: hentikan kerusakan meluas (mitigasi).
2. Restorasi bertahap: kembalikan layanan sedikit demi sedikit — jangan sekaligus.
3. Verifikasi: ukur bahwa layanan sehat secara nyata (traffic normal, error turun).
4. Monitor post-incident: pantau intensif 24-48 jam setelah recovery.

#Blameless Post-Mortem

Post-mortem adalah analisis setelah incident — tujuannya bukan mencari yang salah, melainkan memperbaiki sistem. Blameless berarti: tidak ada individu yang disalahkan; fokus pada proses, tooling, dan kondisi yang memungkinkan kesalahan.

#Struktur Post-Mortem

Judul        : Ringkasan satu kalimat
Timeline     : Fakta kronologis (deteksi → mitigasi → recovery)
Root cause   : Analisis akar masalah (5 Whys)
Dampak       : Durasi, user terdampak, biaya
Aksi         : Item tindakan perbaikan (ber-owner + deadline)
Lesson       : Apa yang bisa dipelajari tim lain

#5 Whys: Menembus Akar Masalah

Contoh: "API down karena database hang."

1. Mengapa database hang? → Query lambat memakan semua koneksi.
2. Mengapa query lambat? → Index hilang setelah migrasi schema.
3. Mengapa index hilang? → Migrasi tidak diuji di staging.
4. Mengapa tidak diuji? → CI tidak menjalankan migrasi.
5. Mengapa CI tidak menjalankannya? → Proses migrasi tidak terotomasi.

Akar masalahnya bukan "query lambat" — melainkan proses yang tidak menguji migrasi. Perbaikan yang benar: otomasi migrasi di CI, bukan "berhati-hati lagi".

#Aksi yang Bisa Dilaksanakan

Post-mortem tanpa aksi adalah latihan menulis. Setiap aksi harus:

• Spesifik: bukan "perbaiki monitoring", melainkan "tambah alert replication lag > 30s".
• Ber-owner: satu orang bertanggung jawab.
• Ber-deadline: tanggal yang jelas.
• Dilacak: ditinjau dalam meeting berkala sampai selesai.

#Common Pitfalls Incident Response

• Mencari yang salah alih-alih memperbaiki: debugging sambil menyalahkan memperlambat semua orang.
• Tanpa runbook: menulis prosedur saat server terbakar = 10x lebih lambat.
• Komunikasi berantakan: informasi tersebar di DM pribadi, tidak ada yang tahu gambaran penuh.
• Recovery sekaligus: semua traffic dilepas bersamaan padahal belum tentu stabil.
• Post-mortem tanpa aksi: rapat selesai, tidak ada yang berubah, incident terulang.
• Incident tidak diumumkan: tim lain tersandung masalah yang sama tanpa tahu.

#Penutup

Pada episode 20 ini kalian telah membangun sistem incident response:

• Siklus: deteksi → triage → mitigasi → recovery → post-mortem → perbaikan.
• Runbook satu skenario per dokumen, ditulis dari incident nyata, mudah dicari.
• Komunikasi satu channel, Incident Commander memimpin, satu orang debug pada satu waktu.
• Blameless post-mortem dengan 5 Whys dan aksi ber-owner + deadline.
• Budaya tanpa menyalahkan membuat incident terlihat dan sistem membaik.

Di episode 21 selanjutnya kita memastikan sistem tidak gampang tumbang: high availability & scaling — redundancy, auto-scaling, dan desain failover. Sampai jumpa di episode 21!