Кои се DevOps?

Во моментов ова е речиси најскапата позиција на пазарот. Буката околу инженерите „DevOps“ е над сите граници што може да се замислат, а уште полошо е со високите инженери за DevOps.
Работам како шеф на одделот за интеграција и автоматизација, погодете го англиското декодирање - DevOps Manager. Малку е веројатно дека англискиот препис ги одразува нашите секојдневни активности, но руската верзија во овој случај е попрецизна. Поради природата на мојата активност, природно е што треба да интервјуирам идни членови на мојот тим, а изминатава година низ мене поминаа околу 50 луѓе, а исто толку беа отсечени на prescreen со моите вработени.

Сè уште бараме колеги, бидејќи зад етикетата DevOps се крие многу голем слој од различни видови инженери.

Сè што е напишано подолу е мое лично мислење, не мора да се согласувате со него, но признавам дека ќе додаде боја на вашиот став кон темата. И покрај ризикот да паднам во немилост, го објавувам моето мислење бидејќи верувам дека има каде да биде.

Компаниите имаат различно разбирање за тоа кои се инженерите на DevOps и, заради брзо ангажирање на ресурс, тие ја закачуваат оваа ознака на сите. Ситуацијата е прилично чудна, бидејќи компаниите се подготвени да плаќаат нереални надоместоци на овие луѓе, добивајќи, во повеќето случаи, администратор на алатки за нив.

Значи, кои се инженерите на DevOps?

Да почнеме со историјата на неговото појавување - Развојните операции се појавија како уште еден чекор кон оптимизирање на интеракцијата во малите тимови за зголемување на брзината на производство на производи, како очекувана последица. Идејата беше да се зајакне развојниот тим со познавање на процедури и пристапи во управувањето со околината на производот. Со други зборови, развивачот мора да разбере и да знае како функционира неговиот производ во одредени услови, мора да разбере како да го распореди својот производ, кои карактеристики на околината може да се прилагодат за да се подобрат перформансите. Така, некое време се појавија програмери со пристап DevOps. Програмерите на DevOps напишаа скрипти за градење и пакување за да ги поедностават нивните активности и перформансите на производната средина. Сепак, сложеноста на архитектурата на решението и меѓусебното влијание на инфраструктурните компоненти со текот на времето почнаа да ги влошуваат перформансите на опкружувањето со секое повторување, беше потребно сè подлабоко разбирање на одредени компоненти, намалувајќи ја продуктивноста на развивачот поради дополнителното; трошоците за разбирање на компонентите и системите за подесување за одредена задача. Сопствените трошоци на инвеститорот пораснаа, цената на производот заедно со неа, барањата за нови програмери во тимот нагло скокнаа, бидејќи тие исто така требаше да ги покријат одговорностите на развојната „ѕвезда“ и, нормално, „ѕвездите“ станаа помалку и помалку достапни. Исто така, вреди да се напомене дека, според моето искуство, малку програмери се заинтересирани за спецификите на обработка на пакети од кернелот на оперативниот систем, правилата за рутирање на пакети и безбедносните аспекти на домаќинот. Логичниот чекор беше да се привлече администратор кој е запознаен со ова и да му додели слични одговорности, што, благодарение на неговото искуство, овозможи да се постигнат истите показатели по пониска цена во споредба со трошоците за развој на „ѕвезда“. Таквите администратори беа сместени во тим, а неговата главна задача беше да управува со тест и производствени средини, според правилата на одреден тим, со ресурси доделени на овој конкретен тим. Така, всушност, DevOps се појави во главите на мнозинството.

Делумно или целосно, со текот на времето, овие системски администратори почнаа да ги разбираат потребите на овој конкретен тим на полето на развојот, како да им го олеснат животот на програмерите и тестерите, како да издадат ажурирање и да не мора да преноќуваат во петок во канцеларијата, исправајќи ги грешките при распоредувањето. Помина времето, а сега „ѕвездите“ беа системски администратори кои разбраа што сакаат програмерите. Со цел да се минимизира влијанието, сите се сеќаваа на старите и сигурни методи за изолирање на нивото на ОС, што овозможи да се минимизираат барањата за безбедност, управување со мрежниот дел и конфигурацијата на домаќинот; целина и, како резултат на тоа, намалување на барањата за нови „ѕвезди“.

Се појави „прекрасна“ работа - докер. Зошто прекрасно? Да, само затоа што создавањето изолација во chroot или затвор, како и OpenVZ, бараше нетривијално познавање на оперативниот систем, за разлика од тоа, алатката ви овозможува едноставно да креирате изолирана околина за апликација на одреден домаќин со се што е потребно внатре и рака повторно над уздите на развојот, а администраторот на системот може да управува само со само еден домаќин, обезбедувајќи ја неговата безбедност и висока достапност - логично поедноставување. Но, напредокот не застанува и системите повторно стануваат сè покомплексни, има се повеќе и повеќе компоненти, еден хост повеќе не ги задоволува потребите на системот и неопходно е да се градат кластери, повторно се враќаме на системските администратори кои се способни да ги градат овие системи.

Циклус по циклус, се појавуваат различни системи кои го поедноставуваат развојот и/или администрацијата, се појавуваат системи за оркестрација, кои, додека не треба да отстапите од стандардниот процес, се лесни за употреба. Се појави и микросервис архитектура со цел да се поедностави сè што е опишано погоре - помалку врски, полесни за управување. Според моето искуство, не најдов целосно микросервисна архитектура, би рекол 50 до 50 - 50 проценти од микросервисите, црните кутии, влегле, излегле обработени, другите 50 се скинат монолит, услугите не можат да работат одделно од другите компоненти. Сето ова повторно наметна ограничувања на нивото на знаење и на програмерите и на администраторите.

Слични „нишалки“ во нивото на стручно знаење за одреден ресурс продолжуваат до ден-денес. Но, ние малку оттргнуваме, има многу точки што вреди да се истакнат.

Инженер за градење/инженер за ослободување

Многу високо специјализирани инженери кои се појавија како средство за стандардизирање на процесите и изданија на софтвер за градење. Во процесот на воведување на широко распространета Agile, се чини дека тие престанаа да бидат на побарувачката, но тоа е далеку од случајот. Оваа специјализација се појави како средство за стандардизирање на склопувањето и испораката на софтвер во индустриски размери, т.е. користејќи стандардни техники за сите производи на компанијата. Со доаѓањето на DevOps, програмерите делумно ги загубија своите функции, бидејќи програмерите беа тие кои почнаа да го подготвуваат производот за испорака, а со оглед на променливата инфраструктура и пристапот за испорака што е можно побрзо без оглед на квалитетот, со текот на времето тие се претворија во спречување на промените, бидејќи почитувањето на стандардите за квалитет неизбежно ги забавува испораките. Така, постепено, дел од функционалноста на инженерите за Build/Release мигрираше на рамениците на системските администратори.

Операциите се толку различни

Продолжуваме понатаму и повторно присуството на голем опсег на одговорности и недостатокот на квалификуван персонал не турка кон строга специјализација, како печурки по дожд, се појавуваат различни операции:

• TechOps - системски администратори на enikey познат како HelpDesk Engineer
• LiveOps - системски администратори првенствено одговорни за производните средини
• CloudOps - системски администратори специјализирани за јавни облаци Azure, AWS, GCP, итн.
• PlatOps/InfraOps/SysOps - администратори на инфраструктурни системи.
• NetOps - мрежни администратори
• SecOps - системски администратори специјализирани за безбедност на информации - усогласеност со PCI, усогласеност со CIS, закрпи итн.

DevOps е (теоретски) лице кое од прва рака ги разбира сите процеси на развојниот циклус - развој, тестирање, ја разбира архитектурата на производот, може да ги процени безбедносните ризици, запознаен е со пристапите и алатките за автоматизација, барем на високо ниво. ниво, покрај ова, ја разбира и поддршката за издавање на производот пред и по обработката. Личност способна да дејствува како застапник и за операции и за развој, што овозможува поволна соработка помеѓу овие два столба. Ги разбира процесите на планирање на работата од страна на тимовите и управување со очекувањата на клиентите.

За извршување на ваков вид на работа и одговорности, ова лице мора да има средства да управува не само со процесите на развој и тестирање, туку и со управувањето со инфраструктурата на производите, како и со планирањето на ресурсите. DevOps во ова разбирање не може да се наоѓа ниту во ИТ, ниту во истражување и развој, па дури и во PMO, тоа мора да има влијание во сите овие области - техничкиот директор на компанијата, главен технички директор;

Дали е ова вистина во вашата компанија? - Се сомневам. Во повеќето случаи, ова е или ИТ или истражување и развој.

Недостатокот на средства и способноста да се влијае на барем една од овие три области на активност ќе ја префрли тежината на проблемите кон онаму каде што овие промени полесно се применуваат, како што е примената на технички ограничувања за изданија во врска со „валканиот“ код според статички системи за анализатор. Односно, кога PMO поставува строг рок за објавување на функционалноста, R&D не може да произведе висококвалитетен резултат во овие рокови и го произведува најдобро што може, оставајќи го рефакторирањето за подоцна, DevOps поврзани со ИТ го блокираат објавувањето со технички средства . Недостигот на овластување за промена на ситуацијата, кај одговорните вработени, доведува до манифестација на хиперодговорност за она на што не можат да влијаат, особено ако овие вработени ги разбираат и гледаат грешките и како да ги поправат - „Блаженството е незнаење“. а како последица на исцрпеност и загуба на овие вработени.

Пазар на ресурси на DevOps

Ајде да погледнеме неколку слободни работни места за позиции во DevOps од различни компании.

Подготвени сме да се сретнеме со вас доколку:

1. Вие поседувате Zabbix и знаете што е Прометеј;
2. Iptables;
3. БАШ докторант;
4. Професор Ансибл;
5. Линукс Гуру;
6. Знајте како да користите дебагирање и наоѓајте проблеми со апликациите заедно со програмерите (php/java/python);
7. Рутирањето не ве прави хистерични;
8. Обрнете значително внимание на безбедноста на системот;
9. Направете резервна копија „сè и сè“, а исто така успешно вратете го ова „сè и сè“;
10. Знаете како да го конфигурирате системот на таков начин што ќе го извлечете максимумот од минимумот;
11. Поставете репликација пред спиење на Postgres и MySQL;
12. Поставувањето и прилагодувањето на CI/CD е потребно за вас како појадок/ручек/вечера.
13. Имајте искуство со AWS;
14. Подготвен за развој со компанијата;

Значи:

• од 1 до 6 - системски администратор
• 7 - малку мрежна администрација, која исто така се вклопува во системскиот администратор, средно ниво
• 8 - малку безбедност, што е задолжително за системски администратор од средно ниво
• 9-11 – Администратор на среден систем
• 12 — Во зависност од доделените задачи, или среден системски администратор или инженер за градење
• 13 - Виртуелизација - Среден системски администратор, или таканаречениот CloudOps, напредно познавање на услугите на одредена локација за хостирање, за ефикасно користење на средствата и намалување на оптоварувањето на одржување

Сумирајќи го ова слободно работно место, можеме да кажеме дека на момците им е доволен среден/постар системски администратор.

Патем, не треба силно да ги делите администраторите на Linux/Windows. Се разбира, разбирам дека услугите и системите на овие два света се различни, но основата за сите е иста и секој администратор кој се почитува себеси е запознаен и со едниот и со другиот, па дури и ако не е запознаен, ќе не е тешко за компетентен админ да се запознае со тоа.

Да разгледаме уште едно слободно работно место:

1. Искуство во изградба на системи со големо оптоварување;
2. Одлично познавање на Linux OS, општ системски софтвер и веб стек (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Искуство со системи за виртуелизација (KVM, VMWare, LXC/Docker);
4. Познавање на јазици за скриптирање;
5. Разбирање на принципите на работа на мрежните протоколски мрежи;
6. Разбирање на принципите на градење системи толерантни на грешки;
7. Независност и иницијатива;

Ајде да погледнеме:

• 1 – Виш системски администратор
• 2 - Во зависност од значењето што е ставено во овој стек - среден/постар системски администратор
• 3 - Работно искуство, вклучително, може да значи - „Кластерот не подигна, туку создаде и управуваше со виртуелни машини, имаше еден домаќин Docker, пристапот до контејнерите не беше достапен“ - Администратор на среден систем
• 4 - Помлад системски администратор - да, админ кој не знае да пишува основни скрипти за автоматизација, без разлика на јазикот, а не админ - enikey.
• 5 - Среден системски администратор
• 6 – Виш системски администратор

Да резимираме - среден/постар системски администратор

Друг:

1. Devops искуство;
2. Искуство во користење на еден или повеќе производи за креирање CI/CD процеси. Gitlab CI ќе биде предност;
3. Работа со контејнери и виртуелизација; Ако сте користеле docker, добро, но ако сте користеле k8s, одлично!
4. Искуство со работа во агилен тим;
5. Познавање на кој било програмски јазик;

Ајде да видиме:

• 1 - Хм... Што мислат момците? =) Најверојатно тие самите не знаат што се крие зад тоа
• 2 - Градежен инженер
• 3 - Среден системски администратор
• 4 - Мека вештина, засега нема да ја разгледуваме, иако Agile е друга работа што се толкува на начин што е пригоден.
• 5 - Премногу опширен - може да биде јазик за скриптирање или компајлиран. Се прашувам дали ќе им одговара пишувањето на Pascal и Basic на училиште? =)

Исто така, би сакал да оставам забелешка во врска со точка 3 со цел да го зајакнам разбирањето зошто оваа точка е покриена од администраторот на системот. Kubernetes е само оркестрација, алатка која ги обвиткува директните команди до мрежните драјвери и хостовите за виртуелизација/изолација во неколку команди и ви овозможува да ја направите комуникацијата со нив апстрактна, тоа е сè. На пример, да го земеме 'build frame' Make, што, патем, јас не го сметам за рамка. Да, знам за модата на туркање Make anywhere, каде што е потребно и не е потребно - завиткување на Maven во Маке, на пример, сериозно?
Во суштина, Make е само обвивка над обвивката, поедноставувајќи ги командите за компилација, поврзување и компилација на околината, исто како k8s.

Еднаш, интервјуирав еден дечко кој користеше k8 во својата работа на врвот на OpenStack, и тој зборуваше за тоа како распоредувал услуги на него, меѓутоа, кога прашав за OpenStack, се покажа дека е администриран, како и подигнат од системот администраторите. Дали навистина мислите дека човек кој има инсталирано OpenStack, без разлика каква платформа користи зад себе, не може да користи k8s =)
Овој апликант всушност не е DevOps, туку системски администратор и, поточно, администратор на Kubernetes.

Да резимираме уште еднаш - ќе им биде доволен среден/постар системски администратор.

Колку да тежи во грамови

Опсегот на предложени плати за посочените слободни работни места е 90-200 илјади
Сега би сакал да направам паралела помеѓу паричните награди на системските администратори и инженерите на DevOps.

Во принцип, за да се поедностават работите, можете да ги расфрлате оценките врз основа на работното искуство, иако тоа нема да биде точно, но за потребите на статијата ќе биде доволно.

Искуство:

1. до 3 години – Јуниор
2. до 6 години – среден
3. повеќе од 6 – Сениор

Веб-страницата за пребарување на вработени нуди:
Системски администратори:

1. Јуниор - 2 години - 50k Бришење.
2. Среден - 5 години - 70k Бришење.
3. Постари - 11 години - 100 илјади Бришење.

Инженери за DevOps:

1. Јуниор - 2 години - 100k Бришење.
2. Среден - 3 години - 160k Бришење.
3. Постари - 6 години - 220 илјади Бришење.

Според искуството на „DevOps“, беше искористено искуство кое барем некако влијаеше на SDLC.

Од горенаведеното произлегува дека всушност на компаниите не им требаат DevOps, а исто така би можеле да заштедат најмалку 50 проценти од првично планираните трошоци со ангажирање на Администратор, а потоа и појасно да ги дефинираат одговорностите на лицето што го бараат и побрзо пополнете ја потребата. Исто така, не треба да заборавиме дека јасната поделба на одговорностите ни овозможува да ги намалиме барањата за персонал, како и да создадеме поповолна атмосфера во тимот, поради отсуството на преклопувања. Огромното мнозинство на слободни работни места се полни со комунални услуги и етикети за DevOps, но тие не се засноваат на реалните барања за инженер за DevOps, туку само барања за администратор на алатки.

Процесот на обука на инженерите на DevOps, исто така, е ограничен само на збир на специфични работи, комунални услуги и не обезбедува општо разбирање на процесите и нивните зависности. Сигурно е добро кога некое лице може да распореди AWS EKS користејќи Terraform, во врска со Fluentd страничната лента во овој кластер и стекот AWS ELK за системот за логирање за 10 минути, користејќи само една команда во конзолата, но ако не го разбира принципот на обработка на самите дневници и за што се потребни, ако не знаете како да собирате метрика на нив и да ја следите деградацијата на услугата, тогаш сепак ќе биде истиот enikey кој знае да користи некои комунални услуги.

Побарувачката, сепак, создава понуда и гледаме екстремно прегреан пазар за позицијата DevOps, каде што барањата не одговараат на вистинската улога, туку само им дозволуваат на системските администратори да заработат повеќе.

Па кои се тие? DevOps или алчни системски администратори? =)

Како да продолжите да живеете?

Работодавците треба попрецизно да ги формулираат барањата и да ги бараат токму оние кои се потребни, а не да фрлаат етикети. Не знаете што прават DevOps - не ви требаат во тој случај.

Работници - Научете. Постојано подобрувајте го вашето знаење, погледнете ја целокупната слика на процесите и следете го патот до вашата цел. Можете да станете кој сакате, само треба да се обидете.

Извор: www.habr.com