2019 թվականն է, և մենք դեռ չունենք ստանդարտ լուծում Kubernetes-ում տեղեկամատյանների ագրեգացման համար: Այս հոդվածում մենք կցանկանայինք, օգտագործելով իրական պրակտիկայի օրինակները, կիսվել մեր որոնումներով, հանդիպած խնդիրներով և դրանց լուծումներով:
Այնուամենայնիվ, նախ, ես վերապահում կանեմ, որ տարբեր հաճախորդներ շատ տարբեր բաներ են հասկանում՝ հավաքելով տեղեկամատյանները.
- ինչ-որ մեկը ցանկանում է տեսնել անվտանգության և աուդիտի տեղեկամատյանները.
- ինչ-որ մեկը - ամբողջ ենթակառուցվածքի կենտրոնացված անտառահատում.
- իսկ ոմանց համար բավական է հավաքել միայն հավելվածների տեղեկամատյանները՝ բացառելով, օրինակ, հավասարակշռողներին։
Ստորև ներկայացնում ենք ստորև բերված հատվածը այն մասին, թե ինչպես ենք մենք իրականացրել տարբեր «ցանկությունների ցուցակներ» և ինչ դժվարությունների ենք հանդիպել:
Տեսություն՝ անտառահատման գործիքների մասին
Հատման համակարգի բաղադրիչների նախապատմություն
Փայտահատումները երկար ճանապարհ են անցել, ինչի արդյունքում մշակվել են գերանների հավաքագրման և վերլուծության մեթոդոլոգիաները, ինչը մենք այսօր օգտագործում ենք: Դեռևս 1950-ականներին Fortran-ը ներկայացրեց ստանդարտ մուտքային/ելքային հոսքերի անալոգը, որն օգնեց ծրագրավորողին կարգաբերել իր ծրագիրը: Սրանք առաջին համակարգչային տեղեկամատյաններն էին, որոնք հեշտացնում էին այն ժամանակների ծրագրավորողների կյանքը: Այսօր մենք տեսնում ենք դրանցում անտառահատումների համակարգի առաջին բաղադրիչը. տեղեկամատյանների աղբյուրը կամ «արտադրողը»:.
Համակարգչային գիտությունը տեղում չմնաց՝ հայտնվեցին համակարգչային ցանցերը, առաջին կլաստերները... Սկսեցին աշխատել մի քանի համակարգիչներից բաղկացած բարդ համակարգեր։ Այժմ համակարգի ադմինիստրատորները ստիպված էին հավաքել տեղեկամատյանները մի քանի մեքենաներից, և հատուկ դեպքերում նրանք կարող էին ավելացնել OS միջուկի հաղորդագրություններ, եթե անհրաժեշտ լիներ հետաքննել համակարգի ձախողումը: 2000-ականների սկզբին տպագրվել է գերանների հավաքման կենտրոնացված համակարգերը , որը ստանդարտացրել է remote_syslog-ը: Ահա թե ինչպես է հայտնվել մեկ այլ կարևոր բաղադրիչ. գերան հավաքող և դրանց պահպանումը:
Լոգերի ծավալի ավելացման և վեբ տեխնոլոգիաների համատարած ներդրման հետ մեկտեղ հարց առաջացավ, թե ինչ տեղեկամատյաններ պետք է հարմար կերպով ցուցադրվեն օգտատերերին։ Վահանակի պարզ գործիքները (awk/sed/grep) փոխարինվել են ավելի առաջադեմներով գրանցամատյան դիտողներ - երրորդ բաղադրիչ.
Գերանների ծավալների ավելացման պատճառով մեկ այլ բան էլ պարզ դարձավ՝ գերաններ են պետք, բայց ոչ բոլորը։ Իսկ տարբեր գերանները պահանջում են պահպանման տարբեր մակարդակներ. մի քանիսը կարող են կորչել մեկ օրում, իսկ մյուսները պետք է պահվեն 5 տարի: Այսպիսով, գրանցման համակարգին ավելացվել է տվյալների հոսքերի զտման և ուղղորդման բաղադրիչ. եկեք այն անվանենք զտիչ.
Storage-ը նույնպես մեծ թռիչք է կատարել՝ սովորական ֆայլերից մինչև հարաբերական տվյալների բազաներ, այնուհետև փաստաթղթերի վրա հիմնված պահեստավորում (օրինակ՝ Elasticsearch): Այսպիսով, պահեստը բաժանվեց կոլեկտորից:
Ի վերջո, գերան հասկացությունն ընդլայնվել է դեպի իրադարձությունների մի տեսակ վերացական հոսք, որը մենք ցանկանում ենք պահպանել պատմության համար: Ավելի ճիշտ՝ հետաքննություն անցկացնելու կամ վերլուծական հաշվետվություն կազմելու անհրաժեշտության դեպքում...
Արդյունքում, համեմատաբար կարճ ժամանակահատվածում տեղեկամատյանների հավաքածուն վերածվել է կարևոր ենթահամակարգի, որն իրավամբ կարելի է անվանել Big Data-ի ենթաբաժիններից մեկը։
Եթե ժամանակին սովորական տպագրությունները բավական էին «հատումների համակարգի» համար, ապա այժմ իրավիճակը շատ է փոխվել։
Կուբերնետներ և տեղեկամատյաններ
Երբ Kubernetes-ը եկավ ենթակառուցվածք, դա չշրջանցեց նաև գերանների հավաքման արդեն գոյություն ունեցող խնդիրը։ Որոշ առումներով դա էլ ավելի ցավալի դարձավ. ենթակառուցվածքի հարթակի կառավարումը ոչ միայն պարզեցվեց, այլև միևնույն ժամանակ բարդացավ։ Շատ հին ծառայություններ սկսել են տեղափոխել միկրոսերվիսներ: Տեղեկամատյանների համատեքստում դա արտացոլվում է տեղեկամատյանների աղբյուրների աճող թվով, դրանց հատուկ կյանքի ցիկլով և տեղեկամատյանների միջոցով համակարգի բոլոր բաղադրիչների հարաբերություններին հետևելու անհրաժեշտությամբ...
Նայելով առաջ՝ ես կարող եմ փաստել, որ այժմ, ցավոք, Kubernetes-ի համար չկա ստանդարտացված անտառահատման տարբերակ, որը բարենպաստ կերպով կհամեմատվի բոլոր մյուսների հետ: Համայնքում ամենատարածված սխեմաները հետևյալն են.
- ինչ-որ մեկը բացում է բուրգը ԷՖԿ (Elasticsearch, Fluentd, Kibana);
- ինչ-որ մեկը փորձում է վերջերս թողարկվածը կամ օգտագործում ;
- մեզ (և գուցե ոչ միայն մենք...) Ես մեծ մասամբ գոհ եմ իմ սեփական զարգացումից. ...
Որպես կանոն, մենք օգտագործում ենք հետևյալ փաթեթները K8s կլաստերներում (ինքնակառավարվող լուծումների համար).
- ;
- .
Այնուամենայնիվ, ես չեմ անդրադառնա դրանց տեղադրման և կազմաձևման հրահանգներին: Փոխարենը կկենտրոնանամ նրանց թերությունների և ընդհանուր առմամբ գերանների հետ կապված իրավիճակի մասին ավելի գլոբալ եզրակացությունների վրա։
Կիրառեք տեղեկամատյանների հետ K8-ում
«Ամենօրյա գերաններ», ձեզանից քանի՞սն եք այնտեղ:
Բավականին մեծ ենթակառուցվածքից գերանների կենտրոնացված հավաքագրումը պահանջում է զգալի ռեսուրսներ, որոնք կծախսվեն գերանների հավաքման, պահպանման և մշակման վրա: Տարբեր նախագծերի շահագործման ընթացքում մենք բախվել ենք տարբեր պահանջների և դրանցից բխող գործառնական խնդիրների հետ։
Փորձենք ClickHouse-ը
Եկեք նայենք նախագծի կենտրոնացված պահեստին մի հավելվածով, որը բավականին ակտիվորեն ստեղծում է տեղեկամատյաններ՝ վայրկյանում ավելի քան 5000 տող: Սկսենք աշխատել նրա լոգերի հետ՝ դրանք ավելացնելով ClickHouse-ում։
Հենց որ առավելագույն իրական ժամանակ պահանջվի, ClickHouse-ով 4 միջուկային սերվերն արդեն ծանրաբեռնված կլինի սկավառակի ենթահամակարգի վրա.
Այս տեսակի բեռնումը պայմանավորված է նրանով, որ մենք փորձում ենք հնարավորինս արագ գրել ClickHouse-ում: Եվ տվյալների բազան դրան արձագանքում է սկավառակի բեռնվածության ավելացմամբ, ինչը կարող է առաջացնել հետևյալ սխալները.
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Փաստն այն է, որ ClickHouse-ում (դրանք պարունակում են տեղեկամատյանների տվյալներ) ունեն իրենց սեփական դժվարությունները գրելու գործողությունների ժամանակ: Դրանց մեջ զետեղված տվյալները առաջացնում են ժամանակավոր բաժանում, որն այնուհետև միաձուլվում է հիմնական աղյուսակի հետ: Արդյունքում ձայնագրությունը սկավառակի վրա շատ պահանջկոտ է ստացվում, և այն նաև ենթակա է այն սահմանափակմանը, որի մասին մենք ստացել ենք վերը նշված ծանուցումը. 1 վայրկյանում հնարավոր չէ միավորել 300-ից ավելի ենթաբաժիններ (իրականում սա 300 ներդիր է: վայրկյանում):
Այս պահվածքից խուսափելու համար. հնարավորինս մեծ կտորներով և ոչ ավելի, քան 1 անգամ 2 վայրկյանը մեկ: Այնուամենայնիվ, մեծ պոռթկումներով գրելը հուշում է, որ մենք պետք է ավելի քիչ հաճախակի գրենք ClickHouse-ում: Սա, իր հերթին, կարող է հանգեցնել բուֆերային արտահոսքի և տեղեկամատյանների կորստի: Լուծումը Fluentd բուֆերի ավելացումն է, բայց հետո հիշողության սպառումը նույնպես կաճի:
ՆշումClickHouse-ի հետ մեր լուծման մեկ այլ խնդրահարույց ասպեկտը կապված էր այն փաստի հետ, որ մեր դեպքում (loghouse) բաժանումն իրականացվում է արտաքին աղյուսակների միջոցով։ . Սա հանգեցնում է այն բանի, որ մեծ ժամանակային ընդմիջումներով նմուշառելիս պահանջվում է ավելորդ RAM, քանի որ մետաբլոկը կրկնվում է բոլոր միջնորմներով, նույնիսկ նրանց, որոնք ակնհայտորեն չեն պարունակում անհրաժեշտ տվյալներ: Այնուամենայնիվ, այժմ այս մոտեցումը կարող է ապահով կերպով հնացած հայտարարվել ClickHouse-ի ընթացիկ տարբերակների համար (ք ).
Արդյունքում պարզ է դառնում, որ ոչ բոլոր նախագիծն ունի բավարար ռեսուրսներ ClickHouse-ում իրական ժամանակում տեղեկամատյանները հավաքելու համար (ավելի ճիշտ՝ դրանց բաշխումը տեղին չի լինի)։ Բացի այդ, դուք պետք է օգտագործեք կուտակիչ, որին կանդրադառնանք ավելի ուշ։ Վերը նկարագրված դեպքն իրական է։ Եվ այն ժամանակ մենք չկարողացանք վստահելի և կայուն լուծում առաջարկել, որը կհամապատասխաներ հաճախորդին և թույլ կտա մեզ նվազագույն ուշացումով գերաններ հավաքել...
Ինչ վերաբերում է Elasticsearch-ին:
Հայտնի է, որ Elasticsearch-ը հաղթահարում է ծանրաբեռնվածությունը: Փորձենք նույն նախագծում։ Այժմ բեռնվածքն ունի հետևյալ տեսքը.
Elasticsearch-ը կարողացավ մարսել տվյալների հոսքը, սակայն դրա վրա նման ծավալներ գրելը մեծապես օգտագործում է պրոցեսորը: Սա որոշվում է կլաստերի կազմակերպմամբ։ Տեխնիկապես սա խնդիր չէ, բայց պարզվում է, որ պարզապես գերանների հավաքման համակարգը գործարկելու համար մենք արդեն օգտագործում ենք մոտ 8 միջուկ և համակարգում ունենք լրացուցիչ բարձր բեռնված բաղադրիչ...
Ներքևի գիծ. այս տարբերակը կարող է արդարացված լինել, բայց միայն այն դեպքում, եթե նախագիծը մեծ է, և դրա ղեկավարությունը պատրաստ է զգալի ռեսուրսներ ծախսել ծառահատումների կենտրոնացված համակարգի վրա:
Հետո բնական հարց է առաջանում.
Ի՞նչ տեղեկամատյաններ են իսկապես անհրաժեշտ:
Փորձենք փոխել մոտեցումն ինքնին. տեղեկամատյանները պետք է միաժամանակ տեղեկատվական լինեն և չծածկեն յուրաքանչյուրը իրադարձություն համակարգում։
Ենթադրենք՝ ունենք հաջողված առցանց խանութ։ Ի՞նչ տեղեկամատյաններ են կարևոր: Հնարավորինս շատ տեղեկատվություն հավաքելը, օրինակ, վճարման դարպասից, հիանալի գաղափար է: Բայց արտադրանքի կատալոգում պատկերների կտրատման ծառայության ոչ բոլոր տեղեկամատյաններն են կարևոր մեզ համար. միայն սխալներն ու առաջադեմ մոնիտորինգը բավական են (օրինակ, 500 սխալների տոկոսը, որ առաջացնում է այս բաղադրիչը):
Այսպիսով, մենք եկել ենք այն եզրակացության, որ կենտրոնացված անտառահատումները միշտ չէ, որ արդարացված են. Շատ հաճախ հաճախորդը ցանկանում է հավաքել բոլոր տեղեկամատյանները մեկ տեղում, չնայած իրականում ամբողջ գրանցամատյանից պահանջվում է բիզնեսի համար կարևոր հաղորդագրությունների միայն պայմանական 5%-ը.
- Երբեմն բավական է կարգավորել, ասենք, միայն կոնտեյների մատյանի չափը և սխալների կոլեկցիոները (օրինակ՝ Sentry):
- Սխալի մասին ծանուցումը և մեծ տեղական գրանցամատյանը հաճախ կարող են բավարար լինել միջադեպերը հետաքննելու համար:
- Մենք ունեինք նախագծեր, որոնք բավարարվեցին բացառապես ֆունկցիոնալ թեստերով և սխալների հավաքման համակարգերով: Մշակողին որպես այդպիսին տեղեկամատյաններ պետք չէին. նրանք ամեն ինչ տեսնում էին սխալի հետքերից:
Նկարազարդում կյանքից
Մեկ այլ պատմություն կարող է լավ օրինակ ծառայել։ Մենք հարցում ստացանք մեր հաճախորդներից մեկի անվտանգության թիմից, որն արդեն օգտագործում էր կոմերցիոն լուծում, որը մշակվել էր Kubernetes-ի ներդրումից շատ առաջ:
Անհրաժեշտ էր «ընկերանալ» գերանների հավաքագրման կենտրոնացված համակարգին կորպորատիվ խնդիրների հայտնաբերման սենսորով՝ QRadar-ով: Այս համակարգը կարող է տեղեկամատյաններ ստանալ syslog արձանագրության միջոցով և առբերել դրանք FTP-ից: Այնուամենայնիվ, անմիջապես հնարավոր չեղավ այն ինտեգրել fluentd-ի համար remote_syslog հավելվածին (ինչպես պարզվեց, ). Պարզվեց, որ QRadar-ի տեղադրման հետ կապված խնդիրները եղել են հաճախորդի անվտանգության թիմի կողմից:
Արդյունքում, բիզնեսի համար կարևոր տեղեկամատյանների մի մասը վերբեռնվեց FTP QRadar, իսկ մյուս մասը վերահղվեց հեռավոր syslog-ի միջոցով անմիջապես հանգույցներից: Սրա համար մենք նույնիսկ գրել ենք - միգուցե դա կօգնի ինչ-որ մեկին լուծել նմանատիպ խնդիր... Ստացված սխեմայի շնորհիվ հաճախորդն ինքն է ստացել և վերլուծել կրիտիկական տեղեկամատյանները (օգտագործելով իր սիրելի գործիքները), և մենք կարողացել ենք նվազեցնել անտառահատումների համակարգի արժեքը՝ խնայելով միայն անցած ամիս.
Մեկ այլ օրինակ բավականին ցուցիչ է, թե ինչ չի կարելի անել: Մեր հաճախորդներից մեկը վերամշակման համար յուրաքանչյուր օգտատերից եկող իրադարձություններ, որոնք կազմված են բազմակողմանի չկառուցված արդյունք տեղեկատվություն գրանցամատյանում: Ինչպես կարող եք կռահել, նման տեղեկամատյանները չափազանց անհարմար էին և՛ կարդալու, և՛ պահելու համար:
Տեղեկամատյանների չափորոշիչներ
Նման օրինակները հանգեցնում են այն եզրակացության, որ լոգերի հավաքման համակարգ ընտրելուց բացի, անհրաժեշտ է նաև ինքնուրույն նախագծել տեղեկամատյանները! Ի՞նչ պահանջներ կան այստեղ:
- Գրանցամատյանները պետք է լինեն մեքենայաընթեռնելի ձևաչափով (օրինակ՝ JSON):
- Տեղեկամատյանները պետք է լինեն կոմպակտ և հնարավորություն ունենան փոխել գրանցման աստիճանը՝ հնարավոր խնդիրները վերացնելու համար: Միևնույն ժամանակ, արտադրական միջավայրերում դուք պետք է գործարկեք այնպիսի համակարգեր, ինչպիսիք են անտառահատումները զգուշացում կամ սխալ.
- Գրանցամատյանները պետք է նորմալացվեն, այսինքն՝ log-ի օբյեկտում բոլոր տողերը պետք է ունենան դաշտի նույն տեսակը։
Չկառուցված տեղեկամատյանները կարող են հանգեցնել տեղեկամատյանների պահեստում բեռնման և դրանց մշակման ամբողջական դադարեցման հետ կապված խնդիրների: Որպես օրինակ, ահա 400 սխալի օրինակ, որը շատերը անպայման հանդիպել են սահուն տեղեկամատյաններում.
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Սխալը նշանակում է, որ դուք պատրաստի քարտեզագրմամբ ուղարկում եք դաշտ, որի տեսակն անկայուն է: Ամենապարզ օրինակը nginx log-ի դաշտն է՝ փոփոխականով $upstream_status. Այն կարող է պարունակել կամ թիվ կամ տող: Օրինակ:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Տեղեկամատյանները ցույց են տալիս, որ 10.100.0.10 սերվերը պատասխանել է 404 սխալով, և հարցումն ուղարկվել է մեկ այլ բովանդակության պահեստ: Արդյունքում, տեղեկամատյաններում արժեքը դարձավ հետևյալը.
"upstream_response_time": "0.001, 0.007"
Այս իրավիճակն այնքան սովորական է, որ նույնիսկ արժանի է առանձին .
Ինչ վերաբերում է հուսալիությանը:
Կան ժամանակներ, երբ բոլոր տեղեկամատյանները առանց բացառության կենսական նշանակություն ունեն: Եվ դրա հետ մեկտեղ, վերը առաջարկված/քննարկված K8-ների համար տեղեկամատյանների հավաքագրման բնորոշ սխեմաները խնդիրներ ունեն:
Օրինակ, fluentd-ը չի կարող կարճատև բեռնարկղերից գերաններ հավաքել: Մեր նախագծերից մեկում տվյալների բազայի միգրացիոն կոնտեյները ապրեց 4 վայրկյանից պակաս, այնուհետև ջնջվեց՝ ըստ համապատասխան անոտացիայի.
"helm.sh/hook-delete-policy": hook-succeeded
Այդ պատճառով միգրացիայի կատարման մատյանը չի ներառվել պահեստում: Քաղաքականությունը կարող է օգնել այս դեպքում։ before-hook-creation.
Մեկ այլ օրինակ է Docker log-ի ռոտացիան: Ենթադրենք կա հավելված, որն ակտիվորեն գրում է լոգերի վրա։ Նորմալ պայմաններում մեզ հաջողվում է մշակել բոլոր տեղեկամատյանները, բայց հենց որ խնդիր հայտնվի, օրինակ, ինչպես վերը նկարագրված է սխալ ձևաչափով, մշակումը դադարում է, և Docker-ը պտտում է ֆայլը։ Արդյունքն այն է, որ բիզնեսի համար կարևոր տեղեկամատյանները կարող են կորչել:
Ահա թե ինչու կարևոր է առանձնացնել լոգերի հոսքերը, ներկառուցելով ամենաարժեքավորներն անմիջապես հավելվածի մեջ ուղարկելը՝ դրանց անվտանգությունն ապահովելու համար: Բացի այդ, ավելորդ չէր լինի մի քանիսը ստեղծել գերանների «կուտակիչ»:, որը կարող է գոյատևել պահեստի կարճատև անհասանելիության պատճառով՝ պահպանելով կարևոր հաղորդագրությունները:
Ի վերջո, մենք չպետք է մոռանանք դա Կարևոր է պատշաճ կերպով վերահսկել ցանկացած ենթահամակարգ. Հակառակ դեպքում, հեշտ է բախվել մի իրավիճակի, երբ fluentd-ը գտնվում է վիճակում CrashLoopBackOff և ոչինչ չի ուղարկում, և դա խոստանում է կարևոր տեղեկատվության կորուստ:
Արդյունքները
Այս հոդվածում մենք չենք նայում SaaS լուծումներին, ինչպիսին է Datadog-ը: Այստեղ նկարագրված խնդիրներից շատերն արդեն այս կամ այն կերպ լուծվել են տեղեկամատյանների հավաքման մեջ մասնագիտացած առևտրային ընկերությունների կողմից, բայց ոչ բոլորը կարող են օգտագործել SaaS տարբեր պատճառներով: (հիմնականները ծախսերն են և համապատասխանությունը 152-FZ-ին).
Կենտրոնացված մատյանների հավաքումը սկզբում պարզ խնդիր է թվում, բայց դա ամենևին էլ այդպես չէ: Կարևոր է հիշել, որ.
- Միայն կարևոր բաղադրիչները պետք է մանրամասն գրանցվեն, մինչդեռ մոնիտորինգը և սխալների հավաքումը կարող են կազմաձևվել այլ համակարգերի համար:
- Արտադրության տեղեկամատյանները պետք է լինեն նվազագույն, որպեսզի ավելորդ բեռ չավելացնեն:
- Տեղեկամատյանները պետք է լինեն մեքենայացված, նորմալացված և խիստ ձևաչափով:
- Իրոք կրիտիկական տեղեկամատյանները պետք է ուղարկել առանձին հոսքով, որը պետք է առանձնացնել հիմնականներից։
- Արժե հաշվի առնել գերանների կուտակիչ, որը կարող է ձեզ փրկել բարձր բեռի պայթյուններից և պահեստի բեռը ավելի միատեսակ դարձնել:
Այս պարզ կանոնները, եթե կիրառվեն ամենուր, թույլ կտան վերը նկարագրված սխեմաներին աշխատել, թեև դրանցում բացակայում են կարևոր բաղադրիչները (մարտկոցը): Եթե դուք հավատարիմ չեք նման սկզբունքներին, ապա առաջադրանքը հեշտությամբ ձեզ և ենթակառուցվածքին կտանի դեպի համակարգի մեկ այլ խիստ բեռնված (և միևնույն ժամանակ անարդյունավետ) բաղադրիչ:
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «.
Source: www.habr.com