Anatomi Deployment Berisiko Akibat Tekanan Rilis

Tekanan bisnis sering mengubah estimasi kasar menjadi tanggal rilis absolut. Saat rilis dipaksakan tanpa cakupan tes yang memadai, strategi mitigasi harus bergeser dari pencegahan kegagalan (failure prevention) ke pembatasan dampak kegagalan (blast radius reduction). Pola paling efektif adalah menggabungkan deployment canary otomatis dengan mekanisme rollback berbasis Service Level Indicator (SLI).

Metrik SLI/SLO Krusial untuk Deteksi Instan

Mendeteksi regresi dalam hitungan detik membutuhkan SLI yang sensitif terhadap kegagalan runtime. Jangan mengandalkan metrik sistem generik seperti utilisasi CPU atau memori untuk memicu rollback darurat.

  • Availability SLI (HTTP 5xx Rate): Persentase request HTTP yang mengembalikan status code 5xx di luar traffic client (4xx). SLO toleransi canary umumnya < 0.5% error rate tambahan.
  • Latency SLI (p95/p99 Latency): Keterlambatan respons sering menandakan query database tanpa index atau deadlock koneksi pool. Pemicu rollback harus aktif jika p99 meningkat lebih dari 20% dibanding baseline stabil.

Query Prometheus untuk Evaluasi Canary

Berikut adalah contoh query Prometheus (PromQL) untuk menghitung error rate pada pod canary dibandingkan dengan pod stable:

# Error rate pada pod versi canary selama interval 2 menit
sum(rate(http_requests_total{status=~"5..", version="canary"}[2m]))
/
sum(rate(http_requests_total{version="canary"}[2m])) * 100

Implementasi Auto-Rollback dengan Kubernetes & Flagger

Argo Rollouts atau Flagger memungkinkan eksekusi routing traffic progresif menggunakan service mesh (Istio, Linkerd) atau Ingress Controller. Jika metrik metrik SLI melampaui batas ambang batas (threshold), traffic langsung dikembalikan ke versi stabil.

Konfigurasi Canary Resource

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: payment-service
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-service
  service:
    port: 8080
    targetPort: 8080
  analysis:
    interval: 1m
    threshold: 3
    maxWeight: 30
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m
    alerts:
      - name: slack-alert
        severity: error
        providerRef:
          name: ops-slack

Konfigurasi di atas membatasi paparan traffic maksimal sebesar 30% dengan kenaikan bertahap 10% setiap menit. Jika request-success-rate berada di bawah 99% atau durasi request melebihi 500ms selama 3 interval berturut-turut (threshold: 3), Flagger langsung membatalkan deployment dan mengarahkan seluruh traffic kembali ke versi sebelumnya.

Siklus Database Saat Terjadi Rollback

Rollback aplikasi menjadi berbahaya jika skema basis data tidak kompatibel mundur (backward-compatible). Aturan utama untuk rilis berisiko tinggi adalah memisahkan siklus migrasi database dari siklus rilis kode:

  1. Expand: Tambahkan kolom atau tabel baru tanpa menghapus skema lama. Buat kolom nullable atau sediakan default value.
  2. Write to Both: Aplikasi baru menulis ke skema lama dan baru.
  3. Deploy Application: Lakukan canary deploy kode aplikasi. Jika canary rollback terpicu, versi lama tetap berjalan normal karena skema lama tidak diubah secara destruktif.
  4. Contract: Hapus kolom atau tabel usang pada rilis terpisah setelah versi baru 100% stabil di production.

Checklist Blameless Postmortem

Jika insiden terjadi akibat rilis yang terburu-buru, analisis pasca-insiden harus menargetkan kelemahan sistemis, bukan mencari individu yang menyetujui rilis.

  • Timeline Rekonstruksi: Catat waktu tepat saat commit dibuat, canary dimulai, metrik SLI anjlok, dan rollback otomatis dieksekusi.
  • Evaluasi Blind Spot: Identifikasi alasan pengujian pra-rilis gagal mendeteksi bug (misalnya ketiadaan data riil di staging atau race condition).
  • Audit Estimasi: Jelaskan secara faktual bagaimana estimasi awal berubah menjadi tenggat waktu tanpa negosiasi ulang cakupan fitur.
  • Tindakan Korektif (Action Items): Buat automated gate baru pada CI/CD pipeline, sesuaikan ambang batas alert, atau buat feature flag baru untuk komponen bermasalah.