SRE (Site Reliability Engineering) վեբ նախագծերի հասանելիությունն ապահովելու մոտեցում է: Այն համարվում է DevOps-ի շրջանակ և խոսում է այն մասին, թե ինչպես հաջողության հասնել DevOps-ի պրակտիկաների կիրառման գործում: Թարգմանությունը այս հոդվածում գրքեր Google-ից: Ես ինքս պատրաստեցի այս թարգմանությունը և ապավինեցի մոնիտորինգի գործընթացները հասկանալու իմ սեփական փորձին: Հեռագրային ալիքում и я публиковал также перевод 6 главы этой же книги о целях уровня обслуживания.
Թարգմանություն՝ կատու. Վայելե՛ք կարդալը:
Անհնար է կառավարել ծառայությունը, եթե չկա պատկերացում, թե իրականում ինչ ցուցանիշներ են կարևոր և ինչպես չափել և գնահատել դրանք: Այդ նպատակով մենք սահմանում և տրամադրում ենք ծառայության որոշակի մակարդակ մեր օգտատերերին՝ անկախ նրանից՝ նրանք օգտագործում են մեր ներքին API-ներից մեկը, թե հանրային արտադրանք:
Մենք օգտագործում ենք մեր ինտուիցիան, փորձը և օգտատերերի՝ Ծառայության մակարդակի ցուցիչները (SLIs), Ծառայության մակարդակի նպատակները (SLO) և Ծառայության մակարդակի համաձայնագրերը (SLAs) հասկանալու ցանկությունը: Այս չափումները նկարագրում են այն հիմնական ցուցանիշները, որոնք մենք ցանկանում ենք վերահսկել, և որոնց մենք կարձագանքենք, եթե չկարողանանք ապահովել սպասվող ծառայության որակը: Ի վերջո, ճիշտ չափորոշիչների ընտրությունը օգնում է ճիշտ գործողություններին ուղղորդել, եթե ինչ-որ բան սխալ լինի, և նաև SRE թիմին վստահություն է հաղորդում ծառայության առողջության նկատմամբ:
В этой главе описывается подход, который мы используем для борьбы с проблемами метрического моделирования, метрического отбора и метрического анализа. Большая часть объяснений будет без примеров, поэтому мы будем использовать сервис Шекспир, описанный в примере его реализации (поиск по произведениям Шекспира), чтобы проиллюстрировать основные моменты.
Ծառայության մակարդակի տերմինաբանություն
Շատ ընթերցողներ հավանաբար ծանոթ են SLA հասկացությանը, բայց SLI և SLO տերմինները արժանի են զգույշ սահմանման, քանի որ ընդհանուր առմամբ SLA տերմինը ծանրաբեռնված է և ունի մի շարք իմաստներ՝ կախված համատեքստից: Պարզության համար մենք ցանկանում ենք առանձնացնել այս արժեքները:
Ցուցանիշներ
SLI является индикатором уровня обслуживания — тщательно определенной количественной мерой одного из аспектов предоставляемого уровня обслуживания.
Для большинства сервисов в качестве ключевого SLI считают задержку запроса — сколько времени требуется для возврата ответа на запрос. Другие распространенные SLI включают частоту ошибок, часто выражаемую как долю всех полученных запросов, и пропускную способность системы, обычно измеряемую в запросах в секунду. Измерения часто агрегируются: сырые данные сначала собираются, а затем преобразуются в скорость изменения, среднее значение или процентиль.
Իդեալում, SLI-ն ուղղակիորեն չափում է հետաքրքրության ծառայության մակարդակը, բայց երբեմն չափման համար հասանելի է միայն հարակից չափանիշը, քանի որ սկզբնականը դժվար է ձեռք բերել կամ մեկնաբանել: Օրինակ, հաճախորդի կողմի հետաձգումը հաճախ ավելի համապատասխան չափանիշ է, բայց կան դեպքեր, երբ հետաձգումը կարող է չափվել միայն սերվերի վրա:
SLI-ի մեկ այլ տեսակ, որը կարևոր է SRE-ների համար, հասանելիությունն է կամ ժամանակի այն հատվածը, որի ընթացքում ծառայությունը կարող է օգտագործվել: Հաճախ սահմանվում է որպես հաջողված հարցումների արագություն, որը երբեմն կոչվում է եկամտաբերություն: (Կյանքի տևողությունը՝ հավանականությունը, որ տվյալները կպահպանվեն երկար ժամանակով, նույնպես կարևոր է տվյալների պահպանման համակարգերի համար:) Թեև 100% հասանելիությունը հնարավոր չէ, 100% մոտ հասանելիությունը հաճախ հասանելի է. մատչելիության արժեքներն արտահայտվում են որպես «ինը» թիվը » հասանելիության տոկոսը: Օրինակ, 99% և 99,999% հասանելիությունը կարող է նշվել որպես «2 ինը» և «5 ինը»: Google Compute Engine-ի ներկայիս հայտարարված հասանելիության նպատակը «երեք ու կես ինը» է կամ 99,95%:
Նպատակը
SLO-ն սպասարկման մակարդակի նպատակ է՝ թիրախային արժեք կամ արժեքների միջակայք ծառայության մակարդակի համար, որը չափվում է SLI-ով: SLO-ի նորմալ արժեքն է «SLI ≤ Target» կամ «Lower Limit ≤ SLI ≤ Upper Limit»: Օրինակ, մենք կարող ենք որոշել, որ Շեքսպիրի որոնման արդյունքները «արագ» կվերադարձնենք՝ SLO-ն սահմանելով 100 միլիվայրկյանից պակաս որոնման հարցման միջին ուշացման:
Ճիշտ SLO-ի ընտրությունը բարդ գործընթաց է: Նախ, դուք միշտ չէ, որ կարող եք ընտրել որոշակի արժեք: Ձեր ծառայությանն ուղղված արտաքին մուտքային HTTP հարցումների դեպքում հարցումների մեկ վայրկյանում (QPS) չափանիշը հիմնականում որոշվում է ձեր օգտատերերի՝ ձեր ծառայությունն այցելելու ցանկությամբ, և դուք չեք կարող դրա համար SLO սահմանել:
Մյուս կողմից, կարող եք ասել, որ ցանկանում եք, որ յուրաքանչյուր հարցման միջին ուշացումը լինի 100 միլիվայրկյանից պակաս: Նման նպատակ դնելը կարող է ստիպել ձեզ գրել ձեր ճակատը ցածր հետաձգմամբ կամ գնել այնպիսի սարքավորումներ, որոնք ապահովում են նման ուշացում: (100 միլիվայրկյան ակնհայտորեն կամայական թիվ է, բայց ավելի լավ է ունենալ նույնիսկ ավելի ցածր հետաձգման թվեր: Կան ապացույցներ, որոնք ցույց են տալիս, որ արագ արագությունները ավելի լավ են, քան դանդաղ արագությունները, և որ որոշակի արժեքներից բարձր օգտվողների հարցումների մշակման հետաձգումն իրականում ստիպում է մարդկանց հեռու մնալ: ձեր ծառայությունից։)
Կրկին, սա ավելի երկիմաստ է, քան կարող է թվալ առաջին հայացքից. դուք չպետք է ամբողջությամբ բացառեք QPS-ը հաշվարկից: Փաստն այն է, որ QPS-ը և հետաձգումը սերտորեն կապված են միմյանց հետ. ավելի բարձր QPS-ը հաճախ հանգեցնում է ավելի մեծ հետաձգման, և ծառայությունները սովորաբար ունենում են կատարողականի կտրուկ նվազում, երբ հասնում են որոշակի բեռի շեմին:
SLO-ի ընտրությունը և հրապարակումը օգտատերերի ակնկալիքներն է դնում ծառայության աշխատանքի վերաբերյալ: Այս ռազմավարությունը կարող է նվազեցնել ծառայության սեփականատիրոջ դեմ անհիմն բողոքները, օրինակ՝ դանդաղ կատարողականությունը: Առանց հստակ SLO-ի, օգտատերերը հաճախ ստեղծում են իրենց ակնկալիքները ցանկալի կատարման վերաբերյալ, որոնք կարող են կապ չունենալ ծառայությունը նախագծող և ղեկավարող մարդկանց կարծիքների հետ: Այս իրավիճակը կարող է հանգեցնել ծառայությունից ուռճացված ակնկալիքների, երբ օգտվողները սխալմամբ կարծում են, որ ծառայությունն ավելի մատչելի կլինի, քան իրականում կա, և անվստահություն առաջացնի, երբ օգտատերերը կարծում են, որ համակարգը ավելի քիչ հուսալի է, քան իրականում կա:
Համաձայնագրեր
Ծառայության մակարդակի համաձայնագիրը բացահայտ կամ անուղղակի պայմանագիր է ձեր օգտատերերի հետ, որը ներառում է դրանց պարունակած SLO-ներին հանդիպելու (կամ չհանդիպելու) հետևանքները: Հետևանքները ամենահեշտ ճանաչվում են, երբ դրանք ֆինանսական են՝ զեղչ կամ տուգանք, բայց դրանք կարող են այլ ձևեր ունենալ: SLO-ների և SLA-ների միջև տարբերության մասին խոսելու հեշտ միջոցն այն է, որ հարցնեն, թե «ինչ է տեղի ունենում, եթե SLO-ները չկատարվեն»: Եթե չկան հստակ հետևանքներ, դուք գրեթե անկասկած նայում եք SLO-ին:
SRE-ն սովորաբար չի մասնակցում SLA-ների ստեղծմանը, քանի որ SLA-ները սերտորեն կապված են բիզնեսի և արտադրանքի որոշումների հետ: SRE-ն, այնուամենայնիվ, մասնակցում է ձախողված SLO-ների հետևանքները մեղմելուն օգնելու գործում: Նրանք կարող են նաև օգնել որոշել SLI-ը. Ակնհայտ է, որ պայմանագրում պետք է լինի SLO-ն չափելու օբյեկտիվ միջոց, հակառակ դեպքում կլինեն անհամաձայնություններ:
Google Search-ը կարևոր ծառայության օրինակ է, որը չունի հանրային SLA. մենք ցանկանում ենք, որ բոլորն օգտագործեն Որոնումը հնարավորինս արդյունավետ, բայց մենք պայմանագիր չենք կնքել աշխարհի հետ: Այնուամենայնիվ, դեռևս կան հետևանքներ, եթե որոնումն անհասանելի է. անհասանելիությունը հանգեցնում է մեր հեղինակության անկմանը, ինչպես նաև գովազդային եկամուտների նվազմանը: Google-ի շատ այլ ծառայություններ, ինչպիսիք են Google for Work-ը, օգտատերերի հետ ունեն ծառայության մակարդակի հստակ համաձայնագրեր: Անկախ նրանից, թե կոնկրետ ծառայությունն ունի SLA, կարևոր է սահմանել SLI և SLO և օգտագործել դրանք ծառայությունը կառավարելու համար:
Так много теории — теперь к опыту.
Индикаторы на практике
Հաշվի առնելով, որ մենք եկել ենք այն եզրակացության, որ կարևոր է ընտրել համապատասխան չափումներ՝ ծառայության մակարդակը չափելու համար, ինչպե՞ս գիտեք, թե որ չափանիշներն են կարևոր ծառայության կամ համակարգի համար:
Ի՞նչն է ձեզ և ձեր օգտատերերին հետաքրքրում:
Ձեզ հարկավոր չէ օգտագործել յուրաքանչյուր չափանիշ որպես SLI, որը կարող եք հետևել մոնիտորինգի համակարգում. Հասկանալով, թե ինչ են ուզում օգտվողները համակարգից, կօգնի ձեզ ընտրել մի քանի չափումներ: Չափազանց շատ ցուցանիշներ ընտրելը դժվարացնում է կենտրոնանալը կարևոր ցուցանիշների վրա, մինչդեռ փոքր թվի ընտրությունը կարող է թողնել ձեր համակարգի մեծ հատվածները առանց ուշադրության: Մենք սովորաբար օգտագործում ենք մի քանի հիմնական ցուցանիշներ՝ գնահատելու և հասկանալու համակարգի առողջությունը:
Ծառայությունները, ընդհանուր առմամբ, կարող են բաժանվել մի քանի մասերի SLI-ի առումով, որոնք վերաբերում են դրանց.
- Պատվերով առջևի համակարգեր, ինչպիսիք են մեր օրինակից Շեքսպիր ծառայության որոնման միջերեսները: Նրանք պետք է հասանելի լինեն, չունենան ուշացումներ և ունենան բավարար թողունակություն: Ըստ այդմ՝ հարցեր կարող են տրվել՝ կարո՞ղ ենք պատասխանել խնդրանքին։ Որքա՞ն ժամանակ տևեց հարցմանը պատասխանելու համար: Քանի՞ հարցում կարող է մշակվել:
- Системы хранения. Для них важна низкая задержка ответа, доступность и долговечность. Соответствующие вопросы: сколько времени требуется для чтения или записи данных? Можем ли мы получить доступ к данным по запросу? Доступны ли данные, когда они нам нужны? См. главу 26 Целостность данных: то, что вы читаете, это то, что вы записали, для детального разбора этих вопросов.
- Մեծ տվյալների համակարգերը, ինչպիսիք են տվյալների մշակման խողովակաշարերը, հիմնված են թողունակության և հարցումների մշակման հետաձգման վրա: Առնչվող հարցեր. Որքա՞ն տվյալներ են մշակվում: Որքա՞ն ժամանակ է պահանջվում տվյալների փոխանցման համար՝ հարցում ստանալուց մինչև պատասխան տրամադրելը: (Համակարգի որոշ մասեր կարող են նաև ուշացումներ ունենալ որոշակի փուլերում):
Сбор индикаторов
Многие индикаторы уровня сервиса наиболее естественно собирать на стороне сервера, используя систему мониторинга, такую как Borgmon (см. ) կամ Պրոմեթևս, կամ պարզապես պարբերաբար վերլուծելով տեղեկամատյանները՝ նույնականացնելով HTTP-ի պատասխանները 500 կարգավիճակով: Այնուամենայնիվ, որոշ համակարգեր պետք է հագեցած լինեն հաճախորդի կողմից չափումների հավաքածուով, քանի որ հաճախորդի կողմից մոնիտորինգի բացակայությունը կարող է հանգեցնել մի շարք խնդիրների, որոնք ազդում են: օգտվողներ, բայց չեն ազդում սերվերի կողմից չափումների վրա: Օրինակ, մեր Շեքսպիրի որոնման թեստի հավելվածի հետին պլանի պատասխանների հետաձգման վրա կենտրոնանալը կարող է հանգեցնել օգտատերերի հետաձգման՝ JavaScript-ի հետ կապված խնդիրների պատճառով. այս դեպքում ավելի լավ չափում է բրաուզերի կողմից էջը մշակելու համար պահանջվող ժամանակը:
Ագրեգացիա
Պարզության և օգտագործման համար մենք հաճախ հավաքում ենք չմշակված չափումները: Սա պետք է արվի ուշադիր:
Որոշ չափումներ թվում են պարզ, օրինակ՝ հարցումները մեկ վայրկյանում, բայց նույնիսկ այս ակնհայտորեն պարզ չափումը ժամանակի ընթացքում անուղղակիորեն համախմբում է տվյալները: Արդյո՞ք չափումը հատուկ է ստացվել վայրկյանում մեկ անգամ, թե՞ չափումը միջինացված է րոպեում հարցումների քանակի նկատմամբ: Վերջին տարբերակը կարող է թաքցնել ակնթարթային շատ ավելի մեծ թվով հարցումներ, որոնք տևում են ընդամենը մի քանի վայրկյան: Դիտարկենք մի համակարգ, որը սպասարկում է 200 հարցում մեկ վայրկյանում զույգ թվերով, իսկ մնացած ժամանակում՝ 0: Մի հաստատուն՝ վայրկյանում 100 հարցումների միջին արժեքի տեսքով և ակնթարթային ծանրաբեռնվածության կրկնակի չափով, նույն բանը չէ: Նմանապես, հարցումների հետաձգումների միջինացումը կարող է գրավիչ թվալ, բայց դա թաքցնում է մի կարևոր մանրամասն. հնարավոր է, որ հարցումների մեծ մասը լինի արագ, բայց կլինեն շատ հարցումներ, որոնք դանդաղ են:
Большинство показателей лучше рассматривать как распределения, а не средние. Например, для SLI задержки некоторые запросы будут обрабатываться быстро, в то время как некоторые всегда будут занимать больше времени, иногда намного больше. Простое среднее может скрывать эти длительные задержки. На рисунке приведен пример: хотя типичный запрос обслуживается примерно 50 мс, 5% запросов в 20 раз медленнее! Мониторинг и оповещения, основанные только на средней задержке, не показывают изменений в поведении в течение дня, когда на самом деле существуют заметные изменения в длительности обработки некоторых запросов (самая верхняя строка).
50, 85, 95 և 99 տոկոսային համակարգի ուշացում: Y առանցքը լոգարիթմական ձևաչափով է:
Ցուցանիշների համար տոկոսների օգտագործումը թույլ է տալիս տեսնել բաշխման ձևը և դրա բնութագրերը. բարձր տոկոսային մակարդակը, ինչպիսին է 99-ը կամ 99,9-ը, ցույց է տալիս ամենավատ արժեքը, մինչդեռ 50 տոկոսը (հայտնի է նաև որպես միջին) ցույց է տալիս ամենահաճախակի վիճակը: մետրիկը։ Որքան մեծ է արձագանքման ժամանակի ցրվածությունը, այնքան երկարաժամկետ հարցումներն ազդում են օգտագործողի փորձի վրա: Էֆեկտը ուժեղանում է բարձր ծանրաբեռնվածության և հերթերի առկայության դեպքում: Օգտատիրոջ փորձի հետազոտությունը ցույց է տվել, որ մարդիկ սովորաբար նախընտրում են ավելի դանդաղ համակարգ՝ բարձր արձագանքման ժամանակի շեղումով, ուստի որոշ SRE թիմեր կենտրոնանում են միայն բարձր տոկոսային միավորների վրա՝ հիմք ընդունելով, որ եթե չափման վարքագիծը 99,9 տոկոսի վրա լավ է, օգտվողների մեծամասնությունը խնդիրներ չի ունենա: .
Նշում վիճակագրական սխալների մասին
Обычно мы предпочитаем работать с процентилями, а не со средним (средним арифметическим) набором значений. Это позволяет рассматривать более дисперсные значения, которые часто имеют существенно отличающиеся (и более интересные) характеристики, чем среднее. Из-за искусственного характера вычислительных систем значения метрик часто искажаются, например, ни один запрос не может получить ответ менее чем за 0 мс, а тайм-аут в 1000 мс означает, что успешных ответов со значениями, превышающими таймаут, не может быть. В результате мы не можем принять, что среднее и медианы могут быть одинаковы или близки друг к другу!
Без предварительной проверки и если некоторые стандартные предположения и аппроксимации не выполняются, мы стараемся не делать выводов, что наши данные нормально распределены. Если распределение не соответствует ожидаемому, процесс автоматизации, который устраняет проблему (например, когда видит выбросы за граничные значения, он перезапускает сервер с высокими задержками обработки запроса), может делать это слишком часто или недостаточно часто (оба варианта не очень-то хороши).
Ստանդարտացնել ցուցանիշները
Մենք խորհուրդ ենք տալիս ստանդարտացնել SLI-ի ընդհանուր բնութագրերը, որպեսզի ստիպված չլինեք ամեն անգամ դրանց մասին ենթադրություններ անել: Ցանկացած հատկանիշ, որը բավարարում է ստանդարտ օրինաչափությունները, կարող է բացառվել առանձին SLI-ի ճշգրտումից, օրինակ՝
- Համախմբման ընդմիջումներ՝ «միջինը 1 րոպեից ավելի»
- Области агрегирования: «Все задачи в кластере»
- Որքան հաճախ են չափումներ կատարվում՝ «10 վայրկյանը մեկ»
- Ինչ հարցումներ են ներառված. «HTTP GET սև արկղի մոնիտորինգի աշխատանքներից»
- Ինչպես են ստացվում տվյալները. «Սերվերի վրա չափված մեր մոնիտորինգի շնորհիվ»
- Տվյալների հասանելիության ուշացում. «Բայթի վերջին ժամանակը»
Чтобы сэкономить усилия, создайте набор многоразовых шаблонов SLI для каждой общей метрики; они также упрощают для всех понимание того, что означает определенный SLI.
Նպատակները գործնականում
Սկսեք մտածել (կամ պարզել) այն մասին, թե ինչն է հետաքրքրում ձեր օգտատերերին, այլ ոչ թե այն, ինչ դուք կարող եք չափել: Հաճախ այն, ինչ ձեր օգտատերերին հետաքրքրում է, դժվար կամ անհնար է չափել, այնպես որ դուք ի վերջո մոտենում եք նրանց կարիքներին: Այնուամենայնիվ, եթե դուք պարզապես սկսեք նրանից, ինչը հեշտ է չափել, դուք կհասցնեք ավելի քիչ օգտակար SLO-ների: Արդյունքում, մենք երբեմն հայտնաբերում ենք, որ սկզբում ցանկալի նպատակների բացահայտումը, այնուհետև կոնկրետ ցուցանիշների հետ աշխատելն ավելի լավ է աշխատում, քան ցուցանիշներ ընտրելը և հետո նպատակներին հասնելը:
Определите цели
Առավելագույն հստակության համար պետք է սահմանել, թե ինչպես են չափվում SLO-ները և ինչ պայմաններում են դրանք վավեր: Օրինակ, մենք կարող ենք ասել հետևյալը (երկրորդ տողը նույնն է, ինչ առաջինը, բայց օգտագործում է SLI լռելյայն).
- 99% (усредненные в течение 1 минуты) вызовов Get RPC будут завершены менее чем за 100 мс (измеряется на всех серверах backend).
- 99% вызовов Get RPC будут завершены менее чем за 100 мс.
Եթե կատարողականության կորերի ձևը կարևոր է, կարող եք նշել մի քանի SLOs.
- Get RPC զանգերի 90%-ն ավարտվել է 1 ms-ից պակաս ժամանակում:
- Get RPC զանգերի 99%-ն ավարտվել է 10 ms-ից պակաս ժամանակում:
- Get RPC զանգերի 99.9%-ն ավարտվել է 100 ms-ից պակաս ժամանակում:
Եթե ձեր օգտատերերը ստեղծում են տարասեռ աշխատանքային ծանրաբեռնվածություն՝ զանգվածային մշակում (որի համար կարևոր է թողունակությունը) և ինտերակտիվ մշակում (որի համար ուշացումը կարևոր է), ապա արժե յուրաքանչյուր բեռնվածության դասի համար սահմանել առանձին նպատակներ.
- Հաճախորդների հարցումների 95%-ը պահանջում է թողունակություն: Սահմանեք RPC կատարվող զանգերի քանակը <1 վրկ:
- Հաճախորդների 99%-ը հոգ է տանում հետաձգման մասին: Սահմանեք <1 ԿԲ տրաֆիկով և <10 ms գործող RPC զանգերի քանակը:
Անիրատեսական և անցանկալի է պնդել, որ SLO-ները կբավարարվեն 100%-ով. դա կարող է նվազեցնել նոր ֆունկցիոնալության և տեղակայման տեմպերը և պահանջել թանկարժեք լուծումներ: Փոխարենը, ավելի լավ է թույլատրել սխալի բյուջեն՝ համակարգի անգործության թույլատրելի տոկոսը, և վերահսկել այս արժեքը ամեն օր կամ շաբաթական: Բարձրագույն ղեկավարությունը կարող է ցանկանալ ամսական կամ եռամսյակային գնահատումներ: (Սխալի բյուջեն պարզապես SLO է մեկ այլ SLO-ի հետ համեմատելու համար):
Долю нарушения SLO можно сравнить с бюджетом ошибок (см. Главу 3 и раздел ), տարբերության արժեքով, որն օգտագործվում է որպես գործընթացի մուտքագրում, որը որոշում է, թե երբ տեղակայել նոր թողարկումները:
Выбор плановых значений
Выбор плановых значений (SLO) не является чисто технической деятельностью из-за интересов продукта и бизнеса, которые должны быть отражены в выбранных SLI, SLO (и, возможно, SLA). Аналогичным образом, может потребоваться обмен информацией по поводу вопросов, связанных с укомплектованием штата персонала, временем выхода на рынок, наличием оборудования и финансированием. SRE должен быть частью этого разговора и помогать разобраться с рисками и жизнеспособностью различных вариантов. Мы прикинули несколько вопросов, которые могут помочь обеспечить более продуктивное обсуждение:
Մի ընտրեք նպատակ՝ հիմնվելով ընթացիկ կատարողականի վրա:
Թեև համակարգի ուժեղ կողմերն ու սահմանները հասկանալը կարևոր է, չափումների հարմարեցումն առանց պատճառաբանության կարող է խանգարել ձեզ պահպանել համակարգը. այն կպահանջի հերոսական ջանքեր՝ հասնելու նպատակներին, որոնք հնարավոր չէ հասնել առանց նշանակալի վերանախագծման:
Պարզ եղեք
Сложные расчёты SLI могут скрыть изменения в производительности системы и усложнят поиск причины проблемы.
Избегайте абсолюта
Хотя возникает соблазн иметь систему, которая может принимать неограниченно растущую нагрузку без увеличения значения задержки — это требование нереально. Система, которая подходит к таким идеалам, вероятно, заставить потратить много времени на проектирование и создание, обойдётся дорого в эксплуатации окажется слишком хороша для ожиданий пользователей, которым хватило бы и меньшего.
Используйте как можно меньшее количество SLO
Выберите достаточное количество SLO, чтобы обеспечить хорошее покрытие атрибутов системы. Защитите SLO, которые вы выбрали: если вы никогда не сможете выиграть спор о приоритетах, указав конкретную SLO, вероятно, не стоит рассматривать эту SLO. Однако, не все атрибуты системы поддаются SLO: трудно подсчитать уровень пользовательского восторга при помощи SLO.
Մի՛ հետապնդիր կատարելությունը
Вы всегда можете уточнить определения и цели SLO с течением времени, когда узнаете больше о поведении системы под нагрузкой. Лучше начинать с плавающей цели, которую вы со временем уточните, чем выбирать слишком строгую цель, которая должна быть ослаблена, когда вы обнаружите, что это недостижимо.
SLO-ները կարող են և պետք է լինեն հիմնական շարժիչ ուժը SRE-ների և արտադրանքի մշակողների համար աշխատանքի առաջնահերթության համար, քանի որ դրանք արտացոլում են օգտվողների մտահոգությունը: Լավ SLO-ն օգտակար կիրառման գործիք է զարգացման թիմի համար: Բայց վատ ձևավորված SLO-ն կարող է հանգեցնել վատնման աշխատանքի, եթե թիմը հերոսական ջանքեր է գործադրում չափազանց ագրեսիվ SLO-ի հասնելու համար, կամ վատ արտադրանքի, եթե SLO-ն շատ ցածր է: SLO-ն հզոր լծակ է, խելամտորեն օգտագործեք այն։
Վերահսկեք ձեր չափումները
SLI-ն և SLO-ն հիմնական տարրերն են, որոնք օգտագործվում են համակարգերը կառավարելու համար.
- Мониторьте и измеряйте SLI системы.
- Համեմատեք SLI-ն SLO-ի հետ և որոշեք, թե արդյոք անհրաժեշտ է գործողություն:
- Եթե գործողություն է պահանջվում, պարզեք, թե ինչ պետք է տեղի ունենա նպատակին հասնելու համար:
- Выполните это действие.
Например, если шаг 2 показывает, что время ожидания запроса увеличивается, и нарушит SLO через несколько часов, если ничего не будет сделано, шаг 3 может включать в себя тестирование гипотезы о том, что нагрузка на серверы привязана к процессорам и добавление новых серверов распределит нагрузку. Без SLO вы не знали бы нужно ли (или когда) принимать меры.
Սահմանեք SLO - այնուհետև կսահմանվեն օգտվողի ակնկալիքները
SLO-ի հրապարակումը սահմանում է օգտատերերի սպասելիքները համակարգի վարքագծի վերաբերյալ: Օգտագործողները (և պոտենցիալ օգտվողները) հաճախ ցանկանում են իմանալ, թե ինչ սպասել ծառայությունից՝ հասկանալու համար, թե արդյոք այն հարմար է օգտագործման համար: Օրինակ, մարդիկ, ովքեր ցանկանում են օգտվել լուսանկարների փոխանակման վեբկայքից, կարող են խուսափել այնպիսի ծառայությունից, որը խոստանում է երկարակեցություն և ցածր գին՝ մի փոքր ավելի քիչ հասանելիության դիմաց, թեև նույն ծառայությունը կարող է իդեալական լինել արխիվային գրառումների կառավարման համակարգի համար:
Ձեր օգտատերերի համար իրատեսական ակնկալիքներ սահմանելու համար օգտագործեք հետևյալ մարտավարություններից մեկը կամ երկուսը.
- Պահպանեք անվտանգության սահմանը: Օգտագործեք ավելի խիստ ներքին SLO, քան այն, ինչ գովազդվում է օգտվողներին: Սա ձեզ հնարավորություն կտա արձագանքել խնդիրներին, նախքան դրանք արտաքին տեսանելի դառնալը: SLO բուֆերը նաև թույլ է տալիս ունենալ անվտանգության մարժա, երբ տեղադրում եք թողարկումներ, որոնք ազդում են համակարգի աշխատանքի վրա և ապահովում են, որ համակարգը հեշտ է պահպանել՝ առանց օգտագործողներին խափանելու պատճառով:
- Не перевыполняйте ожиданий пользователей. Օգտագործողները հիմնված են ձեր առաջարկածի վրա, ոչ թե ձեր ասածի վրա: Եթե ձեր ծառայության իրական կատարումը շատ ավելի լավ է, քան նշված SLO-ն, օգտվողները կվստահեն ընթացիկ կատարողականին: Դուք կարող եք խուսափել գերկախվածությունից՝ միտումնավոր անջատելով համակարգը կամ սահմանափակելով աշխատանքը թեթև բեռների տակ:
Հասկանալը, թե որքանով է համակարգը բավարարում ակնկալիքները, օգնում է որոշել՝ արդյոք ներդրումներ կատարել համակարգը արագացնելու և այն ավելի մատչելի և ճկուն դարձնելու համար: Որպես այլընտրանք, եթե ծառայությունը չափազանց լավ է աշխատում, անձնակազմի որոշ ժամանակ պետք է ծախսվի այլ առաջնահերթությունների վրա, ինչպիսիք են տեխնիկական պարտքի մարումը, նոր հնարավորությունների ավելացումը կամ նոր ապրանքների ներդրումը:
Соглашения на практике
SLA-ի ստեղծումը պահանջում է բիզնես և իրավաբանական թիմեր սահմանել դրա խախտման հետևանքները և տույժերը: SRE-ի դերն է օգնել նրանց հասկանալ SLA-ում պարունակվող SLO-ներին դիմակայելու հնարավոր մարտահրավերները: SLO-ների ստեղծման վերաբերյալ առաջարկությունների մեծ մասը վերաբերում է նաև SLA-ներին: Խելամիտ է լինել պահպանողական այն բանում, ինչ խոստանում եք օգտատերերին, քանի որ որքան շատ ունեք, այնքան դժվար է փոխել կամ հեռացնել SLA-ները, որոնք անհիմն են թվում կամ դժվար է հանդիպել:
Շնորհակալություն թարգմանությունը մինչև վերջ կարդալու համար։ Բաժանորդագրվեք իմ հեռագրային ալիքին մոնիտորինգի մասին и .
Source: www.habr.com