Mitigasi Bad Release: Deteksi Observability, Rollback, dan Postmortem

Bad release terjadi ketika deployment memperkenalkan bug kritis, degradasi performa, atau kegagalan infrastruktur ke lingkungan produksi. Kecepatan mitigasi ditentukan oleh tiga kapabilitas utama: deteksi regresi secara otomatis, keputusan rollback yang deterministik, dan perbaikan struktural melalui blameless postmortem.

1. Deteksi Regresi Menggunakan 4 Golden Signals

Observabilitas pasca-deploy harus difokuskan pada deviasi metrik sistem sesaat setelah traffic dialihkan ke versi baru. Pendekatan berbasis 4 Golden Signals menyederhanakan identifikasi regresi tanpa perlu memeriksa application log secara manual pada tahap awal.

• Latency: Ukur durasi eksekusi request. Pantau persentil P95 dan P99, bukan rata-rata (mean), karena spike pada sebagian kecil user sering tertutupi oleh nilai agregat rata-rata.
• Traffic: Ukur beban permintaan sistem (request per second). Penurunan traffic drastis pasca-deploy menandakan kegagalan routing, DNS, atau crash pada ingress/API gateway.
• Errors: Ukur rasio request yang gagal terhadap total request, baik eksplisit (HTTP 5xx) maupun implisit (HTTP 200 dengan payload error atau timeout).
• Saturation: Ukur utilisasi kapasitas sistem, seperti thread pool exhaust, CPU throttling, memory consumption, dan ketersediaan koneksi database.

Gunakan kueri Prometheus (PromQL) berikut untuk mendeteksi lonjakan error rate dan degradasi latensi P95 secara langsung:

# Error rate melebihi 1% dalam jendela 2 menit terakhir
sum(rate(http_requests_total{status=~"5.."}[2m]))
/
sum(rate(http_requests_total[2m])) * 100 > 1

# Latensi P95 melebihi batas toleransi SLA (misal: 500ms)
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[2m])) by (le)) > 0.5

2. Matriks Keputusan: Rollback Instan vs Forward-Fix

Saat insiden terjadi di produksi, keputusan teknis harus objektif. Mengembangkan perbaikan langsung di produksi (forward-fix) saat sistem berada dalam status tidak stabil membawa risiko compounding failure.

Gunakan parameter berikut untuk menentukan aksi penanganan:

Prinsip Kritis: Jika waktu pemulihan forward-fix tidak dapat diprediksi secara pasti dalam 5 menit pertama investigasi, jalankan prosedur rollback segera.

3. Runbook Eksekusi Rollback

Rollback harus bersifat deterministik dan dapat dieksekusi tanpa ketergantungan pada proses build ulang kode dari source repository. Simpan immutable artifact (container image) dari rilis stabil sebelumnya.

Langkah 1: Rollback Workload Aplikasi

Pada Kubernetes, kembalikan deployment ke revision stabil sebelumnya tanpa menunggu build container baru:

# Verifikasi riwayat revision
kubectl rollout history deployment/order-service -n production

# Kembalikan ke revision sebelum deploy
kubectl rollout undo deployment/order-service -n production

# Pantau status penggantian Pod hingga selesai
kubectl rollout status deployment/order-service -n production --timeout=120s

Langkah 2: Penanganan State Database

Jika rilis melibatkan database migration, pastikan skema mematuhi prinsip Expand and Contract (Parallel Changes). Jangan pernah menghapus kolom lama pada deployment yang sama dengan introduksi kolom baru. Dengan cara ini, rollback aplikasi versi N ke N-1 tidak akan merusak koneksi database.

Langkah 3: Purge / Revalidate Cache Layer

Bad release sering kali mengotori cache layer (Redis, Memcached, atau Edge CDN) dengan data korup atau schema serialization yang usang. Eksekusi invalidasi cache berdasarkan namespace versi rilis:

# Contoh eksekusi invalidasi cache via CLI internal
redis-cli -h cache-prod.internal --scan --pattern 'v2.4.0:*' | xargs redis-cli -h cache-prod.internal del

4. Template Blameless Postmortem

Postmortem bertujuan untuk memperbaiki kelemahan sistem dan proses, bukan menghukum individu. Fokus pada konteks: mengapa keputusan tersebut masuk akal saat diambil dan mengapa sistem mengizinkan kegagalan tersebut terjadi.

# Postmortem: [INC-2024-03] High Error Rate on Checkout Service

## 1. Metadata
- Tanggal: YYYY-MM-DD
- Durasi Insiden: 14 menit (10:12 WIB - 10:26 WIB)
- Incident Commander: @engineer-oncall
- Dampak: 1.420 transaksi checkout gagal (HTTP 500), estimasi kerugian Rp XX.XXX.XXX

## 2. Timeline (WIB)
- 10:10 - Deploy commit a1b2c3d ke production via pipeline CI/CD.
- 10:12 - Prometheus alert memicu notifikasi Slack: error rate checkout > 5%.
- 10:15 - On-call engineer melakukan triage; menemukan connection pool database jenuh.
- 10:17 - Keputusan rollback diambil (root cause belum teridentifikasi pasti).
- 10:19 - Eksekusi `kubectl rollout undo` dijalankan.
- 10:22 - Workload stabil di revision sebelumnya; error rate turun ke < 0.01%.
- 10:26 - Insiden dinyatakan resolved.

## 3. Root Cause
Koneksi database pool default pada service baru dikurangi secara tidak sengaja
dari 50 ke 5 akibat kesalahan overriding nilai environment variable di ConfigMap Helm.
Hal ini menyebabkan starvation koneksi saat menerima beban normal produksi.

## 4. Trigger vs Root Cause
- Trigger: Deployment versi v2.4.1.
- Root Cause: Tidak adanya validasi/linter terhadap konfigurasi resource pool di pipeline CI.

## 5. Action Items
| Aksi Pencegahan | Tipe | Pemilik | Deadline | Ticket |
|------------------|------|---------|----------|--------|
| Tambahkan automated smoke test untuk load connection pool | Prevent | @platform | YYYY-MM-DD | PLAT-102 |
| Buat OPA/Conftest rule untuk validasi ConfigMap minimum pool | Prevent | @devops | YYYY-MM-DD | SEC-405 |
| Tambahkan dashboard saturasipool ke rilis checklist | Detect | @sre | YYYY-MM-DD | OBS-210 |

5. Otomasi Pencegahan di Pipeline CI/CD

Mencegah bad release sampai ke seluruh traffic produksi membutuhkan deployment gate otomatis. Pendekatan ini mencakup automated smoke testing dan penerapan deployment threshold pada Canary release.

Automated Smoke Test Post-Deploy

Gunakan script pengujian sintetis sederhana pada stage deployment verifikasi sebelum traffic penuh dibuka:

#!/usr/bin/env bash
set -euo pipefail

ENDPOINT="https://canary.internal.example.com/healthz"
MAX_RETRIES=5
DELAY=3

for i in $(seq 1 $MAX_RETRIES); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$ENDPOINT" || true)
  if [ "$STATUS" -eq 200 ]; then
    echo "[PASS] Smoke test berhasil pada percobaan ke-$i"
    exit 0
  fi
  echo "[WAIT] Endpoint mengembalikan status $STATUS. Retrying in ${DELAY}s..."
  sleep $DELAY
done

echo "[FAIL] Deployment verifikasi gagal setelah $MAX_RETRIES percobaan."
exit 1

Canary Analysis dan Automated Rollback

Implementasikan deployment strategy seperti Canary Deployment (menggunakan Argo Rollouts atau Flagger). Konfigurasikan threshold otomatis yang membatalkan deployment jika Golden Signals terganggu:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-check
spec:
  metrics:
  - name: success-rate
    interval: 30s
    successCondition: result[0] >= 0.99
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{app="order-service",status!~"5.."}[1m]))
          /
          sum(rate(http_requests_total{app="order-service"}[1m]))

Jika metrik berada di bawah 99% sebanyak 2 kali berturut-turut selama masa evaluasi, controller secara otomatis membatalkan canary routing dan mengembalikan seluruh alokasi traffic ke versi stable tanpa intervensi manual manusia.