SRE (Sayt ishonchliligi muhandisligi) veb-loyihalarning mavjudligini ta'minlashga qaratilgan yondashuvdir. U DevOps uchun asos hisoblanadi va DevOps amaliyotlarini qo'llashda muvaffaqiyatga qanday erishish mumkinligi haqida gapiradi. Ushbu maqoladagi tarjima 4-bob Xizmat darajasining maqsadlari kitoblar Sayt ishonchliligi muhandisligi Google'dan. Men bu tarjimani oʻzim tayyorladim va monitoring jarayonlarini tushunishda oʻz tajribamga tayandim. Telegram kanalida monitorim_it и Habré-dagi so'nggi xabar Men xizmat darajasining maqsadlari haqidagi o'sha kitobning 6-bobining tarjimasini ham nashr qildim.

Mushuk tomonidan tarjima. O'qishdan zavqlaning!

Qaysi ko'rsatkichlar haqiqatda muhimligini va ularni qanday o'lchash va baholashni tushunish bo'lmasa, xizmatni boshqarish mumkin emas. Shu maqsadda biz foydalanuvchilarimiz ichki API-larimizdan yoki ommaviy mahsulotdan foydalanishlaridan qat'i nazar, ularga ma'lum darajadagi xizmatni aniqlaymiz va taqdim etamiz.

Biz sezgi, tajribamiz va foydalanuvchilarning Xizmat darajasi ko'rsatkichlari (SLI), Xizmat darajasining maqsadlari (SLO) va Xizmat darajasi kelishuvlarini (SLAs) tushunish istagini tushunishimizdan foydalanamiz. Ushbu o'lchamlar biz kuzatmoqchi bo'lgan asosiy ko'rsatkichlarni tavsiflaydi va agar biz kutilgan xizmat sifatini ta'minlay olmasak, ularga munosabat bildiramiz. Oxir oqibat, to'g'ri ko'rsatkichlarni tanlash, agar biror narsa noto'g'ri bo'lsa, to'g'ri harakatlarni boshqarishga yordam beradi va SRE jamoasiga xizmatning sog'lig'iga ishonch beradi.

Ushbu bob biz metrik modellashtirish, metrik tanlash va metrik tahlil muammolariga qarshi kurashda foydalanadigan yondashuvni tavsiflaydi. Ko'pgina tushuntirishlar misollarsiz bo'ladi, shuning uchun biz asosiy fikrlarni ko'rsatish uchun uni amalga oshirish misolida tasvirlangan Shekspir xizmatidan foydalanamiz (Shekspir asarlarini qidirish).

Xizmat darajasi terminologiyasi

Ko'pgina o'quvchilar SLA tushunchasi bilan tanish bo'lishi mumkin, ammo SLI va SLO atamalari aniq ta'rifga loyiqdir, chunki umuman olganda SLA atamasi haddan tashqari yuklangan va kontekstga qarab bir qator ma'nolarga ega. Aniqlik uchun biz ushbu qiymatlarni ajratmoqchimiz.

Ko'rsatkichlar

SLI - bu xizmat ko'rsatish darajasi ko'rsatkichi - taqdim etilayotgan xizmatlar darajasining bir jihatining diqqat bilan belgilangan miqdoriy o'lchovidir.

Aksariyat xizmatlar uchun SLI kaliti so'rovning kechikishi hisoblanadi - so'rovga javob qaytarish uchun qancha vaqt ketadi. Boshqa keng tarqalgan SLIlar odatda qabul qilingan barcha so'rovlarning bir qismi sifatida ifodalangan xatolik darajasi va odatda soniyada so'rovlarda o'lchanadigan tizim o'tkazuvchanligini o'z ichiga oladi. O'lchovlar ko'pincha umumlashtiriladi: dastlabki ma'lumotlar yig'iladi va keyin o'zgarish tezligiga, o'rtacha yoki foizga aylantiriladi.

Ideal holda, SLI to'g'ridan-to'g'ri qiziqishning xizmat darajasini o'lchaydi, lekin ba'zida o'lchash uchun faqat tegishli ko'rsatkich mavjud, chunki asl nusxasini olish yoki izohlash qiyin. Masalan, mijoz tomonidagi kechikish ko'pincha mosroq ko'rsatkichdir, lekin ba'zida kechikish faqat serverda o'lchanishi mumkin.

SRE uchun muhim bo'lgan yana bir SLI turi mavjudlik yoki xizmatdan foydalanish mumkin bo'lgan vaqt qismidir. Ko'pincha muvaffaqiyatli so'rovlar tezligi sifatida aniqlanadi, ba'zan rentabellik deb ataladi. (Umr bo'yi - ma'lumotlarning uzoq vaqt davomida saqlanishi ehtimoli - ma'lumotlarni saqlash tizimlari uchun ham muhimdir.) Garchi 100% mavjud bo'lmasa-da, 100% ga yaqin mavjudlikka erishish mumkin; mavjudlik qiymatlari quyidagicha ifodalanadi. "to'qqiz" soni » mavjudligi foizi. Masalan, 99% va 99,999% mavjudligi "2 to'qqiz" va "5 to'qqiz" sifatida belgilanishi mumkin. Google Compute Engine’ning joriy mavjudlik maqsadi “uch yarim to‘qqiz” yoki 99,95%.

Maqsadlar

SLO - bu xizmat darajasining maqsadi: SLI tomonidan o'lchanadigan xizmat darajasi uchun maqsadli qiymat yoki qiymatlar diapazoni. SLO uchun oddiy qiymat “SLI ≤ Target” yoki “Quyi chegara ≤ SLI ≤ Yuqori chegara”dir. Masalan, SLO ni qidiruv soʻrovining oʻrtacha kechikish vaqti 100 millisekunddan kamroq qilib belgilab, Shekspir qidiruvi natijalarini “tezda” qaytarishga qaror qilishimiz mumkin.

To'g'ri SLOni tanlash murakkab jarayon. Birinchidan, har doim ham ma'lum bir qiymatni tanlay olmaysiz. Xizmatingizga tashqi kiruvchi HTTP soʻrovlari uchun soniyada soʻrov (QPS) koʻrsatkichi birinchi navbatda foydalanuvchilaringizning xizmatingizga tashrif buyurish istagi bilan belgilanadi va siz buning uchun SLO oʻrnatolmaysiz.

Boshqa tomondan, har bir so'rov uchun o'rtacha kechikish 100 millisekunddan kam bo'lishini xohlayotganingizni aytishingiz mumkin. Bunday maqsadni qo'yish sizni past kechikish bilan frontend yozishga yoki bunday kechikishni ta'minlaydigan uskunani sotib olishga majbur qilishi mumkin. (100 millisekund - bu ixtiyoriy raqam, lekin undan ham past kechikish raqamlariga ega bo'lish yaxshiroqdir. Tez sur'atlar sekin tezlikdan yaxshiroq ekanligi va foydalanuvchi so'rovlarini ma'lum qiymatlardan yuqori bo'lgan kechikish odamlarni uzoqroq turishga majbur qilishini ko'rsatadigan dalillar mavjud. sizning xizmatingizdan.)

Shunga qaramay, bu birinchi qarashda ko'rinadiganidan ko'ra noaniqroq: siz QPSni hisob-kitobdan butunlay chiqarib tashlamasligingiz kerak. Gap shundaki, QPS va kechikish bir-biri bilan chambarchas bog'liq: yuqori QPS ko'pincha yuqori kechikishlarga olib keladi va xizmatlar odatda ma'lum bir yuklanish chegarasiga yetganda unumdorlikning keskin pasayishiga olib keladi.

SLOni tanlash va nashr etish foydalanuvchining xizmat qanday ishlashi haqidagi taxminlarini belgilaydi. Ushbu strategiya xizmat egasiga nisbatan sekin ishlash kabi asossiz shikoyatlarni kamaytirishi mumkin. Aniq SLO bo'lmasa, foydalanuvchilar ko'pincha kerakli ishlash haqida o'zlarining taxminlarini yaratadilar, bu xizmatni loyihalash va boshqarayotgan odamlarning fikriga hech qanday aloqasi bo'lmasligi mumkin. Bu holat, foydalanuvchilar xizmatdan ko'ra ko'proq foydalanish imkoniyatiga ega bo'ladi, deb noto'g'ri o'ylashganda, xizmatdan kutilayotgan umidlarning oshishiga olib kelishi mumkin va foydalanuvchilar tizim haqiqatdan ko'ra kamroq ishonchli ekanligiga ishonchsizlikni keltirib chiqarishi mumkin.

Shartnomalar

Xizmat koʻrsatish darajasi boʻyicha kelishuv foydalanuvchilar bilan tuzilgan aniq yoki yashirin shartnoma boʻlib, ularda mavjud boʻlgan SLOlarga javob berish (yoki ularga rioya qilmaslik) oqibatlarini oʻz ichiga oladi. Natijalar eng oson moliyaviy bo'lganda tan olinadi - chegirma yoki jarima - lekin ular boshqa shakllarda bo'lishi mumkin. SLO va SLA o'rtasidagi farq haqida gapirishning oson usuli "agar SLOlar bajarilmasa nima bo'ladi?" Deb so'rashdir. Agar aniq oqibatlar bo'lmasa, siz SLOga deyarli qaraysiz.

SRE odatda SLA yaratishda ishtirok etmaydi, chunki SLA biznes va mahsulot qarorlari bilan chambarchas bog'liq. Biroq, SRE muvaffaqiyatsiz SLO oqibatlarini yumshatishda ishtirok etadi. Ular, shuningdek, SLIni aniqlashda yordam berishi mumkin: Shubhasiz, shartnomada SLOni o'lchashning ob'ektiv usuli bo'lishi kerak yoki kelishmovchilik bo'ladi.

Google Qidiruv umumiy SLAga ega boʻlmagan muhim xizmatga misoldir: biz hamma Qidiruvdan imkon qadar samarali foydalanishini istaymiz, lekin biz dunyo bilan shartnoma imzolaganimiz yoʻq. Biroq, agar qidiruv mavjud bo'lmasa, hali ham oqibatlar mavjud - mavjud bo'lmaslik bizning obro'-e'tiborimizni pasaytiradi, shuningdek, reklama daromadini kamaytiradi. Google for Work kabi boshqa koʻplab Google xizmatlarida foydalanuvchilar bilan aniq xizmat darajasidagi shartnomalar mavjud. Muayyan xizmatda SLA mavjudmi yoki yo'qligidan qat'i nazar, SLI va SLOni aniqlash va ulardan xizmatni boshqarish uchun foydalanish muhimdir.

Juda ko'p nazariya - endi tajriba.

Amalda ko'rsatkichlar

Xizmat darajasini o'lchash uchun tegishli ko'rsatkichlarni tanlash muhim degan xulosaga kelganimizni hisobga olsak, xizmat yoki tizim uchun qaysi ko'rsatkichlar muhimligini endi qanday bilasiz?

Siz va sizning foydalanuvchilaringiz nimaga qiziqadi?

Monitoring tizimida kuzatishingiz mumkin bo'lgan har bir ko'rsatkichni SLI sifatida ishlatishingiz shart emas; Foydalanuvchilarning tizimdan nimani xohlashlarini tushunish bir nechta ko'rsatkichlarni tanlashga yordam beradi. Juda ko'p ko'rsatkichlarni tanlash muhim ko'rsatkichlarga e'tibor qaratishni qiyinlashtiradi, kichik sonni tanlash esa tizimingizning katta qismlarini qarovsiz qoldirishi mumkin. Tizimning sog'lig'ini baholash va tushunish uchun odatda bir nechta asosiy ko'rsatkichlardan foydalanamiz.

Xizmatlar, odatda, ularga tegishli bo'lgan SLI nuqtai nazaridan bir necha qismlarga bo'linishi mumkin:

• Bizning misolimizdagi Shekspir xizmati uchun qidiruv interfeyslari kabi maxsus old tizimlar. Ular mavjud bo'lishi kerak, kechikishlar bo'lmasligi va etarli tarmoqli kengligi bo'lishi kerak. Shunga ko'ra, savollar berilishi mumkin: so'rovga javob bera olamizmi? So'rovga javob berish uchun qancha vaqt kerak bo'ldi? Qancha so'rovni ko'rib chiqish mumkin?
• Saqlash tizimlari. Ular javobning past kechikishi, mavjudligi va chidamliligini qadrlashadi. Tegishli savollar: Ma'lumotlarni o'qish yoki yozish uchun qancha vaqt ketadi? So'rov bo'yicha ma'lumotlarga kira olamizmi? Bizga kerak bo'lganda ma'lumotlar mavjudmi? Ushbu masalalarni batafsil muhokama qilish uchun 26-bobga qarang: Ma'lumotlar yaxlitligi: Siz o'qigan narsangiz siz yozgan narsadir.
• Ma'lumotlarni qayta ishlash quvurlari kabi katta ma'lumotlar tizimlari o'tkazish qobiliyati va so'rovlarni qayta ishlash kechikishiga tayanadi. Tegishli savollar: Qancha ma'lumotlar qayta ishlanadi? Ma'lumotlar so'rovni qabul qilishdan javob berishgacha qancha vaqt oladi? (Tizimning ba'zi qismlarida ma'lum bosqichlarda kechikishlar ham bo'lishi mumkin.)

Ko'rsatkichlar to'plami

Ko'pgina xizmat ko'rsatish darajasining ko'rsatkichlari eng tabiiy ravishda Borgmon kabi monitoring tizimi yordamida server tomonida to'planadi (pastga qarang). 10-bob Vaqt seriyasi ma'lumotlariga asoslangan amaliyot ogohlantirishlari) yoki Prometey, yoki oddiygina vaqti-vaqti bilan jurnallarni tahlil qilish, 500 holatiga ega HTTP javoblarini aniqlash. Biroq, ba'zi tizimlar mijoz tomonidan ko'rsatkichlar to'plami bilan jihozlangan bo'lishi kerak, chunki mijoz tomonidan monitoringning etishmasligi ta'sir qiladigan bir qator muammolarni yo'qotishiga olib kelishi mumkin. foydalanuvchilar, lekin server tomoni ko'rsatkichlariga ta'sir qilmaydi. Misol uchun, Shekspir qidiruvi test ilovamizning backend javob kechikishiga e'tibor qaratish JavaScript muammolari tufayli foydalanuvchi tomonida kechikishga olib kelishi mumkin: bu holda brauzer sahifani qayta ishlash uchun qancha vaqt ketishini o'lchash yaxshiroq ko'rsatkichdir.

Birlashtirish

Oddiylik va foydalanish qulayligi uchun biz ko'pincha xom o'lchovlarni birlashtiramiz. Bu ehtiyotkorlik bilan bajarilishi kerak.

Ba'zi ko'rsatkichlar sekundiga so'rovlar kabi oddiy ko'rinadi, ammo bu oddiy ko'rinadigan o'lchov ham vaqt o'tishi bilan ma'lumotlarni to'playdi. O'lchov soniyada bir marta olinadimi yoki o'lchov daqiqada so'rovlar soni bo'yicha o'rtacha hisoblanadimi? Oxirgi variant faqat bir necha soniya davom etadigan so'rovlarning ko'p sonini yashirishi mumkin. Juft raqamlar bilan soniyada 200 ta so'rovga xizmat ko'rsatadigan tizimni ko'rib chiqaylik, qolgan vaqtda esa 0. O'rtacha qiymat ko'rinishidagi doimiy sekundiga 100 ta so'rov va ikki baravar lahzali yuk bir xil narsa emas. Xuddi shunday, so'rovlarning o'rtacha kechikishlari jozibador ko'rinishi mumkin, lekin u muhim tafsilotni yashiradi: ko'pchilik so'rovlar tez bo'lishi mumkin, lekin sekin so'rovlar ko'p bo'ladi.

Aksariyat ko'rsatkichlar o'rtacha emas, balki taqsimot sifatida ko'riladi. Misol uchun, SLI kechikishi uchun ba'zi so'rovlar tezda qayta ishlanadi, ba'zilari esa har doim uzoqroq, ba'zan esa ancha uzoqroq davom etadi. Oddiy o'rtacha bu uzoq kechikishlarni yashirishi mumkin. Rasmda misol ko'rsatilgan: odatiy so'rovga xizmat ko'rsatish uchun taxminan 50 ms vaqt kerak bo'lsa-da, so'rovlarning 5% 20 baravar sekinroq! Faqat o'rtacha kechikishga asoslangan monitoring va ogohlantirish kun davomida xatti-harakatlardagi o'zgarishlarni ko'rsatmaydi, aslida ba'zi so'rovlarni qayta ishlash vaqtida sezilarli o'zgarishlar mavjud (eng yuqori qator).

50, 85, 95 va 99 foizli tizim kechikishi. Y o'qi logarifmik formatda.

Ko'rsatkichlar uchun foizlardan foydalanish taqsimot shakli va uning xususiyatlarini ko'rish imkonini beradi: 99 yoki 99,9 kabi yuqori foizli daraja eng yomon qiymatni ko'rsatadi, 50 foizli (shuningdek, median deb ham ataladi) eng tez-tez uchraydigan holatni ko'rsatadi. metrik. Javob vaqtining tarqalishi qanchalik katta bo'lsa, shunchalik uzoq davom etadigan so'rovlar foydalanuvchi tajribasiga ta'sir qiladi. Effekt yuqori yuk ostida va navbatlar mavjudligida kuchayadi. Foydalanuvchilar tajribasini o'rganish shuni ko'rsatdiki, odamlar odatda yuqori javob vaqti farqiga ega sekinroq tizimni afzal ko'radilar, shuning uchun ba'zi SRE guruhlari faqat yuqori foizli ballarga e'tibor qaratishadi, chunki agar metrikaning 99,9 foizdagi harakati yaxshi bo'lsa, ko'pchilik foydalanuvchilar muammoga duch kelmaydilar. .

Statistik xatolar haqida eslatma

Biz odatda qiymatlar to'plamining o'rtacha (arifmetik o'rtacha) emas, balki foizlar bilan ishlashni afzal ko'ramiz. Bu ko'pincha o'rtacha ko'rsatkichdan sezilarli darajada farq qiladigan (va qiziqarliroq) xususiyatlarga ega bo'lgan ko'proq tarqalgan qiymatlarni ko'rib chiqishga imkon beradi. Hisoblash tizimlarining sun'iy tabiati tufayli metrik qiymatlar ko'pincha egri bo'ladi, masalan, hech qanday so'rov 0 ms dan kamroq vaqt ichida javob ololmaydi va 1000 ms vaqt tugashi kattaroq qiymatlar bilan muvaffaqiyatli javoblar bo'lmasligini anglatadi. vaqt tugashidan ko'ra. Natijada, biz o'rtacha va median bir xil yoki bir-biriga yaqin bo'lishi mumkinligini qabul qila olmaymiz!

Oldindan sinovdan o'tkazmasdan va ba'zi bir standart taxminlar va taxminlar mavjud bo'lmasa, biz ma'lumotlarimiz normal taqsimlangan degan xulosaga kelmaslikdan ehtiyot bo'lamiz. Agar tarqatish kutilganidek bo'lmasa, muammoni hal qiladigan avtomatlashtirish jarayoni (masalan, u chetlab o'tilganlarni ko'rganda, serverni yuqori so'rovlarni qayta ishlash kechikishlari bilan qayta ishga tushiradi) buni juda tez-tez yoki tez-tez bajarayotgan bo'lishi mumkin (ikkalasi ham emas). juda yaxshi).

Ko'rsatkichlarni standartlashtirish

Biz SLI uchun umumiy xususiyatlarni standartlashtirishni tavsiya qilamiz, shunda siz har safar ular haqida spekulyatsiya qilishingiz shart emas. Standart namunalarga javob beradigan har qanday xususiyat alohida SLI spetsifikatsiyasidan chiqarib tashlanishi mumkin, masalan:

• Birlashtirish intervallari: "o'rtacha 1 daqiqadan ko'proq"
• Yig'ish joylari: "Klasterdagi barcha vazifalar"
• O'lchovlar qanchalik tez-tez amalga oshiriladi: "Har 10 soniyada"
• Qaysi so'rovlar kiritilgan: "Qora quti monitoringi ishlaridan HTTP GET"
• Ma'lumotlar qanday olinadi: "Serverda o'lchangan monitoringimiz tufayli"
• Ma'lumotlarga kirishning kechikishi: "Oxirgi baytgacha bo'lgan vaqt"

Harakatni tejash uchun har bir umumiy ko'rsatkich uchun qayta foydalanish mumkin bo'lgan SLI shablonlari to'plamini yarating; ular, shuningdek, har bir kishi uchun ma'lum bir SLI nimani anglatishini tushunishni osonlashtiradi.

Amaliyotdagi maqsadlar

Siz o'lchashingiz mumkin bo'lgan narsalarni emas, balki foydalanuvchilaringiz nimani qiziqtirayotgani haqida o'ylab (yoki bilib oling!) boshlang. Ko'pincha sizning foydalanuvchilaringiz nimani qiziqtirayotganini o'lchash qiyin yoki imkonsizdir, shuning uchun siz ularning ehtiyojlariga yaqinlashasiz. Biroq, agar siz o'lchash oson bo'lgan narsadan boshlasangiz, siz kamroq foydali SLOlarga ega bo'lasiz. Natijada, biz ba'zida dastlab kerakli maqsadlarni aniqlash va keyin aniq ko'rsatkichlar bilan ishlash ko'rsatkichlarni tanlash va keyin maqsadlarga erishishdan ko'ra yaxshiroq ishlashini aniqladik.

Maqsadlaringizni aniqlang

Maksimal ravshanlik uchun SLOlar qanday o'lchanishi va ular amal qilish shartlari aniqlanishi kerak. Masalan, biz quyidagilarni aytishimiz mumkin (ikkinchi qator birinchisi bilan bir xil, lekin SLI standartlaridan foydalanadi):

• Get RPC qo‘ng‘iroqlarining 99% (o‘rtacha 1 daqiqadan ko‘proq) 100 ms dan kamroq vaqt ichida yakunlanadi (barcha backend serverlarida o‘lchanadi).
• Get RPC qo‘ng‘iroqlarining 99% 100 ms dan kamroq vaqt ichida yakunlanadi.

Agar ishlash egri chizig'ining shakli muhim bo'lsa, siz bir nechta SLOni belgilashingiz mumkin:

• Get RPC qo‘ng‘iroqlarining 90% 1 ms dan kamroq vaqt ichida yakunlandi.
• Get RPC qo‘ng‘iroqlarining 99% 10 ms dan kamroq vaqt ichida yakunlandi.
• Get RPC qo‘ng‘iroqlarining 99.9% 100 ms dan kamroq vaqt ichida yakunlandi.

Agar sizning foydalanuvchilaringiz turli xil ish yuklarini yaratsa: ommaviy qayta ishlash (o'tkazish qobiliyati muhim) va interaktiv ishlov berish (buning uchun kechikish muhim), har bir yuk klassi uchun alohida maqsadlarni belgilash maqsadga muvofiq bo'lishi mumkin:

• Mijozlarning so'rovlarining 95% o'tkazish qobiliyatini talab qiladi. Bajarilgan RPC qo'ng'iroqlari sonini o'rnating <1 s.
• Mijozlarning 99 foizi kechikish haqida qayg'uradilar. Trafik <1 KB va <10 ms ishlayotgan RPC qo'ng'iroqlari sonini o'rnating.

SLO 100% bajariladi, deb turib olish noreal va nomaqbuldir: bu yangi funksionallikni joriy etish va joylashtirish tezligini kamaytirishi va qimmat echimlarni talab qilishi mumkin. Buning o'rniga, xato byudjetiga ruxsat berish yaxshidir - tizimning ruxsat etilgan ishlamay qolish foizi - va bu qiymatni har kuni yoki haftada kuzatib boring. Yuqori rahbariyat oylik yoki choraklik baholarni talab qilishi mumkin. (Xatolar byudjeti boshqa SLO bilan solishtirish uchun oddiygina SLO hisoblanadi.)

SLO buzilishining foizini xato byudjeti bilan solishtirish mumkin (3-bob va bo'limga qarang "Xato byudjetlari uchun motivatsiya"), yangi nashrlarni qachon joylashtirishni hal qiluvchi jarayonga kirish sifatida foydalaniladigan farq qiymati bilan.

Maqsadli qiymatlarni tanlash

Rejalashtirish qiymatlarini (SLO) tanlash faqat texnik faoliyat emas, chunki mahsulot va biznes manfaatlari tanlangan SLI, SLO (va, ehtimol, SLA) da aks ettirilishi kerak. Xuddi shunday, xodimlar bilan ta'minlash, bozorga chiqish vaqti, uskunalar mavjudligi va moliyalashtirish bilan bog'liq masalalar bo'yicha ma'lumot almashish kerak bo'lishi mumkin. SRE ushbu suhbatning bir qismi bo'lishi va turli xil variantlarning xavflari va hayotiyligini tushunishga yordam berishi kerak. Biz samaraliroq muhokamani ta'minlashga yordam beradigan bir nechta savollar bilan chiqdik:

Maqsadni joriy natijalarga qarab tanlamang.
Tizimning kuchli tomonlari va chegaralarini tushunish muhim bo'lsa-da, o'lchovlarni asossiz moslashtirish tizimni saqlab qolishingizga to'sqinlik qilishi mumkin: bu muhim qayta loyihalashsiz erishib bo'lmaydigan maqsadlarga erishish uchun qahramonona harakatlarni talab qiladi.

Oddiy qilib qo'ying
Murakkab SLI hisob-kitoblari tizim ishlashidagi o'zgarishlarni yashirishi va muammoning sababini topishni qiyinlashtirishi mumkin.

Mutlaqlardan saqlaning
Kechikish vaqtini oshirmasdan, cheksiz o'sib borayotgan yukni bartaraf eta oladigan tizimga ega bo'lish jozibali bo'lsa-da, bu talab haqiqatga to'g'ri kelmaydi. Bunday ideallarga yaqinlashadigan tizim loyihalash va qurish uchun ko'p vaqt talab qilishi, ishlashi qimmat bo'lishi va undan kam narsa bilan shug'ullanadigan foydalanuvchilarning umidlari uchun juda yaxshi bo'lishi mumkin.

Iloji boricha kamroq SLOlardan foydalaning
Tizim atributlarini yaxshi qamrab olishni ta'minlash uchun etarli miqdordagi SLOlarni tanlang. Siz tanlagan SLOlarni himoya qiling: Agar siz hech qachon ma'lum bir SLOni ko'rsatib, ustuvorliklar bo'yicha bahsda g'alaba qozona olmasangiz, bu SLOni ko'rib chiqishning hojati yo'q. Biroq, barcha tizim atributlari SLO uchun mos emas: SLOlar yordamida foydalanuvchi zavq darajasini hisoblash qiyin.

Mukammallikka intilmang
Tizimning yuk ostidagi xatti-harakati haqida ko'proq ma'lumotga ega bo'lganingizda, vaqt o'tishi bilan SLO ta'riflari va maqsadlarini har doim aniqlab olishingiz mumkin. O'zingiz erishib bo'lmaydigan darajada bo'shashishi kerak bo'lgan haddan tashqari qattiq maqsadni tanlagandan ko'ra, vaqt o'tishi bilan aniqlab beradigan suzuvchi maqsaddan boshlagan ma'qul.

SLOlar SRE va mahsulotni ishlab chiquvchilar uchun ishlarni ustuvorlashtirishda asosiy omil bo'lishi mumkin va bo'lishi kerak, chunki ular foydalanuvchilarning tashvishini aks ettiradi. Yaxshi SLO - bu rivojlanish guruhi uchun foydali qo'llash vositasi. Ammo noto'g'ri ishlab chiqilgan SLO, agar jamoa haddan tashqari tajovuzkor SLOga erishish uchun qahramonona harakatlar qilsa yoki SLO juda past bo'lsa, yomon mahsulot isrofgarchilikka olib kelishi mumkin. SLO - bu kuchli tutqich, undan oqilona foydalaning.

O'lchovlaringizni boshqaring

SLI va SLO tizimlarni boshqarish uchun ishlatiladigan asosiy elementlardir:

• SLI tizimlarini kuzatish va o'lchash.
• SLIni SLO bilan solishtiring va harakat zarurligini hal qiling.
• Agar harakat zarur bo'lsa, maqsadga erishish uchun nima qilish kerakligini aniqlang.
• Ushbu amalni bajaring.

Misol uchun, agar 2-qadam so'rovning vaqti tugashini ko'rsatsa va hech narsa qilinmasa, SLO bir necha soat ichida buziladi, 3-bosqichda serverlar protsessor bilan bog'langanligi haqidagi farazni sinab ko'rish va qo'shimcha serverlarni qo'shish yukni taqsimlashni o'z ichiga olishi mumkin. SLO bo'lmasa, siz harakat qilishni (yoki qachon) bilmaysiz.

SLO o'rnating - keyin foydalanuvchi taxminlari o'rnatiladi
SLOni nashr qilish foydalanuvchining tizim xatti-harakatlari uchun kutishlarini belgilaydi. Foydalanuvchilar (va potentsial foydalanuvchilar) ko'pincha xizmatdan foydalanish uchun mos yoki yo'qligini tushunish uchun undan nimani kutish kerakligini bilishni xohlashadi. Misol uchun, fotosurat almashish veb-saytidan foydalanmoqchi bo'lganlar, bir xil xizmat arxiv yozuvlarini boshqarish tizimi uchun ideal bo'lishi mumkin bo'lsa-da, uzoq umr va arzon narxlarni va'da qiladigan xizmatdan foydalanishdan qochishlari mumkin.

Foydalanuvchilaringiz uchun haqiqiy taxminlarni belgilash uchun quyidagi taktikalardan birini yoki ikkalasini qo'llang:

• Xavfsizlik chegarasini saqlang. Foydalanuvchilarga e'lon qilinganidan ko'ra qattiqroq ichki SLOdan foydalaning. Bu sizga muammolarga tashqi ko'rinishdan oldin javob berish imkoniyatini beradi. SLO buferi, shuningdek, tizimning ishlashiga ta'sir qiluvchi relizlarni o'rnatishda xavfsizlik chegarasiga ega bo'lish imkonini beradi va foydalanuvchilarning ishlamay qolish vaqtidan xafa bo'lmasdan tizimni oson saqlashni ta'minlaydi.
• Foydalanuvchi kutganidan oshmang. Foydalanuvchilar siz aytgan narsaga emas, balki siz taklif qilgan narsangizga asoslanadi. Agar xizmatingizning haqiqiy ishlashi belgilangan SLOdan ancha yaxshi bo'lsa, foydalanuvchilar joriy ishlashga tayanadi. Tizimni ataylab o'chirib qo'yish yoki engil yuk ostida ishlashni cheklash orqali ortiqcha qaramlikdan qochishingiz mumkin.

Tizimning kutilgan natijalarga qanchalik mos kelishini tushunish tizimni tezlashtirish va uni yanada qulayroq va bardoshli qilish uchun mablag 'sarflash to'g'risida qaror qabul qilishga yordam beradi. Shu bilan bir qatorda, agar xizmat juda yaxshi ishlayotgan bo'lsa, xodimlarning bir qismi texnik qarzni to'lash, yangi xususiyatlarni qo'shish yoki yangi mahsulotlarni joriy qilish kabi boshqa ustuvorliklarga sarflanishi kerak.

Amalda kelishuvlar

SLA yaratish biznes va yuridik guruhlardan uni buzganlik uchun oqibatlar va jazolarni belgilashni talab qiladi. SRE ning roli ularga SLAdagi SLOlarni qondirishda yuzaga kelishi mumkin bo'lgan qiyinchiliklarni tushunishga yordam berishdir. SLO yaratish bo'yicha tavsiyalarning aksariyati SLA uchun ham qo'llaniladi. Foydalanuvchilarga va'da qilgan narsada konservativ bo'lish oqilona, ​​chunki sizda qancha ko'p bo'lsa, mantiqsiz yoki qondirish qiyin bo'lib ko'rinadigan SLAlarni o'zgartirish yoki olib tashlash shunchalik qiyin bo'ladi.

Tarjimani oxirigacha o'qiganingiz uchun rahmat. Monitoring haqida mening telegram kanalimga obuna bo'ling monitorim_it и O'rtadagi blog.

Manba: www.habr.com