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
Anthos Service Mesh mendukung jenis indikator tingkat layanan berikut:
- Latensi: Waktu yang dibutuhkan layanan untuk menampilkan respons terhadap permintaan, yang 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 diinginkan dari layanan. Secara umum, SLO tidak boleh lebih tinggi dari yang diperlukan atau bermakna bagi pengguna Anda. Pertimbangkan pada titik mana 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 akan lebih mahal untuk dipenuhi, dan pengguna Anda tidak akan menyadari perbedaannya.
Saat Anda 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 periode waktu saat SLI diukur. Misalnya, ketersediaan 99% dalam satu hari berbeda dari ketersediaan 99% selama sebulan. SLO pertama tidak akan mengizinkan periode nonaktif berturut-turut lebih dari 14 menit (24 jam * 1%), sedangkan SLO kedua akan memungkinkan 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 terpenuhi. Terlepas dari apakah SLA dengan pengguna Anda merupakan keputusan produk atau bisnis, tetapi untuk tujuan pemantauan, Anda masih perlu menentukan periode kepatuhan untuk SLO saat membuatnya.
Saat mengonfigurasi SLO, Anda dapat memilih jenis periode kepatuhan:
Kalender: Bila Anda memilih Kalender sebagai Jenis Periode, Anda juga menentukan Panjang Menstruasi, yang dapat berupa hari, minggu, atau bulan. Periode tidak tumpang tindih dan ditetapkan ke tanggal mulai dan akhir kalender. Kepatuhan hanya dapat dievaluasi di akhir periode.
Rolling: Saat memilih Rolling sebagai Period Type, Anda juga menentukan jumlah hari untuk Period Length, misalnya, 30 hari. Tidak seperti periode Kalender, periode yang berkelanjutan tidak memiliki tanggal mulai dan akhir yang tetap. Anthos 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 mendapatkan ukuran kepatuhan selama 30 hari terakhir, bukan satu per bulan. Namun, layanan dapat berada di antara kepatuhan dan ketidakpatuhan karena status SLO berubah setiap hari.
Anggaran error
Konsep pemantauan penting lainnya
adalah anggaran {i>error<i}. SLO menetapkan SLI dan nilai target yang mengukur keberhasilan layanan dalam periode kepatuhan. Anggaran error untuk SLO mewakili jumlah total waktu ketidakpatuhan layanan sebelum melanggar SLO-nya. Dengan demikian, anggaran error adalah 100% - SLO%
. Misalnya, jika Anda memiliki SLO ketersediaan 30 hari yang bergulir dengan target kepatuhan 99,99%, anggaran error Anda adalah 0,01% dari 30 hari: periode nonaktif yang diizinkan hanya lebih dari 4 menit 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 men-deploy versi baru. Saat anggaran error hampir habis, ini 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 luncurkan 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, sehingga memicu pelanggaran SLO saat anggaran error turun di bawah 0. Anthos Service Mesh mereset anggaran error SLO pada akhir periode kepatuhan.
Jika Anda mengukur SLO selama periode kepatuhan berkelanjutan, secara efektif Anda 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 diluncurkan dari jendela kepatuhan, dan jika SLO memenuhi syarat, anggaran error akan naik. Kapan saja, error budget ≥ 0
menunjukkan jendela SLO bergulir yang sesuai, dan
error budget < 0
menunjukkan jendela SLO bergulir yang tidak mematuhi kebijakan.
Langkah selanjutnya
Pelajari SLO dari Site Reliability Engineering di Google lebih lanjut: