Розгортання: ірраціональний страх перед ними

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

Нещодавній збій за участю CrowdStrike вплинув на 8,5 мільйонів операційних систем Windows, що призвело до збоїв у роботі різних глобальних служб, включаючи авіакомпанії та лікарні. Численні аналізи вивчили першопричину самого інциденту.

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

• Розуміння функції розробки випусків.
• Що цікавить інженерів програмного забезпечення, а що ні.
• Вплив безперервної доставки (CD).
• Погляд на розгортання вручну.
• Проблеми з ручним розгортанням і вирішення цих проблем.

Розробка випуску

Перш ніж заглиблюватися в страх розгортання з точки зору інженера програмного забезпечення, давайте спочатку зрозуміємо роль інженера випуску. За останні роки розробка випусків значно розвинулася завдяки сучасним інструментам CI та CD і стандартизації Kubernetes. Незважаючи на ці досягнення, основні обов’язки залишаються незмінними:

• Послідовне та повторюване розгортання: стандартизація процесів випуску знижує ризик неправильного розгортання у виробництві.

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

• Відстежуйте та оптимізуйте продуктивність: шукайте покращення продуктивності для швидшого та надійнішого розгортання.

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

Про що піклуються розробники програмного забезпечення

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

• Швидке злиття кодів: швидке злиття дозволяє їм перевірити свою роботу та перейти до нових завдань або розблокувати залежні завдання.

• Виробничі інциденти : хоча інженери можуть не дбати про всі виробничі інциденти, вони точно піклуються про зміни коду, що спричиняють будь-які збої у виробництві.

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

Що не хвилює програмістів

Хоча є речі, які нас турбують, є й ті, які нам байдужі:

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

• Вплив інших змін : якщо щось не піде не так, ми не хвилюємося про непов’язані зміни від інших розробників.

• Управління розгортанням : інженеру байдуже, хто керує розгортанням у групі програмного забезпечення. Наприклад, ми будемо дбати лише про керування розгортанням, якщо це буде доручено.

Вплив безперервного розгортання (CD)

Отже, яке відношення цей страх має до безперервного розгортання?

багато.

Дослідження підтвердили [декілька переваг](https://dora.dev/capabilities/continuous-delivery/#:~:text=DevOps%20Research%20and%20Assessment%20(DORA,as%20higher%20levels%20of%20availability) безперервного розгортання (CD), і, як не дивно, багато з яких мають психологічний характер. Безперервне розгортання усуває «людину в циклі», тому вимагає сильної довіри до тестової інфраструктури.

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

Однак, незважаючи на популярність цих стратегій CD, багато компаній все ще запускають розгортання вручну (є людина в циклі), що вказує на обережний підхід до впровадження CD. Така поведінка свідчить про те, що команди вважають за краще контролювати процес випуску та втручатися, якщо це необхідно.

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

Розгортання вручну

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

Нагляд

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

Спеціалізовані групи випусків

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

Електронні таблиці

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

Керівництво QA

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

Де йдуть проблеми з ручним розгортанням?

Багато речей можуть піти не так для будь-якої команди розробників програмного забезпечення, яка покладається виключно на ручне розгортання:

Залежність від малої групи

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

Немає стратегії зменшення ризиків

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

Схильність до людських помилок

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

Високі зусилля

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

Розрив зв'язку

Від команди продуктів незрозуміло, у якому стані випуски та коли їхні зміни потраплять у виробництво.

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

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

Що ми можемо з цим зробити?

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

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

Огородження – Canary та Rollbacks

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

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

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

Зменшення людських помилок – стандартизація

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

Демократизація процесу розгортання

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

Часті розгортання

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

Покращте досвід розробника

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

Визначені стратегії зменшення ризиків

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

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

Прапори функцій

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

Висновок

Команди програмного забезпечення повинні розглядати розробку випусків як пріоритет із самого початку розробки продукту, щоб уникнути дорогих помилок. І ми не повинні дозволяти таким інцидентам, як збій Crowdstrike, скалічити нашу практику розробки. Подолання страху розгортання та запобігання виробничим інцидентам передбачає кілька ключових стратегій:

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

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