Site icon #спільно

Введення в DevOps: основні концепції

Коротка екскурсія по світу DevOps, в якій ми розповімо про топології, практики, культуру та взаємодію команд. DevOps (Development Operations) – це популярна методологія, яку застосовують, щоб підвищити продуктивність компанії – незалежно від того, в якій галузі вона працює. З кожним днем ​​все більше компаній запроваджують у себе цю модель.

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

Хочете стати DevOps Engineer?

ITEA пропонує навчання DevOps онлайн https://onlineitea.com.ua/course/devops/ розроблене для фахівців-практиків, які хочуть підвищити свою кваліфікацію й зануритися у вивчення DevOps-процесів. На курсі ти навчишся впроваджувати CI/CD-процеси в повсякденну роботу, розуміти принципи розробки програмного забезпечення й комбінувати основні сервіси AWS.

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

Зміст

  • Що таке DevOps
  • Звідки взявся DevOps
  • Культура DevOps
  • DevOps-практики
  • Безперервна інтеграція (Continuous Integration, CI)
  • Безперервне постачання (Continuous Delivery, CD)
  • Безперервне тестування (Continuous Testing)
  • Безперервний моніторинг (Continuous Monitoring)
  • Інфраструктура як код (Infrastructure as Code, IaC)
  • Мікросервіси (Microservices)
  • Топології DevOps
  • Співпраця Dev- та Ops-команд
  • Розподілені операційні обов’язки
  • Ops як «інфраструктура як послуги»
  • DevOps як зовнішній сервіс
  • DevOps-команди «на вимогу»
  • Команда захисту DevOps
  • SRE-команда
  • Співробітництво на основі контейнерів
  • Співпраця Dev та DBA
  • Ключові переваги DevOps
  • DevOps виходить за рамки бізнес-моделі

Що таке DevOps

Раніше в IT були окремі команди розробки (developers, Dev-команда) та супроводу, або підтримки (operations, Ops-команда). У цих команд були різні керівники, обов’язки та цілі. Багато компаній вони навіть працювали на різних поверхах і майже не перетиналися.

Така культура розрізненості заважала співпрацювати, а зону відчуженості вони долали лише у разі крайньої потреби. Загалом, на той час працював принцип «відправ софт через сітку на інший бік поля».

Успіхи DevOps допомогли зламати цю стіну. Тепер ці команди:

  • працюють спільно;
  • поділяють обов’язки;
  • разом відповідають за кожну частину ПЗ протягом його життєвого циклу.

Сьогодні DevOps широко використовується у IT-індустрії. Цій методології довіряють навіть техногіганти на кшталт Amazon, Google, Netflix та BMC Software. І все частіше компанії замислюються, як поширити принципи DevOps на всю організацію, тобто використовувати їх не тільки в IT.

Звідки взявся DevOps

До 2000 року більшість IT-компаній застосовували лінійний підхід до розробки ПЗ – каскадну модель , або «водоспад» (waterfall).

За такого підходу:

  • безліч часу розробників йшла на те, щоб написати і зв’язати між собою великі фрагменти коду;
  • тестувальники та команда супроводу працювали роз’єднано та витрачали більше часу на перевірку цього коду.

У результаті випуску ПО утворювалися великі перерви (іноді кілька років). А саме воно часто виходило забагованою, і ці баги затикали численними патчами між випусками.

З появою методології Agile галузь перейшла до ітеративної розробки з більш частими релізами. Безперервна інтеграція (Continuous Integration, CI) , що заробили в цій моделі, і  безперервне постачання (Continuous Delivery, CD) дозволили швидше і частіше випускати ПЗ для користувачів.

DevOps-практики послідовно покращували взаємодію між командами розробки та супроводу на кожному кроці життєвого циклу ПЗ. Тож можна з упевненістю сказати, що коріння DevOps – у Agile-методології.

Культура DevOps

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

  • відмовитися від традиційних методів роботи та управління;
  • переглянути звичний спосіб мислення.

За цією методологією Dev- та Ops-команди повинні працювати спільно і часто спілкуватися один з одним.

У деяких організаціях DevOps-інженери займаються як розробкою, і супроводом. Їхня роль охоплює багато всього: вони поділяють обов’язки з іншими командами і вважають себе відповідальними за весь цикл розробки.

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

DevOps-практики

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

А тепер докладніше про ці практики та інструменти.

Безперервна інтеграція
(Continuous Integration, CI)

Зазвичай розробники вручну оновлювали свій код, а потім його вручну тестували.

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

Ця практика допомагає швидше виявляти помилки та підвищує якість ПЗ.

Безперервне постачання та розгортання
(Continuous Delivery та Continuous Deployment)

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

Всі ці завдання допомагають виконувати Jenkins, Bamboo, Travis, TeamCity та інші CI та CD-утиліти.

Безперервне тестування (Continuous Testing)

Практика безперервного тестування допомагає якомога раніше виявляти можливі ризики на всіх стадіях розробки програмного забезпечення — щоб помилки не вплинули на кінцевих користувачів.

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

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

ПРИМІТКА ПЕРЕКЛАДАЧА

Функціональні тести (ФТ) перевіряють роботу програми зовні, як це робив користувач, а  модульні тести (МТ, юніт-тести)  — зсередини, з погляду розробника.

ФТ допомагають створити програму, яка робить рівно те, чого хоче клієнт. Вони гарантують, що ви ніколи не зламаєте логіку роботи. МТ допомагають писати чистий код без помилок – надійний, продуктивний, що не викликає витоків пам’яті, що розширюється і так далі.

Відповідно до ISTQB, модульне тестування може перевіряти і функціональність — у тому випадку, якщо компонент (модуль, програму, функцію, об’єкт, клас тощо) можна тестувати окремо від інших.

Серед популярних інструментів для безперервного тестування – Selenium, Travis та Appium.

Безперервне спостереження (Continuous Monitoring)

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

Більшість компаній стежать за такими показниками:

  • використання CPU та пам’яті;
  • використання дискового простору;
  • дії клієнтів;
  • політики безпеки.

Використовуючи безперервний моніторинг, ви завжди будете знати будь-які проблеми на контурах: від тестування до продакшену. Це допоможе забезпечити високу доступність продукту.

Популярні інструменти безперервного моніторингу: Nagios, Sensu, Prometheus.

Інфраструктура як код
(Infrastructure as Code, IaC)

Інфраструктура як код (Infrastructure as Code, IaC) – це модель, за якої інфраструктура – ​​віртуальні машини, балансувальники навантаження, мережі тощо – налаштовується та управляється програмно, а не вручну. Така інфраструктура стала необхідним компонентом DevOps в організаціях, які перейшли на хмарні платформи.

Наприклад, Amazon Web Services (AWS) надає API для програмної взаємодії зі своєю хмарною інфраструктурою. Використання програмного коду для визначення конфігурації допомагає зробити процес стандартним та швидко розгортати ресурси у хмарі.

Мікросервіси (Microservices)

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

Мікросервісна архітектура – ​​поширене рішення в DevOps-культурі. І це невипадково. Вона:

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

Топології DevOps

Способи застосування DevOps сильно залежить від конкретної організації. За словами Меттью Скелтона (Matthew Skelton) та Мануеля Пайса (Manuel Pais), щоб впровадження DevOps проходило успішно, компанії застосовують різні типи топологій чи командних структур. Скелтон та Пайс виділяють дев’ять типів топологій.

Співпраця Dev- та Ops-команд

Це ідеальна командна структура для DevOps. У ній Dev-і Ops-групи тісно взаємодіють один з одним:

  • Розробники серйозно ставляться до завдань команд підтримки та прислухаються до Ops-колег, якщо це необхідно.
  • Члени команд підтримки чудово розуміють, чим займаються розробники.

Розподілені операційні обов’язки

Така топологія застосовується у Facebook та Netflix. Вона складається з команд розробників, у які вплетені команди підтримки. Dev і Ops у своїй майже різняться.

Найкраще підходить для компаній із окремими веб-додатками.

Ops як «інфраструктура як послуги»

Ця топологія підходить для організацій з різними/кількома службами, розташованими на хмарних платформах, але з традиційним IT-відділом, реструктурувати який не планується. При такому підході Ops-група – це, по суті, “інфраструктура як послуга” (Infrastructure as a Service , IaaS).

DevOps як зовнішній сервіс

Деякі організації не мають достатнього досвіду або не можуть собі дозволити організацію окремої Ops-команди. У такому разі вони можуть доручити управління операційними аспектами програмного забезпечення зовнішньому провайдеру.

DevOps-команди «на вимогу»

Dev- та Ops-команди тимчасово об’єднуються, щоб досягти якоїсь конкретної мети. Як тільки завдання виконане, команду розпускають.

Команда DevOps advocacy

Така топологія підходить для згуртованих команд. DevOps-адвокати допомагають і розробникам, і групі підтримки, розповідають їм про DevOps-практики та залучають до роботи.

SRE-команда

Цю топологію вигадали в Google. У такій структурі є група, яка займається проектуванням надійності сайту (Site Reliability Engineering, SRE). Розробники доводять співробітникам цієї команди, що їх програмне забезпечення відповідає стандартам. SRE можуть відкотити зміни, якщо не погоджуються з ними.

Співробітництво на основі контейнерів

При контейнерізації вимоги до розгортання та часу виконання переносяться на шар контейнерів. Це прибирає частину взаємозалежностей між Dev-і Ops-командами.

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

Співпраця Dev та DBA

З такою топологією експериментували деякі організації, які мають додатки, підключені до великих централізованих баз даних. Суть структури у цьому, що у  DBA (DataBase Administrator), і у Dev-командах визначено взаємозалежні ролі співробітників, відповідальних за бази даних. Тим самим долається розрив між цими двома групами.

Ключові переваги DevOps

Організації, які впровадили у себе DevOps-культуру, помічають покращення у багатьох аспектах розробки ПЗ:

  • налагодження зв’язків між командами;
  • підвищення ефективності та продуктивності організації;
  • збільшення швидкості випуску;
  • підвищення лояльності клієнтів (вони тепер отримують ПЗ високої якості);
  • впевненість у тому, що система доступна і надійна, завдяки тому, що загрози та помилки швидко знаходять і виправляють;
  • сприяння інноваціям завдяки обміну ідеями між різними командами

На цьому відео Девід Ріццо (David Rizzo), віце-президент з розробки ПЗ у BMC Software, і Девід Кеннеді, архітектор рішень, розповідають про те, як впровадили DevOps у Compuware, щоб підштовхнути інновації, зменшити кількість помилок та зменшити показник MTTR .

DevOps виходить за рамки бізнес-моделі

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

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

При правильному застосуванні культура DevOps може дати компаніям великі можливості успішного випуску ПЗ.

Exit mobile version