В последно време такива обяви запълват интернет. Въпреки красивата заплата, не може да не смущава, че вътре е написана дива глупост. Първоначално предполага се, че "DevOps" и "инженер" могат по някакъв начин да бъдат слепени заедно в една дума, а след това следва произволен списък с изисквания, част от които очевидно са копирани от обявата за системен администратор.
В този пост искам малко да поговоря за това как стигнахме до състояние, в което се намираме, какво всъщност е DevOps и какво да правим с това сега.
Тези обяви могат да бъдат осъждани по всякакъв начин, но факта остава факта: те са много и такъв е пазарът в момента. Ние направихме DevOps конференция и открито заявяваме: „ — не за DevOps инженери“. Тук на много хора ще им се стори странно и лудо: защо хората, които организират напълно комерсиално събитие, действат против пазара. Сега всичко ще стане ясно.
За културата и процесите
Започваме с това, че DevOps не е инженерна дисциплина. Всичко започна от историческия разрив по роли, който не работи за качеството на продуктите. Когато програмистите само програмират, но не искат да чуят нищо за тестване — софтуерът е пълен с бъгове. Когато администраторите не им пука как и защо е написан софтуерът — поддръжката става ад.
Например, с описанието на разликата между подхода на системния администратор и SRE към управление на услуги . Интересни изследвания са проведени в рамките на — видно е, че най-добрите разработчици по някакъв начин успяват да внедряват нови промени в продукция по-бързо от веднъж на час. Те също така не тестват на ръка повече от 10% (това се вижда от ). Как успяват да го постигнат? „Excel или смърт“ - казва един от заглавията на отчета. За подробна дискусия по тази статистика в контекста на тестването можете да се обърнете към keynote-a на Барух Садогурски на друга наша конференция, Heisenbug.
„Когато в другарите няма единство,
Техният бизнес няма да върви,
И от него ще излезе нещо, само мъка.
Един ден Лебед, Рак и Щука…“
Как мислите, коя част от уеб програмистите наистина разбирае в какви условия работят техните приложения в продукция? Колко от тях ще отидат при администраторите и ще се опитат да разберат какво ще стане при срив на базата данни? А колко от тях ще отидат при тестерите и ще поискат да ги научат как да пишат тестове? А там също така има и специалисти по безопасността, продуктови мениджъри и още много хора.
Основната идея на DevOps е да установи взаимодействие между ролите и отделите. Първо, това се постига не с хитро настроен софтуер, а с практиката на комуникацията. DevOps е за култура, практика, методология и процеси. Не съществува такава инженерна специалност, която да отговаря на тези въпроси.
Замкнат кръг
От къде дойде дисциплината "девопс-инженерство"? Имаме версия! Идеите на DevOps се оказаха толкова добри, че станаха жертви на собствения си успех. Около цялата тази тема започнаха да се трупат мътни рекрутъри и търговци на хора, които имат собствена атмосфера.
Представете си: вчера в Химки правехте шаурма, а днес вече сте голям човек, старши рекрутер. Целият процес на търсене и подбор на кандидати е сложен, трябва да се разбере. Да речем, шефът на отдела казва: намери специалист по X. Прибавяме думата "инженер" към X и работата е свършена. Нужен ли е Linux? Тогава, това определено е Linux-инженер, искате DevOps — DevOps инженер. Обявата не се състои само от заглавие, но вътре трябва да се впише и някакъв текст. Най-просто е да се впишат набор от ключови думи от Google, колкото фантазията стигне. DevOps се състои от две думи — "Dev" и "Ops", значи трябва да се съчетаят ключови думи, свързани с разработчици и администратори, всичко в една купа. Така се появяват обяви за владеене на 42 програмен език и 20 години опит едновременно с Kubernetes и Swarm. Работната схема.
По този начин в съзнанието на хората се утвърди безсмисленият и безмилостен образ на супергероя-"девопс", който ще настройи проектите на 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, а за пет основни принципа:
- Подобряване на взаимодействието между ролите и отделите
- Приемане на грешките като неотменима част от работата
- Постепенно осъществяване на промените
- Използване на инструменти и друга автоматизация
- Измерване на всичко, което може да бъде измерено
Това не е просто някакъв набор от твърдения, а конкретно . Например, по пътя към приемане на грешките ще трябвa да се справиш с рисковете, да измериш наличността и недостъпността на услугите с помощта на нещо като SLI () и SLO (), да научиш как да пишеш постмортеми и да направиш така, че да не е страшно да ги пишеш.
В дисциплината SRE използването на инструменти е само една от частите на успеха, въпреки че немаловажна. Трябва постоянно да се развиваме технически, да наблюдаваме какво се случва в света и как това може да бъде приложено в работата ни.
От своя страна, решенията Cloud Native в момента станаха много популярни. Според съвременния подход на Cloud Native Computing Foundation, технологиите Cloud Native позволяват на организациите да разработват и стартират мащабируеми приложения в съвременни динамични среди, като публични, частни и хибридни облаци. Пример за това са контейнерите, сервис-меши, микросервизи, неизменяемата инфраструктура и декларативните API. Всички тези техники позволяват на слабо свързани системи да остават еластични, управляеми и добре наблюдавани. Добрата автоматизация позволява на инженерите да правят големи промени често и с предсказуеми резултати, без да се превръща в адски труд. Всичко това се поддържа от стек от известни инструменти, като Docker и Kubernetes.
Това е доста сложно и разпространено определение, тъй като и областта е доста сложна. От една страна се твърди, че новите промени в тази система трябва да се добавят сравнително лесно. От друга страна, за да разберем как да създадем контейнеризирана среда, в която слабо свързаните услуги функционират на инфраструктура, определяна от софтуер, и преминават там чрез непрекъснато CI/CD, и да изградим DevOps практики около всичко това — не е нужно да бъдат само на теория.
Какво да направим с всичко това
Всеки решава тези проблеми по свой начин: например, може да обяви нормални работни места, за да прекъсне затворения цикъл. Може да разберем какво значат думите като DevOps и Cloud Native и да ги използваме правилно и на място. Може да се развиваме в DevOps и с личния си пример да демонстрираме правилните подходи.
Извършваме конференция , която предоставя възможност да се задълбочим в нещата, за които току-що говорихме. За тази цел има няколко групи доклади:
- Процеси и култура;
- Site Reliability Engineering;
- Cloud Native;
Как да изберете къде да отидете? Има един фин нюанс. От една страна, DevOps е свързано с взаимодействие, и ние наистина ви насърчаваме да присъствате на лекции от различни секции. От друга страна, ако сте ръководител на разработката, който идва на конференцията, за да се фокусира върху една конкретна задача, никой не ви ограничава — очевидно това ще бъде секцията за процеси и култура. Не забравяйте, че след конференцията ще получите записите (след попълване на формата за обратна връзка), така че винаги можете да гледате по-малко важните лекции по-късно.
Очевидно е, че на самата конференция не можете да присъствате на три потока едновременно, затова ние формулираме програмата така, че в всяко времево слот да има теми за всеки вкус.
Остава само да разберете какво да правите, ако сте DevOps инженери! Първо, опитайте да определите с какво всъщност се занимавате. Обикновено с това наименованието се свързва:
- Разработчици, които се занимават с инфраструктура. За вас най-подходящи ще бъдат групите лекции за SRE и Cloud Native.
- Системни администратори. Тук е по-сложно. DevOops не е свързано със системно администриране. За щастие, има много отлични конференции, книги, статии, видеа в интернет и т.н. на тема системно администриране. От друга страна, ако ви интересува да се развивате в разбирането на културата и процесите, изучаването на облачни технологии и детайлите от живота с Cloud Native, ние с удоволствие ще ви видим! Помислете за това: занимавате се с администриране, а какво ще правите след това? За да не се окажете неочаквано в неприятна ситуация, е добре да учите вече сега.
Има и още един вариант: упорствате и продължавате да твърдите, че сте точно DevOps инженер и по никакъв начин, каквото и да означава това. Тогава сме принудени да ви разочароваме, DevOops не е конференция за DevOps инженери!
Слайд от в Мюнхен
DevOops 2020 Москва ще се проведе на 29-30 април в Москва, билети вече могат да се .
Освен това можете до 8 февруари. Обърнете внимание, че при попълване на формата трябва да изберете целевата аудитория, на която вашата лекция ще донесе най-голяма полза (вътре в списъка е скрито изненада).
Източник: habr.com
