Тестирање на производу: Цанари Деплоимент

Канаринац је мала птица која стално пева. Ове птице су осетљиве на метан и угљен-моноксид. Чак и од мале концентрације вишка гасова у ваздуху, они губе свест или умиру. Копачи злата и рудари однели су птице у рудник: док канаринци певају, можете да радите, ако ћутите – у руднику има гаса и време је за одлазак. Рудари су жртвовали малу птицу да би изашли живи из рудника.

Слична пракса се нашла и у ИТ. На пример, у стандардном задатку постављања нове верзије услуге или апликације у производњу са тестирањем пре тога. Тестно окружење може бити прескупо, аутоматизовани тестови не покривају све што желите, а не тестирање и жртвовање квалитета је ризично. Овде је од користи приступ Цанари Деплоимент, где је део стварног производног саобраћаја усмерен ка новој верзији. Приступ помаже сигурно проверите нову верзију за производњу, жртвујући мало за велики циљ. Више детаља о томе како приступ функционише, шта је корисно и како га применити, ће рећи Андреј Маркелов (Андреи_В_Маркелов), на примеру имплементације у компанији Инфобип.

Андреј Маркелов - Водећи софтверски инжењер у Инфобипу, већ 11 година развија Јава апликације у области финансија и телекомуникација. Развија производе отвореног кода, активно учествује у Атлассиан заједници и пише додатке за Атлассиан производе. Јеванђелиста Прометеја, Докера и Редиса.

О Инфобипу

То је глобална телекомуникациона платформа која омогућава банкама, продавцима, онлајн продавницама и транспортним компанијама да шаљу поруке својим клијентима путем СМС-а, пусх порука, писама и гласовних порука. У таквом послу битна је стабилност и поузданост како би купци добили поруке на време.

Инфобип ИТ инфраструктура у бројкама:

• 15 центара података широм света;
• 500 јединствених сервиса у функцији;
• 2500 инстанци услуга, што је много више од команди;
• 4,5 ТБ месечног саобраћаја;
• 4,5 милијарди телефонских бројева;

Посао расте, а са њим и број издања. Трошимо на 60 издања дневнојер купци желе више функција и снаге. Али ово је тешко - има много услуга, али мало команди. Морате брзо да напишете код који би требало да ради у производњи без грешака.

Издања

Типично издање иде овако. На пример, постоје услуге А, Б, Ц, Д и Е, а сваку од њих развија посебан тим.

У неком тренутку, тим сервиса А одлучује да примени нову верзију, али тимови сервиса Б, Ц, Д и Е не знају за то. Постоје две опције како ће сервисни тим А деловати.

Држаће постепено ослобађање: прво замените једну верзију, а затим другу.

Али постоји и друга опција: команда наћи додатне капацитете и машине, примените нову верзију, а затим промените рутер и верзија ће почети да ради за производњу.

У сваком случају, скоро увек постоје проблеми након постављања, чак и ако је верзија тестирана. Можете тестирати ручно, можете то урадити аутоматски, не можете тестирати - проблеми ће се појавити у сваком случају. Најлакши и најисправнији начин да их решите је да се вратите на радну верзију. Тек тада можете да се носите са штетом, са узроцима и исправите их.

Па шта хоћемо?

Не требају нам проблеми. Ако их купци пронађу брже од нас, то ће наштетити њиховој репутацији. Стога морамо проналазе проблеме брже од купаца. Радећи проактивно, минимизирамо штету.

Истовремено, желимо убрзати распоређивањетако да се то дешава брзо, лако, природно и без притиска екипе. Инжењери, ДевОпс инжењери и програмери морају бити заштићени - објављивање нове верзије је стресно. Екипа није потрошна, трудимо се рационално коришћење људских ресурса.

Проблеми са применом

Саобраћај клијената је непредвидив. Немогуће је предвидети када ће саобраћај клијената бити најнижи. Не знамо где и када ће клијенти започети своје кампање - можда вечерас у Индији, сутра у Хонг Конгу. С обзиром на велику временску разлику, постављање чак и у 2 сата ујутро не гарантује да то неће утицати на клијенте.

Проблеми са провајдерима. Мессенгери и провајдери су наши партнери. Понекад имају падове који узрокују грешке током постављања нових верзија.

Дистрибуирани тимови. Тимови који развијају клијентску страну и позадину налазе се у различитим временским зонама. Због тога се често не могу договорити међу собом.

Дата центри се не могу поновити на сцени. Постоји 200 рекова у једном дата центру - ово не можете ни приближно поновити у сандбоку.

Застојинеприхватљиво! Имамо буџет за грешке када радимо 99,99% времена, на пример, а преостали проценат је „маргина грешке“. Постизање 100% поузданости је немогуће, али је важно стално пратити падове и застоје.

Класична решења

Пишите код без грешака. Када сам био млад програмер, менаџери су ми се обраћали са захтевом да објавим без грешака, али то није увек могуће.

Напишите тестове. Тестови функционишу, али понекад не на начин на који посао жели. Зарађивање новца није посао тестова.

Тест на сцени. За 3,5 године мог рада у Инфобипу никада нисам видео да се стање на сцени макар делимично поклапа са продукцијом.

Чак смо покушали да развијемо ову идеју: прво смо имали сцену, затим претпродукцију, а затим претпродукцијску претпродукцију. Али ни ово није помогло - нису се ни поклапали на власти. Са бином можемо гарантовати основну функционалност, али не знамо како ће функционисати под оптерећењем.

Издање је направио онај који га је развио. Ово је добра пракса: чак и ако неко промени име коментара, одмах га дода у продукцију. Ово помаже да се развије одговорност и да се не забораве направљене промене.

Постоје и додатне компликације. Стресно је за програмера да проведе много времена да ручно све проверава.

Агреед Релеасес. Ову опцију обично нуди менаџмент: „Хајде да се договоримо да ћете сваки дан тестирати и додавати нове верзије.“ Не ради: увек постоји команда која чека све остале, или обрнуто.

Тестови дима

Још један начин да решимо проблеме са применом. Размотрите како функционишу тестови дима у претходном примеру, када тим А жели да примени нову верзију.

Прво, тим поставља једну инстанцу у производњу. Поруке инстанци из моцкс симулира стварни саобраћајда одговара нормалном дневном саобраћају. Ако је све у реду, тим пребацује нову верзију на кориснички саобраћај.

Друга опција је распоређивање са додатним гвожђем. Тим га тестира за производњу, затим прелази и све ради.

Недостаци тестова дима:

• Тестовима се не може веровати. Где добити исти промет као за производњу? Можете користити јуче или пре недељу дана, али се не поклапа увек са тренутним.
• Тешко за одржавање. Мораћете да одржавате пробне налоге, да их стално ресетујете пре сваке примене, када се активни записи шаљу у спремиште. Ово је теже него писати тест у сопственом сандбоку.

Једини бонус овде је перформансе се могу проверити.

Цанари релеасес

Због недостатака тестова дима почели смо да користимо канаринца.

Пракса слична оној како су рудари користили канаринце да укажу на ниво гасова нашла се у ИТ-у. Дозволили смо нешто стварног производног саобраћаја до нове верзиједок покушавате да испуните Уговор о нивоу услуге (СЛА). СЛА је наше „право на грешку“, које можемо користити једном годишње (или у неком другом периоду). Ако све буде у реду, додаћемо још саобраћаја. Ако не, вратићемо претходне верзије.

Имплементација и нијансе

Како смо имплементирали канаринце? На пример, група клијената шаље поруке преко наше услуге.

Постављање иде овако: уклањамо један чвор испод балансера (1), мењамо верзију (2) и пуштамо део саобраћаја одвојено (3).

Генерално, сви у групи ће бити срећни, чак и ако је један корисник несрећан. Ако је све у реду, мењамо све верзије.

Шематски ћу показати како изгледа микросервис у већини случајева.

Постоји Сервице Дисцовери и још две услуге: С1Н1 и С2. Прва услуга (С1Н1) обавештава Сервице Дисцовери када се покрене, а Сервице Дисцовери га памти. Друга услуга са два чвора (С2Н1 и С2Н2) такође обавештава Сервице Дисцовери када се покрене.

Други сервис за први ради као сервер. Први тражи од Сервице Дисцовери-а информације о својим серверима, а када их добије, тражи их и проверава („провера здравља“). Када провери, послаће им поруке.

Када неко жели да примени нову верзију другог сервиса, он каже Сервице Дисцовери-у да ће други чвор бити канарински чвор: мање саобраћаја ће бити послато на њега, јер ће се распоређивање одвијати сада. Уклањамо канаринац испод балансера и први сервис не шаље саобраћај на њега.

Ми мењамо верзију и Сервице Дисцовери зна да је други чвор сада канаринац - можете му дати мање оптерећење (5%). Ако је све у реду, мењамо верзију, враћамо оптерећења и радимо даље.

Да бисмо све ово имплементирали, потребно нам је:

• балансирање;
• надгледањејер је важно знати шта сваки корисник очекује и како наше услуге функционишу до детаља;
• анализа верзиједа разуме колико ће нова верзија радити у производњи;
• аутоматизација - пишемо секвенцу распоређивања (цевовод за распоређивање).

Балансирање

Ово је прва ствар о којој треба да размишљамо. Постоје две стратегије балансирања.

Најједноставнија опција када један чвор је увек канаринац. Овај чвор увек прима мање саобраћаја и од њега почињемо примену. У случају проблема, упоредићемо његов рад пре распоређивања и током ње. На пример, ако има 2 пута више грешака, онда се штета повећала 2 пута.

Цанари чвор се поставља током процеса имплементације. Када се имплементација заврши и из њега уклонимо статус канаринског чвора, равнотежа саобраћаја ће бити враћена. Са мање аутомобила, добићемо праведну расподелу.

Праћење

Камен темељац канаринца. Морамо тачно разумети зашто то радимо и које метрике желимо да прикупимо.

Примери показатеља које прикупљамо из наших услуга.

• Број грешака, који су уписани у дневнике. Ово је јасан показатељ да све функционише како треба. Генерално, ово је добар показатељ.
• Време извршења упита (латентност). Сви прате ову метрику јер сви желе да раде брзо.
• Величина реда (пропусност).
• Број успешних одговора у секунди.
• Време извршења 95% свих захтева.
• Пословни показатељи: колико новца предузеће зарађује за дато време или одлив корисника. Ови показатељи за нашу нову верзију могу бити важнији од оних које су додали инжењери.

Примери метрике у најпопуларнијим системима за праћење.

Цоунтер. Ово је нека све већа вредност, на пример, број грешака. Ову метрику је лако интерполирати и проучавати графикон: јуче су биле 2 грешке, а данас 500, што значи да је нешто пошло наопако.

Број грешака у минути или секунди је најважнији показатељ који се може израчунати помоћу бројача. Ови подаци дају јасну слику о томе како систем функционише на даљину. Размотримо пример графикона броја грешака у секунди за две верзије производног система.

У првој верзији било је мало грешака, можда ревизија није успела. У другој верзији, све је много горе. Можемо са сигурношћу рећи да има проблема, па би требало да вратимо ову верзију.

Колосек. Метрике су сличне Цоунтер-у, али бележимо вредности које се могу повећати или смањити. На пример, време извршења упита или величина реда.

Графикон приказује пример кашњења. Графикон показује да су верзије сличне, можете радити са њима. Али ако пажљиво погледате, можете видети како се вредност мења. Ако се време извршавања упита повећа када се додају корисници, онда је одмах јасно да постоје проблеми - раније није био случај.

Резиме. Један од најважнијих индикатора за пословање су перцентили. метрика то показује 95% случајева наш систем функционише онако како ми желимо. Можемо прихватити ако негде има проблема, јер разумемо општи тренд, колико је све добро или лоше.

Алат

ЕЛК Стацк. Можете имплементирати канаринац користећи Еластицсеарцх - уписујемо му грешке када дође до догађаја. Уз најједноставнији АПИ позив, можете добити број грешака у било ком тренутку и упоредити их са прошлим сегментима: GET /applg/_cunt?q=level:errr.

Прометхеус. Добро се показао у Инфобипу. Омогућава вам да примените вишедимензионалне метрике јер се користе ознаке.

Можемо да користимо level, instance, service, комбинују их у један систем. Уз помоћ offset можете видети, на пример, вредност вредности од пре недељу дана са само једном командом GET /api/v1/query?query={query}Где {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Анализа верзија

Постоји неколико стратегија управљања верзијама.

Погледајте само метрику канаринских чворова. Једна од најједноставнијих опција: примените нову верзију и проучите само рад. Али ако инжењер у овом тренутку почне да проучава дневнике, стално нервозно учитавајући странице, онда се ово решење не разликује од осталих.

Канарски чвор се пореди са било којим другим чвором. Ово је поређење са другим инстанцама које раде са пуним прометом. На пример, ако су ствари горе са малим прометом, или не боље него у стварним случајевима, онда нешто није у реду.

Канарски чвор се пореди са самим собом у прошлости. Чворови додељени канаринцу могу се упоредити са историјским подацима. На пример, ако је све било у реду пре недељу дана, онда можемо да се фокусирамо на ове податке како бисмо разумели тренутну ситуацију.

Аутоматизација

Желимо да ослободимо инжењере од ручног поређења, тако да је важно применити аутоматизацију. Цјевовод за имплементацију обично изгледа овако:

• почињемо;
• уклоните чвор испод балансера;
• поставити канаринац;
• укључите балансер са ограниченом количином саобраћаја;
• упоредити.

У овој фази имплементирамо аутоматско поређење. Како то може да изгледа и зашто је боље од верификације након постављања, погледајмо пример из Џенкинса.

Ово је цевовод за Гроови.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Овде у петљи постављамо да ћемо упоређивати нови чвор сат времена. Ако канарски процес још није завршио процес, позивамо функцију. Она извештава да је све у реду или не: def isOk = compare(srv, canary, time, base, offset, metrics).

Ако је све добро - sleep DEFAULT SLEEP, на пример, на секунд, и наставите. Ако не, изађите — имплементација није успела.

Опис метрике. Хајде да видимо како би функција могла да изгледа compare на примеру ДСЛ-а.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Рецимо да упоређујемо број грешака и желимо да знамо број грешака у секунди за последњих 5 минута.

Имамо две вредности: базни и канарски чворови. Вредност чвора канаринца је тренутна. Основни - baseValue је вредност било ког другог не-канаринског чвора. Међусобне вредности упоређујемо према формули, коју постављамо на основу нашег искуства и запажања. Ако вредност canaryValue лоше, онда распоређивање није успело и ми се враћамо назад.

Зашто је све ово потребно?

Особа не може да провери стотине и хиљаде метрикапосебно да то уради брзо. Аутоматско поређење помаже да се провери све метрике и брзо вас обавештава о проблемима. Тајминг упозорења је критичан: ако се нешто догодило у последње 2 секунде, штета неће бити тако велика као да се догодила пре 15 минута. Све док неко не примети проблем, пише подршци и не подржи нас да се вратимо, можете изгубити клијенте.

Ако је процес прошао и све је у реду, аутоматски ћемо распоредити све остале чворове. За то време, инжењери не раде ништа. Тек када лансирају канаринца, одлучују које ће метрике узети, колико дуго да раде поређење, коју стратегију да користе.

Ако постоје проблеми, аутоматски враћамо канарин чвор, радимо на претходним верзијама и исправљамо грешке које смо пронашли. По метрикама их је лако пронаћи и видети штету од нове верзије.

Prepreke

Наравно, ово није лако спровести. Пре свега, потребно је општи систем праћења. Инжењери имају своје метрике, подршка и аналитичари имају различите метрике, а предузећа имају треће. Заједнички систем је заједнички језик којим говоре пословање и развој.

Потребно је тестирати у пракси метричка стабилност. Провера вам помаже да разумете који је минимални скуп метрика потребних да би се обезбедио квалитет.

Како се то може постићи? Не користите Цанари-сервице у време постављања. Додамо одређену услугу на стару верзију, која у било ком тренутку може заузети било који наменски чвор, смањити саобраћај без постављања. Након што упоредимо: проучавамо грешке и тражимо ту линију када постигнемо квалитет.

Какве смо користи имали од канаринца?

Минимизирао проценат оштећења од грешака. Већина грешака у примени настаје због недоследности у неким подацима или приоритету. Таквих грешака је много мање, јер проблем можемо да решимо у првим секундама.

Оптимизован тимски рад. Почетници имају „право на грешку“: могу да се укључе у производњу без страха да ће погрешити, постоји додатна иницијатива, подстицај за рад. Ако нешто покваре, онда то неће бити критично, а онај ко погреши неће добити отказ.

Аутоматско постављање. Ово више није ручни процес, као раније, већ прави аутоматизован. Али то траје дуже.

Наглашене важне метрике. Цела компанија, почевши од бизниса и инжењера, разуме шта је заиста важно у нашем производу, које метрике, на пример, одлив и прилив корисника. Контролишемо процес: тестирамо метрике, уводимо нове, видимо како старе функционишу како бисмо изградили систем који ће продуктивније зарађивати.

Имамо много добрих пракси и система који нам помажу. Упркос томе, трудимо се да будемо професионални и добро радимо свој посао, без обзира да ли имамо систем који ће нам помоћи или не.

Инжењерски приступи и праксе - главни фокус ТецхЛеад Цонф. Ако сте постигли успех на путу ка техничкој изврсности и спремни сте да вам кажемо шта вам је у томе помогло, — пријавити се за извештај.

Планирамо да Тецх Леад Цонф 8. јуна. Разумемо да је сада тешко доносити одлуке о учешћу на конференцији. Али у исто време верујемо да карантин није разлог за прекид професионалне комуникације и развоја. Због тога ћемо, у сваком случају, наћи начин да разговарамо о задацима техничког вође и приступима њиховом решавању – ако буде потребно, изаћи ћемо на мрежу и тамо поставити умрежавање!

Извор: ввв.хабр.цом