Настав час додати концепцію «DevOps-Driven Development» до нашого репертуару.«Тестова» розробка, яка виникла приблизно в той самий час, коли екстремальне програмування та гнучка розробка, спонукає нас думати про тестування, коли ми розробляємо своє програмне забезпечення та плануємо наші завдання. Аналогічним чином, підхід «DevOps-Driven Development» гарантує, що ми розглянемо операційне впровадження, а також процес розгортання на етапі проектування. Щоб бути зрозумілим, мислення DevOps має доповнити (а не замінити) стратегію тестування.
Визначення та мотивація
Спочатку визначення: я використовую слово DevOps тут як ярлик для включення як DevOps (засоби побудови та розгортання), так і Ops (ІТ / Операції центру обробки даних).
Скільки разів ви чули “… але це працює на моїй машині !!” від розробника, чий код виявив помилку в середовищі контролю якості або, що ще гірше, у виробництві? Ми всі погоджуємось, що ці ситуації – жахлива втрата часу для всіх залучених, а найбільше клієнтів. Таким чином, ця публікація виступає за те, що мислення DevOps, як і мислення якості, має відбуватися на етапі проектування і продовжуватися протягом усієї розробки програмного забезпечення, поки програмне забезпечення не буде випущено у виробництво, і навіть після того, як воно буде випущено у виробництво.
Практика розробки, керованої розробниками
Я завжди відстоював: “Якщо ви не знаєте, як це протестувати, ви не знаєте, як його розробити”. (Хто володіє якістю? Частина 3), щоб сформулювати той факт, що «якість не може бути налагоджена, вона повинна бути розроблена». Подібним чином, якщо ми хочемо знати – до того, як наші клієнти зателефонують нам – коли наш код виходить з ладу у виробництві або стає невживано повільним, тоді ми повинні вбудувати в наш код відповідні інструментальні та адміністративні можливості.
Тепер ми повинні додати цю мантру «Якщо ви не знаєте, як її розгорнути та керувати нею у виробництві, ви не знаєте, як її розробити».
Подібно до того, як ми не дозволяємо об’єднувати код в Trunk (основна гілка) без повних модульних тестів, код не можна об’єднувати в Trunk без правильних сценаріїв розгортання, приміток до випуску та виробничих інструментів.
Ось контрольний список “продуманих DevOps”:
Розгортається
Перш за все, ми повинні забезпечити успішне розгортання коду не лише у виробництві, але і у всіх середовищах: Dev, QA, Stage тощо.
Це означає:
Розробники пишуть / оновлюють примітки до випуску: напр. виділення будь-яких змін, необхідних у конфігурації середовищ: відкрити новий порт, додати стовпець у базу даних, нову властивість у файлах конфігурації тощо
Розробники у співпраці зі сценаріями розгортання оновлення команди DevOps, наприклад для обліку нового виконуваного файлу або змін схеми в базі даних
Управління файлами Config / Property виходить за рамки цього блогу, але я настійно рекомендую підхід “Інфраструктура як код”: тобто повністю автоматизувати конфігурацію сервера / зображення для розгортання та керувати конфігурацією, сценаріями розгортання та файлами властивостей програми під вихідним кодом контроль.
Монітор
Якщо ми хочемо виявити проблеми до того, як наші (роздратовані) клієнти зателефонують нам, наш код повинен контролюватися – не тільки на рівні фізичного сервера, але і кожної віртуальної машини, служби та процесу, а також мережевих та систем зберігання даних.
Моніторингові можливості повинні перевершувати відстеження навантаження процесора, дискового простору та пропускної здатності мережі. Ми, розробники, (повинні) знати, які параметри вказують, коли наша система не працює належним чином, чи є це черга, що перевищує заданий розмір, або час очікування певних операцій. Як наслідок, ми повинні опублікувати ці параметри в інтерфейсах, сумісних із засобами моніторингу Ops, яких існує кілька категорій:
Функціональність (наприклад, Nagios,…) – це обслуговування та обробка запитів
Продуктивність (наприклад, New Relic, AppDynamics, Dynatrace,…)
Юзабіліті (наприклад, MixPanel, Flurry, …)
Крім того, роблячи метрики продуктивності легкими для спостереження, ми гарантуємо, що кожен новий випуск підтримує (або покращує) ефективність попереднього випуску.
Діагностується
Незважаючи на наші найкращі наміри, ми повинні смиренно припустити, що в якийсь момент наш код вийде з ладу або серйозно поведеться неправильно і, отже, вимагатиме усунення несправностей. У гіршому випадку буде залучено розробника (як правило, в нічні години ночі), щоб допомогти команді Операторів. Як засвідчить будь-хто, кому довелося з’ясувати, чому дана система періодично виходить з ладу, наявність журналів, що збирають значущу інформацію до інциденту, є безцінним. Потрібно додавати операторські виписки фактично болісний процес. Отже, суцільна гігієна лісозаготівлі є критично важливою (і гідна спеціальної публікації):
Виписки журналів повинні бути записані у форматі, сумісному із системою управління журналами (Splunk, GrayLog2,…)
Усі оператори журналу, які використовуються під час кодування та фази контролю якості, повинні бути видалені
Потрібно додати всебічний журнал, орієнтований на Операції, щоб задокументувати всі операції, які можуть провалитися через проблеми довкілля та даних: відсутність пам’яті, заповнення диска, час очікування, користувач не знайдений, доступ заборонено тощо. Це не помилки, але помилки через будь-яке середовище (наприклад, сервер або з’єднання не працює) або неправильні дані (наприклад, користувача було видалено).
Ієрархія рівнів ведення журналу повинна бути застосована так, щоб у звичайних операціях файли журналу були невеликими, а навпаки – значуща інформація виводилася, коли потрібно усунення несправностей
Виписки журналу повинні містити всю інформацію, необхідну для прив’язки всіх операцій між різними службами, які пов’язані з однією транзакцією на рівні користувача (наприклад, натискання посилання на нову сторінку, додавання товару в кошик) – детальніше нижче в “Настроюється” .
Безпека
Це знову гідно власної публікації, але код, який розгортається у виробництві, повинен одночасно підтримувати методи безпеки, реалізовані командою Ops (наприклад, протоколи автентифікації, мережева інфраструктура), а також забезпечувати безпеку самого коду (наприклад, відсутність введення SQL, переповнення буфера тощо).
Безперервність бізнесу
Безперервність бізнесу часто залишається поза увагою, але ми повинні переконатися, що будь-які постійні дані зберігаються в системі зберігання, яка резервно копіюється командою Ops. Іншими словами, якщо ми додаємо нову базу даних, краще попросимо команду Ops додати її до своїх сценаріїв резервного копіювання.
Подібним чином, якщо наша інфраструктура розгорнута (або навіть просто розгортається) у декількох центрах обробки даних, наш код повинен підтримувати цю конфігурацію.
Вищевикладені вимоги представляють основні вимоги DevOps, на які повинен звернутися будь-який розробник, навіть не думаючи, що його / її код готовий до випуску. Далі описано додаткові практики, які настійно рекомендуються, але не є суворо необхідними.
Масштабована
Код повинен бути розроблений таким чином, щоб команда Ops могла масштабувати його в центрі обробки даних, не потребуючи допомоги з боку розробника.
Це може передбачати розгортання коду на більшому сервері. Це означає, що код можна налаштувати (і задокументувати для команди Ops) для використання розширених ресурсів, будь то кількість ядер, оперативної пам’яті, потоків, вводу-виводу тощо.
Це також може включати додавання екземплярів до кластера. Отже, код повинен бути доступним для пошуку (балансир навантаження повинен з’ясувати, що новий екземпляр доданий / віднятий), а також з урахуванням кластера (наприклад, без стану).
Налаштовується
Оскільки так важко моделювати всі реальні дії та поведінку користувачів у невиробничому середовищі, ми повинні надати команді Ops інструменти для налаштування продуктивності нашого коду за допомогою конфігурації, а не розгортання коду (наприклад, розмір JVM, кількість потоки, розміри черги, розмір хеш-таблиці тощо).
Таким чином, ми повинні надати метрики для спостереження за ефективністю. Візьмемо приклад часу відгуку: залежно від складності програми, запит користувача може оброблятися десятками, а то й сотнями служб. Щоб команда Ops могла побудувати часову шкалу взаємодій між усіма залученими службами, кожен запис журналу повинен містити принаймні один тег, який ідентифікує кореневу транзакцію, яка генерувала запит. В іншому випадку неможливо визначити, чи погіршення продуктивності походить від певної служби, або від унікального сервера, або навіть від мережевої інфраструктури.
Те саме позначення буде використано для усунення несправностей (наприклад, для виявлення, чому дана послуга періодично виходить з ладу).
Qa-здатний
Як я вже згадував у попередньому блозі, QA не зупиняється на QA: ми повинні передбачити «невідомі невідомі», тобто сценарії використання (або продуктивності), які ми не змоделювали в наших середовищах QA. За визначенням, ми не можемо зробити багато іншого, крім забезпечення того, щоб наш код легко було усунути неполадки (див. Вище), а журнали та пов’язані з ними дані могли бути легко та швидко доступні розробникам та команді з контролю якості (наприклад, надання їм доступу до консолі управління журналами).
Іноді ця вимога є більш складною, ніж здається, напр. коли дані користувача повинні бути видалені або забруднені з міркувань конфіденційності або безпеки. Знову ж таки, це слід продумати до розгортання коду.
Аналітика – хакерство зростання – юзабіліті
Ця остання вимога випливає з маркетингу та продажів, а не з операцій, але вона не менш важлива, оскільки стимулює зростання доходів.
У більшості компаній маркетинг та продажі покладаються на звіти про використання для стимулювання нових маркетингових кампаній, ціноутворення, пропозицій товарів та навіть нових функцій. Як наслідок, будь-яка нова функція повинна інтегруватися з інфраструктурою Analytics, будь то шляхом інтеграції з програмами відстеження використання (наприклад, Mixpanel, Flurry, …) або просто консолями управління журналами (Splunk, GrayLog2, …). Однак я настійно рекомендую використовувати окрему інфраструктуру ведення журналу для моніторингу операцій та аналітики використання, хоча б тому, що аналітика використання вимагає додаткових даних, які не є корисними для моніторингу операцій (наприклад, час, проведений користувачем на сторінці, надзвичайно цінний для аналітики використання, але недоречний для операцій)
Навіть більше для мікросервісів
По мірі того, як ми переходимо до архітектури мікропослуг, раннє «мислення DevOps» стає ще більш критичним. Як радить «Мікросервіси: чотири основні контрольні списки на початку роботи»: «Мікросервіси представляють багато рухомих частин, які раніше не існували в монолітній системі».
Те, що було монолітним додатком, що працює в одній віртуальній машині, може перетворитися на 5, 10 або навіть 20 мікросервісів. Отже, Development, DevOps та Ops повинні співпрацювати над інструментами інфраструктури мікросервісів: реєстрацією сервісу, збільшенням / зменшенням кожної служби самостійно, моніторингом стану здоров’я, виявленням помилок тощо, щоб забезпечити видимість стану цих 20 мікросервісів в цілому. Цей виклик навіть підштовхнув спеціальні категорії продуктів (SignalFx, Nirmata тощо)
Резюме
Тільки за допомогою цілісного підходу до архітектури продукту ми можемо забезпечити задоволеність споживачів програмним забезпеченням, яке працює вперше і постійно. Проблеми розгортання та управління операціями, як і тестованість, повинні вирішуватися під час проектування, щоб ці можливості були вбудовані в код, а не “закріплені” на самому справі. Якщо цього не зробити, це, швидше за все, вплине на графік поставок або, що ще гірше, призведе до відключень виробництва.
Що ще важливіше, ми можемо настільки багато чого навчитися, спостерігаючи за тим, як поводиться наш код у виробництві: операційна ефективність, стабільність, продуктивність, зручність використання, що ми зробили б собі погану послугу, якби не скористалися цією цінною інформацією для подальших удосконалень до нашого продукту.
http://sw-engineer.com/2015/12/16/devops-driven-development/
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/devops-driven-development-needs-augment-test-driven-bernard-fraenkel/.
Bernard Fraenkel люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 