🥇 Тестирање при производство: Распоредување на Канари

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

Слична практика се најде и во ИТ. На пример, во стандардната задача за распоредување на нова верзија на услуга или апликација за производство со тестирање пред тоа. Тестната средина може да биде премногу скапа, автоматизираните тестови не покриваат сè што би сакале, а не тестирањето и жртвувањето на квалитетот е ризично. Токму во такви случаи помага пристапот на Canary Deployment, кога малку реален производствен сообраќај се испраќа до новата верзија. Пристапот помага безбедно проверете ја новата верзија за производство, жртвувајќи малку за голема кауза. Ќе кажат повеќе детали за тоа како функционира пристапот, што е корисно и како да се имплементира Андреј Маркелов (Андреј_В_Маркелов), врз основа на примерот на имплементација во Infobip.

Андреј Маркелов — Водечкиот софтверски инженер во Infobip, веќе 11 години развива Java апликации во областа на финансиите и телекомуникациите. Развива производи со отворен код, активно учествува во Atlassian заедница и пишува додатоци за Atlassian производи. Прометеј, Докер и Редис евангелист.

За Infobip

Станува збор за глобална телекомуникациска платформа која им овозможува на банките, малопродажните, онлајн продавниците и транспортните компании да испраќаат пораки до своите клиенти користејќи SMS, push, писма и гласовни пораки. Во таков бизнис, стабилноста и доверливоста се важни за клиентите да добиваат пораки на време.

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

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

Бизнисот расте, а со тоа и бројот на изданија. Ние спроведуваме 60 изданија дневно, бидејќи клиентите сакаат повеќе функции и моќ. Но, ова е тешко - има многу услуги, но малку тимови. Мора брзо да напишете код кој треба да работи во производството без грешки.

Изданија

Типично издание оди вака. На пример, постојат услуги A, B, C, D и E, секој од нив е развиен од посебен тим.

Во одреден момент, сервисниот тим А одлучува да распореди нова верзија, но сервисните тимови B, C, D и E не знаат за тоа. Постојат две опции за тоа што ќе направи сервисниот тим А.

Ќе спроведе постепено ослободување: прво заменете ја едната верзија, а потоа втората.

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

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

Па што сакаме?

Не ни требаат проблеми. Ако клиентите ги најдат побрзо од нас, тоа ќе им наштети на нивниот углед. Затоа мораме најдете проблеми побрзо од клиентите. Работејќи проактивно, ја минимизираме штетата.

Во исто време сакаме забрза распоредувањетоза тоа да се случи брзо, лесно, природно и без тензија од страна на тимот. Инженерите, инженерите на DevOps и програмерите мора да бидат заштитени - објавувањето нова верзија е стресно. Тимот не е потрошен, ние се стремиме рационално користење на човечките ресурси.

Проблеми со распоредувањето

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

Проблеми со давателот. Гласниците и провајдерите се наши партнери. Понекогаш тие имаат дефекти што предизвикуваат грешки за време на распоредувањето на новите верзии.

Дистрибуирани тимови. Тимовите кои ја развиваат страната на клиентот и задниот дел се во различни временски зони. Поради ова, тие често не можат да се договорат меѓу себе.

Центрите за податоци не може да се повторат на сцената. Има 200 полици во еден центар за податоци - ова не можете ни приближно да го повторите во песок.

Застојинеприфатливо! Имаме прифатливо ниво на достапност (Error Budget), кога работиме 99,99% од времето, на пример, а останатиот процент е „право за грешка“. Невозможно е да се постигне 100% сигурност, но важно е постојано да се следи за несреќи и застој.

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

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

Напишете тестови. Тестовите функционираат, но понекогаш воопшто не како што сака бизнисот. Заработувањето пари не е работа на тестови.

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

Дури се обидовме да ја развиеме оваа идеја: прво имавме сцена, потоа претпродукција, а потоа претпродукција на претпродукција. Но, ниту ова не помогна - тие дури и не се совпаѓаа со моќ. Со сцената, можеме да гарантираме основна функционалност, но не знаеме како ќе работи под оптоварување.

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

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

Договорени изданија. Оваа опција обично ја нуди раководството: „Да се договориме дека ќе тестирате и додавате нови верзии секој ден“. Ова не функционира: секогаш постои тим кој ги чека сите други или обратно.

Тестови за чад

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

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

Втората опција е да се распореди со дополнително железо. Тимот го тестира за производство, потоа се префрла и сè работи.

Недостатоци на тестовите за чад:

На тестовите не може да им се верува. Каде можам да го добијам истиот сообраќај како за производство? Можете да користите вчера или пред една недела, но не секогаш се совпаѓа со сегашната.
Тешко за одржување. Ќе мора да одржувате тест сметки и постојано да ги ресетирате пред секое распоредување, кога активните записи се испраќаат во складиштето. Ова е потешко отколку да напишете тест во сопственото песок.

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

Канарските изданија

Поради недостатоците на тестовите за чад, почнавме да користиме канари.

Практика слична на тоа како рударите користеле канаринци за да го покажат нивото на гасови се најде во ИТ. Дозволуваме малку вистински производствен сообраќај кон новата верзија, додека се обидувате да го исполните Договорот за ниво на услуга (SLA). SLA е нашето „право да правиме грешки“ што можеме да го користиме еднаш годишно (или за некој друг временски период). Ако сè оди добро, ќе додадеме поголем сообраќај. Ако не, ќе ги вратиме претходните верзии.

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

Како го имплементиравме изданокот на канари? На пример, група клиенти испраќаат пораки преку нашата услуга.

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

Во принцип, сите во групата ќе бидат среќни, дури и ако еден корисник е несреќен. Ако сè е во ред, ги менуваме сите верзии.

Ќе ви покажам шематски како изгледа за микросервисите во повеќето случаи.

Постои Service Discovery и уште две услуги: S1N1 и S2. Првата услуга (S1N1) го известува Service Discovery кога ќе започне, а Service Discovery го запомнува. Втората услуга со два јазли (S2N1 и S2N2) исто така го известува Service Discovery кога ќе започне.

Втората услуга делува како сервер за првата. Првиот бара од Service Discovery информации за неговите сервери, а кога ќе ги добие, ги пребарува и проверува („здравствена проверка“). Кога ќе провери, ќе им праќа пораки.

Кога некој сака да распореди нова верзија на втората услуга, тие му кажуваат на Service Discovery дека вториот јазол ќе биде канарински јазол: помалку сообраќај ќе биде испратен до него, бидејќи распоредувањето сега ќе се случи. Го отстрануваме канаринскиот јазол од под балансерот и првата услуга не испраќа сообраќај до него.

Ја менуваме верзијата и Service Discovery знае дека вториот јазол сега е канари - можете да му дадете помалку оптоварување (5%). Ако сè е во ред, ја менуваме верзијата, ги враќаме оптоварувањата и продолжуваме понатаму.

За да го спроведеме сето ова, ни требаат:

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

Балансирање

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

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

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

Мониторинг

Камен-темелник на канаринските изданија. Мора да разбереме точно зошто го правиме ова и кои метрики сакаме да ги собереме.

Примери на метрика што ги собираме од нашите услуги.

Број на грешки, кои се запишани во дневниците. Ова е јасен показател дека сè работи како што треба. Генерално, ова е добра метрика.
Време на извршување на барањето (латентност). Сите ја следат оваа метрика бидејќи сите сакаат да работат брзо.
Големина на редот (пропусната моќ).
Број на успешни одговори во секунда.
Време на завршување за 95% од сите барања.
Деловни метрики: колку пари заработува бизнисот во одредено време или отчукување на корисниците. Овие метрики за нашата нова верзија можеби се поважни од оние што ги додаваат инженерите.

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

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

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

Имаше малку грешки во првата верзија, можеби ревизијата не функционираше. Во втората верзија, сè е многу полошо. Можеме со сигурност да кажеме дека има проблеми, па затоа треба да ја вратиме оваа верзија.

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

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

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

Алатки

ELK Стак. Можете да имплементирате канари со помош на Elasticsearch - ние снимаме грешки во него кога се случуваат настани. Со едноставен API повик можете да го добиете бројот на грешки во кој било момент во времето и да ги споредите со претходните периоди: 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 користејќи DSL како пример.

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 минути. Сè додека некој не забележи проблем, не пише за поддршка и не поддржи да го вратиме назад, може да изгубите клиенти.

Ако процесот помина и се е во ред, ќе ги распоредиме сите други јазли автоматски. За тоа време, инженерите не прават ништо. Само кога ќе го лансираат канаринецот, тие одлучуваат кои мерила да ги преземат, колку време да се направи споредба, каква стратегија да се користи.

Ако се појават проблеми, автоматски го враќаме канаринскиот јазол, работиме на претходните верзии и ги коригираме грешките што ги наоѓаме. Користејќи ги метриките, лесно е да ги најдете и да ја видите штетата од новата верзија.

Пречки

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

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

Како може да се постигне ова? Користете канаринска услуга не во моментот на распоредување. Додаваме одредена услуга на старата верзија која во секое време може да преземе кој било посветен јазол и да го намали сообраќајот без распоредување. Потоа споредуваме: ги проучуваме грешките и ја бараме таа линија кога ќе постигнеме квалитет.

Како добивме од изданија на канари

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

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

Автоматско распоредување. Ова повеќе не е рачен процес, како порано, туку вистински автоматизиран. Но, потребно е повеќе време.

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

Имаме многу кул практики и системи кои ни помагаат. И покрај тоа, ние се стремиме да бидеме професионални и добро да си ја вршиме работата, без разлика дали имаме систем кој ќе ни помогне или не.

Инженерски пристапи и практики - главен фокус на TechLead Conf. Ако сте постигнале успех на патот кон техничката извонредност и сте подготвени да ви кажете што ви помогна во тоа, - аплицирајте за извештај.
Планираме да Технички водечки конф 8 јуни. Ние разбираме дека сега е тешко да се носат одлуки за учество на конференцијата. Но, во исто време, веруваме дека карантинот не е причина да се запре професионалната комуникација и развој. Затоа, во секој случај, ќе најдеме начин да разговараме за задачите на техничкиот лидер и пристапите за нивно решавање - доколку е потребно, ќе одиме онлајн и ќе воспоставиме мрежно поврзување таму!

Извор: www.habr.com