Эскертүү. котормо.: Бул макалада IT системаларындагы мүчүлүштүктөрдүн кесепеттерин азайтуу үчүн эксперименттин маанилүүлүгүн жөнөкөй жана түшүнүктүү жол менен түшүндүрүүнү көздөгөн AWS технологиялык евангелист Адриан Хорнсбинин көптөгөн макалалары уланат.
"Эгер сиз план даярдай албасаңыз, анда ийгиликке жетпей каласыз." - Бенджамин Франклин
В Бул макалалар сериясында мен хаос инженериясы түшүнүгүн киргиздим жана ал системадагы кемчиликтерди өндүрүштүн бузулушуна алып келгенге чейин табууга жана оңдоого кандайча жардам берерин түшүндүрдүм. Ошондой эле баш аламандык инженерия уюмдардагы позитивдүү маданий өзгөрүүлөргө кандайча өбөлгө түзөрү талкууланды.
Биринчи бөлүктүн аягында мен "системаларга мүчүлүштүктөрдү киргизүүнүн куралдары жана ыкмалары" жөнүндө сөз кылууга убада бердим. Тилекке каршы, менин башымда бул багытта өзүнүн пландары бар болчу, жана бул макалада мен башаламандык инженериясына кирүүнү каалаган адамдар арасында пайда болгон эң популярдуу суроого жооп берүүгө аракет кылам: Биринчи эмнени бузуу керек?
Улуу суроо! Бирок, аны бул панда өзгөчө тынчсыздандырбайт окшойт...
Баш аламандык панда менен аралашпаңыз!
Кыска жооп: Талап жолунда маанилүү кызматтарды максаттуу.
Узун, бирок так жооп: Башаламандык менен экспериментти кайдан баштоону түшүнүү үчүн үч чөйрөгө көңүл буруңуз:
- карап кыйроо тарыхы жана моделдерин аныктоо;
- Чечиңиз критикалык көз карандылыктар;
- деп аталганды колдонуңуз ашыкча ишеним таасири.
Бул күлкүлүү, бирок бул бөлүктү оңой эле атаса болот "Өзүн-өзү ачууга жана агартууга саякат". Анда биз кээ бир сонун аспаптар менен "ойно" баштайбыз.
1. Жооп өткөндө жатат
Эсиңиздерде болсо, биринчи бөлүктө мен каталарды оңдоо (COE) түшүнүгүн киргизген элем - бул ыкма менен биз каталарыбызды - технологиядагы, процесстеги же уюмдагы каталарды - алардын себептерин түшүнүү жана алдын алуу үчүн анализдеп жатабыз. келечекте кайталануу. Жалпысынан алганда, бул жерден баштоо керек.
"Азыркыны түшүнүү үчүн өткөндү билиш керек." - Карл Саган
Ийгиликтердин тарыхын караңыз, аларды COE же постмортемде белгилеңиз жана классификациялаңыз. Көбүнчө көйгөйлөргө алып келген жалпы үлгүлөрдү аныктаңыз жана ар бир КЭБ үчүн өзүңүзгө төмөнкү суроону бериңиз:
"Муну алдын ала айтууга болот, демек, инъекциянын катачылыктары менен алдын алуу мүмкүнбү?"
Карьерамдын башында бир ийгиликсиздик эсимде. Эгерде биз бир-эки жөнөкөй хаос экспериментин жүргүзсөк, муну оңой эле алдын алса болот эле:
Кадимки шарттарда, backend инстанциялары ден соолук текшерүүлөрүнө жооп беришет ). ELB бул текшерүүлөрдү суроо-талаптарды дени сак инстанцияларга багыттоо үчүн колдонот. Бул инстанция "соолукка зыяндуу" болуп чыкканда, ELB ага суроо-талаптарды жөнөтүүнү токтотот. Бир күнү, ийгиликтүү маркетинг кампаниясынан кийин, трафиктин көлөмү көбөйүп, бейтаптар ден соолук текшерүүлөрүнө адаттагыдан жайыраак жооп бере башташты. Бул ден соолук текшерүүлөр болгон деп айтуу керек , башкача айтканда, көз карандылыктын абалы текшерилди.
Бирок, бир аз убакытка чейин баары жакшы болду.
Андан кийин, буга чейин эле стресстик шарттарда, инстанциялардын бири критикалык эмес, үзгүлтүксүз ETL cron тапшырмасын аткара баштады. Жогорку трафик менен cronjob айкалышы CPU колдонууну дээрлик 100% га чейин түрттү. Процессордун ашыкча жүктөлүшү ден-соолук текшерүүлөрүнө жоопторду андан ары жайлады, ошондуктан ELB инстанцияда иштөө көйгөйлөрү бар деп чечти. Күтүлгөндөй, баланстоочу ага трафикти бөлүштүрүүнү токтотту, бул өз кезегинде топтун калган инстанцияларына жүктөмдүн көбөйүшүнө алып келди.
Күтүлбөгөн жерден, бардык башка учурлар да ден соолук текшерүүдөн өтпөй баштады.
Жаңы инстанцияны баштоо үчүн топтомдорду жүктөө жана орнотуу талап кылынды жана ELB аларды автоматтык масштабдоо тобунда биринин артынан бири өчүрүү үчүн талап кылынгандан да көп убакытты талап кылды. Көп өтпөй бүт процесс критикалык чекке жетип, тиркеме бузулганы түшүнүктүү.
Ошондо биз төмөнкү ойлорду түбөлүккө түшүндүк:
- Жаңы инстанцияны түзүүдө программалык камсыздоону орнотуу көп убакытты талап кылат, ал өзгөрүлбөс ыкмага артыкчылык берүү жана .
- Татаал кырдаалдарда ден соолукту текшерүүгө жана ELB'лерге жооп берүү артыкчылыктуу болушу керек - сиз каалаган эң акыркы нерсе - калган учурлар үчүн жашоону кыйындатуу.
- Ден соолук текшерүүлөрүн жергиликтүү кэштөө көп жардам берет (бир нече секундага да).
- Кыйын кырдаалда cron тапшырмаларын жана башка маанилүү эмес процесстерди аткарбаңыз - эң маанилүү тапшырмалар үчүн ресурстарды үнөмдөңүз.
- Автомасштабтоодо, кичинекей нускаларды колдонуңуз. 10 кичинекей үлгүдөн турган топ 4 чоң топко караганда жакшыраак; эгерде бир инстанция иштебей калса, биринчи учурда трафиктин 10% 9 пунктка бөлүштүрүлөт, экинчисинде - үч баллдан ашык трафиктин 25%.
Ошентип, Муну алдын ала көрүүгө болот беле, ошондуктан маселени киргизүү менен алдын алса болот беле?
ошол, жана бир нече жолдор менен.
Биринчиден, сыяктуу куралдарды колдонуу менен CPU жогорку колдонууну симуляциялоо менен же :
❯ 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 бул 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 менен байланышкан. Firewalls жөнүндө унутпаңыз ...
Эгер кызыл таблетканы ичсең, кереметтер өлкөсүндө каласың, мен сага коёндун тешиги канчалык терең экенин көрсөтөм.
бир кыйла радикалдуу мамиле болуп саналат ажыратуу машиналарды биринин артынан бири көрүп, эмнеси бузулганын көргүлө... “башаламан маймылга” айланышат. Албетте, көптөгөн өндүрүш системалары мындай орой күч чабуулу үчүн иштелип чыккан эмес, бирок, жок эле дегенде, сыноо чөйрөсүндө аракет кылса болот.
Көз карандылыктын картасын түзүү көбүнчө өтө узакка созулган иш. Мен жакында жүздөгөн микросервистердин жана буйруктардын көз карандылык карталарын жарым-жартылай автоматтык түрдө түзүүчү куралды иштеп чыгууга дээрлик 2 жыл сарптаган кардар менен сүйлөштүм.
Бирок натыйжасы абдан кызыктуу жана пайдалуу. Сиз системаңыз, анын көз карандылыгы жана операциялары жөнүндө көп нерсени билесиз. Дагы бир жолу, сабырдуу болуңуз: эң маанилүүсү бул сапардын өзү.
3. Ашыкча ишенүүчүлүктөн сак болуңуз
«Ким эмнени кыялданса, ага ишенет». — Демосфен
Сиз уктуңуз беле ашыкча ишеним таасири?
Википедияга ылайык, ашыкча ишенүү эффекти "адамдын өз иш-аракеттерине жана чечимдерине болгон ишеними, өзгөчө ишеним деңгээли салыштырмалуу жогору болгондо, ал чечимдердин объективдүү тактыгынан кыйла жогору болгон когнитивдик бир тараптуулук".
Инстинкт жана тажрыйбанын негизинде...
Өзүмдүн тажрыйбамдан улам, бул бурмалоо башаламандык инженериясын кайдан баштоо керектиги боюнча чоң ишарат деп айта алам.
Өзүнө ашыкча ишенген оператордон сак болуңуз:
Чарли: "Бул нерсе беш жылдан бери түшкөн жок, баары жакшы!"
Crash: "Күтө туруңуз... Мен жакында келем!"
Ашыкча ишенүүнүн кесепети катары бир тараптуулук, ага таасир эткен ар кандай факторлордон улам тымызын жана ал тургай коркунучтуу нерсе. Бул, өзгөчө, команданын мүчөлөрү технологияга жүрөгүн жумшаганда же аны "оңдоо" үчүн көп убакыт короткондо.
Жыйынтыктоо
Баш аламандык инженериясынын башталгыч чекитин издөө ар дайым күтүлгөндөн көбүрөөк натыйжаларды алып келет жана тез арада бир нерсени бузуп баштаган командалар (хаос-)инженерия - чыгармачылык менен пайдалануу илимий методдор и эмпирикалык далилдер (программалык камсыздоо) системаларын долбоорлоо, иштеп чыгуу, пайдалануу, тейлөө жана өркүндөтүү үчүн.
Муну менен экинчи бөлүк аяктайт. Сураныч, сын-пикир жазыңыз, ой бөлүшүңүз же жөн гана кол чабыңыз . Кийинки бөлүмдө И чындыгында Мен системаларга мүчүлүштүктөрдү киргизүүнүн куралдарын жана ыкмаларын карап чыгам. чейин!
Котормочудан PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- «";
- ««.
Source: www.habr.com