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

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

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

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

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

Какво прави DevOps?

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

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

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

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

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

Освен това инженерът на DevOps трябва да използва административен ресурс от време на време. Например за преодоляване на „съпротивата на околната среда“ – когато екипът не е готов да приеме инструментите и методологията на DevOps.

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

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

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

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

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

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

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

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

• DevOops
• DevOpsConf
• HighLoad ++
• Flant
• Облачно решение MailRu

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

Ако вашата компания продава риба в малък магазин и единственият ИТ продукт е две 1C конфигурации: Enterprise (счетоводство и UNF), тогава едва ли има смисъл да се говори за DevOps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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