Անտոն Վայսը, Otomato Software-ի հիմնադիրն ու տնօրենը, Իսրայելում DevOps-ի առաջին սերտիֆիկացման նախաձեռնողներից և հրահանգիչներից մեկը, ելույթ ունեցավ անցյալ տարվա ընթացքում։ քաոսի տեսության և քաոսի ճարտարագիտության հիմնական սկզբունքների մասին, ինչպես նաև բացատրեց, թե ինչպես է աշխատում ապագայի DevOps-ի իդեալական կազմակերպումը:
Մենք պատրաստել ենք զեկույցի տեքստային տարբերակը։
Good morning!
DevOpsDays Մոսկվայում երկրորդ տարին անընդմեջ, սա իմ երկրորդ անգամն է այս բեմում, ձեզնից շատերը երկրորդ անգամ են այս սենյակում: Ինչ է դա նշանակում? Սա նշանակում է, որ Ռուսաստանում DevOps շարժումը աճում է, բազմապատկվում, և որ ամենակարևորը նշանակում է, որ եկել է ժամանակը խոսելու, թե ինչ է DevOps-ը 2018 թվականին։
Բարձրացրեք ձեր ձեռքերը, ովքեր կարծում են, որ DevOps-ն արդեն մասնագիտություն է 2018 թվականին: Կան այդպիսիք. Սենյակում կա՞ն DevOps-ի ինժեներներ, որոնց աշխատանքի նկարագրության մեջ գրված է «DevOps Engineer»: Սենյակում DevOps-ի մենեջերներ կա՞ն: Չկա այդպիսին։ DevOps ճարտարապետներ: Նաև ոչ: Բավական չէ։ Իսկապե՞ս ճիշտ է, որ ոչ ոք չի ասում, որ իրենք DevOps-ի ինժեներ են:
Այսպիսով, ձեզանից շատերը կարծում են, որ սա հակաօրինաչափություն է: Որ նման մասնագիտություն չպիտի՞ լինի։ Մենք կարող ենք մտածել այն, ինչ ուզում ենք, բայց մինչ մենք մտածում ենք, արդյունաբերությունը հանդիսավոր կերպով առաջ է շարժվում դեպի DevOps շեփորի ձայնը:
Ո՞վ է լսել նոր թեմայի մասին, որը կոչվում է DevDevOps: Սա նոր տեխնիկա է, որը թույլ է տալիս արդյունավետ համագործակցել մշակողների և devops-ի միջև: Եվ ոչ այնքան նոր: Դատելով Twitter-ից՝ այս մասին նրանք արդեն սկսել են խոսել 4 տարի առաջ։ Եվ մինչ այժմ սրա նկատմամբ հետաքրքրությունը գնալով աճում է, այսինքն՝ խնդիր կա։ Խնդիրը պետք է լուծվի։
Մենք ստեղծագործ մարդիկ ենք, մենք պարզապես հանգիստ չենք: Մենք ասում ենք. DevOps-ը բավականաչափ ընդգրկուն բառ չէ, այն դեռևս չունի բոլոր տեսակի տարբեր, հետաքրքիր տարրեր: Եվ մենք գնում ենք մեր գաղտնի լաբորատորիաները և սկսում ենք արտադրել հետաքրքիր մուտացիաներ՝ DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps:
Տրամաբանությունը երկաթյա է, չէ՞: Մեր առաքման համակարգը չի գործում, մեր համակարգերն անկայուն են, և մեր օգտվողները դժգոհ են, մենք ժամանակ չունենք ծրագրակազմը ժամանակին դուրս բերելու, մենք չենք տեղավորվում բյուջեի մեջ: Ինչպե՞ս ենք լուծելու այս ամենը։ Մենք նոր բառով հանդես կգանք։ Այն կավարտվի «Ops»-ով, և խնդիրը լուծված է։
Այսպիսով, ես այս մոտեցումն անվանում եմ՝ «Օփ, և խնդիրը լուծված է»:
Այս ամենը հետին պլան է մղվում, եթե մենք մեզ հիշեցնենք, թե ինչու ենք այս ամենը մտածել: Մենք ստեղծեցինք DevOps-ի այս ամբողջ բանը, որպեսզի ծրագրային ապահովման առաքումը և մեր աշխատանքը այս գործընթացում հնարավորինս անխոչընդոտ, ցավ չպատճառող, արդյունավետ և ամենակարևորը՝ հաճելի դարձնենք:
DevOps-ը մեծացավ ցավից: Եվ մենք հոգնել ենք տառապանքներից: Եվ որպեսզի այս ամենը տեղի ունենա, մենք հենվում ենք մշտադալար պրակտիկայի վրա՝ արդյունավետ համագործակցություն, հոսքային պրակտիկա և ամենակարևորը՝ համակարգային մտածողություն, քանի որ առանց դրա ոչ մի DevOps չի աշխատում:
Ի՞նչ է համակարգը:
Եվ եթե մենք արդեն խոսում ենք համակարգային մտածողության մասին, եկեք մեզ հիշեցնենք, թե ինչ է համակարգը:
Եթե դուք հեղափոխական հաքեր եք, ապա ձեզ համար համակարգը ակնհայտորեն չար է։ Դա ամպ է, որը կախված է ձեր գլխավերեւում և ստիպում է ձեզ անել այն, ինչ չեք ցանկանում անել:
Համակարգային մտածողության տեսանկյունից համակարգը մի ամբողջություն է, որը բաղկացած է մասերից։ Այս առումով մեզանից յուրաքանչյուրը համակարգ է։ Այն կազմակերպությունները, որտեղ մենք աշխատում ենք, համակարգեր են: Իսկ այն, ինչ ես ու դու կառուցում ենք, կոչվում է համակարգ։
Այս ամենը մեկ մեծ սոցիալ-տեխնոլոգիական համակարգի մի մասն է։ Եվ միայն եթե մենք հասկանանք, թե ինչպես է այս սոցիալ-տեխնոլոգիական համակարգը աշխատում միասին, միայն այդ դեպքում մենք կկարողանանք իսկապես ինչ-որ բան օպտիմալացնել այս հարցում։
Համակարգային մտածողության տեսանկյունից համակարգն ունի տարբեր հետաքրքիր հատկություններ: Նախ, այն բաղկացած է մասերից, ինչը նշանակում է, որ դրա վարքագիծը կախված է մասերի վարքագծից: Ընդ որում, նրա բոլոր մասերը նույնպես փոխկապակցված են։ Ստացվում է, որ որքան շատ մասեր ունի համակարգը, այնքան ավելի դժվար է նրա վարքագիծը հասկանալը կամ կանխատեսելը:
Վարքագծային տեսանկյունից կա ևս մեկ հետաքրքիր փաստ. Համակարգը կարող է անել մի բան, որը չի կարող անել նրա առանձին մասերից ոչ մեկը:
Ինչպես ասաց դոկտոր Ռասել Աքոֆը (համակարգային մտածողության հիմնադիրներից մեկը), սա բավականին հեշտ է ապացուցել մտքի փորձով։ Օրինակ, սենյակում ով գիտի, թե ինչպես գրել կոդը: Ձեռքերը շատ են, և դա նորմալ է, քանի որ սա մեր մասնագիտության հիմնական պահանջներից մեկն է։ Դուք գրել գիտե՞ք, բայց ձեր ձեռքերը կարո՞ղ են կոդ գրել ձեզանից առանձին: Կան մարդիկ, ովքեր կասեն. «Իմ ձեռքերը չեն, որ գրում են կոդը, այլ իմ ուղեղն է գրում կոդը»: Կարո՞ղ է ձեր ուղեղը գրել կոդը ձեզանից առանձին: Դե, հավանաբար, ոչ:
Ուղեղը զարմանալի մեքենա է, մենք նույնիսկ չգիտենք, թե ինչպես է այն աշխատում այնտեղ, 10%-ով, բայց այն չի կարող գործել մեր մարմնից առանձին: Իսկ դա հեշտ է ապացուցել՝ բացիր գանգդ, հանիր ուղեղդ, դրիր համակարգչի առաջ, թող փորձի մի պարզ բան գրել։ Օրինակ, Python-ում «Բարև աշխարհ»:
Եթե համակարգը կարող է անել մի բան, որը նրա մասերից ոչ մեկը չի կարող անել առանձին, ապա դա նշանակում է, որ նրա վարքագիծը չի որոշվում իր մասերի վարքագծով: Այդ դեպքում ինչո՞վ է այն որոշվում: Այն որոշվում է այս մասերի փոխազդեցությամբ: Եվ համապատասխանաբար, որքան շատ մասեր, որքան բարդ փոխազդեցությունները, այնքան ավելի դժվար է հասկանալ և կանխատեսել համակարգի վարքագիծը։ Իսկ դա քաոսային է դարձնում նման համակարգը, քանի որ ցանկացած, նույնիսկ ամենաաննշան, անտեսանելի փոփոխություն համակարգի ցանկացած մասում կարող է հանգեցնել բոլորովին անկանխատեսելի արդյունքների։
Նախնական պայմանների նկատմամբ այս զգայունությունն առաջին անգամ հայտնաբերել և ուսումնասիրել է ամերիկացի օդերևութաբան Էդ Լորենցը: Այնուհետև այն կոչվեց «թիթեռի էֆեկտ» և հանգեցրեց գիտական մտքի շարժման զարգացմանը, որը կոչվում էր «քաոսի տեսություն»: Այս տեսությունը դարձավ 20-րդ դարի գիտության հիմնական պարադիգմային փոփոխություններից մեկը:
Քաոսի տեսություն
Մարդիկ, ովքեր ուսումնասիրում են քաոսը, իրենց անվանում են քաոսոլոգ:
Փաստորեն, այս զեկույցի պատճառն այն էր, որ աշխատելով բարդ բաշխված համակարգերի և խոշոր միջազգային կազմակերպությունների հետ, ինչ-որ պահի ես հասկացա, որ ես հենց այդպիսին եմ զգում: Ես քաոսոլոգ եմ։ Սա հիմնականում խելացի ձև է ասելու. «Ես չեմ հասկանում, թե ինչ է կատարվում այստեղ և չգիտեմ, թե ինչ անել դրա հետ»:
Կարծում եմ, որ ձեզանից շատերը նույնպես հաճախ են այդպես զգում, ուստի դուք նույնպես քաոսոլոգ եք։ Ձեզ հրավիրում եմ քաոսոլոգների գիլդիա։ Այն համակարգերը, որոնք դուք և ես, հարգելի գործընկեր քաոսոլոգներ, կուսումնասիրենք, կոչվում են «բարդ հարմարվողական համակարգեր»:
Ի՞նչ է հարմարվողականությունը: Հարմարվողականությունը նշանակում է, որ նման հարմարվողական համակարգի մասերի անհատական և կոլեկտիվ վարքագիծը փոխվում և ինքնակազմակերպվում է՝ արձագանքելով համակարգում տեղի ունեցող իրադարձություններին կամ միկրո իրադարձությունների շղթային: Այսինքն՝ համակարգը հարմարվում է փոփոխություններին ինքնակազմակերպման միջոցով։ Եվ ինքնակազմակերպվելու այս կարողությունը հիմնված է ազատ ինքնավար գործակալների կամավոր, լիովին ապակենտրոնացված համագործակցության վրա։
Նման համակարգերի մեկ այլ հետաքրքիր հատկություն այն է, որ դրանք ազատ մասշտաբելի են: Ինչը, անկասկած, պետք է հետաքրքրի մեզ՝ որպես քաոսոլոգ-ինժեներների։ Այսպիսով, եթե ասենք, որ բարդ համակարգի վարքագիծը որոշվում է նրա մասերի փոխազդեցությամբ, ապա ի՞նչը պետք է մեզ հետաքրքրի։ Փոխազդեցություն.
Եվս երկու հետաքրքիր բացահայտում կա.
Նախ, մենք հասկանում ենք, որ բարդ համակարգը չի կարող պարզեցվել՝ պարզեցնելով դրա մասերը: Երկրորդ, բարդ համակարգը պարզեցնելու միակ միջոցը նրա մասերի միջև փոխազդեցությունների պարզեցումն է:
Ինչպե՞ս ենք մենք փոխազդում: Դուք և ես բոլորս մի մեծ տեղեկատվական համակարգի մասեր ենք, որը կոչվում է մարդկային հասարակություն: Մենք շփվում ենք ընդհանուր լեզվով, եթե ունենք, եթե գտնում ենք:
Բայց լեզուն ինքնին բարդ հարմարվողական համակարգ է: Համապատասխանաբար, ավելի արդյունավետ և պարզ փոխգործակցության համար մենք պետք է ստեղծենք ինչ-որ արձանագրություններ։ Այսինքն՝ սիմվոլների և գործողությունների ինչ-որ հաջորդականություն, որը մեր միջև տեղեկատվության փոխանակումն ավելի պարզ, կանխատեսելի, հասկանալի կդարձնի։
Ուզում եմ ասել, որ ամեն ինչում կարելի է նկատել դեպի բարդություն, դեպի հարմարվողականություն, դեպի ապակենտրոնացում, դեպի քաոս։ Եվ այն համակարգերում, որոնք ես և դու կառուցում ենք, և այն համակարգերում, որոնց մաս ենք կազմում։
Եվ որպեսզի անհիմն չլինենք, եկեք տեսնենք, թե ինչպես են փոխվում մեր ստեղծած համակարգերը:
Դու սպասում էիր այս խոսքին, հասկանում եմ։ Մենք DevOps կոնֆերանսում ենք, այսօր այս բառը կլսվի մոտ հարյուր հազար անգամ, իսկ հետո մենք երազում ենք դրա մասին գիշերը։
Microservices-ը առաջին ծրագրային ճարտարապետությունն է, որը առաջացել է որպես արձագանք DevOps-ի պրակտիկային, որը նախատեսված է մեր համակարգերը դարձնելու ավելի ճկուն, ավելի լայնածավալ և ապահովելու շարունակական առաքում: Ինչպե՞ս է նա դա անում: Նվազեցնելով ծառայությունների ծավալը, նվազեցնելով խնդիրների շրջանակը, որոնք մշակում են այդ ծառայությունները, նվազեցնելով առաքման ժամանակը: Այսինքն՝ մենք կրճատում և պարզեցնում ենք համակարգի մասերը, ավելացնում դրանց թիվը և, համապատասխանաբար, անփոփոխ մեծանում է այդ մասերի միջև փոխազդեցությունների բարդությունը, այսինքն՝ առաջանում են նոր խնդիրներ, որոնք մենք պետք է լուծենք։
Միկրոծառայությունների վերջը չէ, միկրոսերվիսները, ընդհանուր առմամբ, արդեն երեկ են, քանի որ Serverless-ը գալիս է։ Բոլոր սերվերները այրվել են, ոչ մի սերվեր, ոչ օպերացիոն համակարգեր, պարզապես մաքուր գործարկվող կոդ: Կոնֆիգուրացիաները առանձին են, պետությունները՝ առանձին, ամեն ինչ վերահսկվում է իրադարձություններով։ Գեղեցկություն, մաքրություն, լռություն, ոչ մի իրադարձություն, ոչինչ չի լինում, ամբողջական կարգուկանոն.
Որտեղ է բարդությունը: Դժվարությունը, իհարկե, փոխազդեցությունների մեջ է։ Որքա՞ն կարող է մի գործառույթ ինքնուրույն կատարել: Ինչպե՞ս է այն փոխազդում այլ գործառույթների հետ: Հաղորդագրությունների հերթեր, տվյալների բազաներ, հավասարակշռողներ: Ինչպե՞ս վերստեղծել որևէ իրադարձություն, երբ տեղի է ունեցել ձախողում: Շատ հարցեր և քիչ պատասխաններ:
Microservices-ը և Serverless-ն այն են, ինչ մենք հիփսթերները անվանում ենք Cloud Native: Ամեն ինչ ամպի մասին է: Բայց ամպը նաև էապես սահմանափակ է իր մասշտաբայնությամբ: Մենք սովոր ենք այն դիտարկել որպես բաշխված համակարգ։ Փաստորեն, որտեղ են ապրում ամպային մատակարարների սերվերները: Տվյալների կենտրոններում. Այսինքն՝ մենք այստեղ ունենք մի տեսակ կենտրոնացված, շատ սահմանափակ, բաշխված մոդել։
Այսօր մենք հասկանում ենք, որ իրերի ինտերնետն այլևս պարզապես մեծ բառեր չեն, որ նույնիսկ համեստ կանխատեսումների համաձայն՝ հաջորդ հինգ-տասը տարիների ընթացքում մեզ սպասում են ինտերնետին միացված միլիարդավոր սարքեր: Հսկայական քանակությամբ օգտակար և անօգուտ տվյալներ, որոնք կմիավորվեն ամպի մեջ և կվերբեռնվեն ամպից:
Ամպը չի տևի, ուստի մենք ավելի ու ավելի ենք խոսում մի բանի մասին, որը կոչվում է եզրային հաշվարկ: Կամ ինձ դուր է գալիս նաև «մառախուղային հաշվարկի» հրաշալի սահմանումը։ Այն պարուրված է ռոմանտիզմի ու առեղծվածային միստիկայի մեջ։
Մառախուղի հաշվարկ. Բանն այն է, որ ամպերը ջրի, գոլորշու, սառույցի և քարերի կենտրոնացված կուտակումներ են։ Իսկ մառախուղը ջրի կաթիլներ են, որոնք մթնոլորտում ցրված են մեր շուրջը։
Մառախուղի պարադիգմում աշխատանքի մեծ մասը կատարվում է այս կաթիլների կողմից ամբողջովին ինքնուրույն կամ այլ կաթիլների հետ համագործակցությամբ: Եվ նրանք դիմում են ամպին միայն այն ժամանակ, երբ իսկապես ճնշում են:
Այսինքն՝ կրկին ապակենտրոնացում, ինքնավարություն և, իհարկե, ձեզնից շատերն արդեն հասկանում են, թե ուր է գնում այս ամենը, քանի որ դուք չեք կարող խոսել ապակենտրոնացման մասին՝ առանց նշելու բլոկչեյնը։
Կան նրանք, ովքեր հավատում են, սրանք նրանք են, ովքեր ներդրումներ են կատարել կրիպտոարժույթում: Կան, որ հավատում են, բայց վախենում են, օրինակ ինձ նման։ Եվ կան նրանք, ովքեր չեն հավատում. Այստեղ դուք կարող եք այլ կերպ վարվել: Տեխնոլոգիա կա, նոր անհայտ նյութ, խնդիրներ կան։ Ինչպես ցանկացած նոր տեխնոլոգիա, այն ավելի շատ հարցեր է առաջացնում, քան պատասխաններ:
Բլոկչեյնի շուրջ աղմուկը հասկանալի է: Մի կողմ թողնենք ոսկու տենդը, տեխնոլոգիան ինքնին ուշագրավ խոստումներ է տալիս ավելի պայծառ ապագայի համար՝ ավելի շատ ազատություն, ավելի ինքնավարություն, բաշխված գլոբալ վստահություն: Ինչ չի ուզում:
Համապատասխանաբար, ավելի ու ավելի շատ ինժեներներ ամբողջ աշխարհում սկսում են մշակել ապակենտրոնացված հավելվածներ: Եվ սա այն ուժն է, որը չի կարելի անտեսել՝ պարզապես ասելով. «Ահ, բլոկչեյնը պարզապես վատ իրականացված բաշխված տվյալների բազա է»: Կամ, ինչպես հոռետեսները սիրում են ասել. «Բլոկչեյնի համար իրական հավելվածներ չկան»: Եթե լավ մտածեք, 150 տարի առաջ նույն բանն էին ասում էլեկտրաէներգիայի մասին։ Եվ նրանք նույնիսկ որոշ առումներով իրավացի էին, քանի որ այն, ինչ այսօր հնարավոր է դարձնում էլեկտրականությունը, ոչ մի կերպ հնարավոր չէր 19-րդ դարում:
Ի դեպ, ո՞վ գիտի, թե ինչ լոգո է էկրանին։ Սա Hyperledger-ն է: Սա նախագիծ է, որը մշակվում է The Linux Foundation-ի հովանու ներքո և ներառում է բլոկչեյն տեխնոլոգիաների մի շարք: Սա իսկապես մեր բաց կոդով համայնքի ուժն է:
Քաոսի ճարտարագիտություն
Այսպիսով, համակարգը, որը մենք զարգացնում ենք, դառնում է ավելի ու ավելի բարդ, ավելի ու ավելի քաոսային և ավելի ու ավելի հարմարվողական: Netflix-ը միկրոսպասարկման համակարգերի առաջամարտիկներն են: Նրանք առաջիններից էին, որ հասկացան դա, նրանք մշակեցին մի շարք գործիքներ, որոնք նրանք անվանեցին Սիմյան բանակ, որոնցից ամենահայտնին. . Նա սահմանեց այն, ինչ հայտնի դարձավ որպես .
Ի դեպ, զեկույցի վրա աշխատելու ընթացքում մենք նույնիսկ այս տեքստը թարգմանեցինք ռուսերեն, այնպես որ գնացեք , կարդալ, մեկնաբանել, նախատել.
Հակիրճ, քաոսային ինժեներիայի սկզբունքներն ասում են հետևյալը. Բարդ բաշխված համակարգերն իրենց էությամբ անկանխատեսելի են և իրենց էությամբ խելագարված: Սխալներն անխուսափելի են, ինչը նշանակում է, որ մենք պետք է ընդունենք այդ սխալները և բոլորովին այլ կերպ աշխատենք այս համակարգերի հետ:
Մենք ինքներս պետք է փորձենք ներմուծել այդ սխալները մեր արտադրական համակարգերում, որպեսզի փորձարկենք մեր համակարգերը նույն հարմարվողականության, ինքնակազմակերպման, գոյատևման այս կարողության համար:
Եվ դա փոխում է ամեն ինչ: Ոչ միայն այն, թե ինչպես ենք մենք համակարգերը թողարկում արտադրության մեջ, այլև ինչպես ենք դրանք զարգացնում, ինչպես ենք փորձարկում դրանք: Օրենսգրքի կայունացման կամ սառեցման գործընթաց չկա, ընդհակառակը, կա անընդհատ ապակայունացման գործընթաց։ Մենք փորձում ենք սպանել համակարգը և տեսնել, որ այն շարունակում է գոյատևել:
Բաշխված համակարգի ինտեգրման արձանագրություններ
Համապատասխանաբար, սա պահանջում է, որ մեր համակարգերը ինչ-որ կերպ փոխվեն: Որպեսզի նրանք դառնան ավելի կայուն, նրանց անհրաժեշտ են որոշ նոր արձանագրություններ իրենց մասերի միջև փոխգործակցության համար: Որպեսզի այս մասերը պայմանավորվեն ու գան ինչ-որ ինքնակազմակերպման։ Եվ առաջանում են բոլոր տեսակի նոր գործիքներ, նոր արձանագրություններ, որոնք ես անվանում եմ «արձանագրություններ բաշխված համակարգերի փոխազդեցության համար»:
Ինչի՞ մասին եմ խոսում։ Նախ՝ նախագիծը . Ոմանք փորձում են ստեղծել ընդհանուր բաշխված հետևելու արձանագրություն, որը բացարձակապես անփոխարինելի գործիք է բարդ բաշխված համակարգերի վրիպազերծման համար:
Հետագա - . Մենք ասում ենք, որ չենք կարող կանխատեսել, թե ինչ կլինի համակարգի հետ, այսինքն՝ պետք է մեծացնել նրա դիտարկելիությունը, դիտելիությունը։ Opentracing-ը պատկանում է գործիքների ընտանիքին, որոնք դիտելիություն են տալիս մեր համակարգերին: Բայց մեզ անհրաժեշտ է դիտարկելիություն, որպեսզի որոշենք, թե արդյոք համակարգը վարվում է այնպես, ինչպես մենք ակնկալում ենք, թե ոչ: Ինչպե՞ս ենք մենք սահմանում ակնկալվող վարքագիծը: Սահմանելով ինչ-որ քաղաքականություն, ինչ-որ կանոններ։ «Open Policy Agent» նախագիծն աշխատում է կանոնների այս փաթեթը սահմանելու ուղղությամբ՝ սկսած հասանելիությունից մինչև ռեսուրսների բաշխում:
Ինչպես ասացինք, մեր համակարգերն ավելի ու ավելի են առաջնորդվում իրադարձություններով: Serverless-ը իրադարձությունների վրա հիմնված համակարգերի հիանալի օրինակ է: Որպեսզի մենք փոխանցենք իրադարձությունները համակարգերի միջև և հետևենք դրանց, մեզ անհրաժեշտ է ընդհանուր լեզու, ընդհանուր արձանագրություն, թե ինչպես ենք մենք խոսում իրադարձությունների մասին, ինչպես ենք դրանք փոխանցում միմյանց: Այսպես էր կոչվում մի նախագիծ .
Փոփոխությունների մշտական հոսքը, որը ողողում է մեր համակարգերը՝ անընդհատ ապակայունացնելով դրանք, ծրագրային արտեֆակտների շարունակական հոսք է: Որպեսզի մենք պահպանենք փոփոխությունների այս մշտական հոսքը, մեզ անհրաժեշտ է ինչ-որ ընդհանուր արձանագրություն, որի միջոցով մենք կարող ենք խոսել այն մասին, թե ինչ է ծրագրային արտեֆակտը, ինչպես է այն փորձարկվում, ինչ ստուգում է այն անցել: Այսպես էր կոչվում մի նախագիծ . Այսինքն՝ ընդհանուր մետատվյալների արձանագրություն ծրագրային ապահովման արտեֆակտների համար։
Եվ վերջապես, եթե մենք ցանկանում ենք, որ մեր համակարգերը լինեն լիովին անկախ, հարմարվողական և ինքնակազմակերպված, մենք պետք է նրանց ինքնորոշման իրավունք տանք: Նախագիծը կոչված է Սա հենց այն է, ինչ նա անում է: Սա նաև նախագիծ է Cloud Native Computing հիմնադրամի հովանու ներքո:
Այս բոլոր նախագծերը երիտասարդ են, բոլորն էլ մեր սիրո, մեր վավերացման կարիքն ունեն: Այս ամենը բաց կոդով է, մեր փորձարկումը, մեր իրականացումը: Նրանք մեզ ցույց են տալիս, թե ուր է գնում տեխնոլոգիան:
Բայց DevOps-ը երբեք չի եղել հիմնականում տեխնոլոգիայի մասին, այն միշտ եղել է մարդկանց միջև համագործակցության մասին: Եվ, համապատասխանաբար, եթե մենք ուզում ենք, որ մեր մշակած համակարգերը փոխվեն, ապա մենք ինքներս պետք է փոխվենք։ Փաստորեն, մենք ամեն դեպքում փոխվում ենք, մենք մեծ ընտրություն չունենք։
Կա մի հրաշալի Բրիտանացի գրող Ռեյչել Բոտսմանը, որտեղ նա գրում է մարդկության պատմության ընթացքում վստահության էվոլյուցիայի մասին: Նա ասում է, որ ի սկզբանե պարզունակ հասարակություններում վստահությունը եղել է տեղական, այսինքն՝ վստահել ենք միայն նրանց, ում անձամբ ճանաչում ենք։
Հետո եղավ շատ երկար ժամանակ՝ մութ ժամանակ, երբ վստահությունը կենտրոնացված էր, երբ մենք սկսեցինք վստահել մարդկանց, որոնց չենք ճանաչում՝ հիմք ընդունելով նույն հասարակական կամ պետական ինստիտուտին պատկանելը։
Եվ սա այն է, ինչ մենք տեսնում ենք մեր ժամանակակից աշխարհում. վստահությունը դառնում է ավելի ու ավելի բաշխված և ապակենտրոնացված, և այն հիմնված է տեղեկատվական հոսքերի ազատության, տեղեկատվության մատչելիության վրա:
Եթե մտածեք դրա մասին, ապա հենց այս հասանելիությունը, որը հնարավոր է դարձնում այս վստահությունը, այն է, ինչ դուք և ես իրականացնում ենք: Սա նշանակում է, որ և՛ մեր համագործակցության ձևը, և՛ դա պետք է փոխվի, քանի որ կենտրոնացված, հիերարխիկ ՏՏ կազմակերպությունները նախկինում այլևս չեն աշխատում: Նրանք սկսում են մահանալ:
DevOps կազմակերպության հիմունքները
Ապագայի DevOps-ի իդեալական կազմակերպությունը ապակենտրոնացված, հարմարվողական համակարգ է, որը բաղկացած է ինքնավար թիմերից, որոնցից յուրաքանչյուրը բաղկացած է ինքնավար անհատներից: Այս թիմերը ցրված են աշխարհով մեկ՝ արդյունավետ համագործակցելով միմյանց հետ՝ օգտագործելով ասինխրոն հաղորդակցություն՝ օգտագործելով բարձր թափանցիկ հաղորդակցման արձանագրություններ: Շատ գեղեցիկ է, այնպես չէ՞: Շատ գեղեցիկ ապագա։
Իհարկե, առանց մշակութային փոփոխության, այս ամենից ոչ մեկը հնարավոր չէ: Մենք պետք է ունենանք տրանսֆորմացիոն առաջնորդություն, անձնական պատասխանատվություն, ներքին մոտիվացիա։
Սա DevOps կազմակերպությունների հիմքն է՝ տեղեկատվական թափանցիկություն, ասինխրոն հաղորդակցություն, տրանսֆորմացիոն առաջնորդություն, ապակենտրոնացում։
Այրվածքներ
Համակարգերը, որոնց մաս ենք կազմում, և այն համակարգերը, որոնք մենք կառուցում ենք, գնալով ավելի են քաոսային, և մեզ՝ մարդկանց համար, դժվար է հաղթահարել այս միտքը, դժվար է հրաժարվել վերահսկողության պատրանքից: Մենք փորձում ենք շարունակել վերահսկել դրանք, և դա հաճախ հանգեցնում է այրման: Սա իմ սեփական փորձից եմ ասում, ես էլ եմ այրվել, արտադրության մեջ չնախատեսված խափանումներից էլ հաշմանդամ եմ եղել։
Այրվածությունը տեղի է ունենում, երբ մենք փորձում ենք վերահսկել մի բան, որն ի սկզբանե անվերահսկելի է: Երբ այրվում ենք, ամեն ինչ կորցնում է իր իմաստը, քանի որ կորցնում ենք նոր բան անելու ցանկությունը, դառնում ենք պաշտպանողական և սկսում պաշտպանել այն, ինչ ունենք։
Ինժեներ մասնագիտությունը, ինչպես հաճախ եմ սիրում հիշեցնել ինքս ինձ, առաջին հերթին ստեղծագործական մասնագիտություն է։ Եթե կորցնում ենք ինչ-որ բան ստեղծելու ցանկությունը, ուրեմն մոխիր ենք դառնում, մոխիր ենք դառնում։ Մարդիկ այրվում են, ամբողջ կազմակերպություններ են այրվում։
Իմ կարծիքով, միայն քաոսի ստեղծագործական ուժն ընդունելը, միայն դրա սկզբունքներով համագործակցություն կառուցելն է, որ կօգնի մեզ չկորցնել այն, ինչ լավն է մեր մասնագիտության մեջ։
Սա այն է, ինչ ես ցանկանում եմ ձեզ՝ սիրել ձեր աշխատանքը, սիրել այն, ինչ անում ենք: Այս աշխարհը սնվում է տեղեկատվությամբ, մենք պատիվ ունենք այն կերակրելու։ Ուրեմն եկեք ուսումնասիրենք քաոսը, լինենք քաոսոլոգներ, արժեք բերենք, նոր բան ստեղծենք, դե, խնդիրներն, ինչպես արդեն պարզել ենք, անխուսափելի են, և երբ հայտնվեն, ուղղակի կասենք «օփս», և խնդիրը լուծված է։
Քաոս կապիկից բացի ուրիշ ի՞նչ:
Իրականում այս բոլոր գործիքներն այնքան երիտասարդ են։ Նույն Netflix-ը գործիքներ է ստեղծել իրենց համար: Կառուցեք ձեր սեփական գործիքները: Կարդացեք քաոսային ինժեներիայի սկզբունքները և ապրեք այդ սկզբունքներին համապատասխան, այլ ոչ թե փորձեք գտնել այլ գործիքներ, որոնք մեկ ուրիշն արդեն ստեղծել է:
Փորձեք հասկանալ, թե ինչպես են ձեր համակարգերը քայքայվում և սկսեք կոտրել դրանք և տեսեք, թե ինչպես են դրանք դիմանում: Սա առաջինն է: Եվ դուք կարող եք գործիքներ փնտրել: Կան բոլոր տեսակի նախագծեր։
Ես այնքան էլ չհասկացա այն պահը, երբ դու ասացիր, որ համակարգը չի կարելի պարզեցնել իր բաղադրիչները պարզեցնելով, և անմիջապես անցա միկրոսերվիսներին, որոնք պարզեցնում են համակարգը՝ պարզեցնելով իրենց բաղադրիչները և բարդացնելով փոխազդեցությունները: Սրանք ըստ էության երկու մասեր են, որոնք հակասում են միմյանց։
Ճիշտ է, միկրոսերվիսներն ընդհանրապես շատ վիճելի թեմա են։ Փաստորեն, մասերի պարզեցումը մեծացնում է ճկունությունը: Ի՞նչ են տրամադրում միկրոծառայությունները: Նրանք մեզ տալիս են ճկունություն և արագություն, բայց նրանք, իհարկե, մեզ պարզություն չեն տալիս: Նրանք մեծացնում են դժվարությունը:
Այսպիսով, DevOps-ի փիլիսոփայության մեջ միկրոծառայություններն այդքան էլ լավ բան չեն:
Ցանկացած բարիք ունի հակառակ կողմ: Առավելությունն այն է, որ այն մեծացնում է ճկունությունը՝ թույլ տալով մեզ ավելի արագ փոփոխություններ կատարել, բայց մեծացնում է ամբողջ համակարգի բարդությունը և, հետևաբար, փխրունությունը:
Այնուամենայնիվ, ի՞նչն է ավելի շատ շեշտադրում՝ փոխազդեցության պարզեցման, թե՞ մասերի պարզեցման վրա:
Շեշտը, իհարկե, դրված է փոխազդեցությունների պարզեցման վրա, քանի որ եթե դրան նայենք այն տեսանկյունից, թե ինչպես ենք մենք աշխատում ձեզ հետ, ապա առաջին հերթին պետք է ուշադրություն դարձնել փոխազդեցությունների պարզեցմանը, այլ ոչ թե աշխատանքը պարզեցնելուն։ մեզանից յուրաքանչյուրը առանձին-առանձին: Որովհետև աշխատանքը պարզեցնելը նշանակում է վերածվել ռոբոտների։ Այստեղ McDonald's-ում այն նորմալ է աշխատում, երբ հրահանգներ ունես՝ այստեղ դնում ես բուրգերը, այստեղ սոուսը լցնում ես վրան։ Սա բացարձակապես չի աշխատում մեր ստեղծագործական աշխատանքում:
Ճի՞շտ է, որ ձեր ասած ամեն ինչ ապրում է առանց մրցակցության աշխարհում, և այնտեղ քաոսն այնքան բարի է, և այս քաոսի մեջ հակասություններ չկան, ոչ ոք չի ուզում որևէ մեկին ուտել կամ սպանել: Ինչպե՞ս պետք է գնան մրցակցությունը և DevOps-ը:
Դե, դա կախված է նրանից, թե ինչ մրցակցության մասին է խոսքը։ Խոսքը աշխատավայրում մրցակցության, թե՞ ընկերությունների միջև մրցակցության մասին է:
Ծառայությունների մրցակցության մասին, որոնք գոյություն ունեն, քանի որ ծառայությունները մի քանի ընկերություններ չեն։ Մենք ստեղծում ենք նոր տիպի տեղեկատվական միջավայր, և ցանկացած միջավայր չի կարող ապրել առանց մրցակցության։ Ամենուր մրցակցություն է.
Նույն Netflix-ը, մենք նրանց օրինակ ենք վերցնում: Ինչու՞ նրանք եկան սա: Քանի որ նրանք պետք է մրցունակ լինեին: Շարժման այս ճկունությունն ու արագությունը հենց մրցակցային պահանջն են, այն քաոս է մտցնում մեր համակարգերում: Այսինքն՝ քաոսը մի բան չէ, որ մենք գիտակցաբար անում ենք, քանի որ ցանկանում ենք, դա մի բան է, որը տեղի է ունենում, քանի որ աշխարհն է դա պահանջում: Մենք պարզապես պետք է հարմարվենք: Իսկ քաոսը՝ դա հենց մրցակցության արդյունք է։
Արդյո՞ք սա նշանակում է, որ քաոսը, այսպես ասած, նպատակների բացակայությունն է: Կամ այն նպատակները, որոնք մենք չենք ուզում տեսնել: Մենք տանն ենք և չենք հասկանում ուրիշների նպատակները։ Մրցակցությունը, ըստ էության, պայմանավորված է նրանով, որ մենք ունենք հստակ նպատակներ և գիտենք, թե որտեղ ենք հայտնվելու յուրաքանչյուր հաջորդ պահին: Սա, իմ տեսանկյունից, DevOps-ի էությունն է:
Նաև նայեք հարցին. Կարծում եմ՝ մենք բոլորս ունենք նույն նպատակը՝ գոյատևել և անել դա
մեծագույն հաճույք. Իսկ ցանկացած կազմակերպության մրցակցային նպատակը նույնն է. Գոյատևումը հաճախ տեղի է ունենում մրցակցության միջոցով, դրա դեմ ոչինչ չես կարող անել:
Այս տարվա համաժողովը դեկտեմբերի 7-ին Տեխնոպոլիսում։ Հաշվետվությունների հայտերն ընդունում ենք մինչև նոյեմբերի 11-ը։ մեզ, եթե ցանկանում եք խոսել:
Մասնակիցների գրանցումը բաց է, տոմսերի արժեքը 7000 ռուբլի է: Միացեք մեզ!
Source: www.habr.com