DevOps акыркы бир нече жыл ичинде абдан популярдуу тема болуп калды. Көптөгөн адамдар ага кошулууну кыялданышат, бирок, практика көрсөткөндөй, көбүнчө айлык акынын деңгээлине байланыштуу.
Кээ бир адамдар резюмесинде DevOps'ту тизмектешет, бирок алар ар дайым терминдин маңызын билишпейт же түшүнүшпөйт. Кээ бирөөлөр Ansible, GitLab, Jenkins, Terraform жана ушул сыяктууларды (тизмени сиздин табитиңизге жараша улантса болот) окугандан кийин дароо эле "девопсист" болуп каласыз деп ойлошот. Бул, албетте, туура эмес.
Акыркы бир нече жылдан бери мен негизинен ар кандай компанияларда DevOpsти ишке ашыруу менен алектендим. Ага чейин ал 20 жылдан ашык системалык администратордон IT директорго чейинки кызматтарда иштеген. Учурда Playgendaryде DevOps башкы инженери.
DevOps деген ким
Макала жазуу идеясы дагы бир суроодон кийин пайда болду: "DevOps ким?" Азырынча ал эмне жана ким экендиги тууралуу так термин жок. Кээ бир жооптор буга чейин эле бар . Адегенде андан негизги ойлорду баса белгилеп, анан өзүмдүн байкоолорумду, ойлорумду бөлүшөм.
DevOps жалдай турган адис эмес, коммуналдык кызматтардын жыйындысы эмес, инженерлери бар иштеп чыгуучулардын бөлүмү эмес.
DevOps - бул философия жана методология.
Башкача айтканда, бул иштеп чыгуучуларга системалык администраторлор менен активдүү өз ара аракеттенүүгө жардам берген практикалардын жыйындысы. Башкача айтканда, иш процесстерин бири-бирине бириктирүү жана интеграциялоо.
DevOps пайда болушу менен адистердин структурасы жана ролдору өзгөрүүсүз калды (иштеп чыгуучулар бар, инженерлер бар), бирок өз ара аракеттенүү эрежелери өзгөрдү. Бөлүмдөрдүн ортосундагы чек аралар бүдөмүк болуп калды.
DevOps максаттарын үч пунктта сүрөттөсө болот:
- Программалык камсыздоо үзгүлтүксүз жаңыртылууга тийиш.
- Программалык камсыздоону тез арада жасоо керек.
- Программалык камсыздоо ыңгайлуу жана кыска мөөнөттө жайылтылууга тийиш.
DevOps үчүн бирдиктүү курал жок. Бир нече өнүмдөрдү конфигурациялоо, жеткирүү жана изилдөө DevOps компанияда пайда болду дегенди билдирбейт. Куралдар көп жана алардын бардыгы ар кандай этаптарда колдонулат, бирок бир жалпы максатка кызмат кылат.
Бул DevOps куралдарынын бир бөлүгү гана
Мен 2 жылдан ашык убакыттан бери DevOps инженери кызматына адамдардан интервью берип жатам жана терминдин маңызын так түшүнүү канчалык маанилүү экенин түшүндүм. Мен бөлүшкүм келген конкреттүү тажрыйбаларды, байкоолорду жана ойлорумду топтодум.
Маектешүү тажрыйбасынан мен төмөнкү сүрөттү көрдүм: 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 куралдарын жана методологиясын кабыл алууга даяр эмес болгондо.
Иштеп чыгуучу кодду жана тесттерди гана жазышы керек. Бул үчүн ага супер кубаттуу ноутбуктун кереги жок, ага ал орнотуп, долбоордун бардык инфраструктурасын локалдуу колдойт. Мисалы, алдыңкы иштеп чыгуучу тиркеменин бардык элементтерин ноутбукта сактайт, анын ичинде маалымат базасы, S3 эмулятору (minio) ж.б. Башкача айтканда, ал жергиликтүү инфраструктураны сактоого көп убакыт коротот жана мындай чечимдин бардык көйгөйлөрү менен жалгыз күрөшөт. Фронт үчүн кодду иштеп чыгуунун ордуна. Мындай адамдар ар кандай өзгөрүүгө абдан туруштук бере алышат.
Бирок, тескерисинче, жацы инструменттерди жана методдорду киргизууге кубанып, бул процесске активдуу катышкан коллективдер бар. Бул учурда да, DevOps инженери менен команданын ортосундагы байланыш жокко чыгарылган эмес.
DevOps кереги жок болгондо
DevOps кереги жок болгон жагдайлар бар. Бул чындык - аны түшүнүү жана кабыл алуу керек.
Биринчиден, бул ар кандай компанияларга (айрыкча чакан бизнеске) тиешелүү, эгерде алардын пайдасы кардарларга маалыматтык кызматтарды көрсөткөн IT продуктуларынын бар же жоктугунан түздөн-түз көз каранды эмес. Бул жерде биз компаниянын веб-сайты жөнүндө эмес, ал статикалык "визиттик карта" же динамикалык жаңылык блоктору менен ж.б.
Сиздин кардарыңыздын канааттануусу жана анын сизге кайра кайрылып келүү каалоосу кардар менен өз ара аракеттенүү үчүн бул маалыматтык кызматтардын болушуна, алардын сапатына жана максаттуулугуна көз каранды болгондо, DevOps талап кылынат.
Жаркыраган мисал - белгилүү банк. Компанияда кадимки кардарлардын кеңселери жок, документ жүгүртүү почта же курьер аркылуу ишке ашырылат, көптөгөн кызматкерлер үйдөн иштешет. Компания жөн гана банк болууну токтотту жана менин оюмча, өнүккөн DevOps технологиялары бар IT компаниясына айланды.
Башка кептеген мисалдарды жана лекцияларды тематикалык жолугушуулардын жана конференциялардын жазууларынан табууга болот. Мен алардын айрымдарына жеке өзүм барып көрдүм – бул бул багытта өнүгүүнү каалагандар үчүн абдан пайдалуу тажрыйба. Бул жерде DevOps боюнча жакшы лекциялар жана материалдар бар YouTube каналдарына шилтемелер:
Эми бизнесиңизди карап, бул жөнүндө ойлонуп көрүңүз: Сиздин компанияңыз жана анын кирешеси кардарлардын өз ара аракеттенүүсүн камсыз кылуу үчүн IT продуктыларынан канчалык көз каранды?
Эгерде сиздин компанияңыз кичинекей дүкөндө балык сатса жана жалгыз IT продукт эки 1C: Enterprise конфигурациясы болсо (Бухгалтердик эсеп жана UNF), анда DevOps жөнүндө сөз кылуунун мааниси жок.
Эгерде сиз ири соода жана өндүрүш ишканасында иштесеңиз (мисалы, сиз мергенчилик мылтык чыгарсаңыз), анда бул жөнүндө ойлонушуңуз керек. Сиз демилгени колго алып, өзүңүздүн жетекчилигиңизге DevOps программасын ишке ашыруунун келечегин билдире аласыз. Ооба, жана ошол эле учурда, бул жараянды жетектейт. Проактивдүү позиция - DevOps философиясынын маанилүү жоболорунун бири.
Жылдык каржы жүгүртүүнүн көлөмү жана көлөмү сиздин компанияңызга DevOps керекпи же жокпу аныктоо үчүн негизги критерий эмес.
Келгиле, кардарлар менен түз байланышта болбогон ири өнөр жай ишканасын элестетип көрөлү. Мисалы, кээ бир автозаводдор жана автомобиль жасоочу ишканалар. Мен азыр так айта албайм, бирок мурунку тажрыйбам боюнча, көп жылдар бою кардарлардын баарлашуусу электрондук почта жана телефон аркылуу жасалган.
Алардын кардарлары унаа сатуучулардын чектелген тизмеси. Ал эми ар бирине өндүрүүчүдөн адис дайындалат. Бардык ички документ агымы SAP ERP аркылуу ишке ашат. Ички кызматкерлер негизинен маалымат системасынын кардарлары болуп саналат. Бирок бул ИС кластердик системаларды башкаруунун классикалык каражаттары менен башкарылат. Бул DevOps тажрыйбаларын колдонуу мүмкүнчүлүгүн жокко чыгарат.
Демек, тыянак: мындай ишканалар үчүн, DevOps ишке ашыруу маанилүү нерсе эмес, эгерде биз макаланын башынан баштап методологиянын максаттарын эстесек. Бирок мен алар бүгүнкү күндө кээ бир DevOps куралдарын колдонушарын жокко чыгарбайм.
Башка жагынан алганда, DevOps методологиясын, философиясын, практикасын жана куралдарын колдонуу менен программалык камсыздоону иштеп чыгуучу көптөгөн чакан компаниялар бар. Жана алар DevOpsти ишке ашыруунун баасы программалык камсыздоо рыногунда эффективдүү атаандашууга мүмкүндүк берген чыгым деп эсептешет. Мындай компаниялардын мисалдарын көрүүгө болот .
DevOps керекпи же жокпу түшүнүүнүн негизги критерийи: сиздин IT продуктуларыңыз компания жана кардарлар үчүн кандай мааниге ээ.
Эгерде компаниянын киреше алып келүүчү негизги продуктусу программалык камсыздоо болсо, сизге DevOps керек. Жана башка өнүмдөрдү колдонуу менен реалдуу акча тапсаңыз, бул анчалык деле маанилүү эмес. Бул ошондой эле оюндар менен онлайн дүкөндөр же мобилдик тиркемелерди камтыйт.
Бардык оюндар каржылоонун аркасында бар: оюнчулардан түз же кыйыр. Playgendary'де биз аларды түзүүгө түздөн-түз катышкан 200дөн ашык адам менен акысыз мобилдик оюндарды иштеп чыгабыз. DevOps'ту кантип колдонобуз?
Ооба, жогоруда айтылгандай эле. Мен иштеп чыгуучулар жана тестерлер менен дайыма байланышып турам жана DevOps методологиясы жана куралдары боюнча кызматкерлер үчүн ички тренингдерди өткөрөм.
Азыр биз Jenkinsти CI/CD түтүктөр инструменти катары Unity менен бардык монтаждык түтүктөрдү аткаруу жана андан кийин App Store жана Play Market'ке жайылтуу үчүн активдүү колдонуп жатабыз. Классикалык куралдар топтомунан көбүрөөк:
- Asana - долбоорду башкаруу үчүн. Дженкинс менен интеграция конфигурацияланган.
- Google Meet - видео жолугушуулар үчүн.
- Slack - байланыш жана ар кандай эскертүүлөр үчүн, анын ичинде Дженкинстен эскертмелер.
- Atlassian Confluence - документтештирүү жана топтук иш үчүн.
Биздин жакынкы пландарыбызга SonarQube аркылуу статикалык код анализин киргизүү жана Үзгүлтүксүз интеграция баскычында Selenium аркылуу автоматташтырылган UI тестирлөө жүргүзүү кирет.
Ордуна корутундусу
Мен төмөнкү ой менен аяктагым келет: жогорку квалификациялуу DevOps инженери болуу үчүн адамдар менен түз баарлашууну үйрөнүү абдан маанилүү.
DevOps инженери команданын оюнчусу. Жана башка эч нерсе. Кесиптештер менен баарлашууда демилге кээ бир жагдайлардын таасири астында эмес, андан чыгышы керек. DevOps адиси команда үчүн эң жакшы чечимди көрүп, сунушташы керек.
Ооба, кандайдыр бир чечимди ишке ашыруу көп талкууну талап кылат жана акырында ал таптакыр өзгөрүшү мүмкүн. Өз алдынча өнүгүп, өз идеяларын сунуштап жана ишке ашырып жаткан мындай адам коллектив үчүн да, иш берүүчү үчүн да баалуу болуп саналат. Бул, акырында, анын ай сайын төлөнүүчү сыйакысынын өлчөмүндө же кошумча сыйлыктар түрүндө чагылдырылат.
Source: www.habr.com