Վերջերս նման գովազդները հեղեղել են համացանցը։ Չնայած հաճելի աշխատավարձին, չի կարելի չամաչել, որ ներսում վայրի հերետիկոսություն է գրված։ Սկզբում ենթադրվում է, որ «DevOps»-ը և «ինժեներ»-ը կարող են ինչ-որ կերպ սոսնձվել մեկ բառի մեջ, այնուհետև կա պահանջների պատահական ցանկ, որոնցից մի քանիսը հստակորեն պատճենված են sysadmin-ի թափուր աշխատատեղից:
Այս գրառման մեջ ես կցանկանայի մի փոքր խոսել այն մասին, թե ինչպես ենք մենք հասել կյանքի այս կետին, ինչ է իրականում DevOps-ը և ինչ անել դրա հետ հիմա:
Նման թափուր աշխատատեղերը կարելի է ամեն կերպ դատապարտել, բայց փաստը մնում է փաստ՝ դրանք շատ են, և շուկան այս պահին այսպես է աշխատում։ Մենք անցկացրեցինք devops համաժողով և բացահայտ հայտարարում ենք. - ոչ DevOps-ի ինժեներների համար»: Այստեղ շատերին տարօրինակ և վայրի կհամարեն՝ ինչու են մարդիկ, ովքեր ամբողջովին կոմերցիոն միջոցառում են անում, դեմ են գնում շուկային: Հիմա մենք ամեն ինչ կբացատրենք:
Մշակույթի և գործընթացների մասին
Սկսենք նրանից, որ DevOps-ը ինժեներական դիսցիպլին չէ։ Ամեն ինչ սկսվեց նրանից, որ պատմականորեն հաստատված դերերի բաժանումը չի գործում արտադրանքի որակի համար։ Երբ ծրագրավորողները միայն ծրագրավորում են, բայց չեն ցանկանում որևէ բան լսել փորձարկման մասին, ծրագրաշարը լցված է սխալներով: Երբ ադմիններին չի հետաքրքրում, թե ինչպես և ինչու է գրված ծրագրաշարը, աջակցությունը վերածվում է դժոխքի:
Օրինակ՝ նկարագրելով համակարգի ադմինիստրատորի և ծառայության կառավարման SRE մոտեցման տարբերությունը . Հետաքրքիր ուսումնասիրություններ են կատարվել - պարզ է, որ լավագույն ծրագրավորողներին ինչ-որ կերպ հաջողվում է նոր փոփոխություններ կատարել արտադրության մեջ ավելի արագ, քան ժամը մեկ անգամ: Նրանք իրենց ձեռքերով փորձարկում են ոչ ավելի, քան 10% (սա երևում է ). Ինչպե՞ս են նրանք դա անում: «Գերազանցիր կամ մեռնիր», ասվում է զեկույցի վերնագրերից մեկում: Այս վիճակագրության մանրամասն քննարկման համար թեստավորման առումով կարող եք դիմել Բարուխ Սադոգուրսկու հիմնական նոտային. մեր մյուս կոնֆերանսում՝ Հայզենբուգում:
«Երբ ընկերների միջև համաձայնություն չկա,
Գործերը նրանց մոտ լավ չեն լինի,
Եվ դրանից ոչինչ դուրս չի գա, միայն տանջանք:
Ժամանակին Կարապը, Խեցգետինն ու Խեցգետինը...»:
Ձեր կարծիքով, վեբ ծրագրավորողների ո՞ր մասն է իսկապես հասկանում, թե ինչ պայմաններով են իրենց հավելվածներն օգտագործվում արտադրության մեջ: Նրանցից քանիսը կգնան ադմինների մոտ և կփորձեն պարզել, թե ինչ կլինի, եթե տվյալների բազան խափանվի: Իսկ նրանցից ո՞վ կգնա թեստավորողների մոտ և կխնդրի նրանց սովորեցնել թեստերը ճիշտ գրել։ Եվ կան նաև անվտանգության աշխատակիցներ, ապրանքների մենեջերներ և մի խումբ այլ մարդիկ:
DevOps-ի ընդհանուր գաղափարը դերերի և բաժինների միջև համագործակցություն ստեղծելն է: Նախ, դա ձեռք է բերվում ոչ թե ինչ-որ խելացիորեն կազմաձևված ծրագրաշարի, այլ հաղորդակցման պրակտիկայի միջոցով: DevOps-ը մշակույթի, պրակտիկայի, մեթոդաբանության և գործընթացների մասին է: Չկա ինժեներական մասնագիտություն, որը կարող է պատասխանել այս հարցերին:
Արատավոր շրջան
Որտեղի՞ց է այն ժամանակ առաջացել «devops engineering» կարգապահությունը: Մենք ունենք տարբերակ! DevOps-ի գաղափարները լավն էին, այնքան լավ, որ նրանք դարձան սեփական հաջողության զոհը: Որոշ ստվերային հավաքագրողներ և մարդկանց առևտրով զբաղվողներ, ովքեր ունեն իրենց մթնոլորտը, սկսեցին պտտվել այս ամբողջ թեմայի շուրջ:
Պատկերացրեք՝ երեկ դուք Խիմկիում շաուրմա էիք պատրաստում, իսկ այսօր արդեն մեծ մարդ եք, ավագ հավաքագրող։ Թեկնածուների որոնման ու ընտրության մի ամբողջ գործընթաց կա, ամեն ինչ հեշտ չէ, պետք է հասկանալ։ Ենթադրենք, բաժնի վարիչն ասում է՝ X-ում մասնագետ գտեք: X-ին վերագրում ենք «ինժեներ» բառը և ավարտում ենք: Պե՞տք է Linux: Դե, սա հաստատ Linux-ի ինժեներ է, եթե ցանկանում եք DevOps, ապա DevOps-ի ինժեներ: Թափուր աշխատատեղը բաղկացած է ոչ միայն վերնագրից, այլեւ ներսում պետք է մուտքագրվի որոշակի տեքստ։ Ամենահեշտ ձևը Google-ից հիմնաբառերի մի շարք մուտքագրելն է՝ կախված ձեր երևակայությունից: DevOps-ը բաղկացած է երկու բառից՝ «Dev» և «Ops», ինչը նշանակում է, որ մենք պետք է սոսնձենք ծրագրավորողների և ադմինիստրատորների հետ կապված հիմնաբառեր՝ բոլորը մեկ կույտի մեջ: Ահա թե ինչպես են առաջանում թափուր աշխատատեղերը 42 ծրագրավորման լեզուների իմացության և 20 տարվա Kubernetes-ի և Swarm-ի միաժամանակյա օգտագործման վերաբերյալ։ Աշխատանքային դիագրամ.
Ահա թե ինչպես է մարդկանց մտքերում արմատավորվել որոշակի «դևոպս» սուպերհերոսի անիմաստ և անողոք կերպարը, որը բոլորին կձևավորի Ջենկինսի մոտ տեղակայվելու համար, և երջանկությունը կգա: Օ, եթե ամեն ինչ այդքան պարզ լիներ: «Եվ նաև այսպես կարող եք որսալ համակարգի ադմինիստրատորներին,- կարծում է HR-ը,- դա մոդայիկ բառ է, հիմնաբառերը նույնն են, նրանք պետք է խայծը վերցնեն»:
Պահանջարկը ստեղծում է առաջարկ, և այս բոլոր թափուր աշխատատեղերը լցված են համակարգի ադմինիստրատորների խելագար թվով, ովքեր հասկացել են. դու կարող ես ամեն ինչ անել այնպես, ինչպես նախկինում էր, բայց մի քանի անգամ ավելին ստանալ՝ քեզ «դևոպս» անվանելով: Ճիշտ այնպես, ինչպես դուք կարգավորել եք սերվերները SSH-ի միջոցով ձեռքով մեկ առ մեկ, դուք կշարունակեք կարգավորել դրանք, բայց այժմ սա ենթադրաբար զարգացող պրակտիկա է: Սա ինչ-որ բարդ երևույթ է, որը մասամբ կապված է դասական ադմինների թերագնահատման և DevOps-ի շուրջ բարձրացված աղմուկի հետ, բայց ընդհանուր առմամբ այն, ինչ եղավ, եղավ։
Այսպիսով, մենք ունենք առաջարկ և պահանջարկ: Արատավոր շրջան, որը սնվում է ինքն իրեն: Սրա դեմ ենք մենք պայքարում (այդ թվում՝ DevOops կոնֆերանսի ստեղծմամբ):
Իհարկե, բացի համակարգի ադմինիստրատորներից, ովքեր իրենց անվանափոխել են «devops», կան նաև այլ մասնակիցներ, օրինակ՝ պրոֆեսիոնալ SRE-ներ կամ Infrastructure-as-Code ծրագրավորողներ:
Ինչ են անում մարդիկ DevOps-ում (իսկապես)
Այսպիսով, դուք ցանկանում եք առաջադիմել DevOps-ի պրակտիկա սովորելու և կիրառելու հարցում: Բայց ինչպե՞ս դա անել, ո՞ր ուղղությամբ նայել։ Ակնհայտ է, որ դուք չպետք է կուրորեն ապավինեք հանրաճանաչ հիմնաբառերին:
Եթե աշխատանք կա, ինչ-որ մեկը պետք է անի: Մենք արդեն պարզել ենք, որ սրանք «դևոպս ինժեներներ» չեն, հետո ովքե՞ր են։ Ավելի ճիշտ է սա ձեւակերպել ոչ թե պաշտոններով, այլ կոնկրետ աշխատանքային ոլորտներով։
Նախ, դուք կարող եք անդրադառնալ DevOps-ի սրտին՝ գործընթացներին և մշակույթին: Մշակույթը դանդաղ ու բարդ բիզնես է, և թեև ավանդաբար այն մենեջերների պարտականությունն է, բայց այս կամ այն կերպ ներգրավված են բոլորը՝ ծրագրավորողներից մինչև ադմինիստրատորներ: Մի քանի ամիս առաջ Թիմ Լիստերը :
«Մշակույթը որոշվում է կազմակերպության հիմնական արժեքներով։ Սովորաբար մարդիկ դա չեն նկատում, բայց երկար տարիներ աշխատելով խորհրդատվական ոլորտում՝ մենք սովոր ենք դա նկատել։ Մտնում ես ընկերություն և բառացիորեն մի քանի րոպեի ընթացքում սկսում ես զգալ, թե ինչ է կատարվում։ Մենք սա անվանում ենք «համը»: Երբեմն այս բույրը իսկապես լավ է: Երբեմն դա սրտխառնոց է առաջացնում: (...) Դուք չեք կարող փոխել մշակույթը, քանի դեռ չեն հասկացվել կոնկրետ գործողությունների հիմքում ընկած արժեքներն ու համոզմունքները: Վարքագիծը հեշտ է դիտարկել, բայց համոզմունքներ փնտրելը դժվար է: DevOps-ը պարզապես հիանալի օրինակ է այն բանի, թե ինչպես են ամեն ինչ դառնում ավելի ու ավելի բարդ»:
Հարցի տեխնիկական մասն էլ, իհարկե, կա։ Եթե ձեր նոր կոդը փորձարկվի մեկ ամսից, բայց թողարկվի միայն մեկ տարի անց, և ֆիզիկապես անհնար է արագացնել այն, դուք կարող եք չհամապատասխանել լավ փորձին: Լավ փորձը ապահովվում է լավ գործիքներով: Օրինակ՝ հաշվի առնելով Infrastructure-as-Code-ի գաղափարը, դուք կարող եք օգտագործել ցանկացած բան՝ սկսած AWS CloudFormation-ից և Terraform-ից մինչև Chef-Ansible-Puppet: Դուք պետք է իմանաք և կարողանաք անել այս ամենը, և սա արդեն բավականին ինժեներական կարգապահություն է։ Կարևոր է չշփոթել պատճառը հետևանքի հետ. սկզբում դուք աշխատում եք SRE-ի սկզբունքների համաձայն և միայն այնուհետև իրականացնում եք այդ սկզբունքները որոշակի տեխնիկական լուծումների տեսքով: Միևնույն ժամանակ, SRE-ը շատ համապարփակ մեթոդաբանություն է, որը ձեզ չի ասում, թե ինչպես ստեղծել Jenkins-ը, այլ հինգ հիմնական սկզբունքների մասին.
- Բարելավված հաղորդակցությունը դերերի և բաժինների միջև
- Սխալների ընդունումը որպես աշխատանքի անբաժանելի մաս
- Փոփոխություններ կատարել աստիճանաբար
- Գործիքների և այլ ավտոմատացման օգտագործում
- Չափելով այն ամենը, ինչ կարելի է չափել
Սա պարզապես հայտարարությունների մի շարք չէ, այլ կոնկրետ . Օրինակ, սխալների ընդունման ճանապարհին ձեզ հարկավոր է հասկանալ ռիսկերը, չափել ծառայությունների հասանելիությունն ու անհասանելիությունը՝ օգտագործելով SLI-ի նման մի բան () և SLO (), սովորիր գրել հետմահու և այնպես անել, որ գրելը սարսափելի չլինի:
SRE կարգապահության մեջ գործիքների օգտագործումը հաջողության միայն մեկ մասն է, թեև կարևոր: Պետք է անընդհատ տեխնիկապես զարգանանք, տեսնենք, թե ինչ է կատարվում աշխարհում և ինչպես դա կարող է կիրառվել մեր աշխատանքում։
Իր հերթին, Cloud Native լուծումներն այժմ շատ տարածված են դարձել: Ինչպես այսօր սահմանում է Cloud Native Computing Foundation-ը, Cloud Native տեխնոլոգիաները կազմակերպություններին հնարավորություն են տալիս զարգացնել և գործարկել մասշտաբային հավելվածներ այսօրվա դինամիկ միջավայրերում, ինչպիսիք են հանրային, մասնավոր և հիբրիդային ամպերը: Օրինակները ներառում են կոնտեյներներ, սպասարկման ցանցեր, միկրոծառայություններ, անփոփոխ ենթակառուցվածք և դեկլարատիվ API-ներ: Այս բոլոր տեխնիկաները թույլ են տալիս թույլ միացված համակարգերին մնալ առաձգական, կառավարելի և բարձր դիտելի: Լավ ավտոմատացումը թույլ է տալիս ինժեներներին հաճախակի և կանխատեսելի արդյունքներով մեծ փոփոխություններ կատարել՝ առանց դա դժվարություն դարձնելու: Այս ամենը աջակցվում է հայտնի գործիքների փաթեթով, ինչպիսիք են Docker-ը և Kubernetes-ը:
Այս բավականին բարդ և լայն սահմանումը պայմանավորված է նրանով, որ տարածքը նույնպես բավականին բարդ է: Մի կողմից պնդում են, որ այս համակարգում նոր փոփոխությունները պետք է շատ պարզ կերպով ավելացվեն։ Մյուս կողմից, պարզել, թե ինչպես ստեղծել մի տեսակ կոնտեյներային միջավայր, որտեղ թույլ զուգակցված ծառայություններն ապրում են ծրագրային ապահովման կողմից սահմանված ենթակառուցվածքի վրա և առաքվում այնտեղ՝ օգտագործելով շարունակական CI/CD, և կառուցել DevOps պրակտիկա այս ամենի շուրջ, այս ամենը պահանջում է ավելին: քան մեկը ուտում է շանը:
Ի՞նչ անել այս ամենի հետ
Ամեն մեկն յուրովի է լուծում այս խնդիրները՝ օրինակ՝ կարելի է սովորական թափուր աշխատատեղեր հրապարակել՝ խախտելու արատավոր շրջանը։ Դուք կարող եք պարզել, թե ինչ են նշանակում DevOps-ի և Cloud Native-ի նման բառերը և դրանք օգտագործել ճիշտ և ճշգրիտ: Դուք կարող եք զարգանալ DevOps-ում և ձեր օրինակով ցույց տալ ճիշտ մոտեցումները։
Մենք կոնֆերանս ենք անում , որը հնարավորություն է տալիս ավելի խորանալ այն բաների մեջ, որոնց մասին հենց նոր խոսեցինք։ Դրա համար կան զեկույցների մի քանի խմբեր.
- Գործընթացներ և մշակույթ;
- Կայքի հուսալիության ճարտարագիտություն;
- Cloud Native;
Ինչպե՞ս ընտրել ուր գնալ: Այստեղ կա մի նուրբ կետ. Մի կողմից, DevOps-ը փոխազդեցության մասին է, և մենք իսկապես ցանկանում ենք, որ դուք ներկա գտնվեք ներկայացումների տարբեր բլոկներից: Մյուս կողմից, եթե դուք զարգացման մենեջեր եք, ով եկել է կոնֆերանսի մեկ կոնկրետ առաջադրանքի վրա կենտրոնանալու, ապա ձեզ ոչ ոք չի սահմանափակում, ակնհայտ է, որ սա գործընթացների և մշակույթի բլոկ կլինի: Մի մոռացեք, որ դուք կունենաք ձայնագրություններ կոնֆերանսից հետո (հետադարձ կապի ձևաթուղթը լրացնելուց հետո), որպեսզի ավելի ուշ միշտ կարողանաք դիտել ավելի քիչ կարևոր ներկայացումներ:
Ակնհայտ է, որ կոնֆերանսում դուք չեք կարող միանգամից երեք ուղիով գնալ, ուստի մենք կազմակերպում ենք ծրագիրն այնպես, որ յուրաքանչյուր ժամանակի հատվածում կան թեմաներ յուրաքանչյուր ճաշակի համար:
Մնում է միայն հասկանալ, թե ինչ անել, եթե DevOps-ի ինժեներ եք: Նախ, փորձեք որոշել, թե իրականում ինչ եք անում: Սովորաբար նրանք սիրում են այս բառն անվանել.
- Մշակողները, ովքեր աշխատում են ենթակառուցվածքի վրա: SRE-ի և Cloud Native-ի մասին հաշվետվությունների խմբերն առավել հարմար են ձեզ համար:
- Համակարգի ադմինիստրատորներ. Այստեղ ավելի բարդ է: DevOops-ը համակարգի կառավարման մասին չէ: Բարեբախտաբար, ինտերնետում կան շատ հիանալի կոնֆերանսներ, գրքեր, հոդվածներ, տեսանյութեր և այլն՝ համակարգի կառավարման թեմայով: Մյուս կողմից, եթե դուք շահագրգռված եք զարգացնել ինքներդ ձեզ մշակույթն ու գործընթացները հասկանալու, Cloud Native-ի հետ ամպային տեխնոլոգիաների և կյանքի մանրամասների մասին սովորելու առումով, ապա մենք ուրախ կլինենք տեսնել ձեզ: Մտածեք այս մասին՝ դուք վարչարարություն եք անում, հետո ի՞նչ եք անելու։ Որպեսզի հանկարծ չհայտնվեք տհաճ իրավիճակում, պետք է սովորեք հենց հիմա։
Կա ևս մեկ տարբերակ՝ դուք համառում եք և շարունակում պնդել, որ այդպես եք մասնավորապես DevOps-ի ինժեներ և ուրիշ ոչինչ, ինչ էլ որ դա նշանակի: Այդ դեպքում մենք պետք է հիասթափեցնենք ձեզ, DevOops-ը DevOps-ի ինժեներների համար կոնֆերանս չէ:
Սահել-ից Մյունխենում
DevOops 2020 Moscow-ը կանցկացվի ապրիլի 29-30-ը Մոսկվայում, տոմսերն արդեն հասանելի են։ .
Այլընտրանք, դուք կարող եք մինչև փետրվարի 8-ը։ Խնդրում ենք նկատի ունենալ, որ ձևը լրացնելիս դուք պետք է ընտրեք թիրախային լսարանը, որն առավելապես կշահի ձեր զեկույցից (ցուցակում թաղված է անակնկալ).
Source: www.habr.com