Жақында мұндай жарнамалар ғаламторды шарпыды. Жағымды жалақыға қарамастан, ішінде жабайы бидғат жазылғанына ыңғайсыздану мүмкін емес. Алдымен «DevOps» және «инженерді» бір сөзге біріктіруге болады деп болжанады, содан кейін талаптардың кездейсоқ тізімі бар, олардың кейбіреулері жүйе әкімшісінің бос орнынан анық көшіріледі.
Бұл постта мен өмірдің осы нүктесіне қалай жеткеніміз, DevOps деген не және онымен қазір не істеу керектігі туралы аздап сөйлескім келеді.
Мұндай бос орындарды барлық мүмкін түрде айыптауға болады, бірақ факт сақталады: олардың көпшілігі бар және қазіргі уақытта нарық осылай жұмыс істейді. Біз devops конференциясын өткіздік және ашық түрде мәлімдейміз: « - DevOps инженерлері үшін емес. Бұл көпшілікке оғаш және жабайы болып көрінеді: неге толығымен коммерциялық іс-шара жасап жатқан адамдар нарыққа қарсы шығады. Енді бәрін түсіндіреміз.
Мәдениет және процестер туралы
DevOps инженерлік пән емес екендігінен бастайық. Мұның бәрі тарихи қалыптасқан рөлдер бөлінісі өнімнің сапасы үшін жұмыс істемейтінінен басталды. Бағдарламашылар тек бағдарламалағанда, бірақ тестілеу туралы ештеңе естігісі келмесе, бағдарламалық құрал қателерге толы. Әкімшілер бағдарламалық жасақтаманың қалай және не үшін жазылғанына мән бермесе, қолдау тозаққа айналады.
Мысалы, жүйелік әкімші мен қызметті басқарудың SRE тәсілі арасындағы айырмашылықты сипаттау . ішінде қызықты зерттеулер жүргізілді — үздік әзірлеушілер қандай да бір жолмен өндіріске жаңа өзгерістерді сағатына бір реттен жылдамырақ енгізе алатыны анық. Олар қолдарымен 10% аспайды (мұны мына жерден көруге болады ). Олар мұны қалай жасайды? Есеп тақырыптарының бірінде «Excel немесе өл» деп жазылған. Тестілеу контекстінде осы статистиканы егжей-тегжейлі талқылау үшін Барух Садогурскийдің негізгі баяндамасына жүгінуге болады. басқа конференциямызда, Heisenbug.
«Жолдастар арасында келісім болмаса,
Олардың жағдайы жақсы болмайды,
Ал одан ештеңе шықпайды, тек азап.
Баяғыда аққу, шаян, шортан...».
Сіздің ойыңызша, веб-бағдарламашылардың қай бөлігі олардың қосымшалары өндірісте қолданылатын шарттарды шынымен түсінеді? Олардың қаншасы әкімшілерге барып, деректер базасы бұзылса не болатынын анықтауға тырысады? Ал олардың қайсысы тестілеушілерге барып, тесттерді дұрыс жазуды үйретеді? Сондай-ақ күзетшілер, өнім менеджерлері және басқа да адамдар бар.
DevOps-тың жалпы идеясы - рөлдер мен бөлімдер арасында ынтымақтастықты құру. Ең алдымен, бұған ақылды түрде конфигурацияланған бағдарламалық қамтамасыз ету емес, қарым-қатынас тәжірибесі арқылы қол жеткізіледі. DevOps мәдениет, тәжірибе, әдістеме және процестер туралы. Бұл сұрақтарға жауап беретін инженерлік мамандық жоқ.
Тұйықталған шеңбер
«Devops Engineering» пәні сол кезде қайдан пайда болды? Бізде нұсқа бар! DevOps идеяларының жақсы болғаны сонша, олар өз табыстарының құрбаны болды. Жеке атмосферасы бар кейбір көлеңкелі жалдаушылар мен адам саудагерлері осы тақырыптың айналасында айнала бастады.
Елестетіп көріңізші: кеше сіз Химкиде шаурма жасап жатсаңыз, бүгін сіз үлкен адамсыз, аға рекрутерсіз. Үміткерлерді іздеу мен таңдаудың бүкіл процесі бар, бәрі оңай емес, түсіну керек. Бөлім меңгерушісі былай дейді делік: X бойынша маманды табыңыз. Біз «инженер» сөзін X-ке тағайындаймыз және біз аяқтадық. Linux керек пе? Бұл сөзсіз Linux инженері, егер сіз DevOps қаласаңыз, онда DevOps инженері. Бос орын тек тақырыптан ғана емес, сонымен қатар ішіне кейбір мәтінді енгізу керек. Ең оңай жолы - сіздің қиялыңызға байланысты Google-дан кілт сөздер жинағын енгізу. DevOps екі сөзден тұрады - «Dev» және «Ops», яғни әзірлеушілер мен әкімшілерге қатысты кілт сөздерді бір қадаға біріктіру керек. 42 бағдарламалау тілін меңгеру және Kubernetes және Swarm бір мезгілде 20 жыл бойына жұмыс істеу бойынша бос орындар осылай пайда болады. Жұмыс диаграммасы.
Осылайша, белгілі бір «девоп» суперқаһарманының мағынасыз және мейірімсіз бейнесі адамдардың санасында орын алды, ол барлығын Дженкинске орналастыруға конфигурациялайды және бақыт келеді. Әй, бәрі қарапайым болса ғой. «Осылайша сіз жүйелік әкімшілерді іздей аласыз», - деп ойлайды HR, «бұл сәнді сөз, кілт сөздер бірдей, олар жемді алуы керек».
Сұраныс ұсынысты тудырады және осы қоқыс бос орындарының барлығы жүйе әкімшілерінің ақылсыз санымен толтырылды, олар түсінді: сіз бәрін бұрынғыдай жасай аласыз, бірақ өзіңізді «девоп» деп атау арқылы бірнеше есе көп аласыз. SSH арқылы серверлерді бір-бірден қолмен конфигурациялағаныңыздай, оларды конфигурациялауды жалғастырасыз, бірақ қазір бұл devops тәжірибесі болып табылады. Бұл классикалық әкімшілерді бағаламаумен және DevOps айналасындағы хайппен байланысты күрделі құбылыстың бір түрі, бірақ жалпы алғанда, болған оқиға болды.
Сондықтан бізде сұраныс пен ұсыныс бар. Өзін-өзі қоректендіретін тұйық шеңбер. Біз осымен күресіп жатырмыз (соның ішінде DevOops конференциясын құру арқылы).
Әрине, өздерін «девоптар» деп өзгерткен жүйелік әкімшілерден басқа, басқа қатысушылар бар, мысалы, кәсіби SRE немесе Infrastructure-as-Code әзірлеушілері.
Адамдар DevOps-та не істейді (шынымен)
Сондықтан сіз DevOps тәжірибесін үйренуде және қолдануда алға ұмтылғыңыз келеді. Бірақ мұны қалай істеу керек, қай бағытта қарау керек? Танымал кілт сөздерге сенбеу керек екені анық.
Жұмыс бар болса, оны біреу істеу керек. Біз бұл «девопс инженерлері» емес екенін білдік, сонда кімдер? Мұны лауазымдар бойынша емес, нақты жұмыс бағыттары бойынша тұжырымдаған дұрысырақ сияқты.
Біріншіден, сіз DevOps-тің жүрегіне — процестер мен мәдениетке жүгіне аласыз. Мәдениет - бұл баяу және қиын бизнес, және дәстүрлі түрде менеджерлердің жауапкершілігі болса да, бағдарламашылардан бастап әкімшілерге дейін бәрі бір немесе басқа жолмен айналысады. Бірнеше ай бұрын Тим Листер :
«Мәдениет ұйымның негізгі құндылықтарымен анықталады. Әдетте адамдар мұны байқамайды, бірақ көп жылдар бойы кеңес беруде жұмыс істегендіктен, біз оны байқап қалғанбыз. Сіз компанияға кіресіз және бірнеше минут ішінде сіз не болып жатқанын сезіне бастайсыз. Біз мұны «дәм» деп атаймыз. Кейде бұл хош иіс шынымен жақсы. Кейде бұл жүрек айнуын тудырады. (...) Белгілі бір әрекеттердің артындағы құндылықтар мен сенімдер түсінілмейінше, сіз мәдениетті өзгерте алмайсыз. Мінез-құлықты байқау оңай, бірақ сенімдерді іздеу қиын. DevOps - бұл заттардың барған сайын күрделене түсуінің тамаша мысалы».
Әрине, мәселенің техникалық жағы да бар. Егер сіздің жаңа кодыңыз бір айда тексерілсе, бірақ бір жылдан кейін ғана шығарылса және оның барлығын жеделдету физикалық тұрғыдан мүмкін болмаса, сіз жақсы тәжірибелерді орындамауыңыз мүмкін. Жақсы тәжірибе жақсы құралдармен қамтамасыз етіледі. Мысалы, Infrastructure-as-Code идеясын ескере отырып, сіз AWS CloudFormation және Terraform-тан бастап Chef-Ansible-Puppet-ке дейін кез келген нәрсені пайдалана аласыз. Сіз мұның бәрін білуіңіз және жасай білуіңіз керек, бұл қазірдің өзінде инженерлік пән. Себеп пен нәтижені шатастырмау маңызды: алдымен сіз SRE принциптері бойынша жұмыс жасайсыз, содан кейін ғана бұл принциптерді кейбір нақты техникалық шешімдер түрінде жүзеге асырасыз. Сонымен қатар, SRE - бұл Дженкинсті қалай орнату керектігін айтпайтын, бірақ бес негізгі қағидат туралы айтатын өте жан-жақты әдістеме:
- Рөлдер мен бөлімдер арасындағы байланыс жақсарды
- Қателерді жұмыстың ажырамас бөлігі ретінде қабылдау
- Біртіндеп өзгертулер енгізу
- Аспаптарды және басқа автоматтандыруды қолдану
- Өлшеуге болатынның бәрін өлшеу
Бұл тек кейбір мәлімдемелер жиынтығы емес, нақты . Мысалы, қателерді қабылдау жолында тәуекелдерді түсіну, SLI ( сияқты нәрсені пайдаланып қызметтердің қолжетімділігі мен қолжетімсіздігін өлшеу қажет болады.) және SLO (), өлгеннен кейінгі жазуды үйреніңіз және оларды жазуды қорқынышсыз етіңіз.
SRE пәнінде құралдарды пайдалану маңызды болса да, сәттіліктің бір бөлігі ғана. Бізге үнемі техникалық даму керек, әлемде не болып жатқанын және оны біздің жұмысымызда қалай қолдануға болатынын қарастыру керек.
Өз кезегінде, Cloud Native шешімдері қазір өте танымал болды. Бүгінгі күні Cloud Native Computing Foundation анықтағандай, Cloud Native технологиялары ұйымдарға қоғамдық, жеке және гибридті бұлттар сияқты бүгінгі динамикалық орталарда масштабталатын қолданбаларды әзірлеуге және іске қосуға мүмкіндік береді. Мысалдар контейнерлерді, қызмет көрсету торларын, микросервистерді, өзгермейтін инфрақұрылымды және декларативті API интерфейстерін қамтиды. Осы әдістердің барлығы еркін байланысқан жүйелердің серпімді, басқарылатын және жоғары бақылауға қабілетті болып қалуына мүмкіндік береді. Жақсы автоматтандыру инженерлерге жиі және болжамды нәтижелермен үлкен өзгерістер жасауға мүмкіндік береді. Мұның барлығына Docker және Kubernetes сияқты белгілі құралдар жинағы қолдау көрсетеді.
Бұл өте күрделі және кең анықтама ауданның да күрделі болуына байланысты. Бір жағынан, бұл жүйеге жаңа өзгерістерді оңай қосу керек деген пікір бар. Екінші жағынан, бағдарламалық қамтамасыз етумен анықталған инфрақұрылымда еркін байланысқан қызметтер өмір сүретін және үздіксіз CI/CD көмегімен жеткізілетін контейнерлік ортаның түрін қалай құру керектігін анықтау және осының бәріне қатысты DevOps тәжірибелерін құру - мұның бәрі көбірек қажет етеді. Біреу итті жегеннен гөрі.
Мұның бәрін не істеу керек
Бұл мәселелерді әркім өзінше шешеді: мысалы, тұйық шеңберді бұзу үшін қалыпты бос орындарды жариялауға болады. Сіз DevOps және Cloud Native сияқты сөздердің нені білдіретінін анықтап, оларды дұрыс және орынды пайдалана аласыз. Сіз DevOps жүйесінде дамып, мысал арқылы дұрыс тәсілдерді көрсете аласыз.
Біз конференция өткізіп жатырмыз , бұл біз айтқан нәрселерге тереңірек енуге мүмкіндік береді. Бұл үшін есептердің бірнеше топтары бар:
- Процестер мен мәдениет;
- Сайттың сенімділігі инженериясы;
- Cloud Native;
Баратын жерді қалай таңдауға болады? Бұл жерде бір нәзік тұс бар. Бір жағынан, DevOps өзара әрекеттесу туралы және біз әртүрлі блоктардан презентацияларға қатысуыңызды қалаймыз. Екінші жағынан, егер сіз конференцияға бір нақты тапсырмаға шоғырлану үшін келген даму менеджері болсаңыз, онда сізді ешкім шектемейді - бұл процестер мен мәдениетке блок болатыны анық. Конференциядан кейін (кері байланыс формасын толтырғаннан кейін) жазбалар болатынын ұмытпаңыз, осылайша сіз әрқашан маңызды емес презентацияларды кейінірек көре аласыз.
Әлбетте, конференцияның өзінде сіз бірден үш жолға бара алмайсыз, сондықтан біз бағдарламаны әр уақыт слоты кез келген талғамға арналған тақырыптар болатындай етіп ұйымдастырамыз.
Егер сіз DevOps инженері болсаңыз, не істеу керектігін түсіну ғана қалады! Алдымен, шын мәнінде не істеп жатқаныңызды анықтауға тырысыңыз. Әдетте олар бұл сөзді атағанды ұнатады:
- Инфрақұрылымда жұмыс істейтін әзірлеушілер. SRE және Cloud Native туралы есептер топтары сізге ең қолайлы.
- Жүйе әкімшілері. Бұл жерде қиынырақ. DevOops жүйені басқаруға қатысты емес. Бақытымызға орай, жүйені басқару тақырыбында көптеген тамаша конференциялар, кітаптар, мақалалар, Интернетте бейнелер және т.б. Екінші жағынан, егер сіз мәдениет пен процестерді түсіну, бұлттық технологиялар туралы және Cloud Native көмегімен өмірдің егжей-тегжейлері туралы білім алу тұрғысынан өзіңізді дамытқыңыз келсе, біз сізді көргіміз келеді! Мынаны ойлап көріңіз: сіз әкімшілікпен айналысып жатырсыз, содан кейін не істейсіз? Кенеттен жағымсыз жағдайға тап болмас үшін қазір үйрену керек.
Тағы бір нұсқа бар: сіз табандысыз және өзіңізді солай деп мәлімдей бересіз әсіресе DevOps инженері және басқа ештеңе, бұл нені білдіреді. Сонда біз сізді ренжітуіміз керек, DevOops DevOps инженерлеріне арналған конференция емес!
Сырғыту Мюнхенде
DevOops 2020 Мәскеу 29-30 сәуірде Мәскеуде өтеді, билеттер қазірдің өзінде қол жетімді .
Немесе сіз аласыз 8 ақпанға дейін. Пішінді толтырған кезде есеп беруден көбірек пайда алатын мақсатты аудиторияны таңдау керек екенін ескеріңіз (тізімнің ішінде бір тосын сый бар).
Ақпарат көзі: www.habr.com