Պատկեր:
Բարեւ բոլորին! Մենք ընկերության ավտոմատացման ինժեներներ ենք և մենք աջակցում ենք ընկերության արտադրանքի զարգացմանը. մենք աջակցում ենք հավաքման ողջ խողովակաշարին՝ մշակողների կողմից կոդերի գծի հանձնումից մինչև պատրաստի արտադրանքի և լիցենզիաների հրապարակումը թարմացման սերվերների վրա: Ոչ պաշտոնական ձևով մենք կոչվում ենք DevOps ինժեներներ: Այս հոդվածում մենք ցանկանում ենք խոսել ծրագրային ապահովման արտադրության գործընթացի տեխնոլոգիական փուլերի մասին, թե ինչպես ենք դրանք տեսնում և ինչպես ենք դրանք դասակարգում։
Նյութից դուք կսովորեք բազմաբնույթ արտադրանքի մշակման համակարգման բարդության մասին, թե ինչ է իրենից ներկայացնում տեխնոլոգիական քարտեզը և ինչպես է այն օգնում պարզեցնել և կրկնօրինակել լուծումները, որոնք են զարգացման գործընթացի հիմնական փուլերն ու քայլերը, ինչպես են պատասխանատվության ոլորտները: DevOps-ի և մեր ընկերության թիմերի միջև:
Chaos-ի և DevOps-ի մասին
Հակիրճ, DevOps-ի հայեցակարգը ներառում է զարգացման գործիքներ և ծառայություններ, ինչպես նաև դրանց օգտագործման մեթոդաբանություններ և լավագույն փորձ: Առանձնացնենք գլոբալը նպատակ մեր ընկերությունում DevOps-ի գաղափարների իրականացումից. սա արտադրանքի արտադրության և պահպանման արժեքի հետևողական նվազում է քանակական առումով (մարդ-ժամ կամ մեքենայի ժամ, պրոցեսոր, RAM, սկավառակ և այլն): Ամբողջ ընկերության մակարդակով զարգացման ընդհանուր ծախսերը նվազեցնելու ամենադյուրին և ակնհայտ ձևն է նվազագույնի հասցնելով բնորոշ սերիական առաջադրանքների կատարման ծախսերը արտադրության բոլոր փուլերում։ Բայց որո՞նք են այդ փուլերը, ինչպե՞ս դրանք առանձնացնել ընդհանուր գործընթացից, ի՞նչ քայլերից են դրանք բաղկացած։
Երբ ընկերությունը մշակում է մեկ ապրանք, ամեն ինչ քիչ թե շատ պարզ է. սովորաբար կա ընդհանուր ճանապարհային քարտեզ և զարգացման սխեմա: Բայց ի՞նչ անել, երբ արտադրանքի գիծն ընդլայնվում է, և ավելի շատ ապրանքներ կան: Առաջին հայացքից նրանք ունեն նմանատիպ գործընթացներ և հավաքման գծեր, և սկսվում է «գտնել X տարբերությունները» խաղը տեղեկամատյաններում և սցենարներում: Բայց ի՞նչ, եթե արդեն կան 5+ նախագծեր ակտիվ մշակման փուլում, և մի քանի տարիների ընթացքում մշակված մի քանի տարբերակների համար անհրաժեշտ է աջակցություն: Արդյո՞ք մենք ցանկանում ենք վերօգտագործել առավելագույն հնարավոր քանակի լուծումներ արտադրանքի խողովակաշարերում, թե՞ պատրաստ ենք գումար ծախսել յուրաքանչյուրի համար յուրահատուկ մշակման վրա:
Ինչպե՞ս հավասարակշռություն գտնել եզակիության և սերիական լուծումների միջև:
Այս հարցերը մեր առջեւ ավելի ու ավելի հաճախ սկսեցին առաջանալ 2015 թվականից։ Արտադրանքների թիվն աճեց, և մենք փորձեցինք ընդլայնել մեր ավտոմատացման բաժինը (DevOps), որն աջակցում էր այս ապրանքների հավաքման գծերին՝ հասցնելով նվազագույնի: Միևնույն ժամանակ, մենք ցանկանում էինք հնարավորինս շատ լուծումներ կրկնել ապրանքների միջև: Ի վերջո, ինչու՞ նույն բանն անել տասը ապրանքների մեջ տարբեր ձևերով:
Զարգացման տնօրեն«Տղաներ, կարո՞ղ ենք ինչ-որ կերպ գնահատել, թե ինչ է անում DevOps-ը արտադրանքի համար»:
Մենք«Չգիտենք, նման հարց չենք տվել, բայց ի՞նչ ցուցանիշներ պետք է դիտարկել»։
Զարգացման տնօրեն: "Ով գիտի! Մտածեք…»
Ինչպես այդ հայտնի ֆիլմում. «Ես հյուրանոցում եմ...» - «Ըհը... Կարո՞ղ ես ինձ ճանապարհ ցույց տալ»: Մտածելով՝ եկանք այն եզրակացության, որ նախ պետք է որոշենք արտադրանքի վերջնական վիճակը. սա դարձավ մեր առաջին նպատակը:
Այսպիսով, ինչպե՞ս եք վերլուծում 10-ից 200 հոգանոց բավականին մեծ թիմերով տասնյակ ապրանքներ և լուծումներ կրկնելիս որոշել չափելի չափումներ:
1:0 հօգուտ Chaos-ի կամ DevOps-ի ուսի շեղբերների վրա
Մենք սկսեցինք BPwin շարքից IDEF0 դիագրամների և բիզնես գործընթացների տարբեր դիագրամների կիրառման փորձով: Շփոթմունքը սկսվեց հաջորդ նախագծի հաջորդ փուլի հինգերորդ քառակուսուց հետո, և յուրաքանչյուր նախագծի համար այս քառակուսիները կարող են գծվել երկար պիթոնի պոչում՝ 50+ քայլի տակ: Ես տխուր էի և ուզում էի ոռնալ լուսնի վրա, այն ընդհանրապես չէր տեղավորվում:
Տիպիկ արտադրական առաջադրանքներ
Արտադրական գործընթացների մոդելավորումը շատ բարդ և դժվարին աշխատանք է. անհրաժեշտ է հավաքել, մշակել և վերլուծել բազմաթիվ տվյալներ տարբեր բաժիններից և արտադրական շղթաներից: Այս մասին ավելին կարող եք կարդալ հոդվածում ».
Երբ մենք սկսեցինք մոդելավորել մեր արտադրական գործընթացը, մենք ունեինք հատուկ նպատակ՝ մեր ընկերության արտադրանքի մշակման մեջ ներգրավված յուրաքանչյուր աշխատակցին և ծրագրի ղեկավարներին փոխանցել.
- ինչպես են ապրանքները և դրանց բաղադրիչները, սկսած կոդային տողից, հասնում են հաճախորդին՝ տեղադրողների և թարմացումների տեսքով,
- ինչ ռեսուրսներ են տրամադրվում արտադրանքի արտադրության յուրաքանչյուր փուլի համար,
- ինչ ծառայություններ են ներգրավված յուրաքանչյուր փուլում,
- ինչպես են սահմանազատվում յուրաքանչյուր փուլի պատասխանատվության ոլորտները,
- ինչ պայմանագրեր կան յուրաքանչյուր փուլի մուտքի և ելքի ժամանակ:
Սեղմելով նկարի վրա այն կբացվի լրիվ չափով
Մեր աշխատանքը ընկերությունում բաժանված է մի քանի ֆունկցիոնալ ոլորտների: Ենթակառուցվածքի ուղղությունը զբաղվում է գերատեսչության բոլոր «երկաթե» ռեսուրսների շահագործման օպտիմալացմամբ, ինչպես նաև վիրտուալ մեքենաների և դրանց վրա շրջակա միջավայրի տեղակայման ավտոմատացմամբ։ Մոնիտորինգի ուղղությունը ապահովում է 24/7 ծառայության կատարողականի վերահսկում; մենք նաև մոնիտորինգ ենք տրամադրում որպես ծառայություն մշակողների համար: Աշխատանքային հոսքի ուղղությունը թիմերին տրամադրում է գործիքներ՝ կառավարելու զարգացման և թեստավորման գործընթացները, վերլուծելու կոդի վիճակը և նախագծերի վերլուծություն ստանալու համար: Եվ վերջապես, webdev ուղղությունը ապահովում է թողարկումների հրապարակում GUS և FLUS թարմացման սերվերների վրա, ինչպես նաև ապրանքների լիցենզավորում LicenseLab ծառայությունից: Արտադրական խողովակաշարին աջակցելու համար մենք ստեղծեցինք և պահպանում ենք բազմաթիվ տարբեր աջակցության ծառայություններ մշակողների համար (կարող եք լսել պատմություններ դրանցից մի քանիսի մասին հին հանդիպումներում. и). Մենք նաև մշակում ենք ներքին ավտոմատացման գործիքներ, այդ թվում .
Վերջին հինգ տարիների ընթացքում մեր աշխատանքը կուտակել է նույն տիպի և սովորական գործողություններ, և այլ գերատեսչություններից մեր մշակողները հիմնականում գալիս են այսպես կոչված. բնորոշ առաջադրանքներ, որի լուծումը ամբողջությամբ կամ մասնակի ավտոմատացված է, դժվարություններ չի առաջացնում կատարողների համար և չի պահանջում զգալի աշխատանք։ Առաջատար ոլորտների հետ միասին մենք վերլուծեցինք նման առաջադրանքները և կարողացանք բացահայտել աշխատանքի առանձին կատեգորիաները, կամ արտադրության քայլերը, փուլերը բաժանվեցին անբաժանելի քայլերի, և մի քանի փուլեր գումարվեցին արտադրական գործընթացի շղթա.
Տեխնոլոգիական շղթայի ամենապարզ օրինակը ընկերության ներսում մեր յուրաքանչյուր արտադրանքի հավաքման, տեղակայման և փորձարկման փուլերն են: Իր հերթին, օրինակ, կառուցման փուլը բաղկացած է բազմաթիվ առանձին տիպիկ քայլերից՝ աղբյուրների ներբեռնում GitLab-ից, կախվածությունների և երրորդ կողմի գրադարանների պատրաստում, միավորի փորձարկում և ստատիկ կոդի վերլուծություն, GitLab CI-ի վրա կառուցման սցենարի կատարում, պահեստում արտեֆակտների հրապարակում: Արտադրական և թողարկման նշումների ստեղծում մեր ներքին ChangelogBuilder գործիքի միջոցով:
Դուք կարող եք կարդալ DevOps-ի տիպիկ առաջադրանքների մասին Habré-ի մեր մյուս հոդվածներում."Եւ".
Շատ բնորոշ արտադրական շղթաներ են ձևավորվում արտադրական գործընթացը. Գործընթացների նկարագրության ստանդարտ մոտեցումը ֆունկցիոնալ IDEF0 մոդելների օգտագործումն է:
Արտադրական CI գործընթացի մոդելավորման օրինակ
Մենք հատուկ ուշադրություն դարձրինք շարունակական ինտեգրացիոն համակարգի համար ստանդարտ նախագծերի մշակմանը: Սա հնարավորություն տվեց հասնել նախագծերի միավորման՝ կարեւորելով այսպես կոչված թողարկման կառուցման սխեմա՝ առաջխաղացումներով.
Ահա թե ինչպես է այն աշխատում. Բոլոր նախագծերը բնորոշ տեսք ունեն. դրանք ներառում են հավաքների կոնֆիգուրացիա, որոնք ընկնում են Artifactory-ի snapshot-ի պահոցում, որից հետո դրանք տեղադրվում և փորձարկվում են թեստային նստարանների վրա, այնուհետև տեղափոխվում են թողարկման պահոց: Artifactory ծառայությունը միասնական բաշխման կետ է բոլոր կառուցված արտեֆակտների համար թիմերի և այլ ծառայությունների միջև:
Եթե մենք մեծապես պարզեցնում և ընդհանրացնում ենք մեր թողարկման սխեման, ապա այն ներառում է հետևյալ քայլերը.
- միջպլատֆորմային արտադրանքի հավաքում,
- տեղակայում փորձարկման նստարաններին,
- ֆունկցիոնալ և այլ թեստերի անցկացում,
- փորձարկված կառուցվածքների խթանում Artifactory-ում պահեստներ թողարկելու համար,
- թարմացման սերվերների վրա հիմնված թողարկման հրապարակում,
- հավաքների առաքում և արտադրության թարմացումներ,
- արտադրանքի տեղադրման և թարմացման մեկնարկը:
Օրինակ՝ դիտարկեք այս տիպիկ թողարկման սխեմայի (այսուհետ՝ մոդել) տեխնոլոգիական մոդելը ֆունկցիոնալ IDEF0 մոդելի տեսքով: Այն արտացոլում է մեր CI գործընթացի հիմնական փուլերը: IDEF0 մոդելները օգտագործում են այսպես կոչված ICOM նշում (Input-Control-Output-Mechanism) նկարագրելու համար, թե ինչ ռեսուրսներ են օգտագործվում յուրաքանչյուր փուլում, ինչ կանոնների և պահանջների հիման վրա է կատարվում աշխատանքը, որն է արդյունքը և ինչ մեխանիզմներ, ծառայություններ կամ մարդիկ են իրականացնում որոշակի փուլ:
Սեղմելով նկարի վրա այն կբացվի լրիվ չափով
Որպես կանոն, ֆունկցիոնալ մոդելներում ավելի հեշտ է քայքայել և մանրամասնել գործընթացների նկարագրությունը։ Բայց քանի որ տարրերի թիվը մեծանում է, ավելի ու ավելի դժվար է դառնում դրանցում ինչ-որ բան հասկանալը: Բայց իրական զարգացման մեջ կան նաև օժանդակ փուլեր՝ մոնիտորինգ, արտադրանքի սերտիֆիկացում, աշխատանքային հոսքի ավտոմատացում և այլն: Դա մասշտաբային խնդրի պատճառով է, որ մենք հրաժարվեցինք այս նկարագրությունից:
Հույսի ծնունդ
Մի գրքում մենք հանդիպեցինք հին խորհրդային քարտեզների, որոնք նկարագրում էին տեխնոլոգիական գործընթացները (որոնք, ի դեպ, այսօր էլ օգտագործվում են բազմաթիվ պետական ձեռնարկություններում և բուհերում): Սպասեք, սպասեք, որովհետև մենք նաև աշխատանքային հոսք ունենք: Կան փուլեր, արդյունքներ, չափումներ, պահանջներ, ցուցիչներ և այլն, և այլն… Ինչու՞ չփորձել հոսքաթերթեր կիրառել նաև մեր արտադրանքի խողովակաշարերում: Զգացողություն կար. «Սա այն է: Մենք գտել ենք ճիշտ թելը, ժամանակն է այն լավ քաշել:
Պարզ աղյուսակում մենք որոշեցինք արձանագրել ապրանքներն ըստ սյունակների, իսկ տեխնոլոգիական փուլերն ու արտադրանքի խողովակաշարը՝ քայլերն առ տող: Milestones-ը մեծ բան է, օրինակ՝ արտադրանքի կառուցման քայլը: Իսկ քայլերն ավելի փոքր և մանրամասն բան են, ինչպես օրինակ՝ սկզբնական կոդը build սերվերում ներբեռնելու կամ կոդը կազմելու քայլը:
Քարտեզի տողերի և սյունակների խաչմերուկներում մենք դնում ենք կարգավիճակները կոնկրետ փուլի և արտադրանքի համար: Կարգավիճակների համար սահմանվել է մի շարք պետություններ.
- Տեղեկատվություն չկան - կամ անպատշաճ: Անհրաժեշտ է վերլուծել արտադրանքի մի փուլի պահանջարկը: Կամ վերլուծությունն արդեն արված է, բայց փուլն այս պահին կարիք չունի կամ տնտեսապես հիմնավորված չէ։
- Հետաձգվել է - թե ոչ այս պահին։ Խողովակաշարի փուլ է պետք, բայց այս տարի իրականացման ուժեր չկան։
- Պլանավորված. Փուլը նախատեսվում է իրականացնել այս տարի։
- Իրականացվել է. Խողովակաշարում փուլն իրականացվում է անհրաժեշտ ծավալով:
Աղյուսակի լրացումը սկսվեց նախագիծ առ նախագիծ: Նախ դասակարգվել են մեկ նախագծի փուլերն ու քայլերը և արձանագրվել դրանց կարգավիճակը: Հետո վերցրեցին հաջորդ նախագիծը, դրանում ֆիքսեցին կարգավիճակներն ու ավելացրին այն փուլերն ու քայլերը, որոնք բացակայում էին նախորդ նախագծերում։ Արդյունքում մենք ստացանք մեր ամբողջ արտադրական խողովակաշարի փուլերն ու քայլերը և դրանց կարգավիճակները կոնկրետ նախագծում։ Պարզվեց, որ նման է արտադրանքի խողովակաշարի իրավասության մատրիցային: Նման մատրիցը մենք անվանեցինք տեխնոլոգիական քարտեզ։
Տեխնոլոգիական քարտեզի օգնությամբ մենք թիմերի հետ չափագիտական ողջամտորեն համակարգում ենք տարվա աշխատանքային պլանները և նպատակները, որոնց ցանկանում ենք հասնել միասին. որ փուլերն ենք ավելացնում նախագծին այս տարի, և որոնք ենք թողնում ավելի ուշ: Նաև աշխատանքի ընթացքում կարող ենք բարելավումներ ունենալ այն փուլերում, որոնք ավարտել ենք միայն մեկ ապրանքի համար։ Այնուհետև մենք ընդլայնում ենք մեր քարտեզը և ներկայացնում այս բարելավումը որպես փուլ կամ նոր քայլ, այնուհետև մենք վերլուծում ենք յուրաքանչյուր ապրանքի համար և պարզում ենք բարելավումը կրկնելու իրագործելիությունը:
Նրանք կարող են առարկել մեզ. «Այս ամենը, իհարկե, լավ է, միայն թե ժամանակի ընթացքում քայլերի ու փուլերի թիվն անարգելի մեծանա։ Ինչպե՞ս լինել:
Մենք ներկայացրել ենք յուրաքանչյուր փուլի և քայլի պահանջների ստանդարտ և բավականին ամբողջական նկարագրություններ, որպեսզի դրանք բոլորի կողմից ընկալվեն ընկերության ներսում նույն ձևով: Ժամանակի ընթացքում, երբ բարելավումներ են մտցվում, քայլը կարող է ներծծվել մեկ այլ փուլի կամ քայլի մեջ, իսկ հետո դրանք «կփլուզվեն»: Միևնույն ժամանակ, բոլոր պահանջներն ու տեխնոլոգիական նրբությունները տեղավորվում են ընդհանրացնող փուլի կամ քայլի պահանջների մեջ։
Ինչպե՞ս գնահատել լուծույթների կրկնօրինակման ազդեցությունը: Մենք օգտագործում ենք չափազանց պարզ մոտեցում. նոր փուլի իրականացման համար սկզբնական կապիտալ ծախսերը վերագրում ենք արտադրանքի տարեկան ընդհանուր ծախսերին, այնուհետև կրկնօրինակելիս բաժանում ենք բոլորի վրա:
Զարգացման մասերն արդեն ցուցադրվում են որպես ուղենիշներ և քայլեր քարտեզի վրա: Մենք կարող ենք ազդել արտադրանքի ինքնարժեքի նվազեցման վրա՝ բնորոշ փուլերի համար ավտոմատացման ներդրման միջոցով: Դրանից հետո մենք դիտարկում ենք որակական բնութագրերի, քանակական ցուցանիշների և թիմերի ստացած շահույթի փոփոխությունները (մարդ-ժամ կամ խնայողությունների մեքենա-ժամ):
Արտադրության գործընթացի տեխնոլոգիական քարտեզ
Եթե մենք կատարենք մեր բոլոր փուլերն ու քայլերը, կոդավորենք դրանք պիտակներով և ընդլայնենք դրանք մեկ շղթայի մեջ, ապա դա շատ երկար և անհասկանալի կստացվի (պարզապես նույն «պիթոնի պոչը», որի մասին խոսեցինք հոդվածի սկզբում) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Սրանք արտադրանքի կառուցման փուլերն են [Կառուցել], դրանք տեղակայել սերվերների փորձարկման համար [Տեղակայել], փորձարկել [Թեստ], կառուցումներ խթանել՝ փորձարկման արդյունքների հիման վրա պահեստներ թողարկելու համար [Խթանել], լիցենզիաներ ստեղծել և հրապարակել [Լիցենզիա], հրատարակել [ Հրապարակել] GUS թարմացման սերվերում և առաքում FLUS թարմացման սերվերներին, արտադրանքի բաղադրիչների տեղադրում և թարմացում հաճախորդի ենթակառուցվածքում` օգտագործելով Product Configuration Management [Install], ինչպես նաև հեռաչափության հավաքում [Telemetry] տեղադրված արտադրանքներից:
Դրանցից բացի, կարելի է առանձնացնել առանձին փուլեր՝ ենթակառուցվածքի վիճակի մոնիտորինգ [InfMonitoring], սկզբնական կոդի տարբերակում [SourceCodeControl], կառուցման միջավայրի պատրաստում [Պատրաստել], նախագծի կառավարում [Աշխատանքային հոսք], թիմերին հաղորդակցման գործիքներով տրամադրում [Հաղորդակցություն], արտադրանքի հավաստագրում [ Հավաստագրում] և CI գործընթացների ինքնաբավության ապահովում [CISelfSufficiency] (օրինակ՝ հավաքների անկախությունը ինտերնետից): Մեր գործընթացներում տասնյակ քայլեր չեն էլ դիտարկվելու, քանի որ դրանք շատ կոնկրետ են։
Շատ ավելի հեշտ կլինի հասկանալ և դիտել ամբողջ արտադրական գործընթացը, եթե այն ներկայացվի ձևով տեխնոլոգիական քարտեզ; սա աղյուսակ է, որտեղ Մոդելի արտադրության առանձին փուլերը և քայքայված քայլերը գրված են տողերով, իսկ սյունակներում՝ նկարագրությունը, թե ինչ է արվում յուրաքանչյուր փուլում կամ քայլում: Հիմնական շեշտը դրվում է յուրաքանչյուր փուլ ապահովող ռեսուրսների և պատասխանատվության ոլորտների սահմանազատման վրա:
Քարտեզը մեզ համար մի տեսակ դասակարգիչ է։ Այն արտացոլում է արտադրանքի արտադրության խոշոր տեխնոլոգիական մասերը։ Դրա շնորհիվ մեր ավտոմատացման թիմի համար ավելի հեշտ դարձավ շփվել ծրագրավորողների հետ և համատեղ պլանավորել ավտոմատացման փուլերի իրականացումը, ինչպես նաև հասկանալ, թե ինչ աշխատանքային ծախսեր և ռեսուրսներ (մարդկային և ապարատային) կպահանջվեն դրա համար:
Մեր ընկերության ներսում քարտեզը ավտոմատ կերպով ստեղծվում է jinja կաղապարից՝ որպես սովորական HTML ֆայլ, այնուհետև վերբեռնվում է GitLab Pages սերվեր: Կարող է դիտվել ամբողջությամբ ստեղծված քարտեզի օրինակով սքրինշոթ .
Սեղմելով նկարի վրա այն կբացվի լրիվ չափով
Մի խոսքով, տեխնոլոգիական քարտեզը արտադրության գործընթացի ընդհանրացված պատկերն է, որն արտացոլում է հստակ դասակարգված բլոկներ՝ բնորոշ ֆունկցիոնալությամբ։
Մեր ճանապարհային քարտեզի կառուցվածքը
Քարտեզը բաղկացած է մի քանի մասից.
- Վերնագրի տարածք - այստեղ ներկայացված է քարտեզի ընդհանուր նկարագրությունը, ներկայացվում են հիմնական հասկացությունները, սահմանվում են արտադրական գործընթացի հիմնական ռեսուրսները և արդյունքները:
- Վահանակ - այստեղ դուք կարող եք վերահսկել առանձին ապրանքների տվյալների ցուցադրումը, ներկայացված է բոլոր ապրանքների համար իրականացված փուլերի և ընդհանուր քայլերի ամփոփագիրը:
- Տեխնոլոգիական քարտեզ - տեխնոլոգիական գործընթացի աղյուսակային նկարագրություն: Քարտեզի վրա.
- տրված են բոլոր փուլերը, քայլերը և դրանց ծածկագրերը.
- Տրված են փուլերի կարճ և ամբողջական նկարագրությունները.
- նշված են յուրաքանչյուր փուլում օգտագործվող մուտքային ռեսուրսները և ծառայությունները.
- նշվում են յուրաքանչյուր փուլի արդյունքները և առանձին քայլը.
- նշված է յուրաքանչյուր փուլի և քայլի համար պատասխանատվության ոլորտը.
- որոշվել են տեխնիկական ռեսուրսները, ինչպիսիք են HDD-ը (SSD), RAM-ը, vCPU-ն և աշխատաժամանակները, որոնք անհրաժեշտ են այս փուլում աշխատանքին աջակցելու համար, և՛ ներկա պահին՝ փաստ, և՛ ապագայում՝ պլան.
- յուրաքանչյուր ապրանքի համար նշվում է, թե դրա համար որ տեխնոլոգիական փուլերը կամ քայլերն են իրականացվել, ծրագրված են իրականացման համար, անտեղի կամ չկատարված։
Տեխնոլոգիական քարտեզի հիման վրա որոշումների կայացում
Քարտեզը ուսումնասիրելուց հետո հնարավոր է ձեռնարկել որոշ գործողություններ՝ կախված ընկերությունում աշխատողի դերից (զարգացման մենեջեր, արտադրանքի մենեջեր, մշակող կամ փորձարկող).
- հասկանալ, թե ինչ փուլեր են բացակայում իրական արտադրանքում կամ նախագծում և գնահատել դրանց իրականացման անհրաժեշտությունը.
- սահմանազատել պատասխանատվության ոլորտները մի քանի գերատեսչությունների միջև, եթե նրանք աշխատում են տարբեր փուլերում.
- պայմանագրեր համաձայնեցնել փուլերի մուտքերի և ելքերի վերաբերյալ.
- ինտեգրել ձեր աշխատանքի փուլը ընդհանուր զարգացման գործընթացին.
- ավելի ճշգրիտ գնահատել ռեսուրսների անհրաժեշտությունը, որոնք ապահովում են փուլերից յուրաքանչյուրը:
Ամփոփելով վերը նշված բոլորը
Երթուղին բազմակողմանի է, ընդարձակելի և հեշտ է պահպանել: Շատ ավելի հեշտ է մշակել և պահպանել գործընթացների նկարագրությունը այս ձևով, քան խիստ ակադեմիական IDEF0 մոդելում: Բացի այդ, աղյուսակային նկարագրությունն ավելի պարզ է, ավելի ծանոթ և ավելի լավ կառուցված, քան ֆունկցիոնալ մոդելը:
Քայլերի տեխնիկական իրականացման համար մենք ունենք CrossBuilder հատուկ ներքին գործիք՝ շերտավոր գործիք CI համակարգերի, ծառայությունների և ենթակառուցվածքների միջև: Մշակողը կարիք չունի կտրելու իր հեծանիվը. մեր CI համակարգում բավական է գործարկել CrossBuilder գործիքի սցենարներից մեկը (այսպես կոչված առաջադրանքը), որը ճիշտ կկատարի այն՝ հաշվի առնելով մեր ենթակառուցվածքի առանձնահատկությունները։ .
Արդյունքները
Հոդվածը բավականին երկար է ստացվել, բայց դա անխուսափելի է բարդ գործընթացների մոդելավորումը նկարագրելիս։ Վերջում ես կցանկանայի համառոտ ամրագրել մեր հիմնական գաղափարները.
- Մեր ընկերությունում DevOps գաղափարների ներդրման նպատակն է հետևողականորեն նվազեցնել ընկերության արտադրանքի արտադրության և պահպանման ծախսերը քանակական առումով (մարդ-ժամ կամ մեքենայի ժամ, vCPU, RAM, Disk):
- Մշակման ընդհանուր ծախսերը նվազեցնելու ճանապարհը տիպիկ սերիական առաջադրանքների կատարման ծախսերի նվազագույնի հասցնելն է՝ տեխնոլոգիական գործընթացի փուլերն ու քայլերը:
- Տիպիկ առաջադրանքն այն խնդիրն է, որի լուծումը ամբողջությամբ կամ մասամբ ավտոմատացված է, դժվարություններ չի առաջացնում կատարողների համար և չի պահանջում զգալի աշխատանքային ծախսեր:
- Արտադրական գործընթացը բաղկացած է փուլերից, փուլերը բաժանվում են անբաժանելի քայլերի, որոնք տարբեր մասշտաբի և ծավալի բնորոշ առաջադրանքներ են։
- Տարբեր բնորոշ առաջադրանքներից մենք հասել ենք բարդ տեխնոլոգիական շղթաների և արտադրության գործընթացի բազմամակարդակ մոդելների, որոնք կարելի է նկարագրել ֆունկցիոնալ IDEF0 մոդելով կամ ավելի պարզ տեխնոլոգիական քարտեզով:
- Տեխնոլոգիական քարտեզը արտադրական գործընթացի փուլերի և քայլերի աղյուսակային ներկայացումն է։ Ամենակարևորը՝ քարտեզը թույլ է տալիս տեսնել ամբողջ գործընթացը ամբողջությամբ՝ մեծ կտորներով՝ դրանք մանրամասնելու հնարավորությամբ։
- Տեխնոլոգիական քարտեզի հիման վրա հնարավոր է գնահատել որոշակի ապրանքի մեջ փուլերի ներդրման անհրաժեշտությունը, ուրվագծել պատասխանատվության ոլորտները, համաձայնեցնել պայմանագրեր փուլերի մուտքերի և ելքերի վերաբերյալ և ավելի ճշգրիտ գնահատել ռեսուրսների անհրաժեշտությունը:
Հաջորդ հոդվածներում մենք ավելի մանրամասն կներկայացնենք, թե ինչ տեխնիկական գործիքներ են օգտագործվում մեր քարտեզի վրա որոշակի տեխնոլոգիական փուլեր իրականացնելու համար:
Հոդվածի հեղինակներ.
- — Positive Technologies-ի ավտոմատացման (DevOps) ղեկավար
- - Պատգամավոր Positive Technologies-ի ավտոմատացման բաժնի (DevOps) ղեկավար
Source: www.habr.com