Դժվա՞ր է հասկանալ հիմնական կետը DevOps-ի մասին խոսելիս: Մենք ձեզ համար հավաքել ենք վառ անալոգիաներ, տպավորիչ ձևակերպումներ և խորհուրդներ փորձագետներից, որոնք կօգնեն նույնիսկ ոչ մասնագետներին հասնել կետին: Վերջում, բոնուսը Red Hat-ի աշխատակիցների սեփական DevOps-ն է:
DevOps տերմինը ծագել է 10 տարի առաջ և Twitter-ի հեշթեգից վերածվել է ՏՏ աշխարհում հզոր մշակութային շարժման, իսկական փիլիսոփայություն, որը խրախուսում է ծրագրավորողներին անել ամեն ինչ ավելի արագ, փորձարկել և կրկնել առաջ: DevOps-ը դարձել է անքակտելիորեն կապված թվային փոխակերպման հայեցակարգի հետ: Բայց ինչպես հաճախ է պատահում ՏՏ տերմինաբանության հետ, վերջին տասը տարիների ընթացքում DevOps-ը ձեռք է բերել բազմաթիվ սահմանումներ, մեկնաբանություններ և սխալ պատկերացումներ իր մասին:
Հետևաբար, դուք հաճախ կարող եք լսել DevOps-ի վերաբերյալ հարցեր, ինչպիսիք են՝ արդյոք դա նույնն է, ինչ արագաշարժը: Թե՞ սա ինչ-որ հատուկ մեթոդաբանություն է: Թե՞ դա «համագործակցություն» բառի ևս մեկ հոմանիշ է:
DevOps-ը ներառում է բազմաթիվ տարբեր հասկացություններ (շարունակական առաքում, շարունակական ինտեգրում, ավտոմատացում և այլն), այնպես որ կարևորի թորումը կարող է դժվար լինել, հատկապես, երբ դուք կրքոտ եք այդ թեմայի շուրջ: Այնուամենայնիվ, այս հմտությունը շատ օգտակար է, անկախ նրանից՝ դուք փորձում եք ձեր գաղափարները փոխանցել վերադասին, թե պարզապես ձեր ընտանիքի կամ ընկերներից որևէ մեկին պատմում եք ձեր աշխատանքի մասին: Հետևաբար, եկեք առայժմ մի կողմ դնենք DevOps-ի տերմինաբանական նրբությունները և կենտրոնանանք մեծ պատկերի վրա:
Ինչ է DevOps. 6 սահմանումներ և անալոգիաներ
Մենք խնդրեցինք փորձագետներին բացատրել DevOps-ի էությունը հնարավորինս պարզ և հակիրճ, որպեսզի դրա արժեքը պարզ դառնա ցանկացած մակարդակի տեխնիկական գիտելիքներ ունեցող ընթերցողների համար: Այս խոսակցությունների արդյունքների հիման վրա մենք ընտրել ենք ամենավառ անալոգիաներն ու տպավորիչ ձևակերպումները, որոնք կօգնեն ձեզ կառուցել ձեր պատմությունը DevOps-ի մասին:
1. DevOps-ը մշակութային շարժում է
«DevOps-ը մշակութային շարժում է, որտեղ երկու կողմերն էլ (ծրագրավորողներ և ՏՏ համակարգերի շահագործման մասնագետներ) գիտակցում են, որ ծրագրաշարը իրական օգուտներ չի բերում, քանի դեռ ինչ-որ մեկը չի սկսում օգտագործել այն. հաճախորդներ, հաճախորդներ, աշխատակիցներ, ոչ թե իմաստը», - ասում է Էվելին Օերլիխը, ավագ հետազոտող: DevOps ինստիտուտի վերլուծաբան: «Ուստի այս երկու կողմերն էլ համատեղ ապահովում են ծրագրային ապահովման արագ և որակյալ առաքում»։
2. DevOps-ը ծրագրավորողներին հզորացնելու մասին է:
«DevOps-ը ծրագրավորողներին հնարավորություն է տալիս ունենալ հավելվածներ, գործարկել դրանք և կառավարել առաքումը սկզբից մինչև վերջ»:
«Սովորաբար, DevOps-ի մասին խոսվում է որպես հավելվածների առաքումն արտադրություն արագացնելու միջոց՝ կառուցելով և իրականացնելով ավտոմատացված գործընթացներ», - ասում է Liberty Mutual ապահովագրական ընկերության DevOps հարթակների տնօրեն Ջայ Շնիեպը: «Բայց ինձ համար դա շատ ավելի հիմնարար բան է»: DevOps-ը ծրագրավորողներին հնարավորություն է տալիս ունենալ հավելվածներ կամ ծրագրային ապահովման հատուկ մասեր, գործարկել դրանք և կառավարել դրանց առաքումը սկզբից մինչև վերջ: DevOps-ը վերացնում է պատասխանատվության շփոթությունը և ուղղորդում է բոլորին, ովքեր ներգրավված են ավտոմատացված, մշակողների վրա հիմնված ենթակառուցվածք ստեղծելու մեջ»:
3. DevOps-ը հավելվածների ստեղծման և առաքման համագործակցության մասին է:
«Պարզ ասած, DevOps-ը ծրագրային ապահովման արտադրության և առաքման մոտեցում է, որտեղ բոլորն աշխատում են միասին», - ասում է BMC-ի թվային բիզնեսի ավտոմատացման նախագահ և ղեկավար Գուր Ստաֆը:
4. DevOps-ը խողովակաշար է
«Փոխակրիչի հավաքումը հնարավոր է միայն այն դեպքում, եթե բոլոր մասերը տեղավորվեն միասին»:
«Ես DevOps-ը կհամեմատեի մեքենաների հավաքման գծի հետ», - շարունակում է Գուր աշխատակազմը: – Գաղափարն այն է, որ բոլոր մասերը նախապես նախագծվեն և պատրաստվեն, որպեսզի դրանք հետագայում հավաքվեն առանց անհատական ճշգրտման: Փոխակրիչի հավաքումը հնարավոր է միայն այն դեպքում, եթե բոլոր մասերը տեղավորվեն միասին: Նրանք, ովքեր նախագծում և կառուցում են շարժիչը, պետք է մտածեն, թե ինչպես այն ամրացնել մարմնին կամ շրջանակին: Արգելակներ սարքողները պետք է մտածեն անիվների մասին և այլն։ Նույնը պետք է լինի ծրագրային ապահովման դեպքում:
Բիզնեսի տրամաբանությունը կամ օգտատիրոջ միջերեսը ստեղծող ծրագրավորողը պետք է մտածի տվյալների բազայի մասին, որը պահպանում է հաճախորդների տեղեկատվությունը, օգտատերերի տվյալները պաշտպանելու անվտանգության միջոցները և ինչպես կաշխատի այս ամենը, երբ ծառայությունը սկսի սպասարկել մեծ, գուցե նույնիսկ բազմամիլիոնանոց օգտատերերի լսարանին: »:
«Մարդկանց ստիպել համագործակցել և մտածել աշխատանքի այն մասերի մասին, որոնք անում են ուրիշները, այլ ոչ թե կենտրոնանալով բացառապես իրենց առաջադրանքների վրա, հաղթահարելու ամենամեծ խոչընդոտն է: Եթե դուք կարողանաք դա անել, դուք ունեք թվային վերափոխման հիանալի հնարավորություն», - ավելացնում է Գուր աշխատակազմը:
5. DevOps-ը մարդկանց, գործընթացների և ավտոմատացման ճիշտ համադրություն է
DevOps ինստիտուտի գործադիր տնօրեն Ջեյն Գրոլը մեծ անալոգիա է առաջարկել DevOps-ը բացատրելու համար: Նրա խոսքերով, «DevOps-ը նման է բաղադրատոմսի երեք հիմնական կատեգորիայի բաղադրիչներով՝ մարդիկ, գործընթաց և ավտոմատացում: Այս բաղադրիչների մեծ մասը կարելի է վերցնել այլ ոլորտներից և աղբյուրներից՝ Lean, Agile, SRE, CI/CD, ITIL, առաջնորդություն, մշակույթ, գործիքներ: DevOps-ի գաղտնիքը, ինչպես ցանկացած լավ բաղադրատոմս, այն է, թե ինչպես ստանալ ճիշտ համամասնություններ և խառնել այս բաղադրիչները՝ հավելվածների ստեղծման և թողարկման արագությունն ու արդյունավետությունը բարձրացնելու համար»:
6. DevOps-ն այն է, երբ ծրագրավորողները աշխատում են Formula 1-ի թիմի նման
«Մրցավազքը նախատեսված է ոչ թե սկզբից մինչև վերջ, այլ ընդհակառակը, վերջից սկիզբ»:
«Երբ ես խոսում եմ այն մասին, թե ինչ կարելի է սպասել DevOps-ի նախաձեռնությունից, ես որպես օրինակ եմ մտածում NASCAR կամ Formula 1 մրցարշավային թիմի մասին», - ասում է Քրիս Շորթը, Red Hat-ի ամպային հարթակի մարքեթինգի ավագ մենեջերը և DevOps'ish տեղեկագրի հրատարակիչը: – Նման թիմի առաջատարը մեկ նպատակ ունի՝ մրցավազքի վերջում գրավել հնարավոր ամենաբարձր տեղը՝ հաշվի առնելով թիմի հասանելիք ռեսուրսները և նրան սպասվող մարտահրավերները: Այս դեպքում մրցավազքը նախատեսված է ոչ թե սկզբից մինչև վերջ, այլ ընդհակառակը, ավարտից սկիզբ։ Նախ դրվում է հավակնոտ նպատակ, ապա որոշվում են դրան հասնելու ուղիները։ Հետո դրանք բաժանվում են ենթաառաջադրանքների և պատվիրակվում են թիմի անդամներին»:
«Թիմն անցկացնում է մրցավազքից առաջ ամբողջ շաբաթը՝ կատարելագործելով փիթ-ստոպը: Նա ուժային մարզումներ և կարդիո է անում, որպեսզի մարզավիճակում մնա ծանր մրցավազքի օրվա համար: Միասին աշխատելու պրակտիկա՝ մրցավազքի ընթացքում ծագած ցանկացած խնդիր լուծելու համար: Նմանապես, մշակողների թիմը պետք է սովորի նոր տարբերակները հաճախակի թողարկելու հմտությունը: Եթե ունեք նման հմտություններ և լավ աշխատող անվտանգության համակարգ, նոր տարբերակների թողարկումը նույնպես ավելի հաճախ է տեղի ունենում: Այս աշխարհայացքում արագության բարձրացումը նշանակում է անվտանգության բարձրացում»,- ասում է Շորթը:
«Խոսքը «ճիշտ բան» անելու մասին չէ,- ավելացնում է Շորթը, «խոսքը հնարավորինս շատ բաների վերացման մասին է, որոնք խոչընդոտում են ցանկալի արդյունքի: Համագործակցեք և հարմարվեք իրական ժամանակում ստացած արձագանքների հիման վրա: Պատրաստ եղեք անոմալիաներին և աշխատեք բարելավել որակը, որպեսզի նվազագույնի հասցնեք դրանց ազդեցությունը ձեր նպատակին հասնելու առաջընթացի վրա: Ահա թե ինչ է մեզ սպասում DevOps-ի աշխարհում»:
Ինչպես մեծացնել DevOps-ը. 10 խորհուրդ փորձագետներից
Պարզապես DevOps-ն ու զանգվածային DevOps-ը բոլորովին տարբեր բաներ են: Մենք ձեզ կասենք, թե ինչպես հաղթահարել առաջինից երկրորդ ճանապարհին խոչընդոտները:
Շատ կազմակերպությունների համար դեպի DevOps ճանապարհորդությունը սկսվում է հեշտ և հաճելի: Ստեղծվում են փոքր կրքոտ թիմեր, հին գործընթացները փոխարինվում են նորերով, իսկ առաջին հաջողությունները չեն ուշանում։
Ավաղ, սա պարզապես կեղծ փայլ է, առաջընթացի պատրանք, ասում է Բեն Գրինելը, կառավարիչ տնօրեն և թվային բաժնի ղեկավար North Highland խորհրդատվական ընկերությունը: Վաղ հաղթանակները, անշուշտ, հուսադրող են, բայց դրանք չեն օգնում հասնել վերջնական նպատակին՝ DevOps-ի համատարած ընդունումը կազմակերպությունում:
Հեշտ է տեսնել, որ արդյունքը «մեր» և «նրանց» միջև բաժանման մշակույթն է։
«Հաճախ կազմակերպությունները սկսում են այս պիոներական նախագծերը՝ մտածելով, որ դրանք ճանապարհ կհարթեն հիմնական DevOps-ների համար՝ առանց հաշվի առնելու, թե արդյոք ուրիշները կկարողանան կամ կցանկանան գնալ այդ ճանապարհին», - բացատրում է Բեն Գրինելը: – Նման նախագծերի իրականացման համար թիմերը սովորաբար հավաքագրվում են ինքնավստահ «Վարանգյաններից», ովքեր արդեն նման բան արել են այլ վայրերում, բայց նոր են ձեր կազմակերպության համար: Միևնույն ժամանակ, նրանց խրախուսվում է խախտել և ոչնչացնել կանոնները, որոնք պարտադիր են մնում բոլորի համար: Հեշտ է տեսնել, որ արդյունքը «մենք»-ի և «նրանց» մշակույթն է, որը խոչընդոտում է գիտելիքների և հմտությունների փոխանցումը»:
«Եվ այս մշակութային խնդիրը միայն պատճառներից մեկն է, որ DevOps-ը դժվար է մասշտաբավորել: DevOps թիմերը բախվում են աճող տեխնիկական մարտահրավերների, որոնք բնորոշ են արագ զարգացող ՏՏ առաջին ընկերություններին», - ասում է Scalyr-ի հիմնադիր և նախագահ Սթիվ Նյումանը:
«Ժամանակակից աշխարհում ծառայությունները փոխվում են հենց անհրաժեշտություն է առաջանում: Հիանալի է անընդհատ ներդնել և ներդնել նոր հնարավորություններ, բայց այս գործընթացի համակարգումը և առաջացող խնդիրների վերացումը իսկական գլխացավանք է, ավելացնում է Սթիվ Նյումանը: – Շատ արագ զարգացող կազմակերպություններում բազմաֆունկցիոնալ թիմերի ինժեներները պայքարում են փոփոխությունների տեսանելիությունը պահպանելու և դրա ստեղծած կախվածության մակարդակի կասկադային էֆեկտները պահպանելու համար: Ավելին, ինժեներները չեն ուրախանում, երբ զրկվում են այդ հնարավորությունից, և արդյունքում նրանց համար դժվարանում է հասկանալ ծագած խնդիրների էությունը»։
Ինչպե՞ս հաղթահարել վերը նկարագրված այս մարտահրավերները և անցնել DevOps-ի զանգվածային ընդունմանը մեծ կազմակերպությունում: Փորձագետները հորդորում են համբերություն, նույնիսկ եթե ձեր վերջնական նպատակն է արագացնել ձեր ծրագրային ապահովման մշակման ցիկլը և բիզնես գործընթացները:
1. Հիշեք, որ մշակույթի փոփոխությունը ժամանակ է պահանջում:
Ջեյն Գրոլ, DevOps ինստիտուտի գործադիր տնօրեն. «Իմ կարծիքով, DevOps-ի ընդլայնումը պետք է լինի նույնքան աստիճանական և կրկնվող, որքան արագաշարժ զարգացումը (և նույնքան շոշափի մշակույթը): Agile-ը և DevOps-ն ընդգծում են փոքր թիմերը: Բայց քանի որ այս թիմերը մեծանում են թվով և ինտեգրվելով, մենք ի վերջո ավելի շատ մարդիկ են ընդունում աշխատանքի նոր ձևեր, և արդյունքում տեղի է ունենում մշակութային զանգվածային վերափոխում»:
2. Բավական ժամանակ հատկացրեք պլանավորմանը և հարթակի ընտրությանը
Eran Kinsbruner, առաջատար տեխնիկական ավետարանիչ Perfecto-ում. «Որպեսզի ընդլայնումն աշխատի, DevOps-ի թիմերը նախ պետք է սովորեն համատեղել ավանդական գործընթացները, գործիքներն ու հմտությունները, այնուհետև կամաց-կամաց դաստիարակեն և կայունացնեն DevOps-ի յուրաքանչյուր առանձին փուլ: Ամեն ինչ սկսվում է օգտատերերի պատմությունների և արժեքների հոսքերի մանրակրկիտ պլանավորումից, որին հաջորդում է ծրագրային ապահովման և տարբերակների վերահսկումը՝ օգտագործելով բեռնախցիկի վրա հիմնված զարգացում կամ այլ մոտեցումներ, որոնք լավագույնս հարմար են ճյուղավորման և կոդի միաձուլման համար»:
«Այնուհետև գալիս է ինտեգրման և փորձարկման փուլը, որտեղ արդեն իսկ պահանջվում է ավտոմատացման համար մասշտաբային հարթակ: Այստեղ է, որ DevOps թիմերի համար կարևոր է ընտրել ճիշտ հարթակը, որը համապատասխանում է իրենց հմտությունների մակարդակին և նախագծի վերջնական նպատակներին:
Հաջորդ փուլը արտադրության մեջ տեղակայումն է, և այն պետք է ամբողջությամբ ավտոմատացված լինի նվագախմբի գործիքների և կոնտեյներների միջոցով: Կարևոր է ունենալ վիրտուալացված միջավայրեր DevOps-ի բոլոր փուլերում (արտադրության սիմուլյատոր, QA միջավայր և փաստացի արտադրական միջավայր) և միշտ օգտագործել միայն վերջին տվյալները թեստերի համար՝ համապատասխան եզրակացություններ ստանալու համար: Վերլուծությունը պետք է լինի խելացի և ի վիճակի լինի մշակել մեծ տվյալներ արագ և գործնական արձագանքներով»:
3. Մեղքի զգացումը հանեք պատասխանատվությունից։
Գորդոն Հաֆ, RedHat ավետարանիչ. «Համակարգի և մթնոլորտի ստեղծումը, որը թույլ է տալիս և խրախուսում փորձարկումները, թույլ է տալիս այն, ինչը հայտնի է որպես արագաշարժ ծրագրաշարի մշակման հաջող ձախողումներ: Սա չի նշանակում, որ ձախողումների համար ուրիշ ոչ ոք պատասխանատվություն չի կրում։ Իրականում, պարզելը, թե ով է պատասխանատուն, ավելի հեշտ է դառնում, քանի որ «պատասխանատու լինել» այլևս չի նշանակում «վթարի պատճառ դառնալ»։ Այսինքն՝ որակապես փոխվում է պատասխանատվության էությունը։ Չորս գործոն դառնում է կրիտիկական՝ խափանման չափը, մոտեցումները, արտադրական գործընթացները և խթանները»: (Այս գործոնների մասին ավելին կարող եք կարդալ Գորդոն Հաֆի «DevOps դասեր. առողջ փորձերի 4 ասպեկտներ» հոդվածում):
4. Մաքրել առաջ տանող ճանապարհը
Բեն Գրինելը՝ North Highland խորհրդատվական ընկերության գործադիր տնօրեն և թվային բաժնի ղեկավար. «Մասշտաբի հասնելու համար խորհուրդ եմ տալիս պիոներական նախագծերի հետ համատեղ սկսել «ուղիների մաքրման» ծրագիր: Այս ծրագրի նպատակն է մաքրել այն աղբը, որը թողնում են DevOps-ի ռահվիրաները, օրինակ՝ հնացած կանոնները և նման բաները, որպեսզի առաջ տանող ճանապարհը մնա պարզ»:
«Մարդկանց տրամադրեք կազմակերպչական աջակցություն և թափ հաղորդակցության միջոցով, որը գերազանցում է պիոներական խմբին՝ լայնորեն տոնելով աշխատանքի նոր ձևերի հաջողությունները: Մարզեք մարդկանց, ովքեր ներգրավված են DevOps նախագծերի հաջորդ ալիքում և նյարդայնանում են DevOps-ն առաջին անգամ օգտագործելուց: Եվ հիշեք, որ այս մարդիկ շատ են տարբերվում պիոներներից»։
5. Ժողովրդավարացնել գործիքները
Սթիվ Նյուման, Scalyr-ի հիմնադիր և նախագահ. «Գործիքները չպետք է թաքցվեն մարդկանցից, և դրանք պետք է համեմատաբար հեշտ սովորել յուրաքանչյուրի համար, ով ցանկանում է ժամանակ տրամադրել: Եթե տեղեկամատյանները հարցումներ անելու հնարավորությունը սահմանափակված է գործիք օգտագործելու համար «հավաստագրված» երեք հոգով, դուք միշտ կունենաք առավելագույնը երեք հոգի հասանելի՝ խնդիրը լուծելու համար, նույնիսկ եթե ունեք շատ մեծ հաշվողական միջավայր: Այսինքն՝ այստեղ կա մի շեղ, որը կարող է հանգեցնել լուրջ (բիզնեսի) հետեւանքների»։
6. Ստեղծեք իդեալական պայմաններ թիմային աշխատանքի համար
Թոմ Քլարկ, ITV-ի Ընդհանուր հարթակի ղեկավար. «Դու կարող ես ամեն ինչ անել, բայց ոչ ամեն ինչ միանգամից: Այսպիսով, մեծ նպատակներ դրեք, սկսեք փոքրից և առաջ շարժվեք արագ կրկնություններով: Ժամանակի ընթացքում դուք կձևավորեք ձեր գործերն ավարտելու համբավ, այնպես որ ուրիշները նույնպես կցանկանան օգտագործել ձեր մեթոդները: Եվ մի անհանգստացեք բարձր արդյունավետ թիմ ստեղծելու մասին: Փոխարենը մարդկանց ապահովել աշխատանքային իդեալական պայմաններով, իսկ արդյունավետությունը կհետեւի»:
7. Մի մոռացեք Conway's Law-ի և Kanban տախտակների մասին
Logan Daigle, Ծրագրային ապահովման առաքման և DevOps ռազմավարության տնօրեն CollabNetVersionOne-ում. «Կարևոր է հասկանալ Քոնուեյի օրենքի հետևանքները: Իմ անփույթ թարգմանությամբ այս օրենքը նշում է, որ մեր ստեղծած արտադրանքները և գործընթացները, որոնք մենք օգտագործում ենք դրա համար, ներառյալ DevOps-ը, պարզվում է, որ կառուցված են այնպես, ինչպես մեր կազմակերպությունը»:
«Եթե կազմակերպությունում շատ սիլոսներ կան, և ծրագրակազմը պլանավորելիս, կառուցելիս և թողարկելիս վերահսկողությունը բազմիցս փոխվում է, ապա մասշտաբի ազդեցությունը կլինի զրոյական կամ կարճատև: Եթե կազմակերպությունը կառուցում է բազմաֆունկցիոնալ թիմեր ապրանքների շուրջ, որոնք ֆինանսավորվում են շուկայական ուշադրության կենտրոնում, ապա հաջողության շանսերը կտրուկ աճում են»:
«Scaling-ի մեկ այլ կարևոր ասպեկտ է ցուցադրել բոլոր ընթացիկ աշխատանքները (WIP, workinprogress) Kanban վահանակների վրա: Երբ կազմակերպությունն ունի մի տեղ, որտեղ մարդիկ կարող են տեսնել այս բաները, դա մեծապես խրախուսում է համագործակցությունը, ինչը դրականորեն է ազդում մասշտաբների վրա»:
8. Փնտրեք հին սպիներ
Մանուել Պաիս, DevOps-ի խորհրդատու և Team Topologies-ի համահեղինակ. «DevOps-ի պրակտիկաները Dev-ից և Ops-ից դուրս վերցնելը և դրանք այլ գործառույթների վրա կիրառելը դժվար թե օպտիմալ մոտեցում լինի: Սա, անշուշտ, որոշակի ազդեցություն կունենա (օրինակ՝ ավտոմատացնելով ձեռքով կառավարումը), բայց շատ ավելիին կարելի է հասնել, եթե սկսենք հասկանալ առաքման և հետադարձ կապի գործընթացները»:
«Եթե կազմակերպության ՏՏ համակարգում կան հին սպիներ՝ ընթացակարգեր և կառավարման մեխանիզմներ, որոնք ներդրվել են անցյալ միջադեպերի արդյունքում, բայց կորցրել են իրենց արդիականությունը (ապրանքների, տեխնոլոգիաների կամ գործընթացների փոփոխությունների պատճառով), ապա դրանք, անշուշտ, պետք է հեռացվեն։ կամ հարթել, այլ ոչ թե ավտոմատացնել անարդյունավետ կամ ավելորդ գործընթացները»:
9. Մի՛ ստեղծեք DevOps տարբերակները
Էնթոնի Էդվարդս, Eggplant-ի գործառնությունների տնօրեն. «DevOps-ը շատ անորոշ տերմին է, ուստի յուրաքանչյուր թիմ ավարտում է DevOps-ի իր տարբերակը: Եվ ավելի վատ բան չկա, երբ կազմակերպությունը հանկարծ ունի DevOps-ի 20 տեսակ, որոնք իրար հետ այնքան էլ լավ չեն համընկնում: Անհնար է, որ զարգացման երեք թիմերից յուրաքանչյուրն ունենա իր սեփական, հատուկ միջերեսը զարգացման և արտադրանքի կառավարման միջև: Ապրանքները նույնպես չպետք է ունենան իրենց ուրույն ակնկալիքները՝ կապված հետադարձ կապի հետ, երբ փոխանցվում են արտադրության սիմուլյատորին: Հակառակ դեպքում, դուք երբեք չեք կարողանա մեծացնել DevOps-ը»։
10. Քարոզիր DevOps-ի բիզնես արժեքը
Սթիվ Նյուման, Scalyr-ի հիմնադիր և նախագահ. «Աշխատեք ճանաչել DevOps-ի արժեքը: Սովորեք և ազատ զգացեք խոսել ձեր արածի օգուտների մասին: DevOps-ը ժամանակի և գումարի անհավանական խնայողություն է (ուղղակի մտածեք՝ ավելի քիչ ժամանակ, վերականգնման ավելի կարճ միջին ժամանակ), և DevOps-ի թիմերը պետք է անխոնջ շեշտեն (և քարոզեն) այս նախաձեռնությունների կարևորությունը բիզնեսի հաջողության համար: Այս կերպ դուք կարող եք ընդլայնել հետևորդների շրջանակը և մեծացնել DevOps-ի ազդեցությունը կազմակերպությունում»:
ԲՈՆՈՒՍ
On Մեր սեփական DevOps-ը կժամանի սեպտեմբերի 13-ին. այո, Red Hat-ը, որպես ծրագրային ապահովման արտադրող, ունի իր DevOps թիմերն ու պրակտիկան:
Մեր ինժեներ Մարկ Բիրգերը, ով մշակում է ներքին ավտոմատացման ծառայություններ ամբողջ կազմակերպությունում այլ խմբերի համար, կպատմի իր պատմությունը մաքուր ռուսերենով. ինչպես Red Hat DevOps թիմը տեղափոխեց հավելվածները Hat Virtualization վիրտուալ միջավայրերից, որոնք կառավարվում էին Ansible-ի կողմից մինչև ամբողջական կոնտեյների ձևաչափ։ OpenShift հարթակը:
Բայց սա դեռ ամենը չէ.
Երբ կազմակերպությունները ծանրաբեռնվածությունը տեղափոխեն կոնտեյներներ, հավելվածների մոնիտորինգի ավանդական մեթոդները կարող են չաշխատել: Երկրորդ ելույթում մենք կբացատրենք մեր մուտքագրման ձևը փոխելու մեր դրդապատճառը և ցույց կտանք այն ճանապարհի շարունակությունը, որը մեզ տանում էր դեպի անտառահատումների և մոնիտորինգի ժամանակակից մեթոդներ:
Source: www.habr.com