Matematika Ketersediaan

Sembilan ketersediaan, SLA/SLO/SLI, dan error budget sebagai anggaran kegagalan.

Daftar isi

Topik ini membahas matematika yang mendasari klaim ketersediaan, yaitu cara ketersediaan antarkomponen terakumulasi menjadi ketersediaan sistem, perbedaan SLA (service level agreement), SLO, dan SLI, serta aritmetika anggaran error (error budget) sebagai anggaran kegagalan. Pembahasan bergerak dari ketersediaan satu komponen ke sistem yang tersusun seri dan paralel, lalu menutup dengan perhitungan anggaran berdasarkan skrip Python yang dapat dijalankan ulang. Setelah membacanya, target seperti tiga sembilan dapat dilacak dampaknya sampai ke jumlah waktu kegagalan yang masih boleh terjadi dalam satu bulan.

Ketersediaan sebagai peluang#

Ketersediaan menyatakan peluang sebuah layanan merespons dengan benar pada rentang waktu tertentu, dinyatakan sebagai pecahan antara nol dan satu. Layanan dengan ketersediaan 99,9% gagal merespons kira-kira satu dari seribu kejadian, dan angka itu lazim disebut tiga sembilan. Setiap sembilan tambahan memangkas peluang kegagalan sepuluh kali lipat, sehingga lompatan antartarget tidak pernah kecil. Konversi setiap target sembilan menjadi menit waktu henti per bulan sudah dihitung pada topik Kebutuhan Nonfungsional, sehingga pembahasan di sini bekerja langsung pada angka peluangnya.

Satu asumsi menopang seluruh perhitungan pada topik ini, yaitu kegagalan antarkomponen saling bebas. Asumsi ini jarang sepenuhnya benar di lapangan karena banyak komponen berbagi listrik, jaringan, atau rilis perangkat lunak yang sama. Meskipun begitu, aritmetika kebebasan tetap berguna sebagai alat perbandingan pilihan desain sebelum pengukuran nyata menyusul, sedangkan kegagalan yang saling berkaitan dibahas terpisah pada topik Redundansi dan Domain Kegagalan. Angka yang dihasilkan asumsi ini tetap bermanfaat sebagai perkiraan awal, bukan sebagai janji yang dikutip apa adanya.

Ketersediaan sistem gabungan#

Pengguna tidak melihat ketersediaan tiap komponen, melainkan ketersediaan seluruh alur permintaan dari browser sampai basis data. Bentuk penyusunannya menentukan rumusnya. Apabila permintaan melewati beberapa komponen secara berurutan, sistem hanya bekerja bila semuanya bekerja, sehingga ketersediaan gabungan merupakan hasil kali ketersediaan masing-masing:

P_{\text{seri}} = p_1 \times p_2 \times \cdots \times p_k

Konsekuensinya terasa cepat, yaitu ketersediaan rangkaian selalu lebih rendah daripada komponen terlemahnya karena setiap komponen membawa peluang kegagalan baru. Kegagalan satu komponen pada rangkaian membuat permintaan gagal, sedangkan kegagalan satu replika pada susunan paralel hanya memindahkan permintaan ke replika lain yang hidup. Sebaliknya, apabila satu komponen diduplikasi menjadi $n$ replika yang setara dan cukup satu replika yang hidup, ketersediaannya adalah satu dikurangi peluang seluruh replika gagal bersamaan:

P_{\text{paralel}} = 1 - (1-p)^n

Skrip berikut menghitung kedua bentuk pada komponen yang sama, yaitu tiga layanan berurutan dengan ketersediaan masing-masing 99,9% dibandingkan tiga replika paralel dengan ketersediaan yang sama.

python ketersediaan_gabungan.py

ketersediaan_satu_layanan = 0.999

# rangkaian seri: permintaan melewati tiga layanan secara berurutan
seri = ketersediaan_satu_layanan ** 3
print(f"Seri    (3 layanan, 99,9% masing-masing): {seri:.6f}")

# paralel: tiga replika identik, cukup satu yang hidup
p = ketersediaan_satu_layanan
n = 3
paralel = 1 - (1 - p) ** n
print(f"Paralel (3 replika, 99,9% masing-masing): {paralel:.9f}")

text Keluaran

Seri    (3 layanan, 99,9% masing-masing): 0.997003
Paralel (3 replika, 99,9% masing-masing): 0.999999999

Keluaran memperlihatkan dua arah yang bertolak belakang dari komponen yang persis sama. Rangkaian tiga layanan menurunkan ketersediaan dari 99,9% menjadi 99,7003%, yang berarti kegagalan menjadi hampir tiga kali lebih sering dibandingkan satu layanan saja. Tiga replika paralel justru menaikkan ketersediaan menjadi 0,999999999 karena peluang ketiganya mati pada saat yang sama sangat kecil. Sistem nyata adalah campuran keduanya, yaitu rangkaian layanan yang masing-masing direplikasi, sehingga desain yang baik memperpendek rangkaian sekaligus menambah replika pada komponen yang menjadi penghambat.

SLI, SLO, dan SLA#

SLI dan SLO sudah diperkenalkan pada topik Kebutuhan Nonfungsional, dengan SLI sebagai metrik yang diukur langsung dari sistem dan SLO sebagai target berangka yang dipilih untuk metrik itu. Tingkat yang belum dibahas adalah SLA, yaitu janji kinerja layanan yang ditujukan kepada pengguna luar beserta konsekuensi yang menyertainya, misalnya kredit layanan apabila janji dilanggar. Ketiganya tersusun dari dalam ke luar. SLI menyediakan datanya, SLO menetapkan sasaran kerja tim, sedangkan SLA menerima sebagian kecil ruang kegagalan dari SLO untuk menutup risiko kontrak.

Tingkatan itu juga menentukan siapa yang berbicara dengan angka mana pada saat kejadian. Insinyur pemantauan membaca SLI untuk melihat keadaan sebenarnya, manajemen menilai SLO untuk memutuskan prioritas perbaikan, sedangkan pelanggan hanya berinteraksi dengan SLA ketika penalti ditanyakan. Satu SLA dapat mencakup beberapa SLO, dan setiap SLO dapat diukur dari beberapa SLI, sehingga hubungan ketiganya berbentuk piramida yang menyempit ke arah luar. Tabel berikut merangkum perbedaan ketiganya.

Tingkat	Bentuk	Pemegang	Contoh
SLI	metrik terukur	hasil pengukuran	persentil p99 durasi permintaan
SLO	target internal	tim layanan	p99 di bawah 300 ms selama 30 hari
SLA	janji kepada pengguna	perusahaan kepada pelanggan	p99 di bawah 400 ms dengan kredit bila dilanggar

Anggaran error sebagai anggaran kegagalan#

Anggaran error adalah sisa ketahanan yang boleh digunakan sebelum perubahan baru dihentikan, dan nilainya diperoleh dari selisih antara satu dan SLO pada periode pengukuran. Untuk SLO 99,9% dalam 30 hari, anggarannya adalah 0,1% dari 43200 menit, yaitu 43,2 menit waktu henti. Anggaran yang sama dapat dibaca dalam satuan permintaan, misalnya 0,1% dari seluruh permintaan bulan itu, sehingga satu anggaran berlaku untuk kegagalan durasi maupun kegagalan permintaan. Satu perbedaan yang perlu dijaga adalah periode pengukurannya, karena anggaran bulanan menyerap insiden kecil lebih baik daripada anggaran mingguan yang tipis. Skrip berikut menghitung sisa anggaran setelah satu insiden memakan dua belas menit.

python anggaran_error.py

slo = 0.999            # target SLO bulanan
periode_hari = 30

total_menit = periode_hari * 24 * 60
anggaran_menit = (1 - slo) * total_menit
terpakai_menit = 12
sisa_menit = anggaran_menit - terpakai_menit

print("Total menit dalam 30 hari:", total_menit)
print(f"Error budget: {anggaran_menit:.1f} menit")
print(f"Terpakai: {terpakai_menit} menit, sisa: {sisa_menit:.1f} menit")

text Keluaran

Total menit dalam 30 hari: 43200
Error budget: 43.2 menit
Terpakai: 12 menit, sisa: 31.2 menit

Keluaran menunjukkan bahwa satu insiden dua belas menit sudah memakan hampir 28% anggaran bulanan. Angka sisa 31,2 menit inilah yang menentukan keputusan rilis, bukan kesan apakah sistem sedang sehat. Tim yang menggunakan anggaran error secara konsisten memperlambat rilis ketika sisa anggaran tipis dan mempercepatnya ketika anggaran masih besar, sehingga perdebatan antartim berubah dari opini menjadi pembacaan angka.

Kesalahan umum#

Menghitung ketersediaan rangkaian dengan rata-rata. Rata-rata tiga layanan 99,9% tetap 99,9%, sedangkan nilai yang benar adalah hasil kalinya, yaitu 99,7003%. Perbaikannya, kalikan ketersediaan setiap komponen pada jalur permintaan, lalu simpan hasilnya sebagai dasar perbandingan desain.
Menyamakan target internal dengan janji kontrak. SLO yang diset sama dengan SLA menghapus ruang penyangga, sehingga satu kegagalan kecil langsung menimbulkan penalti kontrak. Perbaikannya, buat SLA selalu lebih longgar daripada SLO dan tinjau jarak keduanya pada setiap periode.
Memperlakukan anggaran error sebagai izin gagal. Anggaran yang tersisa bukan target untuk dihabiskan, melainkan sumber daya untuk rilis dan eksperimen. Perbaikannya, pantau laju penggunaannya per minggu, bukan hanya sisanya pada akhir bulan.

Ringkasan#

Ketersediaan rangkaian seri merupakan hasil kali ketersediaan komponennya, sedangkan $n$ replika paralel yang saling bebas mengikuti rumus $1-(1-p)^n$ .
SLI, SLO, dan SLA tersusun dari dalam ke luar, yaitu metrik terukur, target internal, lalu janji kontrak yang lebih longgar.
Anggaran error dihitung dari selisih satu dengan SLO dikalikan ukuran periode, dan sisanya yang memutuskan ritme rilis, bukan kesan apakah sistem sedang sehat.

Referensi#

Service Level Objectives — Google SRE Book — Bab yang mendefinisikan SLI, SLO, dan anggaran error beserta perbedaannya dengan SLA.
Implementing SLOs — Google SRE Workbook — Panduan memilih SLI, menetapkan target, dan menjalankan kebijakan anggaran error.