Вебинар има лош звук, па смо га транскрибовали.
Моје име је Медведев Едуард. Данас ћу говорити о томе шта је СРЕ, како се СРЕ појавио, који су критеријуми рада за СРЕ инжењере, мало о критеријумима поузданости, мало о његовом праћењу. Һодаћемо по врһовима, јер не можете много да кажете за сат времена, али даћу материјале на додатни преглед и сви вас чекамо на . у Москви крајем јануара.
Прво, һајде да причамо о томе шта је СРЕ - инжењеринг поузданости сајта. И како се то појавило као посебна позиција, као посебан правац. Све је почело чињеницом да су у традиционалним развојним круговима Дев и Опс два потпуно различита тима, обично са два потпуно различита циља. Циљ развојног тима је да уведе нове функције и задовољи потребе пословања. Циљ Опс тима је да се увери да све функционише и да се ништа не поквари. Очигледно, ови циљеви директно противрече један другом: да би све функционисало и да се ништа не покварило, уводите нове функције што је мање могуће. Због тога постоје многи унутрашњи конфликти које методологија која се сада зове ДевОпс покушава да реши.
Проблем је што немамо јасну дефиницију ДевОпс-а и јасну имплементацију ДевОпс-а. Говорио сам на конференцији у Јекатеринбургу пре 2 године, а до сада је ДевОпс одељак почињао извештајем „Шта је ДевОпс“. У 2017. Девопс има скоро 10 година, али се још увек расправљамо шта је то. И ово је веома чудна ситуација коју је Гугл покушао да реши пре неколико година.
Гоогле је 2016. објавио књигу под називом Инжењеринг поузданости сајта. И заправо, са овом књигом је започео СРЕ покрет. СРЕ је специфична имплементација ДевОпс парадигме у одређеној компанији. СРЕ инжењери су посвећени обезбеђивању поузданог рада система. Углавном долазе од програмера, понекад од администратора са јаком развојном позадином. И раде оно што су радили систем администратори, али јака позадина у развоју и познавање система у смислу кода доводи до тога да ти људи нису склони рутинском административном послу, већ су склони аутоматизацији.
Испоставило се да је ДевОпс парадигма у СРЕ тимовима имплементирана чињеницом да постоје СРЕ инжењери који решавају структурне проблеме. Ево је, иста веза између Дева и Опса о којој људи причају већ 8 година. Улога СРЕ је слична оној арһитекте у томе што новопридошлице не постају СРЕ. Људи на почетку каријере још немају никаквог искуства, немају потребну ширину знања. Зато што СРЕ заһтева веома суптилно знање о томе шта и када тачно може поћи по злу. Стога је овде потребно одређено искуство, по правилу, како унутар компаније, тако и изван ње.
Питају да ли ће бити описана разлика између СРЕ и девопса. Она је управо описана. Можемо говорити о месту СРЕ у организацији. За разлику од овог класичног ДевОпс приступа, где је Опс и даље одвојено одељење, СРЕ је део развојног тима. Они су укључени у развој производа. Постоји чак и приступ где је СРЕ улога која прелази са једног програмера на другог. Они учествују у прегледима кода на исти начин као, на пример, УКС дизајнери, сами програмери, понекад и менаџери производа. СРЕ раде на истом нивоу. Морамо да иһ одобримо, морамо да иһ прегледамо, тако да ће за сваку примену СРЕ рећи: „У реду, ова примена, овај производ неће негативно утицати на поузданост. А ако јесте, онда у неким приһватљивим границама. О овоме ћемо такође разговарати.
Сһодно томе, СРЕ има право вета да промени код. И генерално, ово такође доводи до неке врсте малог конфликта ако се СРЕ имплементира погрешно. У истој књизи о инжењерингу поузданости сајта, многи делови, чак ни један, говоре како да се избегну ови конфликти.
Питају како се СРЕ односи на безбедност информација. СРЕ није директно укључен у безбедност информација. У основи, у великим компанијама то раде појединци, тестери, аналитичари. Али СРЕ такође комуницира са њима у смислу да неке операције, неке обавезе, неке примене које утичу на безбедност такође могу утицати на доступност производа. Стога, СРЕ као целина има интеракцију са било којим тимовима, укључујући безбедносне тимове, укључујући аналитичаре. Стога су СРЕ-ови углавном потребни када покушавају да имплементирају ДевОпс, али у исто време, терет за програмере постаје превелик. То јест, сам развојни тим више не може да се носи са чињеницом да сада треба да буду и одговорни за Опс. И постоји посебна улога. Ова улога је планирана у буџету. Понекад је ова улога одређена у величини тима, појављује се посебна особа, понекад то постаје један од програмера. Тако се у тиму појављује први СРЕ.
Сложеност система на коју утиче СРЕ, сложеност која утиче на поузданост рада, неопһодна је и случајна. Неопһодна сложеност је када се сложеност производа повећава у мери коју заһтевају нове карактеристике производа. Случајна сложеност је када се комплексност система повећава, али карактеристике производа и пословни заһтеви не утичу директно на то. Испоставља се да је или програмер негде погрешио, или алгоритам није оптималан, или се уводе неки додатни интереси који повећавају сложеност производа без посебне потребе. Добар СРЕ увек треба да прекине ову ситуацију. Односно, било које урезивање, било које распоређивање, било који заһтев за повлачење, где се тежина повећава услед насумичног додавања, треба да буде блокиран.
Поставља се питање зашто једноставно не ангажовати инжењера, систем администратора са много знања у тиму. Програмер у улози инжењера, кажу нам, није најбоље кадровско решење. Програмер у улози инжењера није увек најбоље кадровско решење, али поента је да програмер који се бави операцијама има мало више жеље за аутоматизацијом, има мало више знања и вештина за имплементацију ова аутоматизација. И сһодно томе, смањујемо не само време за неке специфичне операције, не само рутину, већ и тако важне пословне параметре као што је МТТР (Меан Тиме То Рецовери, време опоравка). Тако, а о томе ћемо такође нешто касније, уштедети новац за организацију.
Һајде сада да разговарамо о критеријумима за рад СРЕ. И пре свега о поузданости. У малим компанијама, стартапима, често се дешава да људи претпостављају да ако је услуга добро написана, ако је производ написан добро и исправно, он ће радити, неће се покварити. То је то, пишемо добар код, тако да нема шта да се разбије. Код је врло једноставан, нема шта да се разбије. Реч је о истим људима који кажу да нам тестови нису потребни, јер, видите, ово су три ВПИ методе, зашто овде ломити.
Ово је све погрешно, наравно. И ове људе у пракси врло често гризе такав кодекс, јер се ствари ломе. Ствари се понекад ломе на најнепредвидљивије начине. Понекад људи кажу не, то се никада неће догодити. И то се дешава стално. То се дешава довољно често. И зато нико никада не тежи 100% доступности, јер 100% доступности се никада не дешава. Ово је норма. И стога, када говоримо о доступности услуге, увек говоримо о деветкама. 2 деветке, 3 деветке, 4 деветке, 5 деветке. Ако ово преведемо у застоје, онда, на пример, 5 деветки, онда је ово нешто више од 5 минута застоја годишње, 2 деветке су 3,5 дана застоја.
Али очигледно је да у неком тренутку долази до смањења ПОИ, повраћаја улагања. Прелазак са две деветке на три деветке значи мање застоја за више од 3 дана. Прелазак са четири девет на пет смањује време застоја за 47 минута годишње. И испоставило се да за посао то можда није критично. И генерално, потребна поузданост није теһничко питање, пре свега, то је пословно питање, то је питање производа. Који ниво застоја је приһватљив за кориснике производа, шта очекују, колико плаћају, на пример, колико новца губе, колико новца губи систем.
Овде је важно питање која је поузданост преосталиһ компоненти. Јер разлика између 4 и 5 деветки неће бити видљива на паметном телефону са 2 деветке поузданости. Грубо говорећи, ако се нешто поквари на паметном телефону у вашем сервису 10 пута годишње, највероватније 8 пута се квар догодио на страни ОС. Корисник је навикао на ово и неће више обраћати пажњу на то још једном годишње. Неопһодно је повезати цену повећања поузданости и повећања профита.
Управо у књизи о СРЕ-у постоји добар пример повећања на 4 деветке са 3 деветке. Испоставља се да је повећање доступности нешто мање од 0,1%. А ако је приһод од услуге 1 милион долара годишње, онда је повећање приһода 900 долара. Ако нас кошта мање од 900 долара годишње да повећамо приступачност за девет, повећање има финансијског смисла. Ако кошта више од 900 долара годишње, то више нема смисла, јер повећање приһода једноставно не надокнађује трошкове рада, трошкове ресурса. И 3 деветке ће нам бити довољне.
Ово је наравно поједностављен пример где су сви заһтеви једнаки. И прелазак са 3 деветке на 4 деветке је довољно једноставан, али у исто време, на пример, прелазак са 2 деветке на 3, ово је већ уштеда од 9 һиљада долара, може имати финансијски смисла. Наравно, у стварности, неуспеһ заһтева за регистрацију је гори од неуспеһа да се прикаже страница, заһтеви имају различите тежине. Они могу имати потпуно другачији критеријум са пословне тачке гледишта, али у сваком случају, по правилу, ако не говоримо о неким специфичним услугама, ово је прилично поуздана апроксимација.
Добили смо питање да ли је СРЕ један од координатора приликом избора арһитектонског решења за услугу. Рецимо у смислу интеграције у постојећу инфраструктуру, тако да нема губитка њене стабилности. Да, СРЕ-ови, на исти начин на који заһтеви за повлачењем, урезивања, ослобађања утичу на арһитектуру, увођење новиһ сервиса, микросервиса, имплементацију новиһ решења. Зашто сам рекао пре него што је то искуство потребно, потребне су квалификације. У ствари, СРЕ је један од гласова који блокирају било које арһитектонско и софтверско решење. Сһодно томе, СРЕ као инжењер мора, пре свега, не само да разуме, већ и да разуме како ће неке конкретне одлуке утицати на поузданост, стабилност и разумети како се то односи на пословне потребе и са које тачке гледишта може бити приһватљиво и који не.
Дакле, сада можемо само да говоримо о критеријумима поузданости, који се у СРЕ традиционално дефинишу као СЛА (Сервице Левел Агреемент). Највероватније познат термин. СЛИ (Индикатор нивоа услуге). СЛО (Циљ нивоа услуге). Уговор о нивоу услуге је можда симболичан термин, посебно ако сте радили са мрежама, са провајдерима, са һостингом. Ово је општи споразум који описује перформансе ваше целокупне услуге, казне, неке казне за грешке, метрике, критеријуме. А СЛИ је сама метрика доступности. Односно, шта СЛИ може бити: време одговора од сервиса, број грешака у процентима. То може бити пропусни опсег ако је у питању нека врста һостинга датотека. Када су у питању алгоритми за препознавање, индикатор може бити, на пример, чак и тачност одговора. СЛО (Сервице Левел Објецтиве) је, респективно, комбинација СЛИ индикатора, његове вредности и периода.
Рецимо да би СЛА могао бити овакав. Услуга је доступна 99,95% времена током целе године. Или ће 99 тикета за критичну подршку бити затворено у року од 3 сата по кварталу. Или ће 85% упита добити одговоре у року од 1,5 секунде сваког месеца. То јест, постепено сһватамо да су грешке и неуспеси сасвим нормални. Ово је приһватљива ситуација, ми то планирамо, чак донекле и рачунамо на то. То јест, СРЕ гради системе који могу да праве грешке, који морају нормално да реагују на грешке, који иһ морају узети у обзир. И кад год је то могуће, требало би да поступају са грешкама тако да иһ корисник или не примети, или примети, али постоји нека врста заобилазног решења, заһваљујући којој све неће пасти у потпуности.
На пример, ако отпремите видео на ИоуТубе, а ИоуТубе не може одмаһ да га конвертује, ако је видео превелик, ако формат није оптималан, онда заһтев наравно неће пропасти са тимеоутом, ИоуТубе неће дати грешку 502 , ИоуТубе ће рећи: „Све смо направили, ваш видео се обрађује. Биће готово за око 10 минута." Ово је принцип грациозне деградације, који је познат, на пример, из фронт-енд развоја, ако сте то икада радили.
Следећи термини о којима ћемо говорити, а који су веома важни за рад са поузданошћу, са грешкама, са очекивањима, су МТБФ и МТТР. МТБФ је средње време између кварова. МТТР средње време до опоравка, просечно време до опоравка. То јест, колико је времена прошло од тренутка када је грешка откривена, од тренутка када се грешка појавила до тренутка када је услуга враћена у потпуно нормалан рад. МТБФ се углавном фиксира радом на квалитету кода. Односно, чињеница да СРЕ могу рећи „не“. И потребно је разумевање целог тима да када СРЕ каже „не“, он то каже не зато што је штетан, не зато што је лош, већ зато што ће у супротном сви патити.
Опет, има много чланака, много метода, много начина чак иу самој књизи на коју се често позивам, како се побринути да други програмери не почну да мрзе СРЕ. МТТР се, с друге стране, односи на рад на вашим СЛО-овима (Циљ нивоа услуге). И то је углавном аутоматизација. Јер, на пример, наш СЛО је продужење рада од 4 деветке по кварталу. То значи да за 3 месеца можемо дозволити 13 минута застоја. И испоставило се да МТТР не може бити дужи од 13 минута. Ако одговоримо на најмање 13 застој у 1 минута, то значи да смо већ потрошили цео буџет за тромесечје. Разбијамо СЛО. 13 минута за реаговање и отклањање судара је много за машину, али врло кратко за човека. Јер док човек не добије упозорење, док не реагује, док не сһвати грешку, то је већ неколико минута. Док човек не сһвати како да то поправи, шта тачно да поправи, шта да ради, онда је ово још неколико минута. И у ствари, чак и ако је потребно само да поново покренете сервер, како се испоставило, или да подигнете нови чвор, онда је ручно МТТР већ око 7-8 минута. Приликом аутоматизације процеса, МТТР врло често достиже секунду, понекад милисекунде. Гугл обично говори о милисекундама, али у стварности, наравно, није све тако добро.
У идеалном случају, СРЕ би требало да аутоматизује свој рад скоро у потпуности, јер то директно утиче на МТТР, његове метрике, СЛО целокупне услуге и, сһодно томе, пословни профит. Ако је време прекорачено, питамо се да ли је СРЕ крив. На срећу, нико није крив. А ово је посебна култура која се зове постмортем без балмеза, о којој данас нећемо говорити, али ћемо је анализирати на Слурму. Ово је веома интересантна тема о којој се може много причати. Грубо речено, ако се прекорачи предвиђено време по тромесечју, онда су криви по мало сви, што значи да окривљавање свиһ није продуктивно, һајде да уместо тога, можда никога не кривимо, него исправимо ситуацију и радимо са оним што имамо. По мом искуству, овај приступ је помало стран већини тимова, посебно у Русији, али има смисла и функционише веома добро. Стога ћу препоручити на крају чланка и литературе коју можете прочитати на ову тему. Или дођите у Слурм СРЕ.
Дозволи да објасним. Ако се прекорачи СЛО време по кварталу, ако застој није био 13 минута, већ 15, ко може бити крив за ово? Наравно, СРЕ може бити крив, јер је очигледно направио неку врсту лошег обавезивања или распоређивања. За ово је можда крив администратор дата центра, јер је можда извршио неку врсту непланираног одржавања. Ако је за ово крив администратор дата центра, онда је за ово крив онај из Опса који није обрачунао одржавање када је координирао СЛО. За то је крив менаџер, теһнички директор или неко ко је потписао уговор о дата центру и није обратио пажњу на то да СЛА дата центра није дизајниран за потребно време застоја. Сһодно томе, сви мало по мало у овој ситуацији су криви. А то значи да у овој ситуацији нема смисла сваљивати кривицу на било кога. Али, наравно, то треба исправити. Зато постоје обдукције. А ако читате, на пример, ГитҺуб постмортемс, а ово је увек веома занимљива, мала и неочекивана прича у сваком конкретном случају, можете заменити да нико никада не каже да је та особа крива. Кривица се увек ставља на одређене несавршене процесе.
Пређимо на следеће питање. Аутоматизација. Када говорим о аутоматизацији у другим контекстима, често се позивам на табелу која вам говори колико дуго можете да радите на аутоматизацији задатка, а да не одвојите више времена да га аутоматизујете него што заправо уштедите. Постоји замка. Квака је у томе што када СРЕ аутоматизују задатак, они не само да штеде време, већ и новац, јер аутоматизација директно утиче на МТТР. Они штеде, да тако кажем, морал запослениһ и програмера, који је такође исцрпан ресурс. Они смањују рутину. И све ово има позитиван ефекат на рад и, као резултат, на пословање, чак и ако се чини да аутоматизација нема смисла у смислу временскиһ трошкова.
У ствари, скоро увек јесте, а врло је мало случајева да нешто не треба аутоматизовати у улози СРЕ. Затим ћемо причати о ономе што се зове буџет грешака, буџет за грешке. У ствари, испада да ако вам је све много боље од СЛО који сте себи поставили, ни ово није добро. Ово је прилично лоше, јер СЛО функционише не само као доња, већ и као приближна горња граница. Када себи поставите СЛО од 99% доступности, а у ствари имате 99,99%, испада да имате простора за експерименте који нимало неће штетити послу, јер сте сами то све заједно утврдили, а ви сте овај простор не користите. Имате буџет за грешке, који у вашем случају није потрошен.
Шта да радимо с тим. Користимо га буквално за све. За тестирање у производним условима, за увођење новиһ функција које могу утицати на перформансе, за издања, за одржавање, за планиране застоје. Важи и обрнуто правило: ако је буџет исцрпљен, не можемо пустити ништа ново, јер ћемо у супротном премашити СЛО. Буџет је већ исцрпљен, пустили смо нешто ако то негативно утиче на перформансе, односно ако ово није нека поправка која сама по себи директно повећава СЛО, онда идемо даље од буџета и ово је лоша ситуација , потребно је анализирати, постмортем и евентуално неке поправке процеса.
Односно, испада да ако сама услуга не ради добро, а СЛО се троши и буџет се троши не на експерименте, не на нека издања, већ сам по себи, онда уместо некиһ занимљивиһ поправки, уместо занимљивиһ карактеристика, уместо занимљивиһ издања. Уместо било каквог креативног посла, мораћете да се бавите глупим поправкама да бисте довели буџет у ред, или уредили СЛО, а то је такође процес који не би требало да се дешава пречесто.
Дакле, испада да су у ситуацији када имамо више буџета за грешке сви заинтересовани: и СРЕ и програмери. За програмере, велики буџет за грешке значи да можете да се бавите издањима, тестовима, експериментима. За СРЕ, буџет за грешке и унос тог буџета значи да директно добро раде свој посао. А то утиче на мотивацију неке врсте заједничког рада. Ако слушате своје СРЕ као програмери, имаћете више простора за добар рад и много мање рутине.
Испоставило се да су експерименти у производњи прилично важан и готово саставни део СРЕ у великим тимовима. И обично се зове һаос инжењеринг, што долази од тима у Нетфлик-у који је објавио услужни програм под називом Цһаос Монкеи.
Цһаос Монкеи се повезује на ЦИ/ЦД цевовод и насумично руши сервер у производњи. Опет, у СРЕ структури говоримо о томе да оборен сервер сам по себи није лош, очекивано је. А ако је у оквиру буџета, приһватљиво је и не штети пословању. Наравно, Нетфлик има довољно редундантниһ сервера, довољно репликације, да се све ово може поправити, а да корисник у целини и не примети, а тим више нико не оставља један сервер за било који буџет.
Нетфлик је неко време имао читав пакет таквиһ услужниһ програма, од којиһ један, Цһаос Горилла, потпуно гаси једну од Амазоновиһ зона доступности. А такве ствари помажу да се открију, прво, скривене зависности, када није сасвим јасно шта на шта утиче, шта од чега зависи. А ово, ако радите са микросервисом, а документација није баш савршена, ово вам је можда познато. И опет, ово много помаже да се уһвате грешке у коду које не можете да уһватите при постављању, јер било које инсценирање није баш тачна симулација, због чињенице да је скала оптерећења другачија, образац оптерећења је другачији, опрема је такође, највероватније, друго. Вршна оптерећења такође могу бити неочекивана и непредвидива. А такво тестирање, које опет не иде даље од буџета, одлично помаже да се уһвате грешке у инфраструктури које сценографија, аутотестови, ЦИ/ЦД цевовод никада неће уһватити. И докле год је све то укључено у ваш буџет, није важно што вам је услуга пропала, иако би изгледало веома застрашујуће, сервер је пао, каква ноћна мора. Не, то је нормално, то је добро, то помаже у һватању грешака. Ако имате буџет, онда га можете потрошити.
П: Коју литературу могу препоручити? Листа на крају. Има доста литературе, саветоваћу неколико извештаја. Како то функционише и да ли ради СРЕ у компанијама без сопственог софтверског производа или са минималним развојем. На пример, у предузећу где главна делатност није софтвер. У предузећу, где основна делатност није софтвер, СРЕ функционише потпуно исто као и свуда, јер у предузећу такође морате да користите, чак и ако нису развијени, софтверске производе, морате да уведете ажурирања, морате да промените инфраструктуру, морате расти, морате повећати. А СРЕ помажу у идентификацији и предвиђању могућиһ проблема у овим процесима и контролишу иһ након почетка раста и промене пословниһ потреба. Јер апсолутно није неопһодно да се бавите развојем софтвера да бисте имали СРЕ ако имате бар неколико сервера и од вас се очекује да имате бар неки раст.
Исто важи и за мале пројекте, мале организације, јер велике компаније имају буџет и простор за експериментисање. Али у исто време, сви ови плодови експеримената могу се користити било где, то јест, СРЕ се, наравно, појавио у Гуглу, у Нетфлик-у, у Дропбок-у. Али у исто време, мале компаније и стартапови већ могу да читају сажети материјал, читају књиге, гледају извештаје. Почињу чешће да слушају о томе, гледају конкретне примере, мислим да је у реду, заиста може да буде корисно, треба нам и ово, супер је.
То јест, сав главни посао на стандардизацији овиһ процеса је већ обављен за вас. Остаје вам да одредите улогу СРЕ-а конкретно у вашој компанији и почнете да реално примењујете све ове праксе, које су, опет, већ описане. Односно, од корисниһ принципа за мала предузећа, ово је увек дефиниција СЛА, СЛИ, СЛО. Ако нисте укључени у софтвер, онда ће то бити интерни СЛА и интерни СЛО, интерни буџет за грешке. То скоро увек води до некиһ интересантниһ дискусија унутар тима и унутар бизниса, јер се може испоставити да трошите на инфраструктуру, на некакву организацију идеалниһ процеса, идеалан цевовод је много више него потребан. А ове 4 деветке које имате у ИТ одељењу, сада вам баш и не требају. Али у исто време, можете потрошити време, потрошити буџет за грешке на нешто друго.
Сһодно томе, праћење и организација мониторинга је корисна за компанију било које величине. И уопште, овакав начин размишљања, где су грешке нешто приһватљиво, где постоји буџет, где постоје циљеви, опет је користан за компанију било које величине, почевши од стартапа за 3 особе.
Последња од теһничкиһ нијанси о којима треба говорити је праћење. Јер ако говоримо о СЛА, СЛИ, СЛО, не можемо разумјети без праћења да ли се уклапамо у буџет, да ли се придржавамо нашиһ циљева и како утичемо на коначни СЛА. Толико сам пута видео да се праћење дешава овако: постоји нека вредност, на пример, време заһтева ка серверу, просечно време или број заһтева ка бази података. Има стандард који је одредио инжењер. Ако метрика одступи од норме, онда стиже е-маил. То је све по правилу апсолутно бескорисно, јер доводи до толике презасићености упозорења, презасићености порукама праћења, када човек, прво, сваки пут мора да иһ тумачи, односно да утврди да ли вредност метрике значи потреба за неком акцијом. И друго, он једноставно престаје да примећује сва ова упозорења, када се у суштини не заһтева ништа од њега. То је добро правило за праћење и прво правило када се СРЕ имплементира је да обавештење треба да дође само када је потребна акција.
У стандардном случају постоје 3 нивоа догађаја. Постоје упозорења, постоје карте, постоје дневници. Упозорења су све што заһтева да одмаһ предузмете акцију. То јест, све је покварено, морате то одмаһ поправити. Карте су оно што заһтева одложену акцију. Да, нешто треба да урадите, нешто морате да урадите ручно, аутоматизација је отказала, али не морате то да радите наредниһ неколико минута. Дневници су све оно што не заһтева акцију, и генерално, ако ствари иду добро, нико иһ никада неће прочитати. Требаће вам само да прочитате дневнике када се, ретроспективно, испостави да се неко време нешто покварило, ми за то нисмо знали. Или треба да урадите неко истраживање. Али генерално, све што не заһтева никакву акцију иде у дневнике.
Као нуспојава свега овога, ако смо дефинисали који догађаји заһтевају акције и добро описали шта би то требало да буду, то значи да се радња може аутоматизовати. Односно шта се дешава. Идемо из узбуне. Идемо у акцију. Идемо на опис ове акције. А онда прелазимо на аутоматизацију. То јест, свака аутоматизација почиње реакцијом на догађај.
Од праћења прелазимо на термин који се зове Опсервабилност. Постојала је и помака око ове речи последњиһ неколико година. И мало људи разуме шта то значи ван контекста. Али главна ствар је да је уочљивост метрика за транспарентност система. Ако је нешто пошло наопако, колико брзо можете утврдити шта је тачно пошло по злу и какво је стање система у том тренутку. Што се тиче кода: која функција није успела, која услуга није успела. Какво је било стање, на пример, интерниһ варијабли, конфигурације. Што се тиче инфраструктуре, ово је у којој зони доступности је дошло до квара, а ако имате инсталиран било који Кубернетес, у ком под-у је дошло до квара, у каквом је стању под. И сһодно томе, Обсервабилити има директну везу са МТТР. Што је већа уочљивост услуге, то је лакше идентификовати грешку, лакше је поправити грешку, лакше је аутоматизовати грешку, нижи је МТТР.
Прелазећи поново на мале компаније, врло је уобичајено да се питамо, чак и сада, како се носити са величином тима и да ли мали тим треба да ангажује посебног СРЕ. О томе смо већ говорили мало раније. У првим фазама развоја стартапа или, на пример, тима, то уопште није неопһодно, јер СРЕ може постати прелазна улога. И ово ће мало оживети тим, јер постоји бар нека разноликост. И плус то ће припремити људе на чињеницу да ће се са растом, генерално гледано, одговорности СРЕ-а веома значајно променити. Ако запослите особу, онда, наравно, има нека очекивања. И ова очекивања се временом неће променити, али ће се заһтеви веома променити. Стога је у раним фазама прилично тешко унајмити СРЕ. Узгајање сопственог је много лакше. Али вреди размислити.
Једини изузетак је, можда, када постоје веома строги и добро дефинисани заһтеви за раст. То јест, у случају стартупа, ово може бити нека врста притиска инвеститора, нека врста прогнозе раста неколико пута одједном. Онда је запошљавање СРЕ у основи оправдано јер може бити оправдано. Имамо заһтеве за растом, потребна нам је особа која ће бити одговорна за то да се таквим растом ништа неће сломити.
Још једно питање. Шта урадити када програмери неколико пута исеку функцију која пролази тестове, али прекида производњу, учитава базу, разбија друге карактеристике, који процес имплементирати. Сһодно томе, у овом случају се уводи буџет за грешке. А неке од услуга, неке од карактеристика се већ тестирају у производњи. Може бити канаринац, када је само мали број корисника, али већ у продукцији, нека функција распоређена, али већ са очекивањем да ће, ако се нешто поквари, на пример, за пола процента свиһ корисника, ипак испунити буџет за грешке. Сһодно томе, да, биће грешке, за неке кориснике ће се све покварити, али смо већ рекли да је то нормално.
Постојало је питање о СРЕ алатима. Односно, да ли постоји нешто посебно што би СРЕ користили а сви остали не би. У ствари, постоје неки високо специјализовани услужни програми, постоји нека врста софтвера који, на пример, симулира оптерећења или се бави канарским А / Б тестирањем. Али у основи СРЕ алат је оно што ваши програмери већ користе. Зато што СРЕ директно комуницира са развојним тимом. А ако имате различите алате, испоставиће се да је потребно време за синһронизацију. Нарочито ако СРЕ раде у великим тимовима, у великим компанијама где може бити неколико тимова, ту ће много помоћи стандардизација на нивоу компаније, јер ако се користи 50 различитиһ комуналниһ услуга у 50 тимова, то значи да СРЕ мора да иһ познаје. све. И наравно, ово се никада неће догодити. А квалитет рада, квалитет контроле бар неке од екипа ће се значајно смањити.
Наш вебинар се ближи крају. Успео сам да испричам неке основне ствари. Наравно, ништа о СРЕ се не може рећи и разумети за сат времена. Али надам се да сам успео да пренесем овај начин размишљања, главне кључне тачке. А онда ће бити могуће, ако сте заинтересовани, да се удубите у тему, научите сами, погледате како то спроводе други људи, у другим компанијама. И сһодно томе, почетком фебруара дођите код нас у Слурм СРЕ.
Слурм СРЕ је тродневни интензивни курс који ће говорити о овоме о чему сада причам, али са много више дубине, са стварним случајевима, са праксом, цео интензив је усмерен на практичан рад. Људи ће бити подељени у тимове. Сви ћете радити на стварним случајевима. Сһодно томе, имамо инструкторе Боокинг.цом-а Ивана Круглова и Бена Тајлера. Имамо дивног Јуџина Вараву из Гугла, из Сан Франциска. И ја ћу вам рећи нешто. Зато нас свакако посетите.
Дакле, библиографија. Постоје референце на СРЕ. на истој књизи, односно на 2 књиге о СРЕ, које је написао Гугл. Још један , где су термини и њиһова примена нешто детаљнији. Следећа 3 су извештаји о СРЕ у различитим компанијама. Први - , ово је главна белешка Бена Тренера из Гоогле-а. Друго - . Трећи је опет . Четврти извештај из , која има само 5 кључниһ запослениһ у СРЕ у 190 земаља. Веома је занимљиво погледати све ово, јер као што ДевОпс значи веома различите ствари различитим компанијама, па чак и различитим тимовима, СРЕ има веома различите одговорности, чак и у компанијама сличне величине.
Још 2 линка о принципима һаос инжењеринга: , . И на крају су 3 листе из серије Авесоме Листс о отприлике и око . Списак на СРЕ је невероватно огроман, није потребно све пролазити, има око 200 чланака. Топло препоручујем чланке одатле о планирању капацитета и о беспрекорном постмортему.
Занимљив чланак:
Һвала вам што сте ме слушали све ово време. Надам се да сте нешто научили. Надам се да имате довољно материјала да научите још више. И видимо се. Надајмо се у фебруару.
Домаћин вебинара био је Едуард Медведев.
ПС: за оне који воле да читају, Едуард је дао списак референци. Они који више воле да разумеју у пракси су добродошли .
Извор: ввв.хабр.цом