Զրույցի քննարկման հիման վրա
Վերջերս իրական մարտեր են բռնկվել DevOps-ի և SRE-ի սահմանման շուրջ:
Չնայած այն հանգամանքին, որ այս թեմայի շուրջ քննարկումները շատ առումներով արդեն իսկ շեղել են իմ ատամները, այդ թվում՝ ես, ես որոշեցի այս թեմայի վերաբերյալ իմ տեսակետը ներկայացնել Հաբրա համայնքի դատարան: Նրանց համար, ովքեր հետաքրքրված են, համեցեք կատու: Եվ թող ամեն ինչ սկսվի նորից:
նախապատմությանը
Այսպիսով, հին ժամանակներում ծրագրային ապահովման մշակողների և սերվերի ադմինիստրատորների թիմը առանձին էր ապրում: Առաջինը հաջողությամբ գրեց կոդը, երկրորդը, օգտագործելով տարբեր ջերմ, սիրալիր խոսքեր առաջինին ուղղված, տեղադրեց սերվերները, պարբերաբար գալով ծրագրավորողներին և ի պատասխան ստանալով համապարփակ «ամեն ինչ աշխատում է իմ մեքենայի վրա»: Բիզնեսը սպասում էր ծրագրային ապահովմանը, ամեն ինչ պարապ էր, պարբերաբար կոտրվում էր, բոլորը նյարդայնանում էին։ Հատկապես նա, ով վճարել է այս ամբողջ խառնաշփոթի համար: Փառավոր լամպերի դարաշրջան. Դե, դուք արդեն գիտեք, թե որտեղից է գալիս DevOps-ը:
DevOps պրակտիկայի ծնունդը
Հետո լուրջ տղաներ եկան ու ասացին՝ սա արդյունաբերություն չէ, չես կարող այդպես աշխատել։ Եվ նրանք բերեցին կյանքի ցիկլի մոդելներ: Ահա, օրինակ, V-մոդելը։
Այսպիսով, ինչ ենք մենք տեսնում: Բիզնեսը գալիս է կոնցեպտով, ճարտարապետները նախագծում են լուծումներ, ծրագրավորողները գրում են կոդ, իսկ հետո այն ձախողվում է: Ինչ-որ մեկը ինչ-որ կերպ փորձարկում է արտադրանքը, ինչ-որ մեկը ինչ-որ կերպ այն մատակարարում է վերջնական օգտագործողին, և ինչ-որ տեղ այս հրաշք մոդելի ելքի մոտ նստած է միայնակ գործարար հաճախորդը, որը սպասում է խոստացված եղանակին ծովի մոտ: Մենք եկել ենք այն եզրակացության, որ մեզ անհրաժեշտ են մեթոդներ, որոնք թույլ կտան մեզ հաստատել այս գործընթացը։ Եվ մենք որոշեցինք ստեղծել պրակտիկա, որը կիրականացնի դրանք:
Քնարական շեղում այն թեմայի շուրջ, թե ինչ է պրակտիկան
Պրակտիկա ասելով նկատի ունեմ տեխնոլոգիայի և կարգապահության համադրություն: Օրինակ՝ ենթակառուցվածքի նկարագրության պրակտիկան՝ օգտագործելով տերրաֆորմ կոդը: Կարգապահությունն այն է, թե ինչպես կարելի է նկարագրել ենթակառուցվածքը կոդով, այն գտնվում է ծրագրավորողի գլխում, իսկ տեխնոլոգիան ինքնին տերրաֆորմն է:
Եվ նրանք որոշեցին դրանք անվանել DevOps-ի պրակտիկա, կարծում եմ՝ նկատի ուներ Զարգացումից մինչև Գործառնություններ: Մտածեցինք տարբեր խելացի բաներ՝ CI/CD պրակտիկա, IaC սկզբունքի վրա հիմնված պրակտիկա, հազարավոր դրանցից: Եվ մենք գնում ենք, մշակողները գրում են կոդ, DevOps-ի ինժեներները համակարգի նկարագրությունը վերափոխում են կոդի տեսքով գործող համակարգերի (այո, կոդը, ցավոք, պարզապես նկարագրություն է, բայց ոչ համակարգի մարմնավորում), առաքումը շարունակվում է, եւ այլն։ Երեկվա ադմինիստրատորները, յուրացնելով նոր պրակտիկա, հպարտությամբ վերապատրաստվեցին որպես DevOps-ի ինժեներներ, և ամեն ինչ գնաց այնտեղից: Եվ երեկո եղավ, և եղավ առավոտ... կներեք, ոչ այնտեղից:
Նորից ամեն ինչ լավ չէ, փառք Աստծո
Հենց որ ամեն ինչ հանդարտվեց, և տարբեր խորամանկ «մեթոդաբաններ» սկսեցին հաստ գրքեր գրել DevOps-ի պրակտիկայի վերաբերյալ, վեճերը անաղմուկ բռնկվեցին այն մասին, թե ով է տխրահռչակ DevOps ինժեները, և որ DevOps-ը արտադրության մշակույթ է, նորից դժգոհություն առաջացավ: Հանկարծ պարզվեց, որ ծրագրային ապահովման առաքումը բացարձակապես ոչ տրիվիալ խնդիր է։ Զարգացման յուրաքանչյուր ենթակառուցվածք ունի իր փաթեթը, ինչ-որ տեղ դուք պետք է հավաքեք այն, ինչ-որ տեղ պետք է տեղակայեք միջավայրը, այստեղ ձեզ հարկավոր է Tomcat, այստեղ ձեզ հարկավոր է այն գործարկելու խորամանկ և բարդ եղանակ. ընդհանուր առմամբ, ձեր գլուխը ծեծում է: Եվ խնդիրը, տարօրինակ կերպով, պարզվեց, որ հիմնականում պրոցեսների կազմակերպման մեջ է. առաքման այս գործառույթը, ինչպես շիշը, սկսեց արգելափակել գործընթացները: Բացի այդ, ոչ ոք չեղարկեց Գործողությունները: V-մոդելում այն տեսանելի չէ, բայց աջ կողմում դեռ ողջ կյանքի ցիկլն է: Արդյունքում անհրաժեշտ է ինչ-որ կերպ պահպանել ենթակառուցվածքը, վերահսկել մոնիտորինգը, կարգավորել միջադեպերը, ինչպես նաև զբաղվել առաքմամբ։ Նրանք. նստեք մեկ ոտքով և՛ մշակման, և՛ շահագործման մեջ, և հանկարծ պարզվեց, որ դա եղել է «Զարգացում և գործառնություններ»: Եվ հետո ընդհանուր աղմուկ բարձրացավ միկրոծառայությունների համար: Եվ նրանց հետ տեղական մեքենաներից զարգացումը սկսեց շարժվել դեպի ամպ. փորձեք ինչ-որ բան կարգաբերել տեղում, եթե կան տասնյակ և հարյուրավոր միկրոծառայություններ, ապա մշտական առաքումը դառնում է գոյատևման միջոց: «Փոքր համեստ ընկերության» համար ամեն ինչ կարգին էր, բայց այնուամենայնիվ: Ինչ վերաբերում է Google-ին:
SRE Google-ի կողմից
Google-ը եկավ, կերավ ամենամեծ կակտուսները և որոշեց. մեզ սա պետք չէ, մեզ հուսալիություն է պետք: Իսկ հուսալիությունը պետք է կառավարվի։ Եվ ես որոշեցի, որ մեզ պետք են մասնագետներ, ովքեր կկառավարեն հուսալիությունը։ Ես նրանց անվանեցի SR ինժեներներ և ասացի, որ դա ձեզ համար է, դա լավ արեք, ինչպես միշտ: Ահա SLI, ահա SLO, ահա մոնիտորինգ: Եվ նա քիթը խոթեց վիրահատության մեջ։ Եվ նա անվանեց իր «հուսալի 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-ը, որպես գործառնական պրակտիկաների մի շարք, այս առաքումը հաջողակ է դարձնում:
Source: www.habr.com