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

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

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

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

Մեկ ամիս առաջ

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

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

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

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

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

Problems

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

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

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

Երկու օր առաջ

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

Գրաֆիկից դատելով՝ ակնհայտորեն ինչ-որ բան է տեղի ունեցել, և անհասկանալի է՝ ինչ։ Պարզվեց, որ խնդիրը տվյալների կենտրոնում ցանցային լատենտության մեջ էր. տվյալների կենտրոնում 5 միլիվայրկյան լատենտությունը օգտատերերի համար վերածվեց 2 վայրկյանի։ Թե ինչու է դա տեղի ունեցել, ես չգիտեմ, բայց ամեն դեպքում հայտնի դարձավ, որ խնդիրը տվյալների կենտրոնում է։

Առաջին օրը

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

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

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

Այստեղ ես հասկացա, որ այն ամենը, ինչ ինձ նախկինում ասել էին, ընդամենը սառցաբեկորի գագաթն էր, որի դեմ պետք էր պայքարել։

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

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

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

Երրորդ օրը

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

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

Իմ տեսանկյունից՝ ոչինչ չաշխատեց։ Բոլորի տեսանկյունից՝ այն մի փոքր ավելի դանդաղ աշխատեց, քան սովորաբար։ Բայց դա միայն այդպես չէ, սա լուրջ խնդիր է։

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

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

— Ամաչում եմ հարցնել, 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 տոմս արդեն լավ արդյունք էր։

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

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

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

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

Տասնմեկերորդ օր

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

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

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

Դրանից հետո մենք՝

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

Քսաներորդ օրը

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Երեսուներորդ օր

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

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

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

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

Քառասունհինգերորդ օրը

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

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

Երբ սա արեցի, երկու բան գրավեցին իմ ուշադրությունը.

• որակի ապահովման ստուգումից մշակողներին վերադարձված տոմսերի բարձր տոկոսը։
• Քաշման հայտերի վերանայումները չափազանց երկար էին տևում։

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

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

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

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

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

• Գործընթացի արդյունավետություն. կատարողականը և պլանավորված/իրականացվածը։
• Գործընթացի որակը: թերությունների քանակը, որակի ապահովման ստուգման թերությունները։

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

Հիսուներորդ օր

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

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

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

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

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

Հիսունմեկերորդ օր

Ես սկսեցի նայել թիմին՝ տեսնելու, թե ովքեր են իմ թիմում, և կրկին հիշեցի.

«Խնդիրների մեծ մասը մարդկային խնդիրներ են»։

Ես պարզեցի, որ թիմը՝ և՛ մշակողները, և՛ օպերատորները, ունեն երեք մեծ խնդիր.

• Գոհունակություն գործերի ներկա վիճակից։
• Պատասխանատվության պակաս — քանի որ ոչ ոք երբևէ կատարողների աշխատանքի արդյունքները չի վերածել բիզնեսի վրա ունեցած ազդեցության։
• Փոփոխության վախ։

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

Բայց դու չես կարող ավելի լավը դառնալ՝ առանց որևէ բան փոխելու։

Ես մի աշխատակցի հետ բոլորովին անհեթեթ զրույց ունեցա, ես նրան պատմում էի օպտիմալացման իմ գաղափարները, որին նա ինձ ասաց.
- Ա՜խ, դու չտեսար, թե անցյալ տարի ինչ ունեինք։
-Ուրեմն ի՞նչ:
— Հիմա շատ ավելի լավ է, քան առաջ էր։
- Այսինքն՝ ավելի լավը չի՞ կարող լինել։
- Ինչի համար?

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

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

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

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

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

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

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

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

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

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

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

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

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

Սակայն մշակողները չունեն սերվերներ գնելու փորձ կամ սերվերի ճիշտ չափը որոշելու հմտություն, քանի որ նախկինում դա անելու կարիք չեն ունեցել։ Եվ նրանք սովորաբար լիովին չեն հասկանում մասշտաբայնության և արդյունավետության միջև եղած տարբերությունը։

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

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

Յոթանասունհինգերորդ օրը

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

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

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

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

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

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

Ութսունհինգերորդ օրը

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

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

Ամփոփում

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

Կարելի էր երկար խոսել նմանատիպ միլիոն այլ բաների մասին։ Բայց ամենակարևորը մշակույթի մասին խոսելն է։

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

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

Սրա հետ մեկտեղ մնացած ամեն ինչ կգա։

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

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

Source: www.habr.com