SRE (Site Reliability Engineering) - pendekatan untuk memastikan ketersediaan proyek web. Ini dianggap sebagai kerangka kerja untuk DevOps dan memberitahu cara untuk berhasil dalam menerapkan praktik-praktik DevOps. Artikel ini adalah terjemahan dari Bab 4 Tujuan Tingkat Layanan dari Teknik Keandalan Situs dari Google. Saya menyiapkan terjemahan ini sendiri dan mengandalkan pengalaman saya sendiri dalam memahami proses pemantauan. Di saluran telegram monitorim_it dan pos terakhir tentang Habré saya juga menerbitkan terjemahan bab 6 buku yang sama tentang pemantauan sistem terdistribusi.

Terjemahan oleh kucing. Selamat membaca!

Tidak mungkin mengelola layanan jika tidak ada pemahaman tentang indikator apa yang benar-benar penting dan bagaimana mengukur dan mengevaluasinya. Untuk tujuan ini, kami mendefinisikan dan menyediakan tingkat layanan tertentu kepada pengguna kami, terlepas dari apakah mereka menggunakan salah satu API internal kami atau produk publik.

Kami menggunakan intuisi, pengalaman, dan kami mengenali keinginan pengguna untuk memiliki gagasan tentang indikator tingkat layanan (SLI), tujuan tingkat layanan (SLO) dan perjanjian tingkat layanan (SLA). Pengukuran ini menggambarkan metrik utama yang ingin kami kontrol dan yang akan kami tanggapi jika kami tidak dapat memberikan kualitas layanan yang diharapkan. Pada akhirnya, memilih indikator yang tepat akan membantu mengelola tindakan yang tepat jika terjadi kesalahan, dan juga memberikan kepercayaan kepada tim SRE dalam kesehatan layanan.

Bab ini menjelaskan pendekatan yang kami gunakan untuk menangani masalah pemodelan metrik, pemilihan metrik, dan analisis metrik. Sebagian besar penjelasan akan tanpa contoh, jadi kami akan menggunakan layanan Shakespeare yang dijelaskan dalam contoh implementasinya (mencari karya Shakespeare) untuk menggambarkan poin utama.

Terminologi Tingkat Layanan

Banyak pembaca mungkin akrab dengan konsep SLA, tetapi istilah SLI dan SLO layak definisi hati-hati, karena secara umum istilah SLA kelebihan beban dan memiliki sejumlah makna tergantung pada konteksnya. Untuk kejelasan, kami ingin memisahkan nilai-nilai ini.

Indikator

SLI adalah indikator tingkat layanan - ukuran yang diukur secara hati-hati dari satu aspek tingkat layanan yang disediakan.

Untuk sebagian besar layanan, penundaan permintaan dianggap sebagai SLI utama - berapa banyak waktu yang diperlukan untuk mengembalikan respons terhadap permintaan. SLI umum lainnya termasuk tingkat kesalahan, sering dinyatakan sebagai sebagian kecil dari semua permintaan yang diterima, dan sistem throughput, biasanya diukur dalam permintaan per detik. Pengukuran sering digabungkan: data mentah dikumpulkan pertama kali dan kemudian dikonversi ke tingkat perubahan, rata-rata atau persentil.

Idealnya, SLI secara langsung mengukur tingkat layanan yang menarik, tetapi kadang-kadang hanya metrik terkait yang tersedia untuk pengukuran, karena aslinya sulit untuk diperoleh atau ditafsirkan. Misalnya, latensi sisi klien sering merupakan metrik yang lebih tepat, tetapi kebetulan mengukur latensi hanya mungkin di server.

Jenis SLI lain yang penting untuk SRE adalah ketersediaan atau bagian dari waktu selama layanan dapat digunakan. Ini sering didefinisikan sebagai persentase dari permintaan yang berhasil, kadang-kadang disebut pembuatan. (Harapan hidup - kemungkinan bahwa data akan disimpan untuk jangka waktu yang lama juga penting untuk sistem penyimpanan data.) Meskipun aksesibilitas 100% tidak mungkin, aksesibilitas mendekati 100% sering dapat dicapai, nilai aksesibilitas dinyatakan sebagai angka "sembilan" »Persen ketersediaan. Misalnya, ketersediaan 99% dan 99,999% dapat disebut sebagai "2 nines" dan "5 nines". Tujuan aksesibilitas yang dinyatakan saat ini untuk Mesin Komputasi Google adalah "tiga setengah sembilan" atau 99,95%.

Tujuan

SLO adalah tujuan tingkat layanan: nilai target atau rentang nilai untuk tingkat layanan yang diukur oleh SLI. Nilai normal untuk SLO adalah “SLI ≤ nilai target” atau “batas bawah ≤ SLI ≤ batas atas”. Misalnya, kami dapat memutuskan bahwa kami akan mengembalikan hasil pencarian untuk karya Shakespeare "dengan cepat", dengan mengambil dalam bentuk SLO nilai dari penundaan rata-rata permintaan pencarian kurang dari 100 milidetik.

Memilih SLO yang tepat adalah proses yang kompleks. Pertama, Anda tidak selalu dapat memilih nilai tertentu. Untuk permintaan HTTP eksternal yang masuk ke layanan Anda, metrik jumlah permintaan per detik (QPS) terutama ditentukan oleh keinginan pengguna Anda untuk mengunjungi layanan Anda, dan Anda tidak dapat menginstal SLO untuk ini.

Di sisi lain, Anda dapat mengatakan bahwa Anda ingin penundaan rata-rata untuk setiap permintaan kurang dari 100 milidetik. Menetapkan tujuan seperti itu dapat membuat Anda menulis front-end Anda dengan penundaan rendah atau membeli peralatan yang menyediakan penundaan seperti itu. (100 milidetik jelas merupakan nilai sewenang-wenang, tetapi lebih baik memiliki tingkat latensi yang lebih rendah. Ada alasan untuk percaya bahwa kecepatan tinggi lebih baik daripada lambat dan bahwa menunda permintaan pengguna di atas nilai-nilai tertentu sebenarnya memaksa orang menjauh dari layanan Anda.)

Sekali lagi, ini lebih ambigu daripada yang terlihat pada pandangan pertama: itu tidak layak membuang QPS dari perhitungan. Faktanya adalah bahwa bundel QPS dan penundaan sangat terkait satu sama lain: QPS yang lebih tinggi sering menyebabkan penundaan yang lebih lama, dan biasanya layanan mengalami penurunan tajam dalam kinerja ketika ambang batas beban tertentu tercapai.

Memilih dan menerbitkan SLO menetapkan harapan pengguna tentang bagaimana layanan akan bekerja. Strategi ini dapat mengurangi keluhan yang tidak masuk akal tentang pemilik layanan, misalnya, tentang pekerjaannya yang lambat. Tanpa SLO eksplisit, pengguna sering membuat harapan mereka sendiri tentang kinerja yang diinginkan, yang mungkin tidak terkait dengan pendapat orang yang merancang dan mengelola layanan. Penjajaran ini dapat menyebabkan harapan yang tinggi dari layanan, ketika pengguna secara keliru percaya bahwa layanan akan lebih mudah diakses daripada yang sebenarnya dan menyebabkan ketidakpercayaan ketika pengguna percaya bahwa sistem kurang dapat diandalkan daripada yang sebenarnya.

Perjanjian

Perjanjian tingkat layanan adalah kontrak eksplisit atau implisit dengan pengguna Anda yang mencakup konsekuensi dari awal (atau tidak adanya) SLO yang dikandungnya. Konsekuensinya paling mudah dikenali ketika mereka finansial - diskon atau penalti - tetapi mereka dapat mengambil bentuk lain. Cara mudah untuk berbicara tentang perbedaan antara SLO dan SLA adalah dengan bertanya, "Apa yang terjadi jika SLO tidak terpenuhi?" Jika tidak ada konsekuensi yang jelas, Anda hampir pasti akan melihat SLO.

SRE biasanya tidak terlibat dalam menciptakan SLA karena SLA terkait erat dengan solusi bisnis dan produk. Namun SRE terlibat dalam membantu mencegah konsekuensi dari SLO yang gagal. Mereka juga dapat membantu menentukan SLI: jelas, harus ada cara obyektif untuk mengukur SLO dalam suatu perjanjian atau akan ada ketidaksepakatan.

Google Search adalah contoh layanan penting yang tidak memiliki SLA untuk publik: kami ingin semua orang menggunakan Pencarian seefisien mungkin, tetapi kami belum menandatangani kontrak dengan seluruh dunia. Namun, masih ada konsekuensi jika pencarian tidak tersedia - tidak dapat diaksesnya menyebabkan penurunan reputasi kami, serta penurunan pendapatan iklan. Banyak layanan Google lainnya, seperti Google for Work, memiliki perjanjian tingkat layanan eksplisit dengan pengguna. Terlepas dari apakah layanan tertentu memiliki SLA, penting untuk menentukan SLI dan SLO dan menggunakannya untuk mengelola layanan.

Begitu banyak teori - sekarang untuk mengalami.

Indikator dalam praktik

Mengingat kami telah menyimpulkan bahwa penting untuk memilih indikator yang sesuai untuk mengukur tingkat layanan, bagaimana Anda sekarang tahu indikator mana yang relevan dengan layanan atau sistem?

Apa yang Anda dan pengguna pedulikan

Anda tidak perlu menggunakan setiap indikator sebagai SLI, yang dapat Anda lacak di sistem pemantauan; Memahami apa yang diinginkan pengguna dari sistem akan membantu Anda memilih beberapa metrik. Memilih terlalu banyak indikator membuat sulit untuk memperhatikan indikator penting, sementara memilih terlalu sedikit dapat meninggalkan potongan signifikan dari sistem Anda tanpa pengawasan. Biasanya kami menggunakan beberapa indikator utama untuk mengevaluasi dan memahami keadaan sistem.

Layanan, sebagai suatu peraturan, dapat dibagi menjadi beberapa bagian dalam hal SLI, yang relevan bagi mereka:

• Sistem antarmuka kustom, seperti antarmuka pencarian layanan Shakespeare dari contoh kami. Mereka harus dapat diakses, tidak ditunda dan memiliki bandwidth yang cukup. Dengan demikian, Anda dapat mengajukan pertanyaan: dapatkah kami menjawab permintaan? Berapa lama untuk menjawab permintaan? Berapa banyak permintaan yang bisa diproses?
• Sistem penyimpanan. Latensi rendah, ketersediaan, dan daya tahan penting bagi mereka. Pertanyaan Terkait: Berapa lama untuk membaca atau menulis data? Bisakah kita mengakses data berdasarkan permintaan? Apakah data tersedia saat kita membutuhkannya? Lihat bab 26 Integritas Data: apa yang Anda baca adalah apa yang Anda tulis untuk diskusi terperinci tentang masalah ini.
• Sistem data besar, seperti pipa pemrosesan data, bergantung pada throughput dan latensi pemrosesan permintaan. Pertanyaan yang relevan: berapa banyak data yang diproses? Berapa lama waktu yang dibutuhkan untuk data untuk beralih dari menerima permintaan ke mengeluarkan respons? (Beberapa bagian sistem mungkin juga mengalami keterlambatan pada tahap tertentu.)

Koleksi Indikator

Sangat alami untuk mengumpulkan banyak indikator tingkat layanan di sisi server, menggunakan sistem pemantauan seperti Borgmon (lihat Bab 10 Praktik Peringatan Seri Waktu ) atau Prometheus, atau secara sederhana menganalisis log, mengungkapkan respons HTTP dengan status 500. Namun demikian, beberapa sistem harus dilengkapi dengan kumpulan metrik sisi klien, karena kurangnya pemantauan di sisi klien dapat menyebabkan hilangnya sejumlah masalah yang memengaruhi pengguna tetapi tidak memengaruhi metrik sisi server. Misalnya, berfokus pada respons yang tertunda pada bagian belakang aplikasi pengujian kami yang mencari karya Shakespeare dapat menyebabkan keterlambatan dalam memproses permintaan di sisi pengguna karena masalah JavaScript: dalam hal ini, mengukur berapa lama halaman yang akan diproses dalam browser adalah indikator terbaik.

Agregasi

Untuk kesederhanaan dan kemudahan penggunaan, kami sering mengagregasi dimensi mentah. Ini harus dilakukan dengan hati-hati.

Beberapa indikator tampak sederhana, misalnya, jumlah kueri per detik, tetapi bahkan pengukuran ini, langsung, secara implisit, mengumpulkan data dari waktu ke waktu. Apakah pengukuran diperoleh secara khusus sekali per detik atau apakah pengukuran ini dirata-rata berdasarkan jumlah kueri per menit? Opsi terakhir dapat menyembunyikan jumlah permintaan sesaat yang jauh lebih tinggi yang disimpan hanya untuk beberapa detik. Pertimbangkan sistem yang melayani 200 permintaan per detik dengan angka genap dan 0 sisa waktu. Konstanta dalam bentuk nilai rata-rata 100 permintaan per detik dan dua kali lipat beban instan bukanlah hal yang sama. Demikian juga, rata-rata latensi permintaan mungkin tampak menarik, tetapi menyembunyikan detail penting: ada kemungkinan bahwa sebagian besar permintaan akan cepat, tetapi akan ada banyak permintaan yang akan lambat.

Sebagian besar indikator lebih baik dilihat sebagai distribusi daripada rata-rata. Misalnya, untuk keterlambatan SLI, beberapa permintaan akan diproses dengan cepat, sementara beberapa akan selalu lebih lama, kadang-kadang lebih lama. Rata-rata sederhana dapat menyembunyikan penundaan lama ini. Gambar tersebut menunjukkan contoh: meskipun permintaan tipikal dilayani sekitar 50 ms, 5% permintaan 20 kali lebih lambat! Pemantauan dan peringatan hanya berdasarkan latensi rata-rata tidak menunjukkan perubahan perilaku di siang hari, padahal sebenarnya ada perubahan nyata dalam waktu pemrosesan beberapa permintaan (baris teratas).


50, 85, 95, dan 99 persentil keterlambatan sistem. Sumbu Y dalam format logaritmik.

Menggunakan persentil untuk indikator memungkinkan Anda untuk melihat bentuk distribusi dan karakteristiknya: tingkat persentil yang tinggi, seperti 99 atau 99,9, menunjukkan nilai terburuk, dan pada persentil 50 (juga dikenal sebagai median), Anda dapat melihat status metrik yang paling sering. Semakin besar varians dalam waktu respons, semakin kuat kueri jangka panjang memengaruhi pengalaman pengguna. Efeknya ditingkatkan pada beban tinggi di hadapan antrian. Studi pengalaman pengguna telah menunjukkan bahwa orang biasanya lebih suka sistem yang lebih lambat dengan dispersi waktu respons yang tinggi, sehingga beberapa tim SRE hanya fokus pada nilai persentil tinggi, berdasarkan asumsi bahwa jika perilaku metrik pada 99,9 persentil itu baik, sebagian besar pengguna tidak akan mengalami masalah.

Catatan tentang kesalahan statistik

Biasanya kami lebih suka bekerja dengan persentil daripada dengan set nilai rata-rata (rata-rata aritmatika). Ini memungkinkan kami untuk mempertimbangkan nilai yang lebih tersebar, yang seringkali memiliki karakteristik yang berbeda (dan lebih menarik) dari rata-rata. Karena sifat buatan dari sistem komputasi, nilai metrik sering terdistorsi, misalnya, tidak ada permintaan yang dapat menerima respons dalam waktu kurang dari 0 ms, dan batas waktu 1000 ms berarti bahwa tidak ada respons yang berhasil dengan nilai yang melebihi batas waktu. Akibatnya, kami tidak dapat menerima bahwa mean dan median dapat sama atau dekat satu sama lain!

Tanpa verifikasi awal, dan jika beberapa asumsi dan perkiraan standar tidak terpenuhi, kami mencoba untuk tidak menarik kesimpulan bahwa data kami terdistribusi secara normal. Jika distribusi tidak seperti yang diharapkan, proses otomasi yang memperbaiki masalah (misalnya, ketika melihat outlier melampaui nilai batas, ia memulai kembali server dengan latensi tinggi untuk memproses permintaan) dapat melakukan ini terlalu sering atau tidak cukup sering (kedua opsi tidak terlalu baik).

Standarisasi indikator

Kami merekomendasikan standardisasi karakteristik umum untuk SLI sehingga Anda tidak perlu membicarakannya setiap waktu. Fungsi apa pun yang memenuhi templat standar dapat dikecualikan dari spesifikasi masing-masing SLI, misalnya:

• Interval agregasi: "rata-rata lebih dari 1 menit"
• Area agregasi: "Semua tugas di cluster"
• Seberapa sering pengukuran dilakukan: "Setiap 10 detik"
• Apa permintaan disertakan: "HTTP DAPATKAN dari pekerjaan pemantauan kotak hitam"
• Bagaimana data diterima: "Terima kasih atas pemantauan kami yang diukur pada server",
• Keterlambatan Akses Data: "Time to Last Byte"

Untuk menghemat upaya, buat satu set templat SLI yang dapat digunakan kembali untuk setiap metrik umum; mereka juga memudahkan semua orang untuk memahami apa arti SLI tertentu.

Tujuan latihan

Mulailah dengan berpikir (atau mencari tahu!) Apa yang dipedulikan pengguna Anda, bukan apa yang dapat Anda ukur. Seringkali, apa yang mengganggu pengguna Anda sulit atau tidak mungkin untuk diukur, sehingga Anda akhirnya semakin dekat dengan kebutuhan mereka. Namun, jika Anda baru memulai dengan apa yang mudah diukur, Anda akan mendapatkan SLO yang kurang bermanfaat. Akibatnya, kami terkadang menemukan bahwa definisi awal tujuan yang diinginkan dan pekerjaan lebih lanjut dengan indikator spesifik bekerja lebih baik daripada memilih indikator dan kemudian mencapai tujuan.

Tentukan tujuan

Untuk kejelasan maksimum, harus ditentukan bagaimana SLO diukur dan kondisi di mana mereka valid. Misalnya, kita dapat mengatakan yang berikut (baris kedua sama dengan yang pertama, tetapi menggunakan nilai SLI secara default):

• 99% (rata-rata lebih dari 1 menit) dari Panggilan RPC akan diselesaikan dalam waktu kurang dari 100 ms (diukur pada semua server backend).
• 99% panggilan Get RPC akan selesai dalam waktu kurang dari 100ms.

Jika bentuk kurva kinerja penting, Anda dapat menentukan beberapa sasaran SLO:

• 90% dari Dapatkan panggilan RPC diselesaikan dalam waktu kurang dari 1 ms.
• 99% dari Panggilan RPC selesai dalam waktu kurang dari 10 ms.
• 99,9% dari Dapatkan panggilan RPC diselesaikan dalam waktu kurang dari 100 ms.

Jika pengguna Anda menghasilkan beban heterogen: pemrosesan massal (untuk bandwidth yang penting) dan pemrosesan interaktif (yang jumlah keterlambatannya penting), mungkin disarankan untuk menetapkan tujuan terpisah untuk setiap kelas beban:

• 95% permintaan pelanggan adalah bandwidth penting. Setel jumlah panggilan RPC yang sedang berlangsung <1 dtk.
• 99% pelanggan menghargai jumlah keterlambatan. Siapkan hitungan panggilan RPC dengan lalu lintas <1 kB dan sedang berlangsung <10 ms.

Adalah tidak realistis dan tidak diinginkan untuk bersikeras bahwa SLO akan dieksekusi dalam 100% kasus: ini dapat memperlambat laju pengenalan fungsionalitas dan penyebaran baru, dan membutuhkan solusi yang mahal. Alih-alih, lebih baik membiarkan anggaran kesalahan - sebagian kecil dari downtime sistem dan memantau nilai ini setiap hari atau setiap minggu.Manajemen puncak mungkin menginginkan penilaian bulanan atau triwulanan. (Anggaran kesalahan hanyalah SLO untuk perbandingan dengan SLO lain).

Persentase pelanggaran SLO dapat dibandingkan dengan anggaran kesalahan (lihat Bab 3 dan bagian "Motivasi untuk anggaran kesalahan" ), dan nilai perbedaan digunakan sebagai input untuk proses yang memutuskan kapan akan menyebarkan rilis baru.

Pilih Nilai Paket

Pemilihan nilai yang direncanakan (SLO) bukanlah kegiatan teknis murni karena minat produk dan bisnis, yang harus tercermin dalam SLI, SLO yang dipilih (dan, mungkin, SLA). Demikian pula, mungkin perlu untuk bertukar informasi tentang masalah-masalah yang berkaitan dengan kepegawaian, waktu ke pasar, ketersediaan peralatan, dan pembiayaan. SRE harus menjadi bagian dari percakapan ini dan membantu menangani risiko dan kelayakan berbagai opsi. Kami menemukan beberapa pertanyaan yang mungkin membantu memberikan diskusi yang lebih produktif:

Jangan memilih sasaran berdasarkan kinerja saat ini.
Meskipun memahami manfaat dan batasan sistem itu penting, mengadaptasi indikator tanpa alasan dapat menghalangi Anda untuk mendukung sistem: itu akan mengambil upaya heroik untuk mencapai tujuan yang tidak dapat dicapai tanpa reorganisasi besar.

Tetap sederhana
Perhitungan SLI yang kompleks dapat menyembunyikan perubahan dalam kinerja sistem dan membuatnya lebih sulit untuk menemukan penyebab masalah.

Hindari yang absolut.
Meskipun tergoda untuk memiliki sistem yang dapat mengambil beban yang tumbuh tanpa batas tanpa meningkatkan nilai penundaan, persyaratan ini tidak realistis. Sebuah sistem yang mendekati cita-cita seperti itu kemungkinan akan memaksa banyak waktu untuk merancang dan membangun, akan membutuhkan biaya yang mahal untuk beroperasi akan terlalu baik untuk harapan pengguna yang akan memiliki lebih sedikit.

Gunakan sebagai SLO sesedikit mungkin.
Pilih cukup SLO untuk memberikan cakupan atribut sistem yang baik. Lindungi SLO yang Anda pilih: jika Anda tidak pernah bisa memenangkan perselisihan atas prioritas dengan menetapkan SLO tertentu, Anda mungkin tidak boleh mempertimbangkan SLO ini. Namun, tidak semua atribut sistem cocok untuk SLO: sulit untuk menghitung tingkat antusiasme pengguna dengan SLO.

Jangan Mengejar Kesempurnaan
Anda selalu dapat memperbaiki definisi dan sasaran SLO Anda seiring waktu ketika Anda mempelajari lebih lanjut tentang perilaku sistem yang sedang dimuat. Lebih baik memulai dengan tujuan mengambang, yang akan Anda perjelas seiring waktu, daripada memilih tujuan yang terlalu ketat yang harus dilemahkan ketika Anda menemukan bahwa itu tidak mungkin tercapai.

SLO dapat dan harus menjadi pendorong utama dalam memprioritaskan pekerjaan untuk SRE dan pengembang produk, karena mencerminkan layanan pengguna. SLO yang baik adalah alat yang berguna untuk memaksa tim pengembangan. Tetapi SLO yang dirancang dengan buruk dapat menyebabkan pekerjaan yang sia-sia jika tim melakukan upaya heroik untuk mencapai SLO yang terlalu agresif atau produk yang buruk jika SLO terlalu rendah. SLO adalah tuas yang kuat, gunakan dengan bijak.

Mengontrol pengukuran

SLI dan SLO adalah elemen kunci yang digunakan untuk mengelola sistem:

• Monitor dan ukur sistem SLI.
• Bandingkan SLI dengan SLO dan putuskan apakah diperlukan tindakan.
• Jika diperlukan tindakan, cari tahu apa yang perlu terjadi untuk mencapai tujuan.
• Lakukan tindakan ini.

Misalnya, jika langkah 2 menunjukkan bahwa batas waktu permintaan meningkat, dan akan memecahkan SLO setelah beberapa jam jika tidak ada yang dilakukan, langkah 3 dapat mencakup pengujian hipotesis bahwa beban server terkait dengan prosesor dan menambahkan server baru akan mendistribusikan beban . Tanpa SLO, Anda tidak akan tahu apakah (atau kapan) akan mengambil tindakan.

Tetapkan SLO - lalu ekspektasi pengguna ditetapkan
Menerbitkan SLO menetapkan harapan pengguna untuk perilaku sistem. Pengguna (dan pengguna potensial) sering ingin tahu apa yang diharapkan dari suatu layanan untuk melihat apakah itu cocok untuk digunakan. Misalnya, orang yang ingin menggunakan situs berbagi foto mungkin ingin menghindari menggunakan layanan yang menjanjikan daya tahan dan biaya rendah dengan imbalan ketersediaan yang sedikit lebih rendah, meskipun layanan yang sama mungkin ideal untuk sistem manajemen rekaman arsip.

Untuk menetapkan harapan yang realistis bagi pengguna Anda, gunakan salah satu atau kedua taktik berikut:

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

Memahami seberapa baik sistem memenuhi harapan membantu memutuskan apakah akan mempercepat sistem dan membuatnya lebih mudah diakses dan lebih stabil. Atau, jika layanan bekerja dengan baik, beberapa waktu staf harus dihabiskan untuk prioritas lain, seperti membayar utang teknis, menambahkan fitur baru, atau menempatkan produk baru ke dalam operasi.

Perjanjian praktik

Membuat SLA mensyaratkan bahwa tim bisnis dan hukum menentukan konsekuensi dan hukuman karena melanggarnya. Peran SRE adalah untuk membantu mereka memahami kemungkinan kesulitan dalam melakukan SLO yang terkandung dalam SLA. Sebagian besar pedoman SLO juga berlaku untuk SLA. Dianjurkan untuk bersikap konservatif dalam apa yang Anda janjikan kepada pengguna, karena semakin mereka, semakin sulit untuk mengubah atau menghapus SLA yang tampaknya tidak masuk akal atau sulit untuk diterapkan.

Terima kasih telah membaca terjemahan sampai akhir. Berlangganan saluran telegram saya tentang memantau monitorim_it dan blog di Medium .