2019 жылы IT-компанияның табысты болуы үшін не қажет? Конференциялар мен кездесулердегі лекторлар қарапайым адамдарға түсінікті бола бермейтін көптеген қатты сөздерді айтады. Орналастыру уақыты, микросервистер, монолиттен бас тарту, DevOps трансформациясы және т.б. үшін күрес. Егер біз ауызша сұлулықты тастап, тікелей және орыс тілінде сөйлейтін болсақ, онда бәрі қарапайым тезиске түседі: жоғары сапалы өнім жасаңыз және оны командаға ыңғайлы етіп жасаңыз.
Соңғысы өте маңызды болды. Бизнес, ақырында, ыңғайлы даму процесі өнімділікті арттырады деген қорытындыға келді және егер бәрі түзетіліп, сағат сияқты жұмыс істесе, ол сонымен қатар қиын жағдайларда маневр жасауға мүмкіндік береді. Бір кездері, осы маневр үшін белгілі бір ақылды адам резервтік көшірмелерді ойлап тапты, бірақ сала дамып жатыр, біз DevOps инженерлеріне келдік - даму мен сыртқы инфрақұрылымның өзара әрекеттесу процесін барабар нәрсеге айналдыратын адамдар. шамандыққа қатысы жоқ.
Бұл бүкіл «модульдік» оқиға керемет, бірақ... Кейбір әкімшілер кенеттен DevOps деп аталды, ал DevOps инженерлерінің өздері кем дегенде телепатия мен көріпкелдік дағдыларын талап ете бастады.
Инфрақұрылымды қамтамасыз етудің заманауи мәселелері туралы айтпас бұрын, бұл терминмен нені білдіретінімізді анықтап алайық. Қазіргі уақытта жағдай біз бұл тұжырымдаманың екі жақтылығына жеткендей дамыды: инфрақұрылым шартты түрде сыртқы және шартты түрде ішкі болуы мүмкін.
Сыртқы инфрақұрылым деп біз топ әзірлеп жатқан қызметтің немесе өнімнің функционалдығын қамтамасыз ететін барлық нәрсені түсінеміз. Бұл қолданбалар немесе веб-сайт серверлері, хостинг және өнімнің функционалдығын қамтамасыз ететін басқа қызметтер.
Ішкі инфрақұрылым әзірлеу тобының өзі және әдетте көп болатын басқа қызметкерлер пайдаланатын қызметтер мен жабдықты қамтиды. Бұл кодты сақтау жүйелерінің ішкі серверлері, жергілікті түрде орналастырылған тапсырмалар менеджері және корпоративтік интранет ішінде бар барлығы, барлығы.
Жүйелік әкімші компанияда не істейді? Бұл өте корпоративтік интранетті басқару жұмысынан басқа, ол кеңсе жабдықтарының жұмыс істеуін қамтамасыз ету үшін жиі экономикалық мәселелердің ауыртпалығын көтереді. Әкімші - бұл артқы бөлмеден жаңа жүйелік блокты немесе пайдалануға дайын қосалқы ноутбукты тез сүйреп апаратын, жаңа пернетақтаны беріп, Ethernet кабелін созып, кеңселер арқылы төрт аяқпен жүгіретін сол жігіт. Әкімші тек ішкі және сыртқы серверлердің жергілікті иесі және басқарушысы, сонымен қатар кәсіпорынның басқарушысы болып табылады. Иә, кейбір әкімшілер аппараттық құралдарсыз тек жүйелік жазықтықта жұмыс істей алады. Олар «инфрақұрылымдық жүйе әкімшілерінің» жеке ішкі сыныбына бөлінуі керек. Ал кейбіреулері тек кеңсе техникасына қызмет көрсетуге маманданған, бақытымызға орай, компанияда жүзден астам адам болса, жұмыс ешқашан аяқталмайды. Бірақ олардың ешқайсысы девоп емес.
DevOps деген кім? Devops - бағдарламалық жасақтаманы әзірлеудің сыртқы инфрақұрылыммен өзара әрекеттесуі туралы айтатын жігіттер. Дәлірек айтқанда, қазіргі заманғы әзірлеушілер ftp-ге жаңартуларды жүктеп салған әкімшілерге қарағанда әлдеқайда тереңірек әзірлеу және орналастыру процестеріне қатысады. Қазіргі уақытта DevOps инженерінің негізгі міндеттерінің бірі - әзірлеушілер топтары мен өнім инфрақұрылымы арасындағы өзара әрекеттестіктің ыңғайлы және тиімді құрылымдық процесін қамтамасыз ету. Дәл осы адамдар кері қайтару және орналастыру жүйелерін орналастыруға жауапты; дәл осы адамдар әзірлеушілерге жүктеменің бір бөлігін алып тастайды және олардың өте маңызды міндетіне мүмкіндігінше шоғырланады. Сонымен қатар, devops ешқашан жаңа кабельді өткізбейді немесе артқы бөлмеден жаңа ноутбук шығармайды (c) KO
Бұл не?
«DevOps деген кім?» Деген сұраққа. өрістегі жұмысшылардың жартысы «Ал, қысқасы, бұл әкімші ...» және одан әрі мәтінде жауап бере бастайды. Иә, бір кездері, DevOps инженерінің мамандығы сервистік қызмет көрсету тұрғысынан ең талантты әкімшілерден енді ғана пайда болған кезде, олардың арасындағы айырмашылықтар бәріне анық емес еді. Бірақ қазір, командадағы девоптер мен админнің функциялары түбегейлі басқаша болған кезде, оларды бір-бірімен шатастыруға, тіпті оларды теңестіруге болмайды.
Бірақ бұл бизнес үшін нені білдіреді?
Жалдау, бәрі осыған байланысты.
Сіз «Жүйелік әкімші» бос лауазымын ашасыз және онда көрсетілген талаптар «әзірлеу және тұтынушылармен өзара әрекеттесу», «CI/CD жеткізу жүйесі», «компанияның серверлері мен жабдықтарына техникалық қызмет көрсету», «ішкі жүйелерді әкімшілендіру» және т.б. қосулы; сіз жұмыс берушінің бос сөз айтып жатқанын түсінесіз. «Жүйелік әкімші» орнына бос лауазым атауы «DevOps инженері» болуы керек, ал егер бұл атау өзгертілсе, бәрі орнына келеді.
Дегенмен, мұндай бос орынды оқыған адам қандай әсер алады? Компания нұсқаларды басқару және бақылау жүйесін қосатын және бұрауышты тістерімен қысатын көп машиналы операторды іздейді ...
Бірақ еңбек нарығындағы нашақорлық дәрежесін арттырмау үшін бос жұмыс орындарын өз атауларымен атау және DevOps инженері мен жүйелік әкімші екі түрлі субъект екенін анық түсіну жеткілікті. Бірақ кейбір жұмыс берушілердің үміткерге қойылатын талаптардың барынша кең тізбесін ұсынуға деген басылмайтын ұмтылысы «классикалық» жүйе әкімшілерінің айналасында не болып жатқанын түсінуді тоқтатуына әкеледі. Не, мамандық мутацияға ұшырап, заманнан артта қалды ма?
Жоқ және тағы бір рет жоқ. Компанияның ішкі серверлерін басқаратын немесе L2/L3 қолдау позицияларын алатын және басқа қызметкерлерге көмектесетін инфрақұрылым әкімшілері кеткен жоқ және кеткісі келмейді.
Бұл мамандар DevOps инженері бола ала ма? Әрине, олар мүмкін. Шындығында, бұл жүйелік басқару дағдыларын талап ететін байланысты орта, бірақ оған қосымша мониторинг, жеткізу жүйелерімен жұмыс және жалпы алғанда әзірлеу және тестілеу тобымен тығыз әрекеттесу қосылады.
Тағы бір DevOps мәселесі
Шындығында, бәрі тек жалдаумен және әкімшілер мен devops арасындағы тұрақты шатасумен шектелмейді. Бір сәтте бизнес жаңартуларды жеткізу және әзірлеу тобының соңғы инфрақұрылыммен өзара әрекеттесу мәселесіне тап болды.
Мүмкін бұл бір конференцияның сахнасында көзі жарқыраған ағай тұрып: «Біз мұны жасаймыз және оны DevOps деп атаймыз. Бұл жігіттер сіздің барлық мәселелеріңізді шешеді» - және DevOps тәжірибесін енгізгеннен кейін компаниядағы өмірдің қаншалықты жақсы екенін айта бастады.
Дегенмен, бәрі дұрыс жұмыс істеуі үшін DevOps инженерін жалдау жеткіліксіз. Компания толық DevOps трансформациясынан өтуі керек, яғни біздің DevOps рөлі мен мүмкіндіктері өнімді әзірлеу және тестілеу тобы жағынан да анық түсінілуі керек. Бізде бұл тақырып бойынша кейбір жерлерде болып жатқан барлық қатыгездіктерді толығымен көрсететін «тамаша» әңгіме бар.
Жағдай. DevOps нұсқасын кері қайтару жүйесін оның қалай жұмыс істейтінін нақты зерттемей орналастыру үшін қажет. Пайдаланушылар жүйесінде аты, тегі және құпия сөзі үшін бөлек өрістер бар деп есептейік. Өнімнің жаңа нұсқасы шығады, бірақ әзірлеушілер үшін «қайтару» барлығын түзететін сиқырлы таяқша ғана және олар оның қалай жұмыс істейтінін білмейді. Мәселен, мысалы, келесі патчта әзірлеушілер аты-жөні өрістерін біріктіріп, оны өндіріске шығарды, бірақ қандай да бір себептермен нұсқа баяу. Не болып жатыр? Менеджмент devops-қа келіп, «Ауыстыруды тарт!» дейді, яғни бұрынғы нұсқаға оралуды сұрайды. Devops не істейді? Ол алдыңғы нұсқаға оралады, бірақ әзірлеушілер бұл кері қайтарудың қалай жасалғанын білгісі келмегендіктен, ешкім devops командасына дерекқорды да кері қайтару керек екенін айтқан жоқ. Нәтижесінде біз үшін бәрі бұзылады және баяу веб-сайттың орнына пайдаланушылар «500» қатесін көреді, себебі ескі нұсқа жаңа дерекқор өрістерімен жұмыс істемейді. Девопс бұл туралы білмейді. Әзірлеушілер үндемейді. Басшылық жүйкелері мен ақшаларын жоғалта бастайды және резервтік көшірмелерді есіне алады, олардан «кем дегенде бірдеңе жұмыс істейтін болады» деп қайтаруды ұсынады. Нәтижесінде пайдаланушылар белгілі бір уақыт аралығында барлық деректерін жоғалтады.
Жаңғақтар, әрине, «дұрыс кері қайтару жүйесін жасамаған» devops-қа барады және бұл оқиғадағы бұланның әзірлеушілер екенін ешкім ойламайды.
Қорытынды қарапайым: DevOps-қа қалыпты көзқарассыз оның пайдасы шамалы.
Есте сақтау керек ең бастысы: DevOps инженері сиқыршы емес, сапалы байланыссыз және дамумен екі жақты әрекеттесусіз ол өз міндеттерін орындай алмайды. Әзірлеушілерді өздерінің «мәселелерімен» жалғыз қалдыруға болмайды немесе «әзірлеушілерге араласпа, олардың міндеті - кодтау» пәрменін беру, содан кейін қиын сәтте бәрі дұрыс жұмыс істейтініне үміттенеді. Бұлай жұмыс істемейді.
Негізінде, DevOps - бұл менеджмент пен технология арасындағы шекарадағы құзырет. Оның үстіне, бұл коктейльде менеджменттен гөрі көп технология болуы керек екені анық емес. Егер сіз шынымен тезірек және тиімдірек әзірлеу процестерін құрғыңыз келсе, devops командасына сенуіңіз керек. Ол дұрыс құралдарды біледі, ол ұқсас жобаларды жүзеге асырды, оны қалай жасау керектігін біледі. Оған көмектесіңіз, оның кеңесін тыңдаңыз, оны қандай да бір автономды бірлікке оқшаулауға тырыспаңыз. Егер әкімшілер өздігінен жұмыс істей алатын болса, онда бұл жағдайда devops пайдасыз, егер сіз бұл көмекті қабылдағыңыз келмесе, олар сізге жақсырақ болуға көмектесе алмайды.
Және соңғы бір нәрсе: инфрақұрылым әкімшілерін ренжітуді доғарыңыз. Олардың өз жұмысының өте маңызды фронты бар. Иә, әкімші DevOps инженері бола алады, бірақ бұл қысыммен емес, адамның өз өтініші бойынша болуы керек. Ал жүйелік әкімшінің жүйелік әкімші болып қалғысы келетінінің еш айыбы жоқ – бұл оның жеке кәсібі және оның құқығы. Егер сіз кәсіби трансформациядан өткіңіз келсе, онда сізге тек технологиялық дағдыларды ғана емес, сонымен қатар басқару дағдыларын да қалыптастыру керек екенін ешқашан ұмытпау керек. Сірә, бұл адамдардың барлығын біріктіріп, бір тілде сөйлесуге үйрету көшбасшы ретінде сіздің қолыңызда.
Ақпарат көзі: www.habr.com