Заўв. перав.: Гэты матэрыял працягвае выдатны цыкл артыкулаў ад тэхналагічнага евангеліста з AWS - Adrian Hornsby, - які задаўся мэтай проста і зразумела растлумачыць важнасць эксперыментаў, закліканых змякчыць наступствы збояў у ІТ-сістэмах.
"Калі праваліў падрыхтоўку плана, то плануеш правал". - Бенджамін Франклін
В дадзенай серыі артыкулаў я прадставіў канцэпцыю chaos engineering'а і растлумачыў, як ён дапамагае знаходзіць і выпраўляць заганы ў сістэме да таго, як яны прывядуць да збояў production. Таксама было расказана пра тое, як хаос-інжынірынг спрыяе пазітыўным культурным зменам унутры арганізацый.
У канцы першай часткі я паабяцаў распавесці аб "інструментах і спосабах укаранення збояў у сістэмы". Нажаль, у маёй галавы на гэты конт меліся ўласныя планы, і ў гэтым артыкуле я паспрабую адказаць на самае папулярнае пытанне, якое ўзнікае і людзей, якія жадаюць заняцца хаос-інжынірынгам. Што ламаць у першую чаргу?
Выдатнае пытанне! Зрэшты, гэтую панду ён, падобна, не асоба турбуе…
Не зьвязвайцеся з хаос-пандай!
Кароткі адказ: Цэльцеся ў крытычныя сэрвісы на шляху запыту.
Доўгі, але больш зразумелы адказ: Каб зразумець, з чаго варта пачынаць эксперыменты з хаосам, звернеце ўвагу на тры вобласці:
- Паглядзіце на гісторыю збояў і выявіце заканамернасці;
- Вызначыцеся з крытычнымі залежнасцямі;
- Скарыстайцеся т. зв. эфектам звышупэўненасці.
Пацешна, але гэтую частку з тым жа поспехам можна было назваць «Падарожжа да самапазнання і асветы». У ёй жа мы пачнем "гуляць" з некаторым прышпільнымі інструментамі.
1. Адказ ляжыць у мінулым
Калі памятаеце, у першай частцы я ўвёў паняцце Correction-of-Errors (COE) - метаду, з дапамогай якога мы аналізуем нашы промахі: промахі ў тэхналогіі, працэсе або арганізацыі, - каб зразумець іх прычыну (-ы) і прадухіліць паўтарэнне ў будучыні . Увогуле, з гэтага і трэба пачынаць.
"Каб зразумець сучаснасць, трэба ведаць мінулае". - Карл Саган
Паглядзіце на гісторыю збояў, прастаўце тэгі ў СОЕ або postmortem'ах і класіфікуйце іх. Выявіце агульныя заканамернасці, якія часта прыводзяць да праблем, і для кожнага СОЕ задайце сабе наступнае пытанне:
"Ці можна гэта было прадбачыць, а такім чынам, прадухіліць з дапамогай укаранення няспраўнасці?"
Я прыгадваю адзін збой у самым пачатку маёй кар'еры. Яго можна было б лёгка прадухіліць, калі б мы правялі пару найпростых хаос-эксперыментаў:
У нармальных умовах асобнікі backend'а адказваюць на health check'і ад ). ELB выкарыстоўвае гэтыя праверкі для перанакіравання запытаў на "здаровыя" асобнікі. Калі аказваецца, што нейкі асобнік "нездаровы", ELB перастае накіроўваць на яго запыты. Аднойчы, пасля паспяховай маркетынгавай кампаніі, аб'ём трафіку вырас, і backend'ы пачалі адказваць на health check'і павольней, чым звычайна. Варта сказаць, што гэтыя health check'і былі , гэта значыць праводзілася праверка стану залежнасцяў.
Тым не менш, некаторы час усё было ў парадку.
Затым, ужо знаходзячыся ў даволі напружаных умовах, адзін з асобнікаў прыступіў да выканання некрытычнай, рэгулярнай cron-задачы з разраду ETL. Камбінацыя высокага трафіку і cronjob'а паўплывала на загрузку ЦПУ амаль на 100%. Перагрузка працэсара яшчэ мацней запаволіла адказы на health check'і – настолькі, што ELB вырашыў, што асобнік выпрабоўвае праблемы ў працы. Як і чакалася, балансавальнік перастаў размяркоўваць трафік на яго, што, у сваю чаргу, прывяло да ўзрастання нагрузкі на астатнія асобнікі ў групе.
Раптам усе астатнія асобнікі таксама пачалі правальваць health check.
Запуск новага асобніка патрабаваў загрузкі і ўсталёўкі пакетаў і займаў значна больш часу, чым патрабавалася ELB на іх адключэнне - аднаго за іншым - у групе аўтамаштабавання. Зразумела, што неўзабаве ўвесь працэс дасягнуў крытычнай адзнакі і дадатак упала.
Тады мы назаўжды ўразумелі наступныя моманты:
- Усталёўваць ПА пры стварэнні новага асобніка доўга, лепш аддаць перавагу нязменнаму (immutable) падыходу і .
- У складаных сітуацыях адказы на health-check'і ELB павінны мець прыярытэт - менш за ўсё вы хочаце ўскладніць жыццё пакінутым асобнікам.
- Добра дапамагае лакальнае кэшаванне health-check'аў (нават на некалькі секунд).
- У складанай сітуацыі не запускайце 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. Пабудуйце карту залежнасцяў
Выберыце хвілінку, каб падумаць аб сваім дадатку. Ці ёсць выразная карта яго залежнасцяў? Ці ведаеце вы, які ўплыў яны зробяць у выпадку збою?
Калі вы не вельмі добра знаёмыя з кодам свайго прыкладання ці яно стала занадта вялікім, можа быць цяжка зразумець, што робіць код і якія яго залежнасці. Разуменне гэтых залежнасцяў і іх магчымага ўплыву на дадатак і карыстальнікаў крытычна важна для ўяўлення аб тым, з чаго пачаць хаос-інжынірынг: адпраўной кропкай будзе выступаць кампанент з найбольшым радыусам паражэння.
Выяўленне і дакументаванне залежнасцяў называюць «пабудовай карты залежнасцяў» (dependency mapping). Звычайна яно праводзіцца для прыкладанняў з шырокай базай кода з выкарыстаннем прылад для прафілявання кода (code profiling) і інструментавання (instrumentation). Таксама можна праводзіць пабудову карты, адсочваючы сеткавы трафік.
Пры гэтым не ўсе залежнасці аднолькавыя (што яшчэ мацней ускладняе працэс). Некаторыя крытычна важныя, іншыя - другарадныя (прынамсі тэарэтычна, паколькі збоі часта ўзнікаюць з-за праблем з залежнасцямі, якія лічыліся некрытычнымі).
Без крытычных залежнасці сэрвіс не можа працаваць. Некрытычныя залежнасціне павінны» аказваць уплывы на сэрвіс у выпадку свайго падзення. Каб разабрацца з залежнасцямі, неабходна мець дакладнае ўяўленне аб API, якія выкарыстоўваюцца дадаткам. Гэта можа быць нашмат складаней, чым здаецца - па меншай меры, для буйных прыкладанняў.
Пачніце з перабору ўсіх API. Вылучыце самыя значныя і крытычныя. Вазьміце залежнасці з рэпазітара кода, вывучыце логі падлучэнняў, затым праглядзіце дакументацыю (вядома, калі яна існуе - інакш у вас яшчэ бобольшыя праблемы). Задзейнічайце інструменты для прафілявання і трасіроўкі, адфільтруйце знешнія выклікі.
Можна скарыстацца праграмамі накшталт netstat - утылітай каманднага радка, якая выводзіць спіс усіх сеткавых падлучэнняў (актыўных сокетаў) у сістэме. Напрыклад, каб вывесці ўсе бягучыя злучэнні, набярыце:
❯ netstat -a | more
У AWS можна выкарыстоўваць (flow logs) 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. Не варта забываць і аб firewall'ах…
Выбераш чырвоную пілюлю - застанешся ў Краіне Цудаў, і я пакажу, наколькі глыбока сыходзіць трусіная нара».
Больш за радыкальны падыход складаецца ў тым, каб адключаць машыны адну за адной і глядзець, што зламалася… станьце «малпай хаосу». Вядома, шматлікія production-сістэмы не разлічаны на падобную грубіянскую атаку, але прынамсі яе можна паспрабаваць у тэставым асяроддзі.
Пабудова карты залежнасцяў - часта вельмі доўгае мерапрыемства. Нядаўна я размаўляў з кліентам, што выдаткаваў амаль 2 гады на распрацоўку прылады, які ў паўаўтаматычным рэжыме генеруе карты залежнасцяў для сотняў мікрасэрвісаў і каманд.
Вынік, аднак, надзвычай цікавы і карысны. Вы даведаецеся шмат новага аб сваёй сістэме, яе залежнасцях і аперацыях. Ізноў жа, будзьце цярплівыя: найвялікае значэнне мае само вандраванне.
3. Сцеражыцеся саманадзейнасці
"Хто пра што марыць, той у тое і верыць". - Дэмасфен
Вы калі-небудзь чулі пра эфекце звышупэўненасці?
Паводле Вікіпедыі, эфект звышупэўненасці - гэта «кагнітыўнае скажэнне, пры якім упэўненасць чалавека ў сваіх дзеяннях і рашэннях значна вышэй, чым аб'ектыўная дакладнасць гэтых меркаванняў, асабліва калі ўзровень упэўненасці адносна высокі».
Грунтуючыся на нюху і досведзе…
Па сваім досведзе магу сказаць, што гэтае скажэнне - выдатны намёк на тое, з чаго варта пачынаць хаос-інжынірынг.
Сцеражыцеся самаўпэўненага аператара:
Чарлі: "Гэтая штука не падала гадоў пяць, усё ў норме!"
Збой: "Чакайце… хутка буду!"
Прадузятасць як наступства самаўпэўненасці - рэч падступная і нават небяспечная з-за розных фактараў, якія ўплываюць на яе. Гэта асабліва справядліва, калі чальцы каманды ўклалі душу ў нейкую тэхналогію або выдаткавалі кучу часу на "выпраўленні".
Падводжу вынікі
Пошукі адпраўной кропкі для хаос-інжынірынгу заўсёды прыносяць больш вынікаў, чым чакалася, і каманды, якія пачынаюць занадта хутка ламаць усё вакол, выпускаюць з-пад увагі больш глабальную і цікавую сутнасць (хаос-)інжынірынгу - творчае прымяненне навуковых метадаў и эмпірычных доказаў для праектавання, распрацоўкі, эксплуатацыі, абслугоўвання і ўдасканалення (праграмных) сістэм.
На гэтым другая частка падыходзіць да канца. Калі ласка, пішыце водгукі, дзяліцеся меркаваннямі ці проста пляскайце ў ладкі на . У наступнай частцы я сапраўды разгледжу прылады і метады па ўкараненні збояў у сістэмы. Да таго часу, пакуль!
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com