Belajar Site Reliability Engineer - Incident Management

#Pendahuluan

Setelah di episode 6 kita memastikan alert berbunyi pada saat yang tepat dan on-call siap menjawab, pertanyaan berikutnya: apa yang terjadi setelah pager berbunyi? Inilah yang membedakan tim yang "sibuk" dari tim yang efektif: incident management bukan soal seberapa cepat semua orang panik, melainkan seberapa terstruktur tim merespons tekanan.

Tanpa struktur, insiden berubah menjadi kekacauan yang khas: semua orang membuka terminal, mencoba hal yang sama, tidak ada yang tahu siapa yang mengambil keputusan, dan status tidak pernah dikomunikasikan ke pihak yang menunggu. Episode ini membangun struktur itu — dari deteksi sampai postmortem — dan menutupnya dengan simulasi yang bisa kalian latih di tim.

#Siklus Incident Management

#1. Detection: Lebih dari Alert

Detection dimulai dari alert, tetapi tidak berhenti di sana. Sumber deteksi yang sehat:

• Alert SLO/burn rate — deteksi berbasis janji pengguna (episode 6).
• Uptime checks eksternal — memastikan "server hidup tapi pengguna mati" tetap tertangkap.
• Laporan pengguna / support — sinyal paling lambat tapi paling jujur soal pengalaman nyata.

Aturan penting: deteksi berakhir saat orang yang tepat sudah di-notify dengan konteks cukup. Jika alert sampai ke on-call tanpa konteks, itu bukan deteksi — itu teka-teki tengah malam.

#2. Response: Pertama, Stabilkan

Prinsip pertama respons yang sering dilupakan karena semangat debugging: stabilkan dulu, debug kemudian. Urutan yang benar:

1. Stop the bleeding — bila tersedia mekanisme cepat (rollback, feature flag off, failover), pakai dulu.
2. Dokumentasikan observasi — apa yang terlihat, sejak kapan, apa yang sudah dicoba.
3. Baru debugging mendalam — setelah sistem stabil atau setidaknya tidak memburuk.

#3. Communication: Siapa yang Mengatakan Apa

Insiden yang parah bukan waktunya improvisasi komunikasi. Peran minimalnya:

• Incident Commander (IC) — satu orang yang memegang kendali: menetapkan peran, memutuskan, dan tidak ikut debugging sendirian. Keputusan besar milik IC, bukan orang paling vokal.
• Communicator — satu orang yang menulis status ke pihak luar (management, pelanggan, channel publik). Semua update keluar lewat satu suara agar tidak saling kontradiksi.
• Operations / responders — engineer yang benar-benar menangani sistem, fokus pada mitigasi.

Pola komunikasi status yang baik (format SUTC — status, update, timeline, current actions):

STATUS:  P1 - checkout error (CRITICAL, sedang ditangani)
UPDATE:  Error rate checkout naik 30x sejak 12:00 WIB, terkait rilis v2.4.1
TIMELINE: 12:00 rilis v2.4.1 -> 12:15 alert burn rate -> 12:20 rollback dimulai
NEXT:    Rollback selesai, pantau burn rate 1 jam

#Metrik yang Harus Diukur: MTTA, MTTR

Incident management yang baik diukur, bukan dirasakan:

MTTR sering disalahartikan sebagai "waktu debug". Faktanya, perbaikan tercepat hampir selalu datang dari rollback dan failover — mekanisme yang disiapkan jauh sebelum insiden. Itulah kenapa episode 11 (release reliability) dan 16 (multi-region/DR) adalah investasi MTTR terbaik.

#Blameless Postmortem

Insiden selesai bukan berarti pekerjaan selesai. Postmortem adalah jembatan dari "kenapa down?" menuju "kenapa tidak terulang?". Kuncinya satu kata: blameless — analisis tentang sistem dan proses, bukan tentang siapa.

#Struktur Postmortem yang Efektif

Judul:    [Tanggal] Insiden P1 - error massal checkout
Severity: P1 (budget habis 12 jam)
Ringkasan: error 500 naik 30x selama 2 jam, 18k order gagal
Timeline:  (12:00) rilis v2.4.1 ... (14:15) rollback selesai
Root cause: fitur cache invalidation memperkenalkan race condition
Trigger:   deployment + burst traffic
Pengaruh:  ketersediaan 99.82% bulan ini
Actions:   [A-001] tambah integrasi test untuk cache (P1, owner: x)
           [A-002] ubah pipeline rilis jadi canary (P1, owner: y)

#Bagaimana Menjaga Blameless dalam Praktik

1. Bahasa netral: "perubahan ke X memperkenalkan..." bukan "Anda merusak...".
2. Semua orang menyumbang timeline — bukan satu orang yang diinterogasi.
3. Aksi harus punya owner dan deadline — postmortem tanpa aksi adalah ritual kosong.
4. Follow-up dipantau: aksi yang tidak selesai harus menjadi agenda meeting.

#Praktik: Simulasi Incident Drill

Kunci agar struktur ini bekerja saat tekanan nyata adalah melatihnya sebelum terjadi. Jadwalkan game day 60 menit:

1. Skenario: pilih satu kegagalan realistis — misal database utama down, atau dependency lama menghilang.
2. Bunuh service: di lab, stop container atau isi disk secara bertahap.
3. Jalankan protokol: on-call di-notify, IC ditunjuk, communicator memulai status, tim menstabilkan lalu memulihkan.
4. Evaluasi 30 menit: bagaimana MTTA? Apakah runbook kedaluwarsa? Siapa yang bingung soal peran? Semua menjadi masukan postmortem drill.

docker stop sre-lab-demo-1
curl -s -o /dev/null -w "%{http_code}\n" localhost:8080/health

Hasil drill yang baik bukan "tim berhasil memulihkan dalam 10 menit" — itu hasil akhir. Yang lebih penting: apakah prosesnya kelihatan mulus? Jika tidak, itulah yang harus diperbaiki.

#Penutup

Pada episode 7 ini, kalian telah membangun alur incident management yang lengkap.

Inti yang harus dibawa pulang:

• Siklus: detect → respond → communicate → resolve → postmortem → actions.
• Peran jelas: IC memegang keputusan, communicator mengeluarkan update terjadwal, responders fokus mitigasi.
• Stabilkan dulu, debug kemudian — rollback/failover adalah perbaikan tercepat.
• Ukur MTTA/MTTR, dan selesaikan dengan blameless postmortem yang menghasilkan 2-3 aksi ber-owner.
• Latih semua ini lewat incident drill berkala.

Di episode 8 selanjutnya, kita beralih dari "merespons" ke "mencegah": capacity planning — load forecasting, menyiapkan headroom, dan strategi auto-scaling yang benar, lengkap dengan rencana kapasitas dan scaling untuk service kalian. Sampai jumpa di episode 8!