DevOps соңғы бірнеше жылда өте танымал тақырыпқа айналды. Көптеген адамдар оған қосылуды армандайды, бірақ тәжірибе көрсеткендей, көбінесе жалақы деңгейіне байланысты.
Кейбір адамдар DevOps-ті резюмесінде жазады, дегенмен олар терминнің мәнін әрқашан білмейді немесе түсінбейді. Кейбіреулер Ansible, GitLab, Jenkins, Terraform және т.б. (тізімді сіздің талғамыңызға қарай жалғастыруға болады) оқығаннан кейін сіз бірден «девопсист» боласыз деп ойлайды. Бұл, әрине, дұрыс емес.
Соңғы бірнеше жылда мен негізінен әртүрлі компанияларда DevOps енгізумен айналыстым. Бұған дейін ол жүйелік әкімшіден IT директорына дейін 20 жылдан астам қызмет атқарған. Қазіргі уақытта Playgendary-де DevOps жетекші инженері.
DevOps деген кім
Мақала жазу идеясы тағы бір сұрақтан кейін пайда болды: «DevOps кім?» Әлі күнге дейін бұл не немесе кім екендігі туралы нақты термин жоқ. Жауаптардың кейбірі қазірдің өзінде осында . Алдымен оның негізгі тұстарын бөліп көрсетемін, содан кейін өз бақылауларыммен, ойларыммен бөлісемін.
DevOps жалдауға болатын маман емес, коммуналдық қызметтер жиынтығы емес, инженерлері бар әзірлеушілер бөлімі емес.
DevOps - бұл философия мен әдіснама.
Басқаша айтқанда, бұл әзірлеушілерге жүйелік әкімшілермен белсенді әрекеттесуге көмектесетін тәжірибелер жиынтығы. Яғни, жұмыс процестерін бір-бірімен байланыстыру және біріктіру.
DevOps пайда болған кезде мамандардың құрылымы мен рөлдері өзгеріссіз қалды (әзірлеушілер бар, инженерлер бар), бірақ өзара әрекеттесу ережелері өзгерді. Бөлімшелер арасындағы шекара бұлыңғыр болды.
DevOps мақсаттарын үш тармақта сипаттауға болады:
- Бағдарламалық құрал үнемі жаңартылып отыруы керек.
- Бағдарламалық жасақтаманы тез жасау керек.
- Бағдарламалық қамтамасыз ету ыңғайлы және қысқа мерзімде орналастырылуы керек.
DevOps үшін жалғыз құрал жоқ. Бірнеше өнімді конфигурациялау, жеткізу және зерттеу DevOps компанияда пайда болды дегенді білдірмейді. Құралдар өте көп және олардың барлығы әртүрлі кезеңде қолданылады, бірақ бір мақсатқа қызмет етеді.
Бұл DevOps құралдарының бір бөлігі ғана
Мен DevOps инженері лауазымына адамдармен сұхбат жүргізіп жатқаныма 2 жылдан астам уақыт болды және мен терминнің мәнін нақты түсіну қаншалықты маңызды екенін түсіндім. Мен бөліскім келетін нақты тәжірибелер, бақылаулар мен ойлар жинадым.
Сұхбат тәжірибесінен мен келесі суретті көремін: DevOps-ті лауазым деп санайтын мамандар әдетте әріптестерімен түсініспеушілік тудырады.
Керемет мысал болды. Жас жігіт сұхбатқа түйіндемесінде көптеген ақылды сөздермен келді. Соңғы үш жұмыс орнында оның 5-6 ай тәжірибесі болды. Мен екі стартапты қалдырдым, өйткені олар «ұшпаған». Бірақ үшінші компания туралы ол оны ешкім түсінбейтінін айтты: әзірлеушілер Windows жүйесінде код жазады, ал директор бұл кодты кәдімгі Docker-ге «орауға» және CI/CD құбырына салуға мәжбүр етеді. Жігіт өзінің қазіргі жұмыс орны мен әріптестері туралы көптеген жағымсыз сөздер айтты - мен жай ғана жауап бергім келді: «Сондықтан сіз пілді сатпайсыз».
Содан кейін мен оған әрбір кандидат үшін тізімімде жоғары сұрақ қойдым.
— Жеке сіз үшін DevOps нені білдіреді?
– Жалпы немесе мен оны қалай қабылдаймын?
Мені оның жеке пікірі қызықтырды. Ол терминнің теориясы мен шығу тегін білді, бірақ олармен үзілді-кесілді келіспеді. Ол DevOps жұмыс атауы деп сенді. Оның проблемаларының түп негізі осында жатыр. Сондай-ақ осындай пікірдегі басқа мамандар.
«DevOps сиқыры» туралы көп естіген жұмыс берушілер келіп, осы «сиқырды» жасайтын адамды тапқысы келеді. Ал «DevOps - бұл жұмыс» санатындағы үміткерлер бұл тәсілмен үміттерді ақтай алмайтынын түсінбейді. Жалпы алғанда, олар өз түйіндемелеріне DevOps жазды, өйткені бұл тренд және олар бұл үшін көп төлейді.
DevOps әдіснамасы және философиясы
Әдістеме теориялық және практикалық болуы мүмкін. Біздің жағдайда бұл екінші. Жоғарыда атап өткенімдей, DevOps - бұл қойылған мақсаттарға жету үшін қолданылатын тәжірибелер мен стратегиялар жиынтығы. Әр жағдайда компанияның бизнес-процестеріне байланысты ол айтарлықтай ерекшеленуі мүмкін. Бұл оны жақсырақ немесе нашарлатпайды.
DevOps әдістемесі тек мақсаттарға жету құралы болып табылады.
Енді DevOps философиясы не туралы. Және бұл ең қиын сұрақ шығар.
Қысқа және ықшам жауап беру өте қиын, өйткені ол әлі ресімделмеген. DevOps философиясының жақтаушылары тәжірибемен көбірек айналысатындықтан, философиялауға уақыт жоқ. Дегенмен, бұл өте маңызды процесс. Оның үстіне, ол инженерлік қызметпен тікелей байланысты. Тіпті арнайы білім саласы бар - .
Менің университетімде ондай пән болған жоқ, 90-шы жылдары қолыма түскен материалдарды пайдалана отырып, барлығын өз бетімше оқуға тура келді. Тақырып инженерлік білім үшін факультативтік болып табылады, осыдан жауаптың формалданбауы. Бірақ DevOps-ке байыппен енген адамдар компанияның барлық процестерінің белгілі бір «рухын» немесе «санасыз жан-жақтылығын» сезіне бастайды.
Мен өз тәжірибемді пайдалана отырып, осы философияның кейбір «постулаттары» ресми түрде беруге тырыстым. Нәтиже келесідей:
- DevOps - бұл білімнің немесе қызметтің жеке саласына бөлуге болатын тәуелсіз нәрсе емес.
- Компанияның барлық қызметкерлері өз қызметін жоспарлау кезінде DevOps әдістемесін басшылыққа алуы керек.
- DevOps компаниядағы барлық процестерге әсер етеді.
- DevOps компаниясы қызметтердің дамуын және тұтынушыларға барынша жайлылықты қамтамасыз ету үшін компаниядағы кез келген процестерге уақыт шығындарын азайту үшін бар.
- DevOps, қазіргі тілмен айтқанда, компанияның әрбір қызметкерінің уақыт шығындарын азайтуға және айналамыздағы IT өнімдерінің сапасын жақсартуға бағытталған белсенді ұстанымы.
Менің ойымша, менің «постулаттарым» талқылауға арналған бөлек тақырып. Бірақ енді бірдеңе құру керек.
DevOps не істейді
Мұндағы негізгі сөз – коммуникация. Көптеген коммуникациялар бар, олардың бастамашысы дәл сол DevOps инженері болуы керек. Неге бұлай? Өйткені бұл философия мен әдістеме, содан кейін ғана инженерлік білім.
Мен Батыстың еңбек нарығы туралы 100% сеніммен айта алмаймын. Бірақ мен Ресейдегі DevOps нарығы туралы көп білемін. Жүздеген сұхбаттардан басқа, соңғы бір жарым жыл ішінде мен ірі ресейлік компаниялар мен банктер үшін «DevOps енгізу» сервисінің жүздеген техникалық алдын ала сатылымдарына қатыстым.
Ресейде DevOps әлі де өте жас, бірақ қазірдің өзінде танымал тақырып. Менің білуімше, бір ғана Мәскеуде 2019 жылы мұндай мамандардың жетіспеушілігі 1000-нан астам адамды құрады. Ал жұмыс берушілерге арналған Кубернетес сөзі бұқа үшін қызыл шүберек сияқты. Бұл құралды ұстанушылар оны қажет емес және экономикалық тұрғыдан тиімді болған жағдайда да қолдануға дайын. Жұмыс беруші қай жағдайда нені пайдалану тиімдірек екенін және дұрыс орналастыру кезінде Kubernetes кластерін қолдау әдеттегі кластер схемасын пайдаланып қолданбаны орналастыруға қарағанда 2-3 есе қымбатқа түсетінін әрқашан түсінбейді. Оны шынымен қажет жерде пайдаланыңыз.
DevOps-ті енгізу ақша тұрғысынан қымбат. Және ол өз бетімен емес, басқа салаларда экономикалық пайда әкелетін жерде ғана ақталады.
DevOps инженерлері, шын мәнінде, пионерлер - олар осы әдістемені компанияда бірінші болып енгізіп, процестерді құруы керек. Бұл сәтті болуы үшін маман барлық деңгейдегі қызметкерлермен және әріптестерімен үнемі қарым-қатынаста болуы керек. Әдеттегідей, компанияның барлық қызметкерлері DevOps енгізу процесіне қатысуы керек: тазалаушы әйелден бас директорға дейін. Және бұл міндетті шарт. Егер команданың ең кіші мүшесі DevOps дегеннің не екенін және белгілі бір ұйымдастырушылық әрекеттердің неліктен орындалатынын білмесе және түсінбесе, табысты іске асыру нәтиже бермейді.
Сондай-ақ, DevOps инженері мезгіл-мезгіл әкімшілік ресурсты пайдалануы керек. Мысалы, «қоршаған ортаға қарсылықты» жеңу үшін - команда DevOps құралдары мен әдістемесін қабылдауға дайын болмаған кезде.
Әзірлеуші тек код пен сынақтарды жазуы керек. Мұны істеу үшін оған жобаның барлық инфрақұрылымын орналастыратын және жергілікті түрде қолдайтын өте қуатты ноутбук қажет емес. Мысалы, front-end әзірлеушісі өз ноутбугында қолданбаның барлық элементтерін сақтайды, соның ішінде мәліметтер базасы, S3 эмуляторы (minio) және т.б. Яғни, ол осы жергілікті инфрақұрылымды ұстауға көп уақыт жұмсайды және мұндай шешімнің барлық мәселелерімен жалғыз өзі күреседі. Майданға арналған кодты әзірлеудің орнына. Мұндай адамдар кез келген өзгеріске өте төзімді болуы мүмкін.
Бірақ, керісінше, жаңа құралдар мен әдістерді енгізуге қуанышты және бұл процеске белсенді қатысатын командалар бар. Бұл жағдайда да DevOps инженері мен команда арасындағы байланыс жойылған жоқ.
DevOps қажет болмаған кезде
DevOps қажет емес жағдайлар бар. Бұл шындық - оны түсіну және қабылдау керек.
Ең алдымен, бұл кез келген компанияларға (әсіресе шағын бизнеске), олардың пайдасы клиенттерге ақпараттық қызмет көрсететін АТ өнімдерінің бар немесе жоқтығына тікелей тәуелді болмаған кезде қатысты. Бұл жерде біз компанияның веб-сайты туралы емес, ол статикалық «визит картасы» немесе динамикалық жаңалықтар блоктары бар және т.б.
DevOps клиенттің қанағаттануы және оның сізге қайта оралу ниеті клиентпен өзара әрекеттесу үшін осы ақпараттық қызметтердің қолжетімділігіне, олардың сапасы мен мақсаттылығына байланысты болған кезде қажет.
Жарқын мысал ретінде белгілі бір банкті келтіруге болады. Компанияда дәстүрлі клиенттік кеңселер жоқ, құжат айналымы пошта немесе курьерлер арқылы жүзеге асырылады, көптеген қызметкерлер үйден жұмыс істейді. Компания жай ғана банк болуды тоқтатты және менің ойымша, дамыған DevOps технологиялары бар IT-компанияға айналды.
Көптеген басқа мысалдар мен дәрістерді тақырыптық кездесулер мен конференциялардың жазбаларынан табуға болады. Мен олардың кейбіреулеріне жеке бардым - бұл осы бағытта дамытқысы келетіндер үшін өте пайдалы тәжірибе. Мұнда DevOps бойынша жақсы дәрістер мен материалдары бар YouTube арналарына сілтемелер берілген:
Енді сіздің бизнесіңізге қараңыз және бұл туралы ойланыңыз: Клиенттердің өзара әрекеттесуін қамтамасыз ету үшін сіздің компанияңыз бен оның пайдасы АТ өнімдеріне қаншалықты тәуелді?
Егер сіздің компанияңыз балықты шағын дүкенде сатса және жалғыз IT өнімі екі 1С: Кәсіпорын конфигурациялары болса (Бухгалтерлік есеп және UNF), онда DevOps туралы айтудың мағынасы жоқ.
Егер сіз ірі сауда және өндірістік кәсіпорында жұмыс істесеңіз (мысалы, сіз аңшылық мылтық шығарасыз), онда сіз бұл туралы ойлануыңыз керек. Сіз бастаманы өз қолыңызға алып, басшылыққа DevOps енгізу перспективаларын жеткізе аласыз. Сонымен қатар, бұл процесті басқарыңыз. Проактивті позиция - DevOps философиясының маңызды қағидаларының бірі.
Жылдық қаржы айналымының мөлшері мен көлемі сіздің компанияңызға DevOps қажет пе екенін анықтаудың негізгі критерийі болып табылмайды.
Тұтынушылармен тікелей әрекеттеспейтін ірі өнеркәсіптік кәсіпорынды елестетейік. Мысалы, кейбір автоөндірушілер мен автомобиль шығаратын компаниялар. Мен қазір сенімді емеспін, бірақ өткен тәжірибемнен көптеген жылдар бойы тұтынушылардың өзара әрекеттесуі электрондық пошта және телефон арқылы жасалды.
Олардың клиенттері автокөлік дилерлерінің шектеулі тізімі. Және әрқайсысына өндірушіден маман тағайындалады. Барлық ішкі құжат айналымы SAP ERP арқылы жүзеге асады. Ішкі қызметкерлер негізінен ақпараттық жүйенің клиенттері болып табылады. Бірақ бұл АЖ кластерлік жүйелерді басқарудың классикалық құралдарымен басқарылады. Бұл DevOps тәжірибесін пайдалану мүмкіндігін жоққа шығарады.
Осыдан қорытынды: егер мақаланың басынан бастап әдістеменің мақсаттарын еске түсіретін болсақ, мұндай кәсіпорындар үшін DevOps енгізу маңызды нәрсе емес. Бірақ мен олардың бүгінде кейбір DevOps құралдарын пайдаланатынын жоққа шығармаймын.
Екінші жағынан, DevOps әдістемесін, философиясын, тәжірибелерін және құралдарын пайдалана отырып бағдарламалық қамтамасыз етуді әзірлейтін көптеген шағын компаниялар бар. Және олар DevOps-ті енгізу құны бағдарламалық қамтамасыз ету нарығында тиімді бәсекелесуге мүмкіндік беретін шығындар деп санайды. Мұндай компаниялардың мысалдарын көруге болады .
DevOps қажет пе екенін түсінудің негізгі критерийі: сіздің IT өнімдеріңіз компания мен тұтынушылар үшін қандай құндылыққа ие.
Егер компанияның пайда әкелетін негізгі өнімі бағдарламалық жасақтама болса, сізге DevOps қажет. Егер сіз басқа өнімдерді пайдаланып нақты ақша тапсаңыз, бұл маңызды емес. Бұған онлайн дүкендер немесе ойындары бар мобильді қосымшалар да кіреді.
Кез келген ойындар қаржыландырудың арқасында бар: ойыншылардың тікелей немесе жанама. Playgendary-те біз 200-ден астам адаммен тегін мобильді ойындар әзірлейміз. DevOps-ті қалай пайдаланамыз?
Иә, дәл жоғарыда сипатталғандай. Мен әзірлеушілермен және тестерлермен үнемі байланысып отырамын және қызметкерлерге DevOps әдіснамасы мен құралдары бойынша ішкі тренинг өткіземін.
Біз қазір Unity көмегімен барлық құрастыру құбырларын орындауға және кейіннен App Store және Play Marketке орналастыруға арналған CI/CD конвейерлер құралы ретінде Дженкинсті белсенді түрде пайдаланып жатырмыз. Классикалық құралдар жинағынан көбірек:
- Asana - жобаны басқаруға арналған. Дженкинспен интеграция конфигурацияланды.
- Google Meet - бейне кездесулер үшін.
- Slack - байланыс және әртүрлі ескертулер, соның ішінде Дженкинс хабарламалары үшін.
- Atlassian Confluence - құжаттама және топтық жұмыс үшін.
Біздің жақын арада жоспарларымызға SonarQube көмегімен статикалық код талдауын енгізу және үздіксіз интеграция кезеңінде Selenium көмегімен автоматтандырылған UI тестілеуін жүргізу кіреді.
Орнына жасасу
Мен келесі оймен аяқтағым келеді: жоғары білікті DevOps инженері болу үшін адамдармен тікелей сөйлесуді үйрену өте маңызды.
DevOps инженері – командалық ойыншы. Және басқа ештеңе. Әріптестермен қарым-қатынас жасаудағы бастама кейбір жағдайлардың әсерінен емес, одан туындауы керек. DevOps маманы топ үшін ең жақсы шешімді көруі және ұсынуы керек.
Иә, кез келген шешімді жүзеге асыру көп талқылауды қажет етеді және соңында ол мүлдем өзгеруі мүмкін. Өз бетінше дамып, өз идеяларын ұсынып, жүзеге асыра отырып, мұндай адамның ұжым үшін де, жұмыс беруші үшін де құндылығы арта түседі. Бұл, сайып келгенде, оның ай сайынғы сыйақысының мөлшерінде немесе қосымша бонустар түрінде көрінеді.
Ақпарат көзі: www.habr.com