Produksi terbakar dalam pengembangan — apa itu, penyebab dan algoritma tindakan

Apa arti "produksi terbakar" dan jenis kegagalan apa saja yang ada

Ungkapan "produksi terbakar" (production is on fire, everything is down) menggambarkan situasi ketika lingkungan produksi tidak berfungsi dengan benar dan hal ini memengaruhi pengguna. Kegagalan dapat bermanifestasi sebagai ketidaktersediaan total aplikasi (blank screen, kesalahan 502), ketidaktersediaan sebagian (modul pembayaran tidak berfungsi tetapi fungsi lain tersedia), atau degradasi kinerja (pemuatan sangat lambat). Severity insiden ditentukan oleh persentase pengguna yang terkena dampak dan durasi kegagalan.

Menurut Atlassian Statuspage (2025), rata-rata downtime untuk aplikasi mobile pada tahun 2024 adalah 27 menit per insiden. Penyebab paling umum: regresi kode setelah deploy (34%), kegagalan penyedia cloud (22%), masalah basis data (18%), kesalahan konfigurasi (15%) dan serangan DDoS (11%). Kesimpulan utama: sebagian besar kegagalan terkait dengan perubahan yang dilakukan tim sendiri, bukan faktor eksternal.

Penting untuk membedakan antara crash (aplikasi crash di sisi klien) dan backend outage (server tidak tersedia). Crash biasanya diperbaiki dengan hotfix kode klien, sedangkan backend outage melalui perubahan infrastruktur atau redeploy layanan. Metrik pemantauan: untuk klien — crash-free rate, untuk server — error rate 5xx dan p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — membantu menentukan jenis kegagalan dengan cepat.

Tingkat severity insiden: P0, P1, P2 dan kriteria klasifikasi

Klasifikasi severity yang seragam adalah dasar respons cepat. Tanpanya, tim membuang waktu berdiskusi "seberapa mendesak ini" daripada bertindak. Skala klasik: P0 (critical) — aplikasi sepenuhnya tidak tersedia atau data pengguna bocor, waktu respons — segera; P1 (high) — fungsionalitas kritis tidak berfungsi untuk 50%+ pengguna, waktu respons — 15 menit; P2 (medium) — fungsionalitas tidak kritis tidak tersedia bagi sebagian pengguna, waktu respons — 1 jam.

P0 memerlukan eskalasi segera: insinyur jaga menghentikan pekerjaan saat ini dan beralih ke insiden. Jika setelah 10 menit masalah belum teratasi — tech lead bergabung. Jika setelah 30 menit — eskalasi ke engineering manager. Untuk insiden P0, diperbolehkan melanggar proses apa pun: hotfix tanpa code review lengkap, deploy langsung ke produksi, mengabaikan aturan branch protection. Emergency override harus disetujui sebelumnya di tingkat tim.

Tabel severity

Sangat penting untuk tidak salah mengklasifikasikan severity ke bawah. P0 + P1 yang diklasifikasikan sebagai P2 menyebabkan respons tertunda dan peningkatan downtime. Aturan: jika ragu — tetapkan P0. Over-classification lebih baik daripada under-classification: lebih baik mengadakan pertemuan ekstra daripada kehilangan satu jam waktu pemulihan.

10 menit pertama: algoritma tindakan saat kegagalan

Timer starts: sejak alert atau pesan dari pengguna masuk. 10 menit pertama — yang terpenting. Algoritma: 1) confirm the issue — pastikan masalahnya nyata (bukan alarm palsu); 2) stop the bleeding — segera kurangi dampak (rollback, feature toggle, blokir endpoint); 3) communicate — tulis di kanal umum #incident status: apa yang terjadi, severity, apa yang dilakukan. 10 menit pertama tidak dihabiskan untuk analisis akar penyebab.

Secara paralel dengan menghentikan pendarahan, satu insinyur memulai diagnosis, yang kedua — komunikasi. Saluran komunikasi: Slack #incident channel (untuk tim), halaman status (untuk pengguna), email/SMS eskalasi (untuk manajemen). Setiap 15 menit — pembaruan status dengan informasi: apa yang diketahui, apa yang dilakukan, perkiraan waktu pemulihan. Status page (StatuPage, Statuspal) menampilkan uptime dan riwayat insiden untuk pengguna eksternal.

Cara menghentikan pendarahan: rollback, feature toggle dan hotfix

Aturan pertama dan terpenting: jangan mencoba memperbaiki masalah di produksi. Jika rilis baru menyebabkan kegagalan — rollback ke versi stabil sebelumnya. Jika kegagalan disebabkan oleh fitur tertentu yang dinonaktifkan melalui feature toggle — cukup matikan toggle. Jika rollback maupun toggle tidak tersedia — hotfix dengan diff minimal. Rollback — opsi teraman, karena kita kembali ke kondisi yang sudah berfungsi.

Feature toggle (aka feature flag) — alat yang kuat untuk stop-the-bleeding tanpa deploy. Jika modul pembayaran crash tetapi dinonaktifkan melalui toggle — pengguna tidak melihat tombol pembayaran, bukan layar kesalahan. Toggle tidak memerlukan pembuatan build, tidak memerlukan review toko, bekerja dalam hitungan detik. Setiap fitur kritis harus berada di bawah feature toggle dengan kemampuan penonaktifan di tingkat server (remote config). Feature flag — garis pertahanan pertama.

Jika rollback tidak memungkinkan (misalnya karena migrasi BD yang tidak dapat dibalikkan) dan toggle tidak tersedia — upaya terakhir: hotfix dengan perbaikan minimal. Hotfix dibuat dari tag rilis terakhir, hanya berisi baris yang diperlukan untuk menghilangkan kegagalan dan menjalani deploy fast-track (lihat artikel "Hotfix — perbaikan mendesak"). Golden rule: setelah stabilisasi, selalu lakukan root cause analysis, bahkan jika penyebabnya tampak jelas.

Diagnosis penyebab: log, metrik dan alarm

Setelah menghentikan pendarahan (atau secara paralel, jika jumlah insinyur memungkinkan) diagnosis dimulai. Sumber pertama — log. Pencatatan terpusat (ELK, Grafana Loki, Datadog Logs) memungkinkan menemukan kesalahan berdasarkan timestamp, ID pengguna, atau ID permintaan. Penting: log harus terstruktur (JSON) agar grep berfungsi cepat. Structured logging — persyaratan wajib untuk semua layanan.

Sumber kedua — metrik. Grafana, Datadog, New Relic menunjukkan kapan lonjakan kesalahan terjadi, di endpoint mana, dengan kode status apa. Perbandingan metrik sebelum dan sesudah deploy membantu melokalisasi masalah ke layanan atau endpoint tertentu. RED metrics (Rate, Errors, Duration) — standar pemantauan mikrolayanan.

Sumber ketiga — distributed tracing. Jaeger, Zipkin, Datadog APM menunjukkan jalur permintaan melalui mikrolayanan dan mengidentifikasi di mana tepatnya penundaan atau kesalahan terjadi. Tracing sangat berguna dalam kegagalan berantai, ketika kesalahan di satu layanan menyebabkan kesalahan di semua layanan yang bergantung. Trace ID harus diteruskan dari klien ke semua layanan backend.

# Contoh diagnostik cepat menggunakan kubectl dan log
# Daftar pod dengan kesalahan
kubectl get pods --field-selector=status.phase!=Running

# Periksa log pod yang crash
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Cari kesalahan di layanan selama 30 menit terakhir
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Penting: jangan mencoba mendiagnosis penyebab sebelum menghentikan pendarahan. Jika 50% pengguna melihat crash — rollback dulu, baru analisis. Pengecualian: jika rollback akan memakan waktu lebih lama daripada hotfix langsung (misalnya dalam kasus ketidakcocokan data). Dalam hal ini, hotfix diterapkan segera, dan post-mortem dilakukan setelah stabilisasi. Diagnosis before fix — pola berbahaya yang meningkatkan downtime.

Post-mortem: cara menganalisis insiden tanpa mencari kesalahan

Post-mortem (juga disebut incident review) — analisis terstruktur dari insiden yang dilakukan 24-72 jam setelah penyelesaiannya. Tujuan: memahami mengapa kegagalan terjadi, mengapa pemantauan dan pengujian tidak menangkapnya sebelum produksi, dan apa yang harus diubah dalam proses untuk mencegah terulangnya. Blameless culture — prinsip fundamental: post-mortem membahas proses, alat, dan komunikasi, bukan kesalahan orang tertentu.

Struktur dokumen post-mortem: timeline (kronologi kejadian dengan timestamp), impact (pengguna yang terkena dampak, durasi, kerugian finansial), root cause (penyebab teknis utama), detection (bagaimana ditemukan, mengapa tidak tertangkap lebih awal), response (apa yang dilakukan, apa yang bisa dilakukan lebih cepat), action items (tugas konkret dengan penanggung jawab dan tenggat waktu). Action items harus S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Action items tipikal setelah kegagalan produksi: menambahkan pemantauan dan alert untuk metrik yang diam; memperluas cakupan pengujian untuk kasus yang terlewat; menambahkan halaman di runbook dengan algoritma langkah demi langkah untuk situasi serupa; melakukan pelatihan tim untuk alat yang digunakan secara tidak benar. Setiap action item adalah perubahan konkret yang mengurangi kemungkinan terulangnya insiden.