SRE (Site Reliability Engineering) veb-layihələrin mövcudluğunu təmin etmək üçün bir yanaşmadır. Bu, DevOps üçün çərçivə hesab olunur və DevOps təcrübələrini tətbiq etməkdə uğur qazanmağın yolları haqqında danışır. Bu məqalədə tərcümə kitablar Google-dan. Mən bu tərcüməni özüm hazırladım və monitorinq proseslərini başa düşməkdə öz təcrübəmə əsaslandım. Telegram kanalında и Mən həmçinin xidmət səviyyəsinin məqsədləri haqqında həmin kitabın 6-cı fəslinin tərcüməsini nəşr etdim.
Pişik tərəfindən tərcümə. Oxumaqdan həzz alın!
Hansı göstəricilərin faktiki əhəmiyyət kəsb etdiyini və onları necə ölçmək və qiymətləndirmək barədə heç bir anlayış yoxdursa, xidməti idarə etmək mümkün deyil. Bu məqsədlə biz istifadəçilərimizə daxili API-lərimizdən birini və ya ictimai məhsulu istifadə etmələrindən asılı olmayaraq müəyyən xidmət səviyyəsini müəyyənləşdirir və təqdim edirik.
Biz intuisiyamızdan, təcrübəmizdən və istifadəçilərin Xidmət Səviyyəsi Göstəricilərini (SLI), Xidmət Səviyyəsi Məqsədlərini (SLO) və Xidmət Səviyyəsi Müqavilələrini (SLAs) anlamaq istəyinə dair anlayışımızdan istifadə edirik. Bu ölçülər nəzarət etmək istədiyimiz və gözlənilən xidmət keyfiyyətini təmin edə bilməsək, reaksiya verəcəyimiz əsas ölçüləri təsvir edir. Nəhayət, düzgün ölçülərin seçilməsi bir şey səhv olarsa, düzgün hərəkətləri istiqamətləndirməyə kömək edir və həmçinin SRE komandasına xidmətin sağlamlığına inam verir.
Bu fəsil metrik modelləşdirmə, metrik seçim və metrik analiz problemləri ilə mübarizə aparmaq üçün istifadə etdiyimiz yanaşmanı təsvir edir. İzahatın əksəriyyəti misalsız olacaq, ona görə də əsas məqamları göstərmək üçün onun həyata keçirilməsi nümunəsində təsvir olunan Şekspir xidmətindən istifadə edəcəyik (Şekspirin əsərlərini axtarın).
Xidmət səviyyəsinin terminologiyası
Çoxsaylı oxucular SLA anlayışı ilə yəqin ki, tanışdırlar, lakin SLI və SLO terminləri diqqətli tərifə layiqdir, çünki ümumilikdə SLA termini həddən artıq yüklənir və kontekstdən asılı olaraq bir sıra mənalara malikdir. Aydınlıq üçün bu dəyərləri ayırmaq istəyirik.
Göstəricilər
SLI xidmət səviyyəsinin göstəricisidir - göstərilən xidmət səviyyəsinin bir aspektinin diqqətlə müəyyən edilmiş kəmiyyət ölçüsüdür.
Əksər xidmətlər üçün əsas SLI sorğunun gecikməsi hesab olunur - sorğuya cavabın qaytarılması nə qədər vaxt alır. Digər ümumi SLI-lərə adətən alınan bütün sorğuların bir hissəsi kimi ifadə edilən səhv dərəcəsi və adətən saniyədə sorğularla ölçülən sistem ötürmə qabiliyyəti daxildir. Ölçmələr çox vaxt birləşdirilir: ilkin məlumat toplanır və sonra dəyişiklik sürətinə, orta və ya faizə çevrilir.
İdeal olaraq, SLI birbaşa maraq göstərən xidmət səviyyəsini ölçür, lakin bəzən orijinalı əldə etmək və ya şərh etmək çətin olduğu üçün ölçmək üçün yalnız müvafiq metrik mövcuddur. Məsələn, müştəri tərəfində gecikmə çox vaxt daha uyğun metrikdir, lakin gecikmənin yalnız serverdə ölçülə bildiyi vaxtlar olur.
SRE-lər üçün vacib olan digər SLI növü əlçatanlıq və ya xidmətin istifadə oluna biləcəyi vaxt hissəsidir. Tez-tez uğurlu sorğuların dərəcəsi kimi müəyyən edilir, bəzən gəlir deyilir. (Həyat boyu—məlumatların uzun müddət saxlanılma ehtimalı—məlumat saxlama sistemləri üçün də vacibdir.) 100% əlçatanlıq mümkün olmasa da, 100%-ə yaxın əlçatanlıq çox vaxt əldə edilir; əlçatanlıq dəyərləri aşağıdakı kimi ifadə edilir. "doqquzların" sayı » mövcudluq faizi. Məsələn, 99% və 99,999% əlçatanlıq "2 doqquz" və "5 doqquz" kimi etiketlənə bilər. Google Hesablama Mühərrikinin hazırkı bildirilmiş əlçatanlıq məqsədi "üç yarım doqquz" və ya 99,95% təşkil edir.
Məqsədlər
SLO xidmət səviyyəsinin məqsədidir: SLI tərəfindən ölçülən xidmət səviyyəsi üçün hədəf dəyər və ya dəyərlər diapazonu. SLO üçün normal dəyər “SLI ≤ Target” və ya “Aşağı Limit ≤ SLI ≤ Yuxarı Limit”dir. Məsələn, SLO-nu 100 millisaniyədən az orta axtarış sorğusu gecikməsinə təyin etməklə Şekspir axtarış nəticələrini “sürətlə” qaytaracağımıza qərar verə bilərik.
Düzgün SLO seçmək mürəkkəb prosesdir. Birincisi, həmişə müəyyən bir dəyər seçə bilməzsiniz. Xidmətinizə xaricdən daxil olan HTTP sorğuları üçün Saniyədə Sorğu (QPS) göstəricisi ilk növbədə istifadəçilərinizin xidmətinizə daxil olmaq istəyi ilə müəyyən edilir və siz bunun üçün SLO təyin edə bilməzsiniz.
Digər tərəfdən, hər sorğu üçün orta gecikmənin 100 millisaniyədən az olmasını istədiyinizi söyləyə bilərsiniz. Belə bir məqsəd qoymaq sizi aşağı gecikmə ilə frontend yazmağa və ya belə gecikmə təmin edən avadanlıq almağa məcbur edə bilər. (100 millisaniyə açıq-aydın ixtiyari bir rəqəmdir, lakin daha da aşağı gecikmə rəqəmlərinə sahib olmaq daha yaxşıdır. Sürətli sürətlərin yavaş sürətlərdən daha yaxşı olduğuna dair sübutlar var və müəyyən dəyərlərdən yuxarı olan istifadəçi sorğularının işlənməsində gecikmə əslində insanları uzaq durmağa məcbur edir. xidmətinizdən.)
Yenə də bu, ilk baxışdan göründüyündən daha qeyri-müəyyəndir: QPS-i hesablamadan tamamilə çıxarmamalısınız. Fakt budur ki, QPS və gecikmə bir-biri ilə sıx bağlıdır: daha yüksək QPS tez-tez daha yüksək gecikmələrə səbəb olur və xidmətlər müəyyən bir yükləmə həddinə çatdıqda performansda kəskin azalma yaşayır.
SLO-nun seçilməsi və dərc edilməsi istifadəçinin xidmətin necə işləyəcəyi ilə bağlı gözləntilərini müəyyən edir. Bu strategiya yavaş performans kimi xidmət sahibinə qarşı əsassız şikayətləri azalda bilər. Açıq SLO olmadan, istifadəçilər tez-tez istənilən performansla bağlı öz gözləntilərini yaradırlar ki, bu da xidməti dizayn edən və idarə edən insanların fikirləri ilə heç bir əlaqəsi olmaya bilər. Bu vəziyyət, istifadəçilər səhvən xidmətin olduğundan daha əlçatan olacağına inandıqları zaman xidmətdən gözləntilərin artmasına və istifadəçilər sistemin olduğundan daha az etibarlı olduğuna inandıqda inamsızlığa səbəb ola bilər.
Müqavilələr
Xidmət səviyyəsi müqaviləsi istifadəçilərinizlə olan açıq və ya gizli müqavilədir ki, bu da onların tərkibində olan SLO-lara cavab vermənin (və ya cavab verməməsinin) nəticələrini ehtiva edir. Nəticələr ən asan maliyyə olduqda tanınır - endirim və ya cərimə - lakin onlar başqa formalarda ola bilər. SLO-lar və SLA-lar arasındakı fərq haqqında danışmağın asan yolu “SLO-lar yerinə yetirilmədikdə nə baş verir?” sualını verməkdir. Əgər aydın nəticələr yoxdursa, demək olar ki, SLO-ya baxırsınız.
SRE adətən SLA-ların yaradılmasında iştirak etmir, çünki SLA-lar biznes və məhsul qərarları ilə sıx bağlıdır. Bununla belə, SRE uğursuz SLO-ların nəticələrini yumşaltmağa kömək etməkdə iştirak edir. Onlar həmçinin SLI-ni müəyyən etməyə kömək edə bilərlər: Aydındır ki, razılaşmada SLO-nu ölçməyin obyektiv yolu olmalıdır, əks halda fikir ayrılığı yaranacaq.
Google Axtarış ictimai SLA-ya malik olmayan mühüm xidmətin nümunəsidir: biz hamının Axtarışdan mümkün qədər səmərəli istifadə etməsini istəyirik, lakin biz dünya ilə müqavilə imzalamamışıq. Bununla belə, axtarış mümkün olmadıqda hələ də nəticələr var - əlçatmazlıq reputasiyamızın aşağı düşməsinə, eləcə də reklam gəlirlərinin azalmasına səbəb olur. Google for Work kimi bir çox digər Google xidmətlərinin istifadəçilərlə açıq xidmət səviyyəsi müqavilələri var. Müəyyən bir xidmətin SLA-nın olub-olmamasından asılı olmayaraq, SLI və SLO-nu müəyyən etmək və xidməti idarə etmək üçün onlardan istifadə etmək vacibdir.
Bu qədər nəzəriyyə - indi təcrübə.
Təcrübədə olan göstəricilər
Xidmət səviyyəsini ölçmək üçün müvafiq ölçüləri seçməyin vacib olduğu qənaətinə gəldiyimizi nəzərə alsaq, indi hansı göstəricilərin xidmət və ya sistem üçün vacib olduğunu necə bilirsiniz?
Sizi və istifadəçilərinizi nə maraqlandırır?
Monitorinq sistemində izləyə biləcəyiniz hər bir metrikanı SLI kimi istifadə etməyə ehtiyac yoxdur; İstifadəçilərin sistemdən nə istədiklərini anlamaq sizə bir neçə göstərici seçməyə kömək edəcək. Həddindən artıq çox göstərici seçmək diqqəti vacib göstəricilərə yönəltməyi çətinləşdirir, az sayda seçmək isə sisteminizin böyük hissələrini nəzarətsiz qoya bilər. Sistemin sağlamlığını qiymətləndirmək və anlamaq üçün adətən bir neçə əsas göstəricidən istifadə edirik.
Xidmətlər, ümumiyyətlə, onlara aid olan SLI baxımından bir neçə hissəyə bölünə bilər:
- Bizim nümunəmizdən Şekspir xidməti üçün axtarış interfeysləri kimi fərdi ön sistem sistemləri. Onlar mövcud olmalı, gecikmələri olmamalıdır və kifayət qədər bant genişliyinə malik olmalıdırlar. Buna uyğun olaraq suallar verilə bilər: sorğuya cavab verə bilərikmi? Müraciətə cavab vermək üçün nə qədər vaxt lazım oldu? Nə qədər sorğu emal edilə bilər?
- Saxlama sistemləri. Onlar aşağı cavab gecikməsini, əlçatanlığı və davamlılığı qiymətləndirirlər. Əlaqədar suallar: Məlumatı oxumaq və ya yazmaq nə qədər vaxt aparır? Sorğu əsasında məlumatlara daxil ola bilərikmi? Məlumat ehtiyac duyduğumuz zaman mövcuddurmu? Bu məsələlərin təfərrüatlı müzakirəsi üçün 26-cı Fəsil Məlumat Dürüstlüyü: Oxuduqlarınız Yazdığınızdır.
- Məlumat emal boru kəmərləri kimi böyük məlumat sistemləri ötürmə qabiliyyətinə və sorğuların emal gecikməsinə əsaslanır. Əlaqədar suallar: Nə qədər məlumat emal olunur? Sorğunun alınmasından cavabın verilməsinə qədər məlumatların keçməsi nə qədər vaxt aparır? (Sistemin bəzi hissələrində müəyyən mərhələlərdə gecikmələr də ola bilər.)
Göstəricilərin toplanması
Bir çox xidmət səviyyəsi göstəriciləri ən təbii olaraq Borgmon kimi monitorinq sistemindən istifadə etməklə server tərəfində toplanır (aşağıya bax). ) və ya Prometheus, və ya sadəcə olaraq jurnalların vaxtaşırı təhlili, 500 statuslu HTTP cavablarının müəyyən edilməsi. Bununla belə, bəzi sistemlər müştəri tərəfi ölçülər toplusu ilə təchiz edilməlidir, çünki müştəri tərəfində monitorinqin olmaması təsir edən bir sıra problemlərin itməsinə səbəb ola bilər. istifadəçilər, lakin server tərəfi ölçülərinə təsir etmir. Məsələn, Şekspir axtarış test proqramımızın backend cavab gecikməsinə diqqət yetirmək JavaScript problemlərinə görə istifadəçi tərəfində gecikmə ilə nəticələnə bilər: bu halda brauzerin səhifəni emal etməsi üçün nə qədər vaxt tələb etdiyini ölçmək daha yaxşı göstəricidir.
Toplama
Sadəlik və istifadə rahatlığı üçün biz tez-tez xam ölçmələri birləşdiririk. Bu diqqətlə edilməlidir.
Bəzi ölçülər saniyədə sorğular kimi sadə görünür, lakin hətta bu zahirən sadə ölçmə zamanla məlumatları gizli şəkildə cəmləşdirir. Ölçmə xüsusi olaraq saniyədə bir dəfə alınır və ya ölçmə dəqiqədə sorğuların sayına görə orta hesablanır? Sonuncu seçim yalnız bir neçə saniyə davam edən daha çox ani sorğuları gizlədə bilər. Cüt nömrələrlə saniyədə 200 sorğuya, qalan vaxtda isə 0-a xidmət edən sistemi nəzərdən keçirək. Saniyədə 100 sorğu və iki dəfə ani yükün orta dəyəri şəklində bir sabit eyni şey deyil. Eynilə, sorğuların ortalama gecikmə müddətləri cəlbedici görünə bilər, lakin bu, vacib bir detalı gizlədir: sorğuların əksəriyyətinin sürətli olması mümkündür, lakin yavaş olan sorğular da çox olacaqdır.
Əksər göstəricilərə orta göstəricilərdən daha çox paylanma kimi baxılır. Məsələn, SLI gecikməsi üçün bəzi sorğular tez işləniləcək, bəziləri isə həmişə daha uzun, bəzən isə daha uzun çəkəcək. Sadə bir ortalama bu uzun gecikmələri gizlədə bilər. Şəkil bir nümunə göstərir: adi sorğuya xidmət etmək üçün təxminən 50 ms vaxt tələb olunsa da, sorğuların 5%-i 20 dəfə yavaşdır! Yalnız orta gecikməyə əsaslanan monitorinq və xəbərdarlıq gün ərzində davranış dəyişikliklərini göstərmir, əslində bəzi sorğuların işlənmə müddətində nəzərəçarpacaq dəyişikliklər olur (ən yuxarı xətt).
50, 85, 95 və 99 faizlik sistem gecikməsi. Y oxu loqarifmik formatdadır.
Göstəricilər üçün faizlərdən istifadə paylanmanın formasını və onun xüsusiyyətlərini görməyə imkan verir: 99 və ya 99,9 kimi yüksək faiz dərəcəsi ən pis dəyəri, 50 faizlik isə (həmçinin median kimi tanınır) ən çox rast gəlinən vəziyyəti göstərir. metrik. Cavab müddəti nə qədər çox olarsa, bir o qədər uzunmüddətli sorğular istifadəçi təcrübəsinə təsir edir. Effekt yüksək yük altında və növbələrin mövcudluğunda gücləndirilir. İstifadəçi təcrübəsi araşdırması göstərdi ki, insanlar adətən yüksək cavab müddəti dəyişkənliyi ilə daha yavaş sistemə üstünlük verirlər, buna görə də bəzi SRE komandaları 99,9 faizlik göstəricinin davranışı yaxşı olarsa, əksər istifadəçilər problem yaşamayacağına əsaslanaraq yalnız yüksək faizli ballara diqqət yetirirlər. .
Statistik səhvlər haqqında qeyd
Biz, ümumiyyətlə, bir sıra dəyərlərin orta (arifmetik orta) dəyərindən daha çox faizlərlə işləməyə üstünlük veririk. Bu, tez-tez orta göstəricidən əhəmiyyətli dərəcədə fərqli (və daha maraqlı) xüsusiyyətlərə malik olan daha dispers dəyərləri nəzərdən keçirməyə imkan verir. Hesablama sistemlərinin süni təbiətinə görə metrik dəyərlər tez-tez əyilir, məsələn, heç bir sorğu 0 ms-dən az müddətdə cavab ala bilməz və 1000 ms-lik fasilə o deməkdir ki, daha böyük dəyərlərlə uğurlu cavablar ola bilməz. fasilədən daha çox. Nəticədə, orta və medianın eyni və ya bir-birinə yaxın ola biləcəyini qəbul edə bilmərik!
Əvvəlcədən sınaqdan keçirmədən və müəyyən standart fərziyyələr və təxminlər yerinə yetirilmədikcə, məlumatlarımızın normal şəkildə paylandığı qənaətinə gəlməməyə diqqət edirik. Əgər paylama gözlənildiyi kimi deyilsə, problemi həll edən avtomatlaşdırma prosesi (məsələn, kənar göstəriciləri gördükdə, serveri yüksək sorğu emal gecikmələri ilə yenidən işə salır) bunu çox tez-tez edir və ya kifayət qədər tez-tez etmir (hər ikisi belə deyil). çox yaxşı).
Göstəriciləri standartlaşdırmaq
SLI üçün ümumi xüsusiyyətlərin standartlaşdırılmasını tövsiyə edirik ki, hər dəfə onlar haqqında fərziyyələr aparmağa ehtiyac qalmasın. Standart nümunələrə cavab verən hər hansı xüsusiyyət fərdi SLI-nin spesifikasiyasından xaric edilə bilər, məsələn:
- Toplama intervalları: “ortalama 1 dəqiqədən çox”
- Toplama sahələri: "Klasterdəki bütün tapşırıqlar"
- Ölçmələr nə qədər tez-tez aparılır: "Hər 10 saniyədən bir"
- Hansı sorğular daxildir: "Qara qutu monitorinq işlərindən HTTP GET"
- Məlumatlar necə əldə edilir: "Serverdə ölçülmüş monitorinqimiz sayəsində"
- Məlumata giriş gecikməsi: "Son bayta qədər vaxt"
Səylərə qənaət etmək üçün hər bir ümumi metrik üçün təkrar istifadə edilə bilən SLI şablonları dəsti yaradın; onlar həmçinin hər kəsin müəyyən SLI-nin nə demək olduğunu başa düşməsini asanlaşdırır.
Məqsədlər praktikada
Ölçə biləcəyiniz şeyləri deyil, istifadəçilərinizi maraqlandıran şeylər haqqında düşünməklə (və ya öyrənərək!) başlayın. Çox vaxt istifadəçilərinizin maraqlandıran şeyləri ölçmək çətin və ya qeyri-mümkün olur, buna görə də siz onların ehtiyaclarına yaxınlaşırsınız. Bununla belə, sadəcə ölçmək asan olandan başlasanız, daha az faydalı SLO-larla nəticələnəcəksiniz. Nəticə etibarı ilə biz bəzən gördük ki, ilkin olaraq arzu olunan məqsədləri müəyyən etmək və sonra konkret göstəricilərlə işləmək göstəriciləri seçmək və sonra məqsədlərə nail olmaqdan daha yaxşı nəticə verir.
Məqsədlərinizi müəyyənləşdirin
Maksimum aydınlıq üçün, SLO-ların necə ölçüldüyü və onların etibarlı olduğu şərtlər müəyyən edilməlidir. Məsələn, aşağıdakıları deyə bilərik (ikinci sətir birinci ilə eynidir, lakin SLI defoltlarından istifadə edir):
- Get RPC zənglərinin 99%-i (orta hesabla 1 dəqiqədən çox) 100 ms-dən az müddətdə tamamlanacaq (bütün backend serverlərində ölçülür).
- Get RPC zənglərinin 99%-i 100 ms-dən az müddətdə tamamlanacaq.
Performans əyrilərinin forması vacibdirsə, bir neçə SLO təyin edə bilərsiniz:
- Get RPC zənglərinin 90%-i 1 ms-dən az müddətdə tamamlandı.
- Get RPC zənglərinin 99%-i 10 ms-dən az müddətdə tamamlandı.
- Get RPC zənglərinin 99.9%-i 100 ms-dən az müddətdə tamamlandı.
İstifadəçiləriniz heterojen iş yükləri yaradırsa: toplu emal (bunun üçün ötürmə qabiliyyəti vacibdir) və interaktiv emal (bunun üçün gecikmə vacibdir), hər bir yükləmə sinfi üçün ayrıca məqsədlər müəyyən etmək məqsədəuyğun ola bilər:
- Müştəri sorğularının 95%-i ötürmə qabiliyyətini tələb edir. <1 s yerinə yetirilən RPC zənglərinin sayını təyin edin.
- Müştərilərin 99%-i gecikmə ilə maraqlanır. Trafik <1 KB və <10 ms işləyən RPC zənglərinin sayını təyin edin.
SLO-ların 100% təmin ediləcəyini təkid etmək qeyri-real və arzuolunmazdır: bu, yeni funksionallığın və tətbiqin tətbiqi sürətini azalda bilər və bahalı həllər tələb edə bilər. Bunun əvəzinə, səhv büdcəsinə icazə vermək daha yaxşıdır - sistemin icazə verilən dayanma müddətinin faizi - və bu dəyəri gündəlik və ya həftəlik nəzarət edin. Yüksək rəhbərlik aylıq və ya rüblük qiymətləndirmələr istəyə bilər. (Səhv büdcəsi başqa bir SLO ilə müqayisə üçün sadəcə olaraq SLO-dur.)
SLO pozuntularının faizini səhv büdcəsi ilə müqayisə etmək olar (Fəsil 3 və bölməyə baxın ), yeni buraxılışların nə vaxt yerləşdirilməsinə qərar verən prosesə giriş kimi istifadə edilən fərq dəyəri ilə.
Hədəf dəyərlərin seçilməsi
Planlaşdırma dəyərlərinin (SLO) seçilməsi seçilmiş SLI-larda, SLO-larda (və ola bilsin ki, SLA-larda) əks etdirilməli olan məhsul və biznes maraqlarına görə sırf texniki fəaliyyət deyil. Eynilə, kadr təminatı, bazara çıxma vaxtı, avadanlıqların mövcudluğu və maliyyə ilə bağlı məsələlərlə bağlı məlumat mübadiləsinə ehtiyac ola bilər. SRE bu söhbətin bir hissəsi olmalı və müxtəlif variantların risklərini və həyat qabiliyyətini anlamağa kömək etməlidir. Daha məhsuldar müzakirəyə kömək edə biləcək bir neçə sual hazırladıq:
Cari performansa əsaslanaraq hədəf seçməyin.
Sistemin güclü və hüdudlarını başa düşmək vacib olsa da, ölçüləri əsaslandırmadan uyğunlaşdırmaq sistemi saxlamağınıza mane ola bilər: bu, əhəmiyyətli yenidən dizayn olmadan əldə edilə bilməyən məqsədlərə çatmaq üçün qəhrəmancasına səylər tələb edəcəkdir.
Sadə saxlayın
Kompleks SLI hesablamaları sistem performansındakı dəyişiklikləri gizlədə və problemin səbəbini tapmağı çətinləşdirə bilər.
Mütləqlərdən çəkinin
Gecikmə müddətini artırmadan qeyri-müəyyən artan yükü idarə edə bilən bir sistemə sahib olmaq cazibədar olsa da, bu tələb real deyil. Bu cür ideallara yaxınlaşan bir sistemin dizaynı və qurulması çox güman ki, çox vaxt tələb edəcək, istismarı baha olacaq və daha az şeylə məşğul olan istifadəçilərin gözləntiləri üçün çox yaxşı olacaq.
Mümkün qədər az SLO istifadə edin
Sistem atributlarının yaxşı əhatə olunmasını təmin etmək üçün kifayət qədər sayda SLO seçin. Seçdiyiniz SLO-ları qoruyun: Əgər siz xüsusi SLO-nu qeyd etməklə prioritetlər haqqında mübahisəni heç vaxt qazana bilmirsinizsə, yəqin ki, bu SLO-nu nəzərdən keçirməyə dəyməz. Bununla belə, bütün sistem atributları SLO-lara uyğun deyil: SLO-lardan istifadə edərək istifadəçi həzz səviyyəsini hesablamaq çətindir.
Mükəmməlliyin arxasınca getməyin
Sistemin yük altında davranışı haqqında daha çox məlumat əldə etdikdən sonra zamanla SLO-ların təriflərini və məqsədlərini dəqiqləşdirə bilərsiniz. Əlçatmaz olduğunu gördüyünüz zaman rahatlaşmalı olan həddindən artıq ciddi hədəf seçməkdənsə, zamanla dəqiqləşdirəcəyiniz üzən məqsədlə başlamaq daha yaxşıdır.
SLO-lar SRE-lər və məhsul tərtibatçıları üçün işin prioritetləşdirilməsində əsas sürücü ola bilər və olmalıdır, çünki onlar istifadəçilər üçün narahatlığı əks etdirir. Yaxşı bir SLO inkişaf komandası üçün faydalı bir tətbiq vasitəsidir. Lakin zəif tərtib edilmiş SLO, komanda həddindən artıq aqressiv SLO əldə etmək üçün qəhrəmancasına səylər göstərərsə, israfçı işə və ya SLO çox aşağı olarsa, zəif məhsula səbəb ola bilər. SLO güclü bir qoldur, ondan ağıllı istifadə edin.
Ölçmələrinizə nəzarət edin
SLI və SLO sistemləri idarə etmək üçün istifadə olunan əsas elementlərdir:
- SLI sistemlərinə nəzarət edin və ölçün.
- SLI-ni SLO ilə müqayisə edin və hərəkətə ehtiyac olub olmadığına qərar verin.
- Fəaliyyət tələb olunarsa, məqsədə çatmaq üçün nə baş verməli olduğunu anlayın.
- Bu hərəkəti tamamlayın.
Məsələn, 2-ci addım sorğunun vaxtı bitdiyini və heç bir şey edilmədiyi təqdirdə SLO-nu bir neçə saat ərzində pozacağını göstərirsə, 3-cü addım serverlərin CPU ilə bağlı olduğu fərziyyəsinin sınaqdan keçirilməsini və daha çox serverin əlavə edilməsinin yükü paylayacağını ehtiva edə bilər. SLO olmasaydı, siz (və ya nə vaxt) hərəkətə keçəcəyinizi bilməyəcəksiniz.
SLO təyin et - sonra istifadəçi gözləntiləri təyin olunacaq
SLO-nun dərc edilməsi istifadəçinin sistem davranışı üçün gözləntilərini təyin edir. İstifadəçilər (və potensial istifadəçilər) tez-tez xidmətin istifadəyə yararlı olub-olmadığını anlamaq üçün ondan nə gözlədiklərini bilmək istəyirlər. Məsələn, foto paylaşma veb-saytından istifadə etmək istəyən insanlar bir az daha az əlçatanlıq müqabilində uzunömürlülük və aşağı qiymət vəd edən xidmətdən istifadə etməkdən çəkinə bilər, baxmayaraq ki, eyni xidmət arxiv qeydlərinin idarə edilməsi sistemi üçün ideal ola bilər.
İstifadəçiləriniz üçün real gözləntilər təyin etmək üçün aşağıdakı taktikalardan birini və ya hər ikisini istifadə edin:
- Təhlükəsizlik marjasını qoruyun. İstifadəçilərə elan ediləndən daha sərt daxili SLO istifadə edin. Bu sizə problemlərə xaricdən görünməzdən əvvəl reaksiya vermək imkanı verəcək. SLO buferi, həmçinin, sistemin işinə təsir edən buraxılışları quraşdırarkən təhlükəsizlik marjasına malik olmağa imkan verir və istifadəçiləri dayanma vaxtı ilə məyus etmədən sistemin asan saxlanılmasını təmin edir.
- İstifadəçi gözləntilərini aşmayın. İstifadəçilər dediklərinizə deyil, təklif etdiyinizə əsaslanır. Xidmətinizin faktiki performansı qeyd olunan SLO-dan qat-qat yaxşıdırsa, istifadəçilər cari performansa etibar edəcəklər. Sistemi qəsdən bağlamaqla və ya yüngül yüklər altında performansı məhdudlaşdırmaqla həddindən artıq asılılığın qarşısını ala bilərsiniz.
Sistemin gözləntilərə nə dərəcədə cavab verdiyini başa düşmək, sistemin sürətləndirilməsinə və onu daha əlçatan və davamlı olmasına sərmayə yatırıb-yatırmamağa qərar verməyə kömək edir. Alternativ olaraq, əgər xidmət çox yaxşı performans göstərirsə, işçi vaxtının bir hissəsi texniki borcun ödənilməsi, yeni funksiyaların əlavə edilməsi və ya yeni məhsulların təqdim edilməsi kimi digər prioritetlərə sərf edilməlidir.
Praktikada razılaşmalar
SLA-nın yaradılması biznes və hüquq qruplarından onun pozulmasına görə nəticələri və cəzaları müəyyən etməyi tələb edir. SRE-nin rolu onlara SLA-da olan SLO-lara cavab verməkdə mümkün problemləri anlamağa kömək etməkdir. SLO yaratmaq üçün tövsiyələrin əksəriyyəti SLA-lara da aiddir. İstifadəçilərə vəd etdiyiniz şeylərdə mühafizəkar olmaq müdrikdir, çünki nə qədər çoxunuz varsa, əsassız və ya çətin görünən SLA-ları dəyişdirmək və ya silmək bir o qədər çətindir.
Tərcüməni sona qədər oxuduğunuz üçün təşəkkür edirik. Monitorinq haqqında telegram kanalıma abunə olun и .
Mənbə: www.habr.com