Incident response adalah cara terstruktur menangani gangguan production: mendeteksi, menilai seberapa parah, memulihkan layanan secepatnya, lalu belajar darinya lewat postmortem. Bayangin regu pemadam kebakaran. Komandan regu gak ikut memegang selang: dia membagi tugas dan mengambil keputusan. Api dipadamkan dulu, penyebabnya diselidiki belakangan. Laporan sesudahnya membahas kenapa api bisa merambat (kabel tua, gak ada alat pemadam), bukan mencari siapa yang harus dihukum. Begitu juga insiden di catatan-api.
Pelajaran ini tentang insiden operasional: layanan down atau rusak. Insiden keamanan (kebocoran data, akun dibobol) punya langkah tambahan, dibahas di pelajaran Incident Response untuk Developer di track Security.
🧪 Tebakan cepat: alert error rate catatan-api firing pukul 19:06, enam menit setelah deploy v1.9.0. Belum ada yang tahu penyebabnya. Cari dulu bug-nya di kode, atau rollback dulu? Jawabannya ada di bagian "Mitigate dulu, root cause belakangan".
Severity: seberapa besar dampaknya
Langkah pertama setelah alert adalah menilai severity, karena severity menentukan siapa yang dipanggil dan seberapa cepat:
| Level | Artinya | Contoh |
|---|---|---|
| SEV1 (critical) | layanan down untuk semua atau hampir semua user, atau ada data hilang | semua request catatan-api gagal |
| SEV2 (major) | fungsi penting rusak atau lambat untuk sebagian user | 30% user gak bisa login, sisanya normal |
| SEV3 (minor) | mengganggu, tapi ada jalan lain | ekspor PDF gagal untuk lampiran besar |
| SEV4 (low) | kosmetik, dikerjakan di jam kerja biasa | ikon bergeser 2 piksel |
Kalau ragu, pilih yang lebih tinggi. Menurunkan severity itu murah, terlambat memanggil orang itu mahal.
Empat fase: detect, triage, mitigate, resolve
Ini insiden di Lab, Selasa 13 Oktober 2026 (WIB), dengan jalur tercepat:
| Jam | Fase | Kejadian |
|---|---|---|
| 19:00 | deploy v1.9.0 (fitur tag catatan) | |
| 19:03 | pool koneksi habis, 80% request gagal setelah menunggu 5 detik | |
| 19:06 | detect | alert CatatanApiErrorRateTinggi firing, on-call (Rani) dipanggil |
| 19:08 | triage | Rani ack, membuka Grafana: error rate 80% |
| 19:09 | triage | Rani menyatakan SEV1, jadi incident commander |
| 19:10 | mitigate | keputusan: rollback ke v1.8.0 |
| 19:15 | mitigate | v1.8.0 jalan, error turun ke 0,2% |
| 19:30 | resolve | stabil 15 menit, insiden ditutup |
- Detect: masalah ketahuan, idealnya dari alert (pelajaran Grafana & Prometheus), bukan dari keluhan user. Di sini 3 menit setelah dampak dimulai.
- Triage: tentukan severity, tunjuk incident commander, buka war room (channel
#inc-catatan-1013atau video call). - Mitigate: pulihkan layanan secepatnya.
- Resolve: pastikan benar-benar pulih, pantau sebentar supaya gak kambuh, lalu tutup insidennya.
Dampaknya 12 menit (19:03 sampai 19:15). Dengan 1.000 request per menit dan 80% gagal, itu sekitar 9.600 request gagal: 22,2% dari error budget 30 hari (SLO 99,9% berarti 43.200 request boleh gagal per 30 hari, lihat pelajaran Site Reliability Engineering).
Peran: incident commander, comms, ops
Di insiden SEV1, satu orang yang mengerjakan semuanya pasti kewalahan. Perannya dibagi:
- Incident commander (IC), Rani: memimpin, membagi tugas, dan mengambil keputusan, misalnya "rollback sekarang". IC gak ikut debug, supaya selalu melihat gambar besarnya.
- Comms, Dimas: memperbarui status page dan memberi kabar ke tim lain dan customer support, rutin, walaupun belum ada kabar baru.
- Ops (subject matter expert), Bayu: menjalankan perintah teknis, seperti rollback, dan menyelidiki.
Salah satu dari mereka juga mencatat timeline dengan jam, karena ingatan di tengah insiden gak bisa dipercaya.
Status page: update yang jujur dan rutin
User yang aplikasinya error ingin tahu tiga hal: kalian tahu, kalian sedang menangani, dan kapan beres. Status page seperti status.catatan.example.com menjawabnya dengan empat status update yang umum dipakai:
| Jam | Status | Isi |
|---|---|---|
| 19:10 | Investigating | Kami sedang menyelidiki gangguan: catatan gagal dimuat dan disimpan untuk sebagian besar pengguna. |
| 19:11 | Identified | Masalahnya berasal dari rilis pukul 19:00. Kami sedang mengembalikan versi sebelumnya. |
| 19:16 | Monitoring | Perbaikan sudah diterapkan dan layanan kembali normal. Kami terus memantau. |
| 19:30 | Resolved | Insiden selesai. Catatan bisa dimuat dan disimpan seperti biasa sejak 19:15 WIB. |
Status komponennya mengikuti severity: SEV1 di sini berarti Major outage, bukan "Degraded performance". Menulis dampak lebih kecil dari kenyataannya membuat user makin kesal. Selama insiden berjalan, beri update tiap 30 menit walaupun isinya "masih diselidiki".
Mitigate dulu, root cause belakangan
Di fase mitigate, prioritasnya memulihkan layanan, bukan mencari root cause. Masalah muncul tepat setelah deploy, jadi cara tercepat adalah rollback ke v1.8.0, dan penyebabnya diselidiki setelah layanan pulih. Itu jawaban tebakannya. Lab menghitung tiga pilihan dari jam 19:10:
| Pilihan | Pulih | Dampak | Request gagal | Error budget |
|---|---|---|---|---|
| rollback ke v1.8.0 | 19:15 | 12 menit | 9.600 | 22,2% |
| restart container, lalu rollback | 19:20 | 14 menit | 11.200 | 25,9% |
| cari root cause dulu, lalu hotfix | 19:51 | 48 menit | 38.400 | 88,9% |
Restart cuma menunda: bug-nya masih ada, jadi pool habis lagi 3 menit kemudian. Pilihan mitigasi lain yang umum: mematikan fitur lewat feature flag (pelajaran Feature Flags), menambah kapasitas (scale up), atau pindah ke server cadangan (failover). Rollback gak menghapus bug dari repo, jadi perbaikannya tetap bisa dikerjakan dengan tenang besoknya. Dan kalau ack-nya menunggu laporan user (19:21, bukan 19:08), dampaknya jadi 25 menit walaupun rollback-nya sama.
Postmortem yang blameless
Dalam beberapa hari kerja, selagi ingatan masih segar (di sini Kamis, 15 Oktober), tim menulis postmortem. Templatenya:
# Postmortem: catatan gagal dimuat dan disimpan
Tanggal: Selasa, 13 Oktober 2026
Severity: SEV1, dampak 12 menit (19:03 sampai 19:15 WIB), ~9.600 request gagal
Incident commander: Rani · Comms: Dimas · Ops: Bayu
## Timeline
- 19:00 Deploy v1.9.0 lewat pipeline
- 19:03 Pool koneksi habis, 80% request gagal
- ... (jam per jam, dari timeline yang dicatat)
## Root cause
Handler POST /catatan/:id/tag mengembalikan 400 tanpa melepas koneksi ke pool.
Tiap tag yang ditolak membocorkan satu koneksi sampai pool (max 10) habis,
lalu semua query menunggu 5 detik dan gagal.
## Faktor pendukung
- Tes cuma menguji jalur sukses: jalur validasi gagal gak pernah dites
- v1.9.0 langsung melayani 100% traffic, tanpa canary
- Belum ada alert untuk pool koneksi yang hampir penuh
## Action items
- [ ] Pakai pool.query() atau try/finally client.release() di semua handler (Bayu, 16 Okt)
- [ ] Tes integrasi: 100 tag ditolak, pool tetap tanpa koneksi bocor (Sari, 20 Okt)
- [ ] Canary 5% selama 10 menit untuk tiap rilis (Dimas, 27 Okt)
- Root cause: mekanisme yang bisa dibuktikan dari data, bukan tebakan ("PostgreSQL lambat" salah: error-nya
timeout exceeded when trying to connect, artinya pool di aplikasi yang habis). - Faktor pendukung: kenapa bug itu bisa lolos dan kenapa dampaknya sebesar itu.
- Action items: tiap item punya pemilik dan tenggat, dan bisa dicek selesai atau belum.
Blameless artinya fokus ke sistem dan proses, bukan ke orangnya. "Bayu lupa client.release()" benar secara fakta, tapi gak mengubah apa-apa: besok orang lain bisa lupa hal yang sama. Yang ditanyakan adalah kenapa tes, review, dan rollout membiarkannya lolos. Kalau orang takut disalahkan, mereka berhenti melaporkan kesalahan, dan tim kehilangan bahan belajarnya.
⚠️ Jebakan yang sering ketemu
- Debug di tengah outage. Tiap menit mencari bug = 800 request gagal. Mitigate dulu, root cause setelah layanan pulih.
- IC ikut ngoding. Begitu IC tenggelam di log, gak ada yang memutuskan dan gak ada yang memberi kabar.
- Status page diam, atau menyepelekan. "Degraded performance" saat 80% request gagal merusak kepercayaan lebih dari outage-nya sendiri.
- Action item yang gak bisa dicek. "Lebih hati-hati saat review" gak punya pemilik dan tenggat. Tulis perubahan yang konkret.
TL;DR: Incident response punya empat fase: detect (idealnya lewat alert), triage (tentukan severity dan tunjuk incident commander), mitigate (pulihkan layanan secepatnya, misalnya rollback, bukan mencari root cause dulu), dan resolve (pastikan pulih, pantau, tutup). SEV1 untuk layanan down bagi semua user atau data hilang, SEV2 untuk fungsi penting yang rusak bagi sebagian user (30% gagal login itu SEV2), SEV3 untuk gangguan dengan jalan lain, SEV4 untuk kosmetik. Perannya incident commander (memimpin, gak ikut debug), comms (status page dan kabar rutin), dan ops (eksekusi). Status page bergerak dari Investigating, Identified, Monitoring, sampai Resolved, dengan dampak yang jujur. Postmortem ditulis dalam beberapa hari kerja dan blameless: fokus ke sistem dan proses, bukan orang, berisi timeline, root cause yang terbukti, faktor pendukung, dan action items dengan pemilik dan tenggat.
