Защо системните администратори, разработчиците и тестерите трябва да научат практиките на DevOps?

Къде да отида с тези знания, какво да правя в проекта и колко да печеля, какво да кажа и попитам на интервю - казва Александър Титов, управляващ партньор на Експрес 42 и автор онлайн курс „Практики и инструменти на DevOps“.

Здравейте! Въпреки че терминът DevOps съществува от 2009 г., все още няма консенсус в руската общност. Вероятно сте забелязали, че някои смятат DevOps за специалност, други го смятат за философия, а трети смятат термина за набор от технологии. Вече съм изпълнявал много пъти с лекции за развитието на тази посока, така че няма да навлизам в подробности в тази статия. Нека само да кажа, че в Express 42 включваме следното в него:

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

В класическата корпоративна разработка всичко върви последователно: програмиране, тестване и чак тогава експлоатация, като скоростта на този процес от идеята до производството е 3 месеца. Това е глобален проблем за дигиталните продукти, защото е невъзможно бързото получаване на обратна връзка от клиентите.

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

Какво следва от този подход?

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

  

• DevOps НЕ е следващата форма на системен администратор, към която да надстроите. „Инженер DevOps“ звучи горе-долу по същия начин като „Agile разработчик“.

  
  

• Ако даден екип използва Kubernetes, Ansible, Prometheus, Mesosphere и Docker, това не означава, че там са внедрени DevOps практики.

  
  

Животът след DevOps никога няма да бъде същият

Подходът DevOps е преди всичко различен начин на мислене, възприемане на развитието като цяло и мястото на човека в процеса. Разделихме нашия онлайн курс на 2 блока:

1. Самоопределяне

Първо разглеждаме в детайли същността на подхода DevOps, а студентите откриват нови роли в екипа, виждат коя отговаря повече и сами определят в коя посока да се развиват.

2. Инструменти и практики

Студентите овладяват конкретни технологии от гледна точка на метода DevOps.

Инструментите DevOps могат да се използват както в подхода DevOps, така и в класическата разработка. Най-очевидният пример би бил използването на инструмента за управление на конфигурацията Ansible. Той е създаден и замислен за прилагане на DevOps практиката „Инфраструктура като код“, което означава, че са описани различни състояния на системата, от настройките на операционната система до приложния софтуер. Описанието е разделено на слоеве и ви позволява да управлявате сложна, постоянно променяща се конфигурация. Но инженерите често използват Ansible като начин за изпълнение на bash скриптове на множество машини. Това не е нито лошо, нито добро, но трябва да разберете, че присъствието на Ansible не гарантира наличието на DevOps в компанията.

Ние сме в процес обменен курс Ще се потопите в процеса на разработване на приложение, подобно на известния Reddit, започвайки с неговата монолитна версия, преминавайки стъпка по стъпка към микроуслугите. Стъпка по стъпка ще овладеем нови инструменти: Git, Ansible, Gitlab и ще завършим с Kubernetes и Prometheus.

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

Какво дават тези знания на всеки един от специалистите?

За системни администратори

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

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

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

За разработчици

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

За тестери

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

Така се оказва, че и трите етапа протичат едновременно. Например може да изглежда така:

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

Когато започне непрекъсната интеграция, процесите се изпълняват едновременно. Услугата стартира и се конфигурира. В същото време докер контейнерът се стартира и се проверява дали работи. В същото време цялата информация отива в системата за регистриране. И така на всеки етап от разработката - оказва се истинска екипна работа на системни администратори, разработчици и тестери.

Учих DevOps, какво следва?

Както знаете, човек на полето не е войн. Ако вашата компания не използва този метод, придобитите умения ще лежат празни. И след като се запознаете с подходите на DevOps, най-вероятно няма да искате да бъдете зъбно колело в корпоративното развитие. Може да има едно изключение: вие сте системен администратор в екипа и можете да възстановите всички процеси по нов начин. Тук си струва да добавим, че има много компании, които използват този подход и те не са засегнати от блокирането и търсят специалисти. Тъй като DevOps е за създаване на онлайн продукти.

А сега за добрите неща: овладяването на практиките и инструментите на DevOps е приблизително +30% към вашата стойност на пазара на труда. Заплатите започват от 140 хиляди рубли, но се определят, естествено, от вашата основна специалност и функционалност.

Можете да разгледате свободни позиции с надпис „инфраструктурно ориентирани“, където има тестова автоматизация, разработване на приложения за микросервизи, използващи облачни технологии, свободни позиции за инфраструктурни инженери и всякакви препратки към DevOps. Само не забравяйте, че всяка компания има предвид нещо различно под това определение – прочетете внимателно описанието.

По време на стартирането на нашия курс ми дойде прозрение - много хора след курса попадат в капана на DevOps инженер. Те намират свободно място с гореспоменатото заглавие, получават добра оферта и след това идват на работа и разбират, че ще трябва да поддържат bash скрипт от три страници в Jenkins. Къде са Kubernetes, ChatOps, издания на Canary и всичко това? Но няма нищо, защото компанията няма нужда от DevOps като методология, а използва индивидуални иновации.

Това е причина интензивно да разберете от компанията как протича процесът на доставка на софтуер, технологичният стек и какви отговорности ще изпълнявате.

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

Ако да, тогава изяснете дали ще трябва да работите директно с тези системи или има възможност за хоризонтално движение към екипите на тези услуги, докато демонстрирате добри резултати в DevOps практиките. Ако да, тогава си струва да отидете и да бъдете активни и полезни, а ако завършите нашия курс, последното е гарантирано.

Важно е да се отбележи, че практикуващите Devops придобиват истинска стойност само с опит в разработването/администрирането/тестването. Само тогава знанията няма да бъдат абстрактни, а ще обогатят специалиста (във всякакъв смисъл). Следователно идеята за „изучаване на DevOps от нулата“ е почти същата като да се научите да „използвате обективи от нулата“, ако никога не сте държали камера в ръцете си или сте режисирали снимки. За да ви помогнем да решите дали курсът е подходящ за вас, направихме входящ тест, който ще провери достатъчното ви ниво на знания.

Мисля, че един от триковете обменен курс — че по време на обучението всеки ученик сам определя в каква посока иска да се развива. Често виждаме преходи, когато разработчикът стане инфраструктурен инженер и администратор осъзнава, че се интересува от писане на код - тогава той допълнително изучава езика и го допълва с придобитите DevOps умения. Затова приветстваме особено онези, които смятат, че кариерата им е заседнала на кръстопът. Курсът започва на 28 май, но можете да се включите 2 седмици след началото на занятията. Можете да разгледате програмата и да вземете теста по ссылке. Ще се видим в OTUS!

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