# Apa Itu Canary Deployment? Panduan Praktis untuk SRE URL: https://upstreamapi.com/id/journal/apa-itu-canary-deployment Type: blog Locale: id Published: 2026-10-24 Updated: 2026-10-26 --- > Canary deployment mengirim perubahan ke sebagian kecil trafik dan memperluasnya hanya jika metrik tetap sehat. Langkah, metrik gerbang, dan jebakan yang membutakan tim. 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. ![Burung kenari kuning bertengger di kait lentera di terowongan tambang yang gelap](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/ac107f-img1.webp) 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](https://sre.google/workbook/canarying-releases/) 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. ![Pemandangan udara jalan raya saat satu lajur dipisahkan oleh kerucut oranye sementara lajur lain berjalan normal](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f7c98f-img2.webp) 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](https://argo-rollouts.readthedocs.io/en/stable/features/canary/) 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. ![Panel kontrol industri dengan tombol revert merah berpelindung dan deretan lampu indikator hijau](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/5eb655-img4.webp) ## 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? ## FAQ ### Apa itu canary deployment dalam istilah sederhana? Ini metode rilis ketika versi baru lebih dulu melayani sebagian kecil trafik nyata, sementara versi lama melayani sisanya. Anda membandingkan metrik kesehatan antara kedua kelompok. Jika versi baru tetap sehat, porsinya dinaikkan sampai menangani semua trafik. Jika tidak, Anda melakukan revert. ### Apa bedanya canary deployment dengan blue-green deployment? Blue-green menyimpan dua lingkungan penuh dan memindahkan seluruh trafik sekaligus, sehingga rollback instan tetapi perpindahan itu memapar 100 persen pengguna. Canary memapar sebagian kecil lebih dulu dan menilai versi baru terhadap versi lama menggunakan trafik nyata. Canary punya radius dampak lebih kecil dan kompleksitas operasional lebih tinggi. ### Berapa persen trafik yang sebaiknya masuk ke canary? Tidak ada angka universal. SRE Workbook dari Google memakai contoh 5 persen selama 30 menit. Slice harus cukup besar dan cukup lama untuk menghasilkan sinyal yang berguna secara statistik, dan itu bergantung pada volume trafik Anda serta seberapa seragam request-nya. ### Metrik apa yang sebaiknya menjadi gerbang canary deployment? Mulailah dari SLI Anda: tingkat error dan latensi, dibandingkan antara canary dan kontrol. Tambahkan sinyal saturasi yang bisa dikaitkan dengan perubahan, dan metrik bisnis jika bisa diisolasi per kohort. Hindari metrik yang bising seperti penggunaan CPU mentah, dan jaga daftarnya tetap pendek. ### Apa bedanya canary release dengan canary deployment? Sebagian tim memakai canary release untuk paparan fitur kepada pengguna dan canary deployment untuk rollout infrastruktur yang lebih luas. Banyak tim menganggap kedua istilah ini sama. Yang penting, kelompok terbatas menerima perubahan lebih dulu dan pemeriksaan metrik menentukan langkah berikutnya. ### Bisakah melakukan canary deployment tanpa Kubernetes? Bisa. Mekanisme apa pun yang membagi trafik per versi dapat dipakai: load balancer dengan routing berbobot, service mesh, aturan CDN, atau feature flag yang menargetkan persentase pengguna. Alat Kubernetes seperti Argo Rollouts mengotomatiskan langkah-langkahnya, tetapi pola ini tidak bergantung padanya.