Apa Itu Canary Deployment? Panduan Praktis untuk SRE

Apa itu canary deployment? Ini teknik rilis yang mengirim versi baru ke sebagian kecil trafik produksi, membandingkannya dengan versi yang sudah berjalan, dan hanya memperlebar rollout jika angkanya tetap sehat. Dalam praktiknya, ini adalah deploy dengan titik keputusan bawaan: perubahan sampai dulu ke 1 sampai 5 persen pengguna, lalu pemeriksaan metrik memutuskan apakah rilis dilanjutkan atau di-revert.

Sisa panduan ini membahas cara kerjanya, di mana ia gagal, dan apa yang layak diotomatisasi.

Halaman pukul 3 pagi yang bisa diubah canary menjadi pesan Slack

Deploy keluar pukul 16.40 pada hari Kamis. Tingkat error di layanan checkout naik dari 0.2 persen menjadi 4 persen. Tidak ada yang menyadarinya sampai tiket dukungan masuk dua jam kemudian, dan saat itu setiap pengguna sudah menjalankan build baru. Rollback memakan waktu 25 menit karena migrasinya sudah terpasang separuh jalan.

Jalankan perubahan yang sama sebagai canary pada 5 persen trafik, dan kerusakannya terbatas. Kira-kira 1 dari 20 pengguna melihat bug tersebut, perbandingan terhadap kontrol gagal dalam hitungan menit, dan pipeline berhenti. Post-mortem akan menulis apa yang berhasil ditangkap canary, bukan apa yang terlewat.

Namanya berasal dari tambang batu bara, tempat burung kenari berhenti berkicau sebelum udara menjadi mematikan. Kelompok kecil Anda berperan sama. Ia tidak mencegah rilis yang buruk. Ia membatasi siapa yang ikut menghirupnya.

Apa yang sebenarnya dilakukan canary deployment, langkah demi langkah

Google SRE Workbook mendefinisikan canarying sebagai deployment parsial dan berbatas waktu dari sebuah perubahan, ditambah evaluasi yang memutuskan apakah rollout berlanjut. Subset yang menjalankan perubahan disebut canary, dan sisa armada disebut kontrol. Pembingkaian ini penting karena membuat canary menjadi uji A/B atas keandalan Anda sendiri, bukan sekadar deploy yang lambat.

Urutan khasnya seperti ini:

• Deploy versi baru di samping versi stabil, tanpa trafik dulu.

• Arahkan persentase kecil (contoh Workbook memakai 5 persen) ke versi baru.

• Tahan selama jendela tetap (contoh yang sama memakai 30 menit) sambil membandingkan canary dan kontrol.

• Naik ke tahap berikutnya, misalnya 25, 50, lalu 100 persen, atau batalkan dan kembalikan trafik.

Loop-nya sederhana. Bagian yang sulit adalah langkah perbandingan, yang di banyak tim masih berbentuk "seseorang memantau dashboard".

Canary, blue-green, dan rolling: mana yang cocok dengan mode kegagalan Anda

Ketiganya sering tercampur, jadi berikut perbedaan yang penting saat Anda memilih.

• Rolling update: mengganti instance secara bertahap. Murah dan sudah tersedia di setiap orkestrator, tetapi tidak ada perbandingan terhadap kontrol dan tidak ada pemisahan trafik yang bersih. Versi lama dan baru berbagi beban sampai akhir.

• Blue-green: dua lingkungan penuh, seluruh trafik dipindah sekaligus. Rollback instan, tetapi radius dampak saat perpindahan adalah 100 persen pengguna. Anda membayar kapasitas ganda.

• Canary: sebagian terkontrol dari trafik live pada versi baru, dinilai terhadap versi lama. Radius dampak paling kecil, kompleksitas operasional paling tinggi.

Pilih blue-green jika risikonya adalah deploy rusak yang bisa dideteksi dengan smoke test dan di-revert dalam hitungan detik. Pilih canary jika risikonya adalah regresi halus yang hanya terlihat di trafik nyata: kenaikan latensi p99, kebocoran memori yang pelan, atau query plan yang gagal pada bentuk data produksi.

Lewati canary jika layanan Anda punya trafik sangat rendah. Dengan beberapa ratus request per jam, slice 5 persen hanya memberi segelintir sampel dan tidak ada sinyal. Workbook mengatakannya langsung: query yang sangat sedikit tidak memberikan sinyal yang berguna untuk beban kerja yang beragam.

Kenapa canary 1 persen Anda kemungkinan sedang menyesatkan Anda

Ini kegagalan yang menghantam tim pada tiga bulan pertama. Canary mengambil 5 persen trafik dan gagal pada 20 persen request-nya. Tingkat error seluruh layanan bergerak dari 0.2 ke sekitar 1.2 persen. Threshold alert Anda 2 persen. Tidak ada yang menyala.

Monitoring agregat menyembunyikan kegagalan canary. Aritmetika yang sama muncul di SRE Workbook: canary yang gagal pada 20 persen request dengan 5 persen trafik hanya menampilkan tingkat error 1 persen secara keseluruhan. Anda harus memecah metrik per populasi, canary melawan kontrol, atau sinyalnya hilang di penyebut.

Ada tiga jebakan lain yang layak diketahui:

• Perbandingan sebelum dan sesudah. Membandingkan jendela canary dengan satu jam sebelumnya mencampur perubahan dengan waktu. Pola trafik hari kerja versus akhir pekan saja bisa menenggelamkan regresi yang nyata. Bandingkan dengan kontrol yang berjalan bersamaan.

• Dependensi bersama. Jika canary dan kontrol memakai cache atau database yang sama, canary yang buruk bisa menurunkan performa keduanya, dan perbandingannya tidak menunjukkan apa-apa. Periksa domain kegagalan Anda.

• Metrik yang bising. Penggunaan CPU adalah gerbang yang buruk. Kode error dan latensi mengikuti apa yang dirasakan pengguna. Workbook menyarankan untuk meranking kandidat metrik berdasarkan seberapa baik mereka mencerminkan masalah yang terlihat pengguna, lalu hanya menyimpan yang teratas, mungkin sekitar selusin paling banyak.

Tentukan metrik gerbang sebelum merilis, bukan saat insiden

Mulailah dari SLI Anda. Jika Anda sudah punya SLI ketersediaan dan SLI latensi untuk layanan tersebut, keduanya adalah dua gerbang pertama. Kumpulan awal yang masuk akal untuk layanan berbasis request:

• Tingkat error (5xx) pada canary dibanding kontrol, selama jendela tahan

• Latensi p99 pada canary dibanding kontrol

• Sinyal saturasi yang bisa dikaitkan dengan perubahan, misalnya pertumbuhan memori per pod

• Satu metrik yang dekat dengan bisnis, misalnya penyelesaian checkout, jika bisa diisolasi per kohort

Threshold adalah tempat tim sering kehilangan minggu-minggu kerja. Jika terlalu ketat, setiap canary akan dibatalkan karena noise, dan insinyur belajar untuk mengabaikan gerbang. Jika terlalu longgar, build yang buruk lolos begitu saja. Tinjau secara berkala. Gerbang yang belum pernah membatalkan apa pun selama enam bulan itu sempurna atau hanya hiasan, dan Anda perlu tahu yang mana.

Pastikan juga interval agregasi metrik tidak lebih panjang dari jendela canary. Rollup 10 menit pada canary 5 menit hanya mengaburkan semuanya.

Canary dalam konfigurasi: seperti apa langkahnya di Argo Rollouts

Di Kubernetes, spesifikasi canary Argo Rollouts menyatakan urutan tersebut sebagai daftar langkah. Berikut versi ringkasnya dalam bentuk yang dijelaskan dokumentasi:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Dua detail dari dokumentasi layak diperhatikan. Tanpa traffic router, bobot didekati dengan jumlah pod secara best-effort: 10 replika dengan 10 persen berarti satu pod canary dan sembilan stabil. Itu hitungan replika, bukan hitungan request. Lalu pause: {} tanpa durasi menunggu tanpa batas sampai seseorang menjalankan kubectl argo rollouts promote, yaitu gerbang manusia yang mungkin Anda inginkan atau tidak.

Jika langkah analisis gagal, rollout dibatalkan. Di bagian inilah investasi Anda sebaiknya dilakukan.

Feature flag adalah separuh lainnya dari canary yang aman

Canary infrastruktur membagi trafik per instance atau pod. Canary berbasis flag membagi per pengguna, akun, atau atribut apa pun yang bisa ditargetkan. Keduanya menjawab pertanyaan yang berbeda. Yang pertama bertanya apakah build baru sehat. Yang kedua bertanya apakah perilaku baru itu dapat diterima, dan memungkinkan Anda mematikannya tanpa deploy ulang.

Untuk rollout berbasis flag, pilihan tooling penting. LaunchDarkly punya aturan targeting dan jejak audit yang paling matang, serta unggul dalam keluasan ekosistem. Harganya pada skala enterprise adalah keluhan yang biasa disampaikan para kepala platform.

Statsig menggabungkan eksperimen dengan flag, cocok untuk tim yang ingin penilaian berbasis metrik di platform yang sama. Kurang cocok jika Anda hanya butuh kill switch.

Trade-off yang jujur: platform flag memberi rollout berdasarkan persentase, tetapi sebagian besar tidak membaca SLO Anda sendiri. Tetap ada yang harus menghubungkan metrik ke keputusan.

Anda butuh sumber perbandingan yang bisa dipecah per versi

Apa pun yang menggerakkan rollout, keputusannya berasal dari telemetri Anda. Itu berarti setiap metrik membutuhkan label versi atau kohort, dan backend Anda harus bisa menanyakannya tanpa jeda 10 menit.

Datadog menangani ini dengan baik lewat breakdown berbasis tag, dan pelacakan deploy-nya mengorelasikan rilis dengan lonjakan error. Biaya pada kardinalitas tinggi perlu dihitung dulu sebelum Anda memberi tag pada segalanya.

Grafana dengan Prometheus cocok jika Anda sudah menjalankannya dan memberi label metrik dengan revisi rollout. Anda mendapat kontrol penuh, dan Anda juga yang memelihara.

Mengotomatiskan abort: dari mana ide AI pilot berasal

Analisis canary manual sulit diskalakan. Pada sepuluh deploy per hari, tidak ada yang menatap dashboard selama 30 menit setiap kali, sehingga gerbang diam-diam berubah menjadi "kelihatannya oke". Pola yang bertahan adalah hakim otomatis: definisikan SLO, definisikan perbandingannya, lalu biarkan controller membatalkan dan me-revert ketika canary menghabiskan error budget lebih cepat daripada kontrol.

Itulah masalah yang dibidik AI Pilot upstreamapi: ia membaca sinyal SLO selama rollout dan memicu auto-rollback saat tingkat error melewati threshold yang Anda tetapkan. Ia mengukur tingkat error dan latensi terhadap kohort stabil, tidak lebih dari itu. Jika Anda sudah menjalankan template analisis Argo Rollouts dengan query Prometheus yang baik, Anda sudah punya sebagian besar kemampuan yang sama, dan sebaiknya Anda jujur tentang itu kepada siapa pun yang mencoba menjual sihir. Platform yang di-hosting baru layak dipertimbangkan di stack yang beragam, tempat setiap tim jika tidak harus memelihara template analisisnya sendiri.

Pola kegagalan yang umum: tim mengotomatiskan langkah promote, tetapi tidak pernah mengotomatiskan abort. Pipeline yang hanya tahu cara maju adalah conveyor belt.

Apa yang perlu diukur agar proses canary Anda terbukti bekerja

Program canary punya metriknya sendiri. Pantau ini selama satu kuartal:

• Abort rate canary: proporsi canary yang dihentikan oleh gerbang. Nol berarti gerbangnya buta. Di atas 20 sampai 30 persen biasanya berarti threshold yang tidak stabil atau pengujian pra-merge yang lemah.

• Time to detect pada canary: menit dari request buruk pertama sampai abort. Ini MTTD nyata Anda untuk rilis.

• Regresi yang lolos: insiden yang ditelusuri ke rilis yang lolos canary. Setiap kasus seharusnya mengubah satu gerbang.

• Mean time to revert: dari keputusan abort sampai 100 persen trafik berada di versi stabil.

Jalankan hanya satu canary dalam satu waktu per layanan. Workbook sangat menganjurkannya, dan alasannya praktis: dua perubahan yang tumpang tindih membuat atribusi mustahil, dan Anda tidak akan tahu mana yang merusak.

Mulai dari mana minggu ini

Pilih satu layanan stateless dengan trafik yang cukup untuk menghasilkan sinyal dalam 15 menit. Tambahkan label versi pada metrik error dan latensinya. Tulis satu query perbandingan: canary melawan kontrol. Jalankan canary 5 persen dengan promote manual, dan catat apa yang akan tertangkap pada tiga insiden terakhir.

Lalu ajukan pertanyaan yang tidak nyaman: jika canary gagal pukul 02.00, apakah ada yang akan menghentikannya tanpa manusia yang terjaga?