Petunjuk dan konteks
Sebuah tim ingin mengekspos versi baru ke sebagian kecil permintaan nyata sebelum meningkatkan lalu lintas secara bertahap. Layanan ini harus mengonfigurasi bobot (weights), membandingkan canary dengan versi stabil, dan secara otomatis menghentikan atau melakukan rollback ketika sinyal mengalami degradasi. Rancang control plane dan data plane, termasuk SLO, jendela metrik, durable state, izin, idempotensi, dan perilaku saat controller terputus.
Topik ini cocok untuk peran system design, platform engineering, dan SRE. Keahlian intinya adalah mengubah "rilis yang aman" menjadi state machine yang dapat dipulihkan, bukan sekadar menyebutkan Kubernetes, service mesh, dan produk pemantauan. Jawaban harus mencakup perutean, tugas analisis, ambang batas keputusan, intervensi manusia, dan kompatibilitas mundur dengan versi lama.
Hal yang diuji oleh pewawancara
Jawaban yang kuat mendefinisikan paparan, durasi, dan target rollback sebelum memisahkan rollout controller, router, kueri metrik, dan logika keputusan. Jawaban tersebut membedakan keberhasilan, kegagalan, dan bukti yang tidak cukup sehingga metrik yang hilang tidak secara tidak sengaja dianggap berhasil. Solusi ini menggunakan durable state dan tindakan idempoten untuk bertahan dari restart controller, mencocokkan jendela analisis dengan langkah-langkah peluncuran, serta mengatasi gangguan sampel kecil, metrik yang tertunda, dan badai rollback.
Pertanyaan klarifikasi awal
- Apakah targetnya adalah satu layanan, orkestrasi multilayanan, atau hanya beban kerja Kubernetes?
- Apakah lalu lintas dibagi berdasarkan permintaan acak, hash pengguna yang stabil, wilayah, atau tenant, dan apakah pengguna harus tetap mempertahankan keterikatan (sticky)?
- SLO mana yang penting: tingkat kesalahan, latensi, konversi bisnis, atau biaya, dan bagaimana baseline stabil dipilih?
- Berapa lama setiap langkah boleh berjalan, berapa banyak kegagalan yang memicu rollback, dan apakah analisis yang tidak pasti harus dijeda untuk ditinjau manusia?
- Apakah skema basis data, format pesan, dan API eksternal kompatibel ke belakang, dan apakah rollback ke versi lama aman dilakukan?
Kerangka jawaban 30 detik
"Saya akan membagi layanan menjadi rollout controller, adaptor perutean lalu lintas, penganalisis metrik, dan penyimpanan durable state. Setiap peluncuran memiliki versi stabil dan kandidat, bobot bertahap, jendela analisis, serta kondisi sukses, gagal, dan tidak meyakinkan yang eksplisit. Controller hanya memperluas setelah berhasil, mengembalikan lalu lintas ke stabil saat gagal, dan menjeda dengan peringatan jika buktinya tidak meyakinkan. Perintah membawa versi dan kunci idempotensi, dan status disimpan sebelum langkah berikutnya. Selama pemadaman singkat pada router atau metrik, pertahankan bobot aman terakhir dan lanjutkan dari durable state setelah pemulihan."
Solusi langkah demi langkah
Langkah 1: tentukan sasaran dan skala
Asumsikan satu wilayah menangani 200 rilis per hari, masing-masing berlangsung paling lama 40 menit, sementara controller memproses puluhan peristiwa status dan metrik per detik; permintaan bisnis tetap berada pada gateway dan layanan yang ada. Estimasi order-of-magnitude ini mendukung controller dan antrean dengan ketersediaan tinggi daripada instance alur kerja per permintaan.
Tujuan keamanannya adalah membatasi radius dampak (blast radius). Urutan yang dapat dikonfigurasi seperti 1% → 5% → 25% → 50% → 100% hanyalah ilustrasi, bukan ambang batas universal. Setiap langkah memerlukan waktu pengamatan minimum dan waktu tunggu maksimum agar sinyal yang hilang tidak menempati slot rilis selamanya.
Langkah 2: pisahkan control plane dan data plane
Control plane menyimpan spesifikasi rilis, digest versi, langkah saat ini, target bobot, hasil analisis, dan pelaku (actor). Data plane menggunakan gateway atau service mesh untuk merutekan permintaan ke ReplicaSet stabil atau canary. Arsitektur Argo Rollouts memisahkan Rollout, dua ReplicaSet berversi, Services/Ingress, dan AnalysisTemplate/AnalysisRun, menunjukkan batasan yang dapat berkembang secara independen.
Adaptor metrik hanya mengeksekusi kueri terhadap penyedia seperti Prometheus dan mengembalikan pengamatan beserta jendela waktunya. Mesin keputusan menerapkan kebijakan dan tidak mengedit rute secara langsung, sehingga penggantian backend metrik tidak mengubah state machine peluncuran.
Langkah 3: bangun state machine yang dapat dipulihkan
Gunakan status seperti Draft → Running → Paused → Promoting → Succeeded, dengan Running atau Paused dapat memasuki Aborting → RolledBack. Setiap transisi membawa rollout_id, versi yang diinginkan, nomor langkah, dan kunci idempotensi. Batasan unik atau compare-and-set mencegah dua controller memajukan peluncuran yang sama.
Running + analysis=success -> Promoting(next_weight)
Running + analysis=failure -> Aborting(weight=0)
Running + analysis=inconclusive -> Paused(reason=insufficient_signal)
Paused + operator=resume -> Running
Aborting + route=stable -> RolledBackSetelah restart, controller memutar ulang tindakan yang belum selesai dari status terakhir yang dikomit. Pembaruan rute dan penulisan status tidak dapat membentuk satu transaksi atomik lintas sistem, sehingga tindakan harus dapat diulang: menetapkan bobot yang sama dua kali tidak memiliki efek tambahan, dan controller membaca rute sebenarnya sebelum memilih langkah berikutnya.
Langkah 4: pilih metrik dan jendela waktu
Setiap langkah harus memiliki setidaknya satu sinyal keandalan dan satu sinyal bisnis, seperti selisih tingkat kesalahan canary vs stabil, selisih latensi P95, dan tingkat keberhasilan permintaan utama. Tetapkan jendela kueri, penyebut, dan filter agar percobaan ulang canary tidak dibandingkan dengan permintaan asli dari versi stabil.
Jendela harus mencakup keterlambatan pengumpulan dan tetap berada dalam batas waktu tunggu langkah. Panduan canary Google SRE membandingkan canary dengan kontrol dan memperingatkan bahwa periode metrik yang lebih panjang daripada tahap canary yang pendek akan menghasilkan sinyal yang rancu. Tandai sampel kecil sebagai tidak meyakinkan; menjeda lebih aman daripada memperluas berdasarkan bukti yang lemah.
Langkah 5: tangani pembagian lalu lintas dan stickiness
Pembagian permintaan acak cocok untuk API stateless. Untuk pengalaman yang konsisten, gunakan hash stabil dari pengguna atau tenant dan catat versi yang dirutekan. Perutean persentase harus menangani kandidat yang tidak sehat, bobot yang tidak diterapkan, perbedaan regional, dan tabrakan kunci cache.
Adaptor perutean mengembalikan bobot efektif dan digest versi. Jika nilai yang diinginkan dan nilai aktual berbeda, controller akan menjeda dan memberikan peringatan; respons sukses dari API perutean bukanlah bukti bahwa lalu lintas telah beralih.
Langkah 6: rancang rollback, jeda, dan intervensi manusia
Jika terjadi kegagalan, hentikan peningkatan lalu lintas canary dan kurangi hingga nol atau ke bobot yang aman. Pertahankan versi lama agar tetap dapat dijalankan, dan gunakan urutan expand/contract untuk migrasi basis data sehingga rollback masih dapat membaca skema. Rollback itu sendiri memerlukan batas waktu dan batas percobaan ulang untuk menghindari perulangan tak terbatas saat router tidak tersedia.
Jika analisis berstatus Inconclusive, jeda dengan menyertakan buktinya: kueri, jumlah sampel, versi, jendela, dan ambang batas harus dapat diaudit. Argo Rollouts mendokumentasikan Inconclusive sebagai hasil jeda untuk penilaian manusia, yang lebih aman daripada memperlakukan data yang hilang sebagai keberhasilan.
Langkah 7: keandalan, izin, dan audit
Gunakan pemilihan pemimpin (leader election) atau lease untuk controller. Pengiriman antrean mungkin setidaknya sekali (at-least-once), sehingga konsumen melakukan deduplikasi menggunakan kunci idempotensi. Tulis spesifikasi rilis, perubahan kebijakan, dan persetujuan ke log audit yang tidak dapat diubah (immutable). Hanya pemilik rilis yang dapat mengubah bobot; kredensial metrik berasal dari secret manager; izin rollback terpisah dari promosi biasa.
Lacak SLO control-plane: latensi transisi, peluncuran yang macet, durasi rollback, bobot aktual vs yang diinginkan, dan kegagalan kueri metrik. Ketika control plane gagal, pertahankan rute aman terakhir dan panggil operator daripada secara otomatis mengirim canary ke 100%.
Langkah 8: verifikasi dan uji beban
Sisipkan kegagalan untuk tingkat kesalahan yang meningkat, tidak ada data, data tertunda, batas waktu router, restart controller, pesan duplikat, dan skema basis data yang tidak kompatibel. Periksa status akhir dan peringatan untuk setiap kegagalan, tidak hanya untuk skenario sukses (happy path).
Putar ulang rilis historis untuk mengukur biaya kueri analisis dan backlog antrean, serta jalankan uji kegagalan controller N+1. Gunakan seratus peluncuran bersamaan sebagai contoh batas beban maksimum, amati perebutan kunci penyimpanan status, QPS penyedia metrik, dan tingkat pembaruan rute, lalu tetapkan batas konkurensi.
Trade-off dan batasan
Otomatisasi menghilangkan penundaan manusia, tetapi ambang batas yang buruk dapat mengubah noise menjadi rollback atau membiarkan regresi nyata lolos sebagai berhasil. Ambang batas tingkat kesalahan absolut mudah dijelaskan dan cocok untuk layanan dengan lalu lintas rendah; perbandingan stabil atau baseline bertingkat menangani perubahan lalu lintas harian dengan lebih baik tetapi membutuhkan statistik yang lebih cermat dan penyelarasan sampel. Layanan berisiko tinggi dapat mewajibkan persetujuan manusia setelah analisis otomatis.
Blue-green memberikan cutover cepat dan rollback sederhana tetapi biasanya membutuhkan kapasitas ganda. Canary mengurangi paparan tetapi membutuhkan pembagian lalu lintas dan jendela analisis. Feature flag dapat memisahkan peluncuran fitur dari rilis biner, namun tidak dapat menggantikan pemeriksaan kompatibilitas untuk biner, dependensi, atau skema. Pilih berdasarkan biaya rollback, bentuk lalu lintas, dan risiko SLO.
Rencana peluncuran dan bukti
Mulailah dengan analisis read-only dan jeda manual untuk satu layanan stateless. Verifikasi label stable/canary, pengelompokan metrik, dan bidang audit; kemudian aktifkan rollback otomatis; terakhir, tambahkan sinyal multi-wilayah, metrik bisnis, dan batas konkurensi. Pertahankan sakelar pemutus manual (kill switch) dan pemilik yang jelas di setiap tahap.
Google SRE mendefinisikan canary sebagai penyebaran parsial yang terbatas waktu disertai evaluasi dan mewajibkan evaluasi tersebut menjadi masukan bagi proses rilis. Argo Rollouts menyediakan AnalysisTemplate/AnalysisRun, ambang batas metrik, dan hasil sukses, gagal, serta tidak meyakinkan. Materi wawancara system design publik juga memperlakukan pembagian lalu lintas, evaluasi batas pengaman, dan rollback otomatis sebagai poin desain canary. Oleh karena itu, artikel Offer.cc ini berfokus pada state machine control-plane yang dapat dipulihkan daripada daftar glosarium strategi penerapan.
Kesalahan umum dan tindak lanjut
Hanya mengatakan "pantau 10% lalu lintas"
Tanpa populasi, durasi, penyebut, dan tindakan kegagalan, keamanan tidak terbukti. Tambahkan baseline stabil, jendela, ambang batas, jeda, dan jalur rollback.
Menganggap metrik yang hilang sebagai kelulusan
Kolektor yang mati dapat merekayasa sinyal yang tampak sehat. Tandai ketiadaan data, NaN, keterlambatan, dan sampel yang tidak mencukupi sebagai tidak meyakinkan; jeda dan beri peringatan.
Melakukan rollback pada Deployment tetapi tidak pada rute
Pod lama yang sehat tidak membuktikan bahwa permintaan telah meninggalkan canary. Verifikasi bobot efektif, selektor layanan, dan keterikatan cache atau sesi.
Membuat migrasi basis data tidak dapat diubah kembali
Versi lama mungkin tidak dapat membaca skema baru, sehingga mengalihkan rute kembali tidak dapat memulihkan keamanan. Gunakan perubahan expand/contract yang kompatibel ke belakang dan jadikan status migrasi sebagai gerbang peluncuran.
Bagaimana jika penyedia metrik mati?
Pertahankan bobot aman terakhir, hentikan ekspansi otomatis, catat analisis yang belum selesai, dan beri tahu pemiliknya. Setelah pemulihan, lanjutkan dari durable state; jangan pernah mengisi kekosongan dengan "lulus" secara default.