Напоследък подобни реклами заляха интернет. Въпреки приятната заплата, човек не може да не се смути, че вътре пише дива ерес. Първоначално се предполага, че „DevOps“ и „инженер“ могат по някакъв начин да бъдат слепени заедно в една дума, а след това има произволен списък с изисквания, някои от които са ясно копирани от ваканцията на системния администратор.
В тази публикация бих искал да поговоря малко за това как стигнахме до този етап от живота, какво всъщност е DevOps и какво да правим с него сега.
Такива свободни работни места могат да бъдат осъждани по всякакъв възможен начин, но фактът остава: има много от тях и така работи пазарът в момента. Проведохме devops конференция и открито заявяваме: „ - не за инженерите на DevOps." Тук мнозина ще го намерят странно и диво: защо хора, които правят напълно комерсиално събитие, вървят срещу пазара. Сега ще обясним всичко.
За културата и процесите
Нека започнем с факта, че DevOps не е инженерна дисциплина. Всичко започна с факта, че исторически установеното разделение на ролите не работи за качеството на продуктите. Когато програмистите само програмират, но не искат да чуят нищо за тестване, софтуерът е пълен с грешки. Когато администраторите не се интересуват как и защо е написан софтуерът, поддръжката се превръща в ад.
Например, описвайки разликата между подхода на системен администратор и SRE към управлението на услугата . Интересни проучвания са проведени в рамките на — ясно е, че най-добрите разработчици по някакъв начин успяват да внедрят нови промени в производството по-бързо от веднъж на час. Тестват с ръце не повече от 10% (това се вижда от ). Как правят това? „Excel or die“ гласи едно от заглавията на отчета. За подробно обсъждане на тези статистики в контекста на тестването, можете да се обърнете към основната бележка на Барух Садогурски на другата ни конференция, Heisenbug.
„Когато няма съгласие между другарите,
Нещата няма да вървят добре за тях,
И нищо няма да излезе, само мъки.
Имало едно време лебед, рак и щука..."
Каква част от уеб програмистите според вас наистина разбират условията, при които техните приложения се използват в производството? Колко от тях ще отидат при администраторите и ще се опитат да разберат какво ще се случи, ако базата данни се срине? И кой от тях ще отиде при изпитващите и ще ги помоли да ги научат как да пишат правилно тестове? Има и охранители, продуктови мениджъри и куп други хора.
Цялостната идея на DevOps е да създаде сътрудничество между роли и отдели. На първо място, това се постига не с някакъв хитро конфигуриран софтуер, а с практиката на комуникация. DevOps е за култура, практики, методология и процеси. Няма инженерна специалност, която да отговори на тези въпроси.
Порочен кръг
Откъде тогава дойде дисциплината „devops инженерство“? Имаме версия! Идеите на DevOps бяха добри – толкова добри, че станаха жертви на собствения си успех. Някакви сенчести вербовчици и трафиканти на хора, които имат собствена атмосфера, започнаха да се въртят около цялата тази тема.
Представете си: вчера правехте шаурма в Химки, а днес вече сте голям мъж, старши специалист по подбор на персонал. Има цял процес на търсене и подбор на кандидати, всичко не е лесно, трябва да разберете. Да речем, че ръководителят на отдел казва: намерете специалист по X. Присвояваме думата „инженер“ на X и сме готови. Нуждаете се от Linux? Е, това определено е Linux инженер, ако искате DevOps, тогава DevOps инженер. Свободното място се състои не само от заглавие, но и трябва да се въведе някакъв текст вътре. Най-лесният начин е да въведете набор от ключови думи от Google, в зависимост от вашето въображение. DevOps се състои от две думи - „Dev“ и „Ops“, което означава, че трябва да слепим заедно ключови думи, свързани с разработчици и администратори, всички в една купчина. Ето как се появяват свободни позиции за владеене на 42 езика за програмиране и 20 години използване на Kubernetes и Swarm едновременно. Работна схема.
Ето как безсмисленият и безмилостен образ на определен супергерой „devops“ се е вкоренил в съзнанието на хората, който ще конфигурира всички да се разположат на Дженкинс и щастието ще дойде. О, само ако всичко беше толкова просто. „И по този начин можете да преследвате системните администратори“, смята HR, „това е модерна дума, ключовите думи са същите, те трябва да хванат стръвта.“
Търсенето създава предлагане и всички тези празни работни места бяха запълнени с безумен брой системни администратори, които осъзнаха: можете да правите всичко както преди, но да получавате няколко пъти повече, като се наричате „devops“. Точно както конфигурирахте сървъри чрез SSH ръчно един по един, вие ще продължите да ги конфигурирате, но сега това се предполага, че е практика за devops. Това е някакъв комплексен феномен, отчасти свързан с подценяването на класическите администратори и шума около DevOps, но като цяло каквото стана, стана.
Така че имаме търсене и предлагане. Порочен кръг, който се самозахранва. Срещу това се борим (включително чрез създаването на конференцията DevOops).
Разбира се, в допълнение към системните администратори, които са се преименували на „devops“, има и други участници - например професионални разработчици на SRE или Infrastructure-as-Code.
Какво правят хората в DevOps (наистина)
Така че искате да напреднете в изучаването и прилагането на 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 февруари. Моля, имайте предвид, че когато попълвате формуляра, трябва да изберете целевата аудитория, която ще има най-голяма полза от вашия доклад (в списъка е заровена изненада).
Източник: www.habr.com