Gesaan dan masa ia terpakai
Penemu duga mungkin bertanya, “Dalam reka bentuk sistem, bagaimanakah anda akan menggunakan belanjawan ralat untuk mengimbangi kebolehpercayaan dan kelajuan keluaran?” Anda mesti menerangkan cara SLI, SLO dan belanjawan ralat mempengaruhi keluaran, pengunduran (rollback), kapasiti dan penyelarasan pasukan. Ini sesuai untuk temu duga SRE, platform, bahagian belakang (backend) dan reka bentuk sistem kanan yang melibatkan ketersediaan tinggi, keluaran kerap atau kebergantungan berbilang pasukan.
Perkara yang dinilai oleh penemu duga
Ujian ini bukan tentang sama ada anda boleh menghafal 99.99%. Ia adalah tentang sama ada anda boleh mengubah matlamat pengalaman pengguna menjadi peraturan keputusan operasi. Google SRE menerangkan belanjawan ralat sebagai ruang baki di bawah SLO, yang digunakan untuk menyelaraskan kerja kebolehpercayaan dan inovasi; apabila belanjawan habis dibelanjakan, perubahan biasa dijeda sementara kebolehpercayaan dipulihkan. Penemu duga juga mencari tetingkap pengukuran, kualiti data, penghantaran progresif dan pengecualian yang boleh diaudit.
Soalan penjelasan untuk ditanya kepada diri sendiri
Jelaskan siapa pengguna, perjalanan (journey) mana yang penting, di mana sempadan perkhidmatan terletak, dan sama ada matlamatnya adalah ketersediaan, kependaman (latency), kesegaran (freshness) atau ketepatan. Sahkan tetingkap SLO, wilayah, pemilikan kebergantungan dan keupayaan rollback. Jika nombor tidak disediakan, nyatakan andaian seperti tetingkap empat minggu, ketersediaan 99.9% dan pengukuran mengikut permintaan pengguna yang sah.
Kerangka jawapan 30 saat
Gunakan lima langkah:
- Tentukan SLI dan SLO yang boleh dilihat oleh pengguna.
- Kira belanjawan ralat bagi tetingkap tersebut dan terangkan perkara yang menggunakannya.
- Hubungkan belanjawan kepada penghantaran progresif, rollback automatik dan get perubahan.
- Apabila belanjawan habis, bekukan perubahan biasa dan biayai kerja kebolehpercayaan, dengan pengecualian eksplisit untuk keselamatan dan pembaikan mendesak.
- Gunakan postmortem, atribusi kebergantungan dan trend belanjawan untuk melaraskan kitaran perancangan seterusnya.
Jawapan mendalam langkah demi langkah
1. Tentukan SLI daripada hasil pengguna
Jangan gunakan CPU pelayan atau purata kependaman sebagai sasaran kebolehpercayaan secara lalai. Untuk perkhidmatan berasaskan permintaan, pilih bahagian permintaan yang berjaya dan permintaan di bawah ambang kependaman; untuk kerja tak segerak (asynchronous), gunakan penyiapan tepat pada masanya atau kesegaran hasil. Asingkan kegagalan yang memberi kesan kepada pengguna daripada percubaan semula dalaman dan trafik tidak sah supaya hingar (noise) tidak menggunakan belanjawan.
2. Pilih SLO dan tetingkap yang boleh dijelaskan
Sebagai contoh, 99.9% permintaan sah yang berjaya dalam tempoh empat minggu membenarkan kira-kira 0.1% gagal. Tetingkap mengawal kepekaan terhadap insiden pendek dan trend panjang. Dengan berbilang SLO, nyatakan peraturan gabungan: perjalanan pengguna kritikal boleh menyekat keluaran, manakala metrik sekunder memberi maklumat kepada amaran dan perancangan. Jangan puratakan peratusan tanpa menerangkan populasi dan pemberat.
3. Atribusikan penggunaan belanjawan kepada perubahan
Catat jumlah belanjawan, kadar penggunaan (burn rate) dan punca. Tag keluaran, konfigurasi, kegagalan kebergantungan, kekurangan kapasiti dan positif palsu secara berasingan. Hanya atribusi yang boleh dipercayai yang memberitahu pasukan sama ada perlu membetulkan kod, menambah kapasiti, menukar kontrak kebergantungan atau membaiki pemantauan. Contoh dasar Google juga membezakan kegagalan dalam perkhidmatan, kegagalan yang dimiliki oleh pasukan lain dan trafik di luar skop SLO.
4. Reka bentuk get keluaran dan rollback progresif
Hantar perubahan biasa kepada sebahagian kecil trafik atau satu wilayah, perhatikan kadar ralat, kependaman dan burn rate, kemudian kembangkan. Get harus menyemak kedua-dua baki belanjawan dan burn rate tetingkap pendek; purata bulanan yang selamat boleh menyembunyikan insiden yang memburuk dengan cepat. Apabila tingkah laku tidak dijangka, lakukan rollback sebelum mendiagnosis untuk mengurangkan masa pemulihan. Rollback juga memerlukan keidempotanan (idempotency) dan keserasian data.
5. Tentukan perkara yang berlaku selepas belanjawan habis dibelanjakan
Menghabiskan belanjawan tidak bermakna pembangunan berhenti selama-lamanya. Bekukan ciri biasa dan perubahan data yang tidak penting, kemudian utamakan kapasiti, ujian, pengasingan kebergantungan, degradasi anggun (graceful degradation) dan pembaikan punca utama. Pembaikan keselamatan dan kecacatan mendesak yang menangani ketidaktercapaian SLO boleh menjadi pengecualian, tetapi rekod sebab, pelulus dan semakan susulan supaya "mendesak" tidak menjadi laluan pintas kekal.
6. Kendalikan kebergantungan dan pemilikan merentas pasukan
Jangan sembunyikan setiap kegagalan luaran di dalam SLO perkhidmatan. Jejaki ralat kebergantungan, klien dan perkhidmatan secara berasingan, dan jelaskan pemilikan pembaikan serta komunikasi. Apabila pasukan tidak bersetuju tentang peraturan belanjawan, selaraskan pada perjalanan pengguna dan pengukuran bersama, kemudian eskalasikan melalui pemilik perkhidmatan. Memindahkan kesalahan bukanlah strategi kebolehpercayaan.
Contoh jawapan berkualiti tinggi
Jawapan rekaan ini mesti digantikan dengan nombor dan sempadan anda sendiri:
Saya akan menentukan SLI kadar kejayaan dan kependaman untuk permintaan pengguna yang paling penting. Andaikan SLO kejayaan permintaan sah ialah 99.9% dalam tempoh empat minggu, jadi belanjawan ralat ialah 0.1% daripada permintaan yang sah. Pemantauan menunjukkan baki belanjawan, burn rate satu jam dan atribusi kegagalan, tidak termasuk trafik di luar sempadan perkhidmatan. Keluaran bermula di satu wilayah pada sebahagian kecil trafik dan berkembang secara beransur-ansur; melepasi ambang burn rate akan menghentikan pelancaran dan mencetuskan rollback. Selagi belanjawan sihat, produk dan SRE boleh menghantar dalam lingkungan risiko yang dibenarkan. Selepas ia habis, perubahan biasa dibekukan dan pasukan mengutamakan kapasiti, ujian, pengasingan kebergantungan dan pembaikan punca utama, dengan pengecualian yang dilog untuk kerja keselamatan. Setiap insiden mendapat semakan tanpa menyalahkan (blameless review) dan pembaikan dimasukkan ke dalam kitaran perancangan seterusnya. Oleh itu, kelajuan keluaran dikawal oleh baki belanjawan dan risiko yang diperhatikan dan bukannya mengikut keutamaan subjektif.
Kesilapan biasa
Menganggap belanjawan ralat sebagai kebenaran untuk menyebabkan kegagalan
Belanjawan mewakili ruang kegagalan yang boleh bertolak ansur dengan pengguna, bukan kuota untuk mencipta insiden. Terangkan kesan pengguna, tetingkap, burn rate dan pemilikan pembaikan.
Hanya memberikan nombor ketersediaan
Tanpa SLI, populasi dan tetingkap, 99.99% tidak boleh membimbing keputusan. Tambahkan permintaan yang sah, kependaman atau kesegaran, dan peraturan untuk mengecualikan trafik yang tidak berkaitan.
Membekukan keluaran selama-lamanya selepas terlepas belanjawan
Tindakan itu mengabaikan pembaikan keselamatan, migrasi dan kerja pemulihan. Tentukan pengecualian, kelulusan, rollback dan semakan supaya pengecualian tidak menjadi laluan lalai.
Mengabaikan penghantaran progresif dan keserasian rollback
"Pantau dan lepas" tidak mencukupi. Terangkan peringkat trafik, syarat henti automatik, susunan rollback dan keserasian antara bacaan dan tulisan lama serta baharu.
Soalan susulan dan amalan lanjutan
SLO sihat, tetapi burn rate satu jam adalah tinggi. Adakah anda akan melancarkan keluaran?
Bandingkan baki tetingkap panjang dengan trend tetingkap pendek. Jika penggunaan berterusan, hentikan peluasan trafik, sahkan sama ada ia adalah kesan pengguna sebenar, lonjakan trafik atau kecacatan pemantauan, dan kemudian tentukan sama ada perlu melakukan rollback.
Kebergantungan luaran menghabiskan belanjawan. Patutkah pasukan anda turut membekukan keluaran?
Semak sama ada komitmen perkhidmatan termasuk kegagalan kebergantungan tersebut, kemudian buat keputusan daripada perjalanan pengguna. Lindungi pengguna dan dayakan degradasi walaupun pemilikan adalah luaran; peraturan pembekuan harus dipersetujui terlebih dahulu dengan perkongsian bukti dan eskalasi.
Beberapa SLO gagal serentak. Bagaimanakah anda mengutamakan?
Kedudukan mengikut perjalanan pengguna kritikal, radius letupan (blast radius), burn rate dan kebolehbalikan (reversibility). Atasi penunjuk yang boleh meluaskan insiden atau menyekat pemulihan terlebih dahulu, kemudian isu prestasi setempat, dan nyatakan pertukaran (tradeoff).
Pengurus produk meminta anda mengeluarkan keluaran selepas belanjawan habis. Bagaimanakah anda bertindak balas?
Tukarkan perdebatan kepada data: tunjukkan baki belanjawan, kesan pengguna, kos rollback dan masa pembaikan. Tawarkan eksperimen kecil atau penangguhan. Jika kecemasan perniagaan yang tulen kekal, gunakan pengecualian yang direkodkan sepenuhnya dan jadualkan kerja kebolehpercayaan serta semakan.