Incident Troubleshooting & Production Monitoring

Monitoring yang baik tidak mencegah semua insiden, tetapi mempercepat deteksi dan pemulihan. Halaman ini menggabungkan observability dengan proses insiden.

Siklus insidenCopy Anchor Link

Deteksi → Triage → Mitigasi → Diagnosa → Perbaikan → Postmortem

SeverityCopy Anchor Link

Dashboard monitoringCopy Anchor Link

Dashboard produksi minimal:

• Availability/uptime.
• Error rate (4xx/5xx).
• Latency p50/p95/p99.
• Request per second.
• CPU, RAM, disk.
• Database connections dan query latency.
• Replication lag.
• Queue depth.
• Deploy annotation.

Tambahkan anotasi deploy agar lonjakan bisa dikorelasikan.

SLO burn rateCopy Anchor Link

Burn rate mengukur seberapa cepat error budget habis.

burn rate = error rate aktual / error budget rate

Alert multi-window:

Ini mengurangi alert yang tidak perlu.

RunbookCopy Anchor Link

Setiap alert penting harus punya runbook:

• Arti alert.
• Dampak pengguna.
• Langkah verifikasi.
• Mitigasi cepat.
• Eskalasi.
• Tautan dashboard/log.

Contoh:

# Alert: HighErrorRate

## Cek
1. Buka dashboard API.
2. Lihat error rate per route.
3. Cek log: {job="app"} |= "ERROR"
4. Cek deploy terakhir.

## Mitigasi
- Rollback jika muncul setelah deploy.
- Restart instance jika hang.
- Hubungi DB on-call jika query timeout.

KomunikasiCopy Anchor Link

• Tetapkan incident commander.
• Update status berkala.
• Gunakan channel insiden.
• Hindari spekulasi; sampaikan fakta dan ETA.
• Setelah pulih, umumkan resolusi.

Diagnosa berbasis sinyalCopy Anchor Link

Mitigasi vs perbaikanCopy Anchor Link

Mitigasi mengembalikan layanan; perbaikan menghilangkan akar masalah.

Contoh:

• Rollback = mitigasi.
• Memperbaiki query lambat = perbaikan.

Jangan menunda mitigasi demi mencari akar masalah.

PostmortemCopy Anchor Link

# Postmortem: API 500 selama 18 menit

## Ringkasan
...

## Dampak
...

## Timeline
- 10:00 deploy v1.4.0
- 10:03 error rate naik
- 10:05 alert
- 10:08 rollback
- 10:18 layanan normal

## Akar masalah
Migrasi kolom tidak kompatibel dengan kode lama.

## Tindakan
- [ ] Migrasi expand-contract (owner, tenggat)
- [ ] Test kompatibilitas versi (owner, tenggat)

Praktik: latihan insidenCopy Anchor Link

1. Buat skenario (DB down, app 500, disk penuh).
2. Jalankan di staging.
3. Ukur waktu deteksi dan pemulihan.
4. Uji runbook.
5. Perbaiki gap.

RingkasanCopy Anchor Link

• Deteksi cepat bergantung pada metrik, log, dan alert yang tepat.
• Severity dan runbook mempercepat respons.
• SLO burn rate mengurangi alert fatigue.
• Postmortem blameless menghasilkan perbaikan nyata.