Gesaan dan konteks
Sebuah pasukan ingin mendedahkan versi baharu kepada sebahagian kecil permintaan sebenar sebelum meningkatkan trafik secara beransur-ansur. Perkhidmatan ini mesti mengkonfigurasi pemberat, membandingkan kanari dengan versi stabil, dan berhenti atau berundur balik secara automatik apabila isyarat merosot. Reka bentuk satah kawalan dan data, termasuk SLO, tetingkap metrik, keadaan tahan lasak, kebenaran, keidempotetan, dan tingkah laku apabila pengawal terputus sambungan.
Ini sesuai untuk peranan reka bentuk sistem, kejuruteraan platform, dan SRE. Kemahiran terasnya adalah mengubah "pelepasan selamat" menjadi mesin keadaan yang boleh dipulihkan, bukannya sekadar menyenaraikan Kubernetes, service mesh, dan produk pemantauan. Jawapan tersebut harus merangkumi penghalaan, kerja analisis, ambang keputusan, campur tangan manusia, dan keserasian ke belakang dengan versi lama.
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh mentakrifkan pendedahan, tempoh, dan sasaran undur balik sebelum mengasingkan pengawal pelancaran, penghala, pertanyaan metrik, dan logik keputusan. Ia membezakan kejayaan, kegagalan, dan bukti yang tidak mencukupi supaya metrik yang hilang tidak menjadi kelulusan secara tidak sengaja. Ia menggunakan keadaan tahan lasak dan tindakan idempoten untuk bertahan daripada permulaan semula pengawal, memadankan tetingkap analisis dengan langkah pelancaran, serta menangani hingar sampel kecil, metrik tertunda, dan ribut undur balik.
Soalan untuk dijelaskan terlebih dahulu
- Adakah sasarannya satu perkhidmatan, orkestrasi berbilang perkhidmatan, atau hanya beban kerja Kubernetes?
- Adakah trafik dibahagikan mengikut permintaan rawak, cincangan pengguna yang stabil, rantau, atau penyewa, dan adakah pengguna mesti kekal melekat (sticky)?
- SLO yang manakah penting: kadar ralat, kependaman, penukaran perniagaan, atau kos, dan bagaimanakah garis dasar stabil dipilih?
- Berapa lamakah setiap langkah boleh berjalan, berapa banyak kegagalan yang mencetuskan undur balik, dan patutkah analisis yang tidak pasti dijeda untuk manusia?
- Adakah skema pangkalan data, format mesej, dan API luaran serasi ke belakang, dan adakah undur balik versi lama selamat?
Kerangka jawapan 30 saat
"Saya akan membahagikan perkhidmatan ini kepada pengawal pelancaran, penyesuai penghalaan trafik, penganalisis metrik, dan stor keadaan tahan lasak. Setiap pelancaran mempunyai versi stabil dan calon, pemberat berperingkat, tetingkap analisis, serta syarat kejayaan, kegagalan, dan tidak muktamad yang jelas. Pengawal hanya memperluas selepas berjaya, mengembalikan trafik kepada stabil apabila gagal, dan menjeda dengan amaran apabila bukti tidak muktamad. Perintah membawa versi dan kunci keidempotetan, dan keadaan disimpan secara kekal sebelum langkah seterusnya. Semasa gangguan singkat penghala atau metrik, kekalkan pemberat selamat yang terakhir dan sambung semula daripada keadaan tahan lasak selepas pemulihan."
Penyelesaian langkah demi langkah
Langkah 1: takrifkan matlamat dan skala
Andaikan satu rantau mengendalikan 200 pelepasan sehari, setiap satu berlangsung paling lama 40 minit, manakala pengawal memproses berpuluh-puluh peristiwa keadaan dan metrik sesaat; permintaan perniagaan kekal pada get laluan dan perkhidmatan sedia ada. Anggaran tertib magnitud ini menyokong pengawal dan giliran yang berketersediaan tinggi berbanding satu contoh aliran kerja bagi setiap permintaan.
Matlamat keselamatan adalah untuk mengehadkan radius letupan. Urutan yang boleh dikonfigurasi seperti 1% → 5% → 25% → 50% → 100% adalah sebagai ilustrasi, bukan ambang sejagat. Setiap langkah memerlukan masa pemerhatian minimum dan masa menunggu maksimum supaya isyarat yang hilang tidak menduduki slot pelepasan selama-lamanya.
Langkah 2: asingkan satah kawalan dan data
Satah kawalan menyimpan spesifikasi pelepasan, intelek versi (version digests), langkah semasa, pemberat sasaran, hasil analisis, dan pelaku. Satah data menggunakan get laluan atau service mesh untuk menghalakan permintaan ke ReplicaSet stabil atau kanari. Seni bina Argo Rollouts mengasingkan Rollout, dua ReplicaSet berversi, Services/Ingress, dan AnalysisTemplate/AnalysisRun, menunjukkan sempadan yang boleh berkembang secara bebas.
Penyesuai metrik hanya melaksanakan pertanyaan terhadap penyedia seperti Prometheus dan mengembalikan pemerhatian berserta tetingkap masanya. Enjin keputusan menggunakan dasar dan tidak mengedit laluan secara langsung, jadi penggantian bahagian belakang metrik tidak mengubah mesin keadaan pelancaran.
Langkah 3: bina mesin keadaan yang boleh dipulihkan
Gunakan keadaan seperti Draft → Running → Paused → Promoting → Succeeded, dengan Running atau Paused boleh memasuki Aborting → RolledBack. Setiap peralihan membawa rollout_id, versi yang diingini, nombor langkah, dan kunci keidempotetan. Kekangan unik atau compare-and-set menghalang dua pengawal daripada memajukan pelancaran 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 -> RolledBackSelepas permulaan semula, pengawal memainkan semula tindakan yang belum selesai daripada keadaan komited yang terakhir. Kemas kini laluan dan penulisan keadaan tidak boleh membentuk satu transaksi atom rentas sistem, jadi tindakan mesti boleh diulang: menetapkan pemberat yang sama dua kali tidak mempunyai kesan tambahan, dan pengawal membaca laluan sebenar sebelum memilih langkah seterusnya.
Langkah 4: pilih metrik dan tetingkap
Setiap langkah harus mempunyai sekurang-kurangnya satu isyarat kebolehpercayaan dan satu isyarat perniagaan, seperti delta kadar ralat kanari berbanding stabil, delta kependaman P95, dan kadar kejayaan permintaan utama. Tetapkan tetingkap pertanyaan, penyebut, dan penapis supaya percubaan semula kanari tidak dibandingkan dengan permintaan asal versi stabil.
Tetingkap mesti meliputi kelewatan pengumpulan dan kekal dalam masa tamat langkah. Panduan kanari Google SRE membandingkan kanari dengan kawalan dan memberi amaran bahawa tempoh metrik yang lebih panjang daripada peringkat kanari yang singkat menghasilkan isyarat yang bercelaru. Tandakan sampel kecil sebagai tidak muktamad; menjeda adalah lebih selamat daripada memperluas berdasarkan bukti yang lemah.
Langkah 5: kendalikan pembahagian trafik dan kelekatan
Pembahagian permintaan secara rawak sesuai untuk API tanpa keadaan. Untuk pengalaman yang konsisten, gunakan cincangan stabil pengguna atau penyewa dan rekod versi yang dihalakan. Penghalaan peratusan mesti mengendalikan calon yang tidak sihat, pemberat yang tidak digunakan, pencapahan serantau, dan pertembungan kunci cache.
Penyesuai penghalaan mengembalikan pemberat berkesan dan intelek versi. Jika nilai yang diingini dan nilai sebenar berbeza, pengawal akan menjeda dan memberi amaran; respons API penghalaan yang berjaya bukanlah bukti bahawa trafik telah beralih.
Langkah 6: reka bentuk undur balik, jeda, dan campur tangan manusia
Apabila gagal, hentikan peningkatan trafik kanari dan kurangkannya kepada sifar atau pemberat yang selamat. Pastikan versi lama boleh dijalankan, dan gunakan susunan kembang/kecut (expand/contract) untuk migrasi pangkalan data supaya undur balik masih boleh membaca skema. Undur balik itu sendiri memerlukan masa tamat dan had percubaan semula untuk mengelakkan gelung tak terhingga apabila penghala tidak tersedia.
Apabila analisis adalah Inconclusive, jeda bersama buktinya: pertanyaan, kiraan sampel, versi, tetingkap, dan ambang mestilah boleh diaudit. Argo Rollouts mendokumenkan Inconclusive sebagai hasil yang dijeda untuk penilaian manusia, yang lebih selamat daripada menganggap data yang hilang sebagai kejayaan.
Langkah 7: kebolehpercayaan, kebenaran, dan audit
Gunakan pemilihan pemimpin atau pajakan untuk pengawal. Penghantaran giliran mungkin sekurang-kurangnya sekali (at least once), jadi pengguna menyahduplikasi mengikut kunci keidempotetan. Tulis spesifikasi pelepasan, perubahan dasar, dan kelulusan ke dalam log audit yang tidak boleh diubah. Hanya pemilik pelepasan yang menukar pemberat; kelayakan metrik datang daripada pengurus rahsia; kebenaran undur balik diasingkan daripada kenaikan pangkat biasa.
Jejak SLO satah kawalan: kependaman peralihan, pelancaran yang tersekat, tempoh undur balik, pemberat sebenar berbanding yang diingini, dan kegagalan pertanyaan metrik. Apabila satah kawalan gagal, kekalkan laluan selamat yang terakhir dan hubungi operator melalui kelui dan bukannya menghantar kanari secara automatik kepada 100%.
Langkah 8: sahkan dan lakukan ujian beban
Suntik kerosakan untuk peningkatan kadar ralat, tiada data, data tertunda, masa tamat penghala, permulaan semula pengawal, mesej pendua, dan skema pangkalan data yang tidak serasi. Semak keadaan akhir dan amaran bagi setiap kerosakan, bukan hanya laluan gembira (happy path).
Main semula pelepasan sejarah untuk mengukur kos pertanyaan analisis dan tunggakan giliran, serta jalankan ujian kegagalan pengawal N+1. Gunakan seratus pelancaran serentak sebagai contoh had beban, perhatikan perebutan kunci stor keadaan, QPS penyedia metrik, dan kadar kemas kini laluan, kemudian tetapkan had keserentakan.
Pertukaran kompromi dan sempadan
Automasi menghapuskan kelewatan manusia, tetapi ambang yang teruk boleh mengubah hingar menjadi undur balik atau regresi sebenar menjadi lulus. Ambang kadar ralat mutlak mudah dijelaskan dan sesuai untuk perkhidmatan bervolum trafik rendah; perbandingan stabil atau garis dasar berstrata mengendalikan perubahan trafik harian dengan lebih baik tetapi memerlukan statistik dan penjajaran sampel yang lebih teliti. Perkhidmatan berisiko tinggi boleh memerlukan kelulusan manusia selepas analisis automatik.
Biru-hijau (blue-green) memberikan peralihan pantas dan undur balik yang mudah tetapi biasanya memerlukan kapasiti berganda. Kanari mengurangkan pendedahan tetapi memerlukan pembahagian trafik dan tetingkap analisis. Feature flag boleh memisahkan pelancaran ciri daripada pelepasan binari, namun ia tidak boleh menggantikan pemeriksaan keserasian untuk binari, kebergantungan, atau skema. Buat pilihan mengikut kos undur balik, corak trafik, dan risiko SLO.
Pelan pelancaran dan bukti
Mulakan dengan analisis baca sahaja dan jeda manual untuk satu perkhidmatan tanpa keadaan. Sahkan label stabil/kanari, pengelompokan metrik, dan medan audit; kemudian dayakan undur balik automatik; akhirnya tambah isyarat berbilang rantau, metrik perniagaan, dan had keserentakan. Kekalkan suis pemutus manusia dan pemilik yang jelas pada setiap peringkat.
Google SRE mentakrifkan kanari sebagai penggunaan separa yang terhad masa berserta penilaian dan memerlukan penilaian tersebut disalurkan kembali ke dalam proses pelepasan. Argo Rollouts menyediakan AnalysisTemplate/AnalysisRun, ambang metrik, dan hasil kejayaan, kegagalan, serta tidak muktamad. Bahan temu duga reka bentuk sistem awam juga menganggap pembahagian trafik, penilaian pagar kawalan, dan undur balik automatik sebagai poin reka bentuk kanari. Oleh itu, artikel ini menumpukan pada mesin keadaan satah kawalan yang boleh dipulihkan dan bukannya glosari strategi penggunaan semata-mata.
Kesilapan lazim dan tindakan susulan
Hanya menyebut "pantau 10% trafik"
Tanpa populasi, tempoh, penyebut, dan tindakan kegagalan, keselamatan tidak terbukti. Tambahkan garis dasar stabil, tetingkap, ambang, jeda, dan laluan undur balik.
Menganggap metrik yang hilang sebagai lulus
Gangguan pengumpul boleh mereka-reka isyarat yang kelihatan sihat. Tandakan tiada data, NaN, kelewatan, dan sampel yang tidak mencukupi sebagai tidak muktamad; jeda dan beri amaran.
Mengundur balik Deployment tetapi bukan laluannya
Pod lama yang sihat tidak membuktikan permintaan telah meninggalkan kanari. Sahkan pemberat berkesan, pemilih perkhidmatan, dan kelekatan cache atau sesi.
Menjadikan migrasi pangkalan data tidak boleh dipulihkan
Versi lama mungkin tidak dapat membaca skema baharu, jadi menukar laluan kembali tidak dapat memulihkan keselamatan. Gunakan perubahan kembang/kecut yang serasi ke belakang dan jadikan keadaan migrasi sebagai get pelancaran.
Bagaimana jika penyedia metrik tergendala?
Kekalkan pemberat selamat yang terakhir, hentikan peluasan automatik, rekod analisis yang belum selesai, dan maklumkan kepada pemilik. Selepas pemulihan, sambung semula daripada keadaan tahan lasak; jangan sekali-kali mengisi jurang tersebut dengan "lulus" lalai.