Забелешка. превод.: Оваа статија продолжува со одлична серија написи од евангелистот на технологијата AWS, Адријан Хорнсби, кој на едноставен и јасен начин сака да ја објасни важноста на експериментирањето за да се ублажат последиците од неуспесите во ИТ системите.
„Ако не успеете да подготвите план, тогаш планирате да не успеете“. - Бенџамин Френклин
В Во оваа серија на написи, го претставив концептот на хаос инженеринг и објаснив како помага да се пронајдат и поправат недостатоците во системот пред тие да доведат до дефекти во производството. Исто така, разговараше за тоа како инженерството за хаос промовира позитивни културни промени во организациите.
На крајот од првиот дел, ветив дека ќе зборувам за „алатки и методи за воведување неуспеси во системите“. За жал, мојата глава имаше свои планови во овој поглед, и во оваа статија ќе се обидам да одговорам на најпопуларното прашање што се јавува кај луѓето кои сакаат да влезат во инженерството на хаос: Што прво да се скрши?
Одлично прашање! Сепак, се чини дека не му пречи особено оваа панда...
Не се плеткајте со хаос пандата!
Краток одговор: Насочете ги критичните услуги по патеката на барањето.
Подолг, но појасен одговор: За да разберете каде да започнете да експериментирате со хаосот, обрнете внимание на три области:
- Гледај во историја на несреќа и идентификуваат модели;
- Одлучете се за критични зависности;
- Користете го т.н ефект на прекумерна самодоверба.
Смешно е, но овој дел исто толку лесно може да се нарече „Патување до самооткривање и просветлување“. Во него ќе почнеме да „играме“ со некои кул инструменти.
1. Одговорот лежи во минатото
Ако се сеќавате, во првиот дел го воведов концептот на корекција на грешки (COE) - метод со кој ги анализираме нашите грешки - грешки во технологијата, процесот или организацијата - со цел да ја разбереме нивната причина(и) и да спречиме повторување во иднина. Во принцип, тука треба да започнете.
„За да ја разберете сегашноста, треба да го знаете минатото“. - Карл Саган
Погледнете ја историјата на неуспесите, означете ги во COE или постмортеми и класифицирајте ги. Идентификувајте ги вообичаените обрасци кои често доведуваат до проблеми и за секој COE, поставете си го следново прашање:
„Дали ова можеше да се предвиди и затоа да се спречи со вбризгување на дефект?
Се сеќавам на еден неуспех на почетокот на мојата кариера. Тоа можеше лесно да се спречи ако направевме неколку едноставни хаос експерименти:
Во нормални услови, заднинските примероци реагираат на здравствените проверки од ). ELB ги користи овие проверки за да ги пренасочи барањата до здрави примероци. Кога ќе се покаже дека примерот е „нездрав“, ELB престанува да испраќа барања до него. Еден ден, по успешната маркетиншка кампања, обемот на сообраќај се зголеми и позадините почнаа да реагираат на здравствените проверки побавно од вообичаено. Треба да се каже дека овие здравствени проверки беа , односно проверена е состојбата на зависностите.
Сепак, сè беше во ред некое време.
Потоа, веќе под прилично стресни услови, еден од случаите почна да извршува некритична, редовна ETL cron задача. Комбинацијата на голем сообраќај и cronjob ја турна искористеноста на процесорот на речиси 100%. Преоптоварувањето на процесорот дополнително ги забави одговорите на здравствените проверки, толку многу што ELB одлучи дека примерокот има проблеми со перформансите. Како што се очекуваше, балансерот престана да го дистрибуира сообраќајот до него, што, пак, доведе до зголемување на оптоварувањето на останатите примероци во групата.
Одеднаш, сите други случаи исто така почнаа да не успеваат на здравствениот преглед.
Започнувањето на нова инстанца бараше преземање и инсталирање пакети и беше потребно многу подолго отколку што му требаше на ELB да ги оневозможи - еден по еден - во групата за автоматско скалирање. Јасно е дека набрзо целиот процес достигна критична точка и апликацијата падна.
Тогаш засекогаш ги разбравме следниве точки:
- Инсталирањето на софтвер при креирање на нова инстанца трае долго време, подобро е да се даде предност на непроменливиот пристап и .
- Во сложени ситуации, одговорите на здравствените проверки и ELB треба да имаат приоритет - последното нешто што сакате е да го комплицирате животот за останатите случаи.
- Локалното кеширање на здравствени проверки помага многу (дури и за неколку секунди).
- Во тешка ситуација, не извршувајте cron задачи и други некритични процеси - заштедете ресурси за најважните задачи.
- При автоматско скалирање, користете помали примероци. Група од 10 мали примероци е подобра од група од 4 големи примероци; ако едната инстанца не успее, во првиот случај 10% од сообраќајот ќе биде распределен на 9 точки, во вториот - 25% од сообраќајот на три точки.
Значи, дали тоа можеше да се предвиди, па затоа и да се спречи со воведување на проблемот?
Да, и на неколку начини.
Прво, со симулирање на висока употреба на процесорот користејќи алатки како што се или :
❯ stress-ng --matrix 1 -t 60s
стрес-нг
Второ, со преоптоварување на инстанцата со и други слични комунални услуги:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Експериментите се релативно едноставни, но можат да обезбедат добра храна за размислување без да мора да поминете низ стресот од вистински неуспех.
Но не застанувај тука. Обидете се да го репродуцирате падот во тест средина и проверете го вашиот одговор на прашањето "Дали тоа можеше да се предвиди и затоа да се спречи со воведување дефект?" Ова е мини хаос експеримент во хаос експеримент за тестирање на претпоставките, но почнувајќи со неуспех.
Дали тоа беше сон или навистина се случи?
Затоа, проучете ја историјата на неуспесите, анализирајте СОЕ, означете ги и класифицирајте ги по „радиус на удар“ - или попрецизно, бројот на засегнати клиенти - и потоа побарајте модели. Запрашајте се дали тоа можело да се предвиди и спречи со воведување на проблемот. Проверете го вашиот одговор.
Потоа префрлете се на најчестите обрасци со најголем опсег.
2. Изградете мапа на зависност
Одвојте момент да размислите за вашата апликација. Дали постои јасна карта на нејзините зависности? Дали знаете какво влијание ќе имаат ако има неуспех?
Ако не сте многу запознаени со кодот на вашата апликација или тој станал многу голем, може да биде тешко да се разбере што прави кодот и кои се неговите зависности. Разбирањето на овие зависности и нивното можно влијание врз апликацијата и корисниците е од клучно значење за да се знае од каде да се започне со инженерството за хаос: почетната точка е компонентата со најголем радиус на удар.
Идентификувањето и документирањето на зависностите се нарекува "градење мапа на зависност» (мапирање на зависност). Ова обично се прави за апликации со голема база на код користејќи алатки за профилирање на кодови. (профилирање на код) и инструментација (инструментација). Можете исто така да изградите мапа со следење на мрежниот сообраќај.
Сепак, не се сите зависности исти (што дополнително го комплицира процесот). Некои критички, друго - секундарно (барем во теорија, бидејќи падовите често се случуваат поради проблеми со зависности кои се сметаа за некритични).
Без критични зависности, услугата не може да работи. Некритични зависности "не треба» да влијае на сервисот во случај на пад. За да ги разберете зависностите, треба да имате јасно разбирање за API-ите што ги користи вашата апликација. Ова може да биде многу потешко отколку што изгледа - барем за големи апликации.
Започнете со поминување низ сите API. Истакнете најмногу значајни и критични. Земете зависности од складиштето за кодови, проверете го логови за поврзување, потоа погледнете документација (се разбира, ако постои - инаку сè уште иматеопоголеми проблеми). Користете ги алатките за да профилирање и следење, филтрирајте ги надворешните повици.
Можете да користите програми како netstat - алатка за командна линија која прикажува листа на сите мрежни конекции (активни приклучоци) во системот. На пример, за да ги наведете сите тековни врски, напишете:
❯ netstat -a | more
Во AWS можете да користите (дневници на проток) VPC е метод кој ви овозможува да собирате информации за IP сообраќајот што оди до или од мрежните интерфејси во VPC. Таквите дневници можат да помогнат и при други задачи - на пример, наоѓање одговор на прашањето зошто одреден сообраќај не стигнува до примерокот.
Можете исто така да користите . X-Ray ви овозможува да добиете детални, „ултимативни“ (од крај до крај) преглед на барањата додека се движат низ апликацијата, а исто така гради мапа на основните компоненти на апликацијата. Многу погодно ако треба да ги идентификувате зависностите.
AWS X-Ray конзола
Картата на зависност од мрежата е само делумно решение. Да, покажува која апликација со која комуницира, но има и други зависности.
Многу апликации користат DNS за да се поврзат со зависности, додека други може да користат откривање на услуги или дури и тврдокодирани IP адреси во конфигурациските датотеки (на пр. /etc/hosts).
На пример, можете да креирате со помош на iptables и види што пукна. За да го направите ова, внесете ја следнава команда:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS црна дупка
Ако е /etc/hosts или други конфигурациски датотеки, ќе најдете IP адреси за кои не знаете ништо (да, за жал, ова исто така се случува), можете повторно да дојдете на помош iptables. Да речеме дека сте откриле 8.8.8.8 и не знам дека ова е адресата на јавниот DNS сервер на Google. Со користење на 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"
Затворање на пристапот
Првото правило ги исфрла сите пакети од јавниот DNS на Google: ping работи, но пакетите не се враќаат. Второто правило ги исфрла сите пакети кои потекнуваат од вашиот систем кон јавниот DNS на Google - како одговор на ping добиваме Операцијата не е дозволена.
Забелешка: во овој конкретен случај би било подобро да се користи whois 8.8.8.8, но ова е само пример.
Можеме да одиме уште подлабоко во дупката за зајаци, бидејќи сè што користи TCP и UDP всушност зависи и од IP. Во повеќето случаи, IP е поврзана со ARP. Не заборавајте за заштитните ѕидови...
Ако ја земете црвената пилула, останувате во земјата на чудата, а јас ќе ви покажам колку длабоко оди зајачката дупка“.
Порадикален пристап е да исклучи коли еден по еден и видете што е скршено... станете „мајмун од хаос“. Се разбира, многу системи за производство не се дизајнирани за таков напад со брутална сила, но барем може да се испроба во пробна средина.
Изградбата на мапа на зависност е често многу долга работа. Неодамна разговарав со клиент кој потроши речиси 2 години развивајќи алатка која полуавтоматски генерира мапи на зависност за стотици микросервиси и команди.
Резултатот, сепак, е исклучително интересен и корисен. Ќе научите многу за вашиот систем, неговите зависности и операции. Повторно, бидете трпеливи: тоа е самото патување она што е најважно.
3. Пазете се од прекумерна самодоверба
„Кој што сонува, верува во тоа“. - Демостен
Дали некогаш сте слушнале за ефект на прекумерна самодоверба?
Според Википедија, ефектот на прекумерна доверба е „когнитивна пристрасност во која довербата на една личност во нивните постапки и одлуки е значително поголема од објективната точност на тие пресуди, особено кога нивото на доверба е релативно високо“.
Врз основа на инстинкт и искуство...
Од моето искуство, можам да кажам дека ова нарушување е одличен навестување од каде да се започне со хаос инженеринг.
Пазете се од операторот со прекумерна самодоверба:
Чарли: „Оваа работа не падна веќе пет години, се е во ред!“
Несреќа: „Чекај... ќе бидам таму наскоро!“
Пристрасноста како последица на прекумерната самодоверба е подмолна, па дури и опасна работа поради различните фактори кои влијаат на неа. Ова е особено точно кога членовите на тимот ги преточиле своите срца во технологија или потрошиле многу време за да ја „поправат“.
Сумирање
Потрагата по почетна точка за инженерството за хаос секогаш носи повеќе резултати од очекуваното, а тимовите кои пребрзо почнуваат да ги разбиваат работите ја губат од вид поглобалната и интересна суштина на (хаос-)инженеринг - креативна апликација научни методи и емпириски доказ за проектирање, развој, работа, одржување и подобрување на (софтверски) системи.
Ова го завршува вториот дел. Ве молиме напишете рецензии, споделувајте мислења или само плескајте . Во следниот дел И навистина Ќе ги разгледам алатките и методите за воведување неуспеси во системите. Додека!
PS од преведувач
Прочитајте и на нашиот блог:
- «";
- «";
- «";
- «".
Извор: www.habr.com