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

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

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

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

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

TCP/IP — дуже важливо розуміти, як працює мережа (класичний питання на співбесіді — Що насправді відбувається, коли користувач забиває в браузер адреса google.com ). Ось Cisco CCNA курс , достатньо саме TCP/IP розділу.
Linux (дистрибутив не має значення, головне — свіжий). Особисто мені дуже допомогла в свій час розуміння, що відбувається під капотом під час завантаження операційної системи. «Linux from Scratch» , — напевно, найкраще з безкоштовного, але доведеться повозитися.
Python — напевно, самий простий у вивченні і одночасно самий затребуваний мова в світі DevOps і не тільки.
AWS — хмарна інфраструктура, яка дуже сильно спрощує життя DevOps інженеру, беручи на себе велику частину рутинних завдань. При цьому так званий AWS Free Tier дає можливість новачкам абсолютно безкоштовно помацати левову частку сервісів. Для мене ідеальним у вивченні виявився курс AWS Certified Solutions Architect — гайд до нього .

Це далеко не все, але достатньо для впевненого старту. А попереду 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:

Зовсім базові знання —Computer Science . Будь-яка робота в області інформаційних технологій передбачає базові знання в області комп'ютерних наук. Якщо в інституті цей предмет «не зайшов», то можна подивитися курс CS101 від Stanford University — він знаходиться у вільному доступі і дає хороше розуміння основ.
Scripting basics — без написання скриптів у вік тотальної автоматизації ніяк не обійтися, тому не потрібно боятися командного рядка і написання власних скриптів. Якщо щось потрібно зробити більше, ніж один раз, це потрібно автоматизувати.
Для тих кому світ Linux Shell зовсім не відомий: Intro to Bash , Bash scripting tutorial .
CI/CD — безперервна інтеграція і доставка додатків зараз тісно пов'язана з поняттям DevOps, тому необхідно розуміти, що це таке і для чого потрібно. Концепція чудово описана в книзі Фаулера «Continuous Delivery». Якщо книгу не дістати, то основні концепції описані у автора на сайті (сайт взагалі весь хороший, раджу прочитати від і до).
Інструментарій для безперервної інтеграції досить різноманітний, але лідирує з великим відривом Jenkins , тому раджу почати вивчення саме з нього. Разом з цим вкрай бажано ознайомитися з системами складання тих мов, з якими планується працювати, так як це одна з точок дотику з розробниками (Maven/Gradle/sbt/CMake etc.).
Clouds — сучасна інфраструктура вже давно вийшла за межі дата-центрів. Тому без досвіду/знань провайдерів хмарних зараз мало що можна зробити. Благо великі провайдери надають пробні періоди на доступних умовах і спробувати, що таке хмара, можна легко. А головне, що безкоштовні плани можна використовувати для вивчення різних інструментів і відточування навичок.
AWS надає 1 рік використання деяких типів ресурсів абсолютно безкоштовно (але потрібно налаштувати оповіщення на можливу оплату, так як доступні і платні ресурси, які через незнання можна випадково запустити).
Google Cloud дає кредит $300 терміном на один рік на будь-які ресурси — цього цілком достатньо для навчання.
Microsoft Azure — $200 на місяць — трохи часу, але достатньо, якщо потрібно просто познайомитися з системою.
Infrastructure automation — автоматизація створення інфраструктури тісно переплітається з поняттям infrastructure-as-a-code. Опис інфраструктури кодом намагається вирішити проблему повторюваності, тестування і рев'ю, тобто застосувати принципи CI/CD рівня інфраструктури (посилання на Фаулера ).
З інструментарію найбільш популярними, напевно, є поделия на коліні і Terraform — до нього-то і варто придивитися.
Configuration management — створення повторюваної і передбачуваною налаштування системи/додатків. Також більшість інструментів з цієї області можуть використовуватися для автоматизації доставки додатків (deployment automation). Вивчення варто почати з Ansible, так як у нього нижчий поріг входження. Але також слід порівняти його зі схожими інструментами, такими як Chef і Puppet.

Інструментарію та областей, які зараз входять в 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 культури, допоможуть класичні книги:

«The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win» by Gene Kim, Kevin Behr, George Spafford;
«The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations» by Gene Kim, Patrick Debois, John Willis, Jez Humble;
«Site Reliability Engineering» edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy.

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

Щоб бути в курсі новин, читайте дайджести та статті на 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. Зараз ми активно розвиваємо цю компетенцію всередині компанії.

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

Вибирайте роботодавця і проекти, які будуть вас професійно формувати. Всі мої зміни роботи були продиктовані виключно бажанням розвиватися. Як тільки відчуваєте, що починаєте деградувати — міняйте роботу.
Не бійтеся братися за нові або складні проекти, які вище вашого рівня. А краще всього відразу підключатися до декількох проектів. Такий активний режим дуже допоможе у прокачуванні практичних знань і навичок. Але не забувайте про балансі, щоб швидко не перегоріти.
Задавайте питання вашій ментору/ліду проекту/тимлиду. Якщо протягом двох днів ви не поставили питання з того, що вам незрозуміло — ви втратили два дні в пізнанні професії, і комусь доведеться переробляти вашу роботу. Відкиньте сором, абсолютно всі починали так само, як і ви. Будьте ініціативні та допитливі.
Вчіться на своїх помилках. Завершили проект — проаналізуйте, що було зроблено добре, а що можна і потрібно поліпшити. Підхід continuous improvement повинен стати невід'ємною частиною проектної роботи.
Вивчіть або доучите такі нескладні мови програмування, як Ruby і Python. Python і так давно вже використовується в системному адмініструванні. Чому Ruby? Системи автоматизації Puppet і Сhef використовують DSL, заснований на Ruby, тому деякі тонкі речі доведеться писати на цій мові. Хоч програмування в основному і функціональний, але без основ об'єктно-орієнтованого програмування розвиватися в DevOps буде складно.
Слідкуйте за авторами та читайте профільні матеріали на Habr і DZone . Там же є підкасти і відео.
Пройдіть навчальні курси на Coursera іCodecademy.com.

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

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

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

SEO Блог