У випадку, коли програма не працює, найменше хочеться почути від колег фразу «проблема на вашому боці». В результаті страждають користувачі - а їм неважливо, яка частина команди несе відповідальність за поломку. Культура DevOps з'явилася якраз для того, щоб поєднати розробку і підтримку та об'єднати їх навколо спільної відповідальності за кінцевий продукт. Які практики входять в поняття DevOps і навіщо вони потрібні? Чим займаються DevOps-інженери і що вони повинні вміти? На ці та інші питання відповідають експерти з EPAM: Кирило Сергєєв, системний інженер і DevOps-євангеліст, та Ігор Бойко, провідний системний інженер і координатор однієї з DevOps-команд компанії.
Для чого потрібен DevOps?
Раніше між розробниками і підтримкою (т.зв. operations) існував бар'єр. Звучить парадоксально, але у них були різні цілі і KPI, хоча вони й працювали над спільним проектом. Метою розробки було якомога швидше реалізувати бізнес-вимоги і додати їх в працюючий продукт. Підтримка відповідала за ту частину, яка дозволяє додатку стабільно працювати, а будь-які зміни можуть поставити стабільність під загрозу. Це явний конфлікт інтересів - DevOps з'явився для того, щоб це вирішити.
Хто такий DevOps?
Це питання хороше і дискусійне: остаточно в світі про це поки не домовились. В EPAM вважають, що DevOps об'єднує в собі технології, процеси та культуру взаємодії всередині команди. Це об'єднання націлене на безперервну доставку цінностей кінцевим користувачам.
Кирило Сергєєв: «Розробники пишуть код, тестувальники його перевіряють, а адміністратори встановлюють фінальний продукт на виробниче оточення. Доволі довгий час ці частини команди були дещо роз’єднані, і з часом з'явилася ідея об'єднати їх одним загальним процесом. Так з'явились DevOps-практики».
Настав той день, коли розробники і системні інженери зацікавилися роботою один одного. Бар'єр між продакшеном і підтримкою зменшувався. Так з'явився DevOps, в який входять практики, культура і порядок взаємодії в команді.
В чому саме полягає суть DevOps-культури?
Відповідь у тому, що відповідальність за кінцевий результат лежить на кожному з команди. Найцікавіше і складне в філософії DevOps - зрозуміти, що конкретна людина не просто відповідає за свій етап роботи, а несе відповідальність за те, як буде працювати весь продукт. Проблема не лежить на комусь одному - вона загальна, і кожен з команди допомагає її вирішити.
Найважливіший принцип DevOps-культури - саме вирішувати проблему, а не просто застосовувати DevOps-практики. Більш того, ці практики впроваджують не “на чиїйсь стороні”, а у весь продукт. Проекту потрібен не сам по собі DevOps-інженер - йому потрібне рішення проблеми, а роль DevOps-інженера може бути розподілена між кількома членами команди з різною спеціалізацією.
Які бувають DevOps-практики?
DevOps-практики покривають всі етапи життєвого циклу ПЗ.
Ігор Бойко: «Ідеальний кейс - коли ми починаємо застосовувати DevOps-практики прямо при ініціації проекту. Разом з архітекторами ми плануємо, який саме буде архітектурний ландшафт у додатку, де що буде розташовано і як буде масштабуватись, також вибираємо платформу. Зараз популярна мікросервісна архітектура – і для неї ми обираємо систему оркестрації: потрібно вміти управляти кожним елементом програми окремо і оновлювати його незалежно від інших. Ще одна практика - це "інфраструктура як код". Так називають підхід, при якому інфраструктура проекту створюється і управляється за допомогою коду, а не через пряму взаємодію з серверами.
Наступним етапом ми переходимо до етапу розробки. Тут одна з найбільших практик - побудова CI / CD: потрібно допомогти розробникам інтегрувати зміни в продукт швидко, дрібними порціями, частіше і “безболісно”. CI / CD покриває і перевірку коду, заливку майстра в кодову базу, і розгортання програми на тестових та продуктивних середовищах.
На етапах CI / CD код проходить через quality gates. За їх допомогою перевіряють, щоб код, який вийшов з робочої станції розробника, відповідав заданим критеріям якості. На даному етапі додається юніт- і UI-тестування. Для швидкого, безболісного і сфокусованого розгортання продукту можна обрати відповідний тип деплоймента.
DevOps-практикам є місце і на етапі підтримки готового продукту. Їх застосовують для моніторингу, зворотного зв'язку, безпеки, впровадження змін. На всі ці завдання DevOps дивиться з точки зору постійних поліпшень. Ми зводимо до мінімуму повторювані операції, автоматизуємо їх. Сюди ж відносяться міграції, розширення програми, підтримка працездатності».
Чим корисні DevOps-практики?
Якби ми писали підручник з сучасних практик DevOps, на його першій сторінці значилися б три пункти: автоматизація, прискорення релізу і швидкий зворотний зв'язок від користувачів.
Кирило Сергєєв: «Перше - це автоматизація. Всі взаємодії в команді ми можемо автоматизувати: написали код - викотили - перевірили - встановили - зібрали фідбек - повернулися на початок. Все це - автоматично.
Друге - прискорення виходу релізу і навіть спрощення розробки. Замовнику завжди важливо, щоб продукт вийшов на ринок якнайшвидше і почав приносити користь раніше, ніж аналоги конкурентів. Процес доставки товару можна нескінченно покращувати: скорочувати час, додавати більше контрольних міток, удосконалювати моніторинг.
Третє - це прискорення зворотного зв'язку від користувача. Якщо у нього є зауваження, ми можемо відразу вносити зміни і тут же оновлювати додаток».
Як співвідноситься "системний інженер ", "білд інженер" та DevOps-інженер"?
Насправді вони перетинаються, але відносяться до різних сфер.
Системний інженер в EPAM - це посада. Вони бувають різних рівнів: від джуніора до chief-спеціаліста.
Білд-інженер - це скоріше роль, яку можна виконувати на проекті. Зараз так називають людей, які відповідальні за CI/CD.
DevOps-інженерами називають фахівців, що впроваджують на проекті DevOps-практики.
Якщо все це підсумувати, отримаємо: спеціаліста, який займає посаду системного інженера, виконує на проекті роль білд-інженера і займається упровадженням DevOps-практик.
Чим саме займається DevOps-інженер?
DevOps-інженери поєднують в одне ціле всі частини, з яких складається проект. Вони знають специфіку роботи програмістів, тестувальників, системних адміністраторів і допомагають спростити їх роботу. Вони розуміють потреби і вимоги бізнесу, його роль в процесі розробки - і будують процес з урахуванням інтересів замовника.
Ми багато говорили про автоматизацію - автоматизацією DevOps-інженери займаються в першу чергу. Це дуже важливий аспект, в який також входить підготовка середовища.
Кирило Сергєєв: «Перш ніж впроваджувати оновлення в продукт, його потрібно протестувати на сторонньому середовищі. Його готують DevOps-інженери. Вони ж відповідають за DevOps-культуру на проекті в цілому: впроваджують DevOps-практики на всіх етапах своїх проектів. Ці три принципи: автоматизація, спрощення, прискорення - вони привносять всюди, де є потреба».
Що повинен знати DevOps-інженер?
Насамперед у нього повинні бути знання з різних сфер: програмування, робота з операційними системами, базами даних, системами збірки та конфігурацій. До цього переліку варто додати вміння працювати з хмарною інфраструктурою, системами оркестрації, моніторингу.
1. Мови програмування
DevOps-інженери знають кілька базових мов для автоматизації та можуть, наприклад, сказати програмісту: «Давай ти будеш робити установку коду не руками, а за допомогою нашого скрипта, який все автоматизує? До нього ми підготуємо config-файл, його буде зручно читати і тобі, і нам - і ми в будь-який момент зможемо його змінити. А ще ми будемо бачити, хто, коли і для чого вносить до нього зміни».
DevOps-інженер може вивчити одну або декілька з цих мов: Python, Groovy, Bash, Powershell, Ruby, Go. Знати їх на високому рівні не потрібно - досить основ синтаксису, принципів ООП, вміння писати нескладні скрипти для автоматизації.
2. Операційні системи
DevOps-інженер повинен розуміти, на якому сервері буде встановлено продукт, в якому середовищі буде запускатися, з якими сервісами буде взаємодіяти. Можна вибрати спеціалізацію на Windows або Linux.
3. Системи контролю версій
Без знань систем контролю версій DevOps-інженеру нікуди. Git - одна з найпопулярніших систем зараз.
4. Хмарні провайдери
AWS, Google, Azure - особливо, якщо ми говоримо про Windows-напрямок.
Кирило Сергєєв: «Хмарні провайдери надають нам віртуальні сервери, які прекрасно лягають на рейки CI / CD.
Установка десяти фізичних серверів вимагає близько ста ручних операцій. Кожен сервер потрібно вручну запустити, встановити і налаштувати потрібну операційну систему, встановити наш додаток на цих десяти серверах, а потім десять раз ще все перевірити. Хмарні сервіси замінюють цю процедуру десятьма рядками коду і хороший DevOps-інженер повинен уміти ними оперувати. Так він економить час, сили і гроші - і для замовника, і для компанії».
5. Системи оркестрації: Docker і Kubernetes
Кирило Сергєєв: «Віртуальні сервери розділені на контейнери, в кожен з яких ми можемо встановити наш додаток. Коли контейнерів багато, треба ними керувати: один включити, інший вимкнути, десь зробити бекапи. Це стає досить складною справою, для якої потрібна система оркестрації.
Раніше кожним додатком займався окремий сервер - будь-які зміни в його роботі могли вплинути на роботу додатку. Завдяки контейнерам додатки стають ізольованими і запускаються окремо - кожен на своїй віртуальній машині. Якщо відбувається збій, не потрібно витрачати час на пошук причини. Простіше видалити старий контейнер і додати новий».
6. Системи конфігурацій: Chef, Ansible, Puppet
Коли необхідно обслуговувати цілий парк серверів, доводиться робити багато однотипних операцій. Це довго і складно, а ще ручна робота підвищує шанс помилки. Тут на допомогу приходять системи конфігурацій. З їх допомогою створюють скрипт, який зручно читати і програмістам, і DevOps-інженерам, і системним адміністраторам. Цей скрипт допомагає проводити однакові операції на серверах автоматично. Так ручних операцій (і, отже, помилок) стає менше.
Яку кар'єру може побудувати DevOps-інженер?
Розвиватися можна і горизонтально, і вертикально.
Ігор Бойко: «З точки зору горизонтального розвитку, у DevOps-інженерів зараз найширші перспективи. Все постійно змінюється, і покращувати власні навички можна за найрізноманітнішими напрямами: від систем контролю версій до моніторингу, від управління конфігураціями до баз даних.
Можна стати системним архітектором, якщо спеціалісту цікаво розібратися, як працює додаток на всіх етапах свого життєвого циклу - від розробки до підтримки».
Як стати DevOps-інженером?
- Прочитайте книги «Проект "Фенікс"» і DevOps Handbook. Це справжні стовпи філософії DevOps, причому перша - художній роман.
- Приєднайтесь як DevOps-інженер на опенсорс-проект.
- Практикуйте і пропонуйте DevOps-практики на своїх особистих і робочих проектах.
- Вивчайте технології з нашої Підбірки матеріалів для DevOps.
Приєднуйтеся до навчальних програм для DevOps у EPAM University Program.
