Ինչ է DevOps-ը

DevOps-ի սահմանումը շատ բարդ է, ուստի մենք պետք է ամեն անգամ նորից սկսենք այդ մասին քննարկումը: Միայն Հաբրեում այս թեմայով հազար հրապարակումներ կան։ Բայց եթե կարդում եք սա, հավանաբար գիտեք, թե ինչ է DevOps-ը: Որովհետև ես չեմ: Բարեւ: Իմ անունն է Ալեքսանդր Տիտով (@օսմինոգ), և մենք պարզապես կխոսենք DevOps-ի մասին, և ես կկիսվեմ իմ փորձով:

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

Մի ժամանակ ես ձիավարում էի միաձուլումների և ձեռքբերումների ալիքների վրա: Սկզբում ես աշխատում էի Qik կոչվող փոքրիկ ստարտափում, այնուհետև այն գնեց մի փոքր ավելի մեծ ընկերություն, որը կոչվում էր Skype, որն այնուհետև գնվեց մի փոքր ավելի մեծ ընկերության կողմից, որը կոչվում էր Microsoft: Այդ պահին ես սկսեցի տեսնել, թե ինչպես է DevOps-ի գաղափարը փոխակերպվում տարբեր չափերի ընկերություններում: Դրանից հետո ինձ սկսեց հետաքրքրել DevOps-ը շուկայական տեսանկյունից, և ես ու իմ գործընկերները հիմնեցինք Express 42 ընկերությունը։ Արդեն 6 տարի է՝ մենք շարժվում ենք շուկայի ալիքներով։

Ի թիվս այլ բաների, ես DevOps մոսկովյան համայնքի կազմակերպիչներից եմ և DevOps-Days 2017-ի կազմակերպիչ, բայց ես չեմ կազմակերպել 2018թ. Express 42-ն աշխատում է բազմաթիվ ընկերությունների հետ: Մենք այնտեղ աճեցնում ենք DevOps, դիտում ենք, թե ինչպես է դա տեղի ունենում, եզրակացություններ անում, վերլուծում, բոլորին ասում մեր եզրակացությունները և մարդկանց վարժեցնում DevOps-ի պրակտիկաներում: Ընդհանրապես, մենք անում ենք հնարավորը, որպեսզի մեծացնենք մեր փորձն ու փորձը այս առումով:

Ինչու DevOps

Առաջին հարցը, որը հետապնդում է բոլորին և միշտ այն է՝ ինչո՞ւ: Շատերը կարծում են, որ DevOps-ը պարզապես ավտոմատացում է կամ նմանատիպ բան, որն արդեն ունեցել է յուրաքանչյուր ընկերություն։

— Մենք ունեինք շարունակական ինտեգրում, սա նշանակում է, որ մենք արդեն ունեինք DevOps, և ինչո՞ւ է անհրաժեշտ այս ամենը: Արտերկրում զվարճանում են, բայց մեզ խանգարում են աշխատել։

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

Այս ամենը պայմանավորված է նրանով, որ աշխարհը փոխվում է։ Նա հեռանում է ձեռնարկատիրական մոտեցումից, երբ ընկերությունները գնում են ուղիղ դեպի երազանք, ինչպես երգում էր մեր Սանկտ Պետերբուրգի դասականը՝ A կետից B կետ՝ ըստ որոշակի ռազմավարության, դրա համար կառուցված որոշակի կառուցվածքով։

Սկզբունքորեն, ՏՏ-ում ամեն ինչ պետք է կառուցվի այս մոտեցմամբ։ Այստեղ ՏՏ-ն օգտագործվում է բացառապես գործընթացները ավտոմատացնելու համար։

Ավտոմատացումը հաճախ չի փոխվում, քանի որ երբ ընկերությունն անցնում է լավ ոտնահարված ճանապարհով, ի՞նչ կա փոխելու: Այն աշխատում է, մի դիպչեք դրան: Այժմ աշխարհում մոտեցումները փոխվում են, և Agile կոչվողը հուշում է, որ B վերջնակետը անմիջապես տեսանելի չէ:

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

Ռազմավարությունը ցուցադրվում է մի հետաքրքիր ընկերության կողմից, որի մասին ես վերջերս իմացա: One Box Shave-ը ածելիների և տուփի մեջ սափրվելու պարագաների բաժանորդային առաքման ծառայություն է: Նրանք գիտեն, թե ինչպես հարմարեցնել իրենց «արկղը» տարբեր հաճախորդների համար: Դա արվում է որոշակի ծրագրաշարի միջոցով, որն այնուհետև պատվերն ուղարկում է արտադրանքը արտադրող կորեական գործարան։

Այս ապրանքը գնել է Unilever-ը 1 մլրդ դոլարով։ Այն այժմ մրցակցում է Gillette-ի հետ և խլել է ամերիկյան շուկայում սպառողների զգալի մասը: One Box Shave-ն ասում է.

- 4 շեղբ? Դուք լո՞ւրջ եք ասում: Ինչու է ձեզ դա անհրաժեշտ. այն չի բարելավում սափրվելու որակը: Հատուկ ընտրված քսուքը, բուրմունքը և երկու շեղբերով բարձրորակ սափրիչը շատ ավելի շատ խնդիրներ են լուծում, քան այդ հիմար 4 Gillette սայրերը: Շուտով կհասնե՞նք 10-ին։

Ահա թե ինչպես է փոխվում աշխարհը. Unilever-ը պնդում է, որ իրենք ունեն հիանալի ՏՏ համակարգ, որը թույլ է տալիս դա անել: Ի վերջո, դա կարծես հայեցակարգ է Ժամանակը դեպի շուկա, որի մասին արդեն ոչ ոք չի խոսել։

Time-to-market-ի իմաստը այն չէ, թե որքան հաճախ ենք մենք տեղակայում: Դուք հաճախ կարող եք տեղակայել, բայց թողարկման ցիկլերը երկար կլինեն: Եթե ​​եռամսյա թողարկման ցիկլերը միմյանց վրա դրվում են՝ դրանք մեկ շաբաթով տեղափոխելով, ստացվում է, որ ընկերությունը կարծես թե տեղակայում է շաբաթը մեկ անգամ: Իսկ գաղափարից մինչև վերջնական իրականացում տեւում է 3 ամիս։

Ժամանակը դեպի շուկա գաղափարից մինչև վերջնական իրականացում ժամանակի նվազագույնի հասցնելն է:

Այս դեպքում ծրագրային ապահովումը փոխազդում է շուկայի հետ: Ահա թե ինչպես է One Box Shave կայքը համագործակցում հաճախորդի հետ: Նրանք չունեն վաճառողներ, պարզապես կայք, որտեղ այցելուները սեղմում են և թողնում ցանկություններ: Ըստ այդմ՝ կայքում պետք է անընդհատ տեղադրվի ինչ-որ նոր բան և թարմացվի՝ ըստ ցանկության։ Օրինակ, Հարավային Կորեայում սափրվում են այլ կերպ, քան Ռուսաստանում, և սիրում են ոչ թե սոճու, այլ, օրինակ, գազարի և վանիլի բույրը։

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

Օրինակ, Qik-ում մենք հանկարծ իմացանք, որ մարդկանց իսկապես դուր է եկել կոնտակտների ցուցակները սերվերի վրա վերբեռնել, և նրանք մեզ տրամադրեցին հավելված: Սկզբում մենք չէինք մտածում այդ մասին։ Դասական ընկերությունում բոլորը կորոշեին, որ սա վրիպակ է, քանի որ սպեկտրը չէր ասում, որ այն պետք է հիանալի աշխատի և ընդհանուր առմամբ ներդրված էր ծնկի վրա, նրանք կանջատեին գործառույթը և կասեին. «Սա ոչ ոքի պետք չէ, Ամենակարևորն այն է, որ հիմնական ֆունկցիոնալությունը աշխատի»: Եվ տեխնոլոգիական ընկերությունը դա տեսնում է որպես հնարավորություն և սկսում է սրան համապատասխան փոխել ծրագրային ապահովումը։

1968 թվականին մի տեսիլք ունեցող տղա՝ Մելվին Քոնվեյը, ձևակերպեց հետևյալ միտքը.

Համակարգը ստեղծող կազմակերպությունը սահմանափակված է դիզայնով, որը կրկնում է այդ կազմակերպության հաղորդակցման կառուցվածքը:

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

Կարդացեք Քոնուեյի օրենքի մասին կարելի հղումների միջոցով. Դա կարևոր է DevOps-ի մշակույթը կամ փիլիսոփայությունը հասկանալու համար, քանի որ միակ բանը, որ հիմնովին փոխվում է DevOps-ում, թիմերի միջև հաղորդակցության կառուցվածքն է.

Գործընթացի տեսանկյունից մինչև DevOps-ը բոլոր փուլերը՝ վերլուծություն, մշակում, թեստավորում, շահագործում, գծային էին։
DevOps-ի դեպքում այս բոլոր գործընթացները տեղի են ունենում միաժամանակ։

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

Այսպիսով, ինչու է ձեզ անհրաժեշտ DevOps-ը:

Թվային արտադրանքի մշակման համար. Եթե ​​ձեր ընկերությունը թվային արտադրանք չունի, DevOps-ը պետք չէ, դա շատ կարևոր է:

DevOps-ը հաղթահարում է հաջորդական ծրագրային ապահովման արտադրության արագության սահմանափակումները. Դրանում բոլոր գործընթացները տեղի են ունենում միաժամանակ։

Դժվարությունը մեծանում է. Երբ DevOps-ի ավետարանիչները ձեզ ասում են, որ դա ձեզ համար կհեշտացնի ծրագրակազմի թողարկումը, դա անհեթեթություն է:

DevOps-ի հետ ամեն ինչ միայն ավելի կբարդանա:

Avito-ի ստենդի կոնֆերանսի ժամանակ դուք կարողացաք տեսնել, թե ինչպիսին է Docker կոնտեյների տեղակայումը. անիրատեսական խնդիր: Բարդությունը դառնում է արգելք, դուք պետք է միաժամանակ շատ գնդակներ վարեք:

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

Հարցեր մասնագետին

Ինչ ունես? Հարցեր, որոնք կարող եք ինքներդ ձեզ տալ ընկերությունում աշխատելիս և որպես մասնագետ զարգանալիս:

Ունե՞ք թվային արտադրանք ստեղծելու ռազմավարություն: Եթե ​​կա, դա արդեն լավ է: Սա նշանակում է, որ ձեր ընկերությունը շարժվում է դեպի DevOps:

Ձեր ընկերությունն արդեն թվային արտադրանք է ստեղծում: Սա նշանակում է, որ դուք կարող եք մեկ այլ մակարդակ բարձրանալ և ավելի հետաքրքիր բաներ անել՝ կրկին DevOps-ի տեսանկյունից: Ես միայն այս տեսանկյունից եմ խոսում։

Արդյո՞ք ձեր ընկերությունը թվային արտադրանքի շուկայի առաջատարներից մեկն է: Spotify, Yandex, Uber ընկերություններ են, որոնք այժմ գտնվում են տեխնոլոգիական առաջընթացի գագաթնակետին։

Հարցրեք ինքներդ ձեզ այս հարցերը, և եթե բոլոր պատասխանները ոչ են, ապա միգուցե դուք չպետք է DevOps անեք այս ընկերությունում: Եթե ​​DevOps-ի թեման իսկապես հետաքրքիր է ձեզ, միգուցե... պետք է տեղափոխվե՞ք այլ ընկերություն։ Եթե ​​ձեր ընկերությունը ցանկանում է մտնել DevOps, բայց դուք պատասխանել եք «Ոչ» բոլոր հարցերին, ապա դա նման է այն գեղեցիկ ռնգեղջյուրին, որը երբեք չի փոխվի:

Կազմակերպություն

Ինչպես ասացի, Կոնվեյի օրենքի համաձայն, ընկերության կազմակերպումը փոխվում է։ Ես կսկսեմ նրանից, թե ինչն է խանգարում DevOps-ին կազմակերպչական տեսանկյունից ներթափանցել ընկերության ներսում:

«Հորերի» խնդիրը.

Անգլերեն «Silo» բառն այստեղ ռուսերեն թարգմանվում է որպես «լավ»: Այս խնդրի իմաստն այն է, որ թիմերի միջև տեղեկատվության փոխանակում չկա. Յուրաքանչյուր թիմ խորանում է իր փորձագիտության մեջ՝ առանց նավարկելու ընդհանուր քարտեզ կառուցելու:

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

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

Դրան խանգարում է երկու գործոն.

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

Բայց ամենակարևորն այն է, որ DevOps-ի ոգով տոգորված, Ֆաուլեր և մի շարք այլ գրքեր կարդացած ինժեների համար «հորերի» խնդիրն արտահայտվում է նրանով, որ. «հորերը» թույլ չեն տալիս «ակնհայտ» բաներ անել. Մենք հաճախ ենք հավաքվում DevOps Մոսկվայից հետո, զրուցում միմյանց հետ, և մարդիկ դժգոհում են.

— Մենք պարզապես ցանկանում էինք գործարկել CI-ն, բայց պարզվեց, որ ղեկավարությանը դա պետք չէր:

Սա տեղի է ունենում հենց այն պատճառով, որ CI и Շարունակական առաքման գործընթաց գտնվում են բազմաթիվ քննությունների սահմանին. Պարզապես առանց կազմակերպչական մակարդակում «ջրհորների» խնդիրը հաղթահարելու՝ ինչ էլ անես ու ինչքան էլ տխուր լինի, չես կարողանա առաջ գնալ։

Ընկերության գործընթացի յուրաքանչյուր մասնակից՝ backend և frontend ծրագրավորողներ, թեստավորում, DBA, օպերացիա, ցանց, փորում են իրենց ուղղությամբ, և ոչ ոք չունի ընդհանուր քարտեզ, բացի մենեջերից, ով ինչ-որ կերպ վերահսկում է նրանց և կառավարում դրանք՝ օգտագործելով «բաժանումը»: և նվաճել» մեթոդը։

Մարդիկ պայքարում են ինչ-որ աստղերի կամ դրոշների համար, ամեն մեկն իր փորձն է փորում:

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

Ձեր ընկերությունո՞ւմ է այդպես։

Սա ստուգելու համար կարող եք ինքներդ ձեզ տալ հետևյալ հարցերը.

Արդյո՞ք թիմերն օգտագործում են ընդհանուր գործիքներ և նպաստում են այդ ընդհանուր գործիքների փոփոխություններին:

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

Հնարավո՞ր է փոփոխությունների հանձնաժողով ձևավորել և բան փոխել։ Թե՞ դրա համար պահանջվում է ամենաբարձր ղեկավարության և ուղղության ուժեղ ձեռքը: Վերջերս ֆեյսբուքում գրեցի, թե ինչպես է մի քիչ հայտնի բանկ պատվերների միջոցով գործիքներ ներդնում. մենք պատվեր ենք գրում, կատարում ենք այն մեկ տարի, և տեսնում ենք, թե ինչ կլինի: Սա, իհարկե, երկար է ու տխուր։

Որքանո՞վ է կարևոր մենեջերների համար ստանալ անձնական ձեռքբերումներ՝ առանց հաշվի առնելու ընկերության ձեռքբերումները:

Եթե ​​դուք ինքներդ պատասխանեք այս հարցերին, ապա ավելի պարզ կդառնա, թե արդյոք նման խնդիր ունեք ձեր ընկերությունում։

Ենթակառուցվածքը որպես ծածկագիր

Այս խնդիրն անցնելուց հետո առաջին կարևոր պրակտիկան, առանց որի դժվար է DevOps-ում հետագա առաջընթացը ենթակառուցվածքը որպես ծածկագիր.

Ամենից հաճախ ենթակառուցվածքը որպես ծածկագիր ընկալվում է հետևյալ կերպ.

— Եկեք ավտոմատացնենք ամեն ինչ բաշի մեջ, ծածկվենք սկրիպտներով, որպեսզի ադմիններն ավելի քիչ ձեռքով աշխատանք ունենան։

Բայց դա ճիշտ չէ:

Ենթակառուցվածքը որպես կոդ նշանակում է, որ դուք նկարագրում եք ՏՏ համակարգը, որի հետ աշխատում եք կոդի տեսքով, որպեսզի անընդհատ հասկանաք դրա վիճակը:

Այլ թիմերի հետ միասին դուք ստեղծում եք քարտեզ կոդերի տեսքով, որը բոլորը կարող են հասկանալ և կարող են նավարկել և նավարկել: Կարևոր չէ, թե ինչի վրա է դա արվում՝ խոհարար, Ansible, Salt կամ օգտագործելով YAML ֆայլերը Kubernetes-ում, տարբերություն չկա:

Կոնֆերանսում 2GIS-ի գործընկերը պատմեց, թե ինչպես են իրենք ստեղծել իրենց ներքին իրը Kubernetes-ի համար, որը նկարագրում է առանձին համակարգերի կառուցվածքը: 500 համակարգեր նկարագրելու համար նրանց անհրաժեշտ էր առանձին գործիք, որը գեներացնում է այս նկարագրությունը: Երբ կա այս նկարագրությունը, բոլորը կարող են ստուգել միմյանց հետ, վերահսկել փոփոխությունները, ինչպես փոխել այն և բարելավել այն, ինչն է պակասում:

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

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

Կոդը պահպանվում է լավագույն կոդերի փորձի համաձայնՀամատեղ մշակում, կոդի վերանայում, XP-ծրագրավորում, փորձարկում, pull հարցումներ, CI կոդի ենթակառուցվածքների համար. այս ամենը հարմար է և կարող է օգտագործվել:

Կոդը դառնում է ընդհանուր լեզու բոլոր ինժեներների համար:

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

Կարեւոր է,Եթե ​​դեռ չեք փորձել այս նյութը, հիշեք դա Ansible-ը բաշ չէ! Ուշադիր կարդացեք փաստաթղթերը, ուսումնասիրեք, թե ինչ են գրում դրա մասին։

Ենթակառուցվածքը որպես ծածկագիր ենթակառուցվածքի կոդի բաժանումն է առանձին շերտերի:

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


բազային շերտ - այսպես են կազմաձևվում ՕՀ-ն, կրկնօրինակները և ցածր մակարդակի այլ բաներ, օրինակ՝ ինչպես է Kubernetes-ը տեղակայվում հիմնական մակարդակում:

Ծառայության մակարդակը - սրանք այն ծառայություններն են, որոնք դուք տրամադրում եք մշակողին. գրանցում որպես ծառայություն, մոնիտորինգ որպես ծառայություն, տվյալների բազա՝ որպես ծառայություն, հավասարակշռող՝ որպես ծառայություն, հերթում՝ որպես ծառայություն, շարունակական առաքում որպես ծառայություն. կարող է ապահովել զարգացմանը։ Այս ամենը պետք է նկարագրվի ձեր կոնֆիգուրացիայի կառավարման համակարգի առանձին մոդուլներում:

Շերտը, որտեղ կատարվում են դիմումները և նկարագրում է, թե ինչպես են դրանք բացվելու նախորդ երկու շերտերի վրա:

Վերահսկիչ հարցեր

Ձեր ընկերությունն ունի՞ ընդհանուր ենթակառուցվածքի պահեստ: Դուք կառավարում եք տեխնիկական պարտքը ձեր ենթակառուցվածքում: Դուք կիրառու՞մ եք զարգացման պրակտիկա ենթակառուցվածքի պահեստում: Արդյո՞ք ձեր ենթակառուցվածքը շերտերի է բաժանված: Դուք կարող եք ստուգել Base-service-APP դիագրամը: Որքա՞ն դժվար է փոփոխություն կատարելը:

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

Շարունակական առաքում

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

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

Երբ մենք հետ ենք Վանյա Եվտուխովիչ տեսել է առաջին գիրքը Ջեզ Խոնարհ և հեղինակների խմբեր «Շարունակական առաքում», որը թողարկվել է 2009 թվականին, մենք երկար մտածում էինք, թե ինչպես թարգմանել դրա վերնագիրը ռուսերեն։ Նրանք ցանկանում էին թարգմանել որպես «Մշտապես առաքում», բայց, ցավոք, այն թարգմանվեց որպես «Շարունակական առաքում»: Ինձ թվում է՝ մեր անվան մեջ ռուսական բան կա՝ ճնշումներով։

Անընդհատ մատուցող միջոցներ

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

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

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

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

Տարբեր տեղակայման ռազմավարություններ: Օրինակ, դուք օգտագործում եք AB թեստավորում կամ Canary տեղակայում, որպեսզի փորձարկեք կոդը տարբեր հաճախորդների վրա, տեղեկություններ ստանաք այն մասին, թե ինչպես է աշխատում կոդը և շատ ավելի վաղ, քան այն, երբ այն տարածվում է 100 միլիոն օգտատերերի համար:

«Հետևողականորեն առաքել»-ն այսպիսի տեսք ունի.

Dev, CI, Test, PreProd, Prod առաքման գործընթացը առանձին միջավայր չէ, դրանք փուլեր կամ կայաններ են հրակայուն գումարներով, որոնց միջով անցնում է ձեր արտեֆակտը:

Եթե ​​ունեք ենթակառուցվածքի կոդը, որը նկարագրված է որպես Base Service APP, ապա դա օգնում է մի մոռացեք բոլոր սցենարներըև գրեք դրանք որպես կոդ այս արտեֆակտի համար, խթանել արտեֆակտը և փոխիր այն, երբ գնում ես:

Ինքնաթեստի հարցեր

Գործառույթի նկարագրությունից մինչև արտադրության թողարկումը դեպքերի 95%-ում մեկ շաբաթից պակաս է: Արդյո՞ք արտեֆակտի որակը բարելավվում է խողովակաշարի յուրաքանչյուր փուլում: Կա՞ պատմություն, որի միջով անցնում է: Դուք կիրառո՞ւմ եք տեղակայման տարբեր ռազմավարություններ:

Եթե ​​բոլոր պատասխանները այո են, ապա դուք աներևակայելի հիանալի եք: Գրեք ձեր պատասխանները մեկնաբանություններում, ես ուրախ կլինեմ):

հետադարձ կապ

Սա ամենադժվար պրակտիկան է: DevOpsConf կոնֆերանսում Infobip-ի գործընկերներից մեկը, խոսելով այդ մասին, մի փոքր շփոթված էր իր խոսքերում, քանի որ սա իսկապես շատ բարդ պրակտիկա է այն փաստի վերաբերյալ, որ դուք պետք է վերահսկեք ամեն ինչ:

Օրինակ, շատ վաղուց, երբ ես աշխատում էի Qik-ում, և մենք հասկացանք, որ պետք է ամեն ինչ վերահսկել: Մենք դա արեցինք, և այժմ Zabbix-ում ունենք 150 ապրանք, որոնք մշտապես վերահսկվում են: Սարսափելի էր, տեխնիկական տնօրենը մատը ոլորեց իր քունքին.

- Տղերք, ինչո՞ւ եք սերվերը բռնաբարում անհասկանալի բանով։

Բայց հետո տեղի ունեցավ մի միջադեպ, որը ցույց տվեց, որ սա իսկապես շատ լավ ռազմավարություն է:

Ծառայություններից մեկը սկսել է անընդհատ վթարվել։ Ի սկզբանե այն չէր խափանում, ինչը հետաքրքիր է, կոդը այնտեղ չէր ավելացվել, քանի որ այն հիմնական բրոքեր էր, որը գործնականում չուներ բիզնես ֆունկցիոնալություն. այն ուղղակի հաղորդագրություններ էր ուղարկում առանձին ծառայությունների միջև: Ծառայությունը չի փոխվել 4 ամիս, և հանկարծ այն սկսել է խափանվել «Segmentation fault» սխալով:

Մենք ցնցվեցինք, բացեցինք մեր գծապատկերները Zabbix-ում և պարզվեց, որ մեկուկես շաբաթ առաջ այս բրոքերի կողմից օգտագործվող API ծառայության հարցումների վարքագիծը մեծապես փոխվեց: Հաջորդիվ տեսանք, որ որոշակի տեսակի հաղորդագրություն ուղարկելու հաճախականությունը փոխվել է։ Ավելի ուշ մենք իմացանք, որ դրանք Android-ի հաճախորդներ են։ Մենք հարցրինք.

- Տղերք, ի՞նչ պատահեց ձեզ հետ մեկուկես շաբաթ առաջ:

Ի պատասխան՝ մենք լսեցինք մի հետաքրքիր պատմություն այն մասին, թե ինչպես են նրանք վերանախագծել UI-ը։ Դժվար թե որևէ մեկը անմիջապես ասի, որ փոխել է HTTP գրադարանը: Android-ի հաճախորդների համար դա նման է լոգարանում օճառ փոխելուն. նրանք պարզապես չեն հիշում: Արդյունքում 40 րոպե զրույցից հետո պարզեցինք, որ նրանք փոխել են HTTP գրադարանը, և դրա լռելյայն ժամերը փոխվել են։ Սա հանգեցրեց API սերվերի երթևեկության վարքագծի փոփոխությանը, ինչը հանգեցրեց մի իրավիճակի, որը մրցավազքի առաջացրեց բրոքերի ներսում, և այն սկսեց խափանվել:

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

Հավաքեք ամբողջ տեղեկատվությունը այն մասին, թե ինչ է տեղի ունենում արտեֆակտի հետ առաքման գործընթացի յուրաքանչյուր փուլում՝ ոչ արտադրության մեջ:

Վերբեռնեք մոնիտորինգը CI, և որոշ հիմնական բաներ արդեն տեսանելի կլինեն այնտեղ: Ավելի ուշ դրանք կտեսնեք Test, PredProd և load testing-ում: Հավաքեք տեղեկատվություն բոլոր փուլերում, ոչ միայն չափումներ, վիճակագրություն, այլ նաև տեղեկամատյաններ. ինչպես է հայտնվել հավելվածը, անոմալիաներ - հավաքել ամեն ինչ:

Հակառակ դեպքում դժվար կլինի դա պարզել։ Ես արդեն ասացի, որ DevOps-ն ավելի բարդ է։ Այս բարդությունը հաղթահարելու համար դուք պետք է ունենաք նորմալ վերլուծություն.

Հարցեր ինքնատիրապետման համար

Արդյո՞ք ձեր մոնիտորինգը և գրանցումը մշակման գործիքն է ձեզ համար: Կոդ գրելիս ձեր մշակողները, այդ թվում՝ դուք, մտածո՞ւմ են, թե ինչպես վերահսկել այն:

Հաճախորդներից լսու՞մ եք խնդիրների մասին: Դուք ավելի լավ եք հասկանում հաճախորդին մոնիտորինգից և գրանցումից: Դուք ավելի լավ եք հասկանում համակարգը մոնիտորինգից և գրանցումից: Դուք փոխում եք համակարգը միայն այն պատճառով, որ տեսաք, որ համակարգում միտումը աճում է և հասկանում եք, որ ևս 3 շաբաթից ամեն ինչ կմեռնի։

Երբ դուք ունեք այս երեք բաղադրիչները, կարող եք մտածել, թե ինչպիսի ենթակառուցվածքային հարթակ ունեք ձեր ընկերությունում:

Ենթակառուցվածքային հարթակ

Բանն այն չէ, որ դա տարբեր գործիքների մի շարք է, որն ունի յուրաքանչյուր ընկերություն:

Ենթակառուցվածքային հարթակի իմաստն այն է, որ բոլոր թիմերն օգտագործում են այս գործիքները և միասին զարգացնում դրանք:

Հասկանալի է, որ կան առանձին թիմեր, որոնք պատասխանատու են ենթակառուցվածքի հարթակի առանձին կտորների մշակման համար։ Բայց միևնույն ժամանակ, յուրաքանչյուր ինժեներ պատասխանատվություն է կրում ենթակառուցվածքի հարթակի զարգացման, կատարման և առաջմղման համար: Ներքին մակարդակում այն ​​դառնում է սովորական գործիք.

Բոլոր թիմերը մշակում են ենթակառուցվածքային հարթակը և խնամքով վերաբերվում դրան որպես իրենց սեփական IDE-ի. Ձեր IDE-ում դուք տեղադրում եք տարբեր պլագիններ՝ ամեն ինչ գեղեցիկ և արագ դարձնելու և թեժ ստեղները կարգավորելու համար: Երբ բացում ես Sublime-ը, Atom-ը կամ Visual Studio Code-ը, կոդի սխալներն են հորդում, և հասկանում ես, որ ընդհանրապես անհնար է աշխատել, անմիջապես տխրում ես և վազում ես ուղղելու քո IDE-ը:

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

Ենթակառուցվածքային հարթակն ապահովում է արտեֆակտի փոխանցումը մշակումից պատվիրատուին՝ որակի շարունակական բարելավմամբ. IP-ն ծրագրավորված է մի շարք պատմություններով, որոնք տեղի են ունենում արտադրության կոդի հետ: Զարգացման տարիների ընթացքում այս պատմությունները շատ են, դրանցից մի քանիսը եզակի են և վերաբերում են միայն ձեզ. դրանք չեն կարող փնտրվել Google-ում:

Այս պահին ենթակառուցվածքային հարթակը դառնում է ձեր մրցակցային առավելությունը, քանի որ դրա մեջ ներկառուցված բան կա, որը չկա մրցակցի գործիքի մեջ: Որքան ավելի խորը լինի ձեր IP-ն, այնքան ավելի մեծ կլինի ձեր մրցակցային առավելությունը «Ժամանակից դեպի շուկա» տեսանկյունից: Հայտնվում է այստեղ վաճառողի կողպեքի խնդիրԴուք կարող եք վերցնել ուրիշի հարթակը, բայց օգտագործելով ուրիշի փորձը, չեք հասկանա, թե որքանով է դա ձեզ համար տեղին: Այո, ոչ բոլոր ընկերությունները կարող են կառուցել այնպիսի հարթակ, ինչպիսին Amazon-ն է: Սա բարդ գիծ է, որտեղ ընկերության փորձը համապատասխանում է շուկայում իր դիրքին, և դուք չեք կարող այնտեղ օգտագործել վաճառողի կողպեքը: Սա նույնպես կարևոր է մտածել:

Ծրագիրը

Սա ենթակառուցվածքային հարթակի հիմնական գծապատկերն է, որը կօգնի ձեզ ստեղծել DevOps ընկերության բոլոր պրակտիկաներն ու գործընթացները:

Եկեք նայենք, թե ինչից է այն բաղկացած:

Ռեսուրսների նվագախմբային համակարգ, որն ապահովում է պրոցեսոր, հիշողություն, սկավառակ հավելվածներին և այլ ծառայություններ։ Սրա վերևում - ցածր մակարդակի ծառայություններՄոնիտորինգ, գրանցում, CI/CD շարժիչ, արտեֆակտի պահեստավորում, ենթակառուցվածք՝ որպես համակարգի կոդ:

Բարձր մակարդակի ծառայություններտվյալների բազա՝ որպես ծառայություն, հերթեր՝ որպես ծառայություն, Load Balance՝ որպես ծառայություն, պատկերի չափափոխում՝ որպես ծառայություն, Big Data գործարան՝ որպես ծառայություն: Սրա վերևում - խողովակաշար, որը մշտապես փոփոխված կոդ է տրամադրում ձեր հաճախորդին.

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

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

Կարևոր է հասկանալ, որ պլատֆորմի յուրաքանչյուր հատված ունի իր պատմությունը, և ինքներդ ձեզ հարցրեք, թե ինչ պատմություն է կրում այս աղյուսը, միգուցե այն պետք է դեն նետել և փոխարինել երրորդ կողմի ծառայությունով: Օրինակ, հնարավո՞ր է աղյուսի փոխարեն տեղադրել Okmeter: Երևի տղաներն արդեն զարգացրել են այս փորձաքննությունը, քան մենք։ Բայց միգուցե ոչ, միգուցե մենք ունենք յուրահատուկ փորձ, մենք պետք է տեղադրենք Prometheus-ը և այն ավելի զարգացնենք:

Պլատֆորմի ստեղծում

Սա բարդ հաղորդակցման գործընթաց է: Երբ դուք ունեք հիմնական պրակտիկա, դուք սկսում եք հաղորդակցություն տարբեր ինժեներների և մասնագետների միջև, ովքեր մշակում են պահանջներ և ստանդարտներ և անընդհատ փոխում դրանք տարբեր գործիքների և մոտեցումների: Այստեղ կարևոր է մշակույթը, որը մենք ունենք DevOps-ում:

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

Ինչ ունես?

Կրկին հարցեր, որոնք կարող եք ինքներդ ձեզ տալ:

Արդյո՞ք ենթակառուցվածքի հարթակը նվիրված է: Ո՞վ է պատասխանատու դրա զարգացման համար: Դուք հասկանու՞մ եք ձեր ենթակառուցվածքային հարթակի մրցակցային առավելությունները:

Պետք է անընդհատ ինքներդ ձեզ տալ այս հարցերը. Եթե ​​ինչ-որ բան կարող է փոխանցվել երրորդ կողմի ծառայություններին, այն պետք է փոխանցվի, եթե երրորդ կողմի ծառայությունը սկսում է արգելափակել ձեր շարժումը, ապա դուք պետք է համակարգ կառուցեք ձեր ներսում:

Այսպիսով, DevOps...

... սա բարդ համակարգ է, այն պետք է ունենա.

• Թվային արտադրանք.
• Բիզնես մոդուլներ, որոնք զարգացնում են այս թվային արտադրանքը:
• Ապրանքի թիմեր, որոնք գրում են կոդը:
• Շարունակական առաքման պրակտիկա:
• Հարթակները որպես ծառայություն:
• Ենթակառուցվածքը որպես ծառայություն.
• Ենթակառուցվածքը որպես ծածկագիր:
• Հուսալիության պահպանման առանձին պրակտիկա՝ ներկառուցված DevOps-ում:
• Հետադարձ կապի պրակտիկա, որը նկարագրում է այդ ամենը:

Դուք կարող եք օգտագործել այս դիագրամը՝ դրանում ընդգծելով այն, ինչ դուք արդեն ունեք ձեր ընկերությունում ինչ-որ ձևով. այն մշակե՞լ է, թե՞ դեռ պետք է մշակվի:

Դա կավարտվի մի քանի շաբաթից DevOpsConf 2019 թ. որպես RIT++-ի մաս: Եկեք կոնֆերանսին, որտեղ դուք կգտնեք շատ հետաքրքիր զեկույցներ շարունակական առաքման, ենթակառուցվածքի որպես կոդի և DevOps-ի վերափոխման մասին: Ամրագրեք ձեր տոմսերը, գնի վերջին ժամկետը մայիսի 20-ն է

Source: www.habr.com