Ենթակառուցվածքը որպես կոդ. ինչպես հաղթահարել խնդիրները XP-ի միջոցով

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

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

Ովքե՞ր ենք մենք, որտեղ ենք և ինչ խնդիրներ ունենք

Ներկայումս մենք գտնվում ենք Sre Onboarding Team-ում, որը բաղկացած է վեց ծրագրավորողներից և երեք ենթակառուցվածքի ինժեներից: Մենք բոլորս փորձում ենք Ենթակառուցվածքը գրել որպես կոդ (IaC): Մենք դա անում ենք, քանի որ մենք հիմնականում գիտենք, թե ինչպես գրել կոդ և ունենք «միջինից բարձր» ծրագրավորողների պատմություն:

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

Տեխնոլոգիական փաթեթը, որը մենք օգտագործում ենք մեր IaC-ում:

• Terraform ռեսուրսներ ստեղծելու համար:
• Փաթեթավորող՝ պատկերների հավաքման համար: Սրանք Windows, CentOS 7 պատկերներ են։
• Jsonnet-ը՝ drone.io-ում հզոր կառուցվածք ստեղծելու, ինչպես նաև փաթեթավորող json և մեր տերրաֆորմ մոդուլներ ստեղծելու համար:
• Լազուր
• Հասանելի է պատկերներ պատրաստելիս:
• Python օժանդակ ծառայությունների և սկրիպտների տրամադրման համար:
• Եվ այս ամենը VSCode-ում՝ թիմի անդամների միջև համօգտագործվող պլագիններով:

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

Մենք ներկայումս պայքարում ենք IaC-ի հետևյալ խնդիրների հետ.

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

Ծայրահեղ ծրագրավորում (XP) փրկելու համար

Բոլոր մշակողները ծանոթ են Extreme Programming-ին (XP) և դրա հետևում կանգնած պրակտիկաներին: Մեզանից շատերն աշխատել են այս մոտեցմամբ, և դա հաջողվել է: Այսպիսով, ինչո՞ւ չօգտագործել այնտեղ ամրագրված սկզբունքներն ու գործելակերպը՝ ենթակառուցվածքային մարտահրավերները հաղթահարելու համար: Մենք որոշեցինք այս մոտեցումն ընդունել և տեսնել, թե ինչ կլինի:

Ձեր արդյունաբերության համար XP մոտեցման կիրառելիության ստուգումԱհա այն միջավայրի նկարագրությունը, որի համար հարմար է XP-ն, և ինչպես է այն կապված մեզ հետ.

1. Ծրագրային ապահովման դինամիկ փոփոխվող պահանջները: Մեզ համար պարզ էր, թե որն էր վերջնական նպատակը։ Բայց մանրամասները կարող են տարբեր լինել: Մենք ինքներս ենք որոշում, թե որտեղ պետք է տաքսի գնանք, ուստի պահանջները պարբերաբար փոխվում են (հիմնականում մեր կողմից): Եթե ​​վերցնենք SRE թիմը, որն ինքն է անում ավտոմատացումը և ինքն է սահմանափակում աշխատանքի պահանջներն ու շրջանակը, ապա այս կետը լավ է տեղավորվում:

2. Նոր տեխնոլոգիաների կիրառմամբ ֆիքսված ժամանակի նախագծերի հետևանքով առաջացած ռիսկերը: Մեզ համար անհայտ որոշ բաներ օգտագործելիս մենք կարող ենք ռիսկի հանդիպել: Եվ սա 100%-ով մեր դեպքն է։ Մեր ամբողջ նախագիծը տեխնոլոգիաների օգտագործումն էր, որոնց մենք լիովին ծանոթ չէինք: Ընդհանուր առմամբ, սա մշտական ​​խնդիր է, քանի որ... Ենթակառուցվածքի ոլորտում մշտապես ի հայտ են գալիս բազմաթիվ նոր տեխնոլոգիաներ:

3,4. Փոքր, համատեղ տեղակայված ընդլայնված զարգացման թիմ: Ավտոմատացված տեխնոլոգիան, որը դուք օգտագործում եք, թույլ է տալիս միավորի և ֆունկցիոնալ թեստեր անցկացնել: Այս երկու կետերը մեզ այնքան էլ չեն համապատասխանում: Նախ՝ մենք համակարգված թիմ չենք, երկրորդ՝ ինը հոգի ենք, որոնց կարելի է մեծ թիմ համարել։ Թեև, ըստ «մեծ» թիմի որոշ սահմանումների, շատ բան 14+ մարդ է:

Եկեք նայենք XP-ի որոշ պրակտիկաներին և թե ինչպես են դրանք ազդում հետադարձ կապի արագության և որակի վրա:

XP Հետադարձ կապի սկզբունք

Իմ ընկալմամբ՝ հետադարձ կապը հարցի պատասխանն է՝ ճի՞շտ եմ անում, գնում ենք այնտեղ։ XP-ն դրա համար ունի աստվածային սխեման՝ ժամանակի հետադարձ կապ: Հետաքրքիրն այն է, որ որքան ցածր ենք, այնքան ավելի արագ ենք կարողանում հասնել OS-ին, որպեսզի պատասխանի անհրաժեշտ հարցերին։

Սա բավականին հետաքրքիր քննարկման թեմա է, որ մեր ՏՏ ոլորտում հնարավոր է արագ ստանալ ՕՀ։ Պատկերացրեք, թե որքան ցավալի է վեց ամիս նախագիծ անելը և միայն դրանից հետո պարզել, որ հենց սկզբում սխալ է եղել։ Դա տեղի է ունենում նախագծման և բարդ համակարգերի ցանկացած կառուցման մեջ:

Մեր IaC-ի դեպքում հետադարձ կապն օգնում է մեզ: Ես անմիջապես կկատարեմ վերը նշված գծապատկերի մի փոքր ճշգրտում. թողարկման պլանը ամսական ցիկլ չունի, բայց տեղի է ունենում օրը մի քանի անգամ: ՕՀ-ի այս ցիկլի հետ կապված կան որոշ պրակտիկաներ, որոնց մենք ավելի մանրամասն կանդրադառնանք:

Կարևոր է. հետադարձ կապը կարող է լուծում լինել վերը նշված բոլոր խնդիրների համար: Համակցված XP-ի պրակտիկայի հետ՝ այն կարող է ձեզ դուրս բերել հուսահատության անդունդից:

Ինչպես դուրս հանել ձեզ հուսահատության անդունդից. երեք պրակտիկա

Թեստեր

Թեստերը երկու անգամ նշվում են XP-ի հետադարձ կապի հանգույցում: Դա հենց այնպես չէ: Դրանք չափազանց կարևոր են Էքստրեմալ ծրագրավորման ողջ տեխնիկայի համար:

Ենթադրվում է, որ դուք ունեք Unit և Acceptance թեստեր: Ոմանք ձեզ հետադարձ կապ են տալիս մի քանի րոպեում, մյուսները՝ մի քանի օրվա ընթացքում, ուստի դրանք ավելի երկար են տևում գրելու համար և ավելի հազվադեպ են վերանայվում:

Կա դասական փորձարկման բուրգ, որը ցույց է տալիս, որ պետք է ավելի շատ թեստեր լինեն։

Ինչպե՞ս է այս շրջանակը կիրառվում մեզ համար IaC նախագծում: Իրականում... բնավ:

• Միավոր թեստերը, չնայած այն հանգամանքին, որ դրանք պետք է շատ լինեն, չեն կարող չափազանց շատ լինել: Կամ շատ անուղղակի ինչ-որ բան են փորձարկում։ Փաստորեն, կարելի է ասել, որ դրանք ընդհանրապես չենք գրում։ Բայց ահա այսպիսի թեստերի մի քանի հավելվածներ, որոնք մենք կարողացանք անել.
  1. jsonnet կոդի փորձարկում: Սա, օրինակ, մեր դրոնների հավաքման խողովակաշարն է, որը բավականին բարդ է։ jsonnet կոդը լավ ծածկված է թեստերով:
     Մենք օգտագործում ենք սա Միավորի փորձարկման շրջանակ Jsonnet-ի համար.
  2. Ստուգումներ սկրիպտների համար, որոնք կատարվում են ռեսուրսի մեկնարկի ժամանակ: Սկրիպտները գրված են Python-ով, և հետևաբար դրանց վրա կարելի է թեստեր գրել:
• Հնարավոր է ստուգել կոնֆիգուրացիան թեստերում, բայց մենք դա չենք անում: Հնարավոր է նաև կարգավորել ռեսուրսի ստուգման կոնֆիգուրացիայի կանոնները միջոցով կայծքար. Այնուամենայնիվ, այնտեղ ստուգումները պարզապես չափազանց հիմնական են տերրաֆորմի համար, բայց շատ թեստային սցենարներ գրված են AWS-ի համար: Եվ մենք Azure-ում ենք, ուստի սա կրկին չի կիրառվում:
• Բաղադրիչների ինտեգրման թեստեր. դա կախված է նրանից, թե ինչպես եք դրանք դասակարգում և որտեղ եք դրանք դնում: Բայց դրանք հիմնականում աշխատում են:

  Ահա թե ինչ տեսք ունեն ինտեգրացիոն թեստերը.

  
  
  Սա օրինակ է Drone CI-ում պատկերներ կառուցելիս: Նրանց հասնելու համար դուք պետք է սպասեք 30 րոպե, որպեսզի Packer-ի պատկերը ձևավորվի, ապա սպասեք ևս 15 րոպե, որպեսզի դրանք անցնեն: Բայց նրանք գոյություն ունեն!

  Պատկերի ստուգման ալգորիթմ

  1. Փաքերը նախ պետք է ամբողջությամբ պատրաստի պատկերը:
  2. Փորձարկման կողքին կա տերրաֆորմ՝ տեղական վիճակով, որը մենք օգտագործում ենք այս պատկերը տեղակայելու համար:
  3. Երբ բացվում է, մոտակայքում ընկած փոքրիկ մոդուլն օգտագործվում է պատկերի հետ աշխատելը հեշտացնելու համար:
  4. Երբ VM-ը տեղադրվի պատկերից, ստուգումները կարող են սկսվել: Հիմնականում ստուգումները կատարվում են մեքենայով։ Այն ստուգում է, թե ինչպես են սցենարներն աշխատել գործարկման ժամանակ և ինչպես են աշխատում դևերը: Դա անելու համար ssh-ի կամ winrm-ի միջոցով մենք մուտք ենք գործում նոր բարձրացված մեքենա և ստուգում կոնֆիգուրացիայի կարգավիճակը կամ արդյոք ծառայություններն ավարտված են:

• Իրավիճակը նման է տերրաֆորմի մոդուլների ինտեգրման թեստերի հետ: Ահա մի կարճ աղյուսակ, որը բացատրում է նման թեստերի առանձնահատկությունները:

  
  
  Խողովակաշարի վերաբերյալ կարծիքը տևում է մոտ 40 րոպե: Ամեն ինչ տեղի է ունենում շատ երկար ժամանակ: Այն կարող է օգտագործվել ռեգրեսիայի համար, բայց նոր զարգացման համար դա ընդհանուր առմամբ անիրատեսական է։ Եթե ​​դուք շատ, շատ պատրաստ եք դրան, պատրաստեք վազող սցենարներ, ապա կարող եք կրճատել այն մինչև 10 րոպե: Բայց սրանք դեռ Unit թեստեր չեն, որոնք 5 կտոր են անում 100 վայրկյանում։

Unit-ի թեստերի բացակայությունը պատկերներ կամ տերրաֆորմային մոդուլներ հավաքելիս խրախուսում է աշխատանքը տեղափոխել առանձին ծառայություններ, որոնք կարող են պարզապես գործարկվել REST-ի միջոցով կամ Python սկրիպտների վրա:

Օրինակ, մենք պետք է համոզվեինք, որ երբ վիրտուալ մեքենան միանում է, այն ինքն իրեն գրանցում է ծառայության մեջ ScaleFT, և երբ վիրտուալ մեքենան ոչնչացվեց, այն ինքն իրեն ջնջեց։

Քանի որ մենք ունենք ScaleFT որպես ծառայություն, մենք ստիպված ենք աշխատել դրա հետ API-ի միջոցով: Այնտեղ գրված էր մի փաթաթան, որը կարող ես քաշել ու ասել. Այն պահպանում է բոլոր անհրաժեշտ կարգավորումները և մուտքերը:

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

Թեստերի արդյունքները. Միավորի թեստավորումը, որը պետք է մեկ րոպեում տա ՕՀ-ին, չի տալիս: Իսկ բուրգում ավելի բարձր փորձարկման տեսակներն արդյունավետ են, բայց ընդգրկում են խնդիրների միայն մի մասը:

Զույգերի ծրագրավորում

Թեստերը, իհարկե, լավն են: Դրանցից կարելի է շատ գրել, դրանք կարող են լինել տարբեր տեսակի: Նրանք կաշխատեն իրենց մակարդակներում և մեզ հետադարձ կապ կտան: Բայց Unit-ի վատ թեստերի հետ կապված խնդիրը, որոնք տալիս են ամենաարագ ՕՀ-ը, մնում է: Միևնույն ժամանակ, ես դեռ ցանկանում եմ արագ OS, որի հետ հեշտ և հաճելի է աշխատել: Էլ չենք խոսում ստացված լուծույթի որակի մասին։ Բարեբախտաբար, կան տեխնիկա, որոնք կարող են ապահովել նույնիսկ ավելի արագ արձագանք, քան միավորի թեստերը: Սա զույգ ծրագրավորում է:

Կոդ գրելիս ցանկանում եք հնարավորինս արագ արձագանք ստանալ դրա որակի վերաբերյալ: Այո, դուք կարող եք գրել ամեն ինչ ֆունկցիոնալ ճյուղում (որպեսզի ոչ մեկի համար ոչինչ չկոտրեք), Github-ում pull-ի հարցում անել, վերագրել այն մեկին, ում կարծիքը կշիռ ունի և սպասել պատասխանի։

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

Ստորև բերված են ծրագրավորման զույգ ոճերը և դրանց կիրառելիությունը IaC-ի վրա աշխատելիս.

1. Դասական, Փորձառու+Փորձառու, հերթափոխ ըստ ժամանակաչափի: Երկու դեր՝ վարորդ և նավիգատոր: Երկու մարդ. Նրանք աշխատում են նույն կոդի վրա և որոշակի կանխորոշված ​​ժամանակահատվածից հետո փոխում են դերերը:

Դիտարկենք մեր խնդիրների համատեղելիությունը ոճի հետ.

• Խնդիր. կոդի մշակման գործիքների և գործիքների անկատարություն:
  Բացասական ազդեցություն. զարգացման համար ավելի երկար է պահանջվում, մենք դանդաղում ենք, աշխատանքի տեմպը/ռիթմը կորչում է:
  Ինչպես ենք մենք պայքարում. մենք օգտագործում ենք այլ գործիքակազմ, ընդհանուր IDE, ինչպես նաև սովորում ենք դյուրանցումներ:
• Խնդիր. Դանդաղ տեղակայում:
  Բացասական ազդեցություն. մեծացնում է աշխատանքային կոդ ստեղծելու ժամանակը: Սպասելիս ձանձրանում ենք, սպասելիս մեր ձեռքերը մեկնում են այլ բան անելու։
  Ինչպես ենք մենք պայքարում. մենք դա չհաղթահարեցինք.
• Խնդիր՝ մոտեցումների և պրակտիկայի բացակայություն:
  Բացասական ազդեցություն. չկա գիտելիք, թե ինչպես դա անել լավ և ինչպես դա անել վատ: Երկարացնում է հետադարձ կապի ստացումը:
  Ինչպես ենք մենք պայքարում. զույգերով աշխատանքի ընթացքում կարծիքների և պրակտիկայի փոխադարձ փոխանակումը գրեթե լուծում է խնդիրը:

IaC-ում այս ոճի օգտագործման հիմնական խնդիրը աշխատանքի անհավասար տեմպն է: Ավանդական ծրագրային ապահովման մշակման ժամանակ դուք ունեք միատեսակ շարժում: Կարելի է հինգ րոպե ծախսել և գրել N. Ծախսել 10 րոպե և գրել 2N, 15 րոպե՝ 3N: Այստեղ կարող ես հինգ րոպե ծախսել և գրել N, իսկ հետո ծախսել ևս 30 րոպե և գրել N-ի տասներորդը: Այստեղ դու ոչինչ չգիտես, դու խրված ես, հիմար: Հետաքննությունը ժամանակ է պահանջում և շեղում է ուշադրությունը ծրագրավորումից:

Եզրակացություն՝ իր մաքուր տեսքով այն մեզ հարմար չէ։

2. Պինգ-պոնգ. Այս մոտեցումը ներառում է մեկ անձ գրում է թեստը, իսկ մյուսը կատարում է դրա համար: Հաշվի առնելով այն հանգամանքը, որ Unit թեստերի հետ ամեն ինչ բարդ է, և պետք է գրել ինտեգրացիոն թեստ, որը երկար ժամանակ է պահանջում ծրագրավորելու համար, պինգ-պոնգի ամբողջ հեշտությունը վերանում է:

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

Եզրակացություն. ավաղ, աշխատանքի տեմպը թույլ չի տալիս օգտագործել պինգ-պոնգը որպես զույգ ծրագրավորման պրակտիկա IaC-ում:

3. Ուժեղ ոճ: Դժվար պրակտիկա. Գաղափարն այն է, որ մեկ մասնակիցը դառնում է դիրեկտիվ նավիգատոր, իսկ երկրորդը ստանձնում է կատարման վարորդի դերը: Այս դեպքում որոշումներ կայացնելու իրավունքը պատկանում է բացառապես նավիգատորին: Վարորդը միայն տպում է և կարող է ազդել այն ամենի վրա, ինչ կատարվում է բառով: Դերերը երկար ժամանակ չեն փոխվում։

Լավ է սովորելու համար, բայց պահանջում է ուժեղ փափուկ հմտություններ: Ահա թե որտեղ ենք մենք տատանվել։ Տեխնիկան դժվար էր. Եվ դա նույնիսկ ենթակառուցվածքների մասին չէ:

Եզրակացություն. այն հնարավոր է օգտագործել, մենք չենք հրաժարվում փորձերից:

4. Մոբբինգ, սվառմինգ և բոլոր հայտնի, բայց չնշված ոճերը Մենք դա չենք համարում, քանի որ Մենք դա չենք փորձել, և անհնար է դրա մասին խոսել մեր աշխատանքի համատեքստում։

Զույգ ծրագրավորման օգտագործման ընդհանուր արդյունքներ.

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

5. Չնայած դրան, հաջողություններ եղան. Մենք ստեղծեցինք մեր սեփական մեթոդը՝ «Կոնվերգենցիա - շեղում»: Ես հակիրճ նկարագրելու եմ, թե ինչպես է այն աշխատում:

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

Պլանավորում և հաղորդակցություն

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

1. Նպատակները նպատակի ծառի միջոցով: Մենք կազմակերպեցինք ծրագրի ընդհանուր կառավարումը մի ծառի միջոցով, որն անվերջ գնում է դեպի ապագա: Տեխնիկապես հետագծումը կատարվում է Միրոյում։ Կա մեկ խնդիր՝ դա միջանկյալ նպատակ է։ Դրանից բխում են կամ ավելի փոքր նպատակներ կամ առաջադրանքների խմբեր: Առաջադրանքներն իրենք իրենցից են բխում։ Բոլոր առաջադրանքները ստեղծվում և պահպանվում են այս տախտակի վրա:

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

Առաջադրանքների տեսողական տեսողության առավելությունները.

• Պատճառականություն. Յուրաքանչյուր առաջադրանք տանում է դեպի ինչ-որ գլոբալ նպատակ: Առաջադրանքները խմբավորված են ավելի փոքր նպատակներով: Ենթակառուցվածքի տիրույթն ինքնին բավականին տեխնիկական է: Միշտ չէ, որ անմիջապես պարզ է դառնում, թե կոնկրետ ինչ ազդեցություն է ունենում բիզնեսի վրա, օրինակ, այլ nginx տեղափոխության վերաբերյալ runbook գրելը: Թիրախային քարտը մոտակայքում ունենալը ավելի պարզ է դարձնում:
  
  Պատճառականությունը խնդիրների կարևոր հատկությունն է: Այն ուղղակիորեն պատասխանում է հարցին. «Արդյո՞ք ես ճի՞շտ բան եմ անում»:
• Զուգահեռություն. Մենք ինը հոգի ենք, և ֆիզիկապես անհնար է բոլորին մեկ գործի վրա գցել: Մի ոլորտի առաջադրանքները նույնպես կարող են ոչ միշտ բավարար լինել: Մենք ստիպված ենք զուգահեռաբար զուգահեռել փոքր աշխատանքային խմբերի աշխատանքը։ Միևնույն ժամանակ, խմբերը որոշ ժամանակ նստում են իրենց առաջադրանքի վրա, դրանք կարող են ամրապնդվել մեկ ուրիշի կողմից։ Երբեմն մարդիկ հեռանում են այս աշխատանքային խմբից։ Ինչ-որ մեկը գնում է արձակուրդ, ինչ-որ մեկը զեկույց է պատրաստում DevOps conf-ի համար, ինչ-որ մեկը հոդված է գրում Habr-ում: Իմանալը, թե ինչ նպատակներ և առաջադրանքներ կարելի է կատարել զուգահեռ, շատ կարևոր է դառնում։

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

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

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

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

Ցուցադրության ժամանակ անհրաժեշտ է բացահայտել առաջադրանքի մանրամասները և անպայման ցուցադրել դրա գործողությունը։

Զեկույցը կարող է իրականացվել ստուգաթերթի միջոցով:1. Մտեք համատեքստի մեջ: Որտեղի՞ց առաջացավ առաջադրանքը, ինչո՞ւ էր դա նույնիսկ անհրաժեշտ։

2. Ինչպե՞ս էր խնդիրը լուծվում նախկինում: Օրինակ՝ պահանջվում էր մկնիկի զանգվածային սեղմում, կամ ընդհանրապես անհնար էր որևէ բան անել։

3. Ինչպես ենք մենք այն կատարելագործում: Օրինակ՝ «Տեսեք, հիմա սկրիպտոսիկ կա, ահա ռեդմեյը»։

4. Ցույց տվեք, թե ինչպես է այն աշխատում: Ցանկալի է ուղղակիորեն իրականացնել օգտվողի որոշ սցենար: Ես ուզում եմ X, ես անում եմ Y, տեսնում եմ Y (կամ Z): Օրինակ, ես տեղակայում եմ NGINX-ը, ծխում եմ url-ը և ստանում 200 OK: Եթե ​​գործողությունը երկար է, նախօրոք պատրաստեք այն, որպեսզի հետագայում ցուցադրեք: Ցանկալի է այն շատ չկոտրել ցուցադրումից մեկ ժամ առաջ, եթե այն փխրուն է:

5. Բացատրեք, թե որքանով է հաջողությամբ լուծվել խնդիրը, ինչ դժվարություններ են մնացել, ինչը չի ավարտվել, ինչ բարելավումներ են հնարավոր ապագայում: Օրինակ, հիմա CLI, ապա CI-ում կլինի լիարժեք ավտոմատացում:

Ցանկալի է, որ յուրաքանչյուր խոսնակի համար այն պահի 5-10 րոպե: Եթե ​​ձեր ելույթն ակնհայտորեն կարևոր է և ավելի երկար կպահանջի, նախօրոք համակարգեք դա sre-takeover ալիքում:

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

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

Երկար եզրակացություններ և ինչ է հաջորդը

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

Թեստերն իրենց ներկայիս տեսքով ապահովում են միայն մասնակի ծածկույթ: Կազմաձևման շատ գործառույթներ ավարտվում են չստուգված: Կոդ գրելիս նրանց ազդեցությունը բուն աշխատանքի վրա ցածր է։ Այնուամենայնիվ, կա ինտեգրացիոն թեստերի ազդեցությունը, և դրանք թույլ են տալիս անվախորեն իրականացնել վերամշակումներ: Սա մեծ ձեռքբերում է։ Բացի այդ, բարձր մակարդակի լեզուների զարգացման վրա կենտրոնացումն անցնելով (մենք ունենք python, գնացեք), խնդիրը վերանում է: Եվ «սոսինձի» համար շատ ստուգումներ պետք չեն, ընդհանուր ինտեգրման ստուգումը բավական է:

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

ՕՀ-ի վրա ազդելու ավելի բարձր մակարդակի ուղիները՝ առաջադրանքների պլանավորումը և աշխատանքը ճշգրիտ արդյունք են տալիս՝ բարձրորակ գիտելիքների փոխանակում և զարգացման որակի բարելավում:

Կարճ եզրակացություններ մեկ տողում

• HR պրակտիկանտները աշխատում են IaC-ում, բայց ավելի քիչ արդյունավետությամբ:
• Ամրապնդեք այն, ինչ աշխատում է:
• Ստեղծեք ձեր սեփական փոխհատուցման մեխանիզմները և գործելակերպը:

Source: www.habr.com