Tujuan tingkat layanan pemantauan cloud
Artikel ini adalah bagian dari seri dalam panduan pemantauan cloud.
Di bagian di bawah ini, Anda mempelajari tentang prinsip-prinsip dasar tujuan tingkat layanan, dan cara menerapkan dan menerapkannya.
Gambaran Umum
Tujuan tingkat layanan (SLA) adalah tujuan terukur untuk indikator tingkat layanan (SLI) utama yang berpusat pada pelanggan. Mereka mengukur pengalaman pelanggan Anda tentang beban kerja bisnis atau infrastruktur dan menentukan apakah penyedia layanan bisnis memenuhi janji yang dibuat dalam perjanjian tingkat layanan (SLA) yang dinegosiasikan secara resmi atau perjanjian informal antara semua pihak.
Sebagai broker layanan, Anda mengandalkan komitmen Microsoft terhadap keandalan layanan seperti yang didefinisikan dalam perjanjian tingkat layanan Microsoft untuk layanan Azure. Ini memungkinkan Anda untuk fokus pada tanggung jawab Anda dalam rantai layanan, seperti pemantauan sintetis, konektivitas jaringan, dan keamanan dan kepatuhan.
Terminologi
Di bawah ini adalah definisi untuk masing-masing istilah ini dan deskripsi singkat. Definisi ini diambil dari SRE Handbook Google.
| Persyaratan | Deskripsi |
|---|---|
| Perjanjian tingkat layanan (SLA) | Biasanya komitmen pengikatan antara penyedia layanan dan pelanggan. Perjanjian biasanya mencakup konsekuensi dari kehilangan target SLO . Aspek khusus dari layanan ini adalah kualitas, ketersediaan, dan tanggung jawab sebagaimana disepakati antara penyedia layanan dan konsumen layanan. |
| Pemantauan | Praktik pengumpulan data real-time kuantitatif tentang layanan dan sistem. |
| Metrik | Mengukur perilaku layanan yang relevan dan dapat diagregasi ke dalam indikator tingkat layanan (SLI), yang diproses dan diagregasi untuk mengukur status operasional layanan saat ini dan mengukur perilakunya. SLI adalah indikator utama dan real-time dari kesehatan layanan saat ini. |
| Log | Dimulai dengan kode dan melaporkan informasi tentang eksekusi individual jalur kode atau peristiwa diskrit. Gunakan informasi ini untuk membantu memecahkan masalah dan bekerja untuk mengidentifikasi akar masalah penyebab yang memengaruhi pengalaman pelanggan dan keandalan layanan yang diukur oleh SLI/SLA. |
| Tujuan tingkat layanan (SLO) | Nilai target untuk tingkat layanan, seperti yang diukur oleh indikator tingkat layanan (SLI), yang menetapkan harapan tentang seberapa baik performa layanan. SLO secara khusus melacak pengalaman pelanggan end-to-end. Untuk menetapkan SLA yang baik, Anda biasanya mulai dengan menentukan pengalaman yang diinginkan dan kemudian melengkapi kode layanan untuk mengukur pengalaman tersebut (mengumpulkan SLI yang relevan) dan menetapkan target bagaimana Anda memenuhi harapan pelanggan atau tidak. |
| Indikator tingkat layanan (SLI) | Metrik yang mengukur kualitas atau keandalan layanan. Minimal, empat SLI umum dievaluasi: ketersediaan, latensi, throughput, dan tingkat kesalahan. |
| Ketersediaan | Umumnya mengacu pada persentase waktu yang terukur atau dapat diamati suatu sistem beroperasi dan berfungsi. Anda mengukur ketersediaan sebagai target yang dihadapi pelanggan untuk kelangsungan pengalaman, yang dipengaruhi oleh satu atau beberapa masalah keandalan (dan mode kegagalan lainnya yang terkait dengan perubahan konfigurasi, pembaruan diterapkan, dan banyak lagi). |
| Anggaran kesalahan | Persentase buffer Anda yang tersisa mengenai SLO Anda. Anggaran kesalahan adalah alat DevOps, dan it menggunakan untuk menyeimbangkan keandalan layanan dengan kecepatan inovasi. |
Tujuan SLA
SLO melayani banyak tujuan penting dalam pengembangan dan operasi beban kerja cloud, termasuk:
- Mendekati real-time (NRT): Untuk memberikan tampilan NRT tentang kesehatan layanan seperti yang dialami oleh pelanggan.
- Mengurangi time-to-notify (TTN): Mendorong pemberitahuan otomatis masalah layanan kepada pelanggan, mengurangi waktu untuk memberi tahu (TTN) secara signifikan.
- Sinyal utama kepada pelanggan: Bertindak sebagai sinyal utama untuk operasi penyebaran, mendorong putar kembali otomatis jika masalah terjadi, sehingga mengekspos lebih sedikit pelanggan terhadap potensi masalah.
- Verifikasi perubahan: Berikan validasi bahwa perubahan mencapai peningkatan pengalaman pelanggan yang diharapkan.
- Tentukan prioritas: Bantu tim memahami apakah akan membangun fitur atau mengerjakan keandalan.
- Kondisi layanan wawasan: Mengaktifkan diskusi objektif dan berfokus pada pelanggan tentang kesehatan layanan.
- Mengurangi waktu untuk menganalisis: Mempercepat mitigasi dan analisis akar penyebab (RCA) masalah pelanggan dengan mengarahkan fokus ke layanan yang bertanggung jawab.
- Dependensi arsitektur: Bertindak sebagai input penting ke dalam keputusan arsitektur ketika layanan mengambil dependensi.
- Membangun kepercayaan: Memberikan pemahaman bersama tentang langkah-langkah kesehatan, yang membangun kepercayaan antar tim.
- Bawa transparansi: Mengekspos SLI yang sama dengan yang kami gunakan untuk menjalankan bisnis kami kepada pelanggan kami sehingga mereka dapat menjalankannya.
- Panel kaca tunggal: Aktifkan panel kaca tunggal horizontal untuk layanan & dependensi dan silo perinciannya.
Dengan menggunakan SLO untuk mendorong proses rekayasa Anda, DevOps dan TI bisa mendapatkan pemahaman awal tentang kesehatan aplikasi atau layanan infrastruktur yang mereka bangun atau migrasikan di Azure. Ini kemudian dapat digunakan untuk mendorong manusia dan keputusan otomatis yang perlu dibuat tentang keandalan layanan ini. Transformasi dalam praktik teknik ini akan secara signifikan berdampak pada keandalan layanan tersebut dalam jangka waktu dekat.
Bagaimana cara menentukan SCO?
Tujuan dari SLO adalah untuk mendapatkan sinyal yang jelas yang secara akurat mengukur kualitas dari perspektif pelanggan. Setiap tim layanan membuat serangkaian kecil Tujuan Tingkat Layanan (SLA) yang menentukan rentang yang diizinkan untuk metrik layanan terukur yang paling penting, seperti yang dialami oleh konsumen layanan. SLO adalah tujuan numerik yang ditentukan untuk metrik yang dipancarkan oleh layanan. Metrik yang terkait dengan tujuan ini dapat dipantau untuk menentukan apakah layanan sehat.
Misalnya, berikut adalah contoh SLO yang disederhanakan untuk aplikasi berbasis web pelacakan waktu internal - Permintaan dalam 5 menit terakhir dilayani dalam waktu di bawah 1000 milidetik pada persentil ke-99.
Metrik adalah agregasi data rangkaian waktu yang disebut Indikator Tingkat Layanan (SLI). Di mana SLI dikumpulkan sangat penting. Dalam contoh di atas, jika pelanggan berinteraksi dengan layanan menggunakan API, mengukur latensi sistem dan waktu untuk memproses permintaan adalah SLI yang akurat. Namun, jika pelanggan berinteraksi dengan layanan menggunakan portal web, maka total waktu untuk melayani permintaan juga harus menyertakan performa JavaScript halaman web.
Fokus bagi pemilik layanan adalah menentukan hal-hal berikut:
- Skenario mana yang merupakan indikator penting kesehatan layanan dari perspektif pelanggan,
- Tempat mengumpulkan SLI sehingga mereka sedekat mungkin dengan pengalaman pelanggan, dan
- Apa yang harus dilakukan SLA untuk SLI ini?
SLO dapat didefinisikan dengan pendekatan bertahap untuk mendorong pencapaian, atau ditentukan langsung oleh bisnis. Anda menggunakan SLO yang ditentukan oleh layanan untuk membuat keputusan arsitektur tentang cara Anda membangunnya. Oleh karena itu, penting untuk memilih skenario mana yang harus diukur dan jangka waktu apa yang harus diukur. Untuk meringkas, SLO terdiri dari nilai berikut:
- Sebuah SLI. Misalnya, proporsi permintaan yang cukup cepat, diukur dari load balancer, kurang dari 400 ms.
- Durasi. Periode waktu di mana metrik diukur.
- Target. Misalnya, persentase target permintaan cepat ke total permintaan (seperti 90%) yang Anda harapkan untuk dipenuhi selama durasi tertentu.
Jenis SLA
Jika Anda melihat di seluruh industri, ada dua jenis SLA:
SLA yang berfokus pada layanan - SLA ini adalah tujuan taktis yang ditentukan tim untuk meningkatkan kualitas layanan mereka dari waktu ke waktu secara bertahap. Mereka dirancang untuk menjadi tujuan pragmatis yang dapat dicapai dalam tonggak rekayasa. Misalnya, jika layanan saat ini mencapai ketersediaan 99,7%, tim dapat menetapkan tujuan untuk mencapai ketersediaan 99,9% pada kuartal berikutnya.
SLA yang berfokus pada pelanggan - SCO ini menentukan status atau tujuan masa depan yang ideal. Pada titik ini, investasi lebih lanjut dalam kualitas akan dianggap tidak perlu karena Anda sepenuhnya memenuhi harapan pelanggan.
Misalnya, jika pelanggan Anda mengharapkan bahwa layanan bisnis atau infrastruktur yang Anda operasikan memberikan ketersediaan 99,99%, dan layanan saat ini hanya mencapai ketersediaan 99,8%, SLO yang berentrik pelanggan masih 99,99%.
Menentukan SCO yang tepat membutuhkan waktu. Langkah pertama adalah berbicara dengan pelanggan Anda dan memahami apa yang diinginkan pengguna Anda dari layanan untuk mendapatkan beberapa pilihan indikator dan mendokumentasikannya. Pelajari skenario dan toleransi tentang bagaimana mereka menggunakan layanan Anda dan apa yang perlu dikirimkan layanan Anda untuk menjalankan bisnis mereka dengan sukses. Ini biasanya merupakan pengalaman berulang, dengan harapan mereka mulai dari saya menginginkan ketersediaan 100% dalam semua kondisi, tanpa dampak terhadap aliran pendapatan kami, melalui mengelola ekspektasi varian liar antara segmen pelanggan.
Pendekatan pemantauan yang hanya melihat kesehatan layanan (atau instans layanan) rentan terhadap masalah pengalaman pelanggan yang hilang di kedua ujung spektrum; kesehatan layanan tidak selalu berkorelasi dengan kualitas pengalaman pelanggan. Ini karena ada karakteristik perilaku yang berbeda antara layanan Azure PaaS dan SaaS, konfigurasi layanan Azure tersebut, bagaimana dan di mana (yaitu, wilayah mana) sumber daya mereka disebarkan, dan penambahan kode/logika kustom Anda, yang menambahkan kompleksitas lebih lanjut.
Saat menentukan SLO, penting untuk diingat bahwa penyedia cloud Anda adalah dependensi pada SLA Anda. Memperhitungkan perjanjian tingkat layanan yang ditentukan untuk masing-masing layanan mereka. Untuk Azure, lihat Perjanjian Tingkat Layanan (SLA) untuk Layanan Online
Bagaimana Anda mendefinisikan SLI?
Spesifikasi SLI adalah pernyataan formal dari harapan pengguna Anda tentang satu dimensi keandalan tertentu untuk layanan Anda, seperti latensi atau ketersediaan.
Mulailah sederhana dengan memilih metrik yang tepat untuk mengukur dan mengumpulkan, dan jangan mempersulitnya dengan mengumpulkan terlalu banyak metrik yang tidak bermakna. Pastikan bahwa SLI yang Anda tentukan memiliki hubungan langsung dengan pengalaman pelanggan. Inilah sebabnya mengapa penting untuk memahami perspektif pengguna untuk memulai hanya dengan beberapa indikator.
Jika layanan Anda dibatasi sumber daya dalam beberapa cara, seperti memori atau CPU, maka saturasinya juga dapat menjadi SLI yang sangat baik. Namun, saturasi tidak boleh digunakan sebagai SLO karena tidak secara langsung sesuai dengan pengalaman pengguna yang buruk (layanan dapat memiliki pemanfaatan memori yang tinggi, tetapi pengguna tidak terpengaruh).
Kami menyarankan agar Anda membuat hingga tiga indikator. Lebih dari tiga indikator jarang menambahkan nilai signifikan. Seringkali, jumlah indikator yang berlebihan dapat berarti Anda menyertakan gejala indikator utama. Lalu lintas dan saturasi harus tambahan untuk tiga indikator utama tersebut, seperti yang menjelaskan beban layanan dan dukungan pada interpretasi indikator layanan lainnya.
Bagaimana Anda menerapkan SCO?
SLI yang paling penting adalah yang paling mewakili dampak pada layanan Anda dari perspektif pelanggan Anda. Untuk banyak layanan, ini termasuk latensi, throughput, tingkat kesalahan, dan ketersediaan. Jika layanan Anda memiliki pertimbangan khusus yang memengaruhi pengalaman pelanggan, maka SLI untuk area tersebut juga harus diukur. Misalnya, latensi pemrosesan end-to-end untuk layanan olahpesan adalah indikator langsung dari pengalaman pelanggan dan harus dicakup oleh SLI.
Contoh SLO
Sumber Daya Manusia tertarik untuk memodernisasi aplikasi berbasis web pelacakan waktu internalnya dan menghostingnya di cloud Azure dengan bantuan IT perusahaan. Mereka ingin layanan terus menjangkau semua pengguna di organisasi, sehingga mereka tertarik dengan hal berikut:
- Laporan penggunaan dan berapa banyak pengguna yang menggunakan layanan dari waktu ke waktu.
- Pemantauan kesehatan reguler seperti ketersediaan, performa, keamanan, dan kepatuhan (garansi layanan).
- Biaya, seperti biaya bulanan layanan.
- Keamanan cyber, dalam hal mengontrol akses ke sumber daya dan data dengan mengikuti strategi keamanan Zero Trust.
Seperti yang kita lihat dari contoh-contoh di atas, kategori dan contoh SLO/SLI diperlukan untuk menentukan awal dalam desain layanan. Itu tidak berbeda sama sekali dari layanan lokal yang telah Anda bangun.
Kategori Tabel/SLI SLO
Contoh berikut tidak berarti daftar lengkap. Meskipun SCO keandalan dan pemeliharaan adalah ciri khas sistem selama beberapa dekade, Anda dapat menentukan SCO yang mencakup langkah-langkah untuk keamanan cyber, kualitas dan pengalaman pengguna, serta biaya.
Layanan
Langkah-langkah tingkat tinggi yang khas dari layanan atau sistem biasanya dikodifikasi dalam perjanjian layanan. Sebagian besar perjanjian modern mengukur ketersediaan sebagai SLO utama dan menggunakan langkah-langkah waktu henti sederhana berdasarkan item beban kerja utama atau unit produksi, seperti token autentikasi, kotak surat, atau akun penyimpanan.
| Kategori | Deskripsi | Contoh |
|---|---|---|
| Ketersediaan | Waktu henti sederhana atau Waktu Rata-Rata Antara Pemeliharaan atau ketersediaan operasional (MTBM/(MTBM+MDT)) | 99,99% selama periode bulanan |
| Kapasitas | Pastikan performa bisnis dan layanan yang memadai, maksimum, atau optimal, throughput, penyimpanan, orang, bandwidth, permintaan, sumber daya, dan fungsi layanan. Termasuk batas tenaga kerja dan waktu untuk berfungsi sebagai pemicu. | % Pemanfaatan (CPU, penyimpanan, memori, latensi, throughput, penskalaan) |
| Keamanan | Ancaman dan kerentanan aktif (internal dan eksternal) yang dapat atau menyebabkan kerusakan pada bisnis, aset, dan data. | Deteksi Ancaman HAFNIUM |
| Kepatuhan | Pembaruan, tingkat layanan, kepatuhan pengerasan, penyimpangan konfigurasi yang diinginkan | Pembaruan berlayanan 99,5% pada semua aset |
| Kesinambungan | Kemampuan untuk bertahan hidup dan pulih dari bencana besar dan peristiwa eksternal. | Waktu (rekonstitusi) |
| Kualitas Layanan (QoS) | Karakteristik pengalaman aktual pengguna dari waktu ke waktu. | Kualitas panggilan Teams - kehilangan < paket yang diterima 2% |
Keandalan
Keandalan, SLO klasik, menyiratkan tingkat dependabilitas, durabilitas, dan kualitas dari waktu ke waktu, sistem, layanan, sumber daya, atau komponen untuk kegagalan dan failover, dengan upaya manajemen yang diterapkan untuk mengatasi kegagalan (seperti membangun lebih banyak redundansi atau menambahkan jaringan pengiriman konten) untuk meningkatkan waktu atau ketersediaan operasi. Ini juga bisa berarti akurasi, keakuratan, integritas, dan kepercayaan data yang digunakan untuk mengukur SCO. Ini dapat berarti probabilitas klasik bahwa sistem akan melakukan fungsi yang dimaksudkan dalam kondisi yang ditentukan, seperti tekanan suhu. Ketahanan juga mencakup faktor desain bawaan atau fitur yang memberikan kemampuan beradaptasi seperti penskalaan, pendinginan, penyeimbangan beban, pemulihan, permintaan yang tidak dapat diprediksi, performa yang terdegradasi di bawah tekanan parah, dan desain untuk kelangsungan dalam bencana yang lebih besar (biasanya SLO terpisah).
| Kategori | Deskripsi | Contoh |
|---|---|---|
| Tingkat Kegagalan | Jumlah kegagalan selama total jam operasi | 5 kegagalan dalam 973 jam . 00514 kami |
| Rata-rata Waktu Antar Kegagalan (MTBF) | MTBF adalah kebalikan dari tingkat kegagalan | 194,6 jam |
Pemeliharaan
Gabungkan SCO dukungan untuk proses manajemen layanan TI seperti manajemen insiden dan masalah, bersama dengan SCO keandalan, sehingga pengukuran ketersediaan dapat dicapai.
| Kategori | Deskripsi | Contoh |
|---|---|---|
| Performa Insiden Layanan | Berdasarkan kategori atau produk atau prioritas. | Langkah-langkah waktu dan biaya untuk setiap fase siklus hidup insiden. |
| Performa Insiden Keamanan | Berdasarkan kategori atau produk atau prioritas. | Langkah-langkah waktu dan biaya untuk setiap fase siklus hidup insiden. |
| Waktu rata-rata komponen untuk diperbaiki (MTTR) | Dari deteksi peristiwa melalui pemulihan atau remediasi. | |
| Rata-rata Waktu Antara Pemeliharaan (MTBM) | Rata-rata atau waktu rata-rata antara semua tindakan pemeliharaan, termasuk tindakan pencegahan di mana pekerjaan produksi normal terjadi. | Lihat Waktu Penundaan Pemeliharaan |
| Waktu Penundaan Pemeliharaan (MDT) | Total waktu dari deteksi hingga pemulihan, termasuk logistik dan penundaan administratif. | Saatnya mengganti perangkat keras untuk menyertakan pemesanan, pengiriman, dan penginstalan. |
Pengalaman pelanggan
| Kategori | Deskripsi | Contoh |
|---|---|---|
| Throughput | Jumlah, laju, atau kecepatan beban kerja atau beban produktif yang ditempatkan pada sistem dari waktu ke waktu. | Transaksi per unit waktu. |
| Tingkat kesalahan | Jumlah total kesalahan sebagai persentase. | % Peristiwa keamanan |
| Latensi | Ukuran waktu atau penundaan dari input ke output, pergerakan pekerjaan melalui proses, atau dari aplikasi ke pengguna. | Rata-rata detik. |
Lainnya
| Kategori | Deskripsi | Contoh |
|---|---|---|
| Biaya | Mengukur pengeluaran, penagihan, dan faktur berdasarkan layanan, komponen, atau waktu. | Biaya Modal atau biaya operasi |
| Cakupan | Persentase komponen, sistem, dan layanan di bawah manajemen (kepatuhan) | Kepatuhan |
| Keandalan umpan | Kegagalan heartbeat, konektor, perubahan, dan lainnya. | Melacak perubahan dalam data perusahaan misi penting. |
| Produktivitas | Efektivitas untuk menyelesaikan tugas secara produktif | Tenaga kerja, waktu oleh karyawan, produktivitas analis. |
Pertimbangan
Pastikan akses. Pastikan manajer dan persona lain dalam organisasi diberikan akses ke visualisasi yang tersedia di Azure Monitor atau dari layanan Azure lainnya, terutama Azure SaaS dan PaaS, untuk menghindari duplikatnya.
Pastikan cakupan pemantauan atau visibilitas aset total. Pastikan agen, log yang dipancarkan, tabel, dan kueri untuk semua aset yang perlu dikelola dan diamankan, dan identifikasi "titik buta" atau celah dalam cakupan untuk memastikan realisme dalam SCO.
Dapatkan data yang benar di depan konsumen yang tepat. Pastikan konsumen SLA dan SLI dapat menginterpretasikan data yang mendasar untuk membangun kepercayaan dan memandu keputusan menggunakan informasi yang diperoleh dari data.
Membuat janji yang masuk akal. Saat menetapkan SCO sebagai target terutama ketika manajemen biaya sangat penting, pastikan performa sistem aktual tidak terlalu berkinerja atau kurang terkirim, atau sesuaikan target untuk mengelola ekspektasi pelanggan.
Akun untuk peristiwa eksternal yang tidak terduga. Kembangkan rencana kelangsungan dan penilaian risiko untuk memperhitungkan peristiwa yang tidak berada di bawah kendali Anda, seperti cuaca, pemadaman listrik, atau bencana.
Akun untuk Perubahan. Pastikan akun SLO untuk perubahan pada layanan atau perubahan pada keandalan teknis, throughput, kualitas, dan ketahanan - seperti pengurangan staf dukungan.
Berikan sekumpulan SCO yang seimbang. Pastikan berbagai SLO yang memberikan perspektif seimbang atau 360 derajat pada layanan atau sistem dan fokus pada keandalan.
Langkah berikutnya
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk