Ако някога си искал да научиш повече за мистериозния свят на DevOps или на самият теб ти предстои да започнеш работа като DevOps инженер, на точното място си! Съвсем скоро започва курсът Software Engineering and DevOps - февруари 2024, а по повод старта му сме ти приготвили интересно четиво, в което ще отговорим на два въпроса – какво е и какво не е DevOps.

Какво е DevOps?

DevOps (съкратено съчетание от "Development" и "Operations" - двата основни типа дейности при производството и поддръжката на даден продукт или система) е гъвкава методология и практика, която има за цел да унифицира софтуерната разработка и софтуерните операции. Основната характеристика на DevOps се изразява в подкрепа на процеса на автоматизация и съблюдаване на всяка една стъпка в процеса на софтуерна разработка – от интеграция, тестване и пускане на пазара до инфраструктурен мениджмънт.

Основни инструменти на DevOps

Виртуализацията, контейнеризацията и наблюдението са основни DevOps практики. За осъществяването им можеш да използваш разнообразие от инструменти. Именно с част от тях ще се запознаеш и по време на предстоящия курс. Ще работиш с Docker по процесите на контейнеризация. Ще приложиш Jenkins за автоматизиране на процесите по създаване, тестване и деплой на софтуер, както и continuous integration и continuous delivery. Ще придобиеш практически умения с Prometheus, Grafana и Elastick Stack.

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

Какво не е DevOps?

DevOps не е "NoOps". Както вече споменах по-горе една от основните цели на DevOps е автоматизацията. Процесът на автоматизация обаче е част от development процеса т.е. неговото разгръщане води до намаляване на IT Operations-a. Т.е. привидно в DevOps "Dev" бавно, но сигурно измества "Ops". Това е вярно отчасти и отчасти не е. Какво значи това? Ако метафорично кажем, че процеса на разработка на един софтуерен продукт е едно цяло, съставено от двете допълващите се части "Development" и "Operations", то в случая DevOps се разглежда като зло творение на "Development" частта, чрез което дивелъпърите да изземат функциите на IT операторите.

Истината е, че IT операторите все по-често се "облягат" на DevOps заради неговите преимущества като гъвкава методология. Това се налага, тъй като принципите, процесите и практиките, около които е изграден класическият метод на работа при IT операции, не са в ритъм с това, което е необходимо за успех. От една страна бизнесът (като цяло) и разработчиците имат нужда от повече гъвкавост, тъй като бизнес климатът става все по-динамичен. От другата обаче са хората, работещи в сферата на IT операциите (като системни или мрежови администратори), чиято работа се основава на по-закостенели принципи, което забавя целия процес по поддръжка на дадена система и т.н.

Получава се разминаване в темпа на работа на двете основни части. За да се избегне това, IT операторите осъзнават, че няма как част от процесите да не бъдат автоматизирани, като това означава, че или операторите трябва да започнат сами да разработват необходимата автоматизация, или разработчиците да започнат да пишат код за "операциите", или и двете.

Не става въпрос (просто) за инструменти

Когато говорим за внедряване на DevOps, не става въпрос просто за внедряване на набор от инструменти. Едно от погрешните схващания за DevOps се състои в това, че разчитащите на тази методология "претупват" теорията и пристъпват към практическо внедряване на даден набор инструменти, но без да вземат в предвид принципите, около които тази методология е построена, което всъщност води до реализиране на един своеобразен анти-модел на DevOps. Например: един процес на автоматизация е просто упражняване на сила, но необмислената автоматизация може да нанесе толкова щети, колкото обмислената може да донесе ползи.

Не е (просто) култура

Много хора твърдят, че DevOps "e просто култура" и думата терминът не може да се приложи стриктно към даден принцип или практика, но това е погрешно схващане.

Не става въпрос (просто) за "Devs" и "Ops"

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

Източник: SolarWinds

Има различни видове работа и страни в разработването. Просто защото някой не е получил специална покана (например "Не забравяйте за UI дизайнерите!"), това не означава, че те не са включени. По принцип гъвкавите методологии акцентират върху колаборацията "biz + dev", докато при DevOps акцента пада върху (логично) "dev + ops", но крайният резултат от прилагането на DevOps e, че всички си сътрудничат. В този смисъл DevOps е голяма стъпка напред що се касае до това дадена дисциплина да се включи в общата култура на гъвкавите методологии, като включва всички различни дейности в една дадена организация, а не води до тяхното разделяне или изхвърляне от производствения процес.

Не е (просто) име на професия

Има случаи, в които съществуващ ops team получава нарицателното "The DevOps Team" (не просто "DevOps отбор" а "DevOps отборЪТ" т.е. отнасят се към тази група хора като към отделно звено, с отделни задачи и отделна специализация). В други случаи някой може да промени името на специалността си на "DevOps Engineer".

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

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

DevOps не е "всичко"

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

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

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

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

Ако светът на DevOps ти се струва вълнуващ и интересен, или ти предстои да станеш DevOps инженер и искаш да се сдобиеш фундаментални умения, не се колебай да се включиш в предстоящия курс. За да вземеш максимума от него е необходимо да имаш опит като програмист или системен администратор. За да навлезеш плавно в материята, запиши се за Software Engineering and DevOps - февруари 2024!