Тема 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 у Росії знаю досить багато. Крім сотень співбесід, за останні півтора роки я брав участь у сотні технічних пресейлів за послугою «Впровадження 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:
Тепер подивіться на свій бізнес і подумайте ось про що: як сильно ваша компанія та її прибуток залежать від 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