Saat Pipeline Anda yang Memutuskan: Mengotomatiskan Keputusan Progressive Delivery

Bayangkan ini: jam 2 pagi hari Sabtu. Tim Anda baru saja memicu rilis sebelum pulang. Versi baru mulai menerima 5% traffic produksi. Lima menit kemudian, error rate mulai naik. Tidak ada yang melihat dashboard. Saat seseorang mengecek ponsel di pagi hari, pengguna sudah mengalami error selama berjam-jam.

Skenario ini lebih umum dari yang diakui kebanyakan tim. Rilis tidak selalu terjadi selama jam kerja. Tim memiliki kehidupan di luar pekerjaan. Dan menunggu manusia menyadari masalah sebelum mengambil tindakan hanya menciptakan downtime yang tidak perlu.

Solusinya bukan membuat orang selalu siaga. Melainkan memberikan pipeline Anda kemampuan untuk mengambil keputusan sendiri.

Cara Kerja Automated Gating

Ide intinya sederhana. Pipeline progressive delivery memiliki beberapa tahap, masing-masing mengekspos versi baru ke lebih banyak traffic. Di antara setiap tahap terdapat gate. Gate tersebut memeriksa metrik real-time terhadap ambang batas yang telah ditentukan sebelum memutuskan langkah selanjutnya.

Berikut contoh konkretnya. Pipeline Anda mulai dengan mengarahkan 5% traffic ke versi baru. Pipeline menunggu lima menit agar data terkumpul. Kemudian memeriksa tiga hal:

• Apakah error rate untuk versi baru di bawah 0,1%?
• Apakah latency dalam 10% dari baseline versi lama?
• Apakah tidak ada peningkatan signifikan pada respons 5xx?

Jika semua metrik lolos, pipeline melanjutkan ke tahap berikutnya, misalnya memperluas traffic ke 20%. Jika metrik gagal, pipeline perlu memutuskan apa yang harus dilakukan.

Tiga Tindakan yang Mungkin: Continue, Hold, atau Rollback

Begitu metrik melanggar ambang batas, pipeline memiliki tiga opsi.

Continue berarti semuanya terlihat baik. Versi baru pindah ke tier traffic berikutnya. Ini adalah jalur bahagia dan tidak memerlukan intervensi manusia.

Hold berarti pipeline berhenti memprogres rilis, tetapi versi baru tetap berjalan pada persentase traffic saat ini. Tim mendapat notifikasi dan dapat menyelidiki tanpa tekanan. Ini berguna ketika masalah belum kritis. Mungkin error rate naik sedikit tetapi tidak mengkhawatirkan. Tim dapat memeriksa log, melihat trace, dan memutuskan apakah akan melanjutkan atau rollback.

Rollback berarti pipeline segera mengalihkan semua traffic kembali ke versi lama. Ini terjadi ketika metrik menunjukkan masalah serius. Error rate melonjak drastis. Semua permintaan mulai gagal. Latency memburuk melampaui batas yang dapat diterima. Dalam kasus ini, menunggu persetujuan manusia hanya memperburuk keadaan.

Menetapkan Ambang Batas: Warning vs Critical

Keputusan antara hold dan rollback tergantung pada tingkat keparahan. Banyak tim menerapkan dua level ambang batas.

Ambang batas warning memicu hold. Misalnya, jika error rate mencapai 0,5%, pipeline berhenti memprogres dan memberi notifikasi ke tim. Versi baru tetap pada level traffic saat ini sementara seseorang menyelidiki.

Ambang batas critical memicu rollback otomatis. Jika error rate mencapai 2%, pipeline menarik versi baru segera. Tanpa menunggu. Tanpa pertanyaan.

Pendekatan dua tingkat ini memberi tim ruang bernapas untuk masalah kecil sambil melindungi pengguna dari kegagalan besar. Angka pastinya tergantung pada toleransi aplikasi Anda terhadap error. Sistem pembayaran mungkin memiliki ambang batas yang jauh lebih ketat daripada situs konten.

Yang Dibutuhkan Pipeline untuk Mengambil Keputusan

Pengambilan keputusan otomatis membutuhkan tiga hal yang bekerja bersama.

Pertama, sistem observability Anda harus mengekspos metrik secara real-time. Pipeline perlu menanyakan error rate, latency, dan sinyal lainnya segera setelah mengalihkan traffic. Jika monitoring Anda memiliki penundaan lima menit, pipeline tidak dapat membuat keputusan tepat waktu.

Kedua, pipeline perlu membandingkan metrik versi baru dengan baseline versi lama. Ini berarti menyimpan data baseline dari rilis stabil sebelumnya. Perbandingan harus memperhitungkan fluktuasi normal. Peningkatan latency 5% selama jam sibuk mungkin normal, sementara peningkatan yang sama selama traffic rendah bisa mengindikasikan masalah.

Ketiga, Anda memerlukan aturan yang jelas yang dikodekan dalam konfigurasi pipeline. Aturan ini menentukan metrik mana yang akan diperiksa, ambang batas apa yang digunakan, dan tindakan apa yang harus diambil untuk setiap level ambang batas. Jaga aturan ini tetap sederhana dan eksplisit. Logika kompleks dengan banyak kondisi menjadi sulit dipelihara dan di-debug.

Otomatisasi Tidak Menggantikan Manusia

Sangat menggoda untuk berpikir keputusan otomatis berarti Anda dapat mengabaikan rilis sepenuhnya. Itu tidak benar. Otomatisasi menangani skenario yang dapat diprediksi. Manusia masih perlu:

• Menentukan ambang batas yang sesuai untuk setiap metrik
• Meninjau apakah ambang batas masih relevan seiring evolusi aplikasi
• Menangani kasus tepi yang tidak dicakup oleh otomatisasi
• Menyelidiki hold dan memutuskan apakah akan melanjutkan atau rollback
• Memperbarui aturan ketika pola kegagalan baru muncul

Anggap otomatisasi sebagai jaring pengaman untuk kasus umum. Otomatisasi menangkap masalah yang jelas dengan cepat, memberi manusia lebih banyak waktu untuk fokus pada situasi kompleks yang membutuhkan konteks dan penilaian.

Daftar Periksa Praktis Singkat

Sebelum menerapkan gate keputusan otomatis, verifikasi dasar-dasar ini:

• Dapatkah pipeline Anda menanyakan metrik dari sistem monitoring secara real-time?
• Apakah Anda memiliki metrik baseline dari versi stabil saat ini?
• Apakah Anda telah menentukan ambang batas warning dan critical untuk error rate, latency, dan respons 5xx?
• Apakah pipeline Anda memiliki mekanisme untuk menahan progres tanpa rollback?
• Apakah notifikasi dikonfigurasi untuk menjangkau orang yang tepat ketika hold atau rollback terjadi?
• Sudahkah Anda menguji rollback otomatis di lingkungan staging?

Apa Selanjutnya

Setelah pipeline Anda dapat memutuskan kapan harus continue, hold, atau rollback, langkah selanjutnya adalah memilih cara mendistribusikan traffic. Dua pendekatan umum adalah canary release dan staged rollout. Masing-masing memiliki karakteristik berbeda untuk memperluas jangkauan versi baru. Pilihan yang tepat tergantung pada arsitektur aplikasi Anda dan bagaimana infrastruktur Anda menangani routing traffic.

Tapi itu topik untuk lain waktu. Untuk saat ini, fokuslah memberikan pipeline Anda kemampuan untuk mengambil keputusan ketika tidak ada yang melihat. Pengguna Anda akan berterima kasih, dan tim Anda akan tidur lebih nyenyak.