Merancang SLO

Halaman ini memberikan informasi yang mungkin Anda perlukan sebelum membuat tujuan tingkat layanan (SLO).

Untuk mempelajari pengantar SLO, lihat Ringkasan tujuan tingkat layanan.

Jenis SLI dan target kepatuhan

Cloud Service Mesh mendukung jenis indikator tingkat layanan berikut:

  • Latensi: Waktu yang diperlukan layanan untuk menampilkan respons terhadap permintaan, yang diukur dalam milidetik.
  • Ketersediaan: Persentase waktu layanan merespons dengan berhasil.
  • Lainnya: Jenis SLO yang dapat disesuaikan berdasarkan metrik yang dapat dikonfigurasi.

Anda juga menentukan target kepatuhan yang diinginkan dari layanan Anda. Secara umum, SLO tidak boleh lebih tinggi dari yang diperlukan atau berarti bagi pengguna. Pertimbangkan kapan pengguna mungkin melihat penurunan layanan. Misalnya, jika pengguna tidak dapat membedakan antara latensi 300 md atau 500 md untuk layanan Anda, gunakan nilai yang lebih tinggi sebagai batas latensi di SLO. Nilai yang lebih rendah lebih mahal untuk dipenuhi, dan pengguna Anda tidak akan memperhatikan perbedaannya.

Saat menetapkan target kepatuhan, pertimbangkan persyaratan pengguna akhir untuk layanan Anda. Misalnya, alat internal yang digunakan karyawan untuk memesan waktu liburan mungkin dapat digunakan dengan target ketersediaan 99% (periode nonaktif (~3 hari per tahun). Namun, layanan penting untuk toko online mungkin memerlukan ketersediaan sebesar 99,999% (~5 menit periode nonaktif per tahun).

Periode kepatuhan

Selain menentukan target untuk SLI, SLO menentukan jangka waktu saat SLI diukur. Misalnya, ketersediaan 99% dalam satu hari berbeda dengan ketersediaan 99% selama sebulan. SLO pertama tidak akan mengizinkan periode nonaktif berturut-turut lebih dari 14 menit (24 jam * 1%), sedangkan SLO kedua akan mengizinkan periode nonaktif berturut-turut hingga ~7 jam (30 hari * 1%).

Periode kepatuhan sangat penting jika SLO disertakan dalam perjanjian tingkat layanan (SLA) dengan pengguna Anda. SLA adalah kontrak dengan pengguna layanan Anda yang biasanya menentukan konsekuensi jika SLO tidak dipenuhi. Baik Anda memiliki SLA dengan pengguna atau tidak merupakan keputusan produk atau bisnis, tetapi untuk tujuan pemantauan, Anda masih harus menentukan periode kepatuhan untuk SLO saat membuatnya.

Saat mengonfigurasi SLO, Anda dapat memilih jenis periode kepatuhan:

  • Kalender: Jika memilih Kalender sebagai Jenis Periode, Anda juga menentukan Panjang Periode, yang dapat berupa hari, minggu, atau bulan. Periode tidak tumpang-tindih dan tetap mengikuti tanggal mulai dan akhir kalender. Kepatuhan hanya dapat dievaluasi pada akhir periode.

  • Berkelanjutan: Jika memilih Rolling sebagai Jenis Periode, Anda juga menentukan jumlah hari untuk Panjang Periode, misalnya, 30 hari. Tidak seperti periode Kalender, periode yang berkelanjutan tidak memiliki tanggal mulai dan akhir yang tetap. Cloud Service Mesh terus mengevaluasi SLO dengan periode kepatuhan berkelanjutan. Data terlama dalam penghitungan sebelumnya akan keluar dari penghitungan saat ini karena diganti dengan data baru. Jangka waktu yang bergulir memberikan lebih banyak pengukuran kepatuhan karena setiap hari, Anda akan melihat ukuran kepatuhan selama 30 hari terakhir, bukan satu kali per bulan. Namun, layanan dapat berpindah-pindah antara kepatuhan dan ketidakpatuhan saat status SLO berubah setiap hari.

Anggaran error

Konsep pemantauan penting lainnya adalah anggaran {i>error<i}. SLO menentukan SLI dan nilai target yang mengukur keberhasilan layanan dalam periode kepatuhan. Anggaran error untuk SLO menunjukkan jumlah total waktu yang mungkin tidak dipatuhi layanan sebelum melanggar SLO-nya. Dengan demikian, anggaran error adalah 100% - SLO%. Misalnya, jika Anda memiliki SLO ketersediaan 30 hari yang berkelanjutan dengan target kepatuhan sebesar 99,99%, anggaran error Anda adalah 0,01% dari 30 hari: periode nonaktif yang diizinkan selama 30 hari lebih dari 4 menit. Layanan yang diperlukan untuk memenuhi SLO 100% tidak memiliki anggaran error.

Anggaran error memungkinkan Anda melacak jumlah pengukuran SLI buruk yang boleh terjadi selama sisa periode kepatuhan sebelum layanan melanggar SLO. Anda dapat menggunakan anggaran error untuk membantu mengelola tugas pemeliharaan seperti deployment versi baru. Saat anggaran error hampir habis, bukan waktu yang tepat untuk mengambil tindakan berisiko seperti men-deploy update baru. Sebaliknya, jika Anda memiliki anggaran error penuh menjelang akhir periode kepatuhan, sebaiknya peluncuran fitur baru karena risiko pelanggaran SLO lebih rendah.

Jika Anda mengukur SLO dengan periode kepatuhan kalender, Service Mesh memulai anggaran error pada nilai maksimum dan mengurangi anggaran seiring waktu, sehingga memicu pelanggaran SLO saat anggaran error turun di bawah 0. Cloud Service Mesh mereset anggaran error SLO pada akhir periode kepatuhan.

Jika Anda mengukur SLO selama periode kepatuhan berkelanjutan, Anda secara efektif selalu berada di akhir periode kepatuhan. Bukannya memulai dari awal, titik data lama akan terus berkurang dan titik data baru akan terus ditambahkan. Jika periode kepatuhan yang buruk berakhir, dan jika SLO mematuhi kebijakan, anggaran error akan meningkat. Kapan pun, error budget ≥ 0 menunjukkan periode SLO berkelanjutan yang mematuhi kebijakan, dan error budget < 0 menunjukkan periode SLO berkelanjutan yang tidak mematuhi kebijakan.

Langkah selanjutnya