Кои са DevOps?

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

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

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

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

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

Нека започнем с историята на появата — Development Operations се появи като още една стъпка към оптимизацията на взаимодействието в малки екипи за повишаване на скоростта на производството на продукта, като очаквано следствие. Идеята беше да се засили екипът за разработка с познания за процедурите и подходите в управлението на продуктова среда. С други думи, разработчикът трябва да разбира и знае как работи продуктът му при определени условия, трябва да знае как да внедри продукта, какви характеристики на средата да настрои, за да повиши производителността. Така, за известно време, се появиха разработчици с DevOps подход. DevOps разработчиците пишеха скриптове за компилация и опаковка, за да улеснят своята дейност и работоспособността на продуктивната среда. Въпреки това, сложността на архитектурата на решенията и взаимното влияние на компонентите на инфраструктурата с времето започна да влошава работните показатели на средите, като с всяка итерация се изискваха все по-дълбоки познания за конкретни компоненти, което намаляваше производителността на самия разработчик заради допълнителните разходи по разбирането на компонентите и настройки на системите за конкретна задача. Собствената стойност на разработчика растеше, стойността на продукта заедно с нея, изискванията към новите разработчици в екипа драстично нарастваха, тъй като им беше необходимо също да покриват задълженията на "звездата" на разработката и, естествено, "звезди" ставаха все по-малко достъпни. Също така е важно да се отбележи, че, от моя опит, малко разработчици се интересуват от спецификата на обработката на пакети от ядрото на операционната система, правилата за маршрутизиране на пакетите, аспектите на сигурността на хоста. Логичната стъпка беше да се привлече администратор, който е запознат точно с това и да се възложат подобни задължения на него, което, благодарение на неговия опит, позволи да се постигнат същите показатели с по-ниска стойност в сравнение със стойността на "звездата" на разработката. Такива администратори бяха поставяни в екипа и основната му задача беше управлението на тестови и продуктивни среди, на правилата конкретно вземана от екипа, с ресурсите, които бяха отделени именно за този екип. Така, всъщност, се появиха DevOps в представите на мнозинството.

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

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

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

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

Build Engineer/Release Engineer

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

Ops’ите са толкова различни

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

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

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

За да изпълнява подобни задължения, този човек трябва да има средства за управление не само на процесите на разработка и тестване, но и на управлението на инфраструктурата на продукта, както и на планирането на ресурсите. DevOps в това разбиране не може да бъде само в IT, нито в R&D, нито дори в PMO, той трябва да има влияние във всички тези области — технически директор на компанията, Chief Technical Officer.

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

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

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

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

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

1. Владеете Zabbix и знаете какво е Prometheus;
2. Iptables;
3. Студент по BASH;
4. Професор по Ansible;
5. Гуру по Linux;
6. Умеете да използвате дебъгера и съвместно с разработчиците откривате проблеми в приложенията (php/java/python);
7. Рутингът не предизвиква истерии у вас;
8. Обърщате значително внимание на сигурността на системата;
9. Правите бекъп на „всичко и всяко“ и успешно възстановявате това „всичко и всяко“;
10. Умеете да настроите системата така, че да извлечете максимум от минимума;
11. Настроите репликации преди да заспите на Postgres и MySQL;
12. Настройката и корекцията на CI/CD за вас е необходимост, както закуската/обяда/вечерята.
13. Имате опит с AWS;
14. Готови сте да се развивате заедно с компанията;

И така:

• от 1 до 6 — системен администратор
• 7 — малко мрежово администриране, което също свързва сис админа от ниво Middle
• 8 — малко сигурност, което е задължително за сис админа от ниво Middle
• 9-11 — Middle System Administrator
• 12 — В зависимост от поставените задачи или Middle System Administrator, или Build Engineer
• 13 — Виртуализация — Middle System Administrator, или т.нар. CloudOps, с разширени знания именно на услугите на конкретната хостинг платформа, за ефективно използване на финансовите средства и намаляване на натоварването по обслужването

Обобщавайки по тази обява, можем да кажем, че на момчетата им трябва достатъчно Middle/Senior System Administrator.

Между другото, не бива да разделяте администраторите строго на Linux/Windows. Разбирам, че услугите и системите на тези два свята се различават, но основата е една и всеки уважаващ себе си администратор познава и двете, а дори и да не е запознат, за грамотния администратор не би било трудно да се запознае с темата.

Разгледайме друга обява:

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

Разглеждаме:

• 1 — Senior System Administrator
• 2 — В зависимост от смисъла, вложен в този стек — Middle/Senior System Administrator
• 3 — Опитът може да означава и следното: "Клъстер не съм вдигал, но съм създавал и управлявал виртуалки, имал съм един Docker хост, достъп до контейнерите натий." — Middle System Administrator
• 4 — Младши системен администратор — да, администратор, който не умее да пише елементарни скриптове за автоматизация, независимо от езика, не е администратор — техник.
• 5 — Среден системен администратор
• 6 — Старши системен администратор

Резюмирайки — Среден/Старши системен администратор

Още едно:

1. Опит в DevOps;
2. Опит в използването на един или повече продукти за създаване на CI/CD процеси. GitLab CI е предимство;
3. Работа с контейнери и виртуализация; Ако сте използвали Docker – добре, а ако K8s – отлично!
4. Опит в Agile екип;
5. Знание на какъвто и да е програмен език;

Нека видим:

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

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

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

Резюмираме отново — Среден/Старши системен администратор ще им е достатъчно.

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

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

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

Опит:

1. до 3 години — Junior
2. до 6 години — Middle
3. повече от 6 години — Senior

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

1. Junior — 2 години — 50k руб.
2. Middle — 5 години — 70k руб.
3. Senior — 11 години — 100k руб.

DevOps инженери:

1. Junior — 2 години — 100k руб.
2. Middle — 3 години — 160k руб.
3. Senior — 6 години — 220k руб.

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

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

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

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

Така че, кои са те? DevOps специалисти или алчни системни администратори? =)

Как да продължим напред?

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

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

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