Konteks dan cakupan
Ini adalah masalah release-control-plane, bukan sekadar mengubah jumlah replika Deployment beberapa kali. Controller mencatat versi yang diinginkan, langkah saat ini, bobot lalu lintas, hasil analisis, dan keputusan manusia, lalu merefleksikan tindakan tersebut secara andal di data plane. Google SRE mendefinisikan canary sebagai deployment dan evaluasi parsial yang terbatas waktu. RollingUpdate pada Kubernetes menyediakan ketersediaan dasar; progressive delivery menambahkan analisis berbasis lalu lintas, jeda, persetujuan, dan rollback otomatis.
Hal yang diuji oleh pewawancara
- Memisahkan status control-plane, workload, routing, dan analisis metrik.
- Memodelkan promosi sebagai state machine persisten yang idempoten, bukan skrip yang tidak dapat dipulihkan.
- Menentukan jendela canary/kontrol yang dapat dibandingkan, ukuran sampel, guardrail, dan jeda metrik.
- Menangani rilis baru yang menggantikan rilis lama, restart controller, metrik yang tidak tersedia, dan keberhasilan regional parsial.
- Mencatat siapa yang menyetujui, mengapa rollout dijeda atau dibatalkan, dan versi mana yang menjadi stabil.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah lalu lintas dibagi berdasarkan permintaan, pengguna, wilayah, atau replika? Apakah diperlukan bucketing yang stabil?
- Metrik mana yang merupakan hard gate dan mana yang merupakan observasi? Bagaimana error budget dan sampel minimum ditentukan?
- Apakah rollback hanya mengalihkan lalu lintas, atau juga menghentikan dan menurunkan skala canary? Bagaimana format basis data dan pesan dijaga agar tetap kompatibel?
- Apakah langkah-langkah berjalan otomatis atau disetujui secara manual? Bagaimana persetujuan diotorisasi?
- Apakah wilayah berkembang bersamaan, secara independen, atau apakah satu kegagalan regional menghentikan rollout global?
Jawaban 30 detik
“Saya akan memodelkan rilis sebagai state machine persisten dengan langkah-langkah, bobot target, kebijakan jeda, templat analisis, batas waktu, dan versi rollback. Reconcile loop yang idempoten menerapkan status yang diinginkan ke workload dan routing, lalu membaca status sebenarnya serta metrik yang dicakup versi. Promosi memerlukan sampel yang cukup, jendela yang lengkap, serta lolos dari guardrail eror, tail-latency, dan bisnis; sumber metrik yang hilang akan memicu jeda secara default. Setiap tindakan membawa versi rilis dan langkah, sehingga restart dapat konvergen dengan aman. Persetujuan, jeda, rollback, dan perubahan routing menjadi jejak audit.”
Jawaban mendalam
Langkah 1: Tentukan resource dan status
Resource rilis berisi release_id, versi kandidat dan stabil, langkah-langkah, langkah saat ini, bobot target, templat analisis, alasan jeda, batas waktu, dan kebijakan rollback. Status dapat berupa PENDING, RUNNING, PAUSED, PROMOTING, ABORTING, SUCCEEDED, dan FAILED. Setiap transisi memerlukan prasyarat eksplisit dan efek yang idempoten.
Langkah 2: Pisahkan control plane dan data plane
Control plane menyimpan status yang diinginkan dan kesimpulan analisis; data plane menjalankan Pod, Service, Ingress, atau service mesh. Keberhasilan penulisan API bukan berarti keberhasilan rollout. Amati replika yang tersedia, bobot sebenarnya, kesiapan (readiness), dan label versi. maxUnavailable dan maxSurge pada Kubernetes membatasi penggantian, bukan lalu lintas canary tingkat permintaan.
Langkah 3: Desain alokasi lalu lintas yang stabil
Gunakan kunci permintaan atau pengguna yang konsisten agar satu pengguna tidak berpindah-pindah antara canary dan kontrol. Lapisan routing melaporkan bobot sebenarnya dan jumlah hit versi. Untuk beberapa wilayah, simpan target dan bobot sebenarnya per wilayah; rata-rata global tidak boleh menyembunyikan satu wilayah yang mengalami kegagalan 100%.
Langkah 4: Tentukan jendela analisis dan guardrail
Templat analisis mendeklarasikan kueri, periode pengambilan sampel, sampel minimum, toleransi, kegagalan berturut-turut, dan waktu tunggu maksimum. Metrik mencakup ketersediaan, tail latency, saturasi sumber daya, dan hasil bisnis penting, yang masing-masing diberi tag berdasarkan versi, wilayah, dan penyebut lalu lintas. Jendela yang tidak lengkap atau data yang hilang akan memicu jeda; data yang hilang bukanlah keberhasilan.
Langkah 5: Terapkan rekonsiliasi yang dapat dipulihkan
Controller secara berkala membaca rilis, workload, rute, dan hasil analisis untuk menghitung satu tindakan berikutnya. Penulisan eksternal menyertakan release_id dan versi langkah, sehingga percobaan ulang tidak menduplikasi aturan atau persetujuan. Setelah restart, controller konvergen dari status yang tersimpan dan teramati. Jika bobot sebenarnya berbeda, jeda dan perbaiki sebelum melakukan promosi.
Langkah 6: Tangani jeda, persetujuan, dan batas waktu
Langkah-langkah dapat dijeda secara otomatis, untuk durasi tertentu, atau tanpa batas waktu untuk persetujuan. Persetujuan membawa identitas, cakupan, dan versi langkah saat ini; persetujuan lama tidak dapat mempromosikan rilis baru. Batas waktu (timeout) akan menjeda atau membatalkan sesuai kebijakan, alih-alih memperluas lalu lintas. Promosi paksa memerlukan otorisasi dan alasan.
Langkah 7: Desain batas rollback dan kompatibilitas
Rollback biasanya mengalihkan lalu lintas ke versi stabil terlebih dahulu, lalu memutuskan apakah akan menghentikan atau menurunkan skala canary. Migrasi basis data, skema event, dan format cache memerlukan jendela tumpang tindih untuk kedua versi; mengembalikan biner tidak dapat membatalkan penulisan yang tidak dapat diubah (irreversible). Rollback itu sendiri harus idempoten, dapat diamati, dan mempertahankan versi stabil sebelumnya.
Langkah 8: Verifikasi, audit, dan gladi bersih
Uji promosi, bobot routing, pengelompokan metrik, jeda, restart controller, pemadaman metrik, pemadaman regional, webhook duplikat, dan rilis baru yang menggantikan rilis saat ini. Audit status yang diinginkan dan sebenarnya, pelaku, waktu, alasan, dan snapshot metrik. Pengujian harus membuktikan bahwa sinyal buruk menghentikan ekspansi, bukan hanya sekadar API mengembalikan respons 200.
Pertukaran (trade-off) dan batasan
RollingUpdate bawaan versus progressive controller
RollingUpdate cocok untuk layanan yang membutuhkan penggantian replika secara bertahap dan pemeriksaan kesiapan. Lalu lintas, metrik bisnis, persetujuan, dan rollback otomatis memerlukan kemampuan controller atau platform tambahan; persentase replika bukanlah persentase permintaan.
Rollback otomatis versus keputusan manusia
Hard gate cocok untuk kegagalan dengan tingkat keyakinan tinggi yang dapat dideteksi dengan cepat. Untuk metrik bisnis yang tertunda atau ambigu, otomatisasi harus menjeda dan memberi tahu pemilik sistem. Kebijakan harus menentukan pihak yang memiliki wewenang penghentian akhir.
Progresi global versus regional
Progresi global lebih sederhana tetapi memperbesar risiko regional. Progresi independen lebih aman tetapi membutuhkan lebih banyak status dan kapasitas. Pilihlah berdasarkan isolasi lalu lintas, residensi data, dan batasan failure domain.
Latihan simulasi kegagalan dan evolusi
Kegagalan: memperlakukan rasio replika canary sebagai rasio lalu lintas
Jumlah replika bukan jumlah permintaan; penggunaan kembali koneksi dan lalu lintas regional membuat bobot sebenarnya condong. Alokasikan di lapisan routing dan catat jumlah hit.
Kegagalan: mempromosikan saat metrik hilang
Penundaan kueri, kesalahan label, atau sampel kecil dapat menghasilkan data kosong. Jeda saat data hilang dan bangun kembali jendela yang lengkap setelah pemulihan.
Kegagalan: hanya melakukan rollback pada image aplikasi
Penulisan skema, event, atau cache yang tidak dapat diubah dapat membuat versi lama tidak dapat dibaca. Tambahkan compatibility gate sebelum rollout dan alihkan lalu lintas sebelum remediasi data.
Kesalahan umum dan pertanyaan lanjutan
Kesalahan: menyimpan state machine hanya di memori controller
Restart akan menghilangkan langkah, persetujuan, dan versi rollback. Simpan resource rilis dan audit event secara persisten; memori hanyalah cache.
Pertanyaan lanjutan: bagaimana Anda mencegah controller lama menimpa rilis baru?
Gunakan versi resource dan versi langkah dengan pembaruan bersyarat (conditional update). Baca kembali sebelum menulis dan hentikan tindakan yang sudah usang saat versi berubah.
Pertanyaan lanjutan: bagaimana Anda menangani dua rilis secara bersamaan?
Gunakan mutex layanan atau rute, atau anggarkan lalu lintas secara eksplisit di antara para kandidat. Dua controller tidak boleh memutasi satu bobot yang sama secara independen.
Pertanyaan lanjutan: mengapa p99 dapat mengalami regresi sementara latensi rata-rata normal?
Rata-rata menyembunyikan sebagian kecil permintaan yang sangat lambat. Bandingkan tail latency dan eror dengan versi, wilayah, dan penyebut yang sama.
Pertanyaan lanjutan: bagaimana jika sistem metrik mati?
Jeda dan tandai ANALYSIS_UNAVAILABLE, pertahankan bobot saat ini. Jalankan kembali jendela analisis setelah pemulihan; data yang hilang bukanlah keberhasilan.
Pertanyaan lanjutan: bagaimana Anda mengukur kinerja controller itu sendiri?
Lacak waktu tunggu langkah (dwell time), eror bobot sebenarnya versus target, tingkat rollback palsu, keterlambatan deteksi, waktu pemulihan, kelengkapan audit, dan pengabaian manual (manual overrides).