Saat Deployment Anda Memutuskan Sendiri: Mengotomatiskan Keputusan Rollback dan Promosi

Anda baru saja mendeploy versi baru API Anda. Lima menit kemudian, error rate melonjak dari 0,1% menjadi 4%. Anda sedang dalam rapat. Saat Anda mengecek dashboard, lima belas menit telah berlalu. Pengguna sudah mulai mengeluh.

Sekarang bayangkan ini terjadi tiga kali seminggu. Setiap kali, seseorang harus melihat lonjakan, membuka alat monitoring, menginterpretasi angka, memutuskan apa yang harus dilakukan, lalu memicu rollback atau hold secara manual. Bagi tim yang melakukan beberapa deployment per hari, putaran keputusan manual ini sangat melelahkan. Lebih buruk lagi, hasilnya tidak konsisten. Satu engineer mungkin rollback di error rate 2%. Engineer lain mungkin menunggu hingga 5%. Engineer ketiga mungkin tidak menyadari sama sekali sampai ada yang mention mereka di chat.

Inilah masalah yang dipecahkan oleh deployment gating. Deployment gate adalah checkpoint otomatis yang memutuskan apakah versi baru dapat melanjutkan ke tahap berikutnya atau harus dihentikan. Gate tidak menebak-nebak. Gate mengikuti policy: sekumpulan aturan yang mengatakan, "Jika sinyal ini melewati ambang batas itu, lakukan tindakan ini."

Cara Kerja Deployment Gate

Anggap gate sebagai bouncer di pintu masuk klub. Bouncer tidak tahu siapa Anda. Mereka hanya memeriksa: apakah nama Anda ada di daftar? Apakah ID Anda valid? Jika ya, Anda masuk. Jika tidak, Anda menunggu atau pergi.

Deployment gate bekerja dengan cara yang sama. Setelah versi baru dideploy ke subset pengguna atau lingkungan staging, gate memeriksa sinyal observability. Jika sinyal sehat, gate mempromosikan versi tersebut ke lebih banyak pengguna. Jika sinyal buruk, gate memicu rollback, hold, atau pause.

Diagram di bawah menunjukkan tiga kemungkinan hasil setelah gate memeriksa sinyal observability.

Kuncinya adalah keputusan dibuat secara otomatis, berdasarkan aturan yang telah disepakati tim sebelumnya. Tidak ada yang perlu mengawasi dashboard jam 2 pagi. Tidak ada yang perlu membuat keputusan di bawah tekanan. Sistem mengikuti policy.

Apa Saja yang Masuk ke Dalam Policy

Policy bukanlah aturan tunggal. Policy adalah sekumpulan kondisi yang terkait dengan jenis objek yang Anda deploy. Objek deployment yang berbeda memiliki pola kegagalan yang berbeda, sehingga mereka membutuhkan policy yang berbeda.

Untuk aplikasi, policy mungkin memeriksa:

• Error rate dibandingkan dengan baseline SLO
• Latensi di persentil p95 atau p99
• Penurunan throughput yang mengindikasikan service menolak request

Untuk migrasi database, policy mungkin memeriksa:

• Replication lag antara primary dan replica
• Jumlah slow query setelah migrasi
• Kehabisan koneksi pool

Untuk perubahan infrastruktur, policy mungkin memeriksa:

• Kesehatan node di cluster
• Pola penggunaan CPU dan memori
• Jumlah restart Pod

Setiap objek mendapatkan policy-nya sendiri karena masing-masing rusak dengan cara yang berbeda. Lonjakan latensi di API tidak sama dengan replication lag di database. Policy harus sesuai dengan mode kegagalan.

Berikut adalah contoh minimal policy-as-code yang mengimplementasikan logika yang dijelaskan di atas:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: api-deployment
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: error-rate
      thresholdRange:
        max: 0.05
      interval: 2m
    - name: request-duration
      thresholdRange:
        max: 0.5
      interval: 2m
    webhooks:
    - name: rollback-on-failure
      timeout: 30s
      metadata:
        action: rollback

Policy ini memeriksa error rate dan latensi setiap dua menit. Jika salah satu melebihi ambang batas, deployment secara otomatis di-rollback. Jika semua pemeriksaan lulus selama lima menit, versi baru dipromosikan ke step weight berikutnya.

Menggunakan Error Budget sebagai Jangkar Policy

Error budget memberi Anda angka praktis untuk dimasukkan ke dalam policy. Jika tim Anda menetapkan SLO ketersediaan 99,9%, Anda memiliki sekitar 43 menit downtime yang diizinkan per bulan. Itulah error budget Anda.

Sekarang bayangkan deployment baru menghabiskan 10 menit dari budget tersebut dalam satu jam pertama. Itu adalah sinyal kuat bahwa ada yang salah. Policy dapat mengatakan: "Jika versi baru mengonsumsi lebih dari 5% error budget bulanan dalam 30 menit pertama, rollback secara otomatis."

Pendekatan ini menghilangkan tebak-tebakan. Tim telah menyetujui SLO. Policy menegakkannya. Tidak ada yang perlu berdebat apakah 10 menit terlalu banyak. Angkanya sudah ditetapkan.

Tidak Semua Keputusan Harus Rollback

Kesalahan umum adalah membuat setiap policy berakhir dengan rollback. Itu terlalu agresif untuk banyak situasi. Pendekatan yang lebih baik adalah policy berlapis.

Contoh:

• Jika error rate naik 0,5% tetapi masih di bawah ambang batas SLO, picu hold. Versi baru tetap hidup tetapi tidak dipromosikan ke lebih banyak pengguna. Tim menyelidiki tanpa tekanan.
• Jika error rate melewati ambang batas SLO, picu rollback. Sistem segera kembali ke versi sebelumnya.
• Jika latensi meningkat tetapi error rate stabil, picu pause. Tidak ada promosi lebih lanjut, tetapi versi saat ini terus berjalan. Tim memutuskan secara manual apakah akan melanjutkan atau rollback.

Pendekatan berlapis ini memberi tim ruang untuk menangani berbagai tingkat keparahan tanpa bereaksi berlebihan atau kurang bereaksi.

Apa yang Anda Butuhkan untuk Membuat Ini Berhasil

Deployment gating membutuhkan integrasi antara sistem observability dan platform deployment Anda. Sinyal dari monitoring harus dapat dibaca oleh pipeline atau platform yang mengelola deployment.

Alat seperti Argo Rollouts, Flagger, dan Spinnaker sudah mendukung pola ini. Mereka dapat menarik metrik dari Prometheus, Datadog, New Relic, atau sumber metrik lainnya. Anda mengonfigurasi policy, dan alat tersebut mengeksekusi keputusan.

Tetapi alat bukanlah bagian yang sulit. Bagian yang sulit adalah mendefinisikan policy. Anda perlu tahu:

• Sinyal mana yang penting untuk setiap jenis deployment
• Ambang batas apa yang mengindikasikan masalah nyata versus noise
• Seberapa cepat Anda perlu bereaksi untuk berbagai tingkat keparahan kegagalan

Mulailah dengan sederhana. Pilih satu sinyal, satu ambang batas, dan satu tindakan. Jalankan selama seminggu. Lihat berapa banyak false positive yang Anda dapatkan. Sesuaikan. Tambahkan lebih banyak sinyal secara bertahap.

Apakah Aman Membiarkan Sistem Memutuskan?

Pertanyaan ini selalu muncul. Jawabannya: tergantung seberapa baik Anda mendefinisikan policy.

Policy yang baik tidak sepenuhnya menggantikan penilaian manusia. Policy mengambil alih keputusan yang sudah dapat diprediksi. Jika tim tahu bahwa error rate di atas 2% selama lima menit selalu mengarah ke rollback, mengapa menunggu manusia melakukannya? Otomatiskan keputusan itu.

Bagaimana dengan kasus tepi? Tim harus selalu memiliki mekanisme override. Jika policy salah memicu, seseorang harus dapat menghentikan rollback atau mempromosikan secara manual. Otomatisasi menangani kasus rutin. Manusia menangani pengecualian.

Tujuannya bukan untuk menghilangkan manusia dari loop. Tujuannya adalah untuk menghilangkan manusia dari keputusan yang membosankan, berulang, dan dapat diprediksi sehingga mereka dapat fokus pada keputusan yang benar-benar membutuhkan konteks dan penilaian.

Daftar Periksa Singkat untuk Memulai

Sebelum Anda membangun deployment gate pertama, pastikan Anda memiliki hal-hal berikut:

• Satu sinyal observability yang Anda percayai (mulai dengan error rate atau latensi)
• Ambang batas yang jelas berdasarkan SLO atau error budget Anda
• Platform deployment yang mendukung gating (Argo Rollouts, Flagger, Spinnaker, atau sejenisnya)
• Mekanisme override untuk intervensi manual
• Jadwal review untuk memeriksa efektivitas policy setiap dua minggu

Jangan mencoba membangun policy yang sempurna di hari pertama. Mulailah dengan satu gate, satu sinyal, satu tindakan. Belajar dari hasilnya. Kembangkan dari sana.

Nilai Sebenarnya Adalah Konsistensi

Manfaat terbesar dari keputusan deployment otomatis bukanlah kecepatan, meskipun itu membantu. Manfaatnya adalah konsistensi. Setiap deployment melewati gate yang sama, dinilai dengan standar yang sama, dengan logika keputusan yang sama. Tidak ada yang lolos karena mereka berteman dengan engineer yang on-call. Tidak ada yang di-rollback secara tidak adil karena reviewer sedang dalam suasana hati yang buruk.

Ketika keputusan deployment Anda diotomatiskan oleh policy, tim Anda dapat melakukan deploy lebih sering tanpa kelelahan. Sistem menangani keputusan rutin. Tim Anda menangani pengecualian dan perbaikan. Itulah perbedaan antara tim yang sering melakukan deploy dan tim yang melakukan deploy secara berkelanjutan.