Ескерту. аударма: Бұл мақала АТ жүйелеріндегі сәтсіздіктердің салдарын жеңілдету үшін эксперименттің маңыздылығын қарапайым және түсінікті түрде түсіндіруге кіріскен AWS технологиясының евангелисті Адриан Хорнсбидің мақалаларының тамаша сериясын жалғастырады.
«Егер сіз жоспарды дайындай алмасаңыз, онда сіз сәтсіздікке ұшырайсыз». - Бенджамин Франклин
В Осы мақалалар топтамасында мен хаос инженериясының тұжырымдамасын енгіздім және оның жүйедегі кемшіліктерді өндірістегі сәтсіздіктерге әкелмес бұрын табуға және түзетуге қалай көмектесетінін түсіндірдім. Сондай-ақ хаос инженериясының ұйымдардағы оң мәдени өзгерістерге ықпал ететіні талқыланды.
Бірінші бөлімнің соңында мен «жүйеге ақауларды енгізудің құралдары мен әдістері» туралы айтуға уәде бердім. Өкінішке орай, менің басымның осыған байланысты өз жоспарлары болды және осы мақалада мен хаос инженериясымен айналысқысы келетін адамдар арасында туындайтын ең танымал сұраққа жауап беруге тырысамын: Алдымен нені бұзу керек?
Керемет сұрақ! Дегенмен, оны бұл панда онша мазаламайтын сияқты...
Хаос пандасымен араласпаңыз!
Қысқа жауап: Сұрау жолының бойындағы маңызды қызметтерге бағыттаңыз.
Ұзынырақ, бірақ түсінікті жауап: Хаоспен тәжірибені неден бастау керектігін түсіну үшін үш бағытқа назар аударыңыз:
- Қараңызшы апат тарихы және үлгілерді анықтау;
- Шешіңіз сыни тәуелділіктер;
- деп аталатынды пайдаланыңыз шектен тыс сенімділік әсері.
Бұл күлкілі, бірақ бұл бөлікті оңай атауға болады «Өзін-өзі тануға және ағартуға саяхат». Онда біз керемет аспаптармен «ойнауды» бастаймыз.
1. Жауап өткенде жатыр
Естеріңізде болса, бірінші бөлімде мен қателерді түзету (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
Тәжірибелер салыстырмалы түрде қарапайым, бірақ нақты сәтсіздіктің күйзелісінен өтпей-ақ ойға жақсы тамақ бере алады.
Алайда, сонда тоқтамаңыз. Сынақ ортасында апатты қайта жасап көріңіз және сұраққа жауабыңызды тексеріңіз "Бұны алдын ала болжап, ақауды енгізу арқылы алдын алуға болар ма еді?" Бұл жорамалдарды сынау үшін хаос экспериментіндегі шағын хаос эксперименті, бірақ сәтсіздіктен басталады.
Бұл арман болды ма, әлде шынымен болды ма?
Сондықтан сәтсіздіктердің тарихын зерттеңіз, талдаңыз EOC, белгілеп, оларды «соққы радиусы» (дәлірек айтқанда, зардап шеккен тұтынушылар саны) бойынша жіктеңіз, содан кейін үлгілерді іздеңіз. Өзіңізден сұраңыз, бұл мәселені енгізу арқылы алдын ала болжауға және алдын алуға болады ма еді. Жауабыңызды тексеріңіз.
Содан кейін ең үлкен диапазондағы ең көп таралған үлгілерге ауысыңыз.
2. Тәуелділік картасын құру
Өтінішіңіз туралы ойлануға біраз уақыт бөліңіз. Оның тәуелділіктерінің нақты картасы бар ма? Егер сәтсіздік болса, олардың қандай әсер ететінін білесіз бе?
Қолданбаның кодымен жақсы таныс болмасаңыз немесе ол өте үлкен болып кетсе, кодтың не істейтінін және оның тәуелділіктері қандай екенін түсіну қиын болуы мүмкін. Осы тәуелділіктерді және олардың қолданбаға және пайдаланушыларға ықтимал әсерін түсіну хаос инженериясын қайдан бастау керектігін білу үшін өте маңызды: бастапқы нүкте - ең үлкен әсер ету радиусы бар құрамдас.
Тәуелділіктерді анықтау және құжаттау «деп аталады.тәуелділік картасын құру» (тәуелділік картасы). Бұл әдетте код профилін жасау құралдарын пайдаланып үлкен кодтық базасы бар қолданбалар үшін жасалады. (код профилін жасау) және аспаптар (аспаптар). Сондай-ақ, желілік трафикті бақылау арқылы картаны құруға болады.
Дегенмен, барлық тәуелділіктер бірдей емес (бұл процесті одан әрі қиындатады). Кейбір сыни, басқа - қосалқы (кем дегенде теориялық тұрғыдан, себебі сыни емес деп саналатын тәуелділіктерге байланысты ақаулар жиі орын алады).
Сыни тәуелділіктерсіз қызмет жұмыс істей алмайды. Критикалық емес тәуелділіктер»болмауы тиіс» құлаған жағдайда қызметке әсер ету. Тәуелділіктерді түсіну үшін қолданбаңыз пайдаланатын API интерфейстерін нақты түсінуіңіз керек. Бұл көрінгеннен әлдеқайда қиын болуы мүмкін - кем дегенде үлкен қолданбалар үшін.
Барлық API интерфейстерін өту арқылы бастаңыз. Ең көп белгілеңіз маңызды және сыни. алыңыз тәуелділіктер код репозиторийінен, оны тексеріңіз қосылу журналдары, содан кейін қараңыз құжаттама (әрине, егер ол бар болса - әйтпесе сізде әлі де бароүлкен проблемалар). үшін құралдарды пайдаланыңыз профильдеу және бақылау, сыртқы қоңырауларды сүзіңіз.
сияқты бағдарламаларды пайдалануға болады netstat - жүйедегі барлық желілік қосылымдардың (белсенді ұялар) тізімін көрсететін пәрмен жолы утилитасы. Мысалы, барлық ағымдағы қосылымдарды тізімдеу үшін теріңіз:
❯ netstat -a | more
AWS-де сіз пайдалана аласыз (ағын журналдары) VPC — VPC ішіндегі желі интерфейстеріне баратын немесе одан шығатын IP трафигі туралы ақпаратты жинауға мүмкіндік беретін әдіс. Мұндай журналдар басқа тапсырмаларға да көмектесе алады - мысалы, белгілі бір трафик данаға неге жетпейді деген сұраққа жауап табу.
Сіз де пайдалана аласыз . Рентген егжей-тегжейлі, «соңғы» алуға мүмкіндік береді. (соңына дейін) қолданба арқылы жылжу кезіндегі сұрауларға шолу, сонымен қатар қолданбаның негізгі құрамдастарының картасын жасайды. Тәуелділіктерді анықтау қажет болса, өте ыңғайлы.
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 және бұл Google-дың жалпыға қолжетімді DNS сервер мекенжайы екенін білмеймін. Көмегімен 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"
Жабылатын рұқсат
Бірінші ереже Google-дың жалпыға қолжетімді DNS жүйесінен барлық пакеттерді алып тастайды: ping жұмыс істейді, бірақ пакеттер қайтарылмайды. Екінші ереже сіздің жүйеңізден шыққан барлық пакеттерді Google-дың жалпыға қолжетімді DNS жүйесіне жібереді - жауап ретінде ping Біз алып жатырмыз Операцияға рұқсат етілмейді.
Ескертпе: бұл нақты жағдайда пайдалану жақсы болар еді whois 8.8.8.8, бірақ бұл тек мысал.
Біз қоян тесігінен тереңірек түсе аламыз, өйткені TCP және UDP қолданатын барлық нәрсе шын мәнінде IP-ге байланысты. Көп жағдайда IP ARP-ге байланысты. Брандмауэрлер туралы ұмытпаңыз ...
Егер сіз қызыл таблетканы ішсеңіз, сіз ғажайыптар елінде қаласыз, мен сізге қоянның шұңқырының қаншалықты терең екенін көрсетемін ».
Неғұрлым радикалды көзқарас ажыратыңыз машиналарды бір-бірлеп, ненің бұзылғанын көріңіз... «хаос маймылына» айналады. Әрине, көптеген өндірістік жүйелер мұндай өрескел күш шабуылына арналмаған, бірақ кем дегенде оны сынақ ортасында сынап көруге болады.
Тәуелділік картасын құру көбінесе өте ұзақ жұмыс болып табылады. Мен жақында 2 жылға жуық уақытын жүздеген микросервистер мен пәрмендер үшін тәуелділік карталарын жартылай автоматты түрде жасайтын құралды әзірлеуге жұмсаған клиентпен сөйлестім.
Дегенмен, нәтиже өте қызықты және пайдалы. Сіз өзіңіздің жүйеңіз, оның тәуелділіктері мен операциялары туралы көп нәрсені білесіз. Тағы да, шыдамды болыңыз: ең маңыздысы бұл сапардың өзі.
3. Артық сенімділіктен сақ болыңыз
«Кім нені армандаса, соған сенеді». — Демосфен
Сіз естіп пе едіңіз шектен тыс сенімділік әсері?
Википедияға сәйкес, шектен тыс сенімділік әсері «адамның өз әрекеттері мен шешімдеріне сенімі сол пайымдаулардың объективті дәлдігіне қарағанда, әсіресе сенімділік деңгейі салыстырмалы түрде жоғары болған кезде айтарлықтай жоғары болатын когнитивтік бейімділік».
Инстинкт пен тәжірибеге негізделген...
Менің тәжірибемде бұл бұрмалану хаос инженериясын қайдан бастау керектігі туралы керемет нұсқау болып табылады.
Өзіне тым сенімді оператордан сақ болыңыз:
Чарли: «Бұл бес жыл бойы құлаған жоқ, бәрі жақсы!»
Апат: «Күте тұрыңыз... Мен жақын арада боламын!»
Шамадан тыс сенімділіктің салдары ретінде біржақтылық - оған әсер ететін әртүрлі факторларға байланысты жасырын және тіпті қауіпті нәрсе. Бұл, әсіресе, команда мүшелері технологияға жүректерін құйған немесе оны «түзетуге» көп уақыт жұмсаған кезде дұрыс.
Қорытындылай келе
Хаос инженериясының бастапқы нүктесін іздеу әрқашан күткеннен көп нәтиже береді және заттарды тез бұза бастаған командалар (хаос-)инженерия - шығармашылық қолдану ғылыми әдістер и эмпирикалық дәлелдер (бағдарламалық қамтамасыз ету) жүйелерді жобалау, әзірлеу, пайдалану, техникалық қызмет көрсету және жетілдіру үшін.
Осымен екінші бөлім аяқталады. Пікірлер жазыңыз, пікір бөлісіңіз немесе жай ғана қолыңызды соғыңыз . Келесі бөлімде И шынында Мен жүйеге ақауларды енгізудің құралдары мен әдістерін қарастырамын. Дейін!
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com