SRE (Site Reliability Engineering) adalah pendekatan untuk memastikan aksesibilitas proyek web. Ini dianggap sebagai kerangka kerja untuk DevOps dan membahas tentang cara mencapai kesuksesan dalam menerapkan praktik DevOps. Terjemahan dalam artikel ini buku-buku dari Google. Saya menyiapkan terjemahan ini sendiri dan mengandalkan pengalaman saya sendiri dalam memahami proses pemantauan. Di saluran telegram и Saya juga menerbitkan terjemahan Bab 6 dari buku yang sama tentang sasaran tingkat layanan.
Terjemahan oleh kucing. Selamat membaca!
Tidak mungkin mengelola suatu layanan jika tidak ada pemahaman tentang indikator apa yang sebenarnya penting dan bagaimana mengukur dan mengevaluasinya. Untuk mencapai tujuan ini, kami mendefinisikan dan memberikan tingkat layanan tertentu kepada pengguna kami, terlepas dari apakah mereka menggunakan salah satu API internal kami atau produk publik.
Kami menggunakan intuisi, pengalaman, dan pemahaman kami terhadap keinginan pengguna untuk memahami Indikator Tingkat Layanan (SLI), Sasaran Tingkat Layanan (SLO), dan Perjanjian Tingkat Layanan (SLA). Dimensi ini menggambarkan metrik utama yang ingin kita pantau dan yang akan kita tanggapi jika kita tidak dapat memberikan kualitas layanan yang diharapkan. Pada akhirnya, memilih metrik yang tepat membantu memandu tindakan yang tepat jika terjadi kesalahan, dan juga memberikan kepercayaan kepada tim SRE terhadap kesehatan layanan.
Bab ini menjelaskan pendekatan yang kami gunakan untuk mengatasi masalah pemodelan metrik, pemilihan metrik, dan analisis metrik. Sebagian besar penjelasannya tanpa contoh, jadi kami akan menggunakan layanan Shakespeare yang dijelaskan dalam contoh implementasinya (mencari karya Shakespeare) untuk mengilustrasikan poin utama.
Terminologi tingkat layanan
Banyak pembaca yang mungkin akrab dengan konsep SLA, namun istilah SLI dan SLO perlu didefinisikan secara cermat karena secara umum istilah SLA berlebihan dan memiliki sejumlah arti tergantung pada konteksnya. Agar lebih jelas, kami ingin memisahkan nilai-nilai ini.
Indikator.
SLI adalah indikator tingkat layanan—ukuran kuantitatif yang didefinisikan secara cermat mengenai satu aspek tingkat layanan yang diberikan.
Untuk sebagian besar layanan, SLI utama dianggap sebagai latensi permintaan - berapa lama waktu yang diperlukan untuk mengembalikan respons terhadap permintaan. SLI umum lainnya mencakup tingkat kesalahan, sering kali dinyatakan sebagai sebagian kecil dari semua permintaan yang diterima, dan throughput sistem, biasanya diukur dalam permintaan per detik. Pengukuran sering kali dikumpulkan: data mentah dikumpulkan terlebih dahulu dan kemudian diubah menjadi tingkat perubahan, rata-rata, atau persentil.
Idealnya, SLI secara langsung mengukur tingkat kepentingan layanan, namun terkadang hanya metrik terkait yang tersedia untuk pengukuran karena metrik asli sulit diperoleh atau diinterpretasikan. Misalnya, latensi sisi klien sering kali merupakan metrik yang lebih tepat, namun ada kalanya latensi hanya dapat diukur di server.
Jenis SLI lain yang penting bagi SRE adalah ketersediaan, atau porsi waktu layanan dapat digunakan. Seringkali didefinisikan sebagai tingkat permintaan yang berhasil, terkadang disebut hasil. (Seumur hidup—kemungkinan bahwa data akan disimpan untuk jangka waktu yang lama—juga penting untuk sistem penyimpanan data.) Meskipun ketersediaan 100% tidak mungkin dilakukan, ketersediaan yang mendekati 100% sering kali dapat dicapai; nilai ketersediaan dinyatakan sebagai jumlah "sembilan" » persentase ketersediaan. Misalnya, ketersediaan 99% dan 99,999% mungkin diberi label "2 sembilan" dan "5 sembilan". Target ketersediaan Google Compute Engine saat ini adalah "tiga setengah sembilan" atau 99,95%.
Tujuan
SLO adalah tujuan tingkat layanan: nilai target atau rentang nilai untuk tingkat layanan yang diukur dengan SLI. Nilai normal SLO adalah “SLI ≤ Target” atau “Batas Bawah ≤ SLI ≤ Batas Atas”. Misalnya, kami mungkin memutuskan bahwa kami akan mengembalikan hasil penelusuran Shakespeare “cepat” dengan menyetel SLO ke latensi kueri penelusuran rata-rata kurang dari 100 milidetik.
Memilih SLO yang tepat adalah proses yang rumit. Pertama, Anda tidak selalu bisa memilih nilai tertentu. Untuk permintaan HTTP masuk eksternal ke layanan Anda, metrik Kueri Per Detik (QPS) terutama ditentukan oleh keinginan pengguna untuk mengunjungi layanan Anda, dan Anda tidak dapat menetapkan SLO untuk itu.
Di sisi lain, Anda dapat mengatakan bahwa Anda ingin latensi rata-rata untuk setiap permintaan kurang dari 100 milidetik. Menetapkan tujuan seperti itu mungkin memaksa Anda untuk menulis frontend dengan latensi rendah atau membeli peralatan yang menyediakan latensi tersebut. (100 milidetik jelas merupakan angka yang sewenang-wenang, tetapi lebih baik memiliki angka latensi yang lebih rendah lagi. Ada bukti yang menunjukkan bahwa kecepatan cepat lebih baik daripada kecepatan lambat, dan latensi dalam memproses permintaan pengguna di atas nilai tertentu sebenarnya memaksa orang untuk menjauh. dari layanan Anda.)
Sekali lagi, ini lebih ambigu daripada yang terlihat pada pandangan pertama: Anda tidak boleh sepenuhnya mengecualikan QPS dari penghitungan. Faktanya adalah bahwa QPS dan latensi sangat terkait satu sama lain: QPS yang lebih tinggi sering kali menyebabkan latensi yang lebih tinggi, dan layanan biasanya mengalami penurunan kinerja yang tajam ketika mencapai ambang batas beban tertentu.
Memilih dan memublikasikan SLO menetapkan ekspektasi pengguna tentang cara kerja layanan. Strategi ini dapat mengurangi keluhan yang tidak berdasar terhadap pemilik layanan, misalnya kinerja yang lambat. Tanpa SLO yang eksplisit, pengguna sering kali menciptakan ekspektasi mereka sendiri tentang performa yang diinginkan, yang mungkin tidak ada hubungannya dengan opini orang yang merancang dan mengelola layanan. Situasi ini dapat menyebabkan ekspektasi yang berlebihan terhadap 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 dibandingkan yang sebenarnya.
Perjanjian
Perjanjian tingkat layanan adalah kontrak eksplisit atau implisit dengan pengguna Anda yang mencakup konsekuensi memenuhi (atau tidak memenuhi) SLO yang ada di dalamnya. Konsekuensi paling mudah dikenali jika bersifat finansial—diskon atau denda—namun bisa juga dalam bentuk lain. Cara mudah untuk menjelaskan perbedaan antara SLO dan SLA adalah dengan bertanya “apa yang terjadi jika SLO tidak dipenuhi?” Jika tidak ada konsekuensi yang jelas, Anda hampir pasti sedang mempertimbangkan SLO.
SRE biasanya tidak terlibat dalam pembuatan SLA karena SLA terkait erat dengan keputusan bisnis dan produk. Namun, SRE terlibat dalam membantu mengurangi dampak kegagalan SLO. Mereka juga dapat membantu menentukan SLI: Tentunya harus ada cara yang obyektif untuk mengukur SLO dalam perjanjian atau akan terjadi perselisihan.
Google Penelusuran adalah contoh layanan penting yang tidak memiliki SLA publik: kami ingin semua orang menggunakan Penelusuran seefisien mungkin, namun kami belum menandatangani kontrak dengan dunia. Namun, tetap ada konsekuensi jika penelusuran tidak tersedia - ketidaktersediaan mengakibatkan turunnya reputasi kami serta berkurangnya pendapatan iklan. Banyak layanan Google lainnya, seperti Google for Work, memiliki perjanjian tingkat layanan yang jelas 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 dialami.
Indikator dalam praktiknya
Mengingat kita telah menyimpulkan bahwa penting untuk memilih metrik yang tepat untuk mengukur tingkat layanan, bagaimana Anda sekarang mengetahui metrik mana yang penting bagi layanan atau sistem?
Apa yang menjadi perhatian Anda dan pengguna Anda?
Anda tidak perlu menggunakan setiap metrik sebagai SLI yang dapat Anda lacak dalam sistem pemantauan; Memahami apa yang diinginkan pengguna dari suatu sistem akan membantu Anda memilih beberapa metrik. Memilih terlalu banyak indikator akan menyulitkan Anda untuk berfokus pada indikator-indikator penting, sementara memilih sejumlah kecil indikator dapat menyebabkan sebagian besar sistem Anda tidak diawasi. Kami biasanya menggunakan beberapa indikator utama untuk mengevaluasi dan memahami kesehatan suatu sistem.
Layanan secara umum dapat dipecah menjadi beberapa bagian berdasarkan SLI yang relevan dengannya:
- Sistem front-end khusus, seperti antarmuka pencarian untuk layanan Shakespeare dari contoh kami. Mereka harus tersedia, tidak ada penundaan dan memiliki bandwidth yang cukup. Oleh karena itu, pertanyaan dapat diajukan: dapatkah kami menanggapi permintaan tersebut? Berapa lama waktu yang dibutuhkan untuk menanggapi permintaan tersebut? Berapa banyak permintaan yang dapat diproses?
- Sistem penyimpanan. Mereka menghargai latensi respons yang rendah, ketersediaan, dan daya tahan. Pertanyaan terkait: Berapa lama waktu yang dibutuhkan untuk membaca atau menulis data? Bisakah kami 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 pembahasan mendetail mengenai masalah ini.
- Sistem data besar seperti jalur pemrosesan data mengandalkan throughput dan latensi pemrosesan kueri. Pertanyaan terkait: Berapa banyak data yang diproses? Berapa lama waktu yang dibutuhkan data untuk berpindah dari menerima permintaan hingga mengeluarkan respons? (Beberapa bagian sistem mungkin juga mengalami penundaan pada tahapan tertentu.)
Kumpulan indikator
Banyak indikator tingkat layanan dikumpulkan secara alami di sisi server, menggunakan sistem pemantauan seperti Borgmon (lihat di bawah). ) atau Prometheus, atau sekadar menganalisis log secara berkala, mengidentifikasi respons HTTP dengan status 500. Namun, beberapa sistem harus dilengkapi dengan pengumpulan metrik sisi klien, karena kurangnya pemantauan sisi klien dapat menyebabkan hilangnya sejumlah masalah yang mempengaruhi pengguna, tetapi tidak memengaruhi metrik sisi server. Misalnya, berfokus pada latensi respons backend aplikasi pengujian penelusuran Shakespeare kami dapat mengakibatkan latensi di sisi pengguna karena masalah JavaScript: dalam hal ini, mengukur berapa lama waktu yang dibutuhkan browser untuk memproses laman adalah metrik yang lebih baik.
Pengumpulan
Untuk kesederhanaan dan kemudahan penggunaan, kami sering menggabungkan pengukuran mentah. Ini harus dilakukan dengan hati-hati.
Beberapa metrik tampak sederhana, seperti permintaan per detik, namun pengukuran yang tampaknya sederhana ini secara implisit mengumpulkan data dari waktu ke waktu. Apakah pengukuran diterima secara khusus satu kali per detik atau apakah pengukuran dirata-ratakan berdasarkan jumlah permintaan per menit? Opsi terakhir dapat menyembunyikan jumlah permintaan seketika yang jauh lebih tinggi dan hanya berlangsung beberapa detik. Pertimbangkan sebuah sistem yang melayani 200 permintaan per detik dengan angka genap dan 0 sisanya. Konstanta berupa nilai rata-rata 100 permintaan per detik dan dua kali beban sesaat bukanlah hal yang sama. Demikian pula, rata-rata latensi kueri mungkin tampak menarik, namun menyembunyikan detail penting: mungkin saja sebagian besar kueri akan cepat, namun akan ada banyak kueri yang lambat.
Kebanyakan indikator lebih baik dianggap sebagai distribusi dibandingkan rata-rata. Misalnya, untuk latensi SLI, beberapa permintaan akan diproses dengan cepat, sementara beberapa lainnya selalu membutuhkan waktu lebih lama, terkadang lebih lama. Rata-rata sederhana dapat menyembunyikan penundaan yang lama ini. Gambar tersebut menunjukkan sebuah contoh: meskipun permintaan umum memerlukan waktu sekitar 50 ms untuk dilayani, 5% permintaan 20 kali lebih lambat! Pemantauan dan peringatan hanya berdasarkan latensi rata-rata tidak menunjukkan perubahan perilaku sepanjang hari, padahal sebenarnya ada perubahan nyata dalam waktu pemrosesan beberapa permintaan (baris paling atas).
Latensi sistem persentil 50, 85, 95, dan 99. Sumbu Y dalam format logaritmik.
Penggunaan persentil untuk indikator memungkinkan Anda melihat bentuk distribusi dan karakteristiknya: tingkat persentil yang tinggi, seperti 99 atau 99,9, menunjukkan nilai terburuk, sedangkan persentil 50 (juga dikenal sebagai median) menunjukkan keadaan yang paling sering terjadi. metrik. Semakin besar dispersi waktu respons, semakin besar dampak permintaan yang berjalan lama terhadap pengalaman pengguna. Efeknya ditingkatkan pada beban tinggi dan adanya antrian. Riset pengalaman pengguna menunjukkan bahwa orang umumnya lebih menyukai sistem yang lebih lambat dengan varian waktu respons yang tinggi, sehingga beberapa tim SRE hanya fokus pada skor persentil tinggi, dengan premis bahwa jika perilaku metrik pada persentil 99,9 baik, sebagian besar pengguna tidak akan mengalami masalah .
Catatan tentang kesalahan statistik
Kami umumnya lebih suka bekerja dengan persentil daripada mean (rata-rata aritmatika) dari serangkaian nilai. Hal ini memungkinkan kita untuk mempertimbangkan nilai-nilai yang lebih tersebar, yang seringkali memiliki karakteristik yang sangat berbeda (dan lebih menarik) dibandingkan rata-rata. Karena sifat buatan dari sistem komputasi, nilai metrik sering kali menyimpang, misalnya, tidak ada permintaan yang dapat menerima respons dalam waktu kurang dari 0 ms, dan batas waktu 1000 ms berarti tidak mungkin ada respons yang berhasil dengan nilai yang lebih besar. daripada batas waktu. Akibatnya, kita tidak dapat menerima bahwa mean dan median bisa sama atau berdekatan!
Tanpa pengujian sebelumnya, dan kecuali asumsi dan perkiraan standar tertentu berlaku, kami berhati-hati untuk tidak menyimpulkan bahwa data kami terdistribusi secara normal. Jika distribusi tidak sesuai yang diharapkan, proses otomasi yang memperbaiki masalah (misalnya, ketika melihat outlier, proses ini memulai ulang server dengan latensi pemrosesan permintaan yang tinggi) mungkin melakukannya terlalu sering atau tidak cukup sering (keduanya tidak sangat bagus).
Standarisasi indikator
Kami merekomendasikan standarisasi karakteristik umum SLI sehingga Anda tidak perlu berspekulasi tentangnya setiap saat. Fitur apa pun yang memenuhi pola standar dapat dikecualikan dari spesifikasi SLI individual, misalnya:
- Interval agregasi: “rata-rata selama 1 menit”
- Area agregasi: “Semua tugas di cluster”
- Seberapa sering pengukuran dilakukan: “Setiap 10 detik”
- Permintaan apa yang diaktifkan: "HTTP GET dari pekerjaan pemantauan kotak hitam"
- Bagaimana data diperoleh: "Berkat pemantauan kami yang diukur di server"
- Latensi akses data: "Waktunya hingga byte terakhir"
Untuk menghemat tenaga, buat satu set templat SLI yang dapat digunakan kembali untuk setiap metrik umum; mereka juga memudahkan semua orang untuk memahami arti SLI tertentu.
Tujuan dalam praktik
Mulailah dengan memikirkan (atau mencari tahu!) apa yang menjadi perhatian pengguna Anda, bukan apa yang dapat Anda ukur. Seringkali apa yang menjadi perhatian pengguna Anda sulit atau tidak mungkin diukur, sehingga Anda akhirnya semakin mendekati kebutuhan mereka. Namun, jika Anda baru memulai dengan hal yang mudah diukur, Anda akan mendapatkan SLO yang kurang berguna. Sebagai hasilnya, terkadang kami menemukan bahwa mengidentifikasi tujuan yang diinginkan terlebih dahulu dan kemudian menggunakan indikator tertentu akan lebih baik daripada memilih indikator dan kemudian mencapai tujuan tersebut.
Tentukan tujuan
Agar lebih jelas, cara SLO diukur dan kondisi validnya harus ditentukan. Misalnya, kita dapat mengatakan hal berikut (baris kedua sama dengan baris pertama, namun menggunakan default SLI):
- 99% (rata-rata lebih dari 1 menit) panggilan Dapatkan RPC akan selesai dalam waktu kurang dari 100 md (diukur di seluruh server backend).
- 99% panggilan Dapatkan RPC akan selesai dalam waktu kurang dari 100 md.
Jika bentuk kurva kinerja penting, Anda dapat menentukan beberapa SLO:
- 90% panggilan Dapatkan RPC diselesaikan dalam waktu kurang dari 1 ms.
- 99% panggilan Dapatkan RPC diselesaikan dalam waktu kurang dari 10 ms.
- 99.9% panggilan Dapatkan RPC diselesaikan dalam waktu kurang dari 100 ms.
Jika pengguna Anda menghasilkan beban kerja yang heterogen: pemrosesan massal (yang memerlukan throughput) dan pemrosesan interaktif (yang memerlukan latensi), mungkin ada baiknya untuk menentukan sasaran terpisah untuk setiap kelas beban:
- 95% permintaan pelanggan memerlukan throughput. Atur jumlah panggilan RPC yang dieksekusi <1 detik.
- 99% klien peduli dengan latensi. Atur jumlah panggilan RPC dengan lalu lintas <1 KB dan berjalan <10 ms.
Adalah tidak realistis dan tidak diinginkan untuk memaksakan bahwa SLO akan dipenuhi 100% setiap saat: hal ini dapat mengurangi kecepatan pengenalan fungsi dan penerapan baru, serta memerlukan solusi yang mahal. Sebaliknya, lebih baik untuk memperhitungkan anggaran kesalahan - persentase waktu henti sistem yang diperbolehkan - dan memantau nilai ini setiap hari atau setiap minggu. Manajemen senior mungkin menginginkan evaluasi bulanan atau triwulanan. (Anggaran kesalahan hanyalah sebuah SLO untuk dibandingkan dengan SLO lainnya.)
Persentase pelanggaran SLO dapat dibandingkan dengan kesalahan anggaran (lihat Bab 3 dan bagian ), dengan nilai selisihnya digunakan sebagai masukan pada proses yang memutuskan kapan rilis baru akan disebarkan.
Memilih nilai target
Pemilihan nilai perencanaan (SLO) tidak semata-mata merupakan kegiatan teknis karena produk dan kepentingan bisnis harus tercermin dalam SLI, SLO (dan mungkin SLA) yang dipilih. Demikian pula, informasi mungkin perlu dipertukarkan mengenai isu-isu yang berkaitan dengan kepegawaian, waktu pemasaran, ketersediaan peralatan, dan pembiayaan. SRE harus menjadi bagian dari diskusi ini dan membantu memahami risiko dan kelayakan berbagai pilihan. Kami telah mengajukan beberapa pertanyaan yang mungkin dapat membantu memastikan diskusi yang lebih produktif:
Jangan memilih tujuan berdasarkan kinerja saat ini.
Meskipun memahami kekuatan dan batasan sistem itu penting, mengadaptasi metrik tanpa alasan dapat menghalangi Anda dalam memelihara sistem: hal ini memerlukan upaya heroik untuk mencapai tujuan yang tidak dapat dicapai tanpa desain ulang yang signifikan.
Jadilah sederhana
Perhitungan SLI yang rumit dapat menyembunyikan perubahan kinerja sistem dan mempersulit pencarian penyebab masalahnya.
Hindari yang absolut
Meskipun tergoda untuk memiliki sistem yang dapat menangani beban yang terus bertambah tanpa meningkatkan latensi, persyaratan ini tidak realistis. Sebuah sistem yang mendekati cita-cita tersebut kemungkinan akan memerlukan banyak waktu untuk merancang dan membangun, akan mahal untuk dioperasikan, dan akan terlalu baik untuk harapan pengguna yang akan melakukan sesuatu yang kurang dari itu.
Gunakan SLO sesedikit mungkin
Pilih jumlah SLO yang memadai untuk memastikan cakupan atribut sistem yang baik. Lindungi SLO yang Anda pilih: Jika Anda tidak pernah bisa memenangkan perdebatan tentang prioritas dengan menentukan SLO tertentu, mungkin tidak ada gunanya mempertimbangkan SLO tersebut. Namun, tidak semua atribut sistem dapat menerima SLO: sulit menghitung tingkat kepuasan pengguna menggunakan SLO.
Jangan mengejar kesempurnaan
Anda selalu dapat menyempurnakan definisi dan sasaran SLO dari waktu ke waktu seiring Anda mempelajari lebih lanjut perilaku sistem saat dimuat. Lebih baik memulai dengan tujuan mengambang yang akan Anda perbaiki seiring berjalannya waktu daripada memilih tujuan yang terlalu ketat yang harus dilonggarkan ketika Anda merasa tujuan tersebut tidak mungkin tercapai.
SLO dapat dan harus menjadi pendorong utama dalam memprioritaskan pekerjaan bagi SRE dan pengembang produk karena mencerminkan kepedulian terhadap pengguna. SLO yang baik adalah alat penegakan yang berguna bagi tim pengembangan. Namun SLO yang dirancang dengan buruk dapat mengakibatkan 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, gunakanlah dengan bijak.
Kontrol pengukuran Anda
SLI dan SLO adalah elemen kunci yang digunakan untuk mengelola sistem:
- Memantau dan mengukur sistem SLI.
- Bandingkan SLI dengan SLO dan putuskan apakah tindakan diperlukan.
- Jika tindakan diperlukan, cari tahu apa yang perlu dilakukan untuk mencapai tujuan.
- Selesaikan tindakan ini.
Misalnya, jika langkah 2 menunjukkan bahwa waktu permintaan habis dan akan merusak SLO dalam beberapa jam jika tidak ada yang dilakukan, langkah 3 mungkin melibatkan pengujian hipotesis bahwa server terikat pada CPU dan menambahkan lebih banyak server akan mendistribusikan beban. Tanpa SLO, Anda tidak akan tahu apakah (atau kapan) harus mengambil tindakan.
Tetapkan SLO - maka ekspektasi pengguna akan ditetapkan
Menerbitkan SLO menetapkan ekspektasi pengguna terhadap perilaku sistem. Pengguna (dan calon pengguna) sering kali ingin mengetahui apa yang diharapkan dari suatu layanan untuk memahami apakah layanan tersebut cocok untuk digunakan. Misalnya, orang yang ingin menggunakan situs web berbagi foto mungkin ingin menghindari penggunaan layanan yang menjanjikan umur panjang dan biaya rendah dengan imbalan ketersediaan yang sedikit lebih sedikit, meskipun layanan yang sama mungkin ideal untuk sistem manajemen arsip arsip.
Untuk menetapkan ekspektasi realistis bagi pengguna Anda, gunakan salah satu atau kedua taktik berikut:
- Pertahankan margin keamanan. Gunakan SLO internal yang lebih ketat daripada yang diiklankan kepada pengguna. Ini akan memberi Anda kesempatan untuk bereaksi terhadap masalah sebelum masalah tersebut terlihat secara eksternal. Buffer SLO juga memungkinkan Anda memiliki margin keamanan saat menginstal rilis yang memengaruhi kinerja sistem dan memastikan bahwa sistem mudah dipelihara tanpa harus membuat pengguna frustrasi karena waktu henti.
- Jangan melebihi ekspektasi pengguna. Pengguna didasarkan pada apa yang Anda tawarkan, bukan pada apa yang Anda katakan. Jika kinerja sebenarnya layanan Anda jauh lebih baik daripada SLO yang dinyatakan, pengguna akan mengandalkan kinerja saat ini. Anda dapat menghindari ketergantungan yang berlebihan dengan mematikan sistem secara sengaja atau membatasi kinerja pada beban ringan.
Memahami seberapa baik suatu sistem memenuhi harapan akan membantu memutuskan apakah akan berinvestasi dalam mempercepat sistem dan membuatnya lebih mudah diakses dan tangguh. Alternatifnya, jika suatu layanan berkinerja terlalu baik, sebagian waktu staf harus dihabiskan untuk prioritas lain, seperti melunasi utang teknis, menambah fitur baru, atau memperkenalkan produk baru.
Kesepakatan dalam praktiknya
Membuat SLA memerlukan tim bisnis dan hukum untuk menentukan konsekuensi dan hukuman jika melanggarnya. Peran SRE adalah membantu mereka memahami kemungkinan tantangan dalam memenuhi SLO yang terdapat dalam SLA. Sebagian besar rekomendasi untuk membuat SLO juga berlaku untuk SLA. Sebaiknya bersikap konservatif terhadap apa yang Anda janjikan kepada pengguna karena semakin banyak yang Anda miliki, semakin sulit mengubah atau menghapus SLA yang tampaknya tidak masuk akal atau sulit dipenuhi.
Terima kasih telah membaca terjemahannya sampai akhir. Berlangganan saluran telegram saya tentang pemantauan и .
Sumber: www.habr.com