В ідеальному світі розробники, тестувальники та DevOps-інженери злагоджено працюють разом, інфраструктура завжди стабільна, процеси ніколи не ламаються, а технології обираються тільки за стандартами індустрії. Втім, реальність не така чудова, й різні фахівці часто зіштовхуються з однаковими проблемами.
Про найпоширеніші болі DevOps-інженерів, робочі процеси, вибір технологій та загальне розуміння методології розповів Микита Глушак, DevOps Team Lead в Solidgate, партнерській компанії Genesis. Микита вісім років працює в ІТ-індустрії, шість з яких — на посаді DevOps-інженера. Уже понад рік він керує інфраструктурною командою в Solidgate та разом з колегами налагоджує інженерні процеси в компанії.
БІЛЬ №1
Технології, обрані на початку роботи, стають проблемою у довгостроковій перспективі.
Обираючи нові інструменти, DevOps-інженер відповідає собі на питання: «Зараз потрібно спроєктувати цілісну систему чи вирішити конкретне завдання?» Буває так, що на старті роботи ви обрали технічне рішення, бо воно було не дорогим, нескладним або задовольняло конкретні потреби. Ви почали ним користуватися, команда адаптувала його під свої потреби, але з часом на ринку з’явилися нові технології, які краще підходять під ваші запити. Нові та старі підходи не завжди добре поєднуються між собою.
Наприклад, для поглибленого моніторингу наших систем ми використовуємо продукт Elastic APM. Раніше він ефективно вирішував наші завдання, але коли бізнес масштабувався, а вимоги до системи змінилися, ми звернули увагу на юзабіліті стеку і на те, як всі елементи інтегруються між собою. Саме ця система не достатньо гармонійно поєднувалася з іншими, й мала чужорідний вигляд в інфраструктурі. Попри те, що вона добре функціонує, її несумісність з іншими елементами стала проблемою.
У такому випадку DevOps-інженер має два варіанти: писати «костилі», або змінювати інструмент, а це буває ще болісніше, ніж щось «костилити». Втім, ми все ж таки обрали другий варіант та розглядаємо альтернативні продукти, які повністю відповідатимуть нашим потребам і зараз, і у майбутньому.
БІЛЬ №2
Технології, з якими хочеться працювати, не відповідають потребам і обставинам у бізнесі.
Наприклад, команда працює з SAAS-рішеннями від Google чи Azure, але є альтернативні варіанти від інших вендорів, які виглядають цікавіше — за ціною, кількістю фіч, наявністю інтеграцій з іншими продуктами. Здавалося б, чому просто не перейти на них?
Причини відмови від будь-якого «цікавого» продукту чи інструменту можуть бути різними: від вимог комплаєнсу та нестачі необхідних сертифікатів до відсутності певних фіч чи підтримки технічного стека, який використовується в компанії.
БІЛЬ №3
Документація до інструментів написана не для тих, хто вперше знайомиться з ними.
У роботі DevOps-інженерів бувають специфічні завдання, пов’язані з даними, як-от забезпечення обміну даними між різними системами або їх трансформація у режимі реального часу. Для подібної задачі потрібно налаштувати data-пайплайн за допомогою специфічних інструментів, наприклад, Apache Airflow, ETLworks, Matillion.
Розгортання подібних продуктів може стати справжньою проблемою, бо часто процес зводиться до варіанту «на колінці», й навіть невеличкий крок убік від такого сценарію приводить до годин дебагінгу. І якщо розібратися в документації, щоб налаштувати пайплайни даних, ще вийде, то проблеми з експлуатацією, масштабуванням та підтримкою можуть стати викликом для всіх користувачів.
БІЛЬ №4
DevOps-інженери складають документацію до внутрішніх інструментів, але команді зручніше запитати напряму.
Впроваджуючи нові інструменти, технології або процеси, DevOps-інженери супроводжують їх записами в базі знань з прикладами використання, описом роботи інструмента тощо. Завдяки документації розробники, тестувальники та інші учасники процесу мають уявлення про процеси, інструменти та конфігурації, що використовуються в компанії, код розгортається узгоджено, а кількість помилок зменшується.
Саме завдання не можна назвати цікавим, проте DevOps витрачає на нього час та зусилля: намагається описати процес якомога зрозуміліше, аби документом могли користуватися навіть ті, хто тільки-но приєднався до компанії.
Однак трапляється так, що розробник почав працювати з новим інструментом, але з документацією не ознайомився. Як наслідок, він приходить до DevOps-інженера з питаннями, які або уже описані, або легко гугляться. Подібний підхід непродуктивний, бо затягує реалізацію продукту.
Втім, це не завжди свідчить про ігнорування або неуважність. Подібні випадки трапляються під час зміни інструментів, перебудови процесів або поповнення у команді. Процес адаптації буває болючим для всіх, але з часом все налагоджується.
БІЛЬ №5
До DevOps-інженерів звертаються з питаннями, які знаходяться в зоні відповідальності інших команд.
Навряд чи вийде знайти компанію, де методологія DevOps інтегрована у чистому вигляді. Але коли відділ системних адміністраторів просто перетворили на департамент DevOps — це проблема. Так само й навпаки: неправильно перекладати на команду DevOps завдання, які мають виконувати системні адміністратори. Це як мінімум дорого, як максимум — неефективно.
Через погане розуміння методології час команди, яка мала б займатися оновленням інфраструктури, підвищенням її витривалості або рефакторингом, може розпорошуватися на завдання на кшталт «поламаної» електронної пошти або налагодження Wi-Fi. Це не означає, що проблема з мережею менш важлива — просто вона знаходиться в зоні відповідальності іншої команди.
Зараз тенденція втішна: все більше компаній розуміють, чим саме займаються DevOps, а межа між ними та системними адміністраторами розмивається здебільшого в маленьких або «молодих» бізнесах.
БІЛЬ №6
Код, який передають у роботу, неперевірений чи містить помилки.
Цей біль стосується задач, коли підготувати інфраструктуру потрібно на основі результатів роботи розробників. Наприклад, вони написали код для нового сервісу, а DevOps-інженери готують під нього платформу на AWS, підіймають базу даних або роблять зміни в уже наявній системі. Коли ви вже розгортаєте ПЗ, виявляється, що код «сирий» — він не виконується або падає з незрозумілими помилками.
Через це процес, який мав би працювати як безперебійний конвеєр, ламається. Доводиться писати розробникам, з’ясовувати, в чому проблема, перевіряти все наново — і витрачати на це робочий час як мінімум двох фахівців.
БІЛЬ №7
Загальний та короткий запит.
DevOps-інженер прагне автоматизувати більшість процесів, але деякі задачі, як-от, видача доступів, автоматизувати складніше. Відволікатися від нагальних завдань на подібні запити — не найприємніша частина роботи, особливо якщо ТЗ для завдання надано некоректно. Ідеально, коли людина чітко, по пунктах описує — навіщо їй доступ, якого рівня, тривалий чи постійний. Тоді все просто й ефективно.
Окреме розчарування — коли DevOps створює шаблон в Jira з полями, які слід заповнити, а отримує запит з описом в один рядок. Доводиться звертатися за уточненнями та деталями — а це теж гальмує роботу.
БІЛЬ №8
Завдання, пов’язані з оптимізацією фінансів.
Один з прикладів подібного завдання — оптимізація хмарної інфраструктури для мінімізації витрат. Така задача може вимагати спеціальних навичок, заглиблення в особливості різних інструментів інфраструктури, а ще — вона менш цікава, порівняно з розгортанням ПЗ. Але я не можу сказати, що це біль всіх DevOps-інженерів — радше, окремих представників професії. До того ж завдання має суттєву приємну частину — приносити керівникові гарні новини про те, що твоя оптимізація зекономила компанії купу грошей.
