SRE (Site Reliability Engineering) е подход за осигуряване на наличност на уеб проекти. Смята се за рамка за DevOps и говори за това как да постигнете успех в прилагането на практиките на DevOps. Превод в тази статия Глава 4 Цели на нивото на обслужване книги Инженеринг за надеждност на сайта от Google. Подготвих този превод сам и разчитах на собствения си опит в разбирането на процесите на мониторинг. В телеграм канала monitorim_it и последна публикация на Хабре Публикувах и превод на глава 6 от същата книга относно целите на нивото на обслужване.

Превод по кат. Наслади се на четенето!

Невъзможно е да се управлява услуга, ако няма разбиране какви показатели всъщност имат значение и как да бъдат измерени и оценени. За тази цел ние определяме и предоставяме определено ниво на обслужване на нашите потребители, независимо дали използват един от нашите вътрешни API или публичен продукт.

Ние използваме нашата интуиция, опит и разбиране на желанието на потребителите да разберат индикаторите за ниво на обслужване (SLI), целите на нивото на обслужване (SLO) и споразуменията за ниво на обслужване (SLA). Тези измерения описват основните показатели, които искаме да наблюдаваме и на които ще реагираме, ако не можем да предоставим очакваното качество на услугата. В крайна сметка изборът на правилните показатели помага за насочване на правилните действия, ако нещо се обърка, и също така дава увереност на екипа на SRE в изправността на услугата.

Тази глава описва подхода, който използваме за борба с проблемите на метричното моделиране, избора на метрика и метричния анализ. По-голямата част от обяснението ще бъде без примери, така че ще използваме услугата Shakespeare, описана в нейния пример за изпълнение (търсене на произведения на Шекспир), за да илюстрираме основните точки.

Терминология на ниво обслужване

Много читатели вероятно са запознати с концепцията за 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“ или „Долна граница ≤ SLI ≤ Upper Limit“. Например, може да решим, че ще върнем резултатите от търсенето на Шекспир „бързо“, като настроим SLO на средно забавяне на заявката за търсене от по-малко от 100 милисекунди.

Изборът на правилния SLO е сложен процес. Първо, не винаги можете да изберете конкретна стойност. За външни входящи HTTP заявки към вашата услуга показателят Query Per Second (QPS) се определя основно от желанието на вашите потребители да посетят вашата услуга и не можете да зададете SLO за това.

От друга страна, можете да кажете, че искате средното забавяне за всяка заявка да бъде по-малко от 100 милисекунди. Поставянето на такава цел може да ви принуди да напишете своя интерфейс с ниска латентност или да закупите оборудване, което осигурява такава латентност. (100 милисекунди очевидно е произволно число, но е по-добре да имате още по-ниски числа на латентност. Има доказателства, които сочат, че бързите скорости са по-добри от бавните скорости и че латентността при обработката на потребителски заявки над определени стойности всъщност принуждава хората да стоят настрана от вашата услуга.)

Отново, това е по-двусмислено, отколкото може да изглежда на пръв поглед: не трябва напълно да изключвате QPS от изчислението. Факт е, че QPS и латентността са тясно свързани помежду си: по-високите QPS често водят до по-високи латентности и услугите обикновено изпитват рязък спад в производителността, когато достигнат определен праг на натоварване.

Изборът и публикуването на SLO определя очакванията на потребителите за това как ще работи услугата. Тази стратегия може да намали неоснователните оплаквания срещу собственика на услугата, като бавна производителност. Без изричен SLO потребителите често създават свои собствени очаквания относно желаната производителност, които може да нямат нищо общо с мненията на хората, които проектират и управляват услугата. Тази ситуация може да доведе до завишени очаквания от услугата, когато потребителите погрешно вярват, че услугата ще бъде по-достъпна, отколкото всъщност е, и да предизвика недоверие, когато потребителите вярват, че системата е по-малко надеждна, отколкото е в действителност.

Споразумения

Споразумението за ниво на обслужване е изричен или косвен договор с вашите потребители, който включва последствията от спазването (или неспазването) на съдържащите се в тях SLO. Последствията се разпознават най-лесно, когато са финансови – отстъпка или глоба – но могат да приемат и други форми. Лесен начин да говорите за разликата между SLO и SLA е да попитате „какво се случва, ако SLO не бъдат изпълнени?“ Ако няма ясни последствия, почти сигурно търсите SLO.

SRE обикновено не участва в създаването на SLA, тъй като SLA са тясно свързани с бизнес и продуктови решения. SRE обаче участва в подпомагането на смекчаване на последствията от неуспешни SLO. Те също могат да помогнат при определянето на SLI: Очевидно трябва да има обективен начин за измерване на SLO в споразумението или ще има разногласия.

Google Търсене е пример за важна услуга, която няма публично SLA: искаме всички да използват Търсене възможно най-ефективно, но не сме подписали договор със света. Въпреки това все още има последствия, ако търсенето не е налично - липсата на достъп води до спад в нашата репутация, както и до намалени приходи от реклама. Много други услуги на Google, като Google for Work, имат изрични споразумения за ниво на обслужване с потребителите. Независимо дали дадена услуга има SLA, важно е да се дефинират SLI и SLO и да се използват за управление на услугата.

Толкова много теория - сега опит.

Индикатори на практика

Като се има предвид, че заключихме, че е важно да изберете подходящи показатели за измерване на нивото на услугата, как сега знаете кои показатели имат значение за дадена услуга или система?

Какво ви интересува вас и вашите потребители?

Не е необходимо да използвате всеки показател като SLI, който можете да проследите в система за наблюдение; Разбирането какво искат потребителите от дадена система ще ви помогне да изберете няколко показателя. Избирането на твърде много индикатори затруднява фокусирането върху важни индикатори, докато избирането на малък брой може да остави големи части от вашата система без надзор. Обикновено използваме няколко ключови индикатора, за да оценим и разберем здравето на дадена система.

Услугите обикновено могат да бъдат разделени на няколко части по отношение на SLI, които са подходящи за тях:

• Персонализирани предни системи, като интерфейсите за търсене за услугата Shakespeare от нашия пример. Те трябва да са налични, да нямат закъснения и да имат достатъчна честотна лента. Съответно могат да се задават въпроси: можем ли да отговорим на искането? Колко време отне отговорът на заявката? Колко искания могат да бъдат обработени?
• Системи за съхранение. Те ценят ниската латентност на реакцията, наличността и издръжливостта. Свързани въпроси: Колко време отнема четенето или записването на данни? Можем ли да получим достъп до данните при поискване? Налични ли са данните, когато имаме нужда от тях? Вижте Глава 26 Цялост на данните: Каквото четете, това пишете за подробно обсъждане на тези въпроси.
• Големи системи за данни, като тръбопроводи за обработка на данни, разчитат на пропускателна способност и забавяне на обработката на заявки. Свързани въпроси: Колко данни се обработват? Колко време отнема на данните да преминат от получаване на заявка до издаване на отговор? (Някои части от системата може също да имат закъснения в определени етапи.)

Колекция от показатели

Много индикатори за ниво на обслужване се събират най-естествено от страната на сървъра, като се използва система за наблюдение като Borgmon (вижте по-долу). Глава 10 Практически предупреждения, базирани на данни от времеви редове) или Prometheus, или просто периодично анализиране на регистрационните файлове, идентифициране на HTTP отговори със статус 500. Някои системи обаче трябва да бъдат оборудвани със събиране на показатели от страна на клиента, тъй като липсата на мониторинг от страна на клиента може да доведе до пропускане на редица проблеми, които засягат потребители, но не засягат показателите от страната на сървъра. Например, фокусирането върху латентността на реакцията на бекенда на нашето тестово приложение за търсене на Shakespeare може да доведе до забавяне от страна на потребителя поради проблеми с JavaScript: в този случай измерването колко време отнема на браузъра да обработи страницата е по-добър показател.

Агрегиране

За опростяване и лесна употреба често обобщаваме необработени измервания. Това трябва да се прави внимателно.

Някои показатели изглеждат прости, като заявки в секунда, но дори това очевидно просто измерване имплицитно агрегира данни във времето. Измерването получава ли се конкретно веднъж в секунда или измерването е осреднено спрямо броя заявки в минута? Последната опция може да скрие много по-голям мигновен брой заявки, които продължават само няколко секунди. Помислете за система, която обслужва 200 заявки в секунда с четни числа и 0 през останалото време. Константа под формата на средна стойност от 100 заявки в секунда и двойно по-голямо моментно натоварване не са едно и също нещо. По същия начин, осредняването на закъсненията на заявките може да изглежда привлекателно, но крие важен детайл: възможно е повечето заявки да бъдат бързи, но ще има много заявки, които са бавни.

Повечето индикатори е по-добре да се разглеждат като разпределения, а не средни стойности. Например, за SLI латентност, някои заявки ще бъдат обработени бързо, докато някои винаги ще отнемат повече време, понякога много повече. Една проста средна стойност може да скрие тези дълги закъснения. Фигурата показва пример: въпреки че една типична заявка отнема приблизително 50 ms за обслужване, 5% от заявките са 20 пъти по-бавни! Мониторингът и предупрежденията, базирани само на средна латентност, не показват промени в поведението през целия ден, когато всъщност има забележими промени във времето за обработка на някои заявки (най-горния ред).

50, 85, 95 и 99 персентилна системна латентност. Оста Y е в логаритмичен формат.

Използването на процентили за индикатори ви позволява да видите формата на разпределението и неговите характеристики: високо процентилно ниво, като 99 или 99,9, показва най-лошата стойност, докато 50-ият персентил (известен също като медиана) показва най-честото състояние на метриката. Колкото по-голяма е дисперсията на времето за отговор, толкова по-продължителните заявки влияят върху потребителското изживяване. Ефектът се засилва при голямо натоварване и при наличие на опашки. Проучване на потребителския опит показа, че хората обикновено предпочитат по-бавна система с висока вариация на времето за реакция, така че някои екипи на SRE се фокусират само върху високи персентилни резултати, въз основа на това, че ако поведението на показателя при 99,9 персентил е добро, повечето потребители няма да изпитват проблеми .

Забележка за статистическите грешки

Обикновено предпочитаме да работим с процентили, а не със средна стойност (средна аритметична стойност) на набор от стойности. Това ни позволява да разгледаме по-разпръснати стойности, които често имат значително различни (и по-интересни) характеристики от средните. Поради изкуствения характер на изчислителните системи стойностите на показателите често са изкривени, например нито една заявка не може да получи отговор за по-малко от 0 ms, а изчакване от 1000 ms означава, че не може да има успешни отговори със стойности, по-големи отколкото времето за изчакване. В резултат на това не можем да приемем, че средната стойност и медианата могат да бъдат еднакви или близки една до друга!

Без предварително тестване и освен ако не са валидни определени стандартни допускания и приближения, ние внимаваме да не заключим, че нашите данни са нормално разпространени. Ако разпространението не е според очакванията, процесът на автоматизация, който коригира проблема (например, когато види отклонения, рестартира сървъра с големи закъснения при обработка на заявки), може да го прави твърде често или недостатъчно често (и двете не са много добре).

Стандартизирайте показателите

Препоръчваме стандартизиране на общите характеристики за SLI, така че да не се налага да спекулирате с тях всеки път. Всяка функция, която отговаря на стандартните модели, може да бъде изключена от спецификацията на отделен SLI, например:

• Интервали на агрегиране: „осреднено за 1 минута“
• Области на агрегиране: „Всички задачи в клъстера“
• Колко често се правят измервания: „На всеки 10 секунди“
• Какви заявки са включени: „HTTP GET от задачи за мониторинг на черна кутия“
• Как се получават данните: „Благодарение на нашия мониторинг, измерен на сървъра“
• Забавяне на достъпа до данни: „Време до последния байт“

За да спестите усилия, създайте набор от многократно използвани SLI шаблони за всеки общ показател; те също така улесняват разбирането на всеки какво означава определен SLI.

Цели на практика

Започнете, като помислите (или разберете!) какво интересува вашите потребители, а не какво можете да измерите. Често това, което интересува вашите потребители, е трудно или невъзможно за измерване, така че в крайна сметка се доближавате до техните нужди. Въпреки това, ако просто започнете с това, което е лесно за измерване, ще завършите с по-малко полезни SLO. В резултат на това понякога откриваме, че първоначалното идентифициране на желаните цели и след това работата с конкретни индикатори работи по-добре, отколкото избирането на индикатори и след това постигането на целите.

Определете цели

За максимална яснота трябва да се определи как се измерват SLO и условията, при които са валидни. Например, можем да кажем следното (вторият ред е същият като първия, но използва SLI по подразбиране):

• 99% (средно за 1 минута) от Get RPC повикванията ще завършат за по-малко от 100 ms (измерено във всички бекенд сървъри).
• 99% от обажданията на Get RPC ще завършат за по-малко от 100 ms.

Ако формата на кривите на производителността е важна, можете да посочите множество SLO:

• 90% от обажданията на Get RPC са завършени за по-малко от 1 ms.
• 99% от обажданията на Get RPC са завършени за по-малко от 10 ms.
• 99.9% от обажданията на Get RPC са завършени за по-малко от 100 ms.

Ако вашите потребители генерират разнородни работни натоварвания: групова обработка (за която пропускателната способност е важна) и интерактивна обработка (за която латентността е важна), може да си струва да дефинирате отделни цели за всеки клас на натоварване:

• 95% от заявките на клиенти изискват пропускателна способност. Задайте броя на изпълнените RPC повиквания <1 s.
• 99% от клиентите се интересуват от латентността. Задайте броя на RPC повикванията с трафик <1 KB и работещ <10 ms.

Нереалистично и нежелателно е да се настоява, че 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 е да им помогне да разберат вероятните предизвикателства при изпълнението на SLO, съдържащи се в SLA. Повечето от препоръките за създаване на SLO се отнасят и за SLA. Разумно е да бъдете консервативни в това, което обещавате на потребителите, защото колкото повече имате, толкова по-трудно е да промените или премахнете SLA, които изглеждат неразумни или трудни за изпълнение.

Благодаря ви, че прочетохте превода до края. Абонирайте се за моя телеграм канал за мониторинг monitorim_it и блог на Medium.

Източник: www.habr.com