Куди з цими знаннями йти, чим займатися в проекті і скільки заробляти, що говорити і питати на співбесіді — розповідає Олександр Тітов, партнер Express 42, що управляє, і автор .
Вітання! Хоча термін DevOps існує з 2009 року, єдиної думки у російській спільноті досі немає. Напевно, ви помічали, що одні вважають DevOps спеціальністю, інші філософією, треті під терміном мають на увазі набір технологій. Я вже багато разів виступав з про розвиток цього напряму, тому в цій статті подробиці вдаватися не буду. Скажу лише, що ми в компанії Express 42 закладаємо в нього таке:
DevOps — конкретна методика, культура створення цифрового продукту, коли усі фахівці в команді беруть участь у продакшені.
У класичній корпоративній розробці все йде послідовно: програмування, тестування і потім експлуатація, і швидкість такого процесу від ідеї до продакшена становить 3 місяці. Для цифрових продуктів це глобальна проблема, тому що не можна оперативно отримувати зворотний зв'язок від клієнтів.
У DevOps інструменти та підходи заточені на те, щоб процеси розробки, тестування та експлуатації запускалися одночасно.
Що з цього підходу випливає?
- Не можна найняти якогось «інженера», який прийде та вирішить усі проблеми з продакшеном. Застосовувати методику має вся команда.
- DevOps - це НЕ наступна форма сисадміну, в яку можна проапгрейдитися. "DevOps-інженер" звучить приблизно так само, як "Agile-розробник".
- Якщо в команді використовують Kubernetes, Ansible, Prometheus, Mesosphere та Docker, це ще не означає, що там впроваджено DevOps-практики.
Життя після DevOps вже не буде колишнім
DevOps-підхід – це насамперед інший спосіб мислення, сприйняття розробки загалом та свого місця у процесі. Наш онлайн-курс ми розділили на 2 блоки:
1. Самовизначення
Спочатку ми докладно розуміємо суть DevOps-підходу, а студенти відкривають собі нові ролі в команді, дивляться, яка більше відгукується і визначають собі, в який бік розвиватися.
2. Інструменти та практики
Студенти освоюють конкретні технології з точки зору методу DevOps.
Інструменти DevOps можна використовувати як під час DevOps, так і при класичній розробці. Найяскравішим прикладом може бути використання інструмента керування конфігурацією Ansible. Він створений та задуманий для реалізації DevOps практики «Інфраструктура як код», це означає, що описуються різні стани системи від налаштувань операційної системи до прикладного софту. Опис ділиться на шари і дозволяє керувати складною конфігурацією, що постійно змінюється. Але найчастіше інженери використовують Ansible як спосіб виконання bash скриптів на декількох машинах. Це не погано і не добре, але треба розуміти, що наявність Ansible не гарантує наявність DevOps у компанії.
У нас у ході ви поринете в процес розробки програми, схожої на відомий Reddit, спочатку з його монолітного варіанта, по кроках переходячи до мікросервісів. Крок за кроком ми освоюватимемо нові інструменти: Git, Ansible, Gitlab і закінчимо Kubernetes і Prometheus.
За практиками ми слідуватимемо тактиці трьох шляхів, описаних у книзі DevOps Handbook — практики безперервного постачання, практики зворотного зв'язку та суть всього курсу практика безперервного навчання разом із вашою системою.
Що дають ці знання кожному із фахівців?
Сисадмінам
Практики дозволять відійти від адміністрування у бік створення continuous delivery pipeline та інфраструктурної платформи постачання ПЗ. Сенс у тому, що він створює продукт — інфраструктурну платформу для розробників, яка допомагає їм швидко просувати їх зміни до продакшну.
Раніше сисадміни були останнім бастіоном, після якого все йде у продакшн. І в основному вони займалися безперервним пожежогасінням - у світлі чого досить складно вникати в потреби бізнесу, думати про продукт і користь для користувача.
Завдяки DevOps-методу змінюється мислення. Сисадмін розуміє, як перевести конфігурацію в код, які для цього практики існують.
Це важливо, тому що компанії все частіше розуміють, що не потребують просто автоматизації всього і вся, тобто. в тому, чим по суті звикли займатися сисадмінами старого гарту, які плюс до цього мало спілкувалися і не доносили до команди про всі зроблені зміни. Тепер команди шукають тих, хто стане виробником внутрішнього інфраструктурного продукту та допоможе об'єднати розділені процеси в один.
Розробникам
Розробник перестає думати лише алгоритмами. Він знаходить досвід роботи з інфраструктурою, досвід архітектурного розуміння ландшафту. Такий розробник розуміє, як працює програма, як вона проходить continuous delivery pipeline, як його замоніторити, як його залогувати, щоб вона приносила користь клієнту. У результаті ці знання дозволяють писати релевантний код.
Тестувальникам
Тестування вже давно переходить в автоматичний режим, ми всі говоримо, що багато тестів треба не робити, а писати 🙂 Тестувальнику треба не просто навчитися писати код, а й зрозуміти, як вбудувати його в системи безперервного постачання, як отримувати зворотний зв'язок від коду на всіх етапах постачання, як постійно покращувати тестування, щоб виявляти помилки якомога раніше.
Ось і виходить, що всі три етапи відбуваються одночасно. Наприклад, це може виглядати так:
Розробник пише код, відразу пише для нього тести і описує докер-контейнер для того коду, який повинен запускатися. Також відразу описує моніторинг, який моніторитиме роботу цього сервісу в продакшені, і все це комітіт.
Коли запускається постійна integration, процеси йдуть одночасно. Сервіс стартує, налаштовується. Паралельно стартує докер-контейнер, перевіряється, що він працює. Одночасно вся інформація йде до системи логування. І так на кожному етапі розробки виходить справжня командна робота системних адміністраторів, розробників і тестувальників.
Вивчив DevOps, а що далі?
Як відомо, один у полі не воїн. Якщо у вашій компанії цей метод не використовують, отримані навички лежатимуть без діла. Та й після знайомства з DevOps-підходами бути гвинтиком у корпоративній розробці, швидше за все, не захочеться. Виняток може бути один: ви в команді системний адміністратор і можете перебудувати всі процеси на новий лад. Тут варто додати, що є купа компаній, які цей підхід застосовують, і вони не зачеплені локдауном і шукають фахівців. Тому що DevOps це про створення онлайн-продуктів.
А тепер про приємне: володіння практиками та інструментами DevOps – це приблизно +30% до вашої вартості на ринку праці. Зарплати починаються від 140 тис. рублів, але визначаються, звичайно, вашою основною спеціальністю та функціоналом.
Дивитися можна на вакансії з позначкою «з орієнтиром на інфраструктуру», де є автоматизація тестування, розробка мікросервісних програм з використанням хмарних технологій, вакансії інфраструктурних інженерів та всілякі згадки DevOps. Просто пам'ятайте, що кожна компанія має на увазі під цим визначенням щось своє — уважно вчитуйтесь в опис.
За час запусків нашого курсу до мене прийшов інсайт — багато людей після курсу потрапляють у пастку DevOps-інженера. Знаходять вакансію із вищезгаданою назвою, отримують хороший оффер, а потім приходять на роботу і розуміють, що доведеться підтримувати тристорінковий баш-скрипт у Jenkins. А де ж Kubernetes, ChatOps, канаркові релізи і ось це все? А нічого нема, тому що компанії не потрібен DevOps, як методологія, а використовуються окремі нововведення.
Це привід посилено з'ясовувати у компанії, як влаштований процес постачання ПЗ, технологічний стек і які обов'язки ви виконуватимете.
Якщо на ваші запитання роботодавець відповідає абстрактно, як по книжці, без деталей, то швидше за все DevOps процесу в компанії ще немає, але це не привід відмовляти, вивчіть компанію та її продукти, чи є онлайн-сервіси, які компанія розвиває сама, мобільні програми , ідеї продуктів.
Якщо так, то уточніть, чи вам доведеться безпосередньо працювати з цими системами, чи є можливість горизонтального переміщення в команди цих сервісів при демонстрації хороших результатів у DevOps практиках. Якщо так, то варто йти і бути активним та корисним, а якщо ви закінчите наш курс, то останнє гарантоване.
Важливо зауважити, що справжню цінність Devops-практики набувають лише за наявності досвіду у розробці/адмініструванні/тестуванні. Тільки тоді знання будуть не абстрактними, а збагатять спеціаліста (в усіх розуміннях). Тому ідея «навчитися девопсу з нуля» приблизно те саме, що вчитися «використання об'єктивів з нуля», якщо ти ніколи не тримав у руках фотоапарат або не режисирував зйомки. Щоб допомогти зорієнтуватися, чи вам підходить курс, ми зробили вступний тест, який перевірить достатній рівень знань.
Думаю, одна з фішок — те, що за час навчання кожен студент визначає для себе, в який бік хоче розвиватися. Ми нерідко спостерігаємо переходи, коли розробник стає інфраструктурним інженером, а адміністратор розуміє, що йому цікаво писати код — тоді він додатково вивчає мову та доповнює її набутими DevOps-навичками. Тому ми особливо чекаємо на тих, хто відчуває, що його кар'єра застрягла на роздоріжжі. Курс стартує вже 28 травня, але приєднатися можна і через два тижні після початку занять. Переглянути програму та пройти тест можна . До зустрічі в OTUS!
Джерело: habr.com