«Ինչպես իրականացնել devops» հարցը տարիներ շարունակ եղել է, բայց շատ լավ նյութեր չկան: Երբեմն դուք դառնում եք ոչ այնքան խելացի խորհրդատուների գովազդների զոհը, ովքեր պետք է վաճառեն իրենց ժամանակը, անկախ նրանից, թե ինչպես: Երբեմն սրանք անորոշ, չափազանց ընդհանուր խոսքեր են այն մասին, թե ինչպես են մեգակորպորացիաների նավերը հերկում տիեզերքի տարածությունները: Հարց է առաջանում՝ սա ի՞նչ նշանակություն ունի մեզ համար։ Հարգելի հեղինակ, կարո՞ղ եք հստակ ձևակերպել ձեր գաղափարները ցուցակով:
Այս ամենը բխում է նրանից, որ շատ քիչ իրական պրակտիկա և ընկերության մշակույթի փոխակերպումների արդյունքի ըմբռնում է կուտակվել: Մշակույթի փոփոխությունները երկարաժամկետ բաներ են, որոնց արդյունքը մեկ շաբաթից կամ մեկ ամսից չի երևա։ Մեզ պետք է այնքան մեծ մեկը, ով տեսնի, թե ինչպես են ընկերությունները կառուցվել և ձախողվել տարիների ընթացքում:
Ջոն Ուիլիս - DevOps-ի հայրերից մեկը: Ջոնն ունի հսկայական թվով ընկերությունների հետ աշխատելու տասնամյակների փորձ: Վերջերս Ջոնը սկսեց նկատել կոնկրետ օրինաչափություններ, որոնք տեղի են ունենում նրանցից յուրաքանչյուրի հետ աշխատելիս: Օգտագործելով այս արխետիպերը՝ Ջոնն ուղղորդում է ընկերություններին DevOps-ի վերափոխման իրական ճանապարհով: Ավելին կարդացեք այս արխետիպերի մասին DevOops 2018 կոնֆերանսի նրա զեկույցի թարգմանության մեջ:
Բանախոսի մասին.
Ավելի քան 35 տարի ՏՏ կառավարման ոլորտում, Canonical-ում մասնակցել է OpenCloud-ի նախորդի ստեղծմանը, մասնակցել է 10 ստարտափի, որոնցից երկուսը վաճառվել են Dell-ին և Docker-ին։ Ներկայումս նա SJ Technologies-ի DevOps-ի և թվային պրակտիկայի փոխնախագահն է:
Հաջորդը Ջոնի տեսանկյունից պատմությունն է։
Իմ անունը Ջոն Ուիլիսն է, և ինձ գտնելու ամենահեշտ վայրը Twitter-ն է, . Ես նույն կեղծանունն ունեմ Gmail-ում և GitHub-ում: Ա դուք կարող եք գտնել իմ զեկույցների տեսագրություններն ու ներկայացումները նրանց համար:
Ես բազմաթիվ հանդիպումներ եմ ունենում տարբեր խոշոր ընկերությունների CIO-ների հետ: Նրանք շատ հաճախ դժգոհում են, որ չեն հասկանում, թե ինչ է DevOps-ը, և բոլորը, ովքեր փորձում են դա բացատրել իրենց, խոսում են այլ բանի մասին: Մեկ այլ ընդհանուր բողոք այն է, որ DevOps-ը չի աշխատում, թեև թվում է, թե տնօրեններն ամեն ինչ անում են այնպես, ինչպես բացատրել են իրենց: Խոսքը հարյուրից ավելի տարեկան խոշոր ընկերությունների մասին է։ Նրանց հետ զրուցելուց հետո ես եկա այն եզրակացության, որ շատ խնդիրների դեպքում ոչ թե բարձր տեխնոլոգիաներն են լավագույնս համապատասխանում, այլ համեմատաբար ցածր տեխնոլոգիական լուծումները: Շաբաթներ շարունակ ես պարզապես զրուցում էի տարբեր գերատեսչությունների մարդկանց հետ: Այն, ինչ տեսնում եք գրառման հենց առաջին նկարում, իմ վերջին նախագիծն է, ահա թե ինչպիսի տեսք ուներ սենյակը երեք օր աշխատելուց հետո։
Ի՞նչ է DevOps-ը:
Իսկապես, եթե դուք հարցնեք 10 տարբեր մարդկանց, նրանք կտան 10 տարբեր պատասխաններ։ Բայց ահա հետաքրքիրը. այս տասը պատասխանները ճիշտ կլինեն: Այստեղ սխալ պատասխան չկա։ Ես բավականին խորն էի DevOps-ի մեջ մոտ 10 տարի և առաջին ամերիկացին էի առաջին DevOpsDay-ում: Ես չեմ ասի, որ ես ավելի խելացի եմ, քան բոլորը, ովքեր ներգրավված են DevOps-ում, բայց հազիվ թե գտնվի մեկը, ով այդքան ջանք է ծախսել դրա վրա: Կարծում եմ, որ DevOps-ն առաջանում է, երբ մարդկային կապիտալն ու տեխնոլոգիան միավորվում են: Մենք հաճախ մոռանում ենք մարդկային հարթության մասին, թեև շատ ենք խոսում բոլոր տեսակի մշակույթների մասին:
Այժմ մենք ունենք շատ տվյալներ, հինգ տարվա ակադեմիական հետազոտություն, տեսությունների փորձարկում արդյունաբերական մասշտաբով։ Այն, ինչ մեզ ասում են այս ուսումնասիրությունները, այն է, որ եթե դուք համատեղում եք որոշ վարքագծային օրինաչափություններ կազմակերպչական մշակույթում, կարող եք հասնել 2000 անգամ արագացման: Այս արագացումը համընկնում է կայունության հավասար բարելավմամբ: Սա օգուտի քանակական չափումն է, որը DevOps-ը կարող է բերել ցանկացած ընկերության: Մի քանի տարի առաջ ես խոսում էի DevOps-ի մասին Fortune 5000 ընկերության գործադիր տնօրենի հետ, երբ պատրաստվում էի շնորհանդեսին, ես շատ էի նյարդայնանում, քանի որ պետք է 5 րոպեում ամփոփեի իմ տարիների փորձը։
Վերջում ես տվեցի հետևյալը DevOps-ի սահմանումՍա պրակտիկաների և օրինաչափությունների մի շարք է, որոնք հնարավորություն են տալիս մարդկային կապիտալը վերածել բարձր արդյունավետության կազմակերպչական կապիտալի: Օրինակ՝ Toyota-ն գործել է վերջին 50 կամ 60 տարիների ընթացքում:
(Այսուհետ, նման գծապատկերները տրամադրվում են ոչ թե որպես տեղեկատու նյութ, այլ որպես նկարազարդումներ: Նրանց բովանդակությունը տարբերվում է յուրաքանչյուր նոր ընկերության համար: Այնուամենայնիվ, նկարը կարելի է դիտել առանձին և ընդլայնել:
Ամենահաջող նման պրակտիկաներից մեկն է արժեքի հոսքի քարտեզագրում. Այս մասին մի քանի լավ գրքեր են գրվել, որոնցից ամենահաջողը Կարեն Մարտինի հեղինակն է։ Սակայն վերջին մեկ տարվա ընթացքում ես եկել եմ այն եզրակացության, որ նույնիսկ այս մոտեցումը չափազանց բարձր տեխնոլոգիական է: Այն, իհարկե, շատ առավելություններ ունի, և ես շատ եմ օգտագործել այն: Բայց երբ գործադիր տնօրենը հարցնում է ձեզ, թե ինչու իր ընկերությունը չի կարող անցնել նոր ռելսերի, դեռ վաղ է խոսել արժեքային հոսքերի քարտեզագրման մասին: Կան շատ ավելի հիմնարար հարցեր, որոնց նախ պետք է պատասխանել:
Կարծում եմ, որ իմ գործընկերներից շատերի սխալն այն է, որ նրանք պարզապես ընկերությանը տալիս են հինգ կետից բաղկացած ուղեցույց, իսկ հետո վերադառնում են վեց ամիս հետո և տեսնում, թե ինչ է տեղի ունեցել: Նույնիսկ այնպիսի լավ սխեման, ինչպիսին արժեքային հոսքերի քարտեզագրումն է, ունի, ասենք, կույր կետեր: Տարբեր ընկերությունների տնօրենների հետ հարյուրավոր հարցազրույցներից հետո ես մշակել եմ որոշակի օրինաչափություն, որը թույլ է տալիս խնդիրը բաժանել իր բաղադրիչների, և այժմ մենք կքննարկենք այս բաղադրիչներից յուրաքանչյուրը հերթականությամբ: Մինչև որևէ տեխնոլոգիական լուծում կիրառելը ես օգտագործում եմ այս նախշը, և արդյունքում իմ բոլոր պատերը ծածկված են գծապատկերներով։ Վերջերս ես աշխատում էի փոխադարձ հիմնադրամի հետ և 100-150 նման սխեմաների հայտնվեցի։
Վատ մշակույթը նախաճաշին լավ մոտեցումներ է ուտում
Հիմնական գաղափարը հետևյալն է. Lean, Agile, SAFE և DevOps-ները չեն օգնի, եթե կազմակերպության մշակույթն ինքնին վատ է: Դա նման է սուզվելու խորություններին՝ առանց սկուբա սարքավորումների կամ գործել առանց ռենտգենի: Այլ կերպ ասած, Դրակերին և Դեմինգին վերափոխելու համար՝ կազմակերպչական վատ մշակույթը կուլ կտա ցանկացած լավ համակարգ՝ չխեղդելով այն:
Այս հիմնական խնդիրը լուծելու համար դուք պետք է կատարեք հետևյալ քայլերը.
- Բոլոր աշխատանքները տեսանելի դարձնել՝ դուք պետք է տեսանելի դարձնեք բոլոր աշխատանքները: Ոչ այն առումով, որ այն անպայման պետք է ցուցադրվի ինչ-որ էկրանի վրա, այլ այն իմաստով, որ այն պետք է դիտարկելի լինի։
- Աշխատանքի կառավարման համախմբված համակարգեր. կառավարման համակարգերը պետք է համախմբվեն: «Ցեղային» գիտելիքի և ինստիտուցիոնալ գիտելիքների հարցում 9-ից 10-ի դեպքում խցանը մարդիկ են։ Գրքում Խնդիրը մեկ միայնակ անձի՝ Բրենտի հետ էր, ով պատճառ դարձավ, որ նախագիծը երեք տարով հետ մնա: Եվ ես ամենուր հանդիպում եմ այս «Բրենթներին»: Այս խցանումները լուծելու համար ես օգտագործում եմ մեր ցուցակի հաջորդ երկու կետերը:
- Սահմանափակումների տեսություն Մեթոդաբանություն. սահմանափակումների տեսություն.
- Համագործակցության հաքեր. համագործակցության հաքեր.
- Toyota Kata (): Ես շատ չեմ խոսի Toyota Kata-ի մասին: Եթե հետաքրքրված է, իմ github-ում այս թեմաներից գրեթե յուրաքանչյուրի վերաբերյալ:
- Շուկան ուղղված կազմակերպություն. շուկայական ուղղվածություն ունեցող կազմակերպություն.
- Shift-ձախ աուդիտորներ. աուդիտ ցիկլի վաղ փուլերում:
Ես սկսում եմ աշխատել կազմակերպության հետ շատ պարզ՝ գնում եմ ընկերություն և զրուցում աշխատակիցների հետ։ Ինչպես տեսնում եք, ոչ մի բարձր տեխնոլոգիա: Ձեզ անհրաժեշտ է միայն ինչ-որ բան գրել: Ես հավաքում եմ մի քանի թիմ մեկ սենյակում և վերլուծում այն, ինչ նրանք ինձ ասում են իմ 7 արխետիպերի տեսանկյունից: Եվ հետո ես նրանց տալիս եմ մարկեր և խնդրում եմ գրատախտակին գրել այն ամենը, ինչ նրանք բարձրաձայն ասել են մինչ այժմ: Սովորաբար նման տիպի հանդիպումներում լինում է մեկ մարդ, ով գրում է ամեն ինչ, իսկ լավագույն դեպքում կարող է գրել քննարկման 10%-ը։ Իմ մեթոդով այս ցուցանիշը կարելի է հասցնել մոտ 40%-ի։
(Այս նկարազարդումը կարելի է դիտել առանձին )
Իմ մոտեցումը հիմնված է Ուիլյամ Շնայդերի աշխատանքի վրա։ ) Մոտեցումը հիմնված է այն գաղափարի վրա, որ ցանկացած կազմակերպություն կարելի է բաժանել չորս քառակուսուների։ Այս սխեման ինձ համար սովորաբար այն հարյուրավոր այլ սխեմաների հետ աշխատելու արդյունք է, որոնք առաջանում են կազմակերպությունը վերլուծելիս: Ենթադրենք, մենք ունենք բարձր մակարդակի վերահսկողություն ունեցող, բայց ցածր կոմպետենտություն ունեցող կազմակերպություն։ Սա չափազանց անցանկալի տարբերակ է. երբ բոլորը ոտքի վրա են, բայց ոչ ոք չգիտի, թե ինչ անել:
Մի փոքր ավելի լավ տարբերակն այն է, որն ունի և՛ վերահսկողության, և՛ իրավասության բարձր մակարդակ: Եթե նման ընկերությունը շահութաբեր է, ապա թերևս DevOps-ի կարիքը չունի։ Առավել հետաքրքիր է աշխատել մի ընկերության հետ, որն ունի վերահսկման բարձր մակարդակ, ցածր կոմպետենտություն և համագործակցություն, բայց միևնույն ժամանակ բարձր մակարդակի մշակույթ (մշակույթ): Սա նշանակում է, որ ընկերությունն ունի շատ մարդիկ, ովքեր սիրում են այնտեղ աշխատել, և աշխատուժի շրջանառությունը ցածր է։
(Այս նկարազարդումը կարելի է դիտել առանձին )
Ինձ թվում է, որ կոշտ ուղեցույցներով մեթոդներն ի վերջո խոչընդոտում են ճշմարտությանը հասնելու ճանապարհին: Հատկապես արժեքային հոսքերի քարտեզագրման մեջ կան բազմաթիվ կանոններ, որոնք վերաբերում են տեղեկատվության կառուցվածքին: Աշխատանքի վաղ փուլերում, որի մասին ես հիմա խոսում եմ, այս կանոնները ոչ մեկին պետք չեն: Եթե մարդը, ում ձեռքին մարկեր է, նկարագրում է ընկերության իրական իրավիճակը խորհրդի վրա, սա լավագույն միջոցն է հասկանալու գործերի վիճակը: Նման տեղեկություն տնօրեններին չի հասնում։ Այս պահին հիմարություն է մարդուն ընդհատելն ու ասել, որ նա ինչ-որ նետ սխալ է նկարել։ Այս փուլում ավելի լավ է օգտագործել պարզ կանոններ, օրինակ՝ բազմամակարդակ աբստրակցիա կարելի է ստեղծել պարզապես՝ օգտագործելով բազմագույն մարկերներ։
Կրկնում եմ՝ ոչ մի բարձր տեխնոլոգիա։ Սև մարկերը պատկերում է օբյեկտիվ իրականությունը, թե ինչպես է ամեն ինչ աշխատում: Կարմիր մարկերով մարդիկ նշում են այն, ինչ իրենց դուր չի գալիս ներկայիս իրավիճակում: Կարեւոր է, որ սա գրեն, ոչ թե ես։ Երբ հանդիպումից հետո գնում եմ CIO, ես չեմ առաջարկում 10 բաների ցանկ, որոնք պետք է շտկվեն: Ես ձգտում եմ կապեր գտնել ընկերության մարդկանց ասածների և գոյություն ունեցող ապացուցված օրինաչափությունների միջև: Վերջապես, կապույտ մարկերը առաջարկում է խնդրի հնարավոր լուծումներ:
(Այս նկարազարդումը կարելի է դիտել առանձին )
Այս մոտեցման օրինակն այժմ ներկայացված է վերևում: Այս տարվա սկզբին ես աշխատել եմ մեկ բանկի հետ։ Այնտեղ անվտանգության աշխատակիցները համոզված էին, որ չպետք է գան նախագծման և պահանջների վերանայման։
(Այս նկարազարդումը կարելի է դիտել առանձին )
Եվ հետո մենք խոսեցինք այլ գերատեսչությունների մարդկանց հետ և պարզվեց, որ մոտ 8 տարի առաջ ծրագրային ապահովման մշակողները աշխատանքից ազատել են անվտանգության աշխատողներին, քանի որ նրանք դանդաղեցնում էին աշխատանքը: Իսկ հետո այն վերածվեց արգելքի, որը ընկալվեց որպես բնականոն։ Չնայած իրականում արգելք չի եղել։
Մեր հանդիպումն ընթացավ ծայրաստիճան շփոթեցնող ձևով. մոտ երեք ժամ հինգ տարբեր թիմեր չկարողացան ինձ բացատրել, թե ինչ է կատարվում կոդի և ժողովի միջև: Եվ սա ամենապարզ բանն է թվում: DevOps-ի խորհրդատուների մեծ մասը նախապես ենթադրում է, որ բոլորն արդեն գիտեն դա:
Հետո ՏՏ կառավարման պատասխանատուն, ով չորս ժամ լռում էր, հանկարծ կենդանացավ, երբ հասանք իր թեմային, ու շատ երկար զբաղեցրեց մեզ։ Վերջում հարցրի, թե ինչ է մտածում հանդիպման մասին, և երբեք չեմ մոռանա նրա պատասխանը։ Նա ասաց. «Ես կարծում էի, որ մեր բանկը ծրագրային ապահովման մատակարարման միայն երկու տարբերակ ունի, բայց հիմա գիտեմ, որ դրանք հինգն են, և ես նույնիսկ չգիտեի երեքի մասին»:
(Այս նկարազարդումը կարելի է դիտել առանձին )
Այս բանկում վերջին հանդիպումը ներդրումային ծրագրերի թիմի հետ էր: Նրա հետ էր, որ պարզվեց, որ թղթի թերթիկի վրա մարկերով դիագրամներ գրելն ավելի լավ է, քան տախտակի վրա, և նույնիսկ ավելի լավ, քան խելացի տախտակի վրա:
Լուսանկարները, որոնք դուք տեսնում եք, այնպիսին է, թե ինչպիսի տեսք ուներ հյուրանոցի կոնֆերանսների սենյակը մեր հանդիպման չորրորդ օրը: Եվ մենք օգտագործեցինք այս սխեմաները նախշերի, այսինքն՝ արխետիպերի որոնման համար:
Այսպիսով, ես հարցեր եմ տալիս աշխատողներին, նրանք գրում են պատասխանները երեք գույների (սև, կարմիր և կապույտ) մարկերներով: Ես վերլուծում եմ նրանց պատասխանները արխետիպերի համար: Այժմ եկեք քննարկենք բոլոր արխետիպերը հերթականությամբ։
1. Բոլոր աշխատանքները տեսանելի դարձնել. աշխատանքը տեսանելի դարձնել
Շատ ընկերություններ, որոնց հետ ես աշխատում եմ, ունեն անհայտ աշխատանքի շատ բարձր տոկոս: Օրինակ, սա այն դեպքն է, երբ մի աշխատակից գալիս է մյուսին և պարզապես խնդրում է ինչ-որ բան անել: Խոշոր կազմակերպություններում կարող է լինել 60% չպլանավորված աշխատանք։ Իսկ աշխատանքների մինչեւ 40 տոկոսը որեւէ կերպ փաստաթղթավորված չէ։ Եթե դա լիներ Boeing, ես այլևս երբեք չէի նստի նրանց ինքնաթիռ իմ կյանքում։ Եթե աշխատանքի միայն կեսն է փաստաթղթավորված, ապա հայտնի չէ՝ այս աշխատանքը ճի՞շտ է կատարվում, թե՞ ոչ։ Մնացած բոլոր մեթոդներն անօգուտ են. իմաստ չունի փորձել ինչ-որ բան ավտոմատացնել, քանի որ հայտնի 50%-ը կարող է լինել աշխատանքի ամենահամահունչ և հստակ մասը, որի ավտոմատացումը մեծ արդյունքներ չի տա, և ամենավատը: բաները գտնվում են անտեսանելի կեսում: Փաստաթղթերի բացակայության պայմաններում հնարավոր չէ գտնել ամենատարբեր հաքեր և թաքնված աշխատանք, չգտնել խցանումներ, հենց այդ «Բրենթները», որոնց մասին արդեն խոսեցի։ Դոմինիկա Դե Գրանդիսի հրաշալի գիրք կա . Նա բացահայտում է հինգ տարբեր «ժամանակի արտահոսք» (ժամանակի գողեր):
- Չափազանց շատ աշխատանք (WIP)
- Անհայտ կախվածություններ
- Չպլանավորված աշխատանք
- Հակասական առաջնահերթություններ
- Անտեսված աշխատանք
Սա շատ արժեքավոր վերլուծություն է, և գիրքը հիանալի է, բայց այս բոլոր խորհուրդներն անօգուտ են, եթե տեսանելի է տվյալների միայն 50%-ը։ Դոմինիկայի առաջարկած մեթոդները կարող են կիրառվել 90%-ից բարձր ճշգրտության հասնելու դեպքում: Ես խոսում եմ իրավիճակների մասին, երբ ղեկավարը ենթակային տալիս է 15 րոպեանոց առաջադրանք, բայց դա նրանից պահանջում է երեք օր; բայց շեֆը իրականում չգիտի, որ այս ենթական կախված է չորս կամ հինգ այլ մարդկանցից:
The Phoenix Project-ը հիանալի պատմություն է մի նախագծի մասին, որը շատ ուշ էր երեք տարի: Հերոսներից մեկին այդ պատճառով աշխատանքից ազատում են սպառնում, և նա հանդիպում է մեկ այլ կերպարի, որը ներկայացվում է որպես Սոկրատեսի տեսակ: Նա օգնում է պարզել, թե կոնկրետ ինչն է սխալ եղել: Պարզվում է, որ ընկերությունն ունի մեկ համակարգային ադմինիստրատոր, որի անունը Բրենթ է, և ամբողջ աշխատանքը ինչ-որ կերպ անցնում է նրա միջով։ Հանդիպումներից մեկում ենթականերից մեկին հարցնում են՝ ինչո՞ւ է յուրաքանչյուր կեսժամյա առաջադրանքը մեկ շաբաթ տևում։ Պատասխանը հերթերի տեսության և Լիթլի օրենքի շատ պարզեցված ներկայացումն է, և այս ներկայացման մեջ պարզվում է, որ 90% զբաղվածության դեպքում աշխատանքի յուրաքանչյուր ժամ տևում է 9 ժամ: Յուրաքանչյուր առաջադրանք պետք է ուղարկվի ևս յոթ հոգու, որպեսզի այդ ժամը դառնա 63 ժամ՝ 7 անգամ 9: Ես ասում եմ, որ Լիթլի օրենքը կամ որևէ բարդ հերթերի տեսություն օգտագործելու համար պետք է գոնե տվյալներ ունենալ:
Այսպիսով, երբ ես խոսում եմ տեսանելիության մասին, ես նկատի չունեմ, որ ամեն ինչ էկրանին է, այլ որ դուք գոնե տվյալներ ունեք: Երբ նրանք անում են, հաճախ պարզվում է, որ շատ մեծ քանակությամբ չպլանավորված աշխատանք կա, որը ինչ-որ կերպ ուղարկվում է Բրենտ, երբ դրա կարիքը չկա։ Իսկ Բրենթը հիանալի տղա է, երբեք չի ասի ոչ, բայց ոչ մեկին չի ասում, թե ինչպես է անում իր գործը։
Երբ աշխատանքը տեսանելի է, տվյալները կարող են կոկիկորեն դասակարգվել (այդպես է անում Դոմինիկը լուսանկարում), կարող է կիրառվել ժամանակի հինգ արտահոսքի աբստրակցիան, և կարող է կիրառվել ավտոմատացում։
2. Աշխատանքի կառավարման համակարգերի համախմբում. առաջադրանքների կառավարում
Արխետիպերը, որոնց մասին ես խոսում եմ, մի տեսակ բուրգ են: Եթե առաջինը ճիշտ է արված, ապա երկրորդն արդեն մի տեսակ հավելում է։ Սրանցից շատերը չեն աշխատում ստարտափների համար, դրանք պետք է հիշել ավելի մեծ ընկերությունների համար, ինչպիսին է Fortune 5000-ը: Վերջին ընկերությունը, որտեղ ես աշխատել եմ, ուներ 10 տոմսերի համակարգ: Մի թիմ ուներ Remedy, մյուսը գրել էր իր սեփական համակարգը, երրորդն օգտագործում էր Jira-ն, իսկ ոմանք էլ բավարարվեցին էլեկտրոնային փոստով: Նույն խնդիրն առաջանում է, եթե ընկերությունն ունի 30 տարբեր խողովակաշար, բայց ես ժամանակ չունեմ բոլոր նման դեպքերը քննարկելու։
Ես մարդկանց հետ քննարկում եմ, թե կոնկրետ ինչպես են ստեղծվում տոմսերը, ինչ է տեղի ունենում նրանց հետ և ինչպես են դրանք շրջանցվում: Ամենահետաքրքիրն այն է, որ մեր հանդիպումներին մարդիկ բավականին անկեղծ են խոսում։ Ես հարցրեցի, թե քանի մարդ է «փոքր / ոչ մի ազդեցություն» դրել տոմսերի վրա, որոնք իրականում պետք է տրվեն «մեծ ազդեցություն»: Պարզվեց, որ դա անում են գրեթե բոլորը։ Ես չեմ զբաղվում պախարակումներով և ամեն կերպ փորձում եմ չբացահայտել մարդկանց. Երբ նրանք անկեղծորեն ինձ ինչ-որ բան են խոստովանում, ես մարդուն չեմ տալիս: Բայց երբ գրեթե բոլորը շրջանցում են համակարգը, դա նշանակում է, որ ամբողջ անվտանգությունը, ըստ էության, պատուհանի ծածկույթ է: Ուստի այս համակարգի տվյալներից ոչ մի եզրակացություն չի կարելի անել։
Տոմսերի խնդիրը լուծելու համար անհրաժեշտ է ընտրել մեկ հիմնական համակարգ. Եթե դուք օգտագործում եք Jira, ապա պահեք այն Jira: Եթե այլընտրանք կա, թող միակը լինի։ Եզրակացությունն այն է, որ տոմսերը պետք է դիտարկվեն որպես մշակման գործընթացի ևս մեկ քայլ: Յուրաքանչյուր գործողություն պետք է ունենա տոմս, որը պետք է անցնի զարգացման աշխատանքային հոսքի միջոցով: Տոմսերը ուղարկվում են թիմին, որը դրանք տեղադրում է ցուցատախտակի վրա, այնուհետև պատասխանատվություն է վերցնում դրանց համար:
Սա վերաբերում է բոլոր գերատեսչություններին, ներառյալ ենթակառուցվածքները և գործառնությունները: Այս դեպքում հնարավոր է գոնե ինչ-որ իրական պատկերացում կազմել իրերի վիճակի մասին։ Երբ այս գործընթացը հաստատվի, հանկարծ հեշտ է դառնում պարզել, թե ով է պատասխանատու յուրաքանչյուր դիմումի համար: Որովհետև հիմա մենք ստանում ենք ոչ թե 50%, այլ 98% նոր ծառայություններ։ Եթե այս հիմնական գործընթացը աշխատում է, ապա ճշգրտությունը բարելավվում է ամբողջ համակարգում:
Ծառայությունների խողովակաշար
Սա կրկին վերաբերում է միայն խոշոր կորպորացիաներին։ Եթե դուք նոր ընկերություն եք նոր ոլորտում, ծալեք ձեր թեւերը և աշխատեք ձեր Travis CI-ի կամ CircleCI-ի հետ: Երբ խոսքը վերաբերում է Fortune 5000 ընկերություններին, մի դեպք, որը տեղի է ունեցել այն բանկում, որտեղ ես աշխատել եմ: Google-ը եկավ նրանց մոտ, և նրանց ցույց տվեցին հին IBM համակարգերի դիագրամները: Google-ի տղաները շփոթված հարցրեցին՝ որտե՞ղ է դրա աղբյուրի կոդը: Բայց չկա աղբյուրի կոդ, նույնիսկ GUI: Սա այն իրականությունն է, որի հետ պետք է առնչվեն խոշոր կազմակերպությունները. 40-ամյա բանկային գրառումները հնագույն հիմնական համակարգում: Իմ հաճախորդներից մեկն օգտագործում է Kubernetes կոնտեյներներ Circuit Breaker-ի նախշերով, գումարած Chaos Monkey-ը, բոլորը KeyBank հավելվածի համար: Բայց այս բեռնարկղերը, ի վերջո, միանում են COBOL հավելվածին:
Google-ի տղաները լիովին վստահ էին, որ կլուծեն իմ հաճախորդի բոլոր խնդիրները, և հետո սկսեցին հարցեր տալ՝ ի՞նչ է IBM datapipe-ը: Նրանց ասում են՝ սա միակցիչ է։ Ինչի՞ն է այն միանում: Sperry համակարգին։ Իսկ դա ի՞նչ է։ Եվ այսպես շարունակ։ Առաջին հայացքից թվում է, թե ինչպիսի՞ DevOps կարող են լինել: Բայց իրականում դա հնարավոր է։ Կան առաքման համակարգեր, որոնք թույլ են տալիս աշխատանքի ընթացքը հանձնել առաքման թիմերին:
3. Սահմանափակումների տեսություն. Սահմանափակումների տեսություն
Անցնենք երրորդ արխետիպին՝ ինստիտուցիոնալ/«ցեղային» գիտելիք։ Որպես կանոն, ցանկացած կազմակերպությունում կան մի քանի մարդիկ, ովքեր ամեն ինչ գիտեն և ամեն ինչ կառավարում են։ Սրանք նրանք են, ովքեր ամենաերկարն են եղել կազմակերպությունում և գիտեն բոլոր լուծումները:
Երբ սա հայտնվում է գծապատկերի վրա, ես հատուկ շրջում եմ նման մարդկանց մարկերով. օրինակ, պարզվում է, որ ինչ-որ Լուի ներկա է բոլոր հանդիպումներին: Եվ ինձ համար պարզ է՝ սա տեղական Brent-ն է։ Երբ CIO-ն ընտրում է իմ վերնաշապիկով և սպորտային կոշիկներով և IBM-ի կոստյումով տղայի միջև, ես ընտրվում եմ, քանի որ ես կարող եմ տնօրենին ասել բաներ, որոնք մյուս տղան չի պատմի, և որ տնօրենը կարող է չսիրել լսել: . Ես նրանց ասում եմ, որ իրենց ընկերությունում խոչընդոտը Ֆրեդ անունով մեկն է և Լու անունով մեկը: Այս շեղը պետք է արձակել, նրանցից այս կամ այն կերպ իրենց գիտելիքները քաղել։
Այս կարգի խնդիրը լուծելու համար կարող եմ, օրինակ, առաջարկել օգտագործել Slack-ը: Խելացի ռեժիսորը կհարցնի՝ ինչո՞ւ։ Սովորաբար, նման դեպքերում DevOps-ի խորհրդատուները պատասխանում են՝ քանի որ բոլորն են դա անում։ Եթե տնօրենն իսկապես խելացի լինի, կասի՝ բա ինչ։ Եվ այստեղ ավարտվում է երկխոսությունը։ Եվ իմ պատասխանն այս է. քանի որ ընկերությունում կան չորս խոչընդոտներ՝ Ֆրեդը, Լուին, Սյուզին և Ջեյնը: Նրանց գիտելիքները ինստիտուցիոնալացնելու համար նախ պետք է ներկայացնել Slack-ը: Ձեր բոլոր վիքիները լրիվ անհեթեթություն են, քանի որ ոչ ոք չգիտի դրանց գոյության մասին։ Եթե ինժեներական թիմը ներգրավված է առջևի և հետին պլանի մշակման մեջ, և բոլորը պետք է իմանան, որ հարցերով կարող են կապ հաստատել առջևի զարգացման թիմի կամ ենթակառուցվածքի թիմի հետ: Հենց այդ ժամանակ Լուն կամ Ֆրեդը հավանաբար ժամանակ կունենան միանալու վիքիին։ Եվ հետո Slack-ում ինչ-որ մեկը կարող է հարցնել, թե ինչու, ասենք, քայլ 5-ը չի աշխատում: Եվ հետո Լուն կամ Ֆրեդը կուղղեն վիքիի հրահանգները: Եթե դուք հաստատեք այս գործընթացը, ապա շատ բան ինքնըստինքյան իր տեղը կընկնի:
Սա է իմ հիմնական միտքը. ցանկացած բարձր տեխնոլոգիաներ առաջարկելու համար նախ պետք է դրանց հիմքը կարգի բերել, և դա կարելի է անել հենց նոր նկարագրված ցածր տեխնոլոգիական լուծումներով: Եթե դուք սկսում եք բարձր տեխնոլոգիաներից և չեք բացատրում, թե ինչու են դրանք անհրաժեշտ, ապա, որպես կանոն, դա լավ չի ավարտվում։ Մեր հաճախորդներից մեկն օգտագործում է Azure ML-ը՝ շատ էժան և պարզ լուծում: Նրանց հարցերի շուրջ 30%-ին պատասխանել է ինքնուսուցման մեքենան: Եվ այս բանը գրվել է օպերատորների կողմից, որոնք չեն զբաղվում տվյալների գիտությամբ, վիճակագրությամբ կամ մաթեմատիկայով: Սա նշանակալի է։ Նման լուծման արժեքը նվազագույն է:
4. Համագործակցության հաքեր
Չորրորդ արխետիպը մեկուսացման դեմ պայքարի անհրաժեշտությունն է: Մարդկանց մեծամասնությունն արդեն գիտի սա. մեկուսացումը թշնամություն է ծնում: Եթե յուրաքանչյուր բաժին իր հարկում է, և մարդիկ ոչ մի կերպ չեն հատվում միմյանց հետ, բացի վերելակից, ապա նրանց միջև թշնամանքը շատ հեշտ է առաջանում։ Բայց եթե, ընդհակառակը, մարդիկ միմյանց հետ նույն սենյակում են, նա անմիջապես հեռանում է։ Երբ ինչ-որ մեկը դուրս է նետում ինչ-որ ընդհանուր մեղադրանք, օրինակ՝ այսինչ ինտերֆեյսը երբեք չի աշխատում, նման մեղադրանքը ապակառուցելն ավելի հեշտ բան չկա։ Ինտերֆեյսը գրած ծրագրավորողները պարզապես պետք է սկսեն կոնկրետ հարցեր տալ, և շուտով պարզ կդառնա, որ, օրինակ, օգտատերը պարզապես սխալ է օգտագործել գործիքը։
Մեկուսացումը հաղթահարելու բազմաթիվ եղանակներ կան։ Մի անգամ ինձ խնդրեցին խորհրդակցել Ավստրալիայի բանկի համար, բայց ես հրաժարվեցի դա անել, քանի որ ունեմ երկու երեխա և կին: Այն ամենը, ինչ ես կարող էի անել նրանց օգնելու համար, խորհուրդ տալն էր գրաֆիկական պատմություններ: Սա մի բան է, որն ապացուցված է, որ աշխատում է: Մեկ այլ հետաքրքիր միջոց է անյուղ սուրճի հանդիպումները: Մեծ կազմակերպությունում սա հիանալի տարբերակ է գիտելիքի տարածման համար: Բացի այդ, դուք կարող եք անցկացնել ներքին devopsdays, հաքաթոններ և այլն:
5. Մարզչական Կատա
Ինչպես նախազգուշացրել էի հենց սկզբում, այսօր այս մասին չեմ խոսի։ Եթե դուք հետաքրքրված եք, կարող եք դիտել .
Այս թեմայի շուրջ լավ խոսակցություն կա նաև Մայք Ռոթերից.
6. Շուկայական կողմնորոշված՝ շուկայական ուղղվածություն ունեցող կազմակերպություն
Այստեղ տարբեր խնդիրներ կան։ Օրինակ՝ «I» մարդիկ, «T» մարդիկ և «E» մարդիկ։ «Ես» մարդիկ նրանք են, ովքեր միայն մեկ բան են անում. Սովորաբար դրանք գոյություն ունեն մեկուսացված բաժանմունքներով կազմակերպություններում: «T»-ն այն է, երբ մարդը լավ է մի բանում, բայց նաև լավ է որոշ այլ բաներում: «Է»-ն կամ նույնիսկ «սանր»-ն այն է, երբ մարդն ունի բազմաթիվ հմտություններ:
Կոնուեյի օրենքը գործում է այստեղ (), որը ամենապարզեցված ձևով կարելի է ձևակերպել հետևյալ կերպ. եթե կոմպիլյատորի վրա աշխատեն երեք թիմ, ապա արդյունքը կլինի երեք մասից կազմված կոմպիլյատոր։ Հետևաբար, եթե կազմակերպության ներսում առկա է մեկուսացման բարձր մակարդակ, ապա նույնիսկ Kubernetes-ը, անջատիչը, API-ի ընդարձակումը և այլ շքեղ բաներ այս կազմակերպությունում կդասավորվեն նույն ձևով, ինչպես ինքը կազմակերպությունը: Խստորեն ըստ Քոնուեյի և ի հեճուկս ձեզ բոլոր երիտասարդ գիքերի:
Այս խնդրի լուծումը բազմիցս նկարագրվել է։ Կան, օրինակ, կազմակերպչական արխետիպեր, որոնք նկարագրել է Ֆերնանդո Ֆերնանդեսը։ Այդ խնդրահարույց ճարտարապետությունը, որի մասին ես հենց նոր խոսեցի, մեկուսացվածությամբ, ֆունկցիոնալ ուղղվածություն ունեցող ճարտարապետություն է: Երկրորդ տեսակը ամենավատ, մատրիցային ճարտարապետությունն է, մյուս երկուսի խառնաշփոթը: Երրորդն այն է, ինչ նկատվում է ստարտափների մեծ մասում, և խոշոր ընկերությունները նույնպես փորձում են համապատասխանել այս տեսակին: Այն շուկայական ուղղվածություն ունեցող կազմակերպություն է։ Այստեղ մենք օպտիմիզացնում ենք հաճախորդների հարցումներին ամենաարագ արձագանքման հասնելու համար: Սա երբեմն կոչվում է հարթ կազմակերպություն:
Շատերը տարբեր կերպ են բնութագրում այս կառույցը, ինձ դուր է գալիս ձեւակերպումը ստեղծել/գործարկել թիմեր, Amazon-ում դա անվանում են երկու պիցցայի թիմ. Այս կառույցում բոլոր «I» տիպի մարդիկ խմբավորվում են մեկ ծառայության շուրջ, և աստիճանաբար նրանք մոտենում են «T» տիպին, և եթե ճիշտ կառավարում լինի, նրանք կարող են նույնիսկ դառնալ «E»: Այստեղ առաջին հակափաստարկն այն է, որ նման կառույցը պարունակում է ավելորդ տարրեր։ Ինչո՞ւ է ձեզ անհրաժեշտ յուրաքանչյուր բաժանմունքում թեստավորող, եթե դուք կարող եք ունենալ թեստավորողների հատուկ բաժին: Ինչին ես պատասխանում եմ. հավելյալ ծախսերն այս դեպքում ամբողջ կազմակերպության համար ապագայում «E» տիպի դառնալու գինն է։ Այս կառուցվածքում փորձարկողն աստիճանաբար սովորում է ցանցերի, ճարտարապետության, դիզայնի և այլնի մասին։ Արդյունքում, կազմակերպության յուրաքանչյուր մասնակից լիովին տեղյակ է այն ամենին, ինչ տեղի է ունենում կազմակերպությունում: Եթե ցանկանում եք իմանալ, թե ինչպես է այս սխեման աշխատում արդյունաբերության մեջ, կարդացեք .
7. Ձախ հերթափոխով աուդիտորներ. աուդիտ ցիկլի սկզբում: Ցուցադրված անվտանգության կանոններին համապատասխանելը
Սա այն դեպքում, երբ ձեր գործողությունները, այսպես ասած, չեն անցնում հոտի թեստը: Այն մարդիկ, ովքեր աշխատում են ձեզ համար, հիմար չեն: Եթե, ինչպես վերը նշված օրինակում, նրանք ամենուր աննշան/ոչ մի ազդեցություն են դնում, սա տևեց երեք տարի, և ոչ ոք ոչինչ չնկատեց, ապա բոլորը հիանալի գիտեն, որ համակարգը չի աշխատում: Կամ մեկ այլ օրինակ՝ փոփոխությունների խորհրդատվական խորհուրդ, որտեղ պետք է հաշվետվություններ ներկայացնել ամեն, ասենք, չորեքշաբթի: Այնտեղ աշխատում է մարդկանց մի խումբ (ի դեպ, ոչ այնքան լավ վարձատրվող), ովքեր, տեսականորեն, պետք է իմանան, թե ինչպես է ամբողջ համակարգը աշխատում։ Եվ վերջին հինգ տարիների ընթացքում դուք հավանաբար նկատել եք, որ մեր համակարգերը աներևակայելի բարդ են: Եվ հինգ-վեց հոգի պետք է որոշում կայացնեն մի փոփոխության մասին, որը իրենք չեն արել, և որի մասին ոչինչ չգիտեն։
Իհարկե, այս մոտեցումը չի աշխատում: Ես պետք է ազատվեմ նման բաներից, քանի որ այս մարդիկ չեն պաշտպանում համակարգը։ Որոշումը պետք է կայացնի թիմն ինքը, քանի որ թիմը պետք է պատասխանատվություն կրի դրա համար։ Հակառակ դեպքում պարադոքսալ իրավիճակ է առաջանում, երբ մենեջերը, ով կյանքում երբեք կոդ չի գրել, ծրագրավորողին ասում է, թե որքան ժամանակ պետք է տևի կոդ գրելու համար։ Մեկ ընկերություն, որի հետ ես աշխատել եմ, ուներ 7 տարբեր տախտակներ, որոնք վերանայում էին յուրաքանչյուր փոփոխություն, ներառյալ ճարտարապետական խորհուրդը, արտադրանքի տախտակը և այլն: Անգամ պարտադիր սպասման շրջան է եղել, թեև մի աշխատակից ինձ ասաց, որ տասը տարվա աշխատանքի ընթացքում ոչ ոք չի մերժել այս պարտադիր ժամկետում այս անձի կատարած փոփոխությունը։
Աուդիտորներին պետք է հրավիրել մեզ միանալու, այլ ոչ թե ազատվել նրանցից: Ասացեք նրանց, որ դուք գրում եք անփոփոխ երկուական կոնտեյներներ, որոնք, եթե նրանք անցնեն բոլոր թեստերը, ընդմիշտ կմնան անփոփոխ: Ասեք նրանց, որ դուք խողովակաշար ունեք որպես ծածկագիր և բացատրեք, թե դա ինչ է նշանակում: Ցույց տվեք նրանց հետևյալ սխեման. միայն կարդալու համար անփոփոխ երկուական կոնտեյներով, որն անցնում է խոցելիության բոլոր թեստերը. և հետո ոչ միայն ոչ ոք չի դիպչում դրան, այլև չեն էլ դիպչում խողովակաշարը ստեղծող համակարգին, քանի որ այն նաև դինամիկ է ստեղծվում: Ես ունեմ հաճախորդներ, Capital One, ովքեր օգտագործում են Vault-ը բլոկչեյնի նման մի բան ստեղծելու համար: Աուդիտորին պետք չէ «բաղադրատոմսեր» ցույց տալ խոհարարից, բավական է ցույց տալ բլոկչեյնը, որից պարզ է դառնում, թե ինչ է պատահել Jira տոմսի արտադրությանը և ով է պատասխանատու դրա համար։
Ըստ , որը ստեղծվել է 2018 թվականին Sonatype-ի կողմից, 2017 թվականին եղել է 87 միլիարդ OSS ներբեռնման հարցում։
Խոցելիության պատճառով կրած կորուստներն ահավոր են։ Ավելին, այն թվերը, որոնք այժմ տեսնում եք վերևում, չեն ներառում հնարավոր ծախսերը: Ի՞նչ է DevSecOps-ը մի խոսքով: Անմիջապես ասեմ, որ ինձ չի հետաքրքրում խոսել այն մասին, թե որքանով է հաջողված այս անունը։ Բանն այն է, որ քանի որ DevOps-ն այդքան հաջողակ է, մենք պետք է փորձենք ավելացնել անվտանգությունը այդ խողովակաշարին։
Այս հաջորդականության օրինակ.
Սա առաջարկություն չէ կոնկրետ ապրանքների համար, չնայած ինձ բոլորն էլ դուր են գալիս: Ես դրանք որպես օրինակ բերեցի՝ ցույց տալու համար, որ DevOps-ը, որն ի սկզբանե հիմնված էր արդյունաբերության կազմակերպչական պարադիգմի վրա, թույլ է տալիս ավտոմատացնել արտադրանքի վրա աշխատանքի յուրաքանչյուր փուլ:
Եվ ոչ մի պատճառ չկա, որ մենք չկարողանանք նույն մոտեցումն ունենալ անվտանգության հարցում:
Լրիվ
Որպես վերջաբան՝ ես մի քանի խորհուրդ կտամ DevSecOps-ի համար։ Դուք պետք է ներառեք աուդիտորներին ձեր համակարգերի ստեղծման գործընթացում և ժամանակ հատկացնեք նրանց կրթելուն: Պետք է համագործակցել աուդիտորների հետ։ Հաջորդը, դուք պետք է բացարձակապես անողոք պայքար մղեք կեղծ պոզիտիվների դեմ: Նույնիսկ խոցելիության սկանավորման ամենաթանկ գործիքի դեպքում դուք կարող եք ի վերջո ստեղծել ծայրահեղ վատ սովորություններ ձեր մշակողների շրջանում, եթե չգիտեք, թե որն է ձեր ազդանշան-աղմուկ հարաբերակցությունը: Մշակողները կհեղեղվեն իրադարձություններով և պարզապես կջնջեն դրանք: Եթե դուք լսել եք Equifax-ի պատմության մասին, ապա դա մոտավորապես այն է, ինչ տեղի է ունեցել այնտեղ, որտեղ ամենաբարձր ահազանգի մակարդակը անտեսվել է: Բացի այդ, խոցելիությունները պետք է բացատրվեն այնպես, որ պարզ լինի, թե ինչպես են դրանք ազդում բիզնեսի վրա: Օրինակ, կարելի է ասել, որ սա նույն խոցելիությունն է, ինչ Equifax-ի պատմության մեջ: Անվտանգության խոցելիությունները պետք է վերաբերվեն այնպես, ինչպես ծրագրային ապահովման այլ խնդիրներին, այսինքն՝ դրանք պետք է ներառվեն DevOps-ի ընդհանուր գործընթացում: Նրանց հետ պետք է աշխատել Ժիրայի, Կանբանի և այլնի միջոցով: Մշակողները չպետք է մտածեն, որ ուրիշը դա կանի, ընդհակառակը, բոլորը պետք է դա անեն: Ի վերջո, դուք պետք է էներգիա ծախսեք մարդկանց մարզելու վրա:
Օգտակար հղումներ
Ահա մի քանի խոսակցություններ DevOops կոնֆերանսից, որոնք կարող եք օգտակար լինել.
- Սերգեյ Բերդնիկով, Արտյոմ Կալիչկին - Հաջողության պատմություն կամ «Dev+DevOps+Ops» (, )
- Բարուխ Սադոգուրսկի, Լեոնիդ Իգոլնիկ - DevOps մասշտաբով. հունական ողբերգություն երեք գործողությամբ (, )
- Ալեքսանդր Տիտով, Կիրիլ Տոլկաչով -
- Թիմոթի Լիստեր -
Հայացք գցեք DevOops 2020 Մոսկվա — Այնտեղ նույնպես շատ հետաքրքիր բաներ կան։
Source: www.habr.com