Pendahuluan

Artikel ini menjelaskan langsung bagaimana tim Go Fiber dapat memasang deployment canary yang teramati dengan baik dan siap rollback cepat. Kita membahas pipeline CI/CD, pengukuran latency/error/saturation, alert otomatis, checklist rollback, langkah verifikasi pasca-rollback, serta rangkuman postmortem ringan.

Pipeline CI/CD dan Deployment Canary

Flow yang paling praktis dimulai dari pipeline CI/CD yang menghasilkan artefak Go Fiber (binary atau container image). Setelah artefak teruji, stage deploy membedakan antara primary dan canary dengan pembagian trafik 5-10% ke pod/instance baru.

Contoh potongan stage di GitLab CI/CD:

deploy_canary:
  stage: deploy
  script:
    - gcloud run services update --image gcr.io/myproj/go-fiber:$CI_COMMIT_SHA --platform managed --allow-unauthenticated --region us-central1 --traffic 90=stable,10=canary
  when: manual

Atau jika menggunakan VM/kubernetes, gunakan terraform/helm yang mengupdate label target subset canary dan adjust infrastruktur service mesh (misalnya Istio) untuk routing persentase trafik.

Pipeline harus menyisipkan fase observabilitas sebelum mengalihkan semua trafik: cek readiness, jalankan smoke test yang mengukur latency/response, dan pastikan monitoring agent (Prometheus exporter atau OpenTelemetry collector) sudah mengirim metrik.

Strategi Observabilitas Health

Metrik Latency, Error, dan Saturation

Tiga dimensi utama yang perlu dipantau selama canary:

  • Latency: gunakan histogram untuk p95/p99 endpoint utama. Perubahan rata-rata saja tidak cukup.
  • Error: threshold error rate (contoh >2% selama 5 menit) menandakan regresi.
  • Saturation: lihat queue length, CPU utilization, dan backpressure pada connection pool sehingga canary tidak membebani resource.

Gunakan alert rule berikut dalam monitoring (contoh Prometheus):

alert: CanaryErrorSpike
expr: sum(rate(http_requests_total{job="go-fiber",status=~"5.."}[5m]))
  / sum(rate(http_requests_total{job="go-fiber"}[5m])) > 0.02
for: 3m

Rule tambahan untuk latency: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 500. Saturation alert bisa menggunakan tingkat CPU per pod atau queue backlog.

Alerting dan Trigger Rollback

Alert dapat memicu rollback otomatis (misalnya dengan webhook ke pipeline) jika kondisi terpenuhi. Alternatif lebih aman adalah alert dengan mode manual namun diberi instruksi rollback melalui runbook.

Contoh logika sederhana pada orchestration tool:

  • Cek alert latency/error/saturation dari Prometheus Alertmanager.
  • Jika trigger hits > 3 menit, jalankan job rollback yang menurunkan versi stable.
  • Jika rollback otomatis tidak tersedia, kirim notifikasi ke on-call dengan link runbook.

Checklist Rollback dan Verifikasi

Checklist rollback wajib dibuat.

  1. Identifikasi versi sebelumnya (tag atau image digest).
  2. Jalankan pipeline rollback: update service mesh routing atau deployment spec ke versi stable.
  3. Verifikasi manual bahwa canary traffic kembali 0%.
  4. Pastikan endpoint readiness sudah hijau dan deployment status stabil.
  5. Catat log terkait kesalahan canary.

Setelah rollback, lakukan verifikasi:

  • Gunakan kubectl rollout status atau pemeriksaan health agent.
  • Periksa metrik latency/error untuk versi stable.
  • Pastikan alert yang memicu rollback sudah kembali normal.

Postmortem Ringkas

Proses pasca-rollback harus cepat: buat catatan singkat berisi penyebab, dampak, mitigasi.

  • Penyebab: misalnya perubahan dependency yang menambah latency p99.
  • Dampak: canary error spike menyebabkan alert.
  • Mitigasi: revert config, update benchmark, tambah tes integrasi yang relevan.

Format postmortem bisa berupa dokumen satu halaman, lengkap dengan timeline, siapa yang bertanggung jawab, dan langkah pencegahan.

Tindakan Pencegahan Berkelanjutan

Untuk menjaga keandalan, lakukan:

  • Chaos testing: injeksi latency atau error pada canary untuk memvalidasi observability dan rollback.
  • Runbook jelas: sertakan langkah observability, threshold alert, dan prosedur rollback cepat.
  • Dokumentasi insight: rangkum temuan observability ke dashboard atau wiki tim agar analisis masa depan lebih cepat.

Gabungkan data observability dengan dokumentasi sehingga setiap rollback menghasilkan insight baru yang bisa diuji pada deployment berikutnya.

Dengan pendekatan ini, tim Go Fiber menjaga deployment canary tetap teramati, siap rollback, dan terus belajar melalui postmortem ringan dan praktik pencegahan.