Забелешка. превод.: Задоволство ни е да го споделиме преводот на прекрасниот материјал од Senior Technology Evangelist од AWS - Adrian Hornsby. Со едноставни зборови, тој ја објаснува важноста на експериментирањето за да се ублажат ефектите од неуспесите во ИТ системите. Веројатно веќе сте слушнале за Chaos Monkey (или дури сте користеле слични решенија)? Денес, пристапите за создавање на такви алатки и нивна имплементација во поширок контекст се спроведуваат во рамките на активноста наречена хаос инженеринг. Прочитајте повеќе за тоа во оваа статија.
„Но, зад сета оваа убавина се крие хаос и лудило“. - Танер Волинг
Пожарникари. Овие високо обучени професионалци секојдневно ги ризикуваат своите животи гасејќи пожари. Дали знаевте дека мора да поминете најмалку 600 часа на обука пред да станете пожарникар? И ова е само почеток. Според извештаите, пожарникарите тренираат до 80% од нивното работно време.
Зошто?
Кога пожарникар се бори со вистински пожар, му треба соодветното интуиција. За да го развиете, треба да тренирате час по час, ден по ден. Како што велат, практиката прави чуда.
„Се чини дека тие навлегуваат во самата суштина на огнот; некако како д-р Фил за пламен“. -
Забелешка. превод.: Филип Калвин „Фил“ МекГроу е американски психолог, писател и водител на популарната телевизиска програма Д-р Фил, во која водителот на своите учесници им нуди решенија за нивните проблеми.
Некогаш во Сиетл
Во раните 2000 -ти , кој имаше позиција во Амазон со официјална титула Мајстор за катастрофи, ја креираше и ја водеше програмата GameDay. Се засноваше на неговото искуство како пожарникар. GameDay имаше за цел да ги тестира, обучи и подготви различните системи, софтвер и луѓе на Amazon за потенцијални кризни ситуации.
Исто како што пожарникарите развиваат интуиција за гаснење пожари, Џеси сакал да му помогне на својот тим да развие интуиција за справување со катастрофални настани од големи размери.
„GameDay: Creating Resiliency Through Destruction“ - Џеси Робинс
беше дизајниран да ја зголеми стабилноста на сајтот за малопродажба на Амазон со намерно воведување грешки во критичните системи.
GameDay започна со серија објави до целата компанија дека е планирана вежба - понекогаш доста големи, на пример, исклучување на цел центар за податоци. Беа дадени минимални детали за планираниот прекин, а тимот доби неколку месеци да се подготви. Главната цел на вежбата беше да се тестира дали персоналот може да се справи со локалната криза и брзо да ги реши нејзините последици.
За време на овие вежби, беа користени специфични алатки и процеси, како што се следење, предупредувања и итни повици, за да се анализираат и идентификуваат грешките во процедурите за одговор на инцидентот. Како што се испостави, GameDay е одличен во идентификувањето на класичните архитектонски проблеми. Понекогаш беше можно да се откријат и таканаречените „латентни дефекти“ - проблеми што се манифестираат поради спецификите на инцидентот. На пример, системите за управување со инциденти кои се клучни за процесот на обновување не успеаја поради неочекувани несакани ефекти предизвикани од вештачки проблем.
Како што растеше компанијата, теоретскиот радиус на експлозијата на GameDay се прошири. На крајот, овие вежби беа напуштени бидејќи потенцијалната штета за компанијата ако работите не одат според планот станаа преголеми. Оттогаш, програмата се дегенерира во серија различни експерименти без деловно влијание за обука на персоналот во кризни ситуации. Нема да навлегувам во детали за експериментите во оваа статија, но ќе го сторам тоа во иднина. Овој пат сакам да разговарам за една важна идеја што лежи во основата на GameDay: инженерство за доверливост (инженерство за отпорност), исто така познат како хаос инженеринг ().
Подемот на мајмуните
Веројатно сте слушнале за Netflix, онлајн провајдер на видео содржини. Нетфликс почна да се движи од сопствениот центар за податоци во AWS Cloud во август 2008 година. Овој потег беше поттикнат од сериозно оштетување на базата на податоци што ги одложи испораките на ДВД за три дена (да, Нетфликс започна да испраќа филмови по пошта со полжав). Миграцијата кон облакот беше поттикната од потребата да се справиме со многу поголеми оптоварувања на стриминг, како и желбата да се оддалечиме од монолитна архитектура и кон микросервиси кои лесно можат да се размерат во зависност од бројот на корисници и големината на инженерскиот тим. Потрошувачката страна на услугата за стриминг прво се пресели во AWS, помеѓу 2010 и 2011 година, а потоа следеше претпријатието ИТ и сите други структури. Сопствениот центар за податоци на Нетфликс беше затворен во 2016 година. Компанијата ја мери достапноста како сооднос на бројот на успешни обиди за лансирање филм со вкупниот број, наместо како едноставна споредба на времето на работа и застојот, и се стреми да постигне бројка од 0,9999 во секој регион на квартална основа (тоа често успева). Глобалната архитектура на Netflix опфаќа три AWS региони. Така, доколку се појават проблеми во еден од регионите, компанијата има можност да ги пренасочи корисниците кон други.
Ќе повторам еден од моите омилени цитати:
„Пореметувањата се неизбежни; на крајот секој систем ќе пропадне со текот на времето“. - Вернер Фогелс
Всушност, неуспесите во дистрибуираните системи, особено оние од големи размери, се неизбежни, дури и во облакот. Сепак, облакот AWS и неговите примитиви за вишок - особено , на кој е изграден, му овозможува на секој да дизајнира високо доверливи услуги.
Користење на принципите на вишок (технолошки вишок) и постепено опаѓање на функционалноста (грациозна деградација), Нетфликс без да влијае на крајните корисници.
Нетфликс од самиот почеток се придржува до најстрогите архитектонски принципи. Една од првите апликации што ја распоредија на AWS беше нивната — за поддршка на микросервисите без државјанство со автоматско скалирање. Со други зборови, секој пример може да се запре и автоматски да се замени без никакво губење на состојбата. Chaos Monkey се грижи никој да не го прекрши овој принцип.
Забелешка. превод.: Патем, за Кубернетес постои аналог наречен , чиј развој се чини дека запре во март оваа година.
Netflix има друго правило кое ја дистрибуира секоја услуга низ три зони на достапност. Треба да продолжи да работи доколку се достапни само два од нив. За да се осигура дека ова правило се почитува, ги оневозможува зоните на достапност. На глобално ниво е способен да исклучи цел регион AWS за да потврди дека сите корисници на Netflix може да се опслужуваат од кој било од трите региони. И тие ги спроведуваат овие обемни тестови на секои неколку недели во производството за да се уверат дека ништо не се лизнало низ пукнатините.
Конечно, Нетфликс исто така разви повеќе фокусиран да помогне да се идентификуваат проблемите со микросервисите и архитектурата за складирање. Повеќе за овие техники можете да дознаете во книгата Хаос инженерство, која ја препорачувам на сите заинтересирани за оваа тема.
„Со спроведување на експерименти на редовна основа кои симулираат регионални прекини, успеавме рано да идентификуваме различни недостатоци на системот и да ги исправиме“. -
Денес принципите на хаос инженеринг ; им е дадена следнава дефиниција:
„Инженерството на хаос е пристап кој вклучува спроведување на експерименти на производствен систем за да се обезбеди неговата способност да издржи разни пречки што се појавуваат за време на работата“. -
Меѓутоа, во неговиот посветен на хаос инженерството, , поранешниот креатор на архитектурата на облакот на Нетфликс, кој и помогна на компанијата да се пресели во инфраструктурата со целосен облак, претстави алтернативна дефиниција за инженерството на хаос. Според мене, поточно и потврдено е:
„Инженерството на хаос е експеримент дизајниран да ги ублажи ефектите од неуспехот“.
Всушност, знаеме дека неуспесите се случуваат постојано. Кога правилно се реагира, тие не треба да влијаат на крајните корисници. Главната цел на инженерството за хаос е да открие проблеми што не се решаваат правилно.
Потребни услови за создавање хаос
Пред да започнете со инженерството за хаос, проверете дали сте ја завршиле целата потребна работа за да обезбедите одржливост на сите нивоа на организацијата. Создавањето системи толерантни за грешки не е само софтвер. Започнува на ниво инфраструктура, се шири на мрежа и податоци, влијае на структурата апликации, и на крајот покрива луѓето и културата. Во минатото опширно пишував за моделите на отпорност и неуспесите (, , и ) и нема да се фокусирам на ова сега, но не можам без мало потсетување.
Некои потребни елементи пред да се воведе хаос во системот (списокот не е исцрпен)
Фази на хаос инженеринг
Важно е да се разбере дека суштината на инженерството на хаосот НЕ е да се пуштат мајмуните во дивината и да се остават да уништат се, без никаква цел. Поентата на оваа дисциплина е да се нарушат некои елементи на системот во контролирана средина преку добро дизајнирани експерименти за да се види дали вашата апликација може да издржи турбулентни услови.
За да го направите ова, мора да следите јасно дефиниран, формализиран процес наведен на сликата подолу. Тоа може да ви помогне да преминете од разбирање на стабилната состојба на вашиот систем до формулирање хипотеза, тестирање и, конечно, анализа на искуството стекнато од експериментот и подобрување на стабилноста на самиот систем.
Фази на хаос инженеринг
1. Стабилна состојба
Еден од најважните елементи на хаос инженерството е разбирањето на однесувањето на системот во нормални услови.
Зошто? Едноставно е: по воведувањето на вештачки дефект, мора да се погрижите системот да се врати во добро проучена стабилна состојба и експериментот повеќе да не го попречува неговото нормално однесување.
Клучот овде е да не се фокусираме на внатрешните атрибути на системот (процесор, меморија, итн.) туку на мерливи излези кои ги поврзуваат перформансите со корисничкото искуство. За овие излези да бидат во стабилна состојба, набљудуваното однесување на системот мора да има предвидлива шема, но значително да се менува кога ќе се појави дефект во системот.
Имајќи предвид , предложена погоре од Адријан Коккрофт, оваа стабилна состојба се менува кога дефектот надвор од контрола предизвикува неочекуван проблем и сигнализира дека експериментот за хаос треба да се прекине.
Како пример за стабилни држави, да го земеме искуството на Амазон. Компанијата го користи обемот на нарачката како една од нејзините метрики за стабилна состојба, и со добра причина. Во 2007 година, Грег Линден, порано од Амазон, опиша како експеримент користејќи го овој метод Се обидов да го забавам времето на вчитување на страниците на веб-локациите во чекори од 100 ms и открив дека дури и малите одложувања доведуваат до сериозен пад на приходите. Со зголемување на времето на вчитување за 100 ms, бројот на нарачки (а со тоа и продажбата) се намали за 1%. Ова е причината зошто бројот на нарачки е одличен кандидат за метрика на стабилна состојба.
Netflix користи метрика од страна на серверот поврзана со почетокот на репродукцијата - бројот на кликови на копчето „play“. Тие забележаа шема во однесувањето на индикаторот SPS (почетоци во секунда) и неговите значителни флуктуации кога се случија дефекти на системот. Метриката се нарекува „Пулсот на Нетфликс“ ().
Броевите за нарачки на Амазон и пулсот на Нетфликс се одлични барометри на стабилна состојба бидејќи ги комбинираат корисничкото искуство и оперативните метрики во единствена, мерлива и високо предвидлива метрика.
Мери, мери и мери повторно
Се подразбира дека ако не можете правилно да ги доловите метриките на системот, нема да можете да ги следите (или дури и да ги откриете) промените во стабилна состојба. Обрнете посебно внимание на читањето на сите параметри/индикатори, од мрежа, хардвер до апликација и луѓе. Нацртајте графикони на овие мерења, дури и ако тие не се менуваат со текот на времето. Ќе се изненадите кога ќе откриете корелации за кои не сте знаеле дека постојат.
„Направете им што е можно поедноставно за инженерите да пристапат до податоци што можат да ги пресметаат или да ги прикажат графиконите“. -
2. Хипотеза
Откако ќе се справите со стабилната состојба, можете да продолжите да формулирате хипотеза.
- Што ако моторот со препораки запре?
- Што ако балансерот на товарот се спушти?
- Што ако кеширањето не успее?
- Што ако латентноста се зголеми за 300 ms?
- Што ако се урна главната база на податоци?
Се разбира, треба да изберете само една хипотеза и не треба да ја комплицирате непотребно. Започнете со мали димензии. Сакам да започнам со хипотезата за персоналот. Дали сте слушнале за автобус фактор ()? Факторот на автобусот е мерка за ризикот поврзан со нерамномерно распределено знаење меѓу членовите на тимот. Ви овозможува да го пресметате минималниот број на негови учесници, по чие ненадејно губење проектот ќе престане поради недостаток на знаење или искуство.
Многу компании имаат технички експерти чие ненадејно исчезнување („удрен од автобус“) би имало разорно влијание и врз проектот и врз тимот. Идентификувајте ги овие луѓе и спроведете хаос експерименти врз нив: на пример, одземете им ги компјутерите и испратете ги дома за тој ден, а потоа набљудувајте ги (често хаотичните) резултати.
Направете го проблемот заеднички за сите!
Привлекување целиот тим да се развие хипотеза. Дозволете сите да учествуваат во бурата на идеи: сопственик на производ, технички менаџер, развивачи на задни и преден план, дизајнери, архитекти итн. Секој кој на еден или друг начин е поврзан со производот.
Прво, замолете секој да напише свој одговор на прашањето „Што ако...?“ на парче хартија. Ќе видите дека во повеќето случаи секој ќе има различен одговор и ќе сфатите дека некои од тимот воопшто не размислувале за овој проблем до сега.
Паузирајте во овој момент и разговарајте зошто членовите на тимот имаат различни идеи за тоа како производот ќе се однесува во „Што ако...?“ Вратете се на неговите спецификации и погрижете се сите да имаат добра идеја за тоа што ќе се случи следно.
Земете, на пример, гореспоменатиот сајт за малопродажба на Амазон. Што ако Купување по категорија престане да се вчитува на почетната страница?
Дали треба да вратам грешка 404? Дали вреди да се вчита страницата, оставајќи празен простор како на сликата од екранот подолу?
Дали вреди да се жртвува некоја функционалност и, на пример, да се дозволи страницата да се прошири и да ја скрие грешката?
И тоа е само на страната на корисничкиот интерфејс. Што треба да се случи во задниот дел? Дали треба да се испраќаат предупредувања? Дали услугата неуспешна треба да продолжи да прима барања секогаш кога корисникот ќе ја вчита почетната страница, или бекендот треба целосно да ја прекине?
И нешто последно. Ве молиме, не формулирајте хипотеза за која однапред знаете дека ќе предизвика проблеми! Експериментирајте со делови од системот за кои мислите дека се стабилни - на крајот на краиштата, тоа е целата поента на експериментирањето.
3. Дизајнирајте и спроведете експеримент
- Изберете една хипотеза;
- Дефинирајте го опсегот на експериментот;
- Идентификувајте ги поврзаните индикатори што ќе се мерат;
- Известете ја организацијата.
Денес многу луѓе, како и страницата , ја промовираат идејата за хаос инженеринг во производството. Иако ова треба да биде крајната цел, повеќето организации се заплашени од овој пристап, па затоа не е добро место за почеток.
За мене, хаос инженерството не е само уништување на различни елементи на производствените системи. Ова е патување. Патување во светот на знаењето, нераскинливо поврзано со таква активност како што е уништувањето на системи во контролирана средина - која било средина, било да е тоа локална дев-околина, бета, инсценирање или прод. Нарушете преку добро дизајнирани експерименти за да изградите доверба во способноста на вашата апликација да издржи турбулентни услови. "Градење на доверба“ е клучна точка овде бидејќи е претходник на културните промени потребни за успешно имплементирање на практиките за хаос инженерство и доверливост во вашата компанија.
Искрено, повеќето тимови учат многу од кршење на нештата, дури и во непродукциско опкружување. Само обидете се да направите docker stop database во вашата локална средина и видете дали можете да се справите со овој проблем без последици. Има големи шанси да не биде.
Запирање на база на податоци - Пример
Започнете малку и постепено градете доверба во вашиот тим и организација. Луѓето ќе ви кажат дека „вистинскиот производствен сообраќај е единствениот начин со сигурност да се долови однесувањето на системот“. Слушајте, насмевнете се и продолжете полека да го правите тоа што го правите. Најлошото нешто што можете да направите е да примените хаос инженеринг во производството и да пропаднете очајно. После ова, никој нема да ви верува и ќе бидете принудени засекогаш да заборавите на „мајмуните од хаос“.
Прво, заработи доверба. Покажете им на организацијата и на вашите колеги дека знаете што правите. Станете пожарникар и научете колку што можете повеќе за пламенот пред да продолжите на обуката за пожар во живо. Заработете го вашиот кредибилитет. Запомнете приказната за желката и зајакот? Бавно и трпеливо секогаш победува на трката.
Една од најважните точки за време на експериментот е разбирањето на потенцијалот радиус на оштетување од неуспехот што го воведувате и неговото минимизирање. Поставете си ги следните прашања:
- Колку клиенти ќе бидат засегнати од експериментот?
- Која функционалност ќе биде засегната?
- Кои места ќе бидат засегнати?
Размислете за „копче за убивање“ или начин веднаш да го прекинете експериментот и да се вратите во стабилна состојба што е можно побрзо. Сакам да спроведувам експерименти користејќи т.н. „Канарински“ ролери. Оваа техника го намалува ризикот од неуспех при лансирање на нови верзии на апликација во производство со постепено ширење на промените на мала подгрупа корисници и потоа полека ширење на целата инфраструктура и на сите корисници. Обожавам пуштање канари едноставно затоа што го задоволуваат принципот , а самиот експеримент е прилично лесно да се запре.
Пример за пуштање канари засновано на DNS за експерименти со хаос
Бидете внимателни со експериментите што ја менуваат состојбата на апликацијата (кеш или база на податоци) или оние што не можат да се вратат назад (лесно или воопшто).
Интересно, Адријан Коккрофт ми кажа дека една од причините зошто Netflix почна да користи NoSQL бази на податоци е затоа што немаше шема за промени или враќање назад, така што беше многу полесно постепено да се ажурираат или корегираат поединечните записи на податоци (т.е. тие беа попријателски настроени кон инженерството на хаос) .
4. Набљудувај и учи
За да научите нешто ново и да го следите напредокот на експериментот, треба да бидете во можност да ги следите перформансите на системот. Како што споменавме порано, посветете максимално внимание на сите видови метрики и параметри! Потоа квантифицирајте ги резултатите и секогаш - секогаш! — забележете го времето пред да се појават првите знаци на проблем. Многупати во мојата историја се случило системите за предупредување да не успеат и клиентите прво да твитаат за проблемот... верувајте ми, не сакате да завршите во таква ситуација, затоа користете експерименти за хаос за да ги тестирате вашите системи за следење и предупредување како добро.
- Време до откривање?
- Време пред известување и почеток на активни дејства?
- Време е до јавен оглас?
- Време до делумно губење на функционалноста?
- Колку долго трае периодот на самолекување?
- Време до целосно или делумно закрепнување?
- Време до крајот на кризата и враќање во стабилна состојба?
Запомнете дека не постои единствена изолирана причина за неуспех. Големите несреќи секогаш се резултат на неколку мали дефекти кои се акумулираат и доведуваат до криза од големи размери.
Спроведете детална постмортална анализа на секој експеримент!
Во AWS, ставаме голем акцент на анализирање на откриените неуспеси и разбирање што ги предизвикало за да можеме да спречиме слични проблеми во иднина. Сите заклучоци и резултати од експериментот се сумирани во документ наречен Корекција на грешки (COE). COE ни овозможува да учиме од нашите грешки, без разлика дали се тие недостатоци во технологијата, процесот или дури и организацијата. Ние го користиме овој механизам за да ги елиминираме основните причини за дефекти и постојано да се подобруваме.
Клучот за успехот во овој процес е отвореноста и транспарентноста за тоа што тргнало наопаку. Еден од најважните принципи во пишувањето добар COE е да се биде непристрасен и да се избегнува спомнување конкретни луѓе. Ова е често тешко во средина која го обесхрабрува таквото однесување и не дозволува можност за неуспех. Амазон користи збирка на „лидерски принципи“ () да се поттикне таквото однесување - на пр. самокритика, аналитички пристап, посветеност на највисоките стандарди и одговорност се клучни компоненти на процесот на COE и оперативната извонредност воопшто.
Извештајот на COE има пет главни делови:
- Што се случило (хронолошки редослед)?
- Какво беше влијанието врз клиентите?
- Зошто се појави грешката? ()
- Што научивме?
- Како да се спречи ова во иднина?
Овие прашања се потешки за одговор отколку што изгледаат на прв поглед, бидејќи треба да бидете сигурни дека секоја нејасна/непозната точка е внимателно проучена.
За да го претвориме механизмот COE во целосен процес, ние постојано спроведуваме прегледи во форма на неделни состаноци со задолжителна анализа на оперативните метрики. Покрај тоа, техничките води вршат неделни прегледи на метрика со целиот персонал на AWS.
5. Поправете и подобрете!
Главната лекција овде е прво поправете ги проблемите идентификувани за време на експериментите со хаос, давајќи им повисок приоритет од развојот на нови функции. Вклучете го повисокото раководство во овој процес и всадете им ја идејата дека поправањето на тековните проблеми е поважно од развојот на нова функционалност.
Еднаш му помогнав на клиентот да ги идентификува критичните проблеми со стабилноста користејќи експеримент со хаос, но поради притисокот од продажниот тим, поправките беа деприоритизирани и сите напори беа насочени кон воведување нова работа што беше „критично важна“ за клиентите. Две недели подоцна, 16-часовниот прекин ја принуди компанијата да ги реши истите проблеми што ги идентификувавме за време на експериментот со хаос. Само загубите се покажаа многу поголеми.
Придобивките од хаос инженерството
Има многу предности. Ќе истакнам две, според мене, најважни:
Прво, хаос инженерството помага да се откријат непознати проблеми во системот и да се поправат пред да предизвикаат пад на производството, да речеме, во 3 часот наутро во недела. Односно тој ја зголемува отпорноста на неуспеси и, всушност, квалитетот на спиењето.
Второ, ефективно спроведените експерименти за хаос секогаш предизвикуваат пообемни промени (главно културни) од очекуваното. Можеби најважната од нив е природната еволуција кон „невин“ (не обвинување) културата, на прашањето „Зошто го направи тоа?“ станува „Како можеме да го избегнеме ова во иднина? Резултатот е посреќен, поефикасен, поангажиран и поуспешен тим. И тоа е одлично!
Ова го завршува првиот дел. Се надевам дека ви се допадна. Ве молиме напишете рецензии, споделувајте мислења или само плескајте со рацете . Во следниот дел ќе ги разгледам алатките и техниките за воведување грешки во системите. Додека!
За оние кои се желни да го прочитаат вториот дел, го нудам мојот говор на тема хаос инженеринг во NDC во Осло. Во него зборувам за многу од моите омилени алатки:
PS од преведувач
Вториот дел од статијата на англиски јазик а исто така ќе го преведеме доколку видиме доволен интерес од читателите на Хабр за овој материјал - добредојдени се соодветни коментари на статијата!
Прочитајте и на нашиот блог:
- «";
- «";
- «".
Извор: www.habr.com
