Mendesain SLO

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

Untuk pengantar SLO, lihat Ringkasan tujuan tingkat layanan.

Jenis SLI dan target kepatuhan

Cloud Service Mesh mendukung jenis indikator tingkat layanan berikut:

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

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

Saat menetapkan target kepatuhan, pertimbangkan persyaratan pengguna akhir untuk layanan Anda. Misalnya, alat internal yang digunakan oleh karyawan untuk memesan waktu liburan mungkin tidak masalah dengan target ketersediaan 99% (~3 hari periode nonaktif per tahun). Namun, layanan penting untuk toko online mungkin memerlukan ketersediaan 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% selama 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 tidak memenuhi SLO. Memiliki SLA dengan pengguna atau tidak adalah keputusan produk atau bisnis, tetapi untuk tujuan pemantauan, Anda tetap perlu menentukan periode kepatuhan untuk SLO saat membuatnya.

Saat mengonfigurasi SLO, Anda memilih jenis periode kepatuhan:

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

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

Anggaran error

Konsep pemantauan penting lainnya adalah anggaran error. SLO menentukan SLI dan nilai target yang mengukur keberhasilan layanan dalam periode kepatuhan. Anggaran error untuk SLO mewakili jumlah total waktu layanan dapat tidak mematuhi SLO sebelum melanggar SLO. Dengan demikian, anggaran error adalah 100% - SLO%. Misalnya, jika Anda memiliki SLO ketersediaan 30 hari bergulir dengan target kepatuhan 99,99%, anggaran error Anda adalah 0,01% dari 30 hari: hanya lebih dari 4 menit periode nonaktif yang diizinkan setiap 30 hari. Layanan yang diperlukan untuk memenuhi SLO 100% tidak memiliki anggaran error.

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

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

Jika Anda mengukur SLO selama periode kepatuhan bergulir, Anda secara efektif selalu berada di akhir periode kepatuhan. Daripada memulai dari awal, titik data lama terus dihapus dan titik data baru terus ditambahkan. Jika periode kepatuhan yang buruk keluar dari periode kepatuhan, dan jika SLO mematuhi, anggaran error akan naik. Pada waktu apa pun, error budget ≥ 0 menunjukkan periode SLO rolling yang mematuhi kebijakan, dan error budget < 0 menunjukkan periode SLO rolling yang tidak mematuhi kebijakan.

Langkah selanjutnya