Production Troubleshooting

Saat produksi bermasalah, prioritasnya adalah memulihkan layanan, lalu menemukan akar masalah. Panik dan perubahan acak memperburuk keadaan.

Urutan penanganan insidenCopy Anchor Link

1. Deteksi — alert atau laporan pengguna.
2. Triage — seberapa luas dampaknya?
3. Mitigasi — rollback, restart, failover, atau disable fitur.
4. Diagnosa — kumpulkan metrik, log, trace.
5. Perbaikan — perbaiki akar masalah.
6. Postmortem — dokumentasikan dan cegah berulang.

Peta gejalaCopy Anchor Link

1. Cek status layananCopy Anchor Link

systemctl status nginx --no-pager
pm2 list
docker compose ps
curl -I https://app.example.com
curl -f http://127.0.0.1:3000/health

2. LogCopy Anchor Link

journalctl -u nginx -n 100
journalctl -u app -n 100
pm2 logs app-prod --lines 200
docker compose logs --tail=200 app
tail -f /var/log/nginx/error.log

Cari error pertama, bukan hanya error terakhir. Perhatikan timestamp dan korelasi dengan deploy.

3. ResourceCopy Anchor Link

uptime
free -h
df -h
top -o %CPU
iostat -xz 1
ss -s

4. DatabaseCopy Anchor Link

psql -h 10.10.10.20 -U app -d app -c "select pid, state, query_start, query from pg_stat_activity;"

Cek:

• Koneksi aktif vs batas pool.
• Query lambat.
• Lock.
• Replikasi tertinggal.
• Disk database.

SELECT pid, now() - query_start AS durasi, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY durasi DESC
LIMIT 10;

5. JaringanCopy Anchor Link

ss -tulpn
nc -zv 10.10.10.20 5432
dig +short app.example.com
curl -v https://app.example.com
tcpdump -i any -n port 5432

6. DeploymentCopy Anchor Link

git log --oneline -5
pm2 describe app-prod
docker inspect <container> | grep -i image

Pertanyaan penting:

• Apa yang berubah sebelum insiden?
• Apakah deploy berhasil health check?
• Apakah migrasi berjalan?
• Apakah konfigurasi berubah?

Mitigasi cepatCopy Anchor Link

RollbackCopy Anchor Link

export IMAGE_TAG=git-<sha-stabil>
docker compose pull
docker compose up -d
curl -f https://app.example.com/health

Untuk Nginx blue-green, arahkan upstream ke versi lama lalu reload.

Runbook insidenCopy Anchor Link

Simpan runbook yang berisi:

• Kontak on-call.
• URL dashboard dan log.
• Perintah cek status.
• Prosedur rollback.
• Prosedur failover database.
• Lokasi backup.
• Batas waktu eskalasi.

Runbook harus diuji, bukan hanya disimpan.

Postmortem blamelessCopy Anchor Link

Struktur:

1. Ringkasan insiden.
2. Dampak dan durasi.
3. Timeline.
4. Akar masalah.
5. Tindakan mitigasi.
6. Tindakan pencegahan dengan owner dan tenggat.

Fokus pada sistem, bukan menyalahkan individu.

Checklist troubleshootingCopy Anchor Link

• Konfirmasi dampak dan mulai timeline.
• Cek status service dan health endpoint.
• Ambil log sebelum restart.
• Cek CPU, RAM, disk, dan jaringan.
• Cek database dan koneksi.
• Korelasikan dengan deploy/perubahan.
• Mitigasi dan verifikasi pemulihan.
• Tulis postmortem.

RingkasanCopy Anchor Link

• Pulihkan dulu, diagnosa kemudian.
• Gunakan urutan: status, log, resource, database, jaringan, perubahan.
• Rollback adalah mitigasi utama untuk error pasca-deploy.
• Postmortem blameless mencegah insiden berulang.