Бути сучасним інженером DevOps — це дуже складна роль з технологічної точки зору.
Для цього потрібно знати такі поширені мови програмування, як Node.JS, пакетні сценарії, Python або пакетні сценарії. Ще одне очікування — це розуміння того, як включити автоматизацію тестування в процеси розгортання.
Як інтегратор коду в автоматизовані конвеєри, ви повинні знати принаймні базову функціональність різних хмарних сервісів.
Незважаючи на таку складність технології, технічні навички не завжди є на першому місці серед навичок, яких бракує інженерам DevOps. Незважаючи на те, що можна було б припустити, що оволодіння технічними навичками є ключовим, різні ідеї, зібрані від справжніх практиків DevOps, показують, що їхні навички програмного забезпечення часто навіть важливіші.
Важливі навички DevOps
Джерело: devopsuniversity.org
Спостереження за взаємодією інженера DevOps у команді Scrum часто є досить цікавим спостереженням. У більшості випадків вони мають дуже мало деталей про конкретний зміст історій, які впроваджує решта команди, лише через технічну інформацію про конкретні функції всередині історій для команди.
Проте вони повинні мати можливість об’єднати результат команди в єдиний працездатний конвеєр розгортання разом із виконанням і перевіркою різноманітних автоматизованих тестів.
Ось де бути технічним експертом низького рівня вже недостатньо. Спілкування стає ключовою частиною успіху. Отже, давайте розглянемо найважливіші необхідні навички DevOps.
М’які навички
Справді, саме співпраця та обговорення всередині гнучкої команди є головною причиною того, чому відсутність навичок програмного забезпечення очолює список навичок DevOps. Якщо ви все ще дивуєтеся чому, ось кілька найбільш вагомих аргументів:
- Інженери DevOps не можуть бути ефективними без адаптації до решти команди розробників. Ця команда створює основу програмного забезпечення або функцій платформи. Інженер DevOps повинен створити живе середовище для всього цього та змусити його працювати.
- Окрім синхронізації з власною командою розробників, вони є ключовим контактним пунктом для зовнішніх зацікавлених сторін, які прагнуть отримати доступ до програмної платформи. Вони повинні бути здатні розуміти такі запити та переводити всю технічну складність автоматизованого хмарного середовища в нетехнічні еквіваленти, щоб зацікавлені сторони могли їх справді зрозуміти. І бути остаточним проміжним програмним забезпеченням між командою розробників і зовнішніми зацікавленими сторонами.
- Хоча зазвичай ви можете побудувати систему навчання для набуття конкретних технічних навичок, розвиток правильних навичок спілкування вимагає від вас набагато глибшого вивчення цілісності та особистості. Щоб навчитися вчасно дивитися на себе з іншого ракурсу та визначати напрямки зростання. Це не те, що кожен може зробити з легкістю.
Мережа
Коли ви дивитеся на технологічний ландшафт сучасних хмарних платформ, не потрібно багато, щоб втратити себе. Вам потрібно впоратися зі службами файлової системи, кількома службами баз даних, серверними API, серверними або безсерверними архітектурами, зовнішніми службами, моделями машинного навчання, гібридними середовищами, віртуальними приватними мережами, балансувальниками навантаження високої доступності, різними службами потокового передавання в реальному часі та набагато більше.
Неможливо знати все про все. Але інженерам DevOps абсолютно необхідно знати, як об’єднати все це в одну функціональну програмну платформу. Необхідно створити потужну мережеву спільноту.
Пошук оптимального балансу між простотою та ефективністю комунікації розподілених систем є проблемою, про яку вони повинні знати та бути готовими надати команді рішення.
Зазвичай ви знаєте, що інфраструктура, яку ви будуєте, достатньо зріла, лише коли починаєте серйозніше займатися питаннями безпеки та проблемами платформи. І вгадайте що – це знову сфера діяльності інженера DevOps.
Замість того, щоб дотримуватися старих перевірених контактів, вам потрібно постійно шукати нових, щоб охопити нову частину послуги, яку щойно запитала ваша команда.
Тести програмного забезпечення
Особливо в Agile-світі гнучкість випусків програмного забезпечення має вирішальне значення. Можливо, у вас є сутички з двотижневими спринтами. Очікується, що кожен другий тиждень буде випускатися новий випуск.
Якщо ви подумаєте про весь життєвий цикл проекту, який включає планування, оцінку, розробку, тестування та випуск, ви не зможете досягти цього без серйозної автоматизації якомога більшої кількості цих кроків.
Основною передумовою успіху в цьому налаштуванні (і, зрештою, забезпечення швидшого часу для розгортання у виробництві) є велика увага до автоматизації тестування. Швидше розгортання разом із автоматичними тестами скорочує час для відгуків користувачів із розробниками.
Для інженера DevOps це означає інтеграцію результатів різних команд тестування в конвеєр CI/CD:
- Увімкнути виконання сценарію модульного тестування після кожного фіксування сховища. Якщо їх немає, домовтеся з розробниками про їх створення.
- Включіть інтеграційні тестові випадки в конвеєри CI/CD для розгортання в повністю інтегрованому та узгодженому тестовому середовищі. Немає сенсу запускати інтеграційні тести в кожному середовищі розробки, яке використовує команда розробників. Тестові приклади інтеграції мають працювати бездоганно в середовищі, де розгорнуто всі служби, а дані узгоджені.
- Включіть реальні наскрізні тестові випадки в конвеєр CI/CD. Зробіть його обов’язковим для кожного розгортання головного коду в інтеграційному тесті або середовищі тесту прийнятності користувача. Це гарантує, що всі важливі та критичні бізнес-процеси можуть працювати без збоїв.
Написання ефективних тестів таким чином, щоб ви не перестаралися, але також охоплювали всі критичні процеси, є ще одним завданням, яке потрібно освоїти. Інженерам DevOps не обов’язково бути тут наодинці.
Бізнес-аналітики або менеджери із забезпечення якості можуть бути частиною мережі (якщо не безпосередньо частиною команди), щоб допомогти з цим і визначити точні кроки. Але роль інженера DevOps полягає в тому, щоб перевести його в автоматизований виконуваний код.
CI/CD та інфраструктура як код
Ми вже торкалися цього в кількох місцях. Тим не менш, не можна заперечувати, що IaC (і згодом його виконання через конвеєри CI/CD) є основними результатами інженерів DevOps. Саме тут усі вхідні дані від команди розробників (у формі різноманітних функціональних можливостей сервісу) пов’язані разом із деякими реальними середовищами інфраструктури. Потім вони формують придатне для використання програмне забезпечення як результат служби, який можна багаторазово розгортати в різних середовищах.
Не дивно, що це одне з головних завдань для кожного інженера DevOps. Навіть більше, якщо вимога полягає в тому, щоб залишатися агностиком хмари, це зазвичай означає написання IaC мовою Terraform і гарантування того, що код не містить нюансів, пов’язаних із постачальником хмари. Досвід це яскраво показує. Перехід на сценарії коду хмарної інфраструктури може бути дуже складним завданням навіть для досвідчених інженерів.
Абсолютно неможливо підтримувати хмарну інфраструктуру, використовуючи лише ручні дії для розгортання. У той час це було стандартом. Але таким же чином це був надійний стандарт для доставки через водоспадні способи роботи. Немає шансів вижити з ручним розгортанням у гнучкому середовищі. Необхідно зробити перехід, який майже завжди болючий.
Але як тільки все зроблено належним чином, ви там.
- Потрібне розгортання виробництва? Просто запустіть конвеєр випуску, що містить розгортання коду для виробництва.
- Вам потрібне інше середовище розробки, щоб не накладалося на іншу роботу з розробки всередині команди? Потім знайдіть конвеєр розробки та натисніть кнопку «Виконати». Уся інфраструктура розробки буде виконана та створена автоматично, включаючи тестові дані.
- Коли потреба в існуванні середовища зникає, той самий конвеєр розробки може виконувати команди знищення для всіх служб, які раніше були розгорнуті в середовищі.
Для успішної команди Agile неминуче впроваджувати інфраструктуру як код і розміщувати її в конвеєрах CI/CD, які можуть виконувати роботу будь-коли та щоразу. Інженери DevOps тут, щоб це зробити.
Контейнерізація
Джерело: aws.amazon.com
У великомасштабних проектах можливість швидкого тиражування має вирішальне значення. Одночасне створення сотень копій одного й того самого середовища було б неможливим без контейнерних середовищ. Контейнерізація — це навичка, яка потребує крутого навчання. Це також причина, чому лише кілька проектів насправді використовують його серйозно.
Контейнерний сервер — це шаблон, який потрібно застосовувати так часто, як це необхідно, і результат завжди буде однаковим. Ідентична інфраструктура та ідентичні дані. Це властивість, яку можуть створити для команди лише інженери DevOps. Їм потрібно навчитися створювати це за допомогою різних інструментів.
Контейнери розроблені таким чином, щоб їх було легко створювати та знищувати. Інженери DevOps повинні впровадити інструменти оркестровки контейнерів, такі як Kubernetes або Docker Swarm, які можуть автоматично керувати розгортанням контейнера, масштабуванням і відновленням.
Контейнери використовують ту саму операційну систему хоста. Якщо один контейнер скомпрометовано, він потенційно може скомпрометувати інші контейнери на тому самому хості. Крім того, якщо контейнери створені зі сторонніх образів, вони можуть містити вразливості в коді. Інженери DevOps докладуть зусиль для впровадження таких функцій безпеки, як ізоляція контейнерів, контроль доступу та сканування вразливостей, щоб зменшити ці ризики.
Масштабованість є ще однією рідною властивістю контейнерів. Ви можете легко масштабувати їх горизонтально, щоб впоратися зі збільшеним навантаженням. Це може призвести до суперечок за ресурси та проблем з продуктивністю. Інженери DevOps мають запровадити такі інструменти керування ресурсами, як контрольні групи або квоти ресурсів Kubernetes, які можуть обмежити кількість ресурсів, які може споживати кожен контейнер.
Інженери DevOps повинні підходити до контейнеризації з урахуванням безпеки, масштабованості та стійкості. Серед усіх інших технічних навичок, опанування контейнеризації вимагає особливо крутої кривої навчання. Просто складність занадто висока. Це також причина, чому лише кілька проектів насправді використовують його серйозно.
Висновок
Практик DevOps є унікальним членом вашої гнучкої команди. Ви можете мати лише один або два з них для всього проекту, але навіть тоді вони будуть вирішальними для успіху.
Очікування від інженерів DevOps високі, оскільки їм потрібно виконувати багато ролей одночасно:
- Вони повинні бути сильними технічними розробниками,
- командні гравці, сповнені емпатії, розуміння та готовності до співпраці,
- ефективне проміжне програмне забезпечення між командою розробників і нетехнічними зовнішніми зацікавленими сторонами,
- підключення всієї команди для автоматизації та перевірки тестування коду,
- забезпечення регулярних випусків проекту,
- і послідовне створення мережі експертів, яка змінюється день у день.
Незважаючи на всю технічну складність, саме людський фактор відіграє вирішальну роль в успіху будь-якої ініціативи DevOps. Якщо ви на порозі стати одним із них, ви маєте повне право пишатися своїм рішенням і розглядати підхід до освіти з набагато ширшої точки зору, не обмежуючись лише технічними знаннями.
Далі перегляньте поширені запитання та відповіді на інтерв’ю DevOps.