Поради сеньйорів: як прокачати знання junior DevOps

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

Олег Федотов, Engineer Level 2 в CoreValue

18 років досвіду в ІТ, з них 5 — у DevOps

Почнемо з того, що спочатку DevOps — це культура відносин між групами розробки та експлуатації, а не професія. І тільки згодом, природним шляхом, DevOps перемістився в розряд професії — суміші таких навичок, як системне адміністрування, програмування, використання хмарних технологій і автоматизація інфраструктури. При цьому спектр використовуваних технологій настільки широкий, що починаючому DevOps інженеру треба бути готовим присвячувати достатньо багато часу на їх вивчення. Ну а тепер давайте спробуємо переказати, що важливо і що лежить в основі:

Це далеко не все, але достатньо для впевненого старту. А попереду Docker, Ansible, Jenkins тощо — це ті технології, вивчати які буде набагато легше, освоївши базу. А далі ITIL, DevOps методології і ще багато-багато цікавого і важливого. І я навмисне не згадав Windows! Я вважаю, що освоївши Linux, освоїти Windows буде куди легше, але не навпаки.

Дмитро Замаруев , Technical Director, Cloud Solutions в Grid Dynamics

Понад 14 років досвіду в ІТ

Останнім часом все чомусь шукають спеціалістів на позицію DevOps Engineer, але для тих, хто розбирається в термінології, це звучить приблизно як Agile Engineer — термін, який не говорить взагалі нічого і ні про що. А все тому, що DevOps — це методологія, а не спеціальність. Методологія, яка описує взаємодію між різними командами, дає рекомендації з питань розробки і доставки додатків, управління інфраструктурою.

Найбільш часто компанії на позицію «DevOps Engineer» шукають людей, які будуть відповідати за CI/CD інфраструктуру для проекту/компанії, займатися доставкою додатків (deployment engineer) або автоматизувати створення інфраструктури (infrastructure engineer). Це все окремі самодостатні спеціалізації, про кожну з яких можна довго говорити.

Спробуємо узагальнити знання, які допоможуть інженеру почати розбиратися в цих областях. DevOps охоплює багато визначень: це і continuous delivery (CI/CD), і infrastructure automation, і configuration management:

Інструментарію та областей, які зараз входять в DevOps занадто багато, щоб братися їх вивчати разом. Слід розібратися в декількох інструментах і далі порівнювати вже відомі інструменти/підходи з новими.

І найголовніше — пам'ятати, що кожен інструмент вирішує свою задачу і не потрібно намагатися одним інструментом вирішити всі проблеми проекту — краще для кожної задачі вибрати свій.

Євген Волченко , DevOps Engineer в Luxoft Ukraine

12 років в IT, 5 років досвіду в DevOps

3 must-have навички

Хороший DevOps спеціаліст повинен вільно себе почувати з людьми, з якими працює. Розвинені soft skills однозначно цьому посприяють. Спілкування з фахівцями різного профілю у щоденній діяльності вимагає розвинених комунікативних навичок. Тому якщо вам складно комунікувати — починайте розвивати цю навичку з перших днів роботи, навчитися цьому можна.

Не секрет, що DevOps ресурс в командах часто обмежений, а тому спеціалісту цієї практики потрібно бути самостійним. Особливо це стосується розвитку, освіти і самоосвіти на початкових етапах. Крім підвищення кваліфікації, це дозволить джуніору визначити для себе, чи точно це те, чим хочеться займатися в подальшому і до чого лежить душа. Часто буває, що на практиці DevOps — не зовсім те, що очікують.

Також початківцю фахівця важливо мати технічний бекграунд, а ще краще — техобразование. Розуміння комп'ютерних мереж та інфраструктури, а також основ побудови відмовостійких рішень згодиться. Зараз можна виділити якийсь тренд, коли DevOps стають колишні програмісти. Мій досвід показує, що це не найкращі девопсы, але є і виключення. Я вважаю, що як раз із-за браку розуміння інфраструктури.

Чого робити не треба

DevOps команда завжди в меншості, а на невеликих проектах це і зовсім одна людина. Тому не варто ставити себе вище інших і вважати себе єдиним і неповторним носієм знань, недоступних іншим. Потрібно спілкуватися з командою і визначати її пріоритети, розуміти, як зручніше для всіх взаємодіяти, як оптимізувати роботу і бути єдиним цілим. Тому не рекомендую спиратися лише на теорію, виловлену з книг і статей, і намагатися нав'язати своїм колегам, а прислухатися до чужих словами і робити вибір, виходячи з потреб команди. На ранніх етапах вашої кар'єри — вже точно :)

Тим не менше навіть починаючий спеціаліст повинен бути достатньо твердим у своїх рішеннях і не йти на поводу всіх прохань і пропозицій колег по проекту. Потрібно знаходити певний баланс між командним духом і best practices, прочитаними в книгах, хоч це і непросто.

Знову ж, через те, що DevOps фахівців на проектах часто не більше одного, виникає якийсь вакуум спілкування з колегами, які цікавляться девопс-напрямком та технологіями. Незважаючи на суперечливе ставлення до профільних заходів, я рекомендую не нехтувати ними. Митапы, конференції — все це підійде, особливо, на перших етапах. Як я говорив, DevOps повинен сам займатися своїм розвитком, іноді навіть більше, ніж інші фахівці. Програмістам різного профілю простіше знайти більш досвідчених колег, які направлять і підкажуть, навіть у рамках одного проекту. З досвіду додам, що не варто ігнорувати і навички програмування. Знання архітектури Web-додатків і вміння працювати з Rest API точно знадобляться.

Що почитати

З першою книгою початківцям DevOps'ам пощастило — вона написана в художньому стилі і навряд чи коли застаріє. Це «The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win» авторства Gene Kim. Для розуміння етапів і процесів у production рекомендую «Site Reliability Engineering: How Google Runs Production Systems» Niall Richard Murphy. І книга по програмуванню — «Go in Practice: Includes 70 Techniques» , автор — Matt Butcher. Щоб бути успішним DevOps фахівцем, потрібно вміти програмувати хоча б на базовому рівні.

Антон Чудаев , TeamLead DevOps в V. I. Tech

8 років досвіду в Ops + 4 роки в DevOps

У DevOps часто приходять або з програмістів (Dev), або з адмінів (Ops). Так виходить, що це суміш і культура різних напрямків, тому і вивчати нові технології DevOps інженеру доводиться швидше, ніж пересічному айтишнику. Ще накладається залежність від конкретних технологій, використовуваних у проекті. Я раджу вивчити хоча б одну тулзу в кожній області, а вже потім розширювати і поглиблювати знання по мірі необхідності.

Публічні хмари . Обчислювальні ресурси — це основа, на яку далі все накладається. Якщо вибір припав на «Амазон» (як у більшості випадків), то дочекайтеся знижки і купіть курс за AWS за 10$. Він дасть загальне уявлення про сервіси та ресурси. Для автоматизації розгортання і підтримки інфраструктури (Infrastructure-as-Code) використовуйте нативний для AWS CloudFormation — буде простіше почати і завжди up-to-date. Якщо не «Амазон» чи не бажаєте вендор-лока, то використовуйте Terraform .

Після того як «сітку поставили», инстансы підняли, потрібно упакувати аплікацію. Тут нам допомагає контейнеризація . У цій області править Docker . Почніть з простого створення іміджів і деплоя контейнерів і вже по мірі запитів від бізнесу переходите до кластеризації та сервісів в Kubernetes .

Щоб управління і настройка сервера/сервісами були прозорими і стандартизованими, використовуйте тулзы для config-менеджменту . Мій фаворит, особливо для початківців — Ansible. Вивчайте приклади на Ansible Galaxy і пробуйте модифікувати їх на своїх повсякденних завданнях. З альтернатив — SaltStack або Chef .

Вже побудований work-flow збірки, тестування і деплоя потрібно упакувати і красиво візуалізувати за допомогою пайплайнов , наприклад ось пайплайн для Дженкінса . Це допоможе масштабувати процеси на різні енвайронменти.

Моніторинг. Стежити і підтримувати сервіси допоможе, якщо ще не впроваджений, дідок Zabbix . Також подивіться на більш нові: Prometheus або TICK Stack .

Головне завдання девопса — прискорення доставки продукту від бізнесу до споживачів. Автоматизація — це лише одне з основних коштів, а не самоціль. CI/CD, blue-green, Phoenix, Canary Deployments — це теж кошти, які виникають по мірі необхідності. Щоб це відчути, зрозуміти філософію DevOps культури, допоможуть класичні книги:

При цьому завжди потрібно дивитися в завтрашній день» і стежити за новинками, але не перевантажувати бізнес гонкою за трендами, якщо він поки ще не доріс до таких потреб.

Щоб бути в курсі новин, читайте дайджести та статті на DOU та підписуйтесь на телеграм-канали:

Hints&tips

Не вигадуйте велосипеди, пошукайте популярні рішення для завдань, так буде простіше суппортить не тільки вам.

Не ускладнюйте — робіть код, зрозумілий і простим, щоб навіть новачок зміг швидко розібратися. DevOps — це команда, а не єдиний супермозг.

Автоматизуйте, тільки те, що дійсно вже добре працює і буде використовуватися в подальшому регулярно.

Впроваджуйте нові технології тільки при дійсному їх ефект в майбутньому. Помилка на рівні архітектурі найдорожча.

Сергій Марченко , Head of IT Department в Dev-Pro

6 років досвіду в ІТ

Навколо DevOps зараз стільки галасу, що тисячі людей відразу захотіли оволодіти професією, інколи навіть не розуміючи, що потрібно робити. Я для себе малюю образ DevOps інженера як людини, в першу чергу, обізнаного в системному адмініструванні.

Мій план з рекомендаціями, як освоїти спеціальність:

Спочатку Ops, потім Dev

Замовники постійно турбуються про uptime, безпека, загалом, звичайний IT Operations нікуди не подівся. Тому спочатку знадобляться хороші знання системного адміністрування, troubleshooting і пошук bottlenecks. Infrastructure as a code, CI/CD та інше варто розглядати як продовження кар'єри системного адміністратора, а не окремий шлях.

Не варто ставати людиною, який розгортає інфраструктуру MySQL High Availability на Ansible, не розуміючи, як працює реплікація. Що вже там, іноді навіть процес резервного копіювання бази викликає питання. Вивчайте основи networking, Linux/Windows, web servers (NGINX, Apache), DBs, monitoring і тільки потім DevOps практики.

Clouds

DevOps майже дорівнює Clouds. Тому варто розібратися хоча б з одним Cloud Provider — AWS, Microsoft, Google Cloud Platform. У AWS можна зареєструвати Free Tier , якого достатньо, щоб познайомитися з цією платформою.

Automation

Під час вивчення Cloud Platforms варто звернути увагу на Configuration Management and Provisioning Tools. Я б рекомендував Ansible і Terraform. Разом з вивченням Terraform раджу дивитися на контейнери, Docker, Kubernetes — це дозволить краще зрозуміти сильні сторони Provisioning Tools.

Углиб Копайте

Важливо, щоб після лабораторної, тестового завдання, PoC, роботи на проекті не залишилося відкритих питань. Системно підходите: виписуйте питання, потім обговорюйте з колегами, читайте літературу. Головна мета — повне розуміння того, що відбувається. Чому обрали той чи інший інструмент, чому саме так написали код — у вас повинні бути відповіді на ці питання.

Пишіть код

Крім коду, який необхідно писати для розгортання нової інфраструктури, варто подумати про написання своєї програми. Тут допоможе який-небудь Pet Project. Це може бути веб-сайт, чат-бот або IoT-додаток, яке доливає воду в кавоварку (в ІТ-компаніях і не таке зустрінеш). Головне — глибше зрозуміти роботу і проблеми розробників. Для написання такої програми я б запропонував скористатися мовою, який потім стане в нагоді DevOps інженерові: Python або Golang в самий раз. У разі Go забудьте про книги, A Tour of Go — те, що ви шукайте.

Читайте чужий код

Вивчаючи Terraform, я підглянув tips and tricks, хороші практики з Terraform Module Registry. Читання чужого коду дозволяє подивитися інші практики і, якщо вони виявляться краще ваших, перейняти їх. До речі, говорячи про Terraform, я б рекомендував почати з Terraform: Up and Running .

Security

DevOps підходи прискорюють розгортання інфраструктур і додають ще більше проблем для Security Engineers. Так що варто відразу позбуватися від простих помилок, наприклад, не класти ключі і секрети у відкритому вигляді version control, трохи заглибитися в тему security. Тут вам допоможуть ключові слова DevSecOps, OWASP, Key Vault.

Спільнота

Коли ви визначитеся зі списком software, з яким ви працюєте, варто брати активну участь у житті продукту. Читати форуми (Stack Overflow), стежити за оновленнями на GitHub, можливо, навіть контрибьютить свій код.

Не вирішуйте проблеми, яких немає

AI, Big Data... в світі стільки нових течій. Як тут утриматися і не впровадити щось новеньке в свій проект. Моя порада — впроваджуйте тільки те, в чому ви дійсно потребуєте, ви повинні знати, яку проблему вирішуєте. Більшість модних технологій вам не потрібні або не підходять. You are not Google.

Максим Зінькевич , Lead Systems Engineer в EPAM Kharkiv

5 років досвіду в DevOps

DevOps не можна вивчити за книгами і курсів, а потім вийти на проект і зробити все класно. Практика і тільки практика може сформувати інженера в цьому напрямку. Потрібно бути готовим, що доведеться докладати багато зусиль і постійно долати себе, особливо в самому початку. Чим важче на початку освоєння професії, тим легше на проектах.

Ще будучи студентом, я працював системним адміністратором в різних бізнесах. Починав з Windows і Linux. Поступово перейшов до підтримки серверів і автоматизації. Коли я вперше використовував такі інструменти як Puppet, Jenkins, системи контролю версій Subversion, Git), до мене прийшло усвідомлення, що за межею сисадминистрирования є величезний світ DevOps. Щоб рухатися далі, я приєднався до EPAM. Саме тоді, 5 років тому, в компанії запускалося пілотне напрямок DevOps. Зараз ми активно розвиваємо цю компетенцію всередині компанії.

Спираючись на свій досвід, мої рекомендації починаючим фахівцям будуть виглядати так:

Насправді зараз є величезна кількість ресурсів по темі DevOps, складно порадити щось конкретне. Головне — не зупиняти процес вивчення нових технологій і закріплення актуальних.

За весь свій досвід роботи я прочитав тільки одну книгу «Безперервна інтеграція» Jez Humble, David Farley. Вона дуже легко читається і буде зрозуміла початківцям. Там ще використовуються приклади старого, але всі принципи будуть актуальні і сьогодні. Вона мені допомогла структурувати наявні знання. Решта ж — практика, актуальні статті по темі, документація і, звичайно ж, колеги.

Опубліковано: 27/09/18 @ 07:04
Розділ Різне

Рекомендуємо:

Про менталітеті датських IT-шників – розповідь українського розробника
PM дайджест #14: поради щодо підбору персоналу від Netflix, суміщення ролей тимлида і ПМа, переосмислюємо Scrum
QA дайджест #35: дослідницьке тестування API, з чого почати вивчення автоматизації та тестування атомних електростанцій
DOU Labs: як в Ukad створили Slack-бота для управління проектами
Туторіал з налаштування Rails-додатків на Amazon EC2 з Chef. Частина 1