Що таке DevOps і які завдання виконує DevOps-інженер
Термін DevOps (Development Operations, або операції всередині
Багатий арсенал практик зближує DevOps з іншимпопулярному в ІТ-сфері методом Agile. Це ітеративний підхід до проекту, який дозволяє підлаштовуватися під мінливі вимоги. Відповідно, DevOps-фахівець намагається зробити продукт якісніше, а бізнес-процеси - передбачувані та прозоріше. Ще він покращує бізнес-метрики, наприклад, скорочує Time-to-Market. Це відрізок часу від початку розробки продукту до його виходу на ринок. Знання факторів, які розтягують час створення ПЗ, і системний підхід дозволяють DevOps-інженеру зробити виробництво безперервним і швидким. Щоб стало зрозуміліше, можна провести аналогію з конвеєром зі складання автомобілів. Всі деталі заздалегідь проектують так, щоб вони ідеально підійшли один до одного на збірці. Інженери, які розробляють двигун, думають про його роботі в зв'язці з колесами, гальмівною системою і так далі. Тим же займається і DevOps: бере на себе відповідальність за більшу частину продукту, ніж розробник, стежить, щоб всі команди співпрацювали.
Світ рожевих поні: гонка за модною філософією
Проте, DevOps потрібен не всім компаніям.Наприклад, в колективах без вже існуючих ІТ-відділів, які не займаються виробництвом digital-продукту, філософія DevOps зовсім не може бути застосована. До цих сфер належать компанії, чий прибуток не залежить безпосередньо від того, наскільки клієнти задоволені ІТ-продуктом, з яким вони взаємодіють. Крім того, часто вона не підходить малому бізнесу. Методологія вимагає змін багатьох збудованих бізнес-процесів і навіть корпоративної культури. Невеликі компанії можуть просто не витримати таких змін з точки зору економіки проекту.
Модная болезнь digital-трансформаций зачастую стосується керівників таких компаній. У гонитві за нескінченною оптимізацією вони забувають про інші фактори, які впливають на бізнес. В результаті компанії втрачають гроші, ефективність, а в гіршому випадку і бізнес-процеси, які вибудовували годамі.Другое справа - ІТ-гіганти, банки, великі торгові і виробничі заходи. Для них впровадження DevOps може принести велику вигоду. Так, за річним звітом «Альфа-банку» за 2017 рік, впровадження методології дозволило прискорити розробку та впровадження в 60 разів.
Стахановець-багатоверстатник замість цеху співробітників
Звичайно, такий великий функціонал важковиконувати одному працівникові, тому в ідеалі DevOps займається ціла крос-функціональна команда. У неї входять фахівці, які виконують ролі і менеджерів процесів і продукту, розробника інфраструктурного коду, інженера і ще багато інших ролей. Проте, в російській практиці DevOps-фахівець часто може стати модним способом заощадити гроші на створення продукту. Зазвичай така ситуація відбувається після того, як топ-менеджер компанії вирішує, що настав час digital-трансформації. У компанію екстрено набирають нових фахівців або розширюють список обов'язків вже існуючих розробників і системних адміністраторів. У підсумку на рекрутингових сервісах з'являються вакансію не DevOps-інженера, а многостаночника.
Такого співробітника можуть зобов'язати одноосібноналаштовувати сервери, прокладати кабельні системи, а потім відстежувати помилки, налаштовувати бази даних і хостинг проектів і так далі. Це приклад екстремальний, але реальний. В результаті співробітники швидко вигорають, а впровадження методології в роботу компанії провалюється. Ставлення до DevOps-фахівця як до чарівникові, який здатний одночасно управлятися з великою кількістю завдань укупі з моніторингом роботи всієї системи, не принесе бізнесу прибутку.
Інша поширена проблема пов'язана зподілом колективу на дві групи, які не можуть ужитися один з одним. Уявімо, що в ІТ-компанії з'являється відділ DevOps, якому дозволяють змінювати звичні регламенти роботи. При цьому ці правила залишаються обов'язковими для інших розробників. Звичайно, про кооперацію і «безшовного» роботи говорити в такому випадку не доводиться. Дві команди починають конфліктувати, і продуктивність падає.
Бочка пороху в трюмі: DevOps - не просто навички
Одне із завдань DevOps-відділу - налагодженнякомунікації між різними ІТ-фахівцями компанії. DevOps-інженери повинні не просто впроваджувати технології та налагоджувати процеси, але і занурювати команду розробки в курс справи - розділяти повноваження, допомагати підвищити компетенції. Проте, часто такі фахівці займаються суто технічними завданнями, зазвичай через банальну нестачу часу і у них, і у тих, чиї компетенції потрібно нарощувати.
У підсумку через те, що впровадженими моднимитехнологіями користуються все, а знання і навички сконцентровані в рамках одного відділу, виникають проблемні ситуації, в тому числі катастрофічного характеру. Нові рішення, які створюють DevOps-інженери, без злагодженої роботи різних підрозділів можуть принести стільки ж проблем, скільки повинні були вирішити ізначально.Ето не означає, що DevOps-фахівці повинні з нуля створювати корпоративну культуру, як, по всій видимості, часто вважають вітчизняні керівники. Єдність «конвеєра» digital-виробництва і заохочення передачі нових навичок і спілкування повинно виходити від керівників компанії. Без цього навіть DevOps-команда буде слабо розвиватися і не стане ділитися знаннями з колективом.
Ці проблеми не вирішує ні аутсорс DevOps, ніконсалтинг з фахівцем з боку. У першому випадку зовнішня команда орієнтується не на потреби компанії-замовника, а на стандартний набір технологій, який котирується на ринку. Для клієнта це лотерея: співробітники на аутсорс користуються розмитими уявленнями про DevOps на ринку. В результаті бізнес-процеси ускладнюються все більше, але це не приносить бізнесу ніяких переваг. Найчастіше самі компанії заохочують такий підхід - наприклад, просять не змінювати процеси розробки. Зрозуміло, що це суперечить самому поняттю DevOps.
Довго, дорого, проблемно: суворий DevOps по-російськи
Замість того, щоб застосовувати філософію DevOps довсім бізнес-процесам, вітчизняні компанії часто віддають перевагу роботі над інструментарієм, який не вплине на швидкість роботи. Одним з підсумків, наприклад, є «цегляна стіна» - Operations, тобто команда системних адміністраторів, залишається в ізоляції, а розробники просто закидають їм додатки. Звичайно, в результаті набір інструментів все одно поліпшується. Однак фундаментальних змін не відбувається, прозорість не росте, а кооперація ІТ-команд не стає успішніше.
Ще одна заковика, на яку натикаютьсяменеджери при впровадженні DevOps – відсутність корпоративних баз знань. За даними звіту DORA за 2019 рік, команди, які використовували внутрішні джерела інформації компанії, були в 1,73 рази ефективніші за інші. Ця проблема знову зводиться до закритості культури багатьох російських компаній, у яких колектив не обмінюється знаннями. Через цю закритість компанії починають накопичувати технічний борг. Інструментарій старіє, артефакти не видаляють, документацію не оновлюють.
Об'єктивна потреба бізнесу до стабільності виробництва, а значить, і прибутку, разом із застарілою базою технологій та технічним боргом призводять до невдалого застосування DevOps.
Все це часто призводить до того, що після довгих мук нові рішення, які пропонує DevOps-команда, просто викидаються, і процеси «відкочуються» назад.
У кожної компанії свій шлях digital-трансформації.У більшості випадків вона дійсно змінює розробку і розгортання коду на краще. Значить, DevOps в Росії все-таки існує: кожен місяць на ринку з'являється безліч вакансій, пов'язаних з цією методологією. Інша справа, що стоять за ними різні визначення спеціальності і практичні завдання. Проте, компаніям варто перестати гнатися за примарними ідеальними ІТ-системами і критично ставитися до переходу на модну, але не обов'язково вигідну філософію, віддаючи більший пріоритет власних потреб.
Читайте також:
У чорних дірах можуть бути всесвіти. Розповідаємо про нове відкриття
На 3 день хвороби більшість хворих COVID-19 втрачають нюх і часто страждають нежиттю
Дослідження: на дні океану знайшли 15 млн тонн мікропластіка