Խոսքը, իհարկե, մասին է . Եթե չմանրամասնեք, ապա սեպտեմբերի 30-ին և հոկտեմբերի 1-ին մենք կանցկացնենք կոնֆերանս՝ մշակման, փորձարկման և շահագործման գործընթացները համատեղելու վերաբերյալ, իսկ եթե խորանաք, խնդրում եմ, կատվի տակ։
DevOps մոտեցման շրջանակներում նախագծի տեխնոլոգիական զարգացման բոլոր մասերը փոխկապակցված են, տեղի են ունենում զուգահեռ և ազդում միմյանց վրա: Այստեղ առանձնահատուկ նշանակություն ունի մշակման ավտոմատացված գործընթացների ստեղծումը, որոնք կարող են փոփոխվել, մոդելավորվել և փորձարկվել իրական ժամանակում: Սա օգնում է ձեզ անմիջապես արձագանքել շուկայի փոփոխություններին:
Համաժողովում մենք ցանկանում ենք ցույց տալ, թե ինչպես է այս մոտեցումն ազդում արտադրանքի զարգացման վրա: Ինչպես է ապահովվում համակարգի հուսալիությունը և հարմարվողականությունը հաճախորդի համար: Ինչպես է DevOps-ը փոխում ընկերության կառուցվածքն ու մոտեցումն իր աշխատանքային գործընթացի կազմակերպման հարցում:
կուլիսների ետեւում
Մեզ համար կարևոր է ոչ միայն իմանալ, թե ինչ են անում տարբեր ընկերություններ DevOps մոտեցման շրջանակներում, այլև հասկանալ, թե ինչու է այս ամենը արվում։ Հետևաբար, մենք հրավիրեցինք ոչ միայն փորձագետների՝ միանալու Ծրագրի կոմիտեին, այլ նաև մասնագետների, ովքեր տեսնում են DevOps-ի դիսկուրսը տարբեր դիրքերից.
- ավագ ինժեներներ;
- մշակողներ;
- թիմի ղեկավարներ;
- CTO.
Սա մի կողմից ստեղծում է դժվարություններ և կոնֆլիկտներ հաշվետվությունների հարցումները քննարկելիս: Եթե ինժեներին հետաքրքրում է խոշոր վթարի վերլուծությունը, ապա մշակողի համար ավելի կարևոր է հասկանալ, թե ինչպես ստեղծել ամպերի և ենթակառուցվածքների վրա աշխատող ծրագրակազմ: Բայց համաձայնվելով, մենք ստեղծում ենք մի ծրագիր, որը արժեքավոր և հետաքրքիր կլինի բոլորի համար՝ ինժեներներից մինչև CTO:
Մեր կոնֆերանսի նպատակն է ոչ միայն ընտրել ամենահայտնի հաշվետվությունները, այլ ներկայացնել ընդհանուր պատկերը՝ ինչպես է աշխատում DevOps-ի մոտեցումը գործնականում, ինչպիսի ռոքի կարող եք հանդիպել նոր գործընթացներին անցնելիս: Միաժամանակ մենք կառուցում ենք բովանդակային մասը՝ բիզնես խնդրից իջնելով կոնկրետ տեխնոլոգիաների։
Կոնֆերանսի բաժինները կմնան նույնը, ինչ եղել է .
- Ենթակառուցվածքային հարթակ.
- Ենթակառուցվածքը որպես ծածկագիր:
- Շարունակական առաքում.
- Հետադարձ կապ.
- Ճարտարապետություն DevOps-ում, DevOps՝ CTO-ի համար:
- SRE պրակտիկա.
- Ուսուցում և գիտելիքների կառավարում.
- Անվտանգություն, DevSecOps:
- DevOps-ի փոխակերպում.
Զանգահարեք փաստաթղթերի համար. ինչպիսի զեկույցներ ենք մենք փնտրում
Մենք պայմանականորեն բաժանեցինք կոնֆերանսի պոտենցիալ լսարանը հինգ խմբի՝ ինժեներներ, մշակողներ, անվտանգության մասնագետներ, թիմի ղեկավարներ և CTO: Յուրաքանչյուր խումբ ունի համաժողովին գալու իր մոտիվացիան: Եվ, եթե նայեք DevOps-ին այս դիրքերից, կարող եք հասկանալ, թե ինչպես կենտրոնացնել ձեր թեման և որտեղ շեշտը դնել:
Ինժեներների համար, ովքեր ենթակառուցվածքային հարթակ են ստեղծում, կարևոր է հասկանալ առկա միտումները, հասկանալ, թե որ տեխնոլոգիաներն են այժմ ամենաառաջադեմը: Նրանք շահագրգռված կլինեն իմանալ այս տեխնոլոգիաների օգտագործման իրական փորձի մասին և կարծիքներ փոխանակել: Ինժեները հաճույքով կլսի մի զեկույց, որը վերլուծում է որոշ ծանր վթար, և մենք, իր հերթին, կփորձենք ընտրել և հղկել նման զեկույցը:
Մշակողների համար Կարևոր է հասկանալ այնպիսի հասկացություն, ինչպիսին է ամպի բնիկ հավելված. Այսինքն՝ ինչպես մշակել ծրագրակազմ, որպեսզի այն աշխատի ամպերում և տարբեր ենթակառուցվածքներում։ Մշակողը պետք է անընդհատ հետադարձ կապ ստանա ծրագրաշարից: Այստեղ մենք ցանկանում ենք լսել դեպքեր, թե ինչպես են ընկերությունները կառուցում այս գործընթացը, ինչպես վերահսկել ծրագրային ապահովման աշխատանքը և ինչպես է աշխատում առաքման ամբողջ գործընթացը:
Կիբերանվտանգության մասնագետներ Կարևոր է հասկանալ, թե ինչպես կարգավորել անվտանգության գործընթացը, որպեսզի այն չխանգարի ընկերության ներսում զարգացման և փոփոխության գործընթացներին: Հետաքրքիր կլինեն նաև այն պահանջների մասին թեմաները, որոնք DevOps-ը դնում է նման մասնագետների նկատմամբ։
Թիմի ղեկավարները ցանկանում են իմանալ, ինչպես է աշխատում շարունակական առաքման գործընթացը այլ ընկերություններում: Ինչ ճանապարհ են անցել ընկերությունները դրան հասնելու համար, ինչպես են նրանք կառուցել զարգացման և որակի ապահովման գործընթացներ DevOps-ում: Թիմի առաջատարները նույնպես հետաքրքրված են Cloud native-ով: Եվ նաև հարցեր թիմի ներսում և զարգացման և ինժեներական թիմերի միջև փոխգործակցության վերաբերյալ:
Համար ԱՏՏ Ամենակարևորը պարզելն է, թե ինչպես միացնել այս բոլոր գործընթացները և հարմարեցնել դրանք բիզնեսի կարիքներին: Նա համոզվում է, որ հավելվածը հուսալի է և՛ բիզնեսի, և՛ հաճախորդի համար։ Եվ այստեղ դուք պետք է հասկանաք, թե որ տեխնոլոգիաները կաշխատեն բիզնես առաջադրանքների համար, ինչպես կառուցել ամբողջ գործընթացը և այլն: CTO-ն պատասխանատու է նաև բյուջետավորման համար: Օրինակ, նա պետք է հասկանա, թե որքան գումար է պետք ծախսել մասնագետների վերապատրաստման վրա, որպեսզի նրանք կարողանան աշխատել DevOps-ում։
Եթե այս հարցերի շուրջ ասելիք ունեք, մի լռեք, . Փաստաթղթերի ընդունման վերջնաժամկետը օգոստոսի 20-ն է: Որքան շուտ գրանցվեք, այնքան ավելի շատ ժամանակ կունենաք ձեր զեկույցը վերջնական տեսքի բերելու և ներկայացմանը պատրաստվելու համար: Այնպես որ, մի հապաղեք։
Դե, եթե հրապարակավ խոսելու կարիք չունեք, պարզապես իսկ սեպտեմբերի 30-ին և հոկտեմբերի 1-ին արի գործընկերների հետ շփվելու։ Խոստանում ենք, որ այն կլինի հետաքրքիր և ոգեշնչող։
Ինչպես ենք մենք տեսնում DevOps-ը
Հստակ հասկանալու համար, թե ինչ նկատի ունենք DevOps ասելով, խորհուրդ եմ տալիս կարդալ (կամ վերընթերցել) իմ զեկույցը:« Քայլելով շուկայի ալիքներով՝ ես նկատեցի, թե ինչպես է DevOps-ի գաղափարը փոխակերպվում տարբեր չափերի ընկերություններում՝ փոքր ստարտափից մինչև բազմազգ ընկերություններ: Զեկույցը կառուցված է մի շարք հարցերի վրա, որոնց պատասխանելով դուք կարող եք հասկանալ՝ ձեր ընկերությունը շարժվում է դեպի DevOps, թե ինչ-որ տեղ խնդիրներ կան։
DevOps-ը բարդ համակարգ է, այն պետք է ներառի.
- Թվային արտադրանք.
- Բիզնես մոդուլներ, որոնք զարգացնում են այս թվային արտադրանքը:
- Ապրանքի թիմեր, որոնք գրում են կոդը:
- Շարունակական առաքման պրակտիկա:
- Հարթակները որպես ծառայություն:
- Ենթակառուցվածքը որպես ծառայություն.
- Ենթակառուցվածքը որպես ծածկագիր:
- Հուսալիության պահպանման առանձին պրակտիկա՝ ներկառուցված DevOps-ում:
- Հետադարձ կապի պրակտիկա, որը նկարագրում է այդ ամենը:
Զեկույցի վերջում կա մի դիագրամ, որը պատկերացում է տալիս ընկերության DevOps համակարգի մասին: Այն թույլ կտա ձեզ տեսնել, թե ձեր ընկերությունում որ գործընթացներն են արդեն պարզեցված և որոնք դեռ պետք է կառուցվեն:
Ռեպորտաժի տեսանյութը կարող եք դիտել .
Եվ հիմա կլինի բոնուս. մի քանի տեսանյութ RIT++ 2019-ից, որոնք շոշափում են DevOps-ի վերափոխման ամենաընդհանուր խնդիրները:
Ընկերության ենթակառուցվածքը որպես արտադրանք
Արտյոմ Նաումենկոն գլխավորում է DevOps թիմը Skyeng-ում և հոգ է տանում իր ընկերության ենթակառուցվածքի զարգացման մասին։ Նա պատմեց, թե ինչպես են ենթակառուցվածքն ազդում SkyEng-ի բիզնես գործընթացների վրա. ինչպես հաշվարկել դրա համար ROI, ինչ չափումներ պետք է ընտրել հաշվարկի համար և ինչպես աշխատել դրանք բարելավելու համար:
Միկրոծառայությունների ճանապարհին
Nixys ընկերությունը ապահովում է զբաղված վեբ նախագծերի և բաշխված համակարգերի աջակցություն: Նրա տեխնիկական տնօրեն Բորիս Էրշովը պատմեց, թե ինչպես թարգմանել ծրագրային արտադրանքները, որոնց զարգացումը սկսվել է 5 տարի առաջ (կամ նույնիսկ ավելի), ժամանակակից հարթակ:
Որպես կանոն, նման նախագծերը յուրահատուկ աշխարհ են, որտեղ կան ենթակառուցվածքի այնպիսի մութ ու հնագույն անկյուններ, որոնց մասին ներկայիս ինժեներները չգիտեն։ Իսկ ճարտարապետության և զարգացման մոտեցումները, որոնք ժամանակին ընտրվել են, հնացած են և չեն կարող բիզնեսին ապահովել զարգացման և նոր տարբերակների թողարկման նույն տեմպերով։ Արդյունքում, յուրաքանչյուր արտադրանքի թողարկումը վերածվում է անհավանական արկածի, որտեղ ինչ-որ բան անընդհատ ընկնում է, և ամենաանսպասելի վայրում:
Նման նախագծերի ղեկավարներն անխուսափելիորեն բախվում են բոլոր տեխնոլոգիական գործընթացները վերափոխելու անհրաժեշտությանը: Իր զեկույցում Բորիսն ասել է.
- ինչպես ընտրել նախագծի համար ճիշտ ճարտարապետությունը և կարգի բերել ենթակառուցվածքը.
- ինչ գործիքներ օգտագործել և ինչ որոգայթներ են հանդիպում վերափոխման ճանապարհին.
- ինչ անել հետո:
Թողարկումների ավտոմատացում կամ ինչպես արագ և ցավ չպատճառել
Ալեքսանդր Կորոտկովը CIAN-ում CI/CD համակարգի առաջատար մշակողն է: Նա խոսեց ավտոմատացման գործիքների մասին, որոնք հնարավորություն տվեցին բարելավել որակը և 5 անգամ կրճատել կոդերի արտադրությանը հասցնելու ժամանակը։ Բայց այդպիսի արդյունքների հնարավոր չէր հասնել միայն ավտոմատացման միջոցով, ուստի Ալեքսանդրը նույնպես ուշադրություն դարձրեց զարգացման գործընթացների փոփոխություններին:
Ինչպե՞ս են պատահարներն օգնում ձեզ սովորել:
Ալեքսեյ Կիրպիչնիկովը SKB Kontur-ում իրականացնում է DevOps և ենթակառուցվածքներ արդեն 5 տարի: Երեք տարվա ընթացքում նրա ընկերությունում տեղի է ունեցել մոտավորապես 1000 ֆակապ՝ տարբեր աստիճանի էպիկականությամբ: Դրանցից, օրինակ, 36%-ը առաջացել է ցածրորակ թողարկում արտադրություն դուրս բերելու պատճառով, իսկ 14%-ը՝ տվյալների կենտրոնի ապարատային տեխնիկական սպասարկման աշխատանքների արդյունքում:
Հաշվետվությունների (հետմահու) արխիվը, որը ընկերության ինժեներները պահպանում են մի քանի տարի անընդմեջ, թույլ է տալիս ստանալ նման ճշգրիտ տեղեկատվություն վթարների մասին: Դիահերձումը գրված է հերթապահ ինժեների կողմից, ով առաջինն արձագանքեց վթարային ազդանշանին և սկսեց ամեն ինչ շտկել։ Ինչու՞ տանջել ինժեներներին, ովքեր գիշերները պայքարում են դեմքերի հետ՝ հաշվետվություններ գրելով: Այս տվյալները թույլ են տալիս տեսնել ամբողջ պատկերը և ճիշտ ուղղությամբ տանել ենթակառուցվածքների զարգացումը։
Իր ելույթում Ալեքսեյը կիսվել է, թե ինչպես գրել իսկապես օգտակար հետմահու և ինչպես իրականացնել նման զեկույցների պրակտիկան մեծ ընկերությունում: Եթե ձեզ դուր են գալիս պատմություններ այն մասին, թե ինչպես է ինչ-որ մեկը խաբել, դիտեք ներկայացման տեսանյութը:
Մենք հասկանում ենք, որ DevOps-ի ձեր տեսլականը կարող է չհամընկնել մեր տեսլականի հետ: Հետաքրքիր կլինի իմանալ, թե ինչպես եք տեսնում DevOps-ի փոխակերպումը: Կիսվեք ձեր փորձով և այս թեմայի տեսլականով մեկնաբանություններում:
Ի՞նչ զեկույցներ ենք մենք արդեն ընդունել ծրագրում:
Այս շաբաթ Ծրագրային կոմիտեն ընդունել է 4 զեկույց՝ անվտանգության, ենթակառուցվածքների և SRE պրակտիկայի վերաբերյալ:
Թերևս DevOps-ի վերափոխման ամենացավոտ թեման. ինչպես համոզվել, որ տեղեկատվական անվտանգության բաժնի տղաները չեն քանդում արդեն իսկ կառուցված կապերը զարգացման, շահագործման և կառավարման միջև: Որոշ ընկերություններ կառավարում են առանց տեղեկատվական անվտանգության բաժնի. Ինչպե՞ս ապահովել տեղեկատվական անվտանգությունն այս դեպքում։ Դրա մասին Մոնա Արխիպովան sudo.su-ից. Նրա զեկույցից տեղեկանում ենք.
- ինչն է պետք պաշտպանել և ումից;
- որոնք են սովորական անվտանգության գործընթացները;
- ինչպես են հատվում ՏՏ և տեղեկատվական անվտանգության գործընթացները.
- ինչ է ԱՊՀ CSC-ն և ինչպես այն իրականացնել.
- ինչպես և ինչ ցուցանիշներով իրականացնել տեղեկատվական անվտանգության կանոնավոր ստուգումներ։
Հաջորդ զեկույցը վերաբերում է ենթակառուցվածքների զարգացմանը որպես ծածկագիր։ Նվազեցրե՛ք ձեռքի առօրյայի քանակը և ամբողջ նախագիծը մի վերածեք քաոսի, հնարավո՞ր է դա: Այս հարցին Մաքսիմ Կոստրիկինը Իքսթենսից. Նրա ընկերությունն օգտագործում է Terraform AWS ենթակառուցվածքի հետ աշխատելու համար: Գործիքը հարմար է, բայց հարցն այն է, թե ինչպես խուսափել կոդի հսկայական բլոկ ստեղծելուց այն օգտագործելիս: Նման ժառանգության պահպանումը տարեցտարի ավելի ու ավելի թանկ է դառնալու։
Maxim-ը ցույց կտա, թե ինչպես են աշխատում կոդերի տեղադրման օրինաչափությունները՝ ուղղված ավտոմատացման և զարգացման պարզեցմանը:
Եվս մեկ մենք կլսենք ենթակառուցվածքների մասին Վլադիմիր Ռյաբովը Playkey-ից. Այստեղ մենք կխոսենք ենթակառուցվածքի հարթակի մասին և կսովորենք.
- ինչպես հասկանալ, թե արդյոք պահեստային տարածքն արդյունավետ է օգտագործվում.
- ինչպես կարող են մի քանի հարյուր օգտատերեր ստանալ 10 ՏԲ բովանդակություն, եթե օգտագործվում է միայն 20 ՏԲ պահեստ;
- ինչպես սեղմել տվյալները 5 անգամ և դրանք տրամադրել օգտատերերին իրական ժամանակում;
- ինչպես համաժամացնել տվյալները մի քանի տվյալների կենտրոնների միջև թռիչքի ժամանակ.
- ինչպես վերացնել օգտատերերի ցանկացած ազդեցություն միմյանց վրա մեկ վիրտուալ մեքենա հաջորդաբար օգտագործելիս:
Այս կախարդանքի գաղտնիքը տեխնոլոգիան է ZFS FreeBSD-ի համար և նրա թարմ պատառաքաղը ZFS- ը Linux- ում. Վլադիմիրը կկիսվի Playkey-ի գործերով:
Matvey Kukuy Amixr.IO-ից պատրաստ է կյանքի օրինակներով , ինչ է պատահել ՍԻՐ և ինչպես է այն օգնում կառուցել հուսալի համակարգեր: Amixr.IO-ն փոխանցում է հաճախորդների հետ կապված միջադեպերը ամբողջ աշխարհում տասնյակ հերթապահ թիմեր արդեն զբաղվել են 150 հազար գործերով: Համաժողովում Մատվեյը կկիսվի վիճակագրությամբ և պատկերացումներով, որոնք իր ընկերությունը կուտակել է՝ լուծելով հաճախորդների խնդիրները և վերլուծելով ձախողումները:
Եվս մեկ անգամ կոչ եմ անում ձեզ ագահ չլինել և կիսվել ձեր փորձով որպես DevOps սամուրայ: Ծառայել զեկույցի համար, և ես և դու 2,5 ամիս կունենանք հիանալի ելույթ պատրաստելու համար։ Եթե ուզում ես լինել ունկնդիր, ծրագրի թարմացումներով տեղեկագրին և լրջորեն մտածեք տոմսերը ժամանակից շուտ ամրագրելու մասին, քանի որ դրանք ավելի մոտ կթանկանան համաժողովի ամսաթվերին։
Source: www.habr.com