SRE (Site Reliability Engineering) – бұл веб-жобалардың қолжетімділігін қамтамасыз ету тәсілі. Ол DevOps үшін негіз болып саналады және DevOps тәжірибелерін қолдануда табысқа қалай жетуге болатыны туралы айтылады. Осы мақаладағы аударма кітаптар Google-дан. Мен бұл аударманы өзім дайындадым және мониторинг процестерін түсінудегі өз тәжірибеме сүйендім. Телеграм каналында и Мен сондай-ақ қызмет деңгейінің мақсаттары туралы сол кітаптың 6-тарауының аудармасын жарияладым.
Мысықтың аудармасы. Оқудан ләззат алыңыз!
Қандай көрсеткіштердің шын мәнінде маңызды екенін және оларды қалай өлшеу және бағалау керектігін түсіну болмаса, қызметті басқару мүмкін емес. Осы мақсатта біз пайдаланушыларымызға ішкі API интерфейстерінің бірін немесе жалпыға қолжетімді өнімді пайдаланатынына қарамастан белгілі бір қызмет деңгейін анықтаймыз және қамтамасыз етеміз.
Біз интуициямызды, тәжірибемізді және пайдаланушылардың қызмет көрсету деңгейі көрсеткіштерін (SLI), қызмет көрсету деңгейінің мақсаттарын (SLOs) және қызмет көрсету деңгейі келісімдерін (SLAs) түсінуге деген ұмтылысын түсінеміз. Бұл өлшемдер біз қадағалағымыз келетін және күтілетін қызмет сапасын қамтамасыз ете алмасақ, әрекет ететін негізгі көрсеткіштерді сипаттайды. Сайып келгенде, дұрыс көрсеткіштерді таңдау бірдеңе дұрыс болмаса, дұрыс әрекеттерді басқаруға көмектеседі, сонымен қатар SRE командасына қызметтің денсаулығына сенімділік береді.
Бұл тарау метрикалық үлгілеу, метрикалық таңдау және метрикалық талдау мәселелерімен күресу үшін қолданатын тәсілді сипаттайды. Түсініктемелердің көпшілігі мысалдарсыз болады, сондықтан біз негізгі ойларды көрсету үшін оны іске асыру мысалында сипатталған Шекспир қызметін (Шекспирдің шығармаларын іздеу) қолданамыз.
Қызмет деңгейінің терминологиясы
Көптеген оқырмандар SLA түсінігімен таныс болуы мүмкін, бірақ SLI және SLO терминдері мұқият анықтамаға лайық, өйткені жалпы SLA термині шамадан тыс жүктелген және контекстке байланысты бірқатар мағыналарға ие. Түсінікті болу үшін біз бұл мәндерді бөліп алғымыз келеді.
Көрсеткіштер
SLI - қызмет деңгейінің көрсеткіші — ұсынылатын қызмет деңгейінің бір аспектісінің мұқият анықталған сандық өлшемі.
Көптеген қызметтер үшін SLI кілті сұраудың кешігуі болып саналады - сұрауға жауапты қайтару үшін қанша уақыт қажет. Басқа жалпы SLI-ге жиі қабылданған барлық сұраулардың бір бөлігі ретінде көрсетілген қате жылдамдығы және әдетте секундына сұраныспен өлшенетін жүйенің өткізу қабілеті кіреді. Өлшемдер жиі жинақталады: бастапқы деректер алдымен жиналады, содан кейін өзгеру жылдамдығына, орташа мәнге немесе процентильге түрлендіріледі.
Ең дұрысы, SLI қызығушылықтың қызмет деңгейін тікелей өлшейді, бірақ кейде өлшеу үшін тек қатысты метрика қолжетімді болады, себебі түпнұсқаны алу немесе түсіндіру қиын. Мысалы, клиенттік кідіріс жиі неғұрлым сәйкес көрсеткіш болып табылады, бірақ кідіріс тек серверде өлшенетін кездер болады.
SRE үшін маңызды болып табылатын басқа SLI түрі қолжетімділік немесе қызметті пайдалануға болатын уақыт бөлігі болып табылады. Көбінесе табысты сұраулардың жылдамдығы ретінде анықталады, кейде кірістілік деп аталады. (Өмір мерзімі — деректердің ұзақ уақыт бойы сақталуы ықтималдығы — деректерді сақтау жүйелері үшін де маңызды.) 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 сәтсіз ТҚҰ салдарын жеңілдетуге көмектеседі. Олар сондай-ақ SLI анықтауға көмектесе алады: Әлбетте, келісімде SLO өлшеудің объективті жолы болуы керек немесе келіспеушілік болады.
Google Search жалпыға ортақ SLA жоқ маңызды қызметтің мысалы болып табылады: біз барлығының Іздеуді мүмкіндігінше тиімді пайдаланғанын қалаймыз, бірақ біз әлеммен келісімшартқа отырған жоқпыз. Дегенмен, іздеу қолжетімсіз болса, салдары әлі де бар - қолжетімсіздік біздің беделіміздің төмендеуіне, сонымен қатар жарнамадан түсетін кірістің төмендеуіне әкеледі. Google for Work сияқты көптеген басқа Google қызметтерінде пайдаланушылармен нақты қызмет деңгейі келісімдері бар. Белгілі бір қызметте SLA бар-жоғына қарамастан, SLI және SLO анықтау және оларды қызметті басқару үшін пайдалану маңызды.
Көптеген теориялар - енді тәжірибе.
Тәжірибедегі көрсеткіштер
Қызмет деңгейін өлшеу үшін сәйкес көрсеткіштерді таңдау маңызды деген қорытындыға келгенімізді ескере отырып, енді қай көрсеткіштердің қызмет немесе жүйе үшін маңызды екенін қалай білуге болады?
Сізге және сіздің пайдаланушыларыңызға не маңызды?
Мониторинг жүйесінде бақылай алатын SLI ретінде әрбір көрсеткішті пайдаланудың қажеті жоқ; Пайдаланушылар жүйеден не қалайтынын түсіну бірнеше көрсеткіштерді таңдауға көмектеседі. Тым көп индикаторларды таңдау маңызды көрсеткіштерге назар аударуды қиындатады, ал аз санды таңдау жүйенің үлкен бөліктерін қараусыз қалдыруы мүмкін. Жүйенің денсаулығын бағалау және түсіну үшін әдетте бірнеше негізгі көрсеткіштерді пайдаланамыз.
Қызметтерді әдетте оларға қатысты SLI тұрғысынан бірнеше бөліктерге бөлуге болады:
- Біздің мысалдағы Шекспир қызметі үшін іздеу интерфейстері сияқты теңшелетін алдыңғы қатарлы жүйелер. Олар қолжетімді болуы керек, кідіріссіз және өткізу қабілеттілігі жеткілікті. Тиісінше, сұрақтар қойылуы мүмкін: сұранысқа жауап бере аламыз ба? Өтінімге жауап беру қанша уақытты алды? Қанша сұрауды өңдеуге болады?
- Сақтау жүйелері. Олар төмен жауап беру кідірісін, қолжетімділігін және ұзақ мерзімділігін бағалайды. Қатысты сұрақтар: Деректерді оқу немесе жазу қанша уақытты алады? Сұраныс бойынша деректерге қол жеткізе аламыз ба? Деректер қажет кезде қол жетімді ме? Осы мәселелерді егжей-тегжейлі талқылау үшін 26-тарауды «Деректердің тұтастығы: сіз оқыған нәрсе - сіз жазасыз» бөлімінен қараңыз.
- Деректерді өңдеу құбырлары сияқты үлкен деректер жүйелері өткізу қабілеті мен сұрауларды өңдеудің кідірісіне сүйенеді. Қатысты сұрақтар: Қанша деректер өңделеді? Деректер сұрауды алудан жауап беруге дейін қанша уақытты алады? (Жүйенің кейбір бөліктерінде белгілі бір кезеңдерде де кешігулер болуы мүмкін.)
Көрсеткіштер жинағы
Қызмет көрсету деңгейінің көптеген көрсеткіштері Боргмон сияқты бақылау жүйесін пайдалана отырып, ең табиғи түрде сервер жағында жиналады (төменде қараңыз). ) немесе Prometheus, немесе жай ғана журналдарды мезгіл-мезгіл талдау, 500 күйі бар HTTP жауаптарын анықтау. Дегенмен, кейбір жүйелер клиенттік көрсеткіштер жиынтығымен жабдықталуы керек, себебі клиенттік бақылаудың болмауы әсер ететін бірқатар мәселелердің болмауына әкелуі мүмкін. пайдаланушылар, бірақ серверлік көрсеткіштерге әсер етпейді. Мысалы, біздің Шекспир іздеу сынағы қолданбасының серверлік жауап кідірісіне назар аудару 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 әдепкі параметрлерін пайдаланады):
- Get RPC қоңырауларының 99% (орта есеппен 1 минуттан астам) 100 мс-тен аз уақыт ішінде аяқталады (барлық сервер серверлерінде өлшенеді).
- Get RPC қоңырауларының 99%-ы 100 мс-тен аз уақытта аяқталады.
Егер өнімділік қисықтарының пішіні маңызды болса, бірнеше SLO көрсетуге болады:
- Get RPC қоңырауларының 90%-ы 1 мс-тен аз уақытта аяқталды.
- Get RPC қоңырауларының 99%-ы 10 мс-тен аз уақытта аяқталды.
- Get RPC қоңырауларының 99.9%-ы 100 мс-тен аз уақытта аяқталды.
Егер пайдаланушылар гетерогенді жұмыс жүктемелерін жасаса: жаппай өңдеу (өткізу қабілеті маңызды) және интерактивті өңдеу (бұл үшін кідіріс маңызды), әрбір жүктеме класы үшін жеке мақсаттарды анықтау орынды болуы мүмкін:
- Тұтынушы сұрауларының 95%-ы өткізу қабілеттілігін қажет етеді. Орындалған RPC қоңырауларының санын <1 с орнатыңыз.
- Клиенттердің 99%-ы кідіріс туралы ойлайды. Трафигі <1 КБ және <10 мс орындалатын 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-қадам серверлер CPU байланыстырады деген гипотезаны сынауды қамтуы мүмкін және қосымша серверлерді қосу жүктемені таратады. SLO болмаса, сіз әрекет ету керек пе (немесе қашан) білмейсіз.
SLO орнату - содан кейін пайдаланушы күтулері орнатылады
SLO жариялау пайдаланушының жүйе әрекетіне қатысты күтулерін белгілейді. Пайдаланушылар (және әлеуетті пайдаланушылар) оның пайдалануға жарамдылығын түсіну үшін қызметтен не күтетінін жиі білгісі келеді. Мысалы, фотосуреттерді ортақ пайдалану веб-сайтын пайдаланғысы келетін адамдар, сол қызмет мұрағаттық жазбаларды басқару жүйесі үшін өте қолайлы болуы мүмкін болса да, азырақ қолжетімділіктің орнына ұзақ өмір сүруді және төмен бағаны уәде ететін қызметті пайдаланудан аулақ болуы мүмкін.
Пайдаланушыларыңыз үшін шынайы күтулерді орнату үшін келесі тактикалардың бірін немесе екеуін де пайдаланыңыз:
- Қауіпсіздік шегін сақтаңыз. Пайдаланушыларға жарияланғаннан гөрі қатаңырақ ішкі SLO пайдаланыңыз. Бұл сізге проблемалар сырттан көрінбей тұрып әрекет ету мүмкіндігін береді. SLO буфері сонымен қатар жүйенің өнімділігіне әсер ететін шығарылымдарды орнату кезінде қауіпсіздік шегіне ие болуға мүмкіндік береді және пайдаланушылардың тоқтап қалу уақытын ренжітпей, жүйеге оңай қызмет көрсетуді қамтамасыз етеді.
- Пайдаланушы күткеннен асып кетпеңіз. Пайдаланушылар сіз айтқан нәрсеге емес, сіз ұсынатын нәрсеге негізделеді. Қызметіңіздің нақты өнімділігі көрсетілген SLO мәнінен әлдеқайда жақсы болса, пайдаланушылар ағымдағы өнімділікке сенеді. Жүйені әдейі өшіру немесе жеңіл жүктемелер кезінде өнімділікті шектеу арқылы шамадан тыс тәуелділікті болдырмауға болады.
Жүйенің күтулерге қаншалықты сәйкес келетінін түсіну жүйені жылдамдатуға және оны қол жетімді және икемді етуге инвестиция салуды шешуге көмектеседі. Немесе, егер қызмет тым жақсы жұмыс істеп жатса, қызметкерлердің біраз уақытын техникалық қарызды өтеу, жаңа мүмкіндіктерді қосу немесе жаңа өнімдерді енгізу сияқты басқа басымдықтарға жұмсау керек.
Практикадағы келісімдер
SLA жасау бизнес пен заң топтарынан оны бұзғаны үшін салдар мен жазаларды анықтауды талап етеді. SRE рөлі оларға SLA қамтылған SLO сәйкес келудегі ықтимал қиындықтарды түсінуге көмектесу болып табылады. SLO құру бойынша ұсыныстардың көпшілігі SLA үшін де қолданылады. Пайдаланушыларға уәде бергенде консервативті болғаныңыз дұрыс, себебі сізде неғұрлым көп болса, негізсіз немесе қанағаттандыру қиын болып көрінетін SLA шарттарын өзгерту немесе жою соғұрлым қиын болады.
Аударманы соңына дейін оқығаныңыз үшін рахмет. Бақылау туралы менің телеграм каналыма жазылыңыз и .
Ақпарат көзі: www.habr.com