Хто такий DevOps

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Всім привіт!

На зв’язку Rist і це перша стаття з серії «Who is who in IT?» в яких ми будемо говорити з різними спеціалістами, щоб дізнатись хто вони та за що відповідають на проектах.

Сьогодні з нами Володимир Шинкар — DevOps Engineer в Intellias.

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

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

А відео з Володимиром можете переглянути тут.

Хто такий DevOps? Чим займається?

DevOps інженери, або просто девопси, беруть участь у всіх етапах життєвого циклу продукту. DevOps — це не посада, а назва методології.

Ціль інженера на проекті — тісна кооперація між командами розробників задля зближення їхніх робочих процесів одне з одним і, як результат, допомогти організаціям скоротити час, за який програмний продукт потрапить до кінцевого користувача.

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

• Безперервну доставку коду (збірка, тестування та розгортання)
• Конфігурування та розгортання інфраструктури (частіше за допомогою коду)
• Автоматизація всіх процесів життєвого циклу продукту
• Налаштування хмарних сервісів, мережі, та зв’язків між ними
• Моніторинг та централізоване логування
• Безпеку всього, що є на проекті

Це далеко не весь список активностей, які входять до DevOps процесів. Все дуже залежить від проекту та від клієнта.

Часто можна зустріти DevOps інженерів з окремою спеціальністю, на кшталт:

• Release Engineer
• Infrastructure Engineer
• SRE — це інженер, який відповідає за стабільність та надійність продукту
• DevSecOps — новоутворення, яке останнім часом набирає популярності. Це інженер, який відповідає за безпеку та все, що з нею пов’язано, її впровадження на кожному етапі розробки та інфраструктури загалом

Як зрозуміти, що на проекті потрібний DevOps?

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

Ось кілька сигналів, які дозволять зрозуміти, що на вашому проекті необхідний DevOps:

• Клієнт бажає пришвидшити процеси в команді
• Чи частіше робити релізи. Бо від цього буде залежати прибуток
• Немає чіткого розуміння, як все налаштовано. Це часто призводить до великих рахунків за інфраструктуру, при невеликому проекті
• Розробники витрачають багато часу на доставку коду та нефункціональні вимоги, по типу налаштуваннями хмарних сервісів чи CI процесів
• Часті нестабільні релізи. Трапляються випадки, що реліз відбувається вручну
• Часті поломки продакшину після релізу. Особливо актуально, коли на проекті немає дев середовища, а є тільки продакшн. Відповідно шанс, що піде щось не так, дуже високий. А також на реліз виділяється кілька годин замість кількох хвилин
• Страх перед релізами. Релізи не повинні відбуватися раз в ніколи. Вони мають бути часті, надійні та в ідеалі — непомітні для кінцевого користувача

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

Як зрозуміти, що DevOps справляється з роботою? (метрики, сигнали, показники)

В основному можна виділити кілька речей, з яких можна зрозуміти, що DevOps справляється з покладеними на нього завданнями, а саме:

• скорочення часу між попаданням змін в репозиторії і завершенням збірки з усіма перевірками, тестами та артефактами — білд
• скорочення часу попадання змін на продакшн — деплой
• зменшення кількості проблемних білдів
• хороша видимість поточного стану продукту (моніторинг та логування)
• відсутні систематичні дрібні проблеми з інфраструктурою.

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

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

Які активності часто зустрічаються на проектах?

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

Зазвичай на цих проектах все більш-менш налагоджено і його роль підтримувати або добавляти нові сервіси та покращувати СІ процес.

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

Зрідка трапляються проекти, на яких вже є команда DevOps інженерів, яка розширюється по мірі росту продукту. Це дуже хороша можливість отримати величезний досвід та завжди є з ким порадитись.

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

З ким DevOps найчастіше комунікує? Як полегшити комунікацію?

Найчастіше доводиться комунікувати з розробниками. Немає нічого супер стабільного і проблеми трапляються завжди. Чи то білд впав, чи то застосунок не працює. Будь-які проблеми, пов’язані зі стабільністю інфраструктури, зазвичай адресуються в сторону DevOps інженерів. Звісно, крім випадків, коли є супорт команда і різні рівні підтримки.

В таких ситуаціях часто починається гра «в кого м’ячик», а точніше на чиїй стороні проблема.

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

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

У великих проектах все трохи складніше. Через велику кількість звернень, з’являється проблема фокусу над пріоритетними завданнями. Тут в допомогу приходить система запитів (нпр. Jira чи ServiceNow). Людина, в якої є питання чи проблема, створює запит з відповідним пріоритетом та описом, і по мірі доступності інженера чи команди, він береться в роботу. Таким чином, можна буде оцінити продуктивність команди та кількість проблем на проекті.

Але на жаль, такі процеси ускладнюють комунікацію.

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

Які труднощі виникають?

«В мене локально працює☺». Напевно кожен це чув.

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

От коли ти випадково «дропнув прод базу» (простіше кажучи: видалив всі дані з продакшн бази даних) і в тебе немає резервної копії — це просто фіаско ☺ і тут без коментарів.

Часто виникають спірні моменти, хто за що і за які частини проекту відповідає. DevOps інженери кажуть, що це має бути реалізовано в застосунку, розробники кажуть, що інфраструктура має за них це робити. До прикладу, «хардкод» змінних в коді, без можливості їх перезапису, чи перекидання вини за нестабільну роботу в сторону середовища, до прикладу, в Kubernetes кластері.

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

Які поради для менеджерів, розробників, тестерів від DevOps інженера?

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

Про яких ще спеціалістів в ІТ хочете дізнатись? Пишіть у коментарях, поширюйте друзям та до зустрічі! 🖐

P.S. Відео можна переглянути тут.