Кои са DevOps?

В момента това е почти най-скъпата позиция на пазара. Усилията около инженерите «DevOps» надминават всички мислими граници, а положението е още по-лошо с опитните инженери 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 съответствие, актуализации и др.

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. Отлични познания по ОС Linuх, общосистемен софтуер и уеб стек (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, комбинирано с Fluentd sidecar в този клъстер и AWS ELK стек за система за логиране за 10 минути, използвайки само една команда в консолата. Но ако той не разбира самия принцип на обработка на логовете и защо са нужни, не знае как да събира метрики за тях и да следи деградацията на услугата, той ще бъде просто помощник, който умее да използва някои инструменти.

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

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

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

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

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

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