Բարև, Հաբր: Ես տասը տարի աջակցում եմ Highload ՏՏ համակարգերին: Ես այս հոդվածում չեմ գրի nginx-ը 1000+ RPS ռեժիմով աշխատելու կարգավորելու խնդիրների կամ այլ տեխնիկական բաների մասին։ Ես կկիսվեմ իմ դիտարկումներով գործընթացներում առկա խնդիրների մասին, որոնք առաջանում են նման համակարգերի աջակցության և շահագործման ընթացքում։
Մոնիտորինգ
Տեխնիկական աջակցությունը չի սպասում, մինչև «Ի՞նչ ինչու... կայքը նորից չի աշխատում» բովանդակությամբ հարցումը կժամանի: Կայքի խափանումից հետո մեկ րոպեի ընթացքում աջակցությունն արդեն պետք է տեսնի խնդիրը և սկսի լուծել այն: Բայց կայքը այսբերգի գագաթն է. Դրա հասանելիությունը առաջիններից մեկն է, որը վերահսկվում է:
Ի՞նչ անել այն իրավիճակի հետ, երբ առցանց խանութի մնացած ապրանքներն այլևս չեն գալիս ERP համակարգից: Թե՞ CRM համակարգը, որը հաշվարկում է հաճախորդների համար զեղչերը, դադարել է արձագանքել: Կայքը կարծես թե աշխատում է: Պայմանական Zabbix-ը ստանում է իր 200 պատասխանը: Հերթապահությունը մոնիթորինգից ծանուցումներ չի ստացել և ուրախությամբ դիտում է «Գահերի խաղի» նոր եթերաշրջանի առաջին դրվագը։
Մոնիտորինգը հաճախ սահմանափակվում է միայն հիշողության, RAM-ի և սերվերի պրոցեսորի ծանրաբեռնվածության չափմամբ: Բայց բիզնեսի համար շատ ավելի կարևոր է ապրանքի հասանելիությունը կայքում: Կլաստերում մեկ վիրտուալ մեքենայի պայմանական ձախողումը կհանգեցնի նրան, որ տրաֆիկը կդադարի գնալ դեպի այն, և այլ սերվերների բեռը կավելանա: Ընկերությունը գումար չի կորցնի.
Հետևաբար, բացի սերվերների վրա օպերացիոն համակարգերի տեխնիկական պարամետրերի մոնիտորինգից, դուք պետք է կարգավորեք բիզնեսի չափումները: Չափումներ, որոնք ուղղակիորեն ազդում են փողի վրա: Տարբեր փոխազդեցություններ արտաքին համակարգերի հետ (CRM, ERP և այլն): Որոշակի ժամանակահատվածի պատվերների քանակը: Հաճախորդի հաջող կամ անհաջող թույլտվություններ և այլ չափումներ:
Փոխազդեցություն արտաքին համակարգերի հետ
Ցանկացած կայք կամ բջջային հավելված, որի տարեկան շրջանառությունը կազմում է ավելի քան մեկ միլիարդ ռուբլի, փոխազդում է արտաքին համակարգերի հետ: Սկսած վերը նշված CRM-ից և ERP-ից և վերջացրած վաճառքի տվյալների փոխանցումով արտաքին Big Data համակարգ՝ գնումները վերլուծելու և հաճախորդին առաջարկելու ապրանք, որը նա անպայման կգնի (իրականում՝ ոչ): Յուրաքանչյուր նման համակարգ ունի իր աջակցությունը: Եվ հաճախ այդ համակարգերի հետ շփումը ցավ է պատճառում։ Հատկապես, երբ խնդիրը գլոբալ է, և պետք է այն վերլուծել տարբեր համակարգերում։
Որոշ համակարգեր իրենց ադմինիստրատորների համար տրամադրում են հեռախոսահամար կամ հեռագիր: Ինչ-որ տեղ պետք է նամակներ գրել մենեջերներին կամ գնալ այս արտաքին համակարգերի սխալների հետագծողներին: Նույնիսկ մեկ խոշոր ընկերության համատեքստում, տարբեր համակարգեր հաճախ գործում են տարբեր կիրառական հաշվառման համակարգերում: Երբեմն անհնար է դառնում հետևել հայտի կարգավիճակին: Դուք հարցում եք ստանում մեկ պայմանական Ժիրայում: Այնուհետև այս առաջին Ժիրայի մեկնաբանության մեջ դուք հղում եք դնում մեկ այլ Ժիրայի խնդրին: Հավելվածի երկրորդ Ժիրայում ինչ-որ մեկն արդեն մեկնաբանություն է գրում, որ դուք պետք է զանգահարեք պայմանական ադմին Անդրեյին՝ խնդիրը լուծելու համար: Եվ այսպես շարունակ:
Այս խնդրի լավագույն լուծումը կլինի հաղորդակցության համար մեկ տարածություն ստեղծելը, օրինակ՝ Slack-ում: Արտաքին համակարգերի շահագործման գործընթացի բոլոր մասնակիցներին միանալու հրավիրում: Եվ նաև մեկ թրեքեր՝ հավելվածները չկրկնելու համար։ Ծրագրերին պետք է հետևել մեկ տեղում՝ սկսած մոնիտորինգի ծանուցումներից մինչև ապագա սխալների լուծումների արդյունքը: Դուք կասեք, որ դա անիրատեսական է, և պատմականորեն պատահել է, որ մենք աշխատում ենք մի թրեքերում, իսկ նրանք՝ մյուսում։ Հայտնվեցին տարբեր համակարգեր, նրանք ունեին իրենց ինքնավար ՏՏ թիմերը։ Ես համաձայն եմ, և, հետևաբար, խնդիրը պետք է լուծվի վերևից՝ CIO-ի կամ արտադրանքի սեփականատիրոջ մակարդակով:
Յուրաքանչյուր համակարգ, որի հետ դուք շփվում եք, պետք է աջակցություն տրամադրի որպես ծառայություն՝ հստակ SLA-ով՝ խնդիրները առաջնահերթությամբ լուծելու համար: Եվ ոչ այն ժամանակ, երբ պայմանական ադմին Անդրեյը ձեզ համար րոպե ունի։
Անջատված մարդ
Արդյո՞ք որևէ նախագծում (կամ արտադրանքում) ունե՞ն մարդ, ում արձակուրդ գնալը ջղաձգություն է առաջացնում վերադասի մոտ: Սա կարող է լինել devops ինժեներ, վերլուծաբան կամ մշակող: Ի վերջո, միայն devops-ի ինժեները գիտի, թե որ սերվերներում ինչ կոնտեյներներ են տեղադրված, ինչպես կարելի է վերագործարկել կոնտեյները խնդրի դեպքում, և ընդհանրապես, առանց նրա որևէ բարդ խնդիր չի լուծվում։ Վերլուծաբանը միակն է, ով գիտի, թե ինչպես է աշխատում ձեր բարդ մեխանիզմը։ Որ տվյալների հոսքերը ուր են գնում: Հարցումների ո՞ր պարամետրերով, որ ծառայություններին մենք պատասխան կստանանք:
Ո՞վ արագ կհասկանա, թե ինչու են տեղեկամատյաններում սխալներ և անհապաղ շտկելու արտադրանքի կարևոր սխալը: Իհարկե, նույն մշակողը: Կան ուրիշներ, բայց չգիտես ինչու միայն նա է հասկանում, թե ինչպես են աշխատում համակարգի տարբեր մոդուլները։
Այս խնդրի արմատը փաստաթղթերի բացակայությունն է. Ի վերջո, եթե նկարագրված լինեին ձեր համակարգի բոլոր ծառայությունները, ապա առանց վերլուծաբանի հնարավոր կլիներ լուծել խնդիրը: Եթե Դևոպսը մի քանի օր դուրս բերեց իր զբաղված գրաֆիկից և նկարագրեր բոլոր սերվերները, ծառայություններն ու հրահանգները բնորոշ խնդիրների լուծման համար, ապա նրա բացակայության դեպքում խնդիրը կարող էր լուծվել առանց նրա: Արձակուրդի ժամանակ ձեզ հարկավոր չէ արագ ավարտել ձեր գարեջուրը լողափում և փնտրել wi-fi խնդիրը լուծելու համար:
Աջակցող անձնակազմի իրավասությունը և պատասխանատվությունը
Խոշոր նախագծերում ընկերությունները չեն խնայում կառուցապատողների աշխատավարձերը: Նրանք փնտրում են թանկ միջին կամ ավագ մարդկանց նմանատիպ նախագծերից: Աջակցությամբ իրավիճակը մի փոքր այլ է։ Նրանք ամեն կերպ փորձում են նվազեցնել այդ ծախսերը։ Ընկերությունները վարձում են երեկվա «Էնիկեյի» էժան աշխատողներին և համարձակորեն գնում են մարտի: Այս ռազմավարությունը հնարավոր է, եթե մենք խոսում ենք Զելենոգրադում գտնվող գործարանի այցեքարտի կայքի մասին:
Եթե մենք խոսում ենք մեծ առցանց խանութի մասին, ապա ամեն ժամ պարապուրդն ավելի թանկ արժե, քան Enikey-ի ադմինիստրատորի ամսական աշխատավարձը։ Որպես ելակետ վերցնենք 1 միլիարդ ռուբլի տարեկան շրջանառությունը։ Սա ցանկացած առցանց խանութի նվազագույն շրջանառությունն է վարկանիշից . Բաժանեք այս գումարը տարեկան ժամերի քանակով և ստացեք ավելի քան 100 ռուբլի զուտ կորուստ: Եվ եթե չեք հաշվում գիշերային ժամերը, ապա կարող եք ապահով կերպով կրկնապատկել գումարը:
Բայց փողը գլխավորը չէ, չէ՞: (ոչ, իհարկե գլխավորը) Կան նաև հեղինակության կորուստներ։ Հայտնի առցանց խանութի անկումը կարող է առաջացնել ինչպես կարծիքների ալիք սոցիալական ցանցերում, այնպես էլ թեմատիկ լրատվամիջոցներում հրապարակումներ։ Իսկ խոհանոցում ընկերների խոսակցությունները «այնտեղ ոչինչ մի գնիր, նրանց կայքը միշտ խափանված է» ոճով ամենևին չափելի չէ։
Հիմա պատասխանատվության մասին. Իմ պրակտիկայում եղել է դեպք, երբ հերթապահ ադմինը ժամանակին չի արձագանքել մոնիտորինգի համակարգից կայքի անհասանելիության մասին ծանուցմանը։ Հաճելի ամառային ուրբաթ երեկոյան Մոսկվայի հայտնի առցանց խանութի կայքը հանգիստ պառկած էր։ Շաբաթ առավոտյան այս կայքի արտադրանքի մենեջերը չհասկացավ, թե ինչու կայքը չի բացվում, և լռություն էր տիրում Slack-ի աջակցության և հրատապ ծանուցումների չաթերում։ Նման սխալը մեզ վրա նստեց վեցանիշ գումար, իսկ այս հերթապահը իր աշխատանքը։
Պատասխանատվությունը դժվար զարգացնելուն հմտություն է: կա՛մ մարդ ունի, կա՛մ չունի։ Ուստի հարցազրույցների ժամանակ դրա առկայությունը փորձում եմ նույնացնել տարբեր հարցերի հետ, որոնք անուղղակիորեն ցույց են տալիս, թե արդյոք մարդը սովոր է պատասխանատվություն ստանձնել։ Եթե մարդը պատասխանում է, որ բուհ է ընտրել, որովհետև ծնողներն են այդպես ասել, կամ փոխում է աշխատանքը, քանի որ կինն ասում է, որ բավականաչափ չի վաստակում, ապա ավելի լավ է նման մարդկանց հետ չխառնվել։
Փոխգործակցություն զարգացման թիմի հետ
Երբ օգտագործողները շահագործման ընթացքում բախվում են արտադրանքի հետ կապված պարզ խնդիրների, աջակցությունն ինքնուրույն լուծում է դրանք: Փորձում է վերարտադրել խնդիրը, վերլուծում է տեղեկամատյանները և այլն։ Բայց ի՞նչ անել, երբ արտադրանքի մեջ վրիպակ է հայտնվում: Այս դեպքում աջակցությունը հանձնարարում է առաջադրանքը ծրագրավորողներին և հենց այստեղ է սկսվում զվարճանքը:
Մշակողները մշտապես ծանրաբեռնված են: Նրանք ստեղծում են նոր առանձնահատկություններ: Վաճառքի հետ կապված սխալների շտկումն ամենահետաքրքիր գործունեությունը չէ: Վերջնաժամկետները մոտենում են հաջորդ սպրինտը ավարտելու համար: Հետո գալիս են աջակցության տհաճ մարդիկ և ասում. «Անհապաղ թողեք ամեն ինչ, մենք խնդիրներ ունենք»։ Նման առաջադրանքների առաջնահերթությունը նվազագույն է։ Հատկապես, երբ խնդիրը ամենակարևորը չէ, և կայքի հիմնական գործառույթն աշխատում է, և երբ թողարկման մենեջերը չի վազում ուռած աչքերով և չի գրում.
Նորմալ կամ ցածր առաջնահերթություն ունեցող խնդիրները տեղափոխվում են թողարկումից թողարկում: «Ե՞րբ է ավարտվելու առաջադրանքը» հարցին. Դուք կստանաք պատասխաններ հետևյալ ոճով. «Կներեք, հիմա շատ առաջադրանքներ կան, հարցրեք ձեր թիմի ղեկավարներին կամ ազատեք մենեջերին»:
Արտադրողականության խնդիրներն ավելի առաջնահերթություն են ստանում, քան նոր հնարավորություններ ստեղծելը: Վատ ակնարկները երկար սպասել չեն տա, եթե օգտատերերն անընդհատ սխալներ են հանդիպում: Վնասված հեղինակությունը դժվար է վերականգնել։
Մշակման և աջակցության միջև փոխգործակցության հարցերը լուծվում են DevOps-ի կողմից: Այս հապավումը հաճախ օգտագործվում է կոնկրետ անձի տեսքով, ով օգնում է ստեղծել փորձարկման միջավայրեր զարգացման համար, կառուցում է CICD խողովակաշարեր և արագորեն փորձարկված կոդը ներմուծում արտադրություն: DevOps-ը ծրագրային ապահովման մշակման մոտեցում է, երբ գործընթացի բոլոր մասնակիցները սերտորեն շփվում են միմյանց հետ և օգնում արագ ստեղծել և թարմացնել ծրագրային արտադրանքներն ու ծառայությունները: Ես նկատի ունեմ վերլուծաբաններին, մշակողներին, փորձարկողներին և աջակցությանը:
Այս մոտեցմամբ աջակցությունն ու զարգացումը տարբեր գերատեսչություններ չեն՝ իրենց նպատակներով և խնդիրներով: Զարգացումը ներգրավված է շահագործման մեջ և հակառակը: Բաշխված թիմերի հայտնի արտահայտությունը. «Խնդիրն իմ կողմը չէ» այլևս այդքան հաճախ չի հայտնվում չաթերում, և վերջնական օգտատերերը դառնում են մի փոքր ավելի երջանիկ:
Source: www.habr.com