В последно време такива обяви запълниха интернет. Независимо от приятната заплата, не може да не смущава, че вътре е написано дива ерес. В началото се предполага, че «DevOps» и «инженер» могат да бъдат някак си слепени в една дума, а след това следва случаен списък с изисквания, част от които явно са копирани от обявата на системен администратор.
В този пост искам да говоря малко за това как стигнахме до такъв живот, какво всъщност е DevOps и какво сега да правим с него.
Такива обяви могат да бъдат различно осъждани, но фактът остава: те са много и така е устроен пазарът в момента. Направихме конференция за DevOps и открито заявяваме: « — не за DevOps-инженери». Тук на много хора ще им се стори странно и дико: защо хората, които организират напълно търговско събитие, вървят против пазара. Сега всичко ще е обяснено.
За културата и процесите
Започваме с това, че DevOps не е инженерна дисциплина. Всичко започна с това, че исторически съществуващото разделение на роли не работи за качеството на продуктите. Когато програмистите само програмират, но не искат да чуят нищо за тестване — софтуерът е потънал в бъгове. Когато администраторите не се интересуват как и защо е написан софтуерът — поддръжката се превръща в ад.
Например, с описанието на разликата между системния администратор и SRE подхода към управлението на услугите Интересни изследвания бяха проведени в рамките на — видно е, че най-добрите разработчици успяват по някакъв начин да деплоят нови промени на продукция по-бързо от веднъж на час. Те тестват ръчно не повече от 10% (това е видно по Как постигат това? «Excel or die» – казва един от заглавията на отчета. За подробно обсъждане на тази статистика по отношение на тестването можете да се обърнете към кейноут на Барух Садогурски на другата ни конференция, Heisenbug.
«Когато в другарите няма съгласие,
Няма да тръгне работата им,
И от него няма да излезе работа, само мъка.
Един ден Лебедът, Ракът и Щуката…»
Какво мислите, колко от уеб-програмистите наистина разбират при какви условия работят техните приложения на продуктивната среда? Колко от тях ще отидат при администраторите и ще се опитат да разберат какво ще се случи при срив на базата данни? А колко от тях ще се обърнат към тестировчиците и ще поискат да им покажат как да пишат тестове правилно? А там съществуват и специалисти по сигурност, продукти мениджъри и още куп хора.
Основната идея на DevOps е да се установи взаимодействие между ролите и отделите. На първо място това се постига не с някакъв сложно настроен софтуер, а чрез практиката на общуването. DevOps е за култура, практика, методология и процеси. Няма такава инженерна специалност, която да отговаря на тези въпроси.
Затворен цикъл
От къде тогава се появи дисциплината 'девопс-инженерия'? Имаме версия! Идеите на DevOps се оказаха толкова добри, че станаха жертва на успеха си. Около цялата тази тема започнаха да се въртят съмнителни рекрутери и търговци на хора, които имат своя собствена атмосфера.
Представете си: вчера в Химки сте работили с шурма, а днес сте вече голям човек, старши рекрутер. Целият процес по търсене и подбор на кандидати е сложен и изисква разбиране. Да кажем, шефът на отдела казва: намери специалист по X. Добавяме към X думата 'инженер' и казваме, че задачата е решена. Нужно ли е Linux? Well, това е определено Linux-инженер, искате DevOps — DevOps-инженер. Обявата е не само заглавие, но и съдържа текст. Най-лесно е да впишете набор от ключови думи от Google, на когото му стига въображението. DevOps се състои от две думи — 'Dev' и 'Ops', следователно трябва да свържете ключови думи, свързани с разработчиците и администраторите, в едно цяло. Така появяват обяви за владеене на 42 езика за програмиране и 20 години опит с Kubernetes и Swarm едновременно. Работна схема.
Така в съзнанието на хората се укорени безсмисленият и безпощаден образ на някакъв супер герой-D"DevOps", който ще настрои всички деплой на Jenkins и ще настъпи щастие. Аха, ако всичко беше толкова просто. "А, така може да се ловят сисадмини," мисли HR-ът, "думата е модерна, ключовите думи са същите, трябва да хванат".
Търсенето поражда предлагане и всички тези неадекватни обяви за работа привлякоха лудо количество администратори, които осъзнаха: могат да правят същото, което правеха преди, но да получават многократно повече, наричайки се "девопс". Както си конфигурирал сървъри през SSH по един, така и ще продължиш да конфигурираш, но сега това е уж практика на девопс. Това е някакво сложно явление, частично свързано с недооценяването на класическите администратори и с хайпа около DevOps, но по принцип — каквото и да е, това е, което имаме.
И така, имаме търсене и предлагане. Затворен кръг, който се подхранва сам. С това се борим (включително, създавайки конференцията DevOops).
Безспорно, освен администраторите, преименували се на "девопси", има и други участници — например, професионални SRE или разработчици на Infrastructure-as-Code.
С какво се занимават хората в DevOps (в действителност)
И така, искате да напреднете в изучаването и прилагането на практиките на DevOps. Но как да го направите, в каква посока да гледате? Очевидно, не бива сляпо да се ръководите от популярни ключови думи.
Ако има работа, някой трябва да я върши. Вече установихме, че това не са "девопс инженери", така че кой? Изглежда, по-правилно е да формулираме това не в термини на длъжности, а в термини на конкретни области на работа.
На първо място, можете да се занимавате с сърцето на DevOps — процеси и култура. Културата е бавен и труден процес и, макар традиционно това да е сфера на отговорност на ръководителите, или иначе, всички участници, от програмисти до администратори, по един или друг начин участват. Преди няколко месеца Тим Листър :
"Културата се задава от основните ценности на организацията. Обикновено хората не го забелязват, но ние, работейки в консултантския бизнес през годините, сме свикнали да го забелязваме. Влизаш в компания и буквално след няколко минути започваш да чувстваш какво се случва. Ние наричаме това "аромат". Понякога този аромат наистина е хубав. Понякога предизвиква гадене. (…) Не можеш да промениш културата, преди да осъзнаваш ценностите и убежденията, които стоят зад конкретните действия. Поведението е лесно за наблюдение, а намирането на убеждения — трудно. DevOps е именно отличен пример за това как всичко става все по-сложно и сложно."
Има и техническа част от въпроса, разбира се. Ако имаш нов код за тестване, който попада при вас след месец, а в релиз излиза едва след година, и физически не е възможно да ускори всичко това — до добри практики може и да не стигнеш. Добри практики се поддържат от добри инструменти. Например, държейки в главата си концепцията Infrastructure-as-Code, можеш да използваш каквото и да било — от AWS CloudFormation и Terraform до Chef-Ansible-Puppet. Всичко това трябва да се знае и умее, и е напълно инженерна дисциплина. Важно е да не бъркаме причината с последствията: първо работите по принципите на SRE и едва след това реализирате тези принципи под формата на конкретни технически решения. В този контекст SRE е много комплексна методология, която не говори за това как да конфигурираш Jenkins, а за пет основни принципа:
- Подобряване на взаимодействието между роли и отдели
- Приемане на грешките като неразделна част от работата
- Постепенно реализиране на промени
- Използване на инструменти и друга автоматизация
- Измерване на всичко, което може да се измери
Това не е просто набор от твърдения, а конкретно . Например, на пътя на приемането на грешките ще е необходимо да се разбере с рисковете, да се измери наличността и недостъпността на услугите с нещо като SLI () и SLO (), да се научим да пишем постмортеми и да направим така, че да не е страшно да ги пишем.
В дисциплината SRE използването на инструменти е само една от частите на успеха, въпреки че е важна. Трябва постоянно да се развиваме в технически план, да следим какво се случва в света и как това може да се приложи в нашата работа.
От своя страна, сега решенията Cloud Native станаха много популярни. Според съвременното разбиране на Cloud Native Computing Foundation, технологиите Cloud Native позволяват на организациите да разработват и стартират мащабируеми приложения в съвременни динамични среди, като публични, частни и хибридни облака. Например, можем да споменем контейнери, сервисни мрежи, микросервизи, неизменяемата инфраструктура и декларативни API. Всички тези техники позволяват слабо свързани системи да останат еластични, управляеми и добре наблюдаеми. Добрата автоматизация позволява на инженерите да правят големи промени често и с предсказуеми резултати, без да превръщат това в адски труд. Всичко това се поддържа от стека от добре известни инструменти, като Docker и Kubernetes.
Това е доста сложно и разширено определение, свързано с факта, че самата област е доста сложно. От една страна, се твърди, че новите промени в системата трябва да се добавят доста лесно. От друга страна, за да се разбере как да се направи определена контейнеризирана среда, в която слабо свързани услуги живеят на софтуерно дефинирана инфраструктура и се доставят там чрез непрекъснат CI/CD, и да се изградят DevOps практики около всичко това — не е за подценяване.
Какво да правим с всичко това
Всеки решава тези проблеми по свой начин: например, можете да публикувате нормални обяви за работа, за да прекъснете порочния кръг. Можете да разберете какво означават думите, като DevOps и Cloud Native, и да ги използвате правилно и на място. Можете да се развивате в DevOps и да демонстрирате правилните подходи с примера си.
Ние организираме конференция , която предоставя възможност за по-дълбоко разбиране на нещата, за които току-що говорихме. За целта има няколко групи лекции:
- Процеси и култура;
- Инженерство на надеждността на сайта;
- Cloud Native;
Как да изберем посоката? Има един тънък момент. От една страна, DevOps е за взаимодействие и наистина се надяваме да посетите лекции от различни блокове. От друга страна, ако сте ръководител на разработка, дошъл на конференцията, за да се сосредоточите върху една конкретна задача, никой не ви ограничава — очевидно, това ще бъде блок за процесите и културата. Не забравяйте, че след конференцията ще имате записи (след попълване на обратната връзка), така че винаги ще можете да гледате по-малко важни лекции по-късно.
Очевидно е, че на самата конференция не можете да посещавате три трака едновременно, затова ние оформяме програмата така, че във всеки времеви слот да има теми по всякакъв вкус.
Остава само да разберете какво да правите, ако сте DevOps инженер! На първо място, опитайте се да определите какво всъщност правите. Обикновено с това наименование се наричат:
- Разработчици, които се занимават с инфраструктура. За вас най-подходящи ще бъдат групите от лекции по SRE и Cloud Native.
- Системни администратори. Тук е по-сложно. DevOops не е за системни администратори. За щастие, в темата за системно администриране има много страхотни конференции, книги, статии, видео в интернет и т.н. От друга страна, ако ви интересува да се развивате в разбирането на културата и процесите, изучаването на облачни технологии и подробности за живота с Cloud Native, то ще се радваме да ви видим! Помислете за следното: вие се занимавате с администриране, а какво ще правите след това? За да не се окажете в неприятна ситуация, си струва да учите вече сега.
Има още един вариант: упорствате и продължавате да твърдите, че сте точно DevOps инженер и по никакъв друг начин, каквото и да означава това. Тогава сме принудени да ви разочароваме, DevOops не е конференция за DevOps инженери!
Слайд от в Мюнхен
DevOops 2020 Москва ще се проведе на 29-30 април в Москва, билетите вече могат да бъдат .
Освен това, можете да до 8 февруари. Обърнете внимание, че при попълване на формуляра трябва да изберете целевата аудитория, на която вашата лекция ще донесе най-голяма полза (в списъка има скрито изненада).
Източник: habr.com
