Як покращити доставку програмного забезпечення за допомогою OpenShift

Red Hat поділився новим матеріалом про те, як покращити основні метрики вимірювання ефективності доставки програмного забезпечення за допомогою OpenShift. 

У книзі «Accelerate, The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations» автори Джез Хамбл, Джин Кім та Ніколь Форсгрен використовують дані звіту State of DevOps, зібрані тисячами професіоналів з усього світу, аби чітко продемонструвати – продуктивність доставки програмного забезпечення дійсно створює конкурентні переваги компанії.

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

  • Час внесення змін – час, який потрібен команді, щоб перейти від коду, який був створений, до коду, який успішно працює у продуктивному середовищі.

  • Частота розгортання – частота, з якою новий код розгортається у продуктивне середовище.

  • Середній час відновлення – час відновлення після виникнення проблем в результаті розгортання ПЗ.

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

Перші дві метрики пов’язані зі швидкістю змін. А оскільки інновації походять від експериментів, проведених на великій швидкості – помилки неминучі. Тобто збій рано чи пізно станеться, в DevOps-методології це нормальний процес. Втім, для того, щоб збій не стався вже у кінцевого користувача, варто подбати про його помітність завчасно. Тож DevOps пропонує функцію «швидкий збій». Це дає можливість протягом кількох годин помітити помилку і виправити її одразу. Для цього важливо стежити за останніми двома метриками, які вимірюють, скільки є проблем та як швидко можна їх вирішити.

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

Як покращити ці метрики за допомогою Red Hat OpenShift?

Розробник щойно зробив останній коміт вихідного коду програми MVP і розпочався час внесення змін! Йдеться про нативні хмарні додатки, тому перше, що потрібно, це корпоративний кластер Kubernetes, де можна розгорнути програму. Якщо такого кластера ще немає, можна подумати про локальні та хмарні варіанти. Зокрема, OpenShift пропонує кілька керованих опцій для основних загальнодоступних хмар: OpenShift Dedicated, Azure Red Hat OpenShift, Red Hat OpenShift Service на AWS і Red Hat OpenShift на IBM Cloud. З допомогою будь-якого з них можна створити продуктивний кластер, який буде доступний для розгортання програм вже за пару годин.

Що робити далі, коли продуктивний корпоративний кластер Kubernetes вже є?

У традиційних організаціях, коли розробник хоче протестувати свій код у непродуктивному середовищі (наприклад, для розробки), спочатку він має запитати в команди інфраструктури щодо ресурсів у віртуальній машині, де він може запустити код. Зазвичай для цього потрібно створити запит у внутрішній системі робочого процесу, який, можна вирішити за 1 годину, хоча іноді це може зайняти і більше тижня. Цей час очікування невиправдано затримує час виходу на ринок нової функції або MVP.

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

Кластери OpenShift 4 використовують OpenShift SDN NetworkPolicy як мережеве рішення за замовчуванням. Поведінка за замовчуванням – це широко відкрита мережа в проєктах/неймплейсах (політики не застосовуються). В ній можна встановити кластер у режимі multitenancy як параметр конфігурації під час встановлення. В цій мережі всі проєкти/простори імен за замовчуванням ізольовані один від одного. Це дозволяє уникнути будь-яких перешкод між навантаженнями з різних середовищ всередині одного кластера OpenShift.

Після створення нового неймспейсу, дуже просто побудувати образ контейнера VCS-репозиторію за допомогою функції Source-to-Image та розгорнути його в будь-якому середовищі. Ця проста стратегія для початку може бути корисною для швидкого створення MVP із задовільною початковою метрикою Lead Time For Change.

Тепер покращуємо всі чотири метрики

Наступна важлива річ — включення конвеєрів CI/CD, які можна реалізувати за допомогою OpenShift Pipelines (Tekton) і OpenShift GitOps (ArgoCD).

Конвеєри CI/CD покращують метрики часу внесення змін та частоти розгортання, оскільки завдяки автоматизації можна реалізувати розгортання за пару хвилин у будь-якому середовищі, що відповідно дозволить зробити більше розгортань. Крім цього, це покращує рівень невдалих змін не тільки тому, що завдяки автоматизації ми уникаємо всіх помилок, які виникають під час процесів розгортання вручну, а й тому, що конвеєри містять велику кількість автоматизованих тестів (моніт-тести, статичний аналіз коду, аналіз вразливостей та інтеграційні тести), які різко зменшують можливість появи помилок у розгортанні. Ці автоматичні тести є ключовими для концепції «shift left»: багато контролю ведеться на початку кожного виконання конвеєра, що дозволяє уникнути несподіванок під час розгортання у виробництві, а також покращити час виконання змін.

Правильно реалізована стратегія CI/CD також дозволяє відкат. Якщо проблема буде виявлена ​​після розгортання, попередня версія може бути розгорнута за пару хвилин, що покращить середній час відновлення. На цьому етапі потрібно згадати про цінність використання GitOps у стратегії, що дозволяє підтримувати версію образу контейнера синхронізовано разом з іншими необхідними конфігураціями для роботи програми (дескриптори розгортання, configMaps, маршрути тощо).

OpenShift також дозволяє легко виконувати розгортання на основі маршрутів. Наприклад A/B deployment, де вказується відсоток трафіку, який використовуватиме нову версію програми, або canary deployment, де обирається невеликий набір користувачів для тестування нової версії. Такі типи розгортань дозволяють експериментувати у розробці, обмежуючи вплив помилок, не чекаючи тривалих процесів QA та маючи можливість негайно скерувати весь трафік назад до стабільної версії служби. Ця перевага швидкого експериментування відображається в показнику середнього часу відновлення.

Як контролювати ці метрики?

Pelorus — це інформаційна панель на основі Grafana, яка дозволяє відстежувати ці чотири показники на рівні організації. Цей інструмент є ключовим для впровадження трансформаційного, постійного вдосконалення та процесу на основі показників, як той, який пропонує Тревор Квінн.

Висновок

У наступній таблиці можна побачити синтез того, як різні функції OpenShift, згадані вище, покращують 4 метрики:

Богдан Шавло, Pre-sale engineer компанії Integrity Vision: “З нашого досвіду співпраці з великими корпоративними замовниками ми бачимо, як використання OpenShift пришвидшує процеси розробки в цих компаніях. Готовий до продуктивного середовища набір інструментів дозволяє зосередитись саме на розробці додатків, які реалізують бізнес-функціонал. Він необхідний для того, щоб не витрачати час на валідацію і розробку інфраструктурних рішень, які не приносять бізнесу безпосереднього прибутку і користі”.

Нагадаємо, що Red Hat є партнером Integrity Vision.

×
Оставьте свой номер и мы вам перезвоним