Рейтинги

13 речей, яких треба уникати у DevOps

DevOps рятує бізнеси. Він допомагає створювати якісне програмне забезпечення та впроваджувати зміни якнайшвидше. Обов’язковий елемент, якщо ви хочете створювати найкращі продукти. 

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

Підемо від зворотного: в матеріалі розкриємо 13 шкідливих порад для того, щоб DevOps у вашій компанії точно не прижився. Нумо досліджувати!

Відкладення на потім або надто різкий стрибок в DevOps

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

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

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

Робіть невеликі кроки, і ви не помітите, як ці дії нарощуються, а ви пожинаєте перші плоди.

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

Сьогодні до цієї крайності вдається не так багато компаній, бо ринок має надто багато підтверджень невдалості такої стратегії.

Суворість щодо реалізації DevOps

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

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

Автоматизація неправильних процесів 

Якщо ви все ж почали впроваджувати DevOps та не занадто суворі у цих питаннях, не пробуйте автоматизувати все. 

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

Автоматизувати все, що можливо — зрозумілий підхід. Але деякі моменти краще не чіпати, щоб не створити собі проблем.

Автоматизуйте:

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

Не автоматизуйте:

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

Нехтування технічними авторами у своїй команді DevOps

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

Щоб успішно інтегрувати цих спеціалістів у команду, ви можете скористатися методологією «Документи як код» (Docs as Code). Це ефективніше за традиційні засоби розробки довідкової документації HAT, як MadCap Flare.

Документи як код включають:

• використання програмного забезпечення для контролю версій,
• написання файлів простої текстової документації — Markdown та reStructuredText,
• виконання автоматизованих тестів,
• практику безперервної інтеграції та безперервного доставлення.

Вимірювання впливу або продуктивності DevOps за допомогою жорстких показників

Це дискусійне питання, проте ось що каже з цього приводу Енді Хант, співавтор «Маніфесту Agile». При вимірюванні продуктивності команди та процесів, він досліджував би здоров’я та щастя користувача, команди та керівництва.

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

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

Зосередження на швидкості, а не на безпеці та якості

Багато компаній впроваджують CI/CD, тому що хочуть скоротити кількість часу, який вони витрачають на розробку та розгортання нового коду програми. Це чудово, але не має відбуватися коштом якості та безпеки. Ви можете створювати, тестувати та розгортати нові програми на проді набагато швидше, але вони працюватимуть не так, як ви задумали.

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

Дозвіл великої кількості гілок

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

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

Розробникам може бути складно позбутися звички використовувати гілки, якщо вони звикли до традиційного середовища вотерфолу. Проте розробка на основі магістралі (trunk-based) означає, що розробники постійно працюють над узгодженою єдиною версією вашого коду. 

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

Створення єдиної команди DevOps

Одна з популярних помилок — створення нової команди, яка має займатися усім, що стосується DevOps. 

Суть проблеми в тому, що Dev та Ops достатньо складно мати справу із новою командою, яка має координувати роботу всіх. Методологія першочергово почалася з того, щоб покращити взаємодію команд, що беруть участь в розробці. І мова не лише про ці дві команди, а й про команди безпеки, тестування та DBMS. Створити ще одну команду означає ускладнити все ще більше.

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

DevOps — це не лише одна команда, яка за все відповідає, а й організації, які розвиваються разом, як одна команда.

Незалучення команди безпеки

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

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

Якщо у вас виникли проблеми з безпекою на проді, ви можете вирішити їх у своєму конвеєрі DevOps за допомогою інструментів, які ваша команда безпеки вже використовує. Ви маєте чітко дотримуватися правил методології та безпеки. Жодних компромісів.

Зосередження на чомусь одному: людях, процесах чи технологіях

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

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

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

Якщо ж мова про сучасні практики, вони передбачають команди, що тісно між собою взаємодіють, а також мислення, орієнтоване на продукт, а не процес. Процеси в такому випадку мають рухатися в сторону Agile, наприклад, безперервного доставлення та автоматизації. Тут підключаються ще й нові технології: хмара, контейнери, мікросервіси, API та безсерверні технології.

Бачимо, що DevOps не працюватиме, якщо ми викинемо з цієї схеми щось одне. 

Нехтування стратегіями розгортання

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

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

Стратегії включають A/B тестування, Blue/Green розгортання і релізи Canary. Кожен елемент передбачає багато типів змін та що не всі вони — однакові стандарти. Їхнє застосування означає тестування змін, щоб перевірити їх якість та впевнено їх впроваджувати. Цей процес можна повторити шляхом безперервних експериментів.

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

Необов’язково приймати стратегії розгортання першою чергою, але упускати їх не радимо. 

Фокус на зниженні витрат

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

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

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

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

Щасливі співробітники продуктивніші, дають кращі результати, від чого зростає задоволеність користувачів від продукту.  

Одні плюси. Тож будьте готові інвестувати в DevOps, щоб зменшити свої майбутні витрати.

Неправильне використання управління інцидентами

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

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

А тепер — забудьте все!

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

DevOps — це нескінченний процес вдосконалення. Ступивши на цей шлях завжди з’являтимуться аспекти, які можна покращити. Але ви від того лише виграєте: ви створюватимете круті продукти якісно та швидко.
Якщо хочете отримати максимум від впровадження DevOps — реєструйтесь на наші профільні курси.