Խոսակցությունից ներշնչված
Վերջերս իսկապես բախումներ են ծավալվում DevOps և SRE հանգեցնող հասկացությունների շրջանակներում:
Ինչպես լինում է, այս թեմայի շուրջ քննարկումները գնալով հետզհետե նյարդայնացնում էին, ավելի պատահաբար որոշեցի ներկայացնել իմ տեսակետը և քննարկման դնել մասնագիտական խմբի դատին: Այն բոլորին, ովքեր հետաքրքրված են, ողջունում ենք ներքևում, և թող ամեն բան նորից սկսվի!
Առաջին պատմություն
Ուրեմն, շատ վաղ ժամանակներում ամենաքարտեզված հիթակառը ու ծրագրային ապահովման մշակողների թիմում առկա էր։ Առաջինները հաջողությամբ գրում էին կոդը, երկրորդները, գտնվելով առաջինների շուրջ, կարգավորում էին սերվերները, և շարունակաբար գալիս էին մշակողներին և ստանում էին սպառիչ "չորս տուդաշխի ջրբեն ամեն բան աշխատում է": Բիզնեսը սպասում էր ծրագրային ապահովմանը, ամեն ինչ կանգ էր առնում, ժամանակ առ ժամանակ կտրվում էր, ամեն ինչ անհանգստացնում էր։ Ո besonders ով էր կանգնած այս ամենի համար: Կապանքը լամպական ժամանակաշրջան։ Բայց դուք արդեն գիտեք, որտեղից են DevOps-ի արմատները:
DevOps մեթոդների ծնունդ
Այդ ժամանակի խիստ դդմերը վերջապես նպատակներ հայտարարեցին -- սա արդյունաբերություն չէ, այնպես չի կարելի աշխատել։ Եվ նրանք բերեցին կյանքային ցիկլի մոդելներ։ Օրինակ, V-մոդելը։
Ուրեմն, ինչ տեսնում ենք։ Բիզնեսը գալիս է կոնցեպտով, ճարտարապետները նախագծում են լուծումներ, մշակողները գրում են կոդ, հետո -- խափանում։ Ոմանք ինչ-որ կերպ ստուգում են արտադրանքը, ոմանք ինչ-որ կերպ հասցնում են վերջնական օգտագործողին և որտեղ-որ ինչ-որ փայլատակում այլ որևէ մեկը սպասում է խոստացվածից: Գնացինք եզրակացության, որ անհրաժեշտ են մեթոդներ, որոնք կօգնեն կարգավորել այս գործընթացը: Եվ որոշեցին ստեղծել պրակտիկաներ, որոնք կիրականացնեն դրանք:
Ակնածություն, թե ինչ է պրակտիկան
Պրակտիկա չեմ առնում տեխնոլոգիայի և կարգի փողոցների հավաքույք: Օրինակ՝ ինֆրასტրուկտուրայի նկարագրություն կոդով terraform-ի վրա: Կարգը՝ սա է, թե ինչպես նկարագրել կոդով ինֆրասներժան, նրա միջոցով ընթացել է, իսկ տեխնոլոգիան՝ դա հենց terraform-ը:
Եվ որ նրանք որոշեցին անվանել այդ DevOps պրակտիկաներ -- կարծում եմ, նկատի ունեին Development-ից Operations։ Քայլած տասնյակ գործելակերպերը՝ CI/CD պրակտիկաներ, IaC սկզբունքի վրա հիմնված պրակտիկաներ...ու այլն։ Ավելի վաղ ադմինիստրատորները, նոր պրակտիկաներ իրականացնելով, տպավորիչ կերպով էին վերապատրաստվել DevOps ինժեներների, և այդպես շարունակվեց: Եվ երեկոյան զգացի, իսկ ուսումնաբանությոտն էր... ներեցեք, հենց այդտեղից է:
Ամեն ինչ դեռևս լավ չէ
Միայն ամեն ինչ կարգավորվել էր, և տարբեր հմտությամբ «մեթոդոլոգներ» սկսեցին գրելու հաստ գրքեր DevOps պրակտիկաների մասին, կիսաձայն վեճեր ծագեցին, ով է իրականում համբավավոր DevOps ինժեները և ինչ է DevOps՝ արտադրության մշակույթ, նորից դժգոհություն առաջացավ: Հանկարծ պարզվեց, որ ծրագրակազմի առաքումը՝ լրիվ անկանխատեսելի խնդիր է: Յուրաքանչյուր զարգացման ինֆրակառուցվածք ունի իր ստեկը, որտեղ պետք է հավաքել, որտեղ պետք է բացել միջավայր, այստեղ պետք է tomcat, այստեղ պետք է մեկ այլ խճճված միջոց գործարկման համար՝ ընդհանուր առմամբ, գլխին ցավ է: Եվ նաև խնդիր էր, այլ բան, որ անսովոր էր, առաջին հերթին գործառնությունների կազմակերպման մեջ էր՝ այս առաքման գործառույթը, որպես նեղ կայարան, սկսեց խոչընդոտել գործընթացները: Այնուամենայնիվ, շահագործումը (Operations) ոչ ոք չեղարկեց: Նրա մեջ V-мոդելում չկար, իսկ այնտեղ դեռ ամբողջ կյանքի ցիկլն էր աջ կողմից: Թերևս, անհրաժեշտ էր ինչպես ինչ-որ կերպ աջակցել ինֆրակառուցվածքին, նաև ուշադրություն դարձնել մոնիթորինգին, վթարները լուծել և դեռ Առաքմամբ զբաղվել: Թ.е., նստել մեկ ոտքով ինչպես զարգացում և շահագործում, և հանկարծ այդպիսին դարձավ Development & Operations: Իսկ այստեղ ևս եկավ միկրոսերվիսների համատարած հիթը: Իսկ այդ միկրոսերվիսներ դեռ տեղից սկսեցին տեղափոխվել ս/cloud՝ փորձիր ինչ-որ բան տեղակականից կարգավորել, եթե միկրոսերվիսների տասնյակներ և հարյուրավորներ կա, այստեղ արդեն մշտական առաքումը վերածվում է գոյատևման միջոցի: «Փոքր զուսպ ընկերության» համար դեռ նորմալ է, բայց այնուամենայնիվ? Իսկ Google-ի համար:
SRE Google-ից
Համարում գնաց Google, կերավ ամենամեծ կակտուսներն ու որոշեց՝ մեզ նման բան պետք չէ, մեզ հուսալիություն պետք է: Հուսատարագի պետք է կառավարել: Եվ որոշեց՝ մեզ անհրաժեշտ են մասնագետներ, ովքեր կհսկեն հուսալիությունը: Նրանք նրանց անվանեցին SR-ինժեներներ և ասացին, ահա ձեզ ամենը, արեք, ինչպես միշտ, լավ: Ահա ձեզ SLI, ահա ձեզ SLO, ահա ձեզ մոնիթորինգ: Եվ ցույց տվեց operations-ին: Եվ կոչեց իր «հուսալի DevOps»-ը SRE: Ընդհանուր առմամբ, ամեն մի բան լավ է, բայց կա մեկ արատավոր հաք, որը Google-ը կարող էր թույլ տալ՝ SR ինժեներների պաշտոններում տարատեսակ մարդկանց նորել, որոնք ունեին ծրագրավորողների որակավորում և ավելին՝ մի փոքր ժամանակ գիտեին գործող համակարգերի գործում: Причоум, այդպիսի մարդկանց հարկավոր էր նաև Google-ին հետ հետընթաց. հիմնականում հենց նրա իսկ մրցակցության պատճառով՝ պետք է և բիզնես-լոգիկան պետք է ինչ-որ մեկին նկարագրել: Առաքումը բաժանել էր հրապարակային ինժեների, SR— ինժեներները հսկում են հուսալիությունը (պարզ է, ոչ ուղղակի, այլ ազդելով ինֆրակառուցվածքի վրա, փոխելով ճարտարապետությունը, հետևելով փոփոխություններին և ցուցանիշներին, զբաղվելով վթարներով): Գեղեցիկ է, կարելի է . Իսկ ի՞նչ անել, եթե դուք Google չեք, բայց հուսալիությունը, այնուամենայնիվ, ինչ-որ կերպ անհանգստացնում է?
DevOps գաղափարների զարգացումը
Այստեղ իրեն լավ զգաց Docker-ը, որը հայտնվեց lxc-ից, իսկ հետո տարբեր օրգեյստրաционных համակարգեր, ինչպիսիք են Docker Swarm և Kubernetes, ու DevOps ինժեներները թուլացան՝ պրակտիկաների միացումն ավելի հեշտացրեց տրամադրման գործընթացը: Այնքան, որ հնարավոր դարձավ նույնիսկ փոխանցել տրամադրումը մշակողների ձեռքին՝ ինչի վատն էր deployment.yaml-ին: Կոնտեյներացում խնդիրը լուծում է: Եվ CI/CD համակարգերի հասունությունը արդեն այնքան բարձր է, որ կարելի է գրել մեկ ֆայլ և բոլոր բաները կսկսվեն՝ մշակողները ինքնուրույն կբերեն: Եվ այստեղ մենք սկսում ենք խոսել, թե ինչպես ենք մեր SRE-ն ստեղծելու, անգամ… ով էլ լինի:
SRE Google-ում չէ
Ախ, էլի մենք փոխանցումը թողեցինք, թվում է կարող ենք թուլանալ, վերադառնալ հին բարեբեր ժամանակներ, երբ ադմինները հետևում էին պրոցեսորների բեռին, կարգավորում համակարգերը և հանգիստ ու լուռ խմում էին ինչ-որ անբացատրելի բաների գավաթից… Ստոպ: Մենք դա չենք արել (իսկ, ցավալի է!). Հանկարծ պարզվում է, որ Google-ի մոտեցման մեջ մենք իսկապես կարող ենք վերցնել լավ պրակտիկաներ՝ պրոցեսորների բեռը կարևոր չէ, ու ոչ թե, թե որքան հաճախ ենք մենք փոխում սկավառակները, կամ թե ինչպես ենք համակարգչի ծախսերը օպտիմալացնում ծխում, այլ բիզնես-մետрики՝ բոլոր նույն SLx-ները: Եվ ենթակառուցվածքի կառավարման գրպանը ոչ մեկի ձեռքում չի եղել, և միջադեպերը պետք է լուծել, ու պարբերաբար հերթապահել, ու նույնիսկ բիզնես-գործընթացների մասում լինել: Եվ տղաներ, սկսեք արդեն աստիճանաբար ծրագրել լավ մակարդակում, Google-ը արդեն ձեզ է սպասում:
Ամփոփելով. Հանկարծ, բայց դուք արդեն հոգնել եք կարդալուց ու ուզում եք գցել մեկնաբանություն հոդվածի հեղինակի համար: DevOps-ը որպես տրամադրման պրակտիկա եղել, կա և կլինի: Եվ ոչ տեղից չի հեռանալու: SRE-ն որպես շահագործման պրակտիկաների հավաքածու այս տրամադրումը հաջողությամբ իրականացնում է.
Ընտանիք: habr.com
