Забележка. превод: Тази статия продължава страхотна поредица от статии от евангелизатора на технологиите на AWS Ейдриън Хорнсби, който има за цел да обясни по прост и ясен начин значението на експериментирането за смекчаване на последствията от повреди в ИТ системите.
"Ако не успеете да подготвите план, значи планирате да се провалите." - Бенджамин Франклин
В В тази поредица от статии представих концепцията за хаос инженерство и обясних как помага да се открият и коригират недостатъци в системата, преди те да доведат до производствени повреди. Той също така обсъди как инженерството на хаоса насърчава положителната културна промяна в организациите.
В края на първата част обещах да говоря за „инструменти и методи за въвеждане на грешки в системите“. Уви, главата ми имаше свои собствени планове в това отношение и в тази статия ще се опитам да отговоря на най-популярния въпрос, който възниква сред хората, които искат да влязат в инженерството на хаоса: Какво да счупя първо?
Страхотен въпрос! Той обаче изглежда не се притеснява особено от тази панда...
Не се забърквайте с пандата на хаоса!
Кратък отговор: Насочете критични услуги по пътя на заявката.
По-дълъг, но по-ясен отговор: За да разберете откъде да започнете да експериментирате с хаоса, обърнете внимание на три области:
- Гледам история на сривовете и идентифициране на модели;
- Вземете решение за критични зависимости;
- Използвайте т.нар ефект на свръхувереност.
Смешно е, но тази част може също толкова лесно да се нарече „Пътуване към себеоткриването и просветлението“. В него ще започнем да „свирим“ с някои готини инструменти.
1. Отговорът се крие в миналото
Ако си спомняте, в първата част въведох концепцията за коригиране на грешки (COE) - метод, чрез който анализираме нашите грешки - грешки в технологията, процеса или организацията - за да разберем причината(ите) им и да предотвратим повторение в бъдеще. Като цяло оттук трябва да започнете.
"За да разбереш настоящето, трябва да познаваш миналото." — Карл Сейгън
Погледнете историята на неуспехите, маркирайте ги в COE или postmortems и ги класифицирайте. Идентифицирайте общи модели, които често водят до проблеми, и за всеки 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
Експериментите са сравнително прости, но могат да осигурят добра храна за размисъл, без да се налага да преминавате през стреса от истински провал.
Но не спирайте дотук. Опитайте се да възпроизведете срива в тестова среда и проверете отговора си на въпроса "Може ли това да бъде предвидено и следователно предотвратено чрез въвеждане на повреда?" Това е малък хаос експеримент в рамките на хаос експеримент за тестване на предположения, но започвайки с провал.
Беше ли сън или наистина се случи?
Така че изучавайте историята на неуспехите, анализирайте COE, маркирайте ги и ги класифицирайте по „радиус на попадение“ – или по-точно, по броя на засегнатите клиенти – и след това потърсете модели. Запитайте се дали това е могло да бъде предвидено и предотвратено чрез представяне на проблема. Провери си отговора.
След това преминете към най-често срещаните модели с най-голям диапазон.
2. Изградете карта на зависимостта
Отделете малко време, за да помислите върху вашата кандидатура. Има ли ясна карта на неговите зависимости? Знаете ли какво влияние ще окажат, ако има провал?
Ако не сте много запознати с кода на вашето приложение или той е станал много голям, може да е трудно да разберете какво прави кодът и какви са неговите зависимости. Разбирането на тези зависимости и възможното им въздействие върху приложението и потребителите е от решаващо значение, за да знаете откъде да започнете с инженерството на хаоса: началната точка е компонентът с най-голям радиус на въздействие.
Идентифицирането и документирането на зависимости се нарича "изграждане на карта на зависимостта» (картографиране на зависимост). Това обикновено се прави за приложения с голяма кодова база, като се използват инструменти за профилиране на код. (профилиране на код) и инструментариум (инструменти). Можете също така да изградите карта, като наблюдавате мрежовия трафик.
Не всички зависимости обаче са еднакви (което допълнително усложнява процеса). някои критичен, друго - втори (поне на теория, тъй като често възникват сривове поради проблеми със зависимости, които се считат за некритични).
Без критични зависимости услугата не може да работи. Некритични зависимости "не трябва» за повлияване на услугата в случай на падане. За да разберете зависимостите, трябва да имате ясно разбиране за API, използвани от вашето приложение. Това може да бъде много по-трудно, отколкото изглежда - поне за големи приложения.
Започнете, като преминете през всички API. Маркирайте най-много значими и критични. Предприеме в зависимост от от хранилището на кодове, вижте го регистрационни файлове за връзка, след това прегледайте документация (разбира се, ако съществува - в противен случай все още иматеопо-големи проблеми). Използвайте инструментите за профилиране и проследяване, филтрирайте външни повиквания.
Можете да използвате програми като netstat - помощна програма за команден ред, която показва списък на всички мрежови връзки (активни сокети) в системата. Например, за да изброите всички текущи връзки, въведете:
❯ netstat -a | more
В AWS можете да използвате (журнали на потока) VPC е метод, който ви позволява да събирате информация за IP трафик, отиващ към или от мрежови интерфейси във VPC. Такива регистрационни файлове могат да помогнат и при други задачи - например намиране на отговор на въпроса защо определен трафик не достига до инстанцията.
Можете също да използвате . Рентгеновите лъчи ви позволяват да получите подробни, "крайни" (от край до край) преглед на заявките, докато се движат през приложението, и също така изгражда карта на основните компоненти на приложението. Много удобно, ако трябва да идентифицирате зависимости.
AWS рентгенова конзола
Картата на мрежовата зависимост е само частично решение. Да, показва кое приложение с кое комуникира, но има и други зависимости.
Много приложения използват 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. Пазете се от прекомерна самоувереност
"Който за каквото мечтае, вярва в него." — Демостен
Чували ли сте някога за ефект на свръхувереност?
Според Уикипедия ефектът на свръхувереността е „когнитивно пристрастие, при което увереността на дадено лице в действията и решенията му е значително по-голяма от обективната точност на тези преценки, особено когато нивото на увереност е относително високо“.
На база инстинкт и опит...
Според моя опит това изкривяване е чудесен намек откъде да започнем с инженерството на хаоса.
Пазете се от прекалено самоуверения оператор:
Чарли: „Това нещо не е падало от пет години, всичко е наред!“
Crash: „Чакай... Ще бъда там скоро!“
Пристрастието като следствие от прекомерната самоувереност е коварно и дори опасно нещо поради различните фактори, които му влияят. Това е особено вярно, когато членовете на екипа са вложили сърцето си в дадена технология или са прекарали много време в нейното „поправяне“.
Обобщаване
Търсенето на отправна точка за хаос инженерство винаги носи повече резултати от очакваното и екипи, които започват да разбиват нещата твърде бързо, губят от поглед по-глобалната и интересна същност на (хаос-)инженерство - творческо приложение научни методи и емпирично доказателство за проектиране, разработване, експлоатация, поддръжка и подобряване на (софтуерни) системи.
С това приключваме втората част. Моля, пишете отзиви, споделяйте мнения или просто пляскайте с ръце . В следващата част I наистина Ще разгледам инструменти и методи за въвеждане на грешки в системите. До!
PS от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com