Հայտնի է, որ ՀԿԿ-ի իրավասությունը ստուգվում է միայն երկրորդ անգամ, երբ նա կատարում է այդ դերը։ Որովհետև մի բան է մի քանի տարի աշխատել ընկերությունում, զարգանալ դրա հետ և լինելով նույն մշակութային համատեքստում՝ աստիճանաբար ավելի շատ պատասխանատվություն ստանալ: Եվ դա բոլորովին այլ բան է անմիջապես անցնել տեխնիկական տնօրենի պաշտոնին մի ընկերությունում, որն ունի ժառանգական ուղեբեռ և մի շարք խնդիրներ, որոնք կոկիկորեն ծածկված են գորգի տակ:

Այս առումով Լեոն Ֆայրի փորձը, որը նա կիսվել է DevOpsConf, ոչ թե եզակի, բայց բազմապատկված իր փորձով և տարբեր դերերի քանակով, որոնք նա հասցրել է փորձել 20 տարվա ընթացքում, շատ օգտակար է։ Ներքևում ներկայացված է 90 օրվա ընթացքում տեղի ունեցած իրադարձությունների ժամանակագրությունը և բազմաթիվ պատմություններ, որոնց վրա ծիծաղելը հաճելի է, երբ դրանք պատահում են ուրիշի հետ, բայց որոնք այնքան էլ հաճելի չէ անձամբ հանդիպելը:

Լեոն շատ գունեղ է խոսում ռուսերեն, այնպես որ, եթե ունեք 35-40 րոպե, խորհուրդ եմ տալիս դիտել տեսանյութը։ Տեքստային տարբերակը՝ ժամանակ խնայելու համար ստորև:

Զեկույցի առաջին տարբերակը մարդկանց և գործընթացների հետ աշխատանքի լավ կառուցվածքային նկարագրություն էր, որը պարունակում էր օգտակար առաջարկություններ: Բայց նա չփոխանցեց այն բոլոր անակնկալները, որոնք հանդիպեցին ճանապարհին։ Հետևաբար, ես փոխեցի ձևաչափը և ներկայացրի նոր ընկերությունում իմ առջև առաջացած խնդիրները և դրանց լուծման մեթոդները ժամանակագրական կարգով:

Մեկ ամիս առաջ

Ինչպես շատ լավ պատմություններ, այս մեկն էլ սկսվեց ալկոհոլից: Մենք ընկերներով նստած էինք բարում, և ինչպես և սպասվում էր ՏՏ ոլորտի մասնագետների շրջանում բոլորը լաց էին լինում իրենց խնդիրների մասին։ Նրանցից մեկը նոր էր փոխել աշխատանքը և խոսում էր տեխնոլոգիայի, մարդկանց և թիմի հետ ունեցած իր խնդիրների մասին: Որքան շատ էի լսում, այնքան ավելի շատ էի հասկանում, որ նա պետք է ինձ աշխատանքի ընդունի, քանի որ սրանք խնդիրների տեսակներն են, որոնք ես լուծում եմ վերջին 15 տարիների ընթացքում։ Ես նրան այդպես ասացի, իսկ հաջորդ օրը հանդիպեցինք աշխատանքային միջավայրում։ Ընկերությունը կոչվում էր Teaching Strategies:

Teaching Strategies-ը շուկայի առաջատարն է շատ փոքր երեխաների համար նախատեսված ուսումնական ծրագրերում` ծնվելուց մինչև երեք տարեկան: Ավանդական «թղթային» ընկերությունն արդեն 40 տարեկան է, իսկ հարթակի թվային SaaS տարբերակը՝ 10 տարեկան, համեմատաբար վերջերս սկսվեց թվային տեխնոլոգիաները ընկերության չափանիշներին հարմարեցնելու գործընթացը։ «Նոր» տարբերակը գործարկվեց 2017 թվականին և գրեթե նման էր հինին, միայն այն ավելի վատ էր աշխատում:

Ամենահետաքրքիրն այն է, որ այս ընկերության երթևեկությունը շատ կանխատեսելի է. օրեցօր, տարեցտարի կարող եք շատ հստակ գուշակել, թե քանի մարդ կգա և երբ: Օրինակ, ժամը 13-ից 15-ը մանկապարտեզների բոլոր երեխաները գնում են քնելու, և ուսուցիչները սկսում են տեղեկատվություն մուտքագրել: Եվ դա տեղի է ունենում ամեն օր, բացի հանգստյան օրերից, քանի որ հանգստյան օրերին գրեթե ոչ ոք չի աշխատում։

Մի փոքր առաջ նայելով՝ նշեմ, որ աշխատանքս սկսել եմ տարեկան ամենաբարձր տրաֆիկի ժամանակաշրջանում, ինչը հետաքրքիր է տարբեր պատճառներով։

Պլատֆորմը, որը թվում էր, թե ընդամենը 2 տարեկան էր, ուներ յուրօրինակ փաթեթ՝ ColdFusion & SQL Server 2008 թ. ColdFusion-ը, եթե չգիտեք, և, ամենայն հավանականությամբ, չգիտեք, ձեռնարկատիրական PHP է, որը դուրս եկավ 90-ականների կեսերին, և այդ ժամանակվանից ես նույնիսկ չեմ լսել դրա մասին: Կային նաև՝ Ruby, MySQL, PostgreSQL, Java, Go, Python: Բայց հիմնական մոնոլիտը աշխատում էր ColdFusion-ի և SQL Server-ի վրա:

Problems

Ինչքան շատ էի խոսում ընկերության աշխատակիցների հետ աշխատանքի և ինչ խնդիրների մասին, այնքան ավելի էի հասկանում, որ խնդիրները միայն տեխնիկական բնույթ չեն կրում։ Լավ, տեխնոլոգիան հին է, և նրանք չաշխատեցին դրա վրա, բայց թիմի և գործընթացների հետ կապված խնդիրներ կային, և ընկերությունը սկսեց դա հասկանալ:

Ավանդաբար, նրանց տեխնոլոգները նստում էին անկյունում և ինչ-որ աշխատանք էին կատարում: Սակայն ավելի ու ավելի շատ բիզնես սկսեցին անցնել թվային տարբերակով: Հետևաբար, վերջին մեկ տարում, երբ ես սկսեցի աշխատել, ընկերությունում հայտնվեցին նորերը՝ տնօրենների խորհուրդ, CTO, CPO և QA տնօրեն։ Այսինքն՝ ընկերությունը սկսել է ներդրումներ կատարել տեխնոլոգիական ոլորտում։

Ծանր ժառանգության հետքերը միայն համակարգերում չէին. Ընկերությունն ուներ ժառանգական գործընթացներ, ժառանգական մարդիկ, ժառանգական մշակույթ: Այս ամենը պետք էր փոխել։ Ես մտածեցի, որ դա հաստատ ձանձրալի չի լինի, և որոշեցի փորձել:

Երկու օր առաջ

Նոր աշխատանք սկսելուց երկու օր առաջ ես ժամանեցի գրասենյակ, լրացրեցի վերջին փաստաթղթերը, հանդիպեցի թիմին և հայտնաբերեցի, որ թիմն այդ պահին պայքարում էր մի խնդրի դեմ: Դա այն էր, որ էջի բեռնման միջին ժամանակը թռավ մինչև 4 վայրկյան, այսինքն ՝ 2 անգամ:

Դատելով գրաֆիկից, ինչ-որ բան ակնհայտորեն տեղի ունեցավ, և պարզ չէ, թե ինչ: Պարզվեց, որ խնդիրը տվյալների կենտրոնի ցանցի հետաձգումն էր. 5 ms latency-ը տվյալների կենտրոնում օգտագործողների համար վերածվեց 2 վրկ-ի: Ես չգիտեի, թե ինչու դա տեղի ունեցավ, բայց ամեն դեպքում հայտնի դարձավ, որ խնդիրը տվյալների կենտրոնում է:

Առաջին օրը

Անցավ երկու օր և իմ աշխատանքի առաջին օրը ես հայտնաբերեցի, որ խնդիրը չի վերացել։

Երկու օրվա ընթացքում օգտատերերի էջերը բեռնվում էին միջինը 4 վայրկյանում։ Հարցնում եմ՝ գտե՞լ են, թե որն է խնդիրը։

-Այո, տոմս ենք բացել։
- ԵՎ?
-Դե մեզ դեռ չեն պատասխանել։

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

Կա մի լավ մեջբերում, որը շատ է համապատասխանում սրան.

«Երբեմն տեխնոլոգիան փոխելու համար պետք է փոխել կազմակերպությունը»:

Բայց քանի որ ես սկսել էի աշխատել տարվա ամենածանրաբեռնված ժամանակաշրջանում, ես ստիպված էի խնդրի լուծման երկու տարբերակները՝ և՛ արագ, և՛ երկարաժամկետ: Եվ սկսեք նրանից, ինչն այժմ կարևոր է:

Երրորդ օրը

Այսպիսով, բեռնումը տեւում է 4 վայրկյան, իսկ 13-ից 15-ը ամենամեծ գագաթները:

Այս ժամանակահատվածի երրորդ օրը ներբեռնման արագությունն այսպիսի տեսք ուներ.

Իմ տեսանկյունից ընդհանրապես ոչինչ չստացվեց։ Բոլորի տեսանկյունից այն սովորականից մի փոքր դանդաղ էր ընթանում։ Բայց դա պարզապես այդպես չի լինում, դա լուրջ խնդիր է:

Ես փորձեցի համոզել թիմին, ինչին նրանք պատասխանեցին, որ իրենց պարզապես ավելի շատ սերվերներ են պետք։ Սա, իհարկե, խնդրի լուծում է, բայց ոչ միշտ է միակն ու ամենաարդյունավետը։ Հարցրի, թե ինչու սերվերները քիչ են, ինչքան է տրաֆիկի ծավալը։ Տվյալների էքստրապոլյացիա արեցի և պարզեցի, որ մենք վայրկյանում մոտավորապես 150 հարցում ունենք, ինչը, սկզբունքորեն, ողջամիտ սահմաններում է:

Բայց մենք չպետք է մոռանանք, որ ճիշտ պատասխան ստանալուց առաջ անհրաժեշտ է ճիշտ հարցը տալ: Իմ հաջորդ հարցն էր. քանի՞ ֆրոնտենդ սերվեր ունենք մենք: Պատասխանը «մի փոքր շփոթեցրեց ինձ». մենք ունեինք 17 frontend սերվեր:

— Ես ամաչում եմ հարցնել, բայց 150-ը բաժանելով 17-ը տալիս է մոտ 8: Ուզում եք ասել, որ յուրաքանչյուր սերվեր թույլ է տալիս վայրկյանում 8 հարցում, իսկ եթե վաղը վայրկյանում 160 հարցում լինի, մեզ ևս 2 սերվեր կպահանջվի:

Իհարկե, մենք լրացուցիչ սերվերների կարիք չունեինք։ Լուծումը հենց կոդի մեջ էր, իսկ երեսին.

var currentClass = classes.getCurrentClass();
return currentClass;

Գործառույթ կար getCurrentClass(), քանի որ կայքում ամեն ինչ աշխատում է դասի համատեքստում, դա ճիշտ է: Եվ այս մեկ ֆունկցիայի համար յուրաքանչյուր էջում կար 200+ հարցում.

Այս կերպ լուծումը շատ պարզ էր, նույնիսկ կարիք չուներ որևէ բան վերաշարադրելու. պարզապես նույն տեղեկատվությունը նորից մի՛ հարցրեք:

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Ես շատ ուրախ էի, քանի որ որոշեցի, որ հենց երրորդ օրը ես գտել եմ հիմնական խնդիրը։ Ինչքան էլ միամիտ էի, բայց սա բազմաթիվ խնդիրներից մեկն էր:

Բայց այս առաջին խնդիրը լուծելով գրաֆիկը շատ ավելի ցածր գցեց:

Միաժամանակ այլ օպտիմալացումներ էինք անում։ Տեսադաշտում շատ բաներ կային, որոնք կարելի էր շտկել։ Օրինակ, նույն երրորդ օրը ես հայտնաբերեցի, որ ի վերջո համակարգում քեշ կա (սկզբում կարծում էի, որ բոլոր հարցումները գալիս են անմիջապես տվյալների բազայից): Երբ ես մտածում եմ քեշի մասին, ես մտածում եմ ստանդարտ Redis-ի կամ Memcached-ի մասին: Բայց ես միակն էի, ով այդպես էր մտածում, քանի որ այդ համակարգը քեշավորման համար օգտագործում էր MongoDB և SQL Server-ը, նույնը, որտեղից պարզապես կարդացվել էին տվյալները:

Օր տասներորդ

Առաջին շաբաթը ես զբաղվեցի խնդիրներով, որոնք պետք է լուծվեին հենց հիմա: Ինչ-որ տեղ երկրորդ շաբաթվա ընթացքում ես առաջին անգամ եկա ստենդափ՝ թիմի հետ շփվելու, տեսնելու, թե ինչ է կատարվում և ինչպես է ընթանում ամբողջ գործընթացը։

Նորից հետաքրքիր բան է հայտնաբերվել. Թիմը բաղկացած էր՝ 18 ծրագրավորողներից; 8 թեստեր; 3 մենեջեր; 2 ճարտարապետ. Եվ նրանք բոլորը մասնակցում էին ընդհանուր ծեսերի, այսինքն՝ ամեն առավոտ 30-ից ավելի հոգի գալիս էին ստենդափի ու պատմում, թե ինչ են արել։ Հասկանալի է, որ հանդիպումը 5 կամ 15 րոպե չի տևել։ Ոչ ոք ոչ մեկին չի լսել, քանի որ բոլորն աշխատում են տարբեր համակարգերի վրա: Այս ձևով ժամում 2-3 տոմս խնամքի համար արդեն լավ արդյունք էր։

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

Արդյունքում ստացանք.

• Ստեն-ափների և հանրահավաքների կրճատում.
• Ապրանքի առարկայական իմացություն:
• Սեփականության զգացում. Երբ մարդիկ անընդհատ շփոթում էին համակարգերի հետ, նրանք գիտեին, որ ուրիշը, ամենայն հավանականությամբ, պետք է աշխատի իրենց սխալների հետ, բայց ոչ իրենք:
• Համագործակցություն խմբերի միջև: Ավելորդ է ասել, որ QA-ն նախկինում շատ չէր շփվում ծրագրավորողների հետ, արտադրանքն արեց իր գործը և այլն: Հիմա նրանք ունեն ընդհանուր պատասխանատվության կետ.

Մենք հիմնականում կենտրոնացել ենք արդյունավետության, արտադրողականության և որակի վրա. սրանք այն խնդիրներն են, որոնք փորձել ենք լուծել թիմի վերափոխմամբ:

Օր տասնմեկերորդ

Թիմի կառուցվածքը փոխելու ընթացքում ես հայտնաբերեցի, թե ինչպես կարելի է հաշվել պատմությունՄիավորները. 1 SP հավասար էր մեկ օրվա, և յուրաքանչյուր տոմս պարունակում էր SP և զարգացման, և QA-ի համար, այսինքն՝ առնվազն 2 SP:

Ինչպե՞ս հայտնաբերեցի սա:

Մենք սխալ ենք գտել՝ հաշվետվություններից մեկում, որտեղ մուտքագրված է այն ժամանակաշրջանի սկզբի և ավարտի ամսաթիվը, որի համար անհրաժեշտ է հաշվետվությունը, վերջին օրը հաշվի չի առնվում։ Այսինքն խնդրանքի մեջ ինչ-որ տեղ ոչ թե <=, այլ պարզապես <: Ինձ ասացին, որ սա երեք Story Points է, այսինքն 3 օր.

Սրանից հետո մենք.

• Story Points վարկանիշային համակարգը վերանայվել է։ Այժմ փոքր սխալների շտկումները, որոնք կարող են արագ փոխանցվել համակարգով, ավելի արագ են հասնում օգտվողին:
• Մենք սկսեցինք միաձուլել համապատասխան տոմսերը մշակման և փորձարկման համար: Նախկինում յուրաքանչյուր տոմս, ամեն մի վրիպակ փակ էկոհամակարգ էր, որը կապված չէր որևէ այլ բանի հետ: Մեկ էջի վրա երեք կոճակ փոխելը կարող էր լինել երեք տարբեր տոմսեր երեք տարբեր ՈԱ գործընթացներով՝ յուրաքանչյուր էջի մեկ ավտոմատացված թեստի փոխարեն:
• Մենք սկսեցինք աշխատել մշակողների հետ աշխատուժի ծախսերը գնահատելու մոտեցման վրա: Մեկ կոճակը փոխելու երեք օրը ծիծաղելի չէ։

Օր քսաներորդ

Ինչ-որ տեղ առաջին ամսվա կեսերին իրավիճակը մի փոքր կայունացավ, ես հասկացա, թե ինչ է հիմնականում կատարվում, և արդեն սկսեցի նայել ապագային և մտածել երկարաժամկետ լուծումների մասին:

Երկարաժամկետ նպատակներ.

• Կառավարվող հարթակ. Յուրաքանչյուր էջում հարյուրավոր հարցումներ լուրջ չեն:
• Կանխատեսելի միտումներ. Պարբերական երթևեկության գագաթնակետեր են եղել, որոնք առաջին հայացքից չեն փոխկապակցվում այլ ցուցանիշների հետ. մենք պետք է հասկանայինք, թե ինչու դա տեղի ունեցավ և սովորեինք կանխատեսել:
• Պլատֆորմի ընդլայնում. Բիզնեսն անընդհատ աճում է, ավելի ու ավելի շատ օգտատերեր են գալիս, իսկ թրաֆիկը մեծանում է։

Նախկինում հաճախ ասում էին. «Եկեք ամեն ինչ վերաշարադրենք [լեզվով/շրջանակով], ամեն ինչ ավելի լավ կաշխատի»։

Շատ դեպքերում դա չի աշխատում, լավ է, եթե վերաշարադրումն ընդհանրապես աշխատի: Հետևաբար, մեզ անհրաժեշտ էր ստեղծել ճանապարհային քարտեզ՝ կոնկրետ ռազմավարություն, որը քայլ առ քայլ ցույց կտա, թե ինչպես են իրագործվելու բիզնեսի նպատակները (ինչ և ինչու ենք մենք անելու), որը.

• արտացոլում է ծրագրի առաքելությունն ու նպատակները.
• առաջնահերթություն է տալիս հիմնական նպատակներին.
• պարունակում է դրանց հասնելու ժամանակացույց:

Մինչ այս ոչ ոք թիմի հետ չէր խոսել որևէ փոփոխության նպատակի մասին։ Սա պահանջում է հաջողության ճիշտ չափումներ: Ընկերության պատմության մեջ առաջին անգամ մենք տեխնիկական խմբի համար սահմանեցինք KPI-ներ, և այդ ցուցանիշները կապված էին կազմակերպչական ցուցանիշների հետ:

Այսինքն՝ կազմակերպչական KPI-ներին աջակցում են թիմերը, իսկ թիմային KPI-ներին՝ առանձին KPI-ներ: Հակառակ դեպքում, եթե տեխնոլոգիական KPI-ները չեն համընկնում կազմակերպչականի հետ, ապա բոլորը վերմակը քաշում են իրենց վրա։

Օրինակ, կազմակերպչական KPI-ներից մեկը նոր ապրանքների միջոցով մեծացնում է շուկայի մասնաբաժինը:

Ինչպե՞ս կարող եք աջակցել ավելի շատ նոր ապրանքներ ունենալու նպատակին:

• Նախ, մենք ցանկանում ենք ավելի շատ ժամանակ հատկացնել նոր ապրանքների մշակմանը, թերությունները շտկելու փոխարեն: Սա տրամաբանական լուծում է, որը հեշտ է չափել։
• Երկրորդ, մենք ցանկանում ենք աջակցել գործարքների ծավալի ավելացմանը, քանի որ որքան մեծ է շուկայի մասնաբաժինը, այնքան շատ օգտվողներ և, համապատասխանաբար, ավելի շատ տրաֆիկ:

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

Այսպիսով, յուրաքանչյուր որոշում, ներառյալ կոդը վերաշարադրելը, պետք է աջակցի այն կոնկրետ նպատակներին, որոնք ընկերությունը դրել է մեզ համար (կազմակերպության աճ, նոր հնարավորություններ, հավաքագրում):

Այս գործընթացի ընթացքում ի հայտ եկավ մի հետաքրքիր բան, որը նորություն դարձավ ոչ միայն տեխնոլոգների, այլ ընդհանրապես ընկերության համար՝ բոլոր տոմսերը պետք է կենտրոնացված լինեն առնվազն մեկ KPI-ի վրա։ Այսինքն, եթե ապրանքն ասում է, որ ցանկանում է նոր գործառույթ ստեղծել, ապա առաջին հարցը պետք է տրվի. «Ի՞նչ KPI է աջակցում այս հատկանիշը»: Եթե ​​ոչ, ապա կներեք, դա ավելորդ հատկանիշ է թվում:

Օր երեսուն

Ամսվա վերջում ես հայտնաբերեցի ևս մեկ նրբերանգ. ոչ ոք իմ Ops թիմից երբևէ չի տեսել այն պայմանագրերը, որոնք մենք կնքում ենք հաճախորդների հետ: Դուք կարող եք հարցնել, թե ինչու պետք է տեսնել կոնտակտները:

• Նախ, քանի որ SLA-ները նշված են պայմանագրերում:
• Երկրորդ, SLA-ները բոլորն էլ տարբեր են: Յուրաքանչյուր հաճախորդ եկավ իր պահանջներով, և վաճառքի բաժինը ստորագրեց առանց նայելու:

Մեկ այլ հետաքրքիր նրբություն այն է, որ խոշոր հաճախորդներից մեկի հետ պայմանագրում նշված է, որ պլատֆորմի կողմից աջակցվող բոլոր ծրագրային տարբերակները պետք է լինեն n-1, այսինքն՝ ոչ թե վերջին, այլ նախավերջին տարբերակը։

Պարզ է, թե որքան հեռու էինք մենք n-1-ից, եթե հարթակը հիմնված էր ColdFusion-ի և SQL Server 2008-ի վրա, որն այլևս չէր աջակցվում հուլիսին:

Օր քառասունհինգերորդ

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

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

Երբ ես դա արեցի, երկու բան գրավեց իմ աչքը.

• QA-ից ծրագրավորողներին վերադարձված տոմսերի բարձր տոկոսը.
• քաշելու հարցումների վերանայումները չափազանց երկար տևեցին:

Խնդիրն այն էր, որ սրանք այնպիսի եզրակացություններ էին, ինչպիսիք են. Թվում է, թե շատ ժամանակ է պահանջվում, բայց մենք վստահ չենք, թե որքան ժամանակ:

«Դուք չեք կարող բարելավել այն, ինչ չեք կարող չափել»:

Ինչպե՞ս հիմնավորել, թե որքան լուրջ է խնդիրը։ Արդյո՞ք դա վատնում է օրեր կամ ժամեր:

Դա չափելու համար մենք մի քանի քայլ ավելացրինք Jira-ի գործընթացին՝ «պատրաստ է մշակմանը» և «պատրաստ է QA»-ին՝ չափելու, թե որքան ժամանակ է սպասվում յուրաքանչյուր տոմս և քանի անգամ է այն վերադառնում որոշակի քայլին:

Մենք նաև ավելացրել ենք «վերանայում»՝ իմանալու համար, թե միջինում քանի տոմս կա վերանայման համար, և դրանից կարող եք սկսել պարել: Մենք ունեինք համակարգային չափումներ, հիմա ավելացրինք նոր չափումներ և սկսեցինք չափել.

• Գործընթացի արդյունավետությունը. կատարումը և պլանավորված/մատուցված:
• Գործընթացի որակը. թերությունների քանակը, թերությունները QA-ից:

Դա իսկապես օգնում է հասկանալ, թե ինչն է լավ, իսկ ինչը՝ ոչ։

Օր հիսուներորդ

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

Սա սպասելի էր, սակայն կրճատումների մասշտաբներն անսպասելի էին։ Օրինակ, մեկ շաբաթվա ընթացքում երկու թիմերի առաջատարներ միաժամանակ հրաժարական են ներկայացրել իրենց կամքով։ Հետեւաբար, ես ստիպված էի ոչ միայն մոռանալ այլ խնդիրների մասին, այլեւ կենտրոնանալ ստեղծելով թիմ. Սա երկար և դժվար լուծելի խնդիր է, բայց դրանով պետք էր զբաղվել, քանի որ ես ուզում էի փրկել մնացած մարդկանց (կամ նրանց մեծ մասին): Պետք էր ինչ-որ կերպ արձագանքել մարդկանց հեռանալու փաստին, որպեսզի թիմում բարոյականությունը պահպանվի։

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

• Հին ու նոր. Մենք պետք է պահենք տարեց մարդկանց, ովքեր կարող են փոխվել և աջակցել առաքելությանը: Բայց միևնույն ժամանակ մենք պետք է նոր արյուն մտցնենք, դրա մասին կխոսենք մի փոքր ուշ։
• Փորձ. Շատ եմ զրուցել լավ պատանիների հետ, ովքեր ցանկանում էին աշխատել մեզ հետ: Բայց ես չկարողացա ընդունել նրանց, քանի որ չկային բավական մեծահասակներ, որոնք կաջակցեին կրտսերներին և հանդես գան որպես դաստիարակներ նրանց համար: Հարկավոր էր նախ հավաքագրել վերին մասը, հետո միայն երիտասարդությունը։
• Գազար և փայտ.

Ես լավ պատասխան չունեմ այն ​​հարցին, թե որն է ճիշտ հավասարակշռությունը, ինչպես պահպանել այն, քանի հոգի պահել և ինչքան մղել։ Սա զուտ անհատական ​​գործընթաց է։

Օր հիսուներորդ

Ես սկսեցի ուշադիր նայել թիմին, որպեսզի հասկանամ, թե ով ունեմ, և ևս մեկ անգամ հիշեցի.

«Խնդիրների մեծ մասը մարդկանց խնդիրներն են».

Ես գտա, որ թիմը որպես այդպիսին՝ և՛ Dev, և՛ Ops, ունի երեք մեծ խնդիր.

• Գործերի ներկա վիճակից գոհունակություն.
• Պատասխանատվության բացակայություն - քանի որ ոչ ոք երբեք չի բերել կատարողների աշխատանքի արդյունքները բիզնեսի վրա ազդելու համար:
• Փոփոխության վախ.

Փոփոխությունները միշտ ձեզ դուրս են բերում ձեր հարմարավետության գոտուց, և որքան երիտասարդներն են, այնքան նրանք չեն սիրում փոփոխությունները, քանի որ չեն հասկանում, թե ինչու և չեն հասկանում, թե ինչպես: Ամենատարածված պատասխանը, որ ես լսել եմ, «Մենք երբեք դա չենք արել»: Ավելին, այն հասավ լիակատար անհեթեթության՝ չնչին փոփոխությունները չէին կարող տեղի ունենալ առանց որևէ մեկի վրդովվելու։ Եվ որքան էլ փոփոխություններն ազդեցին իրենց աշխատանքի վրա, մարդիկ ասում էին. «Չէ, ինչո՞ւ։ Սա չի աշխատի»:

Բայց դուք չեք կարող լավանալ առանց որևէ բան փոխելու:

Մի աշխատակցի հետ բացարձակ անհեթեթ խոսակցություն ունեցա, նրան ասացի օպտիմալացման իմ գաղափարները, ինչին նա ինձ ասաց.
- Օ՜, դու չտեսար, թե ինչ ունեինք անցյալ տարի:
- Եւ ինչ?
«Այժմ դա շատ ավելի լավ է, քան եղել է»:
- Այսինքն, ավելի լավ չի՞ կարող լինել:
- Ինչի համար?

Լավ հարց, ինչու: Կարծես հիմա ավելի լավ է, քան եղել է, ուրեմն ամեն ինչ բավական լավ է: Սա հանգեցնում է պատասխանատվության բացակայության, ինչը սկզբունքորեն միանգամայն նորմալ է։ Ինչպես ասացի, տեխնիկական խումբը մի փոքր շեղում էր: Ընկերությունը կարծում էր, որ դրանք պետք է գոյություն ունենան, բայց ոչ ոք երբեք չափանիշներ չի սահմանել. Տեխնիկական աջակցությունը երբեք չի տեսել SLA-ն, ուստի այն խմբի համար բավականին «ընդունելի» էր (և սա ինձ ամենաշատը ցնցեց).

• 12 վայրկյան բեռնում;
• Յուրաքանչյուր թողարկում 5-10 րոպե ընդհատում;
• Կրիտիկական խնդիրների լուծումը տևում է օրեր և շաբաթներ.
• հերթապահ անձնակազմի բացակայություն 24x7 / հերթապահ.

Ոչ ոք երբևէ չի փորձել հարցնել, թե ինչու մենք դա ավելի լավ չենք անում, և ոչ ոք երբեք չի հասկացել, որ դա չպետք է լինի այսպես:

Որպես բոնուս, կար ևս մեկ խնդիր. փորձի բացակայություն. Ավագները գնացին, իսկ մնացած երիտասարդ թիմը մեծացավ նախկին ռեժիմով ու թունավորվեց դրանից։

Այս ամենի վրա մարդիկ վախենում էին նաև ձախողվելուց և ապաշնորհ երևալուց։ Դա արտահայտվում է նրանով, որ առաջին հերթին նրանք ոչ մի դեպքում օգնություն չխնդրեց. Քանի անգամ ենք մենք խոսել խմբով և անհատապես, և ես ասել եմ. «Հարց տվեք, եթե չգիտեք, թե ինչպես անել»: Ես վստահ եմ իմ վրա և գիտեմ, որ կարող եմ լուծել ցանկացած խնդիր, բայց դրա համար ժամանակ կպահանջվի։ Հետեւաբար, եթե ես կարող եմ հարցնել մեկին, ով գիտի, թե ինչպես լուծել այն 10 րոպեում, ես կհարցնեմ. Որքան քիչ փորձ ունես, այնքան ավելի վախենում ես հարցնել, քանի որ կարծում ես, որ քեզ անգործունակ կհամարեն:

Հարցեր տալու այս վախը դրսևորվում է հետաքրքիր ձևերով։ Օրինակ, դուք հարցնում եք. «Ինչպե՞ս եք անում այս առաջադրանքը»: -Մնաց մի քանի ժամ, ես արդեն ավարտում եմ։ Հաջորդ օրը նորից հարցնում ես, պատասխան ես ստանում, որ ամեն ինչ լավ է, բայց մի խնդիր կար, օրվա վերջ հաստատ պատրաստ կլինի։ Անցնում է ևս մեկ օր, և մինչև քեզ կպցնեն պատին և չստիպեն ինչ-որ մեկի հետ խոսել, սա շարունակվում է: Մարդը ցանկանում է ինքնուրույն լուծել խնդիրը, նա հավատում է, որ եթե ինքը չլուծի այն, դա մեծ ձախողում կլինի։

Ահա թե ինչու մշակողները ուռճացրել են գնահատականները. Այդ նույն անեկդոտն էր, երբ ինչ-որ խնդիր էին քննարկում, ինձ այնպիսի ցուցանիշ էին տալիս, որ ես շատ զարմացա։ Ինչին ինձ ասացին, որ ծրագրավորողի գնահատականներում ծրագրավորողը ներառում է այն ժամանակը, երբ տոմսը կվերադարձվի QA-ից, քանի որ այնտեղ սխալներ կգտնեն, և այն ժամանակը, որը կպահանջվի PR-ի համար, և այն ժամանակ, երբ այն մարդիկ, ովքեր պետք է վերանայեն: այն զբաղված կլինի, այսինքն՝ ամեն ինչ, ինչ հնարավոր է։

Երկրորդ՝ մարդիկ, ովքեր վախենում են ապաշնորհ երեւալուց գերվերլուծել. Երբ դուք ասում եք, թե կոնկրետ ինչ է պետք անել, սկսվում է. «Ոչ, իսկ եթե մտածենք դրա մասին այստեղ»: Այս առումով մեր ընկերությունը եզակի չէ, սա ստանդարտ խնդիր է երիտասարդների համար։

Ի պատասխան՝ ես ներկայացրեցի հետևյալ պրակտիկաները.

• Կանոն 30 րոպե. Եթե ​​դուք չեք կարող լուծել խնդիրը կես ժամում, խնդրեք ինչ-որ մեկին օգնել: Սա աշխատում է տարբեր աստիճանի հաջողությամբ, քանի որ մարդիկ դեռ չեն հարցնում, բայց գոնե գործընթացը սկսվել է:
• Վերացրեք ամեն ինչ, բացի էությունից, առաջադրանքը կատարելու վերջնաժամկետը գնահատելիս, այսինքն՝ հաշվի առեք միայն թե որքան ժամանակ կպահանջվի ծածկագիրը գրելու համար։
• Ամբողջ կյանքի ընթացքում ուսուցում նրանց համար, ովքեր գերվերլուծում են. Դա ուղղակի մշտական ​​աշխատանք է մարդկանց հետ:

Վաթսուներորդ օր

Մինչ ես այս ամենն էի անում, ժամանակն էր պարզել բյուջեն։ Իհարկե, ես շատ հետաքրքիր բաներ գտա այնտեղ, որտեղ մենք ծախսեցինք մեր գումարը։ Օրինակ, մենք ունեինք մի ամբողջ դարակ առանձին տվյալների կենտրոնում մեկ FTP սերվերով, որն օգտագործվում էր մեկ հաճախորդի կողմից: Պարզվեց, որ «... տեղափոխվեցինք, բայց նա այդպես մնաց, մենք նրան չփոխեցինք»։ 2 տարի առաջ էր։

Առանձնահատուկ հետաքրքրություն էր ներկայացնում ամպային ծառայությունների օրինագիծը։ Կարծում եմ, որ բարձր ամպային օրինագծի հիմնական պատճառը ծրագրավորողներն են, ովքեր իրենց կյանքում առաջին անգամ ունեն անսահմանափակ մուտք դեպի սերվերներ: Նրանք կարիք չունեն հարցնել. «Խնդրում եմ, տվեք ինձ փորձնական սերվեր», նրանք կարող են ինքնուրույն վերցնել այն: Բացի այդ, ծրագրավորողները միշտ ցանկանում են կառուցել այնպիսի թույն համակարգ, որ Facebook-ը և Netflix-ը նախանձեն:

Բայց մշակողները չունեն սերվերներ ձեռք բերելու փորձ և սերվերների պահանջվող չափը որոշելու հմտություն, քանի որ նախկինում դա նրանց պետք չէր։ Եվ նրանք սովորաբար այնքան էլ չեն հասկանում մասշտաբայնության և կատարողականի տարբերությունը:

Գույքագրման արդյունքներ.

• Մենք թողեցինք նույն տվյալների կենտրոնը:
• Մենք խզել ենք պայմանագիրը 3 լոգ ծառայությունների հետ։ Քանի որ մենք ունեինք դրանցից 5-ը. յուրաքանչյուր ծրագրավորող, ով սկսեց խաղալ ինչ-որ բանի հետ, վերցրեց նորը:
• Անջատվել է 7 AWS համակարգ։ Կրկին ոչ ոք չդադարեցրեց մեռած նախագծերը, նրանք բոլորը շարունակեցին աշխատել:
• Ծրագրային ապահովման ծախսերը կրճատվել են 6 անգամ։

Օր յոթանասունհինգերորդ

Անցավ ժամանակ, և երկուսուկես ամսից ես պետք է հանդիպեի տնօրենների խորհրդի հետ։ Մեր տնօրենների խորհուրդը մյուսներից ոչ լավն է, ոչ վատը, ինչպես բոլոր տնօրենների խորհուրդները, նա ուզում է ամեն ինչ իմանալ: Մարդիկ գումար են ներդնում և ցանկանում են հասկանալ, թե մեր արածը որքանով է տեղավորվում սահմանված KPI-ների մեջ:

Տնօրենների խորհուրդն ամեն ամիս ստանում է բազմաթիվ տեղեկություններ՝ օգտատերերի թիվը, նրանց աճը, ինչ ծառայություններ և ինչպես են նրանք օգտագործում, կատարողականություն և արտադրողականություն և վերջապես՝ էջի բեռնման միջին արագություն։

Միակ խնդիրն այն է, որ ես հավատում եմ, որ միջինը մաքուր չարիք է։ Բայց տնօրենների խորհրդին դա շատ դժվար է բացատրել։ Նրանք սովոր են գործել ագրեգացված թվերով, այլ ոչ թե, օրինակ, վայրկյանում բեռնման ժամանակների տարածումով։

Այս առումով կային մի քանի հետաքրքիր կետեր. Օրինակ, ես ասացի, որ մենք պետք է բաժանենք տրաֆիկը առանձին վեբ սերվերների միջև՝ կախված բովանդակության տեսակից:

Այսինքն՝ ColdFusion-ն անցնում է Jetty-ով և nginx-ով և գործարկում է էջերը։ Իսկ պատկերները, JS-ը և CSS-ն անցնում են առանձին nginx-ով՝ իրենց սեփական կոնֆիգուրացիաներով: Սա բավականին ստանդարտ պրակտիկա է, որի մասին ես խոսում եմ գրել է մի երկու տարի առաջ. Արդյունքում նկարները շատ ավելի արագ են բեռնվում, և... բեռնման միջին արագությունն ավելացել է 200 ms-ով։

Դա տեղի է ունեցել, քանի որ գրաֆիկը կառուցված է Jetty-ի հետ բերվող տվյալների հիման վրա: Այսինքն՝ արագ բովանդակությունը ներառված չէ հաշվարկի մեջ՝ միջին արժեքը ցատկել է։ Սա մեզ համար պարզ էր, մենք ծիծաղեցինք, բայց ինչպե՞ս բացատրենք տնօրենների խորհրդին, թե ինչու մենք ինչ-որ բան արեցինք, և ամեն ինչ վատացավ 12 տոկոսով:

Օր ութսուն հինգերորդ

Երրորդ ամսվա վերջում ես հասկացա, որ կա մի բան, որի վրա բացարձակապես չէի ապավինում՝ ժամանակը։ Այն ամենը, ինչի մասին ես խոսեցի, ժամանակ է պահանջում:

Սա իմ իրական շաբաթական օրացույցն է՝ ընդամենը աշխատանքային շաբաթ, ոչ շատ զբաղված: Ամեն ինչի համար ժամանակը չի բավականացնում։ Հետևաբար, կրկին պետք է հավաքագրեք մարդկանց, ովքեր կօգնեն ձեզ հաղթահարել խնդիրները:

Ամփոփում

Սա դեռ ամենը չէ: Այս պատմության մեջ ես նույնիսկ չեմ հասկացել, թե ինչպես ենք մենք աշխատել արտադրանքի հետ և փորձել համակերպվել ընդհանուր ալիքին, կամ ինչպես ենք մենք ինտեգրել տեխնիկական աջակցությունը կամ ինչպես ենք լուծել այլ տեխնիկական խնդիրներ: Օրինակ, ես շատ պատահաբար իմացա, որ տվյալների բազայի ամենամեծ աղյուսակներում մենք չենք օգտագործում SEQUENCE. Մենք ինքնագրային ֆունկցիա ունենք nextID, և այն չի օգտագործվում գործարքի մեջ:

Եվս մեկ միլիոն նման բաներ կային, որոնց մասին մենք կարող էինք երկար խոսել։ Բայց ամենակարեւորը, որ դեռ պետք է ասել, մշակույթն է։

Մշակույթն է կամ դրա բացակայությունը հանգեցնում է մնացած բոլոր խնդիրների: Մենք փորձում ենք մշակույթ կառուցել, որտեղ մարդիկ.

• չվախենալ ձախողումներից;
• սովորել սխալներից;
• համագործակցել այլ թիմերի հետ;
• նախաձեռնություն ձեռնարկել;
• պատասխանատվություն ստանձնել;
• ողջունել արդյունքը որպես նպատակ;
• տոնում է հաջողությունը.

Սրանով մնացած ամեն ինչ կգա:

Լեոն Ֆայր twitter-ում, facebook իսկ միջին.

Ժառանգության հետ կապված երկու ռազմավարություն կա՝ ամեն գնով խուսափեք դրա հետ աշխատելուց կամ համարձակորեն հաղթահարեք դրա հետ կապված դժվարությունները: Մենք ք DevOpsConf Մենք գնում ենք երկրորդ ճանապարհով՝ փոխելով գործընթացներն ու մոտեցումները։ Միացե՛ք մեզ youtube, փոստային ցուցակում и հեռագիր, և միասին մենք կիրագործենք DevOps մշակույթը։

Source: www.habr.com