Skop dan gesaan
Ini adalah masalah satah kawalan pelepasan (release-control-plane), bukan sekadar mengubah bilangan replika Deployment beberapa kali. Pengawal merekodkan versi yang diingini, langkah semasa, pemberatan trafik, keputusan analisis dan keputusan manusia, kemudian mencerminkan tindakan tersebut secara andal dalam satah data. Google SRE mentakrifkan canary sebagai triển khai dan penilaian separa yang terhad masa. Kubernetes RollingUpdate menyediakan ketersediaan asas; penghantaran progresif menambah analisis berasaskan trafik, jeda, kelulusan dan rollback automatik.
Perkara yang diuji oleh penemuduga
- Memisahkan keadaan satah kawalan, beban kerja, penghalaan dan analisis metrik.
- Memodelkan kenaikan pangkat (promotion) sebagai mesin keadaan tahan lasak yang idempoten dan bukannya skrip yang tidak boleh dipulihkan.
- Menentukan tetingkap canary/kawalan yang boleh dibandingkan, saiz sampel, penghadang keselamatan (guardrails) dan kelewatan metrik.
- Mengendalikan pelepasan baharu yang menggantikan pelepasan lama, penghentian/penyalaan semula pengawal, metrik yang tidak tersedia dan kejayaan serantau separa.
- Mengekalkan rekod siapa yang meluluskan, sebab pelancaran dijeda atau dibatalkan, dan versi mana yang menjadi stabil.
Soalan untuk dijelaskan terlebih dahulu
- Adakah trafik dibahagikan mengikut permintaan, pengguna, wilayah atau replika? Adakah pembahagian baldi (bucketing) yang stabil diperlukan?
- Metrik manakah yang merupakan pintu kawalan keras (hard gates) dan manakah yang merupakan pemerhatian? Bagaimanakah bajet ralat dan sampel minimum ditakrifkan?
- Adakah rollback hanya mengalihkan trafik, atau adakah ia juga menghentikan dan mengecilkan skala canary? Bagaimanakah format pangkalan data dan mesej dipastikan serasi?
- Adakah langkah-langkah berjalan secara automatik atau diluluskan secara manual? Bagaimanakah kelulusan diberi kuasa?
- Adakah wilayah maju bersama-sama, secara bebas, atau adakah satu kegagalan serantau menghentikan keseluruhan pelancaran global?
Jawapan 30 saat
“Saya akan memodelkan pelepasan sebagai mesin keadaan tahan lasak dengan langkah-langkah, sasaran berat trafik, dasar jeda, templat analisis, masa tamat dan versi rollback. Gelung penyelarasan (reconcile loop) yang idempoten menggunakan keadaan yang diingini pada beban kerja dan penghalaan, kemudian membaca keadaan sebenar serta metrik berskop versi. Kenaikan pangkat memerlukan sampel yang mencukupi, tetingkap yang lengkap, melepasi kawalan ralat, latensi ekor dan perniagaan; ketiadaan sumber metrik akan menjeda sistem secara lalai. Setiap tindakan membawa versi pelepasan dan langkah, supaya penyalaan semula menumpu dengan selamat. Kelulusan, jeda, rollback dan perubahan penghalaan menjadi jejak audit.”
Jawapan mendalam
Langkah 1: Tentukan sumber dan keadaan
Sumber pelepasan mengandungi release_id, versi calon dan stabil, langkah-langkah, langkah semasa, sasaran berat trafik, templat analisis, sebab jeda, masa tamat dan dasar rollback. Keadaan boleh menjadi PENDING, RUNNING, PAUSED, PROMOTING, ABORTING, SUCCEEDED, dan FAILED. Setiap peralihan memerlukan prasyarat yang jelas dan kesan yang idempoten.
Langkah 2: Pisahkan satah kawalan dan data
Satah kawalan menyimpan keadaan yang diingini dan kesimpulan analisis; satah data menjalankan Pods, Services, Ingress atau service mesh. Penulisan API yang berjaya bukanlah kejayaan pelancaran. Perhatikan replika yang tersedia, berat sebenar, kesediaan (readiness) dan label versi. maxUnavailable dan maxSurge Kubernetes mengehadkan penggantian, bukan trafik canary pada peringkat permintaan.
Langkah 3: Reka bentuk peruntukan trafik yang stabil
Gunakan kunci permintaan atau pengguna yang konsisten supaya pengguna yang sama tidak melompat-lompat antara canary dan kawalan. Lapisan penghalaan melaporkan berat sebenar dan bilangan capaian versi. Bagi pelbagai wilayah, simpan sasaran dan berat sebenar bagi setiap wilayah; purata global tidak boleh menyembunyikan satu wilayah yang mengalami 100% kegagalan.
Langkah 4: Tentukan tetingkap analisis dan penghadang keselamatan
Templat analisis mengisytiharkan pertanyaan, tempoh persampelan, sampel minimum, toleransi, kegagalan berturut-turut dan masa menunggu maksimum. Metrik merangkumi ketersediaan, latensi ekor, ketepuan sumber dan hasil perniagaan kritikal, setiap satunya ditag mengikut versi, wilayah dan pembahagi trafik. Tetingkap yang tidak lengkap atau data yang hilang akan menjeda proses; ketiadaan data bukan bermaksud kejayaan.
Langkah 5: Laksanakan penyelarasan yang boleh dipulihkan
Pengawal membaca pelepasan, beban kerja, laluan dan hasil analisis secara berkala untuk mengira satu tindakan seterusnya. Penulisan luaran menyertakan release_id dan versi langkah, supaya percubaan semula tidak menduplikasi peraturan atau kelulusan. Selepas penyalaan semula, ia menumpu daripada keadaan yang disimpan dan diperhatikan. Jika berat sebenar menyimpang, jeda dan baiki sebelum meneruskan kenaikan pangkat.
Langkah 6: Kendalikan jeda, kelulusan dan masa tamat
Langkah-langkah boleh dijeda secara automatik, untuk tempoh tertentu, atau selama-lamanya untuk kelulusan. Kelulusan membawa identiti, skop dan versi langkah semasa; kelulusan lama tidak boleh mempromosikan pelepasan baharu. Masa tamat menjeda atau membatalkan mengikut dasar dan bukannya meluaskan trafik. Kenaikan pangkat paksa (force-promote) memerlukan kebenaran dan sebab yang kukuh.
Langkah 7: Reka bentuk sempadan rollback dan keserasian
Rollback biasanya mengalihkan trafik ke versi stabil terlebih dahulu, kemudian memutuskan sama ada untuk menghentikan atau mengecilkan skala canary. Migrasi pangkalan data, skema acara dan format cache memerlukan tetingkap bertindih untuk kedua-dua versi; mengembalikan binari tidak boleh membatalkan penulisan yang tidak boleh diubah (irreversible). Rollback itu sendiri mestilah idempoten, boleh diperhatikan dan mengekalkan versi stabil sebelumnya.
Langkah 8: Sahkan, audit dan latihan amali
Uji kenaikan pangkat, berat penghalaan, pengelompokan metrik, jeda, penyalaan semula pengawal, gangguan metrik, gangguan serantau, webhook pendua dan pelepasan baharu yang menggantikan pelepasan semasa. Audit keadaan yang diingini dan sebenar, pelaku, masa, sebab dan snapshot metrik. Latihan mesti membuktikan bahawa isyarat yang buruk menghentikan peluasan trafik, bukan sekadar API mengembalikan respons 200.
Pertukaran (trade-offs) dan sempadan
RollingUpdate natif berbanding pengawal progresif
RollingUpdate sesuai untuk perkhidmatan yang memerlukan penggantian replika secara beransur-ansur dan pemeriksaan kesediaan. Trafik, metrik perniagaan, kelulusan dan rollback automatik memerlukan keupayaan pengawal atau platform tambahan; peratusan replika bukan peratusan permintaan.
Rollback automatik berbanding keputusan manusia
Pintu kawalan keras sesuai untuk kegagalan berkeyakinan tinggi dan dikesan dengan cepat. Untuk metrik perniagaan yang tertangguh atau samar-samar, automasi harus menjeda dan memberitahu pemilik. Dasar mesti menamakan pihak berkuasa hentian muktamad.
Perkembangan global berbanding serantau
Perkembangan global lebih mudah tetapi meningkatkan risiko serantau. Perkembangan bebas lebih selamat tetapi memerlukan lebih banyak keadaan dan kapasiti. Pilih berdasarkan pengasingan trafik, pemastautan data (data residency) dan sempadan domain kegagalan.
Latihan latih tubi kegagalan dan evolusi
Kegagalan: menganggap nisbah replika canary sebagai nisbah trafik
Bilangan replika bukan bilangan permintaan; penggunaan semula sambungan dan trafik serantau memesongkan berat sebenar. Peruntukkan pada lapisan penghalaan dan rekod capaian.
Kegagalan: menaikkan pangkat apabila metrik hilang
Kelewatan pertanyaan, ralat label atau sampel kecil boleh menghasilkan keputusan kosong. Jeda apabila data tiada dan bina semula tetingkap yang lengkap selepas pemulihan.
Kegagalan: hanya melakukan rollback pada imej aplikasi
Penulisan skema, acara atau cache yang tidak boleh diubah boleh menyebabkan versi lama tidak boleh dibaca. Tambahkan pintu keserasian sebelum pelancaran dan alihkan trafik sebelum pemulihan data.
Kesilapan biasa dan soalan susulan
Kesilapan: menyimpan mesin keadaan hanya dalam memori pengawal
Penyalaan semula akan kehilangan langkah, kelulusan dan versi rollback. Kekalkan sumber pelepasan dan peristiwa audit; memori hanyalah cache.
Soalan susulan: bagaimanakah anda menghalang pengawal lama daripada menimpa pelepasan baharu?
Gunakan versi sumber dan versi langkah dengan kemas kini bersyarat (conditional updates). Baca semula sebelum menulis dan hentikan tindakan lapuk apabila versi telah berubah.
Soalan susulan: bagaimanakah anda mengendalikan dua pelepasan serentak?
Gunakan mutex perkhidmatan atau laluan, atau peruntukkan belanjawan trafik secara eksplisit merentasi calon. Dua pengawal tidak boleh mengubah satu berat trafik secara bebas.
Soalan susulan: mengapakah p99 boleh merosot sedangkan latensi purata adalah normal?
Nilai purata menyembunyikan sebilangan kecil permintaan yang sangat perlahan. Bandingkan latensi ekor dan ralat dengan versi, wilayah dan pembahagi yang sama.
Soalan susulan: bagaimana jika sistem metrik tergendala?
Jeda dan tandakan ANALYSIS_UNAVAILABLE, sambil mengekalkan berat semasa. Jalankan semula tetingkap analisis selepas pemulihan; data yang hilang bukan bermaksud kejayaan.
Soalan susulan: bagaimanakah anda mengukur prestasi pengawal itu sendiri?
Jejak masa rehat langkah (step dwell time), ralat berat sebenar berbanding sasaran, kadar rollback palsu, kelewatan pengesanan, masa pemulihan, kelengkapan audit dan pintasan manual (manual overrides).