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

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

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

През последните няколко години основно се занимавам с внедряване на DevOps в различни компании. Преди това работих повече от 20 години на позиции от системен администратор до ИТ директор. В момента съм 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 в Русия знам доста. Освен стотиците интервюта, през послед year и половина участвах в стотина технически пресейла по услугата "Внедряване на DevOps" за големи руски компании и банки.

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

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

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

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

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

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

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

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

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

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

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

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

• DevOops
• DevOpsConf
• HighLoad++
• Флант
• MailRu Cloud Solution

Сега погледнете бизнеса си и помислете за следното: на колко силно зависят компанията ви и печалбата ѝ от IT продуктите, които осигуряват взаимодействие с клиента?

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

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

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

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

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

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

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

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

Ако основният продукт на компанията, който носи печалба, е софтуер — вие имате нужда от 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 на етапа на Continuous Integration.

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

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

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

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

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