SRE (Site Reliability Engineering) ialah pendekatan untuk memastikan ketersediaan projek web. Ia dianggap sebagai rangka kerja untuk DevOps dan bercakap tentang cara mencapai kejayaan dalam menggunakan amalan DevOps. Terjemahan dalam artikel ini buku daripada Google. Saya menyediakan terjemahan ini sendiri dan bergantung kepada pengalaman saya sendiri dalam memahami proses pemantauan. Dalam saluran telegram и Saya juga menerbitkan terjemahan Bab 6 buku yang sama tentang matlamat tahap perkhidmatan.
Terjemahan oleh kucing. Selamat membaca!
Adalah mustahil untuk menguruskan perkhidmatan jika tiada pemahaman tentang penunjuk yang sebenarnya penting dan cara mengukur dan menilainya. Untuk tujuan ini, kami menentukan dan menyediakan tahap perkhidmatan tertentu kepada pengguna kami, tidak kira sama ada mereka menggunakan salah satu API dalaman kami atau produk awam.
Kami menggunakan intuisi, pengalaman dan pemahaman kami tentang keinginan pengguna untuk memahami Petunjuk Tahap Perkhidmatan (SLI), Objektif Tahap Perkhidmatan (SLO) dan Perjanjian Tahap Perkhidmatan (SLA). Dimensi ini menerangkan metrik utama yang ingin kami pantau dan kami akan bertindak balas jika kami tidak dapat memberikan kualiti perkhidmatan yang diharapkan. Akhirnya, memilih metrik yang betul membantu membimbing tindakan yang betul jika berlaku kesilapan, dan juga memberi keyakinan kepada pasukan SRE terhadap kesihatan perkhidmatan.
Bab ini menerangkan pendekatan yang kami gunakan untuk memerangi masalah pemodelan metrik, pemilihan metrik dan analisis metrik. Kebanyakan penjelasan akan tanpa contoh, jadi kami akan menggunakan perkhidmatan Shakespeare yang diterangkan dalam contoh pelaksanaannya (cari karya Shakespeare) untuk menggambarkan perkara utama.
Terminologi peringkat perkhidmatan
Ramai pembaca berkemungkinan biasa dengan konsep SLA, tetapi istilah SLI dan SLO patut ditakrifkan dengan teliti kerana secara umum istilah SLA terlampau beban dan mempunyai beberapa makna bergantung pada konteksnya. Untuk kejelasan, kami ingin memisahkan nilai ini.
Petunjuk
SLI ialah penunjuk tahap perkhidmatan—ukuran kuantitatif yang ditakrifkan dengan teliti bagi satu aspek tahap perkhidmatan yang disediakan.
Untuk kebanyakan perkhidmatan, SLI utama dianggap sebagai kependaman permintaan - berapa lama masa yang diperlukan untuk mengembalikan respons kepada permintaan. SLI biasa lain termasuk kadar ralat, sering dinyatakan sebagai sebahagian kecil daripada semua permintaan yang diterima, dan daya pemprosesan sistem, biasanya diukur dalam permintaan sesaat. Pengukuran selalunya diagregatkan: data mentah mula-mula dikumpul dan kemudian ditukar kepada kadar perubahan, min atau persentil.
Sebaik-baiknya, SLI mengukur secara langsung tahap perkhidmatan yang diminati, tetapi kadangkala hanya metrik yang berkaitan tersedia untuk pengukuran kerana yang asal sukar diperoleh atau ditafsirkan. Sebagai contoh, kependaman sisi klien selalunya merupakan metrik yang lebih sesuai, tetapi ada kalanya kependaman hanya boleh diukur pada pelayan.
Satu lagi jenis SLI yang penting kepada SRE ialah ketersediaan, atau bahagian masa semasa sesuatu perkhidmatan boleh digunakan. Selalunya ditakrifkan sebagai kadar permintaan yang berjaya, kadangkala dipanggil hasil. (Seumur hidup—kemungkinan data akan disimpan untuk tempoh masa yang panjang—juga penting untuk sistem storan data.) Walaupun ketersediaan 100% tidak mungkin, ketersediaan hampir 100% selalunya boleh dicapai; nilai ketersediaan dinyatakan sebagai bilangan "sembilan" » peratusan ketersediaan. Sebagai contoh, ketersediaan 99% dan 99,999% mungkin dilabelkan sebagai "2 sembilan" dan "5 sembilan". Matlamat ketersediaan semasa Google Compute Engine yang dinyatakan ialah "tiga setengah sembilan" atau 99,95%.
Objektif
SLO ialah objektif tahap perkhidmatan: nilai sasaran atau julat nilai untuk tahap perkhidmatan yang diukur oleh SLI. Nilai biasa untuk SLO ialah “SLI ≤ Sasaran” atau “Had Bawah ≤ SLI ≤ Had Atas”. Sebagai contoh, kami mungkin memutuskan bahawa kami akan mengembalikan hasil carian Shakespeare "cepat" dengan menetapkan SLO kepada purata kependaman pertanyaan carian kurang daripada 100 milisaat.
Memilih SLO yang betul adalah proses yang kompleks. Pertama, anda tidak boleh selalu memilih nilai tertentu. Untuk permintaan HTTP masuk luaran kepada perkhidmatan anda, metrik Query Per Second (QPS) ditentukan terutamanya oleh keinginan pengguna anda untuk melawat perkhidmatan anda dan anda tidak boleh menetapkan SLO untuk itu.
Sebaliknya, anda boleh mengatakan bahawa anda mahukan kependaman purata untuk setiap permintaan kurang daripada 100 milisaat. Menetapkan matlamat sedemikian mungkin memaksa anda untuk menulis bahagian hadapan anda dengan kependaman rendah atau membeli peralatan yang menyediakan kependaman sedemikian. (100 milisaat jelas merupakan nombor sewenang-wenangnya, tetapi lebih baik untuk mempunyai nombor kependaman yang lebih rendah. Terdapat bukti yang menunjukkan bahawa kelajuan pantas adalah lebih baik daripada kelajuan perlahan, dan kependaman dalam memproses permintaan pengguna melebihi nilai tertentu sebenarnya memaksa orang untuk menjauhkan diri daripada perkhidmatan anda.)
Sekali lagi, ini lebih samar-samar daripada yang kelihatan pada pandangan pertama: anda tidak seharusnya mengecualikan QPS sepenuhnya daripada pengiraan. Hakikatnya ialah QPS dan kependaman sangat berkait antara satu sama lain: QPS yang lebih tinggi sering membawa kepada kependaman yang lebih tinggi, dan perkhidmatan biasanya mengalami penurunan mendadak dalam prestasi apabila mereka mencapai ambang beban tertentu.
Memilih dan menerbitkan SLO menetapkan jangkaan pengguna tentang cara perkhidmatan tersebut akan beroperasi. Strategi ini boleh mengurangkan aduan yang tidak berasas terhadap pemilik perkhidmatan, seperti prestasi yang perlahan. Tanpa SLO yang jelas, pengguna sering mencipta jangkaan mereka sendiri tentang prestasi yang diingini, yang mungkin tiada kaitan dengan pendapat orang yang mereka bentuk dan mengurus perkhidmatan. Keadaan ini boleh membawa kepada jangkaan yang melambung daripada perkhidmatan, apabila pengguna tersilap percaya bahawa perkhidmatan itu akan lebih mudah diakses daripada yang sebenarnya, dan menyebabkan ketidakpercayaan apabila pengguna percaya bahawa sistem itu kurang dipercayai daripada yang sebenarnya.
Perjanjian
Perjanjian tahap perkhidmatan ialah kontrak tersurat atau tersirat dengan pengguna anda yang merangkumi akibat daripada memenuhi (atau tidak memenuhi) SLO yang terkandung di dalamnya. Akibat paling mudah dikenali apabila ia adalah kewangan—diskaun atau denda—tetapi ia boleh dalam bentuk lain. Cara mudah untuk bercakap tentang perbezaan antara SLO dan SLA adalah dengan bertanya "apa yang berlaku jika SLO tidak dipenuhi?" Jika tiada akibat yang jelas, anda hampir pasti melihat SLO.
SRE biasanya tidak terlibat dalam mencipta SLA kerana SLA berkait rapat dengan keputusan perniagaan dan produk. SRE, bagaimanapun, terlibat dalam membantu mengurangkan akibat kegagalan SLO. Mereka juga boleh membantu menentukan SLI: Jelas sekali, mesti ada cara objektif untuk mengukur SLO dalam perjanjian atau akan berlaku perselisihan faham.
Carian Google ialah contoh perkhidmatan penting yang tidak mempunyai SLA awam: kami mahu semua orang menggunakan Carian secekap mungkin, tetapi kami belum menandatangani kontrak dengan dunia. Walau bagaimanapun, masih terdapat akibat jika carian tidak tersedia - ketidaksediaan mengakibatkan kejatuhan dalam reputasi kami serta mengurangkan hasil pengiklanan. Banyak perkhidmatan Google yang lain, seperti Google for Work, mempunyai perjanjian tahap perkhidmatan yang jelas dengan pengguna. Tidak kira sama ada perkhidmatan tertentu mempunyai SLA, adalah penting untuk menentukan SLI dan SLO dan menggunakannya untuk mengurus perkhidmatan.
Begitu banyak teori - sekarang untuk dialami.
Penunjuk dalam amalan
Memandangkan kami telah membuat kesimpulan bahawa adalah penting untuk memilih metrik yang sesuai untuk mengukur tahap perkhidmatan, bagaimanakah anda kini mengetahui metrik mana yang penting untuk perkhidmatan atau sistem?
Apakah yang anda dan pengguna anda ambil berat tentang?
Anda tidak perlu menggunakan setiap metrik sebagai SLI yang boleh anda jejaki dalam sistem pemantauan; Memahami perkara yang pengguna inginkan daripada sistem akan membantu anda memilih beberapa metrik. Memilih terlalu banyak penunjuk menyukarkan untuk menumpukan pada penunjuk penting, manakala memilih nombor yang kecil boleh meninggalkan sebahagian besar sistem anda tanpa pengawasan. Kami biasanya menggunakan beberapa penunjuk utama untuk menilai dan memahami kesihatan sistem.
Perkhidmatan secara amnya boleh dipecahkan kepada beberapa bahagian dari segi SLI yang berkaitan dengannya:
- Sistem bahagian hadapan tersuai, seperti antara muka carian untuk perkhidmatan Shakespeare daripada contoh kami. Ia mesti tersedia, tiada kelewatan dan mempunyai lebar jalur yang mencukupi. Sehubungan itu, soalan boleh ditanya: bolehkah kami menjawab permintaan itu? Berapa lama masa yang diambil untuk menjawab permintaan itu? Berapa banyak permintaan boleh diproses?
- Sistem storan. Mereka menghargai kependaman respons rendah, ketersediaan dan ketahanan. Soalan berkaitan: Berapa lama masa yang diambil untuk membaca atau menulis data? Bolehkah kami mengakses data atas permintaan? Adakah data tersedia apabila kita memerlukannya? Lihat Bab 26 Integriti Data: Apa yang Anda Baca Adalah Apa yang Anda Tulis untuk perbincangan terperinci tentang isu-isu ini.
- Sistem data besar seperti saluran paip pemprosesan data bergantung pada kependaman pemprosesan dan pemprosesan pertanyaan. Soalan berkaitan: Berapa banyak data yang diproses? Berapa lamakah masa yang diambil untuk data bergerak daripada menerima permintaan kepada mengeluarkan respons? (Sesetengah bahagian sistem juga mungkin mengalami kelewatan dalam peringkat tertentu.)
Pengumpulan penunjuk
Banyak penunjuk tahap perkhidmatan dikumpulkan secara semula jadi pada bahagian pelayan, menggunakan sistem pemantauan seperti Borgmon (lihat di bawah). ) atau Prometheus, atau hanya menganalisis log secara berkala, mengenal pasti respons HTTP dengan status 500. Walau bagaimanapun, sesetengah sistem harus dilengkapi dengan pengumpulan metrik pihak pelanggan, kerana kekurangan pemantauan pihak pelanggan boleh menyebabkan kehilangan beberapa masalah yang menjejaskan pengguna, tetapi tidak menjejaskan metrik sebelah pelayan. Sebagai contoh, memfokuskan pada kependaman respons bahagian belakang aplikasi ujian carian Shakespeare kami boleh mengakibatkan kependaman pada bahagian pengguna disebabkan oleh isu JavaScript: dalam kes ini, mengukur tempoh masa penyemak imbas memproses halaman adalah metrik yang lebih baik.
Pengagregatan
Untuk kesederhanaan dan kemudahan penggunaan, kami sering mengagregatkan ukuran mentah. Ini mesti dilakukan dengan berhati-hati.
Sesetengah metrik kelihatan mudah, seperti permintaan sesaat, tetapi walaupun ukuran yang nampaknya mudah ini secara tersirat mengagregatkan data dari semasa ke semasa. Adakah ukuran diterima secara khusus sekali sesaat atau adakah ukuran dipuratakan berbanding bilangan permintaan seminit? Pilihan terakhir boleh menyembunyikan bilangan permintaan segera yang lebih tinggi yang hanya bertahan beberapa saat. Pertimbangkan sistem yang menyediakan 200 permintaan sesaat dengan nombor genap dan 0 sepanjang masa. Pemalar dalam bentuk nilai purata 100 permintaan sesaat dan dua kali ganda beban serta-merta bukanlah perkara yang sama. Begitu juga, purata kependaman pertanyaan mungkin kelihatan menarik, tetapi ia menyembunyikan butiran penting: ada kemungkinan kebanyakan pertanyaan akan pantas, tetapi akan terdapat banyak pertanyaan yang perlahan.
Kebanyakan penunjuk lebih baik dilihat sebagai pengagihan dan bukannya purata. Contohnya, untuk kependaman SLI, sesetengah permintaan akan diproses dengan cepat, manakala sesetengahnya akan sentiasa mengambil masa yang lebih lama, kadangkala lebih lama. Purata mudah boleh menyembunyikan kelewatan yang panjang ini. Rajah menunjukkan contoh: walaupun permintaan biasa mengambil masa kira-kira 50 ms untuk disiarkan, 5% daripada permintaan adalah 20 kali lebih perlahan! Pemantauan dan makluman hanya berdasarkan kependaman purata tidak menunjukkan perubahan dalam tingkah laku sepanjang hari, sedangkan sebenarnya terdapat perubahan ketara dalam masa pemprosesan beberapa permintaan (baris paling atas).
Kependaman sistem 50, 85, 95 dan 99 persentil. Paksi Y adalah dalam format logaritma.
Menggunakan persentil untuk penunjuk membolehkan anda melihat bentuk taburan dan cirinya: tahap persentil yang tinggi, seperti 99 atau 99,9, menunjukkan nilai yang paling teruk, manakala 50 persentil (juga dikenali sebagai median) menunjukkan keadaan yang paling kerap metrik. Lebih besar penyebaran masa tindak balas, lebih banyak permintaan jangka panjang memberi kesan kepada pengalaman pengguna. Kesannya dipertingkatkan di bawah beban tinggi dan dengan kehadiran barisan. Penyelidikan pengalaman pengguna telah menunjukkan bahawa orang biasanya lebih suka sistem yang lebih perlahan dengan varians masa tindak balas yang tinggi, jadi sesetengah pasukan SRE hanya menumpukan pada skor persentil yang tinggi, atas dasar bahawa jika tingkah laku metrik pada persentil 99,9 adalah baik, kebanyakan pengguna tidak akan mengalami masalah. .
Nota tentang ralat statistik
Kami biasanya lebih suka bekerja dengan persentil daripada min (min aritmetik) bagi satu set nilai. Ini membolehkan kami mempertimbangkan lebih banyak nilai yang tersebar, yang selalunya mempunyai ciri yang berbeza secara ketara (dan lebih menarik) daripada purata. Disebabkan sifat buatan sistem pengkomputeran, nilai metrik sering terpesong, sebagai contoh, tiada permintaan boleh menerima respons dalam masa kurang daripada 0 ms, dan tamat masa 1000 ms bermakna tidak boleh ada respons yang berjaya dengan nilai yang lebih besar. daripada tamat masa. Akibatnya, kita tidak boleh menerima bahawa min dan median boleh sama atau hampir antara satu sama lain!
Tanpa ujian terlebih dahulu, dan melainkan andaian dan anggaran standard tertentu dipegang, kami berhati-hati untuk tidak membuat kesimpulan bahawa data kami diedarkan secara normal. Jika pengedaran tidak seperti yang dijangkakan, proses automasi yang membetulkan masalah (contohnya, apabila ia melihat outlier, ia memulakan semula pelayan dengan kependaman pemprosesan permintaan tinggi) mungkin melakukannya terlalu kerap atau tidak cukup kerap (kedua-duanya tidak sangat bagus).
Seragamkan penunjuk
Kami mengesyorkan menyeragamkan ciri umum untuk SLI supaya anda tidak perlu membuat spekulasi mengenainya setiap masa. Sebarang ciri yang memenuhi corak standard boleh dikecualikan daripada spesifikasi SLI individu, contohnya:
- Selang pengagregatan: "purata melebihi 1 minit"
- Kawasan pengagregatan: "Semua tugas dalam kelompok"
- Kekerapan pengukuran diambil: "Setiap 10 saat"
- Apakah permintaan yang disertakan: "HTTP GET daripada kerja pemantauan kotak hitam"
- Cara data diperoleh: "Terima kasih kepada pemantauan kami yang diukur pada pelayan"
- Kependaman akses data: "Masa untuk bait terakhir"
Untuk menjimatkan usaha, buat satu set templat SLI boleh guna semula untuk setiap metrik biasa; mereka juga memudahkan semua orang memahami maksud SLI tertentu.
Matlamat dalam amalan
Mulakan dengan memikirkan (atau mengetahui!) perkara yang pengguna anda ambil berat, bukan perkara yang boleh anda ukur. Selalunya perkara yang penting bagi pengguna anda adalah sukar atau mustahil untuk diukur, jadi anda akhirnya semakin hampir dengan keperluan mereka. Walau bagaimanapun, jika anda hanya bermula dengan perkara yang mudah diukur, anda akan mendapat SLO yang kurang berguna. Akibatnya, kami kadangkala mendapati bahawa pada mulanya mengenal pasti matlamat yang diingini dan kemudian bekerja dengan penunjuk tertentu berfungsi lebih baik daripada memilih penunjuk dan kemudian mencapai matlamat.
Tentukan matlamat anda
Untuk kejelasan maksimum, ia harus ditakrifkan bagaimana SLO diukur dan keadaan di mana ia sah. Sebagai contoh, kita boleh mengatakan yang berikut (baris kedua adalah sama dengan yang pertama, tetapi menggunakan lalai SLI):
- 99% (purata lebih 1 minit) panggilan Dapatkan RPC akan selesai dalam masa kurang daripada 100ms (diukur merentas semua pelayan bahagian belakang).
- 99% daripada panggilan Get RPC akan selesai dalam masa kurang daripada 100ms.
Jika bentuk lengkung prestasi adalah penting, anda boleh menentukan berbilang SLO:
- 90% daripada Dapatkan panggilan RPC diselesaikan dalam masa kurang daripada 1 ms.
- 99% daripada Dapatkan panggilan RPC diselesaikan dalam masa kurang daripada 10 ms.
- 99.9% daripada Dapatkan panggilan RPC diselesaikan dalam masa kurang daripada 100 ms.
Jika pengguna anda menjana beban kerja yang heterogen: pemprosesan pukal (yang pemprosesannya penting) dan pemprosesan interaktif (yang kependamannya penting), mungkin berbaloi untuk menentukan matlamat berasingan untuk setiap kelas beban:
- 95% permintaan pelanggan memerlukan pemprosesan. Tetapkan kiraan panggilan RPC yang dilaksanakan <1 s.
- 99% pelanggan mengambil berat tentang kependaman. Tetapkan kiraan panggilan RPC dengan trafik <1 KB dan berjalan <10 ms.
Adalah tidak realistik dan tidak diingini untuk menegaskan bahawa SLO akan dipenuhi 100% setiap masa: ini boleh mengurangkan kadar memperkenalkan fungsi dan penggunaan baharu, dan memerlukan penyelesaian yang mahal. Sebaliknya, adalah lebih baik untuk membenarkan belanjawan ralat - peratusan masa henti sistem yang dibenarkan - dan memantau nilai ini setiap hari atau mingguan. Pengurusan kanan mungkin mahukan penilaian bulanan atau suku tahunan. (Bajet ralat hanyalah SLO untuk perbandingan dengan SLO lain.)
Peratusan pelanggaran SLO boleh dibandingkan dengan belanjawan ralat (lihat Bab 3 dan bahagian ), dengan nilai perbezaan digunakan sebagai input kepada proses yang menentukan masa untuk menggunakan keluaran baharu.
Memilih nilai sasaran
Memilih nilai perancangan (SLO) bukanlah aktiviti teknikal semata-mata kerana kepentingan produk dan perniagaan yang mesti ditunjukkan dalam SLI, SLO (dan mungkin SLA) terpilih. Begitu juga, maklumat mungkin perlu ditukar mengenai isu yang berkaitan dengan kakitangan, masa ke pasaran, ketersediaan peralatan dan pembiayaan. SRE harus menjadi sebahagian daripada perbualan ini dan membantu memahami risiko dan daya maju pilihan yang berbeza. Kami telah mengemukakan beberapa soalan yang mungkin membantu memastikan perbincangan yang lebih produktif:
Jangan pilih matlamat berdasarkan prestasi semasa.
Walaupun memahami kekuatan dan had sistem adalah penting, menyesuaikan metrik tanpa alasan boleh menghalang anda daripada mengekalkan sistem: ia memerlukan usaha heroik untuk mencapai matlamat yang tidak boleh dicapai tanpa reka bentuk semula yang ketara.
Pastikan ia mudah
Pengiraan SLI yang kompleks boleh menyembunyikan perubahan dalam prestasi sistem dan menjadikannya lebih sukar untuk mencari punca masalah.
Elakkan perkara mutlak
Walaupun ia menggoda untuk mempunyai sistem yang boleh mengendalikan beban yang semakin meningkat tanpa had tanpa meningkatkan kependaman, keperluan ini adalah tidak realistik. Sistem yang mendekati cita-cita sedemikian mungkin memerlukan banyak masa untuk mereka bentuk dan membina, akan mahal untuk dikendalikan, dan akan terlalu baik untuk jangkaan pengguna yang akan melakukan apa-apa yang kurang.
Gunakan sesedikit mungkin SLO
Pilih bilangan SLO yang mencukupi untuk memastikan liputan yang baik bagi atribut sistem. Lindungi SLO yang anda pilih: Jika anda tidak boleh memenangi hujah tentang keutamaan dengan menyatakan SLO tertentu, ia mungkin tidak berbaloi untuk mempertimbangkan SLO itu. Walau bagaimanapun, tidak semua atribut sistem boleh diterima oleh SLO: adalah sukar untuk mengira tahap keseronokan pengguna menggunakan SLO.
Jangan mengejar kesempurnaan
Anda sentiasa boleh memperhalusi definisi dan matlamat SLO dari semasa ke semasa sambil anda mengetahui lebih lanjut tentang gelagat sistem di bawah beban. Adalah lebih baik untuk memulakan dengan matlamat terapung yang akan anda perhalusi dari semasa ke semasa daripada memilih matlamat yang terlalu ketat yang perlu dilonggarkan apabila anda mendapati matlamat itu tidak dapat dicapai.
SLO boleh dan harus menjadi pemacu utama dalam mengutamakan kerja untuk SRE dan pembangun produk kerana ia mencerminkan kebimbangan terhadap pengguna. SLO yang baik ialah alat penguatkuasaan yang berguna untuk pasukan pembangunan. Tetapi SLO yang direka bentuk dengan buruk boleh membawa kepada kerja yang membazir jika pasukan melakukan usaha heroik untuk mencapai SLO yang terlalu agresif, atau produk yang buruk jika SLO terlalu rendah. SLO ialah tuas yang berkuasa, gunakannya dengan bijak.
Kawal ukuran anda
SLI dan SLO ialah elemen utama yang digunakan untuk mengurus sistem:
- Memantau dan mengukur sistem SLI.
- Bandingkan SLI dengan SLO dan tentukan sama ada tindakan diperlukan.
- Jika tindakan diperlukan, fikirkan apa yang perlu berlaku untuk mencapai matlamat.
- Selesaikan tindakan ini.
Sebagai contoh, jika langkah 2 menunjukkan bahawa permintaan sedang tamat masa dan akan memecahkan SLO dalam beberapa jam jika tiada apa yang dilakukan, langkah 3 mungkin melibatkan ujian hipotesis bahawa pelayan terikat CPU dan menambah lebih banyak pelayan akan mengagihkan beban . Tanpa SLO, anda tidak akan tahu sama ada (atau bila) untuk mengambil tindakan.
Tetapkan SLO - maka jangkaan pengguna akan ditetapkan
Menerbitkan SLO menetapkan jangkaan pengguna untuk tingkah laku sistem. Pengguna (dan bakal pengguna) selalunya ingin mengetahui apa yang diharapkan daripada perkhidmatan untuk memahami sama ada ia sesuai untuk digunakan. Contohnya, orang yang ingin menggunakan tapak web perkongsian foto mungkin ingin mengelak daripada menggunakan perkhidmatan yang menjanjikan jangka hayat dan kos rendah sebagai pertukaran untuk ketersediaan yang kurang sedikit, walaupun perkhidmatan yang sama mungkin sesuai untuk sistem pengurusan rekod arkib.
Untuk menetapkan jangkaan yang realistik untuk pengguna anda, gunakan satu atau kedua-dua taktik berikut:
- Kekalkan margin keselamatan. Gunakan SLO dalaman yang lebih ketat daripada yang diiklankan kepada pengguna. Ini akan memberi anda peluang untuk bertindak balas terhadap masalah sebelum ia kelihatan secara luaran. Penampan SLO juga membolehkan anda mempunyai margin keselamatan apabila memasang keluaran yang menjejaskan prestasi sistem dan memastikan sistem mudah diselenggara tanpa perlu mengecewakan pengguna dengan masa henti.
- Jangan melebihi jangkaan pengguna. Pengguna adalah berdasarkan apa yang anda tawarkan, bukan apa yang anda katakan. Jika prestasi sebenar perkhidmatan anda jauh lebih baik daripada SLO yang dinyatakan, pengguna akan bergantung pada prestasi semasa. Anda boleh mengelakkan terlalu bergantung dengan sengaja menutup sistem atau mengehadkan prestasi di bawah beban ringan.
Memahami sejauh mana sistem memenuhi jangkaan membantu memutuskan sama ada untuk melabur dalam mempercepatkan sistem dan menjadikannya lebih mudah diakses dan berdaya tahan. Sebagai alternatif, jika perkhidmatan berprestasi terlalu baik, beberapa masa kakitangan harus dibelanjakan untuk keutamaan lain, seperti membayar hutang teknikal, menambah ciri baharu atau memperkenalkan produk baharu.
Perjanjian dalam amalan
Mencipta SLA memerlukan pasukan perniagaan dan undang-undang untuk menentukan akibat dan penalti kerana melanggarnya. Peranan SRE adalah untuk membantu mereka memahami kemungkinan cabaran dalam memenuhi SLO yang terkandung dalam SLA. Kebanyakan pengesyoran untuk membuat SLO juga digunakan untuk SLA. Adalah bijak untuk bersikap konservatif dalam perkara yang anda janjikan kepada pengguna kerana semakin banyak yang anda miliki, semakin sukar untuk menukar atau mengalih keluar SLA yang kelihatan tidak munasabah atau sukar untuk dipenuhi.
Terima kasih kerana membaca terjemahan hingga habis. Langgan saluran telegram saya tentang pemantauan и .
Sumber: www.habr.com