🥇Кой е DevOps и кога не е нужен

Темата DevOps стана много популярна през последните няколко години. Мнозина мечтаят да се включат в нея, но, както показва практиката, често само поради заплатите.

Някои посочват DevOps в своето резюме, макар не винаги да разбират същността на термина. Някой смята, че щом изучи Ansible, GitLab, Jenkins, Terraform и подобни (списъкът може да продължи по желание), ще стане веднага "девопс". Това, разбира се, не е така.

През последните няколко години се занимавам главно с внедряване на DevOps в различни компании. Преди това работих повече от 20 години на позиции от системен администратор до IT директор. Сега съм DevOps Lead Engineer в Playgendary.

Кой е DevOps

Идеята за написването на статията възникна след поредния въпрос: "Кой е DevOps?". Все още няма установен термин, какво или кой е това. Част от отговорите вече са налични в този видео. Първо ще посоча основните тези от него, а след това ще споделя моите наблюдения и мисли.

DevOps не е специалист, когото може да наемете, не е набор от инструменти и не е отдел разработчици с инженери.

DevOps е философия и методология.

С други думи, това е набор от практики, който помага активно да се взаимодействат разработчиците със системните администратори. Тоест да свързват и интегрират работните процеси помежду си.

С появата на DevOps структурата и ролите на специалистите останаха същите (има разработчици, има инженери), но правилата за взаимодействие се промениха. Границите между отделите се размият.

Целите на DevOps могат да бъдат описани с три точки:

Софтът трябва да се обновява редовно.
Софтът трябва да се прави бързо.
Софтът трябва да се разгръща удобно и в кратки срокове.

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

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

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

От опита ми с интервюта виждам такава картина: при специалистите, които смятат DevOps за длъжност, обикновено има недоразумения с колегите..

Имаше ярък пример. На интервю дойде млад човек с куп умни думи в автобиографията. В последните три места на работа той имаше стаж от 5-6 месеца. От двата стартапа си тръгна, защото "не успяха да полетят". А за третата компания каза, че там никой не го разбира: разработчиците пишат код за Windows, а директорът му нарежда да "опаковат" този код в обикновен Docker и да го вградят в CI/CD пайплайн. Момчето разказа много негативни неща за текущото си работно място и колегите си — и направо ми се прииска да му кажа: "Така не можеш да продадеш слон".

След това му зададох въпрос, който в моя списък е един от първите за всеки кандидат.

— Какво означава DevOps лично за теб?
— Общо или как аз го възприемам?

Интересуваше ме неговото лично мнение. Той познаваше теорията и произхода на термина, но беше категорично несъгласен с тях. Считаше, че DevOps е позиция. Тук се крие коренът на неговите проблеми. Както и на другите специалисти с такова мнение.

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

Методологията и философията на DevOps

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

Методологията на DevOps е просто средство за постигане на поставените цели.

Сега за това какво представлява философията на DevOps. И това вероятно е най-трудният въпрос.

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

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

В опита си се опитах да формализирам някои 'постулати' на тази философия. Получи се следното:

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

Мисля, че моите 'постулати' са отделна тема за обсъждане. Но сега има от какво да се изхожда.

Какво прави DevOps

Ключовата дума тук е - комуникации. Има много комуникации, инициатор на които трябва да бъде именно DevOps инженера. Защо така? Защото това е философия и методология, а чак след това инженерни знания.

Не мога да говоря за западния пазар на труда с 100% увереност. Но за пазара на DevOps в Русия знам доста. Освен стотиците интервюта, през последната година и половина участвам в стотина технически пресейла по услугата 'Внедряване на DevOps' за големи руски компании и банки.

В България DevOps все още е много млада, но вече актуална тема. Толкова, колкото знам, само в София недостигът на такива специалисти през 2019 година е над 1000 души. А думата Kubernetes за работодателите е почти като червено знаме за бика. Привържениците на този инструмент са готови да го използват дори там, където не е необходимо и икономически неизгодно. Работодателят не винаги разбира в кои случаи какво е по-уместно да се използва, а при правилно разгръщане съдържанието на кластера Kubernetes струва 2-3 пъти повече отколкото разгръщането на приложение по стандартна кластерна схема. Използвайте го там, където той наистина е нужен.

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

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

Също така, DevOps-инженерът трябва от време на време да използва административен ресурс. Например, за преодоляване на „съпротивата на средата“ — когато екипът не е готов да приеме инструментите и методологията на DevOps.

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

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

Кога DevOps не е необходим

Има ситуации, когато DevOps не е необходим. Това е факт, който трябва да се разбере и приеме.

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

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

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

Много други примери и лекции могат да се намерят в записите на тематични митапи и конференции. Част от тях посетих лично — това е много полезен опит за тези, които искат да се развиват в тази посока. Ето линкове към YouTube канали с добри лекции и материали по DevOps:

Сега погледнете на бизнеса си и помислете за това: колко силно зависи вашата компания и нейният приход от ИТ-продукти, които осигуряват взаимодействие с клиента?

Ако вашата компания търгува с риба в малък магазин и единствените ИТ-продукти са две конфигурации на 1С: Предприятие (Счетоводство и УНФ), то едва ли има смисъл да говорим за DevOps.

Ако обаче работите в голямо търговско и производствено предприятие (например произвеждате ловни пушки), то трябва да се замислите. Можете да проявите инициатива и да предадете на ръководството си перспективите за внедряване на DevOps. И заедно с това, да ръководите този процес. Проактивната позиция е един от важните постулати на философията на DevOps.

Размерът и обемът на годишния финансов оборот не са основен критерий за определяне на необходимостта от DevOps в компанията ви.

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

Техните клиенти са ограничен списък от автомобилни дилъри. И към всеки от тях е назначен специалист от производителя. Цялата вътрешна документация преминава през ERP SAP. Вътрешните служители всъщност са клиенти на информационната система. Но управлението на тази ИС се осъществява чрез класически методи за управление на клъстерни системи. Това изключва възможността за използване на практики DevOps.

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

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

Основният критерий за разбиране дали DevOps е необходим: какво значение имат вашите IT-продукти за компанията и клиентите.

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

Всички игри съществуват благодарение на финансиране: пряко или косвено от страна на играчите. В Playgendary разработваме безплатни мобилни игри, в непосредственото създаване на които участват повече от 200 души. Как използваме DevOps?

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

В момента активно използваме Jenkins като инструмент за CI/CD pipelines за изпълнение на всички конвейери за компилация с Unity и последващ деплой в App Store и Play Market. Още от класическия набор инструменти:

Asana — за управление на проекти. Настройка на интеграция с Jenkins.
Google Meet — за провеждане на видео срещи.
Slack — за комуникация и различни известия, включително уведомления от Jenkins.
Atlassian Confluence — за документиране и работа в група.

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

Вместо заключение

Искам да завърша с следната мисъл: за да станеш висококвалифициран DevOps инженерен, е жизненоважно да научиш как да общуваш с хора.

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

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

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