SRE (Site Reliability Engineering) – падыход да забеспячэння даступнасці вэб-праектаў. Лічыцца фрэймворкам для DevOps і кажа як дамагчыся поспеху ва ўжыванне DevOps-практык. У гэтым артыкуле пераклад кнігі ад Google. Гэты пераклад я рыхтаваў самастойна і належыў на ўласны досвед разумення працэсаў маніторынгу. У тэлеграм-канале и я публікаваў таксама пераклад 6 раздзела гэтай жа кнігі аб мэтах ўзроўню абслугоўвання.
Пераклад па ката. Прыемнага чытання!
Немагчыма кіраваць сэрвісам, калі няма разумення аб тым, якія паказчыкі насамрэч маюць значэнне і як іх вымяраць і ацэньваць. З гэтай мэтай мы вызначаем і даем пэўны ўзровень абслугоўвання нашым карыстальнікам, незалежна ад таго, ці выкарыстоўваюць яны адзін з нашых унутраных API або публічны прадукт.
Мы выкарыстоўваем свае інтуіцыю, вопыт і ўсведамляем жаданне карыстальнікаў мець уяўленне аб індыкатарах ўзроўню абслугоўвання (SLI), мэтах ўзроўню абслугоўвання (SLO) і пагадненні аб узроўні абслугоўвання (SLA). Гэтыя вымярэнні апісваюць асноўныя метрыкі, якія мы жадаем кантраляваць і на якія будзем рэагаваць, калі не зможам падаць чаканую якасць сэрвісу. У канчатковым рахунку, выбар падыходных паказчыкаў дапамагае кіраваць правільнымі дзеяннямі, калі нешта пайдзе не так, а таксама дае ўпэўненасць камандзе 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 ≤ мэтавага значэння" або "ніжняя мяжа ≤ SLI ≤ верхняя мяжа". Напрыклад, мы можам вырашыць, што мы вернем вынікі пошуку па творах Шэкспіра «хутка», прыняўшы ў выглядзе 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 (гл. ) ці Prometheus, ці проста перыядычна аналізуючы логі, выяўляючы 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 мс.
Калі форма крывых прадукцыйнасці важная, вы можаце пазначыць некалькі мэт SLO:
- 90% выклікаў Get RPC выканаліся менш чым за 1 мс.
- 99% выклікаў Get RPC выканаліся менш чым за 10 мс.
- 99.9% выклікаў Get RPC выканаліся менш чым за 100 мс.
Калі вашы карыстачы генеруюць гетэрагеннымі нагрузкі: масавая апрацоўка (для які важная прапускная здольнасць) і інтэрактыўная апрацоўка (для якой важная велічыня затрымкі), можа быць мэтазгодна вызначыць асобныя мэты для кожнага класа нагрузкі:
- 95% запытам кліентаў важная прапускная здольнасць. Усталюйце падлік RPC-выклікаў якія выконваліся <1 с.
- 99% кліентам важная велічыня затрымкі. Усталюеце падлік RPC-выклікаў з трафікам <1 кБ і якія выконваліся <10 мс.
Нерэалістычна і непажадана настойваць на тым, што 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, якія здаюцца неразумнымі ці цяжкімі для выканання.
Дзякуй, што прачыталі пераклад да канца. Падпісвайцеся на мой тэлеграм-канал аб маніторынгу и .
Крыніца: habr.com