Runbook Deployment dan Rollback untuk Insiden dengan Observabilitas menjawab pertanyaan: bagaimana tim DevOps bisa menjalankan rilis berisiko dengan pengawasan ketat dan langkah tanggap saat degradasi terjadi. Artikel ini menyiapkan checklist pra-deployment, metrik monitoring yang harus dipantau, prosedur rollback yang bisa dijalankan dalam hitungan menit, serta format postmortem ringan agar pengalaman belajar terdokumentasi.

Checklist Pra-Deployment untuk Runbook Berisiko

Sebelum menekan tombol deploy, jalankan checklist yang memastikan semua pihak siap dan lingkungan dalam kondisi stabil.

1. Validasi lingkungan dan dependensi

  • Verifikasi versi image yang akan dirilis, pastikan tidak ada perubahan konfigurasi yang belum direview.
  • Cek ketersediaan layanan downstream (database, cache, API pihak ketiga) memakai health check terakhir dan threshold latency.
  • Pastikan secret dan configuration injection sudah sesuai dengan environment (misal: kubectl get secret atau tooling lain).

2. Komunikasi dan kanal eskalasi

  • Umumkan jadwal deployment pada status page atau channel tim, sertakan window rollback dan waktu mitigasi maksimum.
  • Siapkan narahubung untuk observabilitas (SRE/pemantau log) dan operator cadangan.
  • Lakukan uji komunikasi (ping kanal) agar saat timeout tidak ada delay koordinasi.

3. Validasi strategi release

Tentukan apakah rilis dilakukan secara blue-green, canary, atau big-bang, lalu pastikan tooling sekolah untuk memantau perbandingan traffic dengan versi lama.

DeploymentChecklist:
  - versi_image: app:v2.4.1
  - dependensi: db-readiness=green, cache-hits>95%
  - monitoring: dashboards siap, alerts diterapkan
  - rollback-plan: revert-annotation=git-sha, alternate-route=blue

Checklist seperti di atas bisa dibuat dalam format YAML/JSON dan dieksekusi oleh pipeline untuk menghindari kebocoran manual.

Metrik Observabilitas Saat Rilis

Observabilitas menjadi tulang punggung runbook. Fokuskan pada metrik yang langsung mengindikasikan regresi atau degradasi.

1. Metrik Kinerja Aplikasi

  • Latency P95/P99 di endpoint kritis, bukan hanya rata-rata. Lonjakan di kuantil atas sering kali awal degradasi.
  • Throughput dibandingkan baseline; penurunan bisa menunjukkan bottleneck baru atau throttling di service.

2. Metrik Kesehatan Sistem

  • Error rate per endpoint atau service. Gunakan alerting pada error > 0.5% selama 5 menit window.
  • Resource usage (CPU/Memory) pada pod utama: lonjakan mendadak bisa menandakan memory leak akibat kode baru.

3. Observabilitas Infrastruktur dan Log

Gabungkan log terstruktur, tracing, dan metrics. Saat observability tools (Grafana, Prometheus, OpenTelemetry) menunjukkan anomali, jalankan cross-correlation untuk menemukan titik sumber.

  • Gunakan query log untuk melihat error yang bersamaan dengan spike latensi.
  • Trace distribusi saat ada request timeout untuk menemukan layanan yang menolak transaksi.

4. Tip Debugging

Jika alert menyebutkan error 503 setelah deploy, jangan langsung rollback: periksa dahulu apakah error terjadi pada subset traffic (canary). Bila true, isolate deployment dan pertimbangkan mematikan feature flag. Ini menghindarkan rollback walau error sebenarnya hanya berlaku di segmen terbatas.

Langkah Rollback Cepat Saat Degradasi

Rollback harus bisa dijalankan dalam hitungan menit, dengan langkah yang jelas agar tidak memperburuk insiden.

1. Kriteria pemicunya

  • Pemicu pertama bisa berupa alert di observabilitas (error rate > threshold, latency P99 naik signifikan).
  • Sertakan konfirmasi manual atau otomatis, seperti dua orang tanda tangan dan review log terakhir sebelum rollback.

2. Eksekusi rollback

Bergantung platform, rollback dapat berupa mengembalikan deployment revision terakhir yang stabil. Pastikan runbook menyertakan perintah spesifik.

# Contoh rollback Kubernetes
kubectl rollout undo deployment/my-app --to-revision=5
kubectl rollout status deployment/my-app --watch

Perintah di atas berlaku umum, namun runbook harus menyebutkan versi revision yang sebelumnya stabil dan penyesuaian label routing jika menggunakan service mesh.

3. Verifikasi pasca-rollback

  • Cek metrik latency/error untuk memastikan return to baseline.
  • Pastikan traffic kembali ke versi lama melalui debugging observabilitas (trace ID ulang).
  • Dokumentasikan waktu rollback, alasan, dan siapa mengeksekusi untuk postmortem.

4. Trade-off

Rollback cepat menjaga kestabilan, namun mungkin membuat Anda kehilangan kesempatan menyelidiki kode baru lebih dalam. Solusi alternatif: feature flag rollback (menonaktifkan fitur tertentu) bila memungkinkan, agar debug bisa dilanjutkan tanpa mengganggu versi utama.

Postmortem Ringan dan Tindakan Pencegahan

Setelah insiden ditutup, runbook harus meneruskan informasi ke seluruh tim sehingga kegagalan tidak terulang.

Format Postmortem Ringan

Gunakan template singkat agar tim benar-benar mengisi dokumen tersebut.

  • Judul: Nama deployment + tanggal.
  • Timeline: bullet point dari rilis hingga rollback.
  • Penyebab utama: detail metrik/kode yang menyebabkan degradasi.
  • Actions: langkah konkret (bug fix, alert tuning, automation rollout).

Contoh singkat:

Title: Deploy api-gateway v1.9.2 (15 Apr 2024)
Timeline:
  - 10:00 deploy canary
  - 10:05 latency P99 naik 2x dan error 502
  - 10:07 rollback ke v1.9.1
Cause: perubahan retry policy memicu surge downstream
Actions:
  - revert retry config dan tambah guardrail simulasi load
  - update alert thresholds untuk response code baru

Tindakan Pencegahan

  • Tambahkan chained observability: log correlated IDs, traces, dan metrics untuk fast post-incident analysis.
  • Pelajari apakah deployment perlu lebih banyak canary atau feature flag rollout.
  • Update runbook dengan pelajaran baru: misalnya threshold alert harus sesuai data P95 historis.

Latihan dan Review

Jadwalkan tabletop exercise untuk menjalankan runbook secara berkala. Catat waktu eksekusi dan kendala, lalu tambahkan ke dokumentasi agar runbook tidak ketinggalan perubahan arsitektur.

Dengan struktur ini, tim DevOps memiliki panduan langsung untuk menghadapi insiden pada deployment berisiko, lengkap dengan metrik observabilitas, langkah rollback, dan sesi belajar untuk meningkatkan resiliency.