Ինչու՞ ինժեներները չեն մտածում հավելվածների մոնիտորինգի մասին:

Ուրախ ուրբաթ բոլորին: Ընկերներ, այսօր շարունակում ենք դասընթացին նվիրված հրապարակումների շարքը «DevOps պրակտիկա և գործիքներ», քանի որ դասընթացի նոր խմբում դասերը կսկսվեն հաջորդ շաբաթվա վերջին։ Այսպիսով, եկեք սկսենք:

Մոնիտորինգն է ուղղակի. Սա հայտնի փաստ է։ Բարձրացրեք Nagios-ը, գործարկեք NRPE-ը հեռակառավարվող համակարգում, կարգավորեք Nagios-ը NRPE TCP 5666 պորտի վրա և դուք ունեք մոնիտորինգ:

Դա այնքան հեշտ է, որ հետաքրքիր չէ: Այժմ դուք ունեք հիմնական չափումներ պրոցեսորի ժամանակի, սկավառակի ենթահամակարգի, RAM-ի համար, որոնք լռելյայն տրամադրվում են Nagios-ին և NRPE-ին: Բայց սա իրականում որպես այդպիսին «մոնիթորինգ» չէ։ Սա դեռ սկիզբն է:

(Սովորաբար նրանք տեղադրում են PNP4Nagios-ը, RRDtool-ը և Thruk-ը, տեղադրում են ծանուցումներ Slack-ում և գնում ուղիղ դեպի nagiosexchange, բայց եկեք դա առայժմ բաց թողնենք):

Լավ մոնիտորինգ իրականում բավականին բարդ է, դուք իսկապես պետք է իմանաք հավելվածի ներքին կառուցվածքը, որը դուք վերահսկում եք:

Դժվա՞ր է մոնիտորինգը:

Ցանկացած սերվեր, լինի դա Linux կամ Windows, ըստ սահմանման որոշակի նպատակի կծառայի: Apache, Samba, Tomcat, ֆայլերի պահեստավորում, LDAP - այս բոլոր ծառայությունները քիչ թե շատ եզակի են մեկ կամ մի քանի առումներով: Յուրաքանչյուրն ունի իր գործառույթը, իր առանձնահատկությունները: Կան չափումներ, KPI (հիմնական կատարողականի ցուցիչներ) ստանալու տարբեր եղանակներ, որոնք ձեզ հետաքրքիր են, երբ սերվերը ծանրաբեռնված է:

Լուսանկարի հեղինակ Լյուկ Չեսսեր մասին Unsplash

(Ես կցանկանայի, որ իմ վահանակները նեոնային կապույտ լինեին - երազկոտ հառաչում է - ... հմմ ...)

Ծառայություններ մատուցող ցանկացած ծրագրակազմ պետք է ունենա չափումներ հավաքելու մեխանիզմ: Apache-ն ունի մոդուլ mod-status, ցուցադրելով սերվերի կարգավիճակի էջը: Nginx-ն ունի - stub_status. Tomcat-ն ունի JMX կամ հատուկ վեբ հավելվածներ, որոնք ցույց են տալիս հիմնական չափումները: MySQL-ն ունի «ցուցադրել գլոբալ կարգավիճակը» հրամանը և այլն:
Այսպիսով, ինչու՞ մշակողները չեն կառուցում նմանատիպ մեխանիզմներ իրենց ստեղծած հավելվածների մեջ:

Արդյո՞ք միայն մշակողները դա անում են:

Չափումների ներդրման նկատմամբ անտարբերության որոշակի մակարդակ չի սահմանափակվում միայն մշակողներով: Ես աշխատում էի ընկերություններում, որտեղ նրանք մշակում էին հավելվածներ՝ օգտագործելով Tomcat-ը և չէին տրամադրում իրենց սեփական ցուցանիշները, ծառայության գործունեության տեղեկամատյանները, բացառությամբ ընդհանուր Tomcat-ի սխալների մատյանների: Որոշ մշակողներ ստեղծում են բազմաթիվ տեղեկամատյաններ, որոնք ոչինչ չեն նշանակում համակարգի ադմինիստրատորի համար, ով բախտ չի վիճակի կարդալ դրանք առավոտյան ժամը 3:15-ին:

Լուսանկարի հեղինակ Թիմ Գուվ մասին Unsplash

Համակարգի ինժեներները, որոնք թույլ են տալիս նման արտադրանքի թողարկումը, նույնպես պետք է որոշակի պատասխանատվություն կրեն իրավիճակի համար: Համակարգի ինժեներներից մի քանիսը ժամանակ կամ հոգատարություն ունեն՝ փորձելու տեղեկամատյաններից իմաստալից չափումներ հանել՝ առանց այդ չափումների համատեքստի և կիրառական գործունեության լույսի ներքո դրանք մեկնաբանելու հնարավորության: Ոմանք չեն հասկանում, թե ինչպես կարող են դրանից օգուտ քաղել, բացի «ինչ-որ բան ներկայումս սխալ է (կամ շուտով կլինի)» ցուցանիշներից։

Չափումների անհրաժեշտության վերաբերյալ մտածողության փոփոխությունը պետք է տեղի ունենա ոչ միայն մշակողների, այլ նաև համակարգերի ինժեներների շրջանում:

Համակարգերի ցանկացած ինժեների համար, ով պետք է ոչ միայն արձագանքի կարևոր իրադարձություններին, այլ նաև ապահովի, որ դրանք տեղի չունենան, չափումների բացակայությունը սովորաբար խոչընդոտ է դա անելու համար:

Այնուամենայնիվ, համակարգերի ինժեներները սովորաբար չեն շտկում ծածկագիրը իրենց ընկերության համար գումար վաստակելու համար: Նրանց պետք են առաջատար ծրագրավորողներ, ովքեր կհասկանան համակարգերի ինժեների պատասխանատվության կարևորությունը խնդիրների բացահայտման, կատարողականի խնդիրների մասին իրազեկվածության բարձրացման և այլնի հարցում:

Սա զարգացնում է բանը

Deops մտածելակերպը նկարագրում է սիներգիան զարգացման (dev) և գործառնական (ops) մտածողության միջև: Ցանկացած ընկերություն, որը հավակնում է «կատարել devops» պետք է.

1. ասելով բաներ, որոնք նրանք, հավանաբար, չեն ասում (նկատի ունենալով The Princess Bride մեմը.
2. Խրախուսեք արտադրանքի շարունակական բարելավման վերաբերմունքը:

Դուք չեք կարող բարելավել ապրանքը և իմանալ, որ այն բարելավվել է, եթե չգիտեք, թե ինչպես է այն ներկայումս աշխատում: Դուք չեք կարող իմանալ, թե ինչպես է աշխատում ապրանքը, եթե չեք հասկանում, թե ինչպես են աշխատում դրա բաղադրիչները, այն ծառայությունները, որոնցից կախված է, դրա հիմնական ցավի կետերն ու խոչընդոտները:
Եթե ​​դուք չեք հետևում պոտենցիալ խոչընդոտներին, դուք չեք կարողանա հետևել «Հինգ ինչու» տեխնիկան հետմահու գրելիս: Դուք չեք կարողանա ամեն ինչ տեղադրել մեկ էկրանին՝ տեսնելու, թե ինչպես է աշխատում ապրանքը կամ իմանալ, թե ինչ տեսք ունի այն «նորմալ և երջանիկ»:

Շարժվեք ձախ, ՁԱԽ, ԵՍ ԱՍԱՑԻ ԼԵԵԵ-

Ինձ համար Devops-ի հիմնական սկզբունքներից մեկը «հերթափոխը ձախ» է: Այս համատեքստում ձախից տեղաշարժը նշանակում է հնարավորության փոփոխություն (ոչ մի պատասխանատվություն, բայց միայն հնարավորություններ) անելու այնպիսի բաներ, որոնց մասին սովորաբար հետաքրքրում են համակարգերի ինժեներները, ինչպիսիք են կատարողականության ցուցանիշների ստեղծումը, տեղեկամատյանների ավելի արդյունավետ օգտագործումը և այլն, Ծրագրաշարի առաքման կյանքի ցիկլի ձախ կողմում:

Լուսանկարի հեղինակ NESA կողմից Makers մասին Unsplash

Ծրագրային ապահովման մշակողները պետք է կարողանան օգտագործել և իմանալ մոնիտորինգի գործիքները, որոնք ընկերությունը օգտագործում է մոնիտորինգ իրականացնելու համար իր բոլոր ձևերով, չափումների, գրանցման, մոնիտորինգի միջերեսներով և, ամենակարևորը, դիտեք, թե ինչպես է իրենց արտադրանքը աշխատում արտադրության մեջ. Դուք չեք կարող ծրագրավորողներին ստիպել ջանքեր և ժամանակ ներդնել մոնիտորինգի համար, քանի դեռ նրանք չեն կարող տեսնել չափորոշիչները և ազդել դրանց տեսքի վրա, ինչպես է ապրանքի սեփականատերը դրանք ներկայացնում CTO-ին հաջորդ ճեպազրույցում և այլն:

Կարճ ասած

1. Ձին տար ջուրը: Ցույց տվեք մշակողներին, թե որքան դժվարություններից նրանք կարող են խուսափել իրենց համար, օգնեք նրանց բացահայտել ճիշտ KPI-ներն ու չափիչները իրենց հավելվածների համար, որպեսզի ավելի քիչ գոռգոռոցներ լինեն ապրանքի սեփականատիրոջ կողմից, ում վրա գոռում է CTO-ն: Բերեք դրանք լույսի մեջ, նրբորեն և հանգիստ: Եթե ​​դա չի աշխատում, ապա կաշառեք, սպառնացեք և ստիպեք նրանց կամ արտադրանքի սեփականատիրոջը, որպեսզի հնարավորինս արագ կիրառեն այս ցուցանիշները հավելվածներից, այնուհետև գծեք դիագրամները: Սա դժվար կլինի, քանի որ այն չի դիտարկվի որպես առաջնահերթություն, և արտադրանքի ճանապարհային քարտեզը կունենա բազմաթիվ եկամուտներ ստեղծող ծրագրեր: Հետևաբար, ձեզ հարկավոր կլինի բիզնես գործ՝ ապրանքի մոնիտորինգի իրականացման համար ծախսված ժամանակն ու ծախսերը հիմնավորելու համար:
2. Օգնեք համակարգի ինժեներներին լավ քնել: Ցույց տվեք նրանց, որ թողարկվող ցանկացած ապրանքի համար «եկեք թողարկենք» ստուգաթերթի օգտագործումը լավ բան է: Եվ համոզվելով, որ արտադրության բոլոր հավելվածները ծածկված են չափորոշիչներով, կօգնի ձեզ ավելի լավ քնել գիշերը՝ թույլ տալով ծրագրավորողներին տեսնել, թե ինչն է սխալ և որտեղ: Այնուամենայնիվ, ցանկացած մշակողի, արտադրանքի սեփականատիրոջ կամ CTO-ին նյարդայնացնելու և հիասթափեցնելու ճիշտ միջոցը համառելն ու դիմադրելն է: Այս պահվածքը կազդի ցանկացած ապրանքի թողարկման ամսաթվի վրա, եթե նորից սպասեք մինչև վերջին րոպեն, այնպես որ նորից տեղափոխեք ձախ և հնարավորինս շուտ ներառեք այս խնդիրները ձեր ծրագրի պլանում: Անհրաժեշտության դեպքում ճանապարհ անցեք դեպի արտադրանքի հանդիպումներ: Հագեք կեղծ բեղեր և ֆետեր կամ այլ բան, այն երբեք չի ձախողվի: Հաղորդեք ձեր մտահոգությունները, ցույց տվեք հստակ օգուտներ և ավետարանեք:
3. Համոզվեք, որ ինչպես մշակումը (dev), այնպես էլ գործառնությունները (ops) հասկանում են կարմիր գոտի տեղափոխվող արտադրանքի չափումների իմաստն ու հետևանքը: Ops-ին մի թողեք որպես արտադրանքի առողջության միակ պահապանը, համոզվեք, որ մշակողները նույնպես ներգրավված են (#productsquads):
4. Տեղեկամատյանները հիանալի բան են, բայց չափիչները նույնպես: Միավորեք դրանք և թույլ մի տվեք, որ ձեր գերանները աղբ դառնան անպետքության հսկայական բոցավառ գնդակի մեջ: Բացատրեք և ցույց տվեք ծրագրավորողներին, թե ինչու ոչ ոք չի հասկանա նրանց տեղեկամատյանները, ցույց տվեք նրանց, թե ինչ է առավոտյան ժամը 3:15-ին անօգուտ տեղեկամատյաններին նայելը:

Լուսանկարի հեղինակ Մարկո Հորվաթ մասին Unsplash

Այսքանը: Նոր նյութը կթողարկվի հաջորդ շաբաթ։ Եթե ​​ցանկանում եք ավելին իմանալ դասընթացի մասին, հրավիրում ենք ձեզ բաց օր, որը տեղի կունենա երկուշաբթի օրը։ Իսկ հիմա մենք ավանդաբար սպասում ենք ձեր մեկնաբանություններին։

Source: www.habr.com