Maklum balas dan konteks
Perkhidmatan ini mempunyai SLO ketersediaan sebanyak 99.99% dan belanjawan ralat bulanan sebanyak 0.01%. Kegagalan yang dapat dilihat oleh pengguna telah pun melebihi belanjawan, namun ciri yang mempengaruhi pembaharuan kontrak utama masih menunggu untuk dikeluarkan. Terangkan cara anda mentakrifkan penunjuk, mengesahkan bahawa belanjawan benar-benar telah habis, memutuskan perubahan mana yang perlu dijeda, dan memulihkan rentak pelepasan yang sihat.
Google SRE menganggap belanjawan ralat sebagai ruang kegagalan yang dibenarkan oleh SLO: selagi ia masih ada, pasukan boleh melepaskan perubahan dalam batas yang munasabah; selepas ia habis, perubahan biasanya dibekukan, kecuali pembetulan keselamatan segera dan pembetulan untuk kegagalan semasa. Ini merupakan input untuk keputusan risiko, bukannya larangan produk tanpa syarat.
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh bermula dengan SLI berpusatkan pengguna dan menghubungkan penggunaan belanjawan dengan masa pelepasan, rollback dan pemulihan. Jangkakan soalan tentang sebab metrik pelayan boleh memberikan gambaran salah mengenai ketersediaan pengguna, cara memisahkan lonjakan singkat daripada penggunaan berterusan (burn), bukti yang mewajarkan pengecualian, dan pihak yang boleh menarik balik pembekuan.
"Hentikan semua pembangunan" mengabaikan kewajiban keselamatan, integriti data dan pematuhan. "Perniagaan itu penting, jadi teruskan pelepasan" mengabaikan bahasa risiko yang dikongsi bersama.
Soalan untuk penjelasan awal
Impak pengguna dan sempadan metrik
Sahkan bahawa SLI datang daripada perjalanan pengguna sebenar dan merangkumi klien, kebergantungan (dependencies), serta aliran kerja kritikal. Asingkan kegagalan permintaan, pendam (latency), data yang salah dan ketidaktersediaan; satu purata sahaja boleh menyembunyikan tail latency atau impak teruk pada satu kelas pelanggan tertentu.
Tempoh belanjawan dan kadar pembakaran (burn rate)
Jelaskan sama ada belanjawan adalah secara bulanan, suku tahunan atau bergolek (rolling), berserta kadar pembakaran semasa dan ketidakpastian. Baki belanjawan sepatutnya menjawab "berapa lama kita boleh mengekalkan keadaan ini?" dan bukannya sekadar menunjukkan peratusan.
Nilai dan risiko pelepasan
Nilaikan hasil, pematuhan dan nilai keselamatan. Bolehkah ciri tersebut diuji melalui canary, di-rollback atau dihadkan kepada penyewa (tenant) terpilih? Tanpa nilai yang boleh disahkan dan laluan pemulihan, desakan pelanggan bukanlah bukti risiko.
Jawapan 30 saat
"Mula-mula saya mengesahkan SLI pihak pengguna, tempoh SLO dan kadar pembakaran, bagi menyemak sama ada isyarat itu berterusan atau ralat instrumentasi. Jika belanjawan benar-benar habis, saya menjeda pelepasan bukan penting dan mengarahkan kapasiti serta usaha kejuruteraan untuk memulihkan SLO, membetulkan punca masalah dan mengesahkan pemantauan. Perubahan keselamatan, pematuhan atau mitigasi insiden boleh menjadi pengecualian sekiranya ia berskala kecil, boleh diterbalikkan (reversible) dan mempunyai pemilik yang jelas. Bagi ciri pelanggan utama, saya akan mencari pengasingan penyewa atau canary yang tertangguh, kemudian menggunakan semakan risiko untuk memutuskan sama ada hendak diteruskan. Sebaik sahaja margin belanjawan yang dipersetujui kembali, saya akan membuka semula pelepasan secara beransur-ansur dan menyemak sama ada SLO mewakili nilai pengguna."
Penyelesaian langkah demi langkah
Langkah 1: Takrifkan SLI sebagai hasil pengguna
Takrifkan kadar kejayaan, pendam hujung-ke-hujung dan ketepatan untuk aliran kerja kritikal, menggunakan data klien atau edge jika boleh. Nyatakan perkara yang dikira sebagai permintaan sah, tempoh penyelenggaraan dan pembahagian penyewa. Jika pengguna mementingkan penyiapan eksport, wujudkan SLI penyiapan tugas dan bukannya bergantung pada respons API 200 semata-mata.
Langkah 2: Kira belanjawan dan kadar pembakaran
Sasaran ketersediaan 99.99% membenarkan nisbah kegagalan 0.01% dalam tempoh yang dipilih; jumlah minit bergantung pada tempoh dan kaedah pengiraan. Gunakan satu pertanyaan (query) untuk mengira baki belanjawan, kadar pembakaran dan ketidakpastian, serta labelkan kelewatan data. Sebelum bertindak atas sebarang anomali, periksa pengiraan berganda, telemetri yang hilang dan atribusi kebergantungan.
Langkah 3: Wujudkan gerbang pelepasan (release gates)
Apabila belanjawan sihat, pelepasan biasa masih memerlukan rollback dan pemantauan. Apabila ia menghampiri kehabisan, tingkatkan tahap semakan serta kurangkan pendedahan kelompok (batch) dan canary. Sebaik sahaja habis, bekukan perubahan bukan penting; benarkan pembetulan insiden, kerja integriti data, keselamatan kritikal atau perubahan pematuhan dengan bukti rollback sahaja. Selitkan gerbang ini dalam peralatan (tooling) dan matriks tanggungjawab dan bukannya bergantung pada persetujuan lisan.
Langkah 4: Nilaikan pengecualian
Bagi setiap pengecualian, rekodkan manfaat pengguna, risiko, penyewa yang terdedah, peratusan, syarat rollback dan tempoh pemerhatian. Pengasingan kepada satu penyewa, trafik bayangan (shadow traffic) atau pengguna dalaman ialah bukti yang berguna. Produk, pemilik perubahan dan SRE meluluskan bersama; janji jualan semata-mata tidak boleh menentukan keputusan.
Langkah 5: Pulihkan kebolehpercayaan sebelum mengejar kesempurnaan
Sepanjang pembekuan, selesaikan punca utama, had kapasiti dan jurang pemantauan, berserta SLO pemulihan, margin belanjawan dan tarikh akhir. Jika sasaran memaksa usaha luar biasa berpanjangan, laraskannya semasa semakan, tetapi jangan ubah tempoh atau mengecualikan kegagalan selepas peristiwa berlaku semata-mata untuk membolehkan pelepasan.
Langkah 6: Berkomunikasi dengan pelanggan dan pasukan
Terangkan aliran kerja yang terjejas, julat masa, mitigasi dan kemas kini seterusnya. Tawarkan alternatif atau jadual yang boleh disahkan untuk ciri pelanggan; jangan menjanjikan masa pemulihan yang tidak disahkan. Gunakan satu papan pemuka belanjawan, garis masa insiden dan senarai pemilik secara dalaman untuk mengurangkan rundingan politik antara produk dan kejuruteraan.
Langkah 7: Tadbir urus pemulihan
Apabila belanjawan mencapai ambang yang dipersetujui, buka semula pelepasan secara berperingkat, bermula dengan kelompok kecil. Semak perubahan yang gagal, kelewatan pengesanan, tempoh rollback dan impak kepada pelanggan. Jika SLO tidak mewakili nilai pengguna, cadangkan perubahan yang disokong data. Simpan rekod pembekuan, pengecualian, kelulusan dan hasil untuk semakan risiko suku tahunan.
Jawapan contoh berkualiti tinggi
Saya tidak akan membuat keputusan mutlak berdasarkan "jualan adalah mendesak" atau "belanjawan adalah sifar". Saya akan mengesahkan SLI pihak pengguna, tempoh statistik, integriti data dan kadar pembakaran, bagi mengecualikan ralat instrumentasi dan pengiraan berganda. Jika belanjawan benar-benar habis, saya akan membekukan pelepasan bukan penting dan melabur dalam pemulihan, pembetulan serta pemantauan. Keselamatan, pematuhan, pembaikan data dan mitigasi insiden boleh memohon pengecualian.
Sekiranya ciri pelanggan utama mesti diteruskan, saya akan mengasingkan penyewa, menggunakan canary kecil, menambah rollback automatik dan mentakrifkan tempoh pemerhatian. Produk, pemilik perubahan dan SRE akan meluluskan bersama dengan manfaat, risiko dan syarat henti direkodkan. Selepas belanjawan pulih, saya akan menarik balik pembekuan secara beransur-ansur dan menyemak sama ada SLO mengukur hasil pengguna sebenar sebelum mengubah sasaran atau proses.
Kesilapan lazim
- Kesilapan: Membekukan setiap perubahan selepas belanjawan habis. → Sebab ia gagal: Keselamatan, pembaikan data dan mitigasi insiden mungkin tertangguh. → Penyelesaian: Takrifkan pengecualian yang terhad, pihak yang meluluskan dan bukti rollback.
- Kesilapan: Menggunakan purata pendam pelayan sahaja. → Sebab ia gagal: Ia terlepas kegagalan klien, tail latency dan pengalaman penyewa utama. → Penyelesaian: Takrifkan SLI hujung-ke-hujung daripada perjalanan pengguna.
- Kesilapan: Mengubah tempoh SLO atau mengecualikan kegagalan semata-mata untuk melepaskan ciri. → Sebab ia gagal: Belanjawan kehilangan kebolehbandingan dan menyembunyikan risiko. → Penyelesaian: Kekalkan tempoh semasa dan gunakan tadbir urus rasmi untuk perubahan seterusnya.
- Kesilapan: Menganggap satu canary yang berjaya sebagai bukti pelepasan penuh. → Sebab ia gagal: Pendedahan, kebergantungan dan tail risk adalah berbeza. → Penyelesaian: Kembangkan secara beransur-ansur dengan rollback automatik.
Soalan susulan dan respons
Soalan susulan 1: Berapakah jumlah belanjawan yang diwakili oleh 99.99%?
Nisbah kegagalan yang dibenarkan dalam tempoh yang dipilih ialah 0.01%. Penukaran kepada minit memerlukan tempoh, kaedah pengiraan, dan sama ada metrik berasaskan permintaan atau masa. Perkara penting adalah menyatakan tempoh tersebut dan bukannya mengemukakan nombor tanpa syarat.
Soalan susulan 2: Adakah ciri yang dijanjikan oleh jualan merupakan pengecualian?
Nilai komersial semata-mata tidak memberikan pengecualian. Tunjukkan impak pengguna, hasil atau pematuhan; sediakan bukti pengasingan, canary, rollback dan pemerhatian; serta dapatkan kelulusan bersama. Jika pendedahan tidak dapat dikurangkan, tangguhkan ciri tersebut dan tawarkan alternatif.
Soalan susulan 3: Bagaimana jika pengiraan belanjawan mungkin salah?
Bekukan pelepasan berisiko tinggi sambil menyemak liputan telemetri, pengiraan berganda, kelewatan masa, atribusi kebergantungan dan sampel klien secara serentak. Kira semula selepas pembetulan, tetapi jangan luaskan pendedahan selagi keputusannya belum pasti.
Soalan susulan 4: Bilakah SLO patut diubah?
Ubahnya apabila operasi yang stabil dan data semakan menunjukkan bahawa sasaran tidak sepadan dengan nilai pengguna, kos atau keupayaan. Rekodkan sasaran lama, sasaran baharu, impak dan pihak yang meluluskan terlebih dahulu. Gangguan perkhidmatan (outage) atau tekanan pelepasan bukanlah alasan untuk menurunkan sasaran secara ad-hoc.
Soalan susulan 5: Bagaimanakah anda tahu bahawa pembekuan telah tamat?
Takrifkan syarat pemulihan terlebih dahulu: SLI memenuhi sasaran untuk tempoh pemerhatian, belanjawan telah dibina semula ke tahap ambang tertentu, pembetulan punca utama telah disahkan, dan fungsi rollback beroperasi. Kemudian mulakan dengan kelompok kecil dan teruskan pemantauan dan bukannya terus kembali kepada kelajuan penuh serta-merta.