Учурда бул рынокто дээрлик эң кымбат позиция. "DevOps" инженерлеринин айланасындагы ызы-чуу бардык элестете турган чектен ашып, DevOps улук инженерлери менен андан да жаман.
Мен интеграция жана автоматташтыруу бөлүмүнүн башчысы болуп иштейм, англисче декоддоону болжолдойм - DevOps Manager. Англисче стенограмма биздин күнүмдүк иш-аракеттерибизди чагылдырышы күмөн, бирок бул учурда орус версиясы такыраак. Менин ишмердүүлүгүмдүн мүнөзүнө жараша, менин командамдын болочок мүчөлөрү менен интервью алуу зарылчылыгы табигый нерсе, акыркы бир жылдын ичинде мен аркылуу 50гө жакын адам өттү, менин кызматкерлерим менен алдын ала экранда ушунча адам үзүлдү.
Биз дагы эле кесиптештерди издеп жатабыз, анткени DevOps энбелгинин артында ар кандай инженерлердин абдан чоң катмары жашырылган.
Төмөндө жазылгандардын баары менин жеке оюм, ага кошулушуңуз шарт эмес, бирок темага болгон мамилеңизге кандайдыр бир түс кошуп турганын моюнга алам. Элдин көңүлүнөн чыгып калуу коркунучуна карабай, мен өз оюмду жарыялайм, анткени анын орду бар деп эсептейм.
Компаниялар DevOps инженерлери ким экенин ар кандай түшүнүшөт жана ресурсту тез жалдоо үчүн бул энбелгисин баарына илип коюшат. Кырдаал абдан кызык, анткени компаниялар бул адамдарга реалдуу эмес сый акыларды төлөөгө даяр, көпчүлүк учурда алар үчүн инструменттин администратору.
Демек, DevOps инженерлери кимдер?
Келгиле, анын пайда болуу тарыхынан баштайлы - Өнүгүү Операциялары күтүлгөн натыйжа катары, продукт өндүрүшүнүн ылдамдыгын жогорулатуу үчүн чакан командалардагы өз ара аракеттенүүнү оптималдаштыруунун дагы бир кадамы катары пайда болду. Идея өнүм чөйрөсүн башкарууда жол-жоболорду жана ыкмаларды билүү менен иштеп чыгуу тобун бекемдөө болгон. Башка сөз менен айтканда, иштеп чыгуучу түшүнүшү жана белгилүү бир шарттарда анын продуктусу кандай иштээрин билиши керек, анын продуктуну кантип жайылтуу керек экенин түшүнүшү керек, чөйрөнүн кандай мүнөздөмөлөрү натыйжалуулугун жакшыртуу үчүн жөнгө салынышы керек. Ошентип, бир нече убакыт бою DevOps ыкмасы менен иштеп чыгуучулар пайда болду. DevOps иштеп чыгуучулары алардын иш-аракеттерин жана өндүрүш чөйрөсүнүн иштешин жөнөкөйлөтүү үчүн куруу жана таңгактоо скрипттерин жазышкан. Бирок, чечим архитектурасынын татаалдыгы жана инфраструктуранын компоненттеринин өз ара таасири убакыттын өтүшү менен чөйрөлөрдүн иштешин начарлай баштады; ар бир итерация менен белгилүү бир компоненттерди барган сайын тереңирээк түшүнүү талап кылынган, бул кошумча иштеп чыгуучунун өндүрүмдүүлүгүн төмөндөткөн. Белгилүү бир тапшырма үчүн компоненттерди жана тюнинг системаларын түшүнүүгө кеткен чыгымдар. Иштеп чыгуучунун өздүк наркы өстү, аны менен бирге буюмдун баасы, командадагы жаңы иштеп чыгуучуларга талаптар кескин секирип кетти, анткени алар да өнүгүүнүн "жылдызынын" милдеттерин жабуу керек болчу жана, албетте, "жылдыздар" азайып калды. жана азыраак жеткиликтүү. Белгилей кетчү нерсе, менин тажрыйбам боюнча, бир нече иштеп чыгуучулар операциялык тутумдун өзөгү тарабынан пакеттерди иштетүүнүн өзгөчөлүктөрүнө, пакеттерди маршрутташтыруу эрежелерине жана хосттун коопсуздук аспектилерине кызыкдар. Логикалык кадам ушуну жакшы билген администраторду тартуу жана ага окшош милдеттерди жүктөө болду, бул анын тажрыйбасынын аркасында ошол эле көрсөткүчтөргө «жылдыз» иштеп чыгуунун наркына салыштырмалуу төмөн баада жетишүүгө мүмкүндүк берди. Мындай администраторлор бир командага жайгаштырылган жана анын негизги милдети бул командага бөлүнгөн ресурстар менен белгилүү бир команданын эрежелерине ылайык, сыноо жана өндүрүш чөйрөлөрүн башкаруу болгон. Чындыгында, DevOps көпчүлүктүн аң-сезиминде ушундай пайда болду.
Жарым-жартылай же толугу менен, убакыттын өтүшү менен, бул системалык администраторлор иштеп чыгуу чөйрөсүндөгү бул конкреттүү команданын муктаждыктарын түшүнө башташты, иштеп чыгуучулар жана тестерлер үчүн жашоону кантип жеңилдетүү керек, кантип жаңыртуу керек жана жума күнү түнөп калбоо керек. офис, жайгаштыруу каталарын оңдоо. Убакыт өттү, эми "жылдыздар" иштеп чыгуучулар эмнени каалап жатканын түшүнгөн системалык администраторлор болушту. Таасирди азайтуу үчүн башкаруунун утилиталары чыга баштады, бардыгы OS деңгээлин изоляциялоонун эски жана ишенимдүү ыкмаларын эстеп калышты, бул коопсуздукка, тармак бөлүгүн башкарууга жана хост конфигурациясына талаптарды минималдаштырууга мүмкүндүк берди. бүтүндөй жана натыйжада жаңы "жылдыздарга" талаптарды азайтат.
"Сонун" нерсе пайда болду - докер. Эмне үчүн керемет? Ооба, chroot же түрмөдө изоляцияны түзүү, ошондой эле OpenVZ сыяктуу эле, ОС боюнча тривиалдуу эмес билимди талап кылгандыктан, утилита белгилүү бир хостто обочолонгон тиркеме чөйрөсүн түзүүгө мүмкүндүк берет. кайра өнүгүү тизгинин үстүнөн, жана системалык администратор бир гана хост менен башкара алат, анын коопсуздугун жана жогорку жеткиликтүүлүгүн камсыз кылуу - логикалык жөнөкөйлөтүү. Бирок прогресс бир жерде токтобойт жана системалар кайра барган сайын татаалдашып баратат, уламдан-улам көп компоненттер бар, бир хост системанын керектөөлөрүнө жооп бербейт жана кластерлерди куруу керек, биз кайрадан системалык администраторлорго кайрылып жатабыз, алар бул системаларды курууга жөндөмдүү.
Цикл артынан цикл, иштеп чыгууну жана/же башкарууну жөнөкөйлөткөн ар кандай системалар пайда болот, стандарттуу процесстен четтөө керек болгонго чейин колдонууга оңой болгон оркестрдик системалар пайда болот. Микросервис архитектурасы да жогоруда сүрөттөлгөн нерселердин баарын жөнөкөйлөтүү максатында пайда болгон - мамилелер азыраак, башкаруу оңой. Мен өзүмдүн тажрыйбамда микросервис архитектурасын толук таппадым, 50-50-50 пайыз микросервис, кара кутулар кирди, кайра иштетилди, калган 50ү жыртык монолит, кызматтар башкалардан өзүнчө иштей албайт. компоненттер. Мунун баары кайра иштеп чыгуучулардын да, администраторлордун да билим деңгээлине чектөөлөрдү киргизди.
Белгилүү бир ресурстун эксперттик билим деңгээлиндеги ушул сыяктуу "селкинүүлөр" бүгүнкү күнгө чейин уланууда. Бирок биз бир аз чегинебиз, баса белгилей турган көп жагдайлар бар.
Build Engineer/Release Engineer
Программалык камсыздоону куруу процесстерин жана релиздерин стандартташтыруунун каражаты катары пайда болгон өтө адистештирилген инженерлер. Кеңири жайылган Agileди киргизүү процессинде, алар суроо-талапка ээ болбой калды окшойт, бирок бул андай эмес. Бул адистештирүү өнөр жайлык масштабда программалык камсыздоону чогултууну жана жеткирүүнү стандартташтыруу каражаты катары пайда болгон, б.а. бардык компания буюмдар үчүн стандарттык ыкмаларды колдонуу. DevOps пайда болушу менен, иштеп чыгуучулар өз функцияларын жарым-жартылай жоготушту, анткени иштеп чыгуучулар продуктуну жеткирүүгө даярдай башташкан жана инфраструктуранын өзгөрүшүн жана сапатын эске албай, мүмкүн болушунча тез жеткирүү ыкмасын эске алганда, убакыттын өтүшү менен алар сапат стандарттарын сактоо сөзсүз түрдө жеткирүүлөрдү жайлатат, анткени өзгөрүүлөрдү токтотуу. Ошентип, акырындык менен Build/Release инженерлеринин функционалдарынын бир бөлүгү системалык администраторлордун мойнуна өттү.
Оп абдан башкача
Биз улам-улам жылып жатабыз, милдеттердин чоң спектринин болушу жана квалификациялуу кадрлардын жоктугу бизди катуу адистештирүүгө түртөт, жаандан кийинки козу карындар сыяктуу, ар кандай операциялар пайда болот:
- TechOps - enikey система администраторлору, aka HelpDesk Engineer
- LiveOps - өндүрүш чөйрөлөрү үчүн биринчи кезекте жооптуу системалык администраторлор
- CloudOps - Azure, AWS, GCP жана башкалар коомдук булуттарга адистешкен системалык администраторлор.
- PlatOps/InfraOps/SysOps - инфраструктура системасынын администраторлору.
- NetOps - тармак администраторлору
- SecOps - маалыматтык коопсуздук боюнча адистешкен системалык администраторлор - PCI ылайыктуулугу, КМШ шайкештиги, патчинг ж.б.
DevOps (теорияда) - иштеп чыгуу, тестирлөө процессинин бардык процесстерин өз көзү менен түшүнгөн, продукт архитектурасын түшүнгөн, коопсуздук тобокелдиктерин баалай алган, ыкмаларды жана автоматташтыруу куралдарын, жок эле дегенде, жогорку деңгээлде билген адам. деңгээл, буга кошумча, ошондой эле кайра иштетүүгө чейинки жана кийинки процессти түшүнөт. Операциялардын да, өнүгүүнүн да жактоочусу катары иш алып барууга жөндөмдүү адам, бул эки түркүктүн ортосундагы жагымдуу кызматташууга мүмкүндүк берет. Командалардын ишин пландаштыруу жана кардарлардын күтүүлөрүн башкаруу процесстерин түшүнөт.
Мындай иш жана милдеттерди аткаруу үчүн, бул адам иштеп чыгуу жана сыноо процесстерин гана эмес, ошондой эле продукт инфраструктурасын башкаруу, ошондой эле ресурстарды пландаштыруу үчүн каражаттарга ээ болушу керек. Бул түшүнүктөгү DevOps ITде да, R&Dде да, жада калса PMOдо да жайгаштырылышы мүмкүн эмес; ал бардык бул чөйрөлөрдө таасир этиши керек - компаниянын техникалык директору, башкы техникалык директору.
Бул сиздин компанияңызда чынбы? - Күмөнүм бар. Көпчүлүк учурларда, бул IT же R&D.
Каражаттын жетишсиздиги жана ишмердүүлүктүн ушул үч чөйрөсүнүн жок дегенде бирине таасир этүү мүмкүнчүлүгү көйгөйлөрдүн салмагын бул өзгөртүүлөр колдонуу оңой болгон жакка жылдырат, мисалы, статикага ылайык “кир” кодго байланыштуу чыгарууларга техникалык чектөөлөрдү колдонуу. анализатор системалары. Башкача айтканда, PMO функцияларды чыгаруунун катуу мөөнөтүн белгилегенде, R&D бул мөөнөттөрдүн ичинде жогорку сапаттагы натыйжаны бере албайт жана аны мүмкүн болушунча чыгарат, рефакторингди кийинчерээк калтырат, IT менен байланышкан DevOps техникалык каражаттарды колдонуу менен чыгарууну бөгөттөйт. . Кырдаалды өзгөртүүгө ыйгарым укуктардын жоктугу, жооптуу кызматкерлердин учурда, алар таасир эте албаган нерселер үчүн гипер-жоопкерчиликтин көрүнүшүнө алып келет, айрыкча, бул кызматкерлер каталарды түшүнүп, көрүп калса жана аларды кантип оңдоо керек - "Бактылуулук - наадандык", жана натыйжада бул кызматкерлердин күйүп кетиши жана жоготуу.
DevOps ресурстар рыногу
Келгиле, ар кандай компаниялардын DevOps кызматтары үчүн бир нече вакансияларды карап көрөлү.
Биз сиз менен жолугушууга даярбыз, эгерде сиз:
- Сиз Заббикске ээсиз жана Прометейдин эмне экенин билесиз;
- iptables;
- BASH PhD студенти;
- Professor Ansible;
- Linux Guru;
- Мүчүлүштүктөрдү оңдоону кантип колдонууну билүү жана иштеп чыгуучулар менен бирге тиркеме көйгөйлөрүн табуу (php/java/python);
- Маршруттук сизди истерика кылбайт;
- Системанын коопсуздугуна олуттуу көңүл буруңуз;
- "Баарын жана бардыгын" камдык көчүрмөнү сактоо, ошондой эле бул "баарын жана бардыгын" ийгиликтүү калыбына келтириңиз;
- Сиз системаны минимумдан максималдуу пайда алгыдай кылып конфигурациялоону билесиз;
- Postgres жана MySQLде уктаар алдында репликацияны орнотуу;
- CI/CDди орнотуу жана тууралоо сиз үчүн эртең мененки тамак/түшкү тамак сыяктуу эле зарыл.
- AWS менен тажрыйбага ээ болуу;
- Компания менен иштеп чыгууга даяр;
Ошондуктан:
- 1ден 6га чейин - системалык администратор
- 7 - бир аз тармактык башкаруу, ал ошондой эле системалык администраторго туура келет, Орто деңгээл
- 8 - Орто деңгээлдеги системалык администратор үчүн милдеттүү болгон бир аз коопсуздук
- 9-11 – Орто системанын администратору
- 12 — Тапшырылган милдеттерге жараша, орто системанын администратору же куруу инженери
- 13 - Виртуалдаштыруу - Орто системанын администратору же CloudOps деп аталган, каражаттарды эффективдүү пайдалануу жана техникалык тейлөөгө жүктү азайтуу үчүн белгилүү бир хостинг сайтынын кызматтары боюнча өнүккөн билим.
Бул вакансияны жыйынтыктап, биз орто/улук системалык администратор балдар үчүн жетиштүү деп айта алабыз.
Баса, Linux/Windows боюнча администраторлорду катуу бөлбөшүңүз керек. Албетте, бул эки дүйнөнүн кызматтары, системалары эки башка экенин түшүнөм, бирок бардыгынын негизи бир жана өзүн сыйлаган ар бир админ бири менен да, экинчиси менен да тааныш, тааныш болбосо дагы компетенттүү админ аны менен таанышуу кыйын эмес.
Дагы бир вакансияны карап көрөлү:
- Жогорку жүктөө системаларын куруу тажрыйбасы;
- Linux OS, жалпы системалык программалык камсыздоо жана веб стек (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) боюнча мыкты билим;
- Виртуалдаштыруу системалары (KVM, VMWare, LXC/Docker) менен иштөө тажрыйбасы;
- Скрипт тилдерин билүү;
- Тармактык протоколдук тармактардын иштөө принциптерин түшүнүү;
- каталарга чыдамдуу системаларды куруу принциптерин түшүнүү;
- Көз карандысыздык жана демилге;
Келгиле, карап көрөлү:
- 1 – Системанын улук администратору
- 2 - Бул стекке коюлган мааниге жараша - Орто/Улук система администратору
- 3 - Иш тажрыйбасы, анын ичинде, - "Кластер көтөргөн жок, бирок виртуалдык машиналарды түздү жана башкарды, бир Docker хосту бар, контейнерлерге кирүү мүмкүн эмес" дегенди билдириши мүмкүн - Ортоңку системанын администратору
- 4 - Junior System Administrator - ооба, админ эмес, тилге карабастан, негизги автоматташтыруу скрипттерин жазганды билбеген админ - enikey.
- 5 - Орто системанын администратору
- 6 – Системанын улук администратору
Кыскача айтканда - орто/улук система администратору
Дагы бир:
- Devos тажрыйбасы;
- CI/CD процесстерин түзүү үчүн бир же бир нече өнүмдөрдү колдонуу тажрыйбасы. Gitlab CI артыкчылыгы болот;
- Контейнерлер жана виртуалдаштыруу менен иштөө; Эгер сиз докерди колдонсоңуз, жакшы, бирок k8s колдонсоңуз, сонун!
- Agile командада иштөө тажрыйбасы;
- Ар кандай программалоо тилин билүү;
карап көрөлү:
- 1 - Ммм... Жигиттер эмне дейт? =) Мунун артында эмне катылганын алар өздөрү билишпейт
- 2 - Курулуш инженери
- 3 - Орто системанын администратору
- 4 - Жумшак чеберчилик, биз аны азыр эске албайбыз, бирок Agile дагы бир нерсе, бул ыңгайлуу жол менен чечмеленет.
- 5 - Өтө кенен - бул скрипт тили же түзүлгөн тил болушу мүмкүн. Кызык, мектепте Pascal жана Basic тилдеринде жазуу аларга туура келеби? =)
Бул пункт эмне үчүн системалык администратор тарабынан камтылганын түшүнүү үчүн мен 3-пунктка байланыштуу эскертүү калтыргым келет. Kubernetes - бул жөн гана оркестр, тармак драйверлерине жана виртуалдаштыруу/изоляция хостторуна түз буйруктарды бир нече буйруктарга ороп, алар менен абстракттуу байланышты түзүүгө мүмкүндүк берүүчү курал. Мисалы, "алкак куруу" Make программасын алалы, демек, мен алкак деп эсептебейм. Ооба, мен Мавенди керектүү жана кереги жок каалаган жерге түртүү модасы жөнүндө билем - Мавенди Макеге ороп, мисалы, олуттуу?
Негизи, Make бул жөн гана k8s сыяктуу компиляция, байланыш жана компиляция чөйрө буйруктарын жөнөкөйлөтүп, кабыктын үстүнөн оролгон.
Бир жолу мен OpenStack үстүндө иштөөдө k8s колдонгон жигиттен интервью алдым жана ал ага кантип кызматтарды орноткондугу жөнүндө айтып берди, бирок мен OpenStack жөнүндө сураганда, ал башкарылат, ошондой эле система тарабынан көтөрүлдү. администраторлор. OpenStack орноткон адам, анын артында кайсы платформаны колдонсо да, k8s колдоно албайт деп ойлойсузбу? =)
Бул арыз берүүчү чындыгында DevOps эмес, системалык администратор жана тагыраак айтканда, Kubernetes администратору.
Келгиле, дагы бир жолу жыйынтыктайлы - алар үчүн Орто/Улук системалык администратор жетиштүү болот.
Канча грамм салмакта
Көрсөтүлгөн бош орундар үчүн сунушталган эмгек акынын диапазону 90 миңден 200 миңге чейин
Эми мен системалык администраторлор менен DevOps инженерлеринин акчалай сыйлыктарынын ортосунда параллелдүү болгум келет.
Негизи, нерселерди жөнөкөйлөтүү үчүн, сиз иш тажрыйбасынын негизинде бааларды чачырата аласыз, бирок бул так эмес, бирок макаланын максаттары үчүн бул жетиштүү болот.
Тажрыйба:
- 3 жашка чейин - кенже
- 6 жашка чейин - орто
- 6дан ашык - улук
Кызматкерлерди издөө сайты төмөнкүлөрдү сунуш кылат:
Системалык администраторлор:
- Кенже - 2 жыл - 50 миң руб.
- Орто - 5 жыл - 70 миң руб.
- Улук - 11 жыл - 100 миң руб.
DevOps инженерлери:
- Кенже - 2 жыл - 100 миң руб.
- Орто - 3 жыл - 160 миң руб.
- Улук - 6 жыл - 220 миң руб.
"DevOps" тажрыйбасына ылайык, жок дегенде кандайдыр бир жол менен SDLCге таасир эткен тажрыйба колдонулган.
Жогоруда айтылгандардан көрүнүп тургандай, чындыгында компанияларга DevOps керек эмес, ошондой эле алар Администраторду жалдоо менен алгач пландаштырылган чыгымдардын жок дегенде 50 пайызын үнөмдөй алышат; андан тышкары, алар издеген адамдын милдеттерин так аныктай алышат. жана муктаждыкты тезирээк толтуруңуз. Милдеттерди так бөлүштүрүү кадрларга болгон талаптарды кыскартууга, ошондой эле бири-бирин кайталоонун жоктугуна байланыштуу коллективде жагымдуу кырдаалды түзүүгө мүмкүндүк берерин да эстен чыгарбоо керек. Бош орундардын басымдуу көпчүлүгү коммуналдык кызматтарга жана DevOps энбелгилерине толгон, бирок алар DevOps инженерине коюлган талаптарга негизделбейт, бир гана инструмент администраторуна суроо-талаптар.
DevOps инженерлерин окутуу процесси ошондой эле конкреттүү иштердин, утилиталардын жыйындысы менен гана чектелет жана процесстер жана алардын көз карандылыгы жөнүндө жалпы түшүнүктү бербейт. Адам AWS EKSти Terraform аркылуу, бул кластердеги Fluentd капталчасы жана AWS ELK стек менен бирдикте консолдо бир гана буйрукту колдонуп, 10 мүнөттүн ичинде орното алганы жакшы, бирок ал түшүнбөсө журналдарды кайра иштетүү принциби жана алар эмне үчүн керек, эгер сиз аларга метрикаларды кантип чогултууну жана кызматтын деградациясын көзөмөлдөөнү билбесеңиз, анда ал дагы эле кээ бир утилиталарды кантип колдонууну билген эңикей бойдон калат.
Бирок суроо-талап сунушту жаратат жана биз DevOps позициясы үчүн өтө ысып кеткен рынокту көрүп жатабыз, мында талаптар чыныгы ролго туура келбейт, бирок системалык администраторлорго көбүрөөк акча табууга мүмкүнчүлүк берет.
Анда алар кимдер? DevOps же ач көз система администраторлору? =)
Кантип жашоону улантуу керек?
Иш берүүчүлөр талаптарды так формулировкалап, керек болгондорду издеши керек жана этикеткаларды ыргытпашы керек. Сиз DevOps эмне кыларын билбейсиз - бул учурда сизге алардын кереги жок.
Жумушчулар - Үйрөнүү. Дайыма билимиңизди өркүндөтүңүз, процесстердин жалпы сүрөтүн карап, максатыңызга карай жолду байкаңыз. Сиз каалаган адам боло аласыз, болгону аракет кылуу керек.
Source: www.habr.com