СРЕ (Сите Релиабилити Енгинееринг) је приступ да се веб пројекти постану доступни. Сматра се оквиром за ДевОпс и говори како да успете у примени ДевОпс пракси. Овај чланак преводи књиге од Гоогле-а. Сам сам припремио овај превод и ослањао се на сопствено искуство у разумевању процеса праћења. У телеграм каналу и Такође сам објавио превод поглавља 6 исте књиге о циљевима нивоа услуге.
Превод кат. Уживај у читању!
Немогуће је управљати услугом ако нема разумевања који су индикатори заправо битни и како их мерити и вредновати. У том циљу дефинишемо и пружамо одређени ниво услуге нашим корисницима, без обзира да ли користе неки од наших интерних АПИ-ја или јавни производ.
Користимо нашу интуицију, искуство и разумевање жеље корисника да разумеју индикаторе нивоа услуге (СЛИ), циљеве нивоа услуге (СЛО) и уговоре о нивоу услуге (СЛА). Ове димензије описују главне метрике које желимо да пратимо и на које ћемо реаговати ако не можемо да обезбедимо очекивани квалитет услуге. На крају крајева, одабир правих метрика помаже у вођењу исправних радњи ако нешто крене наопако, а такође даје СРЕ тиму поверење у здравље услуге.
Ово поглавље описује приступ који користимо у борби против проблема метричког моделирања, селекције метрике и метричке анализе. Већина објашњења ће бити без примера, па ћемо користити Шекспирову услугу описану у њеном примеру имплементације (потрага за Шекспировим делима) да илуструјемо главне тачке.
Терминологија нивоа услуге
Многи читаоци су вероватно упознати са концептом СЛА, али термини СЛИ и СЛО заслужују пажљиву дефиницију јер је генерално термин СЛА преоптерећен и има више значења у зависности од контекста. Ради јасноће, желимо да раздвојимо ове вредности.
Индикатори
СЛИ је индикатор нивоа услуге—пажљиво дефинисана квантитативна мера једног аспекта нивоа пружене услуге.
За већину услуга, кључни СЛИ се сматра кашњењем захтева – колико дуго је потребно да се врати одговор на захтев. Други уобичајени СЛИ укључују стопу грешке, често изражену као део свих примљених захтева, и системску пропусност, обично мерену у захтевима у секунди. Мерења се често обједињују: необрађени подаци се прво прикупљају, а затим се претварају у стопу промене, средњу вредност или проценат.
У идеалном случају, СЛИ директно мери ниво услуге од интереса, али понекад је само сродна метрика доступна за мерење јер је оригиналну тешко добити или протумачити. На пример, кашњење на страни клијента је често прикладнији показатељ, али постоје случајеви када се кашњење може мерити само на серверу.
Други тип СЛИ који је важан за СРЕ је доступност или део времена током којег се услуга може користити. Често се дефинише као стопа успешних захтева, која се понекад назива и принос. (Век трајања – вероватноћа да ће подаци бити задржани током дужег временског периода – такође је важна за системе за складиштење података.) Иако 100% доступност није могућа, доступност близу 100% је често достижна; вредности доступности се изражавају као број „деветки“ » проценат доступности. На пример, доступност од 99% и 99,999% може бити означена као „2 деветке” и „5 деветке”. Тренутни наведени циљ доступности Гоогле Цомпуте Енгине-а је „три и по деветке“ или 99,95%.
Мете
СЛО је циљ нивоа услуге: циљна вредност или опсег вредности за ниво услуге који се мери помоћу СЛИ. Нормална вредност за СЛО је „СЛИ ≤ Таргет“ или „Доња граница ≤ СЛИ ≤ Горња граница“. На пример, могли бисмо да одлучимо да ћемо резултате Шекспирове претраге вратити „брзо“ тако што ћемо СЛО поставити на просечно кашњење упита за претрагу мање од 100 милисекунди.
Одабир правог СЛО-а је сложен процес. Прво, не можете увек да изаберете одређену вредност. За спољне долазне ХТТП захтеве вашој услузи, метрика упита у секунди (КПС) је првенствено одређена жељом ваших корисника да посете вашу услугу, а за то не можете да подесите СЛО.
С друге стране, можете рећи да желите да просечно кашњење за сваки захтев буде мање од 100 милисекунди. Постављање таквог циља може вас приморати да напишете свој фронтенд са малим кашњењем или купите опрему која обезбеђује такво кашњење. (100 милисекунди је очигледно произвољан број, али боље је имати чак ниже бројеве кашњења. Постоје докази који указују на то да су велике брзине боље од малих брзина и да кашњење у обради корисничких захтева изнад одређених вредности заправо тера људе да се држе подаље из ваше службе.)
Опет, ово је више двосмислено него што може изгледати на први поглед: не би требало потпуно искључити КПС из прорачуна. Чињеница је да су КПС и латенција уско повезани једни са другима: већи КПС често доводи до већих кашњења, а услуге обично доживљавају нагло смањење перформанси када достигну одређени праг оптерећења.
Одабир и објављивање СЛО-а поставља очекивања корисника о томе како ће услуга радити. Ова стратегија може смањити неосноване жалбе против власника услуге, као што је спор рад. Без експлицитног СЛО-а, корисници често креирају сопствена очекивања о жељеним перформансама, која можда немају никакве везе са мишљењима људи који дизајнирају и управљају услугом. Ова ситуација може довести до надуваних очекивања од сервиса, када корисници погрешно верују да ће услуга бити приступачнија него што заправо јесте, и изазвати неповерење када корисници верују да је систем мање поуздан него што заправо јесте.
Уговори
Уговор о нивоу услуге је експлицитан или имплицитан уговор са вашим корисницима који укључује последице испуњавања (или неиспуњавања) СЛО-ова које садрже. Последице се најлакше препознају када су финансијске – попуст или новчана казна – али могу имати и друге облике. Једноставан начин да се говори о разлици између СЛО и СЛА је да се запита „шта се дешава ако СЛО нису испуњени?“ Ако нема јасних посљедица, готово сигурно гледате у СЛО.
СРЕ обично није укључен у креирање СЛА јер су СЛА уско повезани са пословним одлукама и одлукама о производима. СРЕ, међутим, учествује у помагању у ублажавању посљедица неуспјелих СЛО-а. Они такође могу помоћи у одређивању СЛИ: Очигледно, мора постојати објективан начин за мјерење СЛО у споразуму или ће доћи до неслагања.
Гоогле претрага је пример важне услуге која нема јавни СЛА: желимо да сви користе претрагу што ефикасније, али нисмо потписали уговор са светом. Међутим, и даље постоје последице ако претрага није доступна – недоступност доводи до пада наше репутације, као и до смањења прихода од оглашавања. Многе друге Гоогле услуге, као што је Гоогле фор Ворк, имају експлицитне уговоре о нивоу услуге са корисницима. Без обзира на то да ли одређена услуга има СЛА, важно је дефинисати СЛИ и СЛО и користити их за управљање услугом.
Толико теорије - сада за искуство.
Индикатори у пракси
С обзиром на то да смо закључили да је важно одабрати одговарајућу метрику за мерење нивоа услуге, како сада знате које су метрике важне за услугу или систем?
Шта вас и ваше кориснике занима?
Не морате да користите сваку метрику као СЛИ коју можете пратити у систему за праћење; Разумевање шта корисници желе од система помоћи ће вам да изаберете неколико метрика. Одабир превише индикатора отежава фокусирање на важне индикаторе, док одабир малог броја може оставити велике делове вашег система без надзора. Обично користимо неколико кључних индикатора да проценимо и разумемо здравље система.
Услуге се генерално могу поделити на неколико делова у смислу СЛИ који су релевантни за њих:
- Прилагођени фронт-енд системи, као што су интерфејси за претрагу за Шекспирову услугу из нашег примера. Морају бити доступни, без кашњења и довољног пропусног опсега. Сходно томе, могу се поставити питања: можемо ли одговорити на захтев? Колико је времена требало да се одговори на захтев? Колико захтева се може обрадити?
- Системи за складиштење. Они цене ниско кашњење одговора, доступност и издржљивост. Повезана питања: Колико је времена потребно за читање или писање података? Можемо ли приступити подацима на захтев? Да ли су подаци доступни када су нам потребни? Погледајте Поглавље 26 Интегритет података: оно што читате је оно што пишете за детаљну дискусију о овим питањима.
- Системи великих података као што су цевоводи за обраду података ослањају се на пропусност и кашњење у обради упита. Повезана питања: Колико података се обрађује? Колико времена је потребно да подаци путују од пријема захтева до издавања одговора? (Неки делови система такође могу имати кашњења у одређеним фазама.)
Збирка индикатора
Многи индикатори нивоа услуге се најприродније прикупљају на страни сервера, користећи систем за праћење као што је Боргмон (погледајте доле). ) или Прометхеус, или једноставно периодично анализирање дневника, идентификујући ХТТП одговоре са статусом 500. Међутим, неки системи би требало да буду опремљени прикупљањем метрика на страни клијента, пошто недостатак надзора на страни клијента може довести до пропуштања бројних проблема који утичу на корисника, али не утичу на метрику на страни сервера. На пример, фокусирање на кашњење позадинског одговора наше апликације за тестирање Шекспирове претраге може да доведе до кашњења на страни корисника због проблема са ЈаваСцрипт-ом: у овом случају, мерење колико дуго је претраживачу потребно да обради страницу је боља метрика.
Агрегација
Ради једноставности и лакоће употребе, често обједињујемо необрађена мерења. Ово се мора урадити пажљиво.
Неки показатељи изгледају једноставни, попут захтева у секунди, али чак и ово наизглед једноставно мерење имплицитно обједињује податке током времена. Да ли се мерење прима једном у секунди или се мерење усредсређује на број захтева у минути? Последња опција може сакрити много већи тренутни број захтева који трају само неколико секунди. Замислите систем који опслужује 200 захтева у секунди са парним бројевима и 0 све остало време. Константа у виду просечне вредности од 100 захтева у секунди и двоструко тренутно оптерећење нису иста ствар. Слично томе, усредњавање кашњења упита може изгледати привлачно, али крије важан детаљ: могуће је да ће већина упита бити брза, али ће бити много упита који су спори.
Већина индикатора се боље посматра као дистрибуције, а не као просеци. На пример, за кашњење СЛИ, неки захтеви ће бити обрађени брзо, док ће неки увек трајати дуже, понекад много дуже. Једноставан просек може сакрити ова дуга кашњења. На слици је приказан пример: иако је обичном захтеву потребно приближно 50 мс да се послужи, 5% захтева је 20 пута спорије! Праћење и упозорење само на основу просечне латенције не показују промене у понашању током дана, када су у ствари приметне промене у времену обраде неких захтева (највиша линија).
50, 85, 95 и 99 процената кашњења система. И оса је у логаритамском формату.
Коришћење перцентила за индикаторе вам омогућава да видите облик дистрибуције и њене карактеристике: висок проценат процената, као што је 99 или 99,9, показује најгору вредност, док 50 перцентил (такође познат као медијана) показује најчешће стање метрику. Што је већа дисперзија времена одговора, то више дуготрајних захтева утиче на корисничко искуство. Ефекат је појачан под великим оптерећењем и у присуству редова. Истраживање корисничког искуства је показало да људи генерално преферирају спорији систем са великом варијацијом времена одзива, тако да се неки СРЕ тимови фокусирају само на високе процентуалне резултате, на основу тога да ако је понашање метрике на 99,9 процената добро, већина корисника неће имати проблема .
Напомена о статистичким грешкама
Обично радије радимо са перцентилима него са средњом (аритметичком средином) скупа вредности. Ово нам омогућава да размотримо више дисперзоване вредности, које често имају значајно другачије (и интересантније) карактеристике од просечних. Због вештачке природе рачунарских система, метричке вредности су често искривљене, на пример, ниједан захтев не може да добије одговор за мање од 0 мс, а временско ограничење од 1000 мс значи да не може бити успешних одговора са вредностима већим него временско ограничење. Као резултат тога, не можемо прихватити да средња вредност и медијана могу бити исти или блиски једно другом!
Без претходног тестирања и осим ако постоје одређене стандардне претпоставке и апроксимације, пазимо да не закључимо да се наши подаци нормално дистрибуирају. Ако дистрибуција није онако како се очекивало, процес аутоматизације који решава проблем (на пример, када види ванредне вредности, поново покреће сервер са великим кашњењима у процесуирању захтева) можда то ради пречесто или недовољно често (и једно и друго није врло добар).
Стандардизујте индикаторе
Препоручујемо да стандардизујете опште карактеристике за СЛИ тако да не морате сваки пут да спекулишете о њима. Свака карактеристика која задовољава стандардне обрасце може бити искључена из спецификације појединачног СЛИ, на пример:
- Интервали агрегације: „у просеку преко 1 минута“
- Области агрегације: „Сви задаци у кластеру“
- Колико често се мерења врше: „Сваких 10 секунди“
- Који су захтеви укључени: „ХТТП ГЕТ из послова надгледања црне кутије“
- Како се добијају подаци: „Захваљујући нашем праћењу мереном на серверу“
- Кашњење приступа подацима: „Време до последњег бајта“
Да бисте уштедели труд, направите скуп СЛИ шаблона за вишекратну употребу за сваку уобичајену метрику; такође олакшавају свима да разумеју шта значи одређени СЛИ.
Циљеви у пракси
Почните тако што ћете размишљати (или сазнати!) до чега је вашим корисницима стало, а не шта ви можете да измерите. Често је оно до чега је вашим корисницима стало тешко или немогуће измерити, тако да се на крају приближавате њиховим потребама. Међутим, ако само почнете са оним што је лако измерити, завршићете са мање корисним СЛО. Као резултат тога, понекад смо открили да почетно идентификовање жељених циљева, а затим рад са специфичним индикаторима функционише боље него одабир индикатора и затим постизање циљева.
Дефинишите циљеве
Ради максималне јасноће, требало би дефинисати како се мере СЛО и услови под којима важе. На пример, могли бисмо да кажемо следеће (други ред је исти као први, али користи подразумеване вредности СЛИ):
- 99% (у просеку за 1 минут) Гет РПЦ позива ће се завршити за мање од 100 мс (мерено на свим позадинским серверима).
- 99% Гет РПЦ позива ће се завршити за мање од 100 мс.
Ако је облик криве перформанси важан, можете навести више СЛО:
- 90% Гет РПЦ позива је завршено за мање од 1 мс.
- 99% Гет РПЦ позива је завршено за мање од 10 мс.
- 99.9% Гет РПЦ позива је завршено за мање од 100 мс.
Ако ваши корисници генеришу хетерогена радна оптерећења: групну обраду (за коју је пропусност важна) и интерактивну обраду (за коју је кашњење важно), можда би било вредно дефинисати засебне циљеве за сваку класу оптерећења:
- 95% захтева купаца захтева проток. Подесите број извршених РПЦ позива <1 с.
- 99% клијената брине о кашњењу. Подесите број РПЦ позива са саобраћајем <1 КБ и покренутим <10 мс.
Нереално је и непожељно инсистирати на томе да ће СЛО бити испуњени 100% времена: то може смањити темпо увођења нове функционалности и имплементације и захтијевати скупа рјешења. Уместо тога, боље је дозволити буџет за грешку – проценат дозвољеног застоја система – и надгледати ову вредност дневно или недељно. Виши менаџмент може желети месечне или тромесечне евалуације. (Буџет грешке је једноставно СЛО за поређење са другим СЛО.)
Проценат кршења СЛО може се упоредити са буџетом грешке (погледајте Поглавље 3 и одјељак ), са вредношћу разлике која се користи као улаз у процес који одлучује када ће се применити нова издања.
Избор циљних вредности
Одабир вриједности планирања (СЛО) није чисто техничка активност због производа и пословних интереса који се морају одразити у одабраним СЛИ, СЛО (и евентуално СЛА). Исто тако, можда ће бити потребно размјењивати информације у вези са питањима везаним за особље, вријеме за долазак на тржиште, доступност опреме и финансирање. СРЕ би требало да буде део овог разговора и да помогне у разумевању ризика и одрживости различитих опција. Дошли смо до неколико питања која би могла помоћи да обезбедимо продуктивнију дискусију:
Не бирајте циљ на основу тренутног учинка.
Иако је разумевање снага и ограничења система важно, прилагођавање метрике без расуђивања може вас блокирати у одржавању система: биће потребни херојски напори за постизање циљева који се не могу постићи без значајног редизајнирања.
Будите једноставни
Сложене СЛИ калкулације могу сакрити промене у перформансама система и отежати проналажење узрока проблема.
Избегавајте апсолутне
Иако је примамљиво имати систем који може да поднесе бесконачно растуће оптерећење без повећања латенције, овај захтев је нереалан. Систем који се приближава таквим идеалима вероватно ће захтевати доста времена за пројектовање и изградњу, биће скуп за рад и биће превише добар за очекивања корисника који би радили са било чим мање.
Користите што мање СЛО-ова
Изаберите довољан број СЛО-а да осигурате добру покривеност системских атрибута. Заштитите СЛО које одаберете: Ако никада не можете побиједити у расправи око приоритета навођењем одређеног СЛО-а, вјероватно није вриједно разматрања тог СЛО-а. Међутим, нису сви системски атрибути подложни СЛО-овима: тешко је израчунати ниво задовољства корисника користећи СЛО.
Не јурите за савршенством
Увек можете прецизирати дефиниције и циљеве СЛО-а током времена како будете сазнали више о понашању система под оптерећењем. Боље је почети са плутајућим циљем који ћете временом усавршити него изабрати престрог циљ који мора бити опуштен када сматрате да је недостижан.
СЛО могу и треба да буду кључни покретач у одређивању приоритета рада за СРЕ и програмере производа јер одражавају бригу за кориснике. Добар СЛО је користан алат за спровођење за развојни тим. Али лоше дизајниран СЛО може довести до расипничког рада ако тим уложи херојске напоре да постигне превише агресиван СЛО или лош производ ако је СЛО пренизак. СЛО је моћна полуга, користите је паметно.
Контролишите своја мерења
СЛИ и СЛО су кључни елементи који се користе за управљање системима:
- Надгледање и мерење СЛИ система.
- Упоредите СЛИ са СЛО и одлучите да ли је потребна акција.
- Ако је потребна акција, схватите шта треба да се деси да бисте постигли циљ.
- Довршите ову радњу.
На пример, ако корак 2 покаже да је захтев истекао и да ће прекинути СЛО за неколико сати ако се ништа не уради, корак 3 може укључивати тестирање хипотезе да су сервери везани за ЦПУ и додавање више сервера ће дистрибуирати оптерећење. Без СЛО-а, не бисте знали да ли (или када) да предузмете акцију.
Подесите СЛО - тада ће се поставити очекивања корисника
Објављивање СЛО поставља очекивања корисника за понашање система. Корисници (и потенцијални корисници) често желе да знају шта могу да очекују од услуге да би разумели да ли је она погодна за употребу. На пример, људи који желе да користе веб локацију за дељење фотографија можда желе да избегну коришћење услуге која обећава дуговечност и ниску цену у замену за нешто мању доступност, иако би иста услуга могла бити идеална за систем управљања архивским записима.
Да бисте поставили реална очекивања за своје кориснике, користите једну или обе од следећих тактика:
- Одржавајте маргину сигурности. Користите строжи интерни СЛО од онога што се оглашава корисницима. Ово ће вам дати прилику да реагујете на проблеме пре него што постану видљиви споља. СЛО бафер вам такође омогућава да имате сигурносну маргину када инсталирате издања која утичу на перформансе система и осигуравају да је систем једноставан за одржавање без потребе да фрустрирате кориснике застојима.
- Немојте премашити очекивања корисника. Корисници се заснивају на ономе што нудите, а не на ономе што кажете. Ако је стварни учинак ваше услуге много бољи од наведеног СЛО, корисници ће се ослонити на тренутне перформансе. Претерану зависност можете избећи намерним искључивањем система или ограничавањем перформанси под малим оптерећењима.
Разумевање колико добро систем испуњава очекивања помаже у одлучивању да ли да инвестирате у убрзавање система и учините га доступнијим и отпорнијим. Алтернативно, ако услуга ради превише добро, неко време особља треба потрошити на друге приоритете, као што је отплата техничког дуга, додавање нових функција или увођење нових производа.
Споразуми у пракси
Стварање СЛА захтева од пословних и правних тимова да дефинишу последице и казне за његово кршење. Улога СРЕ-а је да им помогне да схвате могуће изазове у испуњавању СЛО-ова садржаних у СЛА. Већина препорука за креирање СЛО се такође односи на СЛА. Мудро је бити конзервативан у ономе што обећавате корисницима, јер што више имате, то је теже променити или уклонити СЛА које изгледа неразумно или тешко испунити.
Хвала вам што сте прочитали превод до краја. Претплатите се на мој телеграм канал о праћењу и .
Извор: ввв.хабр.цом