Аgile, безперервне постачання і «три шляхи»: уривок із книжки «Посібник із DevOps»
Пропоную вашій увазі уривок з книги «Посібник із DevOps». Цей розділ присвячений введенню в основи теорії ощадливого виробництва і «трьох шляхів» — саме на ці підвалини спирається сучасний стан DevOps. Головна увага приділяється теорії і принципам, виробленим за кілька десятиліть дослідження робочих середовищ, організації високої надійності виробництва, створенню моделей управління з високим рівнем довіри, покладених в основу методів DevOps. Отримані зрештою принципи і схеми дій, а також їхнє практичне застосування у створенні потоку технологічної цінності описані в інших розділах посібника.
Виробничий потік цінності
Одна із фундаментальних концепцій ощадливого виробництва — потік створення цінності. Спочатку визначимо це поняття в межах промисловості, а потім екстраполюємо на DevOps і технологічний потік створення цінності. Карен Мартін і Майк Остерлінг у книжці Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation визначають потік створення цінності як «послідовність дій, що вживаються організацією з метою виконати запит клієнта», або як «послідовність дій, необхідних для розробки, випуску і постачання товарів клієнту, включно з обома потоками — як інформаційним, так і матеріальним»
У матеріальному виробництві потік створення цінності легко визначити і так само легко спостерігати за ним: він починається із отримання замовлення від клієнта і надходження сировини на склад. Аби забезпечити стислий і передбачуваний час виконання замовлення у будь-якому потоці створення цінності, зусилля організації зазвичай фокусуються на створенні плавного й рівномірного потоку роботи з використанням таких прийомів, як зменшення розміру партії, зниження обсягу незавершеного виробництва (WIP, Work in Process), недопущення переробок, аби виключити використання дефектних деталей на кінцевих етапах, і постійна оптимізація системи заради стійкого руху до глобальних цілей.
Технологічний потік цінності
Ті самі принципи і методи, що забезпечують швидкість виконання роботи в процесах матеріального виробництва, можуть застосовуватися в галузі технологій (і взагалі будь-якої діяльності, що створює знання). У DevOps технологічний потік створення цінності зазвичай визначають як процес, необхідний для перетворення бізнес-гіпотез на технологічний сервіс, що постачає цінність замовнику.
Вихідними даними для процесу є формулювання бізнес-цілі, концепції, ідеї або гіпотези. Усе починається, коли ми приймаємо завдання в галузі розробки, додаючи їх до вже наявних у роботі беклогів (списків завдань до виконання).
Отже команда розробників, що дотримується типового Agile або ітеративного процесу, ймовірно, зможе адаптувати певну ідею відповідно до побажань користувачів, створивши різновид специфікації функціональних можливостей, що згодом будуть реалізовані у вигляді коду програми або у створюваному сервісі. За цим слідує розміщення програми або сервісу в репозиторії системи контролю версій, де кожна зміна інтегрується в основний код і тестується разом з усією системою ПЗ.
Оскільки цінність створюється, коли наші сервіси працюють у виробничому середовищі, слід забезпечити не лише швидкий потік постачання, а й виконання розгортання без хаосу і перебоїв — затримок в обслуговуванні та порушень функціонування сервісів, вимог безпеки або сумісності.
Фокус на часі розгортання
У подальших частинах книжки ми зосередимося на одній зі складових частин потоку створення цінності — часі розгортання. Починається він тоді, коли якийсь інженер із команди потоку створення цінностей (включно з розробниками, тестувальниками, відділами експлуатації та інформаційної безпеки) отримує зміну від системи контролю версій, а закінчується, коли зміна починає успішно працювати у виробничому середовищі, створюючи продукт для клієнтів і генеруючи зворотний зв’язок і телеметрію.
До першого етапу роботи входять проєктування і розробка, що певним чином схоже на ощадливу розробку продуктів, і характеризується високою мінливістю і невизначеністю, часто вимагає творчого підходу до виконання роботи, що може ніколи не знадобитися. Це призводить до різної тривалості даного етапу. На відміну від нього, другий етап, що включає тестування і виробництво, цілком відповідає принципам ощадливого виробництва. Він вимагає творчого підходу й досвіду і має тенденцію до передбачуваності та автоматизації, його мета — забезпечити корисний результат із мінімальною мінливістю (наприклад, невеликий і передбачуваний час виконання, близьку до нуля кількість дефектів).
Замість того щоби пропускати великі обсяги роботи через такі частини потоку створення цінності, як «проєктування і розробка», а потім через потік «тестування і виробництво» (наприклад, коли використовується великий каскадний процес або довготривалі функціональні гілки коду) наша мета полягає в тому, щоби тестування і виробництво відбувалися одночасно із проєктуванням і розробкою, що забезпечує швидкий рух потоку та високу якість. Цей метод стає успішним, коли виконання здійснюється невеликими частинами, а якість забезпечується на кожному етапі потоку створення цінності.
Визначення часу виконання і часу обробки
У Lean-спільноті час виконання вважається однією із двох характеристик, що зазвичай використовуються для вимірювання продуктивності потоків цінності, інша характеристика — час обробки (іноді його також називають «часом контактування» або «часом виконання завдання»2).
Якщо відлік часу виконання замовлення починається з його оформлення і закінчується з виконанням, то час виробництва відраховується з моменту, коли ми починаємо роботу над замовленням, тобто не враховується той період часу, доки замовлення перебувало у черзі на обробку (рис. 2).
Оскільки час виконання замовлення — найважливіша для клієнта характеристика, то звичайною метою є вдосконалення процесів заради скорочення цього параметра, а не часу обробки. Однак співвідношення часу обробки і часу виконання замовлення є важливим критерієм оцінки ефективності: для того, щоби забезпечити швидкий потік і скорочений час виконання замовлення, майже завжди потрібно скоротити час очікування, доки черга дійде до завдання.
Типовий сценарій: час розгортання вимагає місяців
У випадку ведення бізнесу звичайними способами ми часто опиняємося в ситуації, коли розгортання займає кілька місяців. Особливо часто це відбувається у великих організаціях зі складною структурою, що використовують тісно пов’язані один з одним монолітні застосунки, котрі зазвичай погано інтегровані в середовище для тестування, мають значну тривалість тестування і тривалий час розгортання в робочому середовищі, високу залежність від тестування вручну і необхідність схвалення численними інстанціями в компанії. Коли щось подібне відбувається, потік створення цінності починає виглядати приблизно так, як показано на рис.3
За наявності великої тривалості часу розгортання практично на кожній стадії потоку створення цінності потрібні надзусилля. Може статися і так, що на завершальному етапі проєкту, коли всі результати праці інженерів буде зібрано докупи, все перестане працювати, код не буде збиратися правильно або не витримуватиме тестування. Виправлення проблеми разом із виявленням того, хто саме «зламав» код і як це виправити, вимагатиме кількох днів або навіть тижнів, а в результаті віддача для клієнтів виявиться невисокою.
Наш ідеал — DevOps: розгортання за хвилини
В ідеальному випадку при роботі з DevOps розробники швидко й регулярно отримують зворотний зв’язок. Це надає їм можливість швидко й незалежно впроваджувати, інтегрувати і валідувати код, а також забезпечувати його розгортання у виробничому середовищі (це можуть робити як вони самі, так і інший відділ).
Це досягається шляхом постійної перевірки невеликих змін у коді, зроблених у репозиторії системи контролю версій, виконанням автоматичного і передвиробничого тестування змін, а потім розгортанням у реальному виробничому середовищі. Що й дозволяє нам бути твердо впевненими: зроблені зміни після розгортання будуть функціонувати так, як задумано і будь-яку проблему, що виникне, буде швидко виявлено і виправлено.
Цього найпростіше досягти, коли архітектура є модульною, добре інкапсульованою й у ній відсутні тісні зв’язки між компонентами. Завдяки цьому невеликі групи розробників отримують можливість працювати з високим ступенем автономності, а можливі збої зазвичай мають обмежені наслідки, що не викликають глобальних порушень працездатності системи.
За такого сценарію час розгортання вимірюється хвилинами або, у гіршому разі, годинами, а карта потоку цінності має виглядати приблизно так, як показано на рис. 4.
