Тема DevOps за останні кілька років стала дуже популярною. Багато хто мріє влитися у неї, але, як показує практика, часто лише через рівень зарплат. Деякі зазначають у своєму резюме DevOps, хоча не завжди знають і розуміють суть терміну.
Хтось вважає, що вивчивши Ansible, GitLab, Jenkins, Terraform та подібне (список можна продовжувати), відразу стане "девопсом". Звісно, це не так. Протягом останніх кількох років я займаюся переважно впровадженням DevOps у різних компаніях. До цього понад 10 років працював на посадах від системного адміністратора до ІТ-директора.
Зараз я співзасновник та СТО у Gart Solutions.
Хто такий DevOps
Ідея написати статтю виникла після чергового питання: "хто такий DevOps?". Досі немає усталеного терміну, що або хто це таке. DevOps - це не фахівець, якого можна найняти, не набір утиліт і не відділ розробників з інженерами.
DevOps - це філософія і методологія.
Іншими словами, це набір практик, який допомагає активно взаємодіяти розробникам з системними адміністраторами. Тобто пов'язувати та інтегрувати робочі процеси один з одним. З появою DevOps структура та ролі фахівців залишилися такими ж (є розробники, є інженери), але змінилися правила взаємодії. Розмилися межі між відділами. Цілі DevOps можна описати трьома пунктами:
Програмне забезпечення має оновлюватися регулярно.
Створення програмного забезпечення має бути швидким.
Розгортання програмного забезпечення має бути зручним і відбуватися в короткі терміни.
У DevOps немає єдиного інструменту. Налаштування, встановлення та вивчення кількох продуктів не означає, що в компанії з'явився DevOps. Інструментів дуже багато, і всі вони задіяні на різних етапах, але служать одній загальній меті.
Вже понад 2 роки я проводжу співбесіди з людьми на посаду DevOps-інженера, і до мене прийшло розуміння, наскільки важливо чітко усвідомлювати суть терміну. Накопичився специфічний досвід, спостереження і думки, якими я хочу поділитися. З досвіду співбесід я бачу таку картину: у фахівців, які вважають DevOps посадою, зазвичай виникають непорозуміння з колегами.
Методологія та філософія DevOps
Методологія буває теоретичною та практичною. У нашому випадку - друга. Як я зазначав вище, DevOps - це набір практик і стратегій, що застосовуються для досягнення заявлених цілей. І в кожному випадку, залежно від бізнес-процесів компанії, він може істотно відрізнятися. Що не робить його кращим чи гіршим.
Методологія DevOps - лише засіб досягнення поставлених цілей.
Тепер про те, що таке філософія DevOps. І це, напевно, найскладніше питання. Оскільки адепти філософії DevOps більше займаються практикою – на філософствування просто немає часу. Тим не менш, це дуже важливий процес. Причому безпосередньо пов'язаний з інженерною діяльністю.
Я на своєму досвіді спробував сформалізувати деякі "постулати" цієї філософії. Вийшло наступне:
DevOps не є чимось самостійним, що можна виділити в окремий напрямок знань або діяльності.
Методологією DevOps повинні керуватися всі співробітники компанії, плануючи свою діяльність.
DevOps торкається всіх процесів всередині компанії.
DevOps існує, щоб знижувати часові витрати на будь-які процеси всередині компанії для забезпечення розвитку її послуг та максимального комфорту клієнта.
DevOps сучасною мовою це проактивна позиція кожного співробітника компанії, спрямована на зниження часових витрат і поліпшення якості ІТ-продуктів, що нас оточують.
Що робить DevOps
Ключове слово тут - комунікації. Дуже багато комунікацій, ініціатором яких повинен бути саме DevOps-інженер. Чому так? Тому що це філософія і методологія, а вже потім інженерні знання.
В Україні DevOps ще доволі молода, але вже трендова тема. Слово Kubernetes для роботодавців майже як червона ганчірка для бика. Адепти цього інструменту готові використовувати його навіть там, де це не потрібно і економічно невигідно. Роботодавець не завжди розуміє в яких випадках, що доречніше використовувати, а при належному розгортанні утримання кластера Kubernetes коштує у 2-3 рази дорожче, ніж розгортання додатку за звичайною кластерною схемою.
Впровадження DevOps з точки зору грошей - дороге. І виправдане тільки там, де приносить економічну вигоду в інших сферах, а не саме по собі.
DevOps-інженери, фактично, першопрохідці - саме вони першими повинні впроваджувати в компаніях цю методологію і вибудовувати процеси. Щоб це було успішно, фахівець повинен постійно взаємодіяти зі співробітниками і колегами на всіх рівнях. Як я зазвичай кажу, в процес впровадження DevOps повинні бути залучені всі співробітники компанії: від прибиральниці до CEO. І це обов'язкова умова. Якщо наймолодший член команди не буде знати і розуміти, що таке DevOps і навіщо виконуються ті чи інші організаційні дії, то успішного впровадження не вийде.
Також DevOps-інженеру потрібно час від часу використовувати адміністративний ресурс. Наприклад, для подолання "опору середовища" - коли команда не готова прийняти інструменти та методологію DevOps.
Розробник повинен писати тільки код і тести. Для цього йому не потрібен надпотужний ноутбук, на якому він буде розгортати та підтримувати локально всю інфраструктуру проекту. Наприклад, фронтендер тримає у себе на ноутбуці всі елементи додатку, включаючи базу даних, емулятор S3 (minio) і таке інше. Тобто витрачає багато часу на підтримання цієї локальної інфраструктури і самотужки бореться з усіма проблемами такого рішення. Замість того, щоб розробляти код для фронту. Такі люди можуть сильно чинити опір будь-яким змінам.
Але є команди, які, навпаки, раді впровадженню нових інструментів і методів, і жваво беруть участь у цьому процесі. Хоча навіть у такому випадку комунікації між DevOps-інженером і командою ніхто не скасовував.
Коли DevOps не потрібний
Бувають ситуації, коли DevOps не потрібний. Це факт - його потрібно зрозуміти і прийняти.
Перш за все, це стосується будь-яких компаній (особливо малого бізнесу), коли їхній прибуток не залежить безпосередньо від наявності або відсутності ІТ-продуктів, які надають інформаційні сервіси клієнтам. І тут мова не про сайт компанії, хай він буде статичною "візиткою" чи з динамічними новинними блоками тощо.
DevOps потрібний, коли від наявності цих інформаційних сервісів для взаємодії з клієнтом, їхньої якості та таргетованості залежить задоволеність вашого клієнта і його бажання знову повертатися саме до вас.
Яскравим прикладом є Монобанк. Компанія ніколи і не була просто банком і, на мою думку, перетворилася на ІТ-компанію з розвиненими DevOps-технологіями.
Тепер погляньте на свій бізнес і подумайте ось про що: наскільки сильно ваша компанія та її прибуток залежать від ІТ-продуктів, що забезпечують взаємодію з клієнтом?
Якщо ваша компанія торгує рибою в невеличкому магазинчику, а єдиним ІТ-продуктом є дві конфігурації 1С, то навряд чи є сенс говорити про DevOps.
Якщо ж ви працюєте на великому торговому та виробничому підприємстві (наприклад, виробляєте мисливські рушниці), то варто задуматися. Ви можете проявити ініціативу та донести своєму керівництву перспективи впровадження DevOps. І, заодно, очолити цей процес. Проактивна позиція - один з важливих постулатів філософії DevOps.
Розмір та обсяг річного фінансового обороту не є основним критерієм для визначення, чи потрібен вашій компанії DevOps.
Уявімо собі велике промислове підприємство, яке не взаємодіє безпосередньо з клієнтами. Наприклад, деякі автоконцерни та автомобілебудівні компанії. Зараз не впевнений, але з мого минулого досвіду, багато років вся взаємодія з клієнтами здійснювалася електронною поштою і телефоном.
Їхні клієнти - це обмежений список автомобільних дилерів. І до кожного прикріплений фахівець від виробника. Весь внутрішній документообіг відбувається через ERP SAP. Внутрішні співробітники, по суті, є клієнтами інформаційної системи. Але управління цією ІС здійснюється класичними засобами управління кластерними системами. Що виключає можливість використання практик DevOps.
Звідси висновок: для подібних підприємств впровадження DevOps не є чимось критично важливим, якщо згадати цілі методології з початку статті. Але не виключаю, що якісь інструменти DevOps використовуються ними сьогодні.
З іншого боку, є багато невеликих компаній, які розробляють програмне забезпечення з використанням методології, філософії, практик та інструментів DevOps. І вважають, що витрати на впровадження DevOps є витратами, що дозволяють їм ефективно конкурувати на ринку ПЗ.
Основний критерій для розуміння чи потрібен DevOps: яке значення ваші ІТ-продукти мають для компанії та клієнтів?
Якщо основний продукт компанії, що приносить прибуток, це ПЗ - вам потрібен DevOps. І не так важливо, якщо реальні гроші ви заробляєте за допомогою інших товарів. Сюди також можна віднести інтернет-магазини або мобільні ігрові додатки.
Замість висновку
Хочу закінчити такою думкою: щоб стати DevOps-інженером високої кваліфікації, життєво необхідно навчитися живому спілкуванню з людьми.
DevOps-інженер - командний гравець. І нічого більше. Ініціатива в спілкуванні з колегами має виходити від нього самого, а не під впливом якихось обставин. DevOps-фахівець має побачити та запропонувати найкраще рішення для команди.
І так, впровадження будь-якого рішення потребуватиме багато обговорень, а під кінець може взагалі змінитися. Самостійно розвиваючись, пропонуючи та втілюючи свої задуми - така людина стає дедалі ціннішою як для команди, так і для роботодавця. Що, зрештою, відображається і на розмірі її щомісячної винагороди або у вигляді додаткових премій.
