Նշում. թարգմ.Այս հոդվածը շարունակում է AWS տեխնոլոգիաների ավետարանիչ Ադրիան Հորնսբիի հոդվածների մեծ շարքը, ով փորձում է պարզ և պարզ կերպով բացատրել ՏՏ համակարգերում խափանումների հետևանքները մեղմելու փորձերի կարևորությունը:
«Եթե դուք չեք կարողանում պլան պատրաստել, ապա նախատեսում եք ձախողվել»: - Բենջամին Ֆրանկլին
В Այս հոդվածաշարում ես ներկայացրեցի քաոսային ճարտարագիտության հայեցակարգը և բացատրեցի, թե ինչպես է այն օգնում գտնել և ուղղել համակարգում առկա թերությունները, նախքան դրանք կհանգեցնեն արտադրության ձախողումների: Այն նաև քննարկեց, թե ինչպես է քաոսային ճարտարագիտությունը նպաստում կազմակերպությունների ներսում դրական մշակութային փոփոխություններին:
Առաջին մասի վերջում ես խոստացա խոսել «համակարգերում խափանումների ներդրման գործիքների և մեթոդների մասին»: Ավաղ, իմ գլուխն ուներ իր ծրագրերն այս առումով, և այս հոդվածում ես կփորձեմ պատասխանել ամենահայտնի հարցին, որը ծագում է այն մարդկանց շրջանում, ովքեր ցանկանում են մտնել քաոսային ճարտարագիտության մեջ. Ինչ կոտրել առաջինը:
Հիանալի հարց! Այնուամենայնիվ, նրան կարծես առանձնապես չի անհանգստացնում այս պանդան…
Մի խառնվեք քաոսային պանդաների հետ:
Կարճ պատասխաննԹիրախավորեք կարևոր ծառայությունները հարցումների ուղու երկայնքով:
Ավելի երկար, բայց ավելի հստակ պատասխանՀասկանալու համար, թե որտեղից սկսել քաոսի փորձարկումները, ուշադրություն դարձրեք երեք ոլորտների.
- Նայիր վթարի պատմություն և բացահայտել օրինաչափությունները;
- Վճռել կրիտիկական կախվածություններ;
- Օգտագործեք այսպես կոչված գերվստահության ազդեցությունը.
Ծիծաղելի է, բայց այս հատվածը նույնքան հեշտությամբ կարելի է անվանել «Ճանապարհորդություն դեպի ինքնաբացահայտում և լուսավորություն». Դրանում մենք կսկսենք «նվագել» մի քանի զով գործիքներով։
1. Պատասխանը անցյալում է
Եթե հիշում եք, առաջին մասում ես ներկայացրեցի Սխալների ուղղում (COE) հասկացությունը՝ մեթոդ, որով մենք վերլուծում ենք մեր սխալները՝ տեխնոլոգիայի, գործընթացի կամ կազմակերպման սխալները, որպեսզի հասկանանք դրանց պատճառ(ները) և կանխենք: կրկնություն ապագայում: Ընդհանրապես, այստեղից պետք է սկսել:
«Ներկան հասկանալու համար հարկավոր է իմանալ անցյալը»: - Կարլ Սագան
Նայեք ձախողումների պատմությանը, նշեք դրանք COE-ում կամ հետմահու և դասակարգեք դրանք: Բացահայտեք ընդհանուր օրինաչափությունները, որոնք հաճախ հանգեցնում են խնդիրների, և յուրաքանչյուր COE-ի համար ինքներդ ձեզ տվեք հետևյալ հարցը.
«Կարո՞ղ էր դա կանխատեսվել և, հետևաբար, կանխվել անսարքության ներարկման միջոցով»:
Ես հիշում եմ մեկ անհաջողություն իմ կարիերայի սկզբում. Դա կարելի էր հեշտությամբ կանխել, եթե մենք կատարեինք մի քանի պարզ քաոսային փորձեր.
Սովորական պայմաններում, հետին պլանային դեպքերը արձագանքում են առողջական ստուգումներին ) ELB-ն օգտագործում է այս ստուգումները՝ հարցումները առողջ օրինակներ վերահղելու համար: Երբ պարզվում է, որ օրինակը «անառողջ է», ELB-ն դադարում է հարցումներ ուղարկել նրան։ Մի օր, հաջող մարքեթինգային արշավից հետո, տրաֆիկի ծավալը մեծացավ, և հետին պլանները սկսեցին սովորականից ավելի դանդաղ արձագանքել առողջության ստուգումներին: Պետք է ասել, որ այս առողջական ստուգումները եղել են , այսինքն՝ ստուգվել է կախվածությունների վիճակը։
Այնուամենայնիվ, որոշ ժամանակ ամեն ինչ լավ էր։
Այնուհետև, արդեն բավականին սթրեսային պայմաններում, դեպքերից մեկը սկսեց կատարել ոչ կրիտիկական, կանոնավոր ETL cron առաջադրանք: Բարձր տրաֆիկի և cronjob-ի համադրությունը CPU-ի օգտագործումը մղեց գրեթե 100%: CPU-ի ծանրաբեռնվածությունը հետագայում դանդաղեցրեց առողջական ստուգումների պատասխանները, այնքան, որ 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-ում: Նման տեղեկամատյանները կարող են նաև օգնել այլ առաջադրանքներում, օրինակ՝ գտնել պատասխան այն հարցին, թե ինչու որոշակի տրաֆիկ չի հասնում օրինակին:
Կարող եք նաև օգտագործել . Ռենտգենը թույլ է տալիս ստանալ մանրամասն, «վերջնական» (վերջից վերջ) հարցումների ակնարկ, երբ դրանք շարժվում են հավելվածի միջով, ինչպես նաև կառուցում է հավելվածի հիմքում ընկած բաղադրիչների քարտեզը: Շատ հարմար է, եթե անհրաժեշտ է բացահայտել կախվածությունները:
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 և չգիտեմ, որ սա 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. Զգուշացեք չափից ավելի ինքնավստահությունից
«Ով ինչի մասին է երազում, հավատում է դրան»: -Դեմոսթենես
Դուք երբևէ լսել եք գերվստահության ազդեցությունը?
Ըստ Վիքիպեդիայի՝ գերվստահության էֆեկտը «ճանաչողական կողմնակալություն է, որի դեպքում մարդու վստահությունն իրենց գործողությունների և որոշումների նկատմամբ զգալիորեն ավելի մեծ է, քան այդ դատողությունների օբյեկտիվ ճշգրտությունը, հատկապես, երբ վստահության մակարդակը համեմատաբար բարձր է»:
Բնազդի և փորձի հիման վրա...
Իմ փորձից, այս աղավաղումը հիանալի հուշում է, թե որտեղից սկսել քաոսային ինժեներությունը:
Զգուշացեք չափազանց ինքնավստահ օպերատորից.
Չարլի. «Այս բանը հինգ տարի է, ինչ չի ընկել, ամեն ինչ լավ է»:
Վթար. «Սպասիր... ես շուտով այնտեղ կլինեմ»:
Չափից ավելի ինքնավստահության հետևանքով առաջացած կողմնակալությունը նենգ և նույնիսկ վտանգավոր բան է դրա վրա ազդող տարբեր գործոնների պատճառով: Սա հատկապես ճիշտ է, երբ թիմի անդամներն իրենց սրտերը լցրել են տեխնոլոգիայի մեջ կամ շատ ժամանակ են ծախսել այն «շտկելու» վրա:
Ամփոփելով
Քաոսի ճարտարագիտության մեկնարկային կետի որոնումը միշտ բերում է ավելի շատ արդյունքներ, քան սպասվում էր, և թիմերը, որոնք սկսում են շատ արագ կոտրել իրերը, կորցնում են տեսադաշտը (քաոս-) ավելի գլոբալ և հետաքրքիր էությունը:ճարտարագիտություն - ստեղծագործական օգտագործում գիտական մեթոդներ и էմպիրիկ ապացույցներ (ծրագրային) համակարգերի նախագծման, մշակման, շահագործման, պահպանման և կատարելագործման համար:
Սրանով ավարտվում է երկրորդ մասը։ Խնդրում ենք գրել ակնարկներ, կիսվել կարծիքներով կամ պարզապես ծափահարել . Հաջորդ մասում Ի իրականում Ես կքննարկեմ համակարգերում խափանումների ներդրման գործիքներն ու մեթոդները: մինչև!
PS թարգմանչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «.
Source: www.habr.com