Кои са DevOps?

В момента това е почти най-скъпата позиция на пазара. Шумът около инженерите на „DevOps“ е извън всички възможни граници и дори по-лошо със старшите инженери на DevOps.
Работя като ръководител на отдела за интеграция и автоматизация, познайте английското декодиране - DevOps Manager. Малко вероятно е английският препис да отразява ежедневните ни дейности, но руският вариант в този случай е по-точен. Поради естеството на дейността ми е естествено да имам нужда да интервюирам бъдещи членове на екипа си, като през изминалата година през мен са минали около 50 човека, като още толкова са били отрязани на прескрин със служителите ми.

Все още търсим колеги, защото зад етикета DevOps се крие много голям слой от различни видове инженери.

Всичко написано по-долу е мое лично мнение, не е задължително да се съгласявате с него, но признавам, че ще внесе малко цвят в отношението ви към темата. Въпреки риска да изпадна в немилост, публикувам мнението си, защото смятам, че то има място.

Компаниите имат различни разбирания за това кои са инженерите на DevOps и в името на бързото наемане на ресурс те закачат този етикет на всички. Ситуацията е доста странна, тъй като компаниите са готови да плащат нереални възнаграждения на тези хора, като в повечето случаи получават администратор на инструменти за тях.

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

Да започнем с историята на появата му – Development Operations се появи като още една стъпка към оптимизиране на взаимодействието в малки екипи за увеличаване на скоростта на производство на продукта, като очаквано следствие. Идеята беше екипът за разработка да се подсили с познания за процедурите и подходите при управление на продуктовата среда. С други думи, разработчикът трябва да разбира и знае как неговият продукт работи при определени условия, трябва да разбира как да внедри своя продукт, какви характеристики на средата могат да бъдат коригирани, за да се подобри производителността. Така за известно време се появиха разработчици с подход DevOps. Разработчиците на DevOps написаха скриптове за изграждане и опаковане, за да опростят своите дейности и производителността на производствената среда. Въпреки това, сложността на архитектурата на решението и взаимното влияние на инфраструктурните компоненти с течение на времето започнаха да влошават производителността на средите; с всяка итерация се изискваше все по-задълбочено разбиране на определени компоненти, намалявайки производителността на разработчика поради допълнителните разходи за разбиране на компонентите и системите за настройка за конкретна задача. Собствените разходи на разработчика нараснаха, цената на продукта заедно с него, изискванията към новите разработчици в екипа скочиха рязко, защото те също трябваше да покрият отговорностите на „звездата“ на разработката и, естествено, „звездите“ станаха по-малко и по-малко достъпни. Също така си струва да се отбележи, че според моя опит малко разработчици се интересуват от спецификата на обработката на пакети от ядрото на операционната система, правилата за маршрутизиране на пакети и аспектите на сигурността на хоста. Логичната стъпка беше да се привлече администратор, който е запознат с това и да му се възложат подобни отговорности, което благодарение на опита му позволи да се постигнат същите показатели на по-ниска цена в сравнение с цената на „звездна“ разработка. Такива администратори бяха поставени в екип и основната му задача беше да управлява тестови и производствени среди, според правилата на конкретен екип, с ресурси, разпределени към този конкретен екип. Ето как всъщност DevOps се появи в съзнанието на мнозинството.

Частично или напълно, с течение на времето, тези системни администратори започнаха да разбират нуждите на този конкретен екип в областта на разработката, как да улеснят живота на разработчиците и тестерите, как да пуснат актуализация и да не се налага да остават през нощта в петък в офиса, коригиране на грешки при внедряването. Мина време и сега „звездите“ бяха системни администратори, които разбираха какво искат разработчиците. За да се сведе до минимум въздействието, започнаха да се появяват помощни програми за управление; всички си спомниха старите и надеждни методи за изолиране на ниво ОС, което направи възможно минимизиране на изискванията за сигурност, управление на мрежовата част и конфигурацията на хоста като цяло и в резултат на това намаляват изискванията за нови „звезди“.

Появи се „чудесно“ нещо - докер. Защо прекрасно? Да, само защото създаването на изолация в chroot или jail, както и OpenVZ, изисква нетривиално познаване на операционната система, за разлика от това, помощната програма ви позволява просто да създадете изолирана среда на приложение на определен хост с всичко необходимо вътре и на ръка отново над юздите на разработката и системният администратор може да управлява само с един хост, гарантирайки неговата сигурност и висока достъпност - логично опростяване. Но прогресът не стои неподвижен и системите отново стават все по-сложни, има все повече и повече компоненти, един хост вече не отговаря на нуждите на системата и е необходимо да се изграждат клъстери, отново се връщаме към системните администратори, които са в състояние да изгради тези системи.

Цикъл след цикъл се появяват различни системи, които опростяват разработката и/или администрирането, появяват се системи за оркестрация, които, докато не се наложи да се отклоните от стандартния процес, са лесни за използване. Архитектурата на микросервизите също се появи с цел да опрости всичко описано по-горе - по-малко връзки, по-лесно управление. Според моя опит не намерих напълно архитектура на микроуслуги, бих казал 50 на 50 - 50 процента от микроуслугите, черните кутии, влязоха, излязоха обработени, останалите 50 са разкъсан монолит, услуги, които не могат да работят отделно от другите компоненти. Всичко това отново наложи ограничения върху нивото на познания както на разработчиците, така и на администраторите.

Подобни „люлки“ в нивото на експертни познания за конкретен ресурс продължават и до днес. Но ние се отклонихме малко, има много точки, които си струва да се подчертаят.

Build Engineer/Release Engineer

Много силно специализирани инженери, които се появиха като средство за стандартизиране на процесите и изданията на софтуер. В процеса на въвеждане на широко разпространените Agile изглежда, че те са престанали да бъдат търсени, но това далеч не е така. Тази специализация се появи като средство за стандартизиране на сглобяването и доставката на софтуер в индустриален мащаб, т.е. използвайки стандартни техники за всички продукти на компанията. С появата на DevOps разработчиците частично загубиха функциите си, тъй като разработчиците бяха тези, които започнаха да подготвят продукта за доставка и предвид променящата се инфраструктура и подхода за доставка възможно най-бързо, без оглед на качеството, с течение на времето те се превърнаха в спирач на промените, тъй като спазването на стандартите за качество неизбежно забавя доставките. Така постепенно част от функционалността на инженерите на Build/Release мигрира към раменете на системните администратори.

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

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

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

DevOps е (на теория) човек, който разбира от първа ръка всички процеси на цикъла на разработка - разработка, тестване, разбира продуктовата архитектура, умее да оценява рисковете за сигурността, запознат е с подходите и инструментите за автоматизация, поне на високо ниво, в допълнение към това, също така разбира предварителна и последваща обработка.поддръжка за пускане на продукта. Човек, способен да действа като защитник както на операциите, така и на развитието, което позволява благоприятно сътрудничество между тези два стълба. Разбира процесите на планиране на работата на екипите и управление на очакванията на клиентите.

За да изпълнява този вид работа и отговорности, това лице трябва да разполага със средствата за управление не само на процесите на разработка и тестване, но и на управлението на продуктовата инфраструктура, както и планирането на ресурсите. DevOps в това разбиране не може да бъде разположен нито в ИТ, нито в R&D, нито дори в PMO; той трябва да има влияние във всички тези области - технически директор на компанията, главен технически директор.

Това вярно ли е във вашата компания? - Съмнявам се. В повечето случаи това е или ИТ, или R&D.

Липсата на средства и способност да се повлияе на поне една от тези три области на дейност ще измести тежестта на проблемите към местата, където тези промени са по-лесни за прилагане, като например прилагането на технически ограничения върху версиите във връзка с „мръсен“ код според статиката анализаторни системи. Тоест, когато PMO определя строг краен срок за пускане на функционалност, R&D не може да произведе висококачествен резултат в рамките на тези срокове и го произвежда възможно най-добре, оставяйки преработването за по-късно, DevOps, свързан с ИТ, блокира пускането чрез технически средства . Липсата на власт за промяна на ситуацията, в случай на отговорни служители, води до проява на свръхотговорност за това, върху което не могат да повлияят, особено ако тези служители разбират и виждат грешките и как да ги коригират - „Блаженството е невежество“, и като следствие до прегаряне и загуба на тези служители.

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

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

Готови сме да се срещнем с вас, ако:

1. Вие притежавате Zabbix и знаете какво е Prometheus;
2. Iptables;
3. Докторант на БАШ;
4. професор Анзибъл;
5. Linux гуру;
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 - Junior System Administrator - да, администратор, който не знае как да пише елементарни скриптове за автоматизация, независимо от езика, не е администратор - enikey.
• 5 - Среден системен администратор
• 6 – Старши системен администратор

Да обобщим - среден/старш системен администратор

Друг:

1. Devops опит;
2. Опит в използването на един или повече продукти за създаване на CI/CD процеси. Gitlab CI ще бъде предимство;
3. Работа с контейнери и виртуализация; Ако сте използвали docker, добре, но ако сте използвали k8s, страхотно!
4. Опит в работа в agile екип;
5. Владеене на всеки език за програмиране;

Да видим:

• 1 - Хм... Какво имат предвид момчетата? =) Най-вероятно те самите не знаят какво се крие зад него
• 2 - Строителен инженер
• 3 - Среден системен администратор
• 4 – Soft skill, няма да го разглеждаме засега, въпреки че Agile е друго нещо, което се интерпретира по удобен начин.
• 5 – Твърде многословен – може да е скриптов език или компилиран. Чудя се дали писането на Pascal и Basic в училище ще им отива? =)

Бих искал също така да оставя бележка относно точка 3, за да засиля разбирането защо тази точка се покрива от системния администратор. Kubernetes е просто оркестрация, инструмент, който обгръща директни команди към мрежови драйвери и хостове за виртуализация/изолация в няколко команди и ви позволява да направите комуникацията с тях абстрактна, това е всичко. Например, нека вземем „build framework“ Make, който между другото не считам за framework. Да, знам за модата да се бута Make навсякъде, където трябва и където не е необходимо - опаковане на Maven в Make, например, сериозно?
По същество Make е просто обвивка върху обвивката, опростяваща командите за компилиране, свързване и среда за компилиране, точно като k8s.

Веднъж интервюирах човек, който използва k8s в работата си върху OpenStack, и той говори за това как е разположил услуги върху него, но когато попитах за OpenStack, се оказа, че е администриран, както и повдигнат от система администратори. Наистина ли мислите, че човек, който е инсталирал OpenStack, независимо каква платформа използва зад него, не може да използва k8s? =)
Този кандидат всъщност не е DevOps, а системен администратор и, за да бъдем по-точни, администратор на Kubernetes.

Нека обобщим още веднъж – среден/старш системен администратор ще им е достатъчен.

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

Диапазонът на предложените заплати за посочените свободни позиции е 90k-200k
Сега бих искал да направя паралел между паричните награди на системните администратори и DevOps инженерите.

По принцип, за да опростите нещата, можете да разпръснете оценките на база трудов стаж, въпреки че това няма да е точно, но за целите на статията ще бъде достатъчно.

Опит:

1. до 3 години – Junior
2. до 6 години – ср
3. повече от 6 – старши

Сайтът за търсене на служители предлага:
Системни администратори:

1. Junior - 2 години - 50k rub.
2. Средно - 5 години - 70 хиляди рубли.
3. Старши - 11 години - 100k rub.

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

1. Junior - 2 години - 100k rub.
2. Средна - 3 години - 160k rub.
3. Старши - 6 години - 220k rub.

Според опита на „DevOps“ е използван опит, който поне по някакъв начин е повлиял на SDLC.

От гореизложеното следва, че всъщност компаниите нямат нужда от DevOps, както и че биха могли да спестят поне 50 процента от първоначално планираните разходи, като наемат Администратор, освен това биха могли по-ясно да дефинират отговорностите на лицето, което търсят и задоволете нуждата по-бързо. Също така не трябва да забравяме, че ясното разделение на отговорностите ни позволява да намалим изискванията към персонала, както и да създадем по-благоприятна атмосфера в екипа, поради липсата на припокриване. По-голямата част от свободните позиции са пълни с помощни програми и DevOps етикети, но те не се основават на действителните изисквания за DevOps инженер, а само на заявки за администратор на инструменти.

Процесът на обучение на инженери на DevOps също е ограничен само до набор от специфични работи, помощни програми и не осигурява общо разбиране на процесите и техните зависимости. Със сигурност е добре, когато човек може да разположи AWS EKS с помощта на Terraform, във връзка с Fluentd sidecar в този клъстер и AWS ELK стека за системата за регистриране за 10 минути, като използва само една команда в конзолата, но ако не разбира принцип на обработка на самите регистрационни файлове и за какво са необходими, ако не знаете как да събирате показатели за тях и да проследявате влошаването на услугата, тогава пак ще бъде същият enikey, който знае как да използва някои помощни програми.

Търсенето обаче създава предлагане и виждаме изключително прегрял пазар за DevOps позицията, където изискванията не отговарят на действителната роля, а само позволяват на системните администратори да печелят повече.

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

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

Работодателите трябва да формулират по-прецизно изискванията и да търсят точно тези, от които има нужда, а не да хвърлят етикети. Не знаете какво правят DevOps – в такъв случай нямате нужда от тях.

Работници - Учете. Постоянно подобрявайте знанията си, разглеждайте цялостната картина на процесите и проследявайте пътя към целта си. Можеш да станеш какъвто искаш, просто трябва да опиташ.

Източник: www.habr.com