Това е препис на епизод. Посетете подкаст уебсайта за записа, бележките за шоуто и безплатните.
Индикаторите за ниво на обслужване, целите на нивото на обслужване и споразуменията за ниво на обслужване създават йерархия. Индикаторите за ниво на обслужване определят число. Целите за ниво на обслужване определят цел за броя. Споразуменията за ниво на обслужване определят правила и очаквания за това кога целта е ударена или пропусната.
Това са мощни инструменти за обединяване на заинтересованите страни и определяне на приоритети. Всеки надгражда друг, така че нека работим отдолу нагоре, като започнем с индикаторите за ниво на обслужване.
SLI, или индикатори за ниво на услугата, определят количествено аспектите на предоставяната услуга. Примерите включват латентност, време за работа и процент грешки. Използвайте този шаблон за дефиниране на SLI: празно, измерено чрез празно. Ето един пример: степен на успех, измерена чрез броя на успешните HTTP заявки, разделен на общия брой HTTP заявки. Изразете SLI като съотношения на общия брой стоки, разделени на общия брой събития. Това осигурява плъзгаща се скала между нула и сто.
Има безкраен избор за SLI, така че те трябва да бъдат избрани внимателно, за да се измери стойността на предоставената услуга. Задайте този въпрос като инстинктивна проверка, когато обмисляте SLI: „услугата ще загуби ли потребители, ако този индикатор бъде повлиян отрицателно?“
И така, кое е правилното число? Това число е SLO или целта за ниво на обслужване. Очевидно 0 е грешното число, защото това означава, че всичко е счупено. От друга страна, 100% не е правилният отговор, защото това означава, че нищо не се поврежда. Това е невъзможно. Истинският отговор е, че зависи само от бизнеса.
SLO се намира в пресечната точка на продукта и инженеринга. Заинтересованите страни трябва да се съгласят, че ако SLO падне под даден праг, тогава си струва да се пренастрои приоритетът на работата, за да се достигне SLO. Означава, че отговорната страна може да се ангажира с нова работа или да избегне съществуваща работа, за да я поддържа. От друга страна, това означава, че работите по начини за поддържане на надеждността, така че SLO да не падне под прага на първо място.
След като SLO бъде дефинирано, тогава заинтересованите страни могат да сключат споразумение за това как да поддържат SLO и какво да правят, когато то бъде пропуснато. Това е споразумението за ниво на обслужване или SLA. Те обикновено са под формата на финансови санкции или други негативни последици, записани в договор. Тези споразумения се сключват между потребителя и доставчика.
Въпреки това съм съсредоточен върху споразумението между отговорните за поддържането на SLO. Инженерната литература за надеждност на сайта препоръчва използването на бюджет за грешки за това.
Ето един пример. Да кажем, че SLO е 99% на тримесечие. Това осигурява бюджет за грешка от 1%. Така че, ако проблемът причини процент на неуспех от 0,5%, тогава се използват 50% от бюджета за грешки.
Бюджетът за грешки е обективен начин за управление на риска по отношение на SLO. Екипът може да реши да предприеме рискована миграция на база данни, когато бюджетът за грешки е пълен. От друга страна екипът може да бъде по-консервативен, когато бюджетът е нисък, като се фокусира върху издания с нисък риск. Бюджетът за грешки позволява на екипите да балансират риска, иновациите и надеждността. Това предполага, че всички заинтересовани страни приемат бюджета за грешки като средство за планиране и поддържане на SLO. С други думи, ако бюджетът за грешки е изчерпан, тогава може да не са възможни издания. Съгласни ли са заинтересованите страни с това?
Точно там приятелите са трудният проблем. Измерването на нещо е лесен проблем. Даването на правомощията на SLO да променя приоритетите е трудният проблем. Ето защо е толкова важно и не мога да го преувелича достатъчно, SLO да има пряка връзка с бизнес успеха. Има нужда от зъби!
Много отбори не решават трудния проблем. В резултат на това SLO са кабуки театър или преместени в някаква електронна таблица с KPI. До голяма степен това е моят опит. Въпреки това имам положителен опит с добре проектирани SLO и споразумение да се ангажирам с тях.
И накрая, искам да се върна към доставката на софтуер и трите начина на DevOps.
SLI и SLO осигуряват обратна връзка за процеса на доставка на софтуер. Обратната връзка е вторият начин на DevOps. Екипите не могат да оценят напредъка си без обратна връзка от производството. SLO предоставят обратна връзка на всички заинтересовани страни, било то инженери, бизнес ръководители или продуктови мениджъри. Обратната връзка е втората половина от непрекъснатия цикъл на доставка. Бърз поток — A.K.A. непрекъсната доставка — случва се само с бърза обратна връзка.
SLO също не са статични. Те ще се променят с промените в бизнеса. Предприятията на ранен етап могат да приемат повече риск от установените предприятия. С течение на времето системите може да се променят до точка, в която поддържането на SLO има отрицателно въздействие върху бизнеса. Поддържането на SLO е безкраен акт на балансиране, който изисква обратна връзка от заинтересованите страни и гъвкавост за подобряването им с течение на времето. Това е акт на непрекъснато подобрение – A.K.A третият начин на DevOps.
Много теми в доставката на софтуер, инженеринга за издаване или инженеринга за надеждност на сайта се свързват обратно със SLO, така че не ги пропускайте. Те са задължителни за издигане нагоре в йерархията на нуждите на SRE. Обърнете се към работната книга SRE и книгата SRE за примери за определяне, дефиниране и прилагане на всичко, обсъдено в този епизод.
