Վերջերս նման հայտարարությունները տարափում են ինտերնետում։ Չնայած գրավիչ աշխատավարձին, չի կարող չանհանգստացնել, որ վարում գրած վայրենությունից։ Ստացման սկզբում ենթադրվում է, որ «DevOps» և «ինժեներ» ինչ-որ կերպ կարելի է միավորված անել մեկ բառի մեջ, իսկ հետո գնում է պատահական պահանջների ցանկ, որոնց մի մասը դեև ճակատով շինված յուրաքանչյուր կարիերայի հայտարարությունից։
Այս հրապարակումն ուզում եմ մի քիչ խոսել, ինչպես ենք մենք հասել այս վիճակին, ինչ է DevOps-ը իրականում և ինչ պետք է անել հիմա։
Այսպիսի աշխատանքները կարելի է տարբեր կերպ քննադատել, բայց փաստը մնում է փաստ՝ դրանք շատ են, և այսպիսի է շուկայական վիճակը։ Մենք կազմակերպեցինք devops-ոհնաժողով և բացահայտ հայտարարում ենք՝ « — չենք համարում DevOps-ինժեներների համար»։ Այստեղ շատերին կարող է թվալ տարօրինակ և վայրենի․ ինչու են մարդիկ, որոնք պարտվողական գործարարություն են իրականացնում, գնում շուկայի դեմ։ Հիմա ամեն ինչ կբացատրենք։
Մշակույթն ու գործընթացները
Թող մենք սկսենք նրանից, որ DevOps-ը ինժեներական դիսցիպլին չէ։ Ամեն ինչ սկսվեց նրանից, որ պատմականորեն բաշխված դերերը չեն աշխատում արտադրանքի որակի վրա։ Երբ ծրագրավորողները միայն ծրագրավորում են, բայց ոչինչ չեն ցանկանում լսել թեստավորման մասին՝ ծրագրային ապահովումը լի է սխալներով։ Երբ ադմիններին անհանգստացնում է՝ ինչպես է և ինչու է ստեղծվել ծրագրային ապահովումը՝ աջակցությունը վերածվում է դժոխքի։
Օրինակ, համակարգչային ադմինիստրատորի և SRE-ի մոտեցման տուփի վերաբերյալ . Հետաքրքիր հետազոտություններ են իրականացվել — կարելի է տեսնել, որ լավագույն ծրագրավորողները ինչ-որ կերպ կարողանում են նոր փոփոխությունները ավելացնել արտադրությանը ավելի արագ, քան մեկ ժամում։ Նրանք նույն ժամանակ ձեռքով թեստավորում են անում ոչ ավելի քան 10% (այսպիսին է ). Ինչպե՞ս են նրանք դա կարողանում։ «Excel or die» – այս շարքի վերնագրերից մեկն է։ Այս վիճակագրության մանրամասն քննարկման համար կարող եք դիմել Բարուխ Սաադոգուրսկու ելույթին մեր մյուս կոնֆերանսում, Heisenbug։
«Երբ ընկերությունում համաձայնություն չկա,
Նրանց գործը չի առաջանալու,
և ելքը նրանից չի լինելու ոչ մի բան, միայն աղքատություն։
Մի օր Արծիվը, Ցարվուն և Ձուկը…»
Ինչպես եք կարծում, որ բանկային խմբի իրական գիտակցությունն ունեցող ծրագրավորողների մասնաբաժինը որքան է, և նրանք իսկապես հասկանում են, թե ինչ պայմաններում են ընկալվում իրենց դիմումները արտադրությունում؟ Քանի հոգի կգնա ադմինների մոտ և փորձում կիմանա, թե ինչ կառաջանա տվյալների բազայի փոքրացման ժամանակ? Իսկ ով է ստուգողներին դիմելու և խնդրելու, որպեսզի նոր հմտություններ ձեռք բերեն, ինչպես ճիշտ գրել թեստեր? Եվ այնտեղ էլ կան անվտանգության մասնագետներ, արտադրության կառավարիչներ, ու դեռ շատ մարդիկ։
DevOps-ի ընդհանուր գաղափարն է հաստատել համագործակցություն դերերի և բաժինների միջև: Սա հիմնականում ձեռք է բերվում ոչ թե ինչ-որ բարդ ծրագրային ապահովմամբ, այլ փոխհարաբերությունների պրակտիկայով: DevOps-ը մշակույթ է, պրակտիկա, մեթոդաբանություն և գործընթացներ: Չկա այդպիսի ինժեներական մասնագիտություն, որը պատասխաներ տա այս հարցերին.
Փակ շրջան
Որտեղի՞ց է առաջացել «դեվոփս-անձին» մասնագիտությունը: Ասենք, որ մենք ունենք տարբերակ: DevOps-ի գաղափարները լավ էին՝ այնքան լավ, որ իրենց հաջողության զոհը դարձան: Այս թեմայի շուրջ սկսեցին խառնվել որոշ մութ ռեկրուտերներ և մարդկանց վաճառող մասնագետներ, որոնք ունեն իրենց յուրահատուկ մթնոլորտը.
Համաձայնեք՝ երեկ դուք Հիմկներում շաուրմա էինք պատրաստում, իսկ այսօր՝ արդեն մեծ մարդ եք, սերը ռեկրուտեր: Այստեղ ամբողջ գործընթաց է՝ թեկնածուների որոնում և ընտրություն, ամեն ինչ ինչպիսինն է, պիտի հասկանալ: Աթողը ասում է՝ գտիր X մասնագետ: Վերադարձնում ենք X-ին «ինժեներ» բառը, և խնդիրը լուծված է: Գնահատովն եք Linux-ն ուզում? Շատ լավ, այդ դեպքում Linux-ինժեներ է պահանջվում, ուզում եք DevOps՝ DevOps-ինժեներ: Վականցիան բաղկացած չէ միայն վերնագրից, այլ ներսում պիտի գրեք որոշ տեքստ: Իրավիճակը ամենադյուրինն է՝ գրել Google-ի բանալի բառերի հավաքածու, ինչպես ով ինչքան երևակայություն ունի: DevOps-ը բաղկացած է «Dev» և «Ops» բառերից, նշանակում է, պետք է կապել բանալի բառերը, որոնք վերաբերում են մշակողների և ադմինիստրատորների հետ, բոլորին մի տեղ: Այդպես են առաջանում վականցիաները՝ 42 ծրագրավորման լեզուների տիրապետմամբ և 20 տարվա Kubernetes- և Swarm-կիրարում: Աշխատանքի սխեմա.
Այդպիսով, մարդկանց գիտակցության մեջ հաստատվեցին միանշանակ և բիրմաց superhero-«դեվոպս»-ի կերպարները, որը պատրաստում է բոլորի համար Jenkins-ում տեղադրում և երջանկությունը գալիս է: Հա, եթե այդքան հեշտ լիներ: «Իսկ կան հարցազրույցներ, և ես հույս ունեմ՝ կառցելու է, այնպես որ, նոր են համարում, իսկ բանալի բառերը նույնն են, պետք է խաղալ»,- մտածում է HR-ը:
Պահանջը ծնում է առաջարկ, և բոլոր այս թրեշ-վականցիաներին հարձակում է եղել անսահման թվով ադմինիստրատորների, ովքեր հասկացան. կարելի է անել փնտրելով, բայց ավելի շատ վաստակել, անվանվելով «դեվոպս»: Ինչպես պետք է սերվերները անմիջապես SSH-ով մենակ կարգավորեք, այնպես էլ շարունակելու եք կարգավորել, բայց հիմա դա կարծես թե դեվոպս-պրակտիկա է: Սա ինչ-որ բարդ现ահիմում է, մասնակիորեն կապված է էլիտային ադմինիստրատորների արգելափակման և DevOps-ի շուրջ սլագի հետ, բայց ընդհանուր առմամբ՝ ինչն ստացվեց, այն ստացվեց.
Այսպիսով, մենք ունենք պահանջ և առաջարկ: Փակ շրջան, որը սնուցում է ինքն իրեն: Սա մեր կողմից պայքարելու պահանջատիրություն է ( այդ թվում՝ DevOops կոնֆերանս ստեղծելով):
Անշուշտ, բացի ադմինիստրատորներից, ովքեր վերանվանվել են «դեվոպս», կան նաև այլ մասնակիցներ՝ օրինակ՝ պրոֆեսիոնալ SRE-ներ կամ Infrastructure-as-Code մշակողներ.
Ի՞նչ են անում մարդիկ DevOps-ում ( vraiment)
Ուրեմն, դուք ցանկանում եք առաջ գնալ DevOps պրակտիկաների ուսումնասիրման և կիրառման մեջ: Բայց ինչպես դա անել, ինչ կողմի վրա նայել: Անշուշտ, առտաքին պատկերացումներով ոչինչ անել չի կարելի:
Եթե աշխատանք կա, ապա ով որ պետք է զբաղվի դրանով: Մենք արդեն պարզել ենք, որ դա «դևոպս ինժեներներ» չեն, ապա quién: Ասես ավելի ճիշտ կլինի սա ձևավորել ոչ պաշտոնային պայմաններով, այլ կոնկրետ աշխատանքային ուղղություններով:
Առաջինը, կարելի է զբաղվել հենց 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 տեխնոլոգիաները կազմակերպություններին թույլ են տալիս մշակել և գործարկել ընդլայնելի ծրագրեր ժամանակակից դինամիկ միջավայրերում, ինչպիսիք են հանրային, մասնավոր և հիբրիդային Cloud-ները։ Արևատենյակ կարող են լինել կոնտեյներները, ծառայական ցանցերը, միկրոսերվիսները, անփոփոխ ինֆրաստրուկտուրան և հայտարարված API-ները։ Այս բոլոր տեխնիկաները թույլ են տալիս թույլ կապակցված համակարգերին մնալ ճկուն, կառավարելի և լավ տեսանելի։ Լավ ավտոմատացումը հնարավորություն է տալիս ինժեներին հաճախ անել մեծ փոփոխություններ կանխատեսելի արդյունքներով, չդարձնելով դա դժոխային աշխատանք։ Այս ամենը աջակցվում է հայտնի գործիքների շտեկով, ինչպիսիք են Docker-ը և Kubernetes-ը։
Այս բավականին դժվար և ծիծաղելի սահմանումը կապվում է այն բանի հետ, որ ոլորտը բավականին բարդ է։ Մեկ կողմից, նշվում է, որ նոր փոփոխությունները այս համակարգին պետք է լրացվեն αρκεաչափ հեշտությամբ։ Մյուս կողմից, որպեսզի հասկանաք, ինչպես ստեղծել կոնտեյներացված միջավայր, որտեղ թույլ կապակցված ծառայությունները ապրում են ծրագրով սահմանված ինֆրաստրուկտուրայում և մատակարարվում CI/CD-ի միջոցով, ու ստեղծել DevOps պրակտիկայի շուրջ՝ դրանում պետք է շատ ճակատագրերով հանդես գալ։
Ինչ անենք այս ամենի հետ։
Հետաքրքիր է, որ յուրաքանչյուրն այս խնդիրները լուծում է իր սեփական եղանակով։ Օրինակ, կարելի է հայտարարել նորմալ աշխատանքային առաջարկներ՝ փակ շրջանները կոտրելու համար։ Կարելի է հասկանալ, թե ինչ են նշանակում DevOps և Cloud Native բառերը, և օգտագործել դրանք իրոք իրավացիভাবে։ Կարելի է զարգանալ DevOps-ի մեջ և սեփական օրինակով ցուցադրել ճիշտ մոտեցումները։
Մենք անում ենք կոնֆերանս։ , որը հնարավորություն է տալիս ավելի խորը հասկանալ այն բաները, որոնց մասին刚刚 քննարկեցինք։ Դրա համար կա մի քանի զեկույցների խմբեր՝
- Պրոցեսներ և մշակույթ;
- Սայթերի հուսալիություն և ինժեներություն;
- Cloud Native;
Ինչպես ընտրել, թե ուր գնալ։ Այս խնդիրը նուրբ է։ Մեկ կողմից, DevOps-ը վերաբերում է փոխհարաբերություններին, և մենք շատ մեզ խիստ ազնավորության ենք զգում՝ հանդիպելով տարբեր բլոկներում զեկույցների։ Մյուս կողմից, եթե դուք ծրագրավորման ղեկավար եք, որը եկել է կոնֆերանսին կոնկրետ մի խնդրի շուրջ կենտրոնանալու համար, երբեք դա չի արգելակում ձեզ։ Ավելին, դա կլինի պրոցեսների և մշակույթի բլոկը։ Не забудьте, что после конференции у вас останутся записи (после заполнения формы обратной связи), поэтому вы всегда сможете посмотреть менее важные доклады позже.
Տեղի ունեցած կոնֆերանսի ընթացքում ակներև է, որ դուք միաժամանակ չեք կարող մասնակցել երեք ճյուղերի, հետեւաբար մենք այդպես ենք ձևավորում ծրագիրը, որպեսզի յուրաքանչյուր ժամանակահատվածում լինեն թեմաներ բոլորի համար։
Մնացել է միայն հասկանալ, թե ինչ անել, եթե դուք DevOps ճարտարապետ եք: Նախ, փորձեք պարզել, թե ինչով եք ճիշտ զբաղված։ Իուրույն, այդ բառի տակ սովորաբար հասկանում են:
- Էֆսկ տեղավորողների մշակողների։ Ձեր համար լավագույնը կլինեն SRE և Cloud Native թեմաների ներկայացումները։
- Համակարգային ադմինիստրատորները։ Ա aici ավելի բարդ է։ DevOops-ը չի է: Ցավոք, համակարգային ադմինիստրատության վերաբերյալ մեծամասամբ ունեն սիրիր ցուցահանդեսներ, գրքեր, հոդվածներ, տեսանյութեր և այլն: Մյուս կողմից, եթե ձեզ հետաքրքրում է զարգանալ մշակույթի և գործընթացների միջև, ուսումնասիրել ամպային տեխնոլոգիաները և Cloud Native-ի հետ կապված մանրամասները, ապա մենք շնորհակալ կլինենք ձեզ տեսնելու։ Փոքրիկ մտածեք այս մասին: Դուք զբաղվում եք ադմինիստրացիայով, իսկ արդեն հետո ի՞նչ եք անելու։ Որպեսզի անակնկալների մեջ չհայտնվեք, լավ է սովորել արդեն հիմա։
Բացի այդ, մեկ այլ տարբերակ կա. դուք կպնդեք և կշարունակեք պնդել, որ դուք ճիշտ DevOps ճարտարապետ եք և ոչ այլ կերպ, ինչ էլ որ դա նշանակի։ Այդ դեպքում ստիպված ենք հիասթափեցնել, DevOops-ը կոնֆերանս չէ DevOps ճարտարապետների համար։
Սլայդը Մյունխենում
DevOops 2020 Մոսկվայում տեղի կունենա ապրիլի 29-30-ը, տոմսերը արդեն կարելի է .
Բացի այդ, դուք կարող եք ֆեբրուարի 8-ից առաջ։ Խնդրում ենք ուշադրություն դարձնել, որ հայտի ձևաթղթիս լրացման ժամանակ պետք է ընտրեք նիշ, որի մեջ ձեր հաղորդումը առավելագույն օգուտներ կտա (ցույց տալու այս շարքում թաքնված է մի անակնկալ).
Ընտանիք: habr.com
