Белешка. трансл.: Овај чланак наставља сјајну серију чланака еванђелисте АВС технологије Адриана Хорнсбија, који има за циљ да на једноставан и јасан начин објасни важност експериментисања за ублажавање последица кварова у ИТ системима.
"Ако не успете да припремите план, онда планирате да не успете." - Бенџамин Френклин
В У овој серији чланака увео сам концепт хаос инжењеринга и објаснио како помаже да се пронађу и исправе недостаци у систему пре него што доведу до кварова у производњи. Такође се расправљало о томе како хаос инжењеринг промовише позитивне културне промене унутар организација.
На крају првог дела, обећао сам да ћу говорити о „алатима и методама за увођење кварова у системе“. Авај, моја глава је имала своје планове у вези с тим, а у овом чланку покушаћу да одговорим на најпопуларније питање које се намеће међу људима који желе да уђу у хаос инжењеринг: Шта прво покварити?
Одлично питање! Међутим, изгледа да му ова панда не смета посебно...
Не петљајте се са пандом хаоса!
Кратак одговор: Циљајте критичне услуге дуж путање захтева.
Дужи али јаснији одговор: Да бисте разумели одакле да почнете да експериментишете са хаосом, обратите пажњу на три области:
- Погледати на историја судара и идентификују обрасце;
- Одлучује о критичне зависности;
- Користите тзв ефекат претераног самопоуздања.
Смешно је, али овај део би се исто тако лако могао назвати „Путовање у самооткривање и просветљење“. У њему ћемо почети да се „свирамо“ са неким кул инструментима.
1. Одговор лежи у прошлости
Ако се сећате, у првом делу сам представио концепт исправљања грешака (ЦОЕ) – метод којим анализирамо наше грешке – грешке у технологији, процесу или организацији – како бисмо разумели њихов узрок(е) и спречили понављање у будућности . Уопштено говорећи, овде треба да почнете.
"Да бисте разумели садашњост, морате знати прошлост." — Карл Саган
Погледајте историју неуспеха, означите их у ЦОЕ или постмортемима и класификујте их. Идентификујте уобичајене обрасце који често доводе до проблема и за сваки ЦОЕ поставите себи следеће питање:
„Да ли се ово могло предвидети и стога спречити убризгавањем грешке?“
Сећам се једног неуспеха на почетку каријере. То се могло лако спречити да смо спровели неколико једноставних експеримената са хаосом:
У нормалним условима, позадинске инстанце реагују на здравствене провере из ). ЕЛБ користи ове провере да преусмери захтеве на здраве инстанце. Када се испостави да је инстанца „нездрава“, ЕЛБ престаје да јој шаље захтеве. Једног дана, након успешне маркетиншке кампање, обим саобраћаја се повећао и бацкендови су почели да реагују на здравствене провере спорије него иначе. Треба рећи да су ови здравствени прегледи , односно проверено је стање зависности.
Међутим, неко време је све било у реду.
Затим, већ под прилично стресним условима, једна од инстанци је почела да извршава некритичан, редован ЕТЛ црон задатак. Комбинација великог саобраћаја и цроњоб-а повећала је искоришћеност ЦПУ-а на скоро 100%. Преоптерећење процесора додатно је успорило одговоре на здравствене провере, толико да је ЕЛБ одлучио да инстанца има проблема са перформансама. Као што се и очекивало, балансер је престао да дистрибуира саобраћај на њега, што је, заузврат, довело до повећања оптерећења на преосталим инстанцама у групи.
Одједном су и све друге инстанце почеле да пропадају на здравственој контроли.
Покретање нове инстанце захтевало је преузимање и инсталирање пакета и трајало је много дуже него што је ЕЛБ-у било потребно да их онемогући – једног по једног – у групи за аутоматско скалирање. Јасно је да је убрзо цео процес достигао критичну тачку и апликација је пала.
Тада смо заувек разумели следеће тачке:
- Инсталирање софтвера приликом креирања нове инстанце траје дуго; боље је дати предност непроменљивом приступу и .
- У тешким ситуацијама, одговори на здравствене прегледе и ЕЛБ треба да имају приоритет - последња ствар коју желите је да закомпликујете живот преосталим случајевима.
- Локално кеширање здравствених провера много помаже (чак и на неколико секунди).
- У тешкој ситуацији немојте покретати црон задатке и друге некритичне процесе - уштедите ресурсе за најважније задатке.
- Приликом аутоматског скалирања користите мање инстанце. Група од 10 малих примерака је боља од групе од 4 велика; ако једна инстанца не успе, у првом случају 10% саобраћаја ће бити распоређено на 9 тачака, у другом - 25% саобраћаја на три тачке.
Дакле, да ли се то могло предвидети, па самим тим и спречити увођењем проблема?
Да, и то на неколико начина.
Прво, симулацијом високе употребе ЦПУ-а користећи алате као што су или :
❯ stress-ng --matrix 1 -t 60s
стрес-нг
Друго, преоптерећењем инстанце са и други слични услужни програми:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Експерименти су релативно једноставни, али могу пружити добру храну за размишљање без потребе да пролазите кроз стрес правог неуспеха.
Али не заустављај се ту. Покушајте да репродукујете пад у тест окружењу и проверите свој одговор на питање "Да ли се то могло предвидети и стога спречити уношењем квара?" Ово је мини експеримент хаоса у оквиру експеримента хаоса да се тестирају претпоставке, али почиње неуспехом.
Да ли је то био сан, или се заиста догодило?
Зато проучите историју неуспеха, анализирајте ЦОЕ, означите их и класификујте према „радијусу поготка“ – или тачније, броју купаца на које то утиче – а затим потражите обрасце. Запитајте се да ли је ово могло да се предвиди и спречи увођењем проблема. Проверите одговор.
Затим пређите на најчешће обрасце са највећим опсегом.
2. Направите мапу зависности
Одвојите тренутак да размислите о својој пријави. Да ли постоји јасна мапа његових зависности? Да ли знате какав ће утицај имати ако дође до неуспеха?
Ако нисте баш упознати са кодом ваше апликације или је постао веома велики, може бити тешко разумети шта код ради и које су његове зависности. Разумевање ових зависности и њиховог могућег утицаја на апликацију и кориснике је кључно за сазнање одакле почети са хаос инжењерингом: почетна тачка је компонента са највећим радијусом удара.
Идентификација и документовање зависности се назива "прављење мапе зависности» (мапирање зависности). Ово се обично ради за апликације са великом базом кода користећи алате за профилисање кода. (профилисање кода) и инструментација (инструментација). Такође можете да направите мапу праћењем мрежног саобраћаја.
Међутим, нису све зависности исте (што додатно компликује процес). Неки критичан, остало - секундарни (барем у теорији, пошто се кварови често дешавају због проблема са зависностима које се сматрају некритичним).
Без критичних зависности, услуга не може да ради. Некритичне зависности "не треба» да утиче на сервис у случају пада. Да бисте разумели зависности, морате јасно разумети АПИ-је које користи ваша апликација. Ово може бити много теже него што се чини - барем за велике апликације.
Почните тако што ћете проћи кроз све АПИ-је. Истакните највише значајан и критичан... Узми зависности из складишта кодова, проверите евиденције веза, а затим погледајте документација (наравно, ако постоји - иначе још увек иматеовећи проблеми). Користите алате да профилисање и праћење, филтрирање екстерних позива.
Можете користити програме попут netstat - услужни програм командне линије који приказује листу свих мрежних веза (активних утичница) у систему. На пример, да бисте навели све тренутне везе, откуцајте:
❯ netstat -a | more
У АВС-у можете да користите (дневници тока) ВПЦ је метод који вам омогућава да прикупите информације о ИП саобраћају који иде ка или са мрежних интерфејса у ВПЦ-у. Такви логови могу помоћи и код других задатака – на пример, проналажење одговора на питање зашто одређени саобраћај не стиже до инстанце.
Такође можете користити . Рендген вам омогућава да добијете детаљан, "крајњи" (крај са крајем) преглед захтева док се крећу кроз апликацију, а такође гради мапу основних компоненти апликације. Веома згодно ако треба да идентификујете зависности.
АВС Кс-Раи конзола
Мапа мрежне зависности је само делимично решење. Да, показује која апликација са којом комуницира, али постоје и друге зависности.
Многе апликације користе ДНС за повезивање са зависностима, док друге могу користити откривање услуга или чак тврдо кодиране ИП адресе у конфигурационим датотекама (нпр. /etc/hosts).
На пример, можете креирати уз помоћ iptables и види шта се ломи. Да бисте то урадили, унесите следећу команду:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
ДНС црна рупа
Иф ин /etc/hosts или друге конфигурационе датотеке, наћи ћете ИП адресе о којима не знате ништа (да, нажалост, и то се дешава), можете поново прискочити у помоћ iptables. Рецимо да сте открили 8.8.8.8 и не знам да је ово јавна адреса Гоогле-овог ДНС сервера. Коришћењем iptables Можете блокирати долазни и одлазни саобраћај на ову адресу користећи следеће команде:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Затварање приступа
Прво правило испушта све пакете са Гоогле-овог јавног ДНС-а: ping ради, али се пакети не враћају. Друго правило испушта све пакете који потичу из вашег система ка Гоогле-овом јавном ДНС-у – као одговор на ping ми добијамо Операција није дозвољена.
Напомена: у овом конкретном случају било би боље користити whois 8.8.8.8, али ово је само пример.
Можемо ићи још дубље у зечју рупу, јер све што користи ТЦП и УДП заправо зависи и од ИП-а. У већини случајева, ИП је везан за АРП. Не заборавите на заштитне зидове...
Ако узмеш црвену пилулу, остаћеш у земљи чуда, а ја ћу ти показати колико је дубока зечја рупа."
Радикалнији приступ је да искључити аутомобиле један по један и видите шта је покварено... постаните "мајмун хаоса". Наравно, многи производни системи нису дизајнирани за такав напад грубом силом, али се барем може испробати у тестном окружењу.
Израда мапе зависности је често веома дуготрајан подухват. Недавно сам разговарао са клијентом који је провео скоро 2 године развијајући алат који полуаутоматски генерише мапе зависности за стотине микросервиса и команди.
Резултат је, међутим, изузетно занимљив и користан. Научићете много о свом систему, његовим зависностима и операцијама. Опет, будите стрпљиви: само путовање је најважније.
3. Чувајте се претераног самопоуздања
„Ко шта сања, верује у то.” — Демостен
Да ли сте икада чули за ефекат претераног самопоуздања?
Према Википедији, ефекат превеликог самопоуздања је „когнитивна пристрасност у којој је поверење особе у своје поступке и одлуке знатно веће од објективне тачности тих пресуда, посебно када је ниво самопоуздања релативно висок.
На основу инстикта и искуства...
По мом искуству, ово изобличење је одличан наговештај о томе одакле почети са инжењерингом хаоса.
Чувајте се претерано самоувереног оператера:
Чарли: "Ова ствар није пала пет година, све је у реду!"
Црасх: „Чекај... Бићу тамо ускоро!“
Пристрасност као последица претераног самопоуздања је подмукла, па чак и опасна ствар због различитих фактора који на то утичу. Ово је посебно тачно када су чланови тима уложили своје срце у технологију или провели много времена да је „поправљају“.
Сумирајући
Потрага за почетном тачком за инжењеринг хаоса увек доноси више резултата него што се очекивало, а тимови који пребрзо почну да разбијају ствари губе из вида глобалнију и занимљивију суштину (хаоса-)инжењеринг - креативна апликација научним методама и емпиријски докази за пројектовање, развој, рад, одржавање и унапређење (софтверских) система.
Овим се завршава други део. Молимо вас да напишете рецензије, поделите мишљења или само пљесните рукама . У следећем делу И стварно Размотрићу алате и методе за увођење кварова у системе. Све док!
ПС од преводиоца
Прочитајте и на нашем блогу:
- «";
- «";
- «";
- «'.
Извор: ввв.хабр.цом