Checklist Deploy Aman menjawab kebutuhan tim DevOps agar setiap rilis bisa kembali ke kondisi stabil, diamati secara efektif, dan ditutup dengan pembelajaran singkat. Lengkapi proses CI/CD dengan langkah-langkah konkret untuk rollback otomatis, metrik kritikal, dan postmortem ringan agar deployment modern tetap terkendali.

Artikel ini menguraikan rangkaian checklist sebelum, selama, dan setelah go-live: apa yang harus dicek pada rollback, observability yang perlu dipantau, serta bagaimana mendokumentasikan root cause tanpa memperberat proses. Fokusnya adalah pada implementasi praktis menggunakan coding, automation, dan monitoring yang biasa ditemui di lingkungan infra-as-code.

Kesiapan Rollback Otomatis

Tidak cukup hanya punya dokumentasi rollback manual; tim harus membuktikan setiap deployment bisa dibatalkan dengan serangkaian aksi yang terekam dalam pipeline. Mulai dari validasi artefak hingga pengujian rollback di staging, checklist minimal mencakup:

  • Validasi artefak: pastikan tag atau image yang dipakai masih tersedia dan sudah ditandai sebagai "rollback candidate".
  • Penyiapan pipeline rollback: tahap terpisah yang bisa dipicu tanpa merilis ulang fitur.
  • Verifikasi dependensi: konfigurasi database, secret, dan versi service yang terlibat sesuai dengan versi rollback.

Contoh potongan pipeline untuk rollback berbasis GitLab CI/CD:

rollback_to_previous_version:
  stage: rollback
deploy_job:
  script:
    - kubectl rollout undo deployment/api --to-revision=2
    - kubectl rollout status deployment/api
  when: manual
  allow_failure: false

Jika menggunakan Helm, tambahkan flag --history-max agar versi sebelumnya terjaga. Kunci dari pendekatan ini adalah tes manual minimal: jalankan perintah rollback di staging setiap kali ada versi baru agar tim terbiasa dan pipeline dapat diverifikasi.

Perhatikan keterbatasan otomatisasi: rollback database tidak selalu bisa otomatis, jadi sertakan database snapshot atau feature flag untuk mematikan fitur baru tanpa migrasi balik. Jangan lupa menambahkan langkah verifikasi setelah rollback (smoke test) untuk memastikan sistem kembali bekerja.

Observability Relevan Setelah Go-live

Observability bukan sekadar menghidupkan dashboard; harus ada metrik dan alert yang langsung menunjukkan apakah deployment mengalami regresi. Berikut daftar utama yang perlu ada di checklist deploy aman:

  • Error rate global dan per-endpoint, dengan baseline diambil dari periode sebelumnya.
  • Latency 95/99 persentil untuk API utama.
  • Traffic dan success rate database atau message queue jika perubahan menyentuh data layer.
  • Resource CPU/memory pod terutama jika deployment menambah load.

Alert contoh (opsional, tergantung alat):

- alert: High5xxRate
  expr: increase(http_requests_total{status=~"5.."}[5m]) / increase(http_requests_total[5m]) > 0.02
  for: 3m
  labels:
    severity: critical
  annotations:
    summary: "5xx rate naik drastis setelah deploy"

Setiap alert harus terhubung ke runbook singkat yang menjelaskan langkah mitigasi, seperti rollback instant atau menurunkan traffic dengan feature flag. Gunakan observability yang sudah dipasang (Prometheus, OpenTelemetry, log centralization) dan tambah metrik custom jika deployment menyentuh komponen baru.

Jangan lupa menambahkan heartbeat atau health check synthetic untuk memantau user journey esensial. Observability yang tepat memberi tim sinyal dini, mengurangi kebutuhan rollback buru-buru.

Postmortem Ringan: Dokumentasi dan Tindakan Lanjutan

Jika deployment men-trigger incident, postmortem ringan harus dibuat segera dan fokus pada fakta tanpa menyalahkan. Checklist postmortem harus mencakup:

  • Timeline singkat kejadian: kapan deploy selesai, issue mulai muncul, respon awal.
  • Root cause hypothesis dan bukti pendukung (logs, metrics, tracing).
  • Impact yang dirasakan pengguna atau sistem internal (jumlah error, latency berlebih).
  • Tindakan mitigasi yang dilakukan dan statusnya (rollback, config fix, patch).
  • Tindakan preventif untuk checklist berikutnya (menambah test, mematikan auto-scaling, revisi runbook).

Contoh struktur dokumentasi postmortem ringkas:

## Incident: Timeout API Endpoint
- Timeline:
  - 10:15 deploy feature X
  - 10:18 spike latency
  - 10:22 rollback
- Root Cause: resource limit tidak cukup untuk worker baru
- Mitigasi: rollback + increase pod limit
- Pencegahan: tambahkan load test simulating 2x traffic + review quota baru

Gunakan template sederhana di wiki atau tool ticketing agar dokumentasi konsisten. Pastikan setiap postmortem memberi referensi ke checklist deploy untuk mencegah ulang dan dijadikan bahan evaluasi release readiness.

Tindakan Pencegahan Sebelum dan Sesudah Go-live

Checklist deploy aman tidak berhenti saat deployment sukses. Berikut tindakan yang perlu ditandai sebelum dan sesudah go-live:

Sebelum Go-live

  • Pastikan pull request sudah melewati auto-test dan manual review, lalu artifact sudah di-tag dengan versi.
  • Konfirmasi rollback path: branch rollback, config, dan secrets sudah siap.
  • Update monitoring config jika ada feature baru, termasuk alert threshold sementara.
  • Siapkan kanban board atau chat ops dengan langkah validasi post-deploy.

Sesudah Go-live

  • Jalankan smoke test otomatis untuk endpoint kritikal, catat hasilnya.
  • Monitor observability selama 15-30 menit awal, verifikasi tidak ada anomaly.
  • Jika deploy besar, lakukan pengawasan langsung (war-room) dan update status ke stakeholders.
  • Sertakan catatan ringkas hasil deploy dan kesiapan rollback di log deployment.

Penambahan catatan ke monitoring dan dokumentasi membantu tim tracking dan memberikan konteks untuk postmortem.

Penutup Checklist Deploy Aman

Menggabungkan rollback terautomasi, observability yang fokus pada metrik kritis, dan postmortem ringan membuat deployment lebih dapat diprediksi. Checklist ini membantu tim DevOps meminimalkan dampak issue, belajar dari kejadian, dan memastikan setiap go-live mengikuti standar keamanan operasional yang jelas.