зображення:
Всім привіт! Ми інженери-автоматизатори з компанії і займаємося супроводом розробки продуктів компанії: підтримуємо весь складальний конвеєр від коміту рядка коду розробниками до публікації готових продуктів та ліцензій на серверах оновлень. Неформально нас називають DevOps-інженери. У цій статті ми хочемо розповісти про технологічні етапи процесу виробництва, про те, як ми їх бачимо і як класифікуємо.
З матеріалу ви дізнаєтеся про складність координації мультипродуктової розробки, про те, що таке технологічна карта та як вона допомагає впорядковувати та тиражувати рішення, з яких основних етапів та кроків складається процес розробки, як розмежовані зони відповідальності між DevOps та командами у нашій компанії.
Про Хаос та DevOps
Коротко зазначимо, що поняття DevOps включає інструменти та сервіси розробки, а також методології та кращі практики їх використання. Виділимо глобальну мета від впровадження ідей DevOps у нашій компанії: це послідовне зниження собівартості виробництва та супроводу продуктів у кількісних показниках (людино-годинниках або машино-годинниках, CPU, RAM, Disk etc.). Найпростіший і очевидніший спосіб зниження загальної собівартості розробки на рівні всієї компанії — це мінімізація вартості виконання типових серійних завдань всіх етапах виробництва. Але що це за етапи, як їх виділити із загального процесу, з яких кроків вони складаються?
Коли компанія розробляє один продукт, все більш-менш зрозуміло: зазвичай є загальний роадмап та схема розробки. Але що робити, коли продуктова лінійка розширюється та продуктів стає більше? На перший погляд, у них схожі процеси та складальні конвеєри і починається гра «знайди Х відмінностей» у логах та скриптах. А якщо активна розробка вже має 5+ проектів і потребує підтримки кількох версій, розроблених за кілька років? Чи хочемо ми перевикористовувати максимально можливу кількість рішень у продуктових конвеєрах чи готові витрачатися на унікальну розробку під кожен?
Як знайти баланс між унікальністю та серійністю рішень?
Ці питання стали постати перед нами дедалі частіше починаючи з 2015 року. Кількість продуктів зростала, а розширювати наш відділ автоматизації (DevOps), у якого на підтримці перебували складальні конвеєри цих продуктів, намагалися щонайменше. При цьому хотілося якнайбільше рішень тиражувати між продуктами. Зрештою, навіщо робити те саме в десяти продуктах різними способами?
Директор з розробки: "Хлопці, а ми якось можемо оцінити, що робить DevOps для продуктів?"
Ми: «Не знаємо, чи не задавалися таким питанням, а які показники вважати треба?»
Директор з розробки: "А хто його знає! Подумайте…»
Як у відомому фільмі: «Мені в готель!..» — «Е-е… А дорогу покажеш?». Подумавши, дійшли висновку, що спочатку потрібно визначитися з кінцевими станами продуктів; це стало нашою першою метою.
Отже, як провести аналіз десятка продуктів з досить великими командами від 10 до 200 чоловік і визначити вимірні метрики при тиражуванні рішень?
1:0 на користь Хаосу, або DevOps на лопатках
Почали зі спроби застосувати діаграми IDEF0 та різні діаграми бізнес-процесів із серії BPwin. Плутанина почалася після п'ятого квадратика чергового етапу чергового проекту, а квадратиків у кожного проекту можна намалювати в хвіст довжелезного пітона під 50+ кроків. Засмутилося і захотілося повити на місяць - не підійшло взагалі.
Типові виробничі завдання
Моделювання виробничих процесів - це дуже складна і копітка робота: потрібно зібрати, обробити та проаналізувати безліч даних з різних відділів та виробничих ланцюжків. Докладніше про це ви можете прочитати у статті «».
Коли ми зайнялися моделюванням нашого виробничого процесу, то мали конкретну мету — донести до кожного співробітника, який бере участь у розробці продуктів нашої компанії, і до керівників проектів:
- як продукти та їх компоненти, починаючи від комміта рядка коду, доходять до замовника у вигляді інсталяторів та оновлень,
- якими ресурсами забезпечено кожен етап виробництва товарів,
- які послуги беруть участь кожному етапі,
- як розмежовані зони відповідальності для кожного етапу,
- які контракти існують на вході та виході кожного етапу.
На кліку картинка відкриється в повному розмірі
Наша робота в компанії поділена на декілька функціональних напрямків. Напрямок інфраструктури оптимізує експлуатацію всіх «залізних» ресурсів відділу, а також автоматизує розгортання віртуальних машин і оточення на них. Напрямок моніторингу забезпечує контроль працездатності сервісів 24/7; також ми надаємо моніторинг як сервіс для розробників. Напрямок workflow надає командам інструменти для управління процесами розробки та тестування, аналізу стану коду, отримання аналітики по проектам. Нарешті, напрямок webdev забезпечує публікацію релізів на серверах оновлень GUS та FLUS, а також ліцензування продуктів за допомогою сервісу LicenseLab. Для підтримки виробничого конвеєра ми налаштовуємо та супроводжуємо безліч різних допоміжних сервісів для розробників (розповіді про деякі з них можна послухати на старих мітапах: и). Також ми розробляємо інструменти внутрішньої автоматизації, у тому числі .
За останні п'ять років у нашій роботі накопичилося безліч однотипних та рутинних операцій, а від наших розробників з інших відділів здебільшого приходять так звані типові завдання, Вирішення яких автоматизовано повністю або частково, не викликає труднощів у виконавців і не вимагає значних обсягів робіт. Спільно з провідними напрямками ми проаналізували такі завдання та змогли виділити окремі категорії робіт, або виробничі етапи, етапи розбили на неподільні кроки, та якщо з кількох етапів складається виробничий технологічний ланцюжок.
Найпростіший приклад технологічного ланцюжка - це етапи складання, деплою та тестування кожного нашого продукту всередині компанії. У свою чергу, наприклад, етап складання складається з безлічі окремих типових кроків: викачування вихідних джерел з GitLab, підготовка залежностей та 3rd-party бібліотек, юніт-тестування та статичний аналіз коду, виконання білд-сценарію на GitLab CI, публікація артефактів у сховище на Artifactory та генерація реліз-нотів через наш внутрішній інструмент ChangelogBuilder.
Про типові завдання DevOps ви можете прочитати в інших наших статтях на Хабре: «» та «».
Безліч типових виробничих ланцюжків утворюють виробничий процес. Стандартний підхід до опису процесів – використовувати функціональні IDEF0-моделі.
Приклад моделювання виробничого CI-процесу
Особливу увагу ми приділили розробці типових проектів системи безперервної інтеграції. Це дозволило досягти уніфікації проектів, виділивши так звану релізну схему збірок із просуваннями.
Ось як це працює. Всі проекти виглядають типовими: вони включають конфігурацію збірок, які потрапляють до snapshot-репозиторій на Artifactory, після чого здійснюється їхнє розгортання та тестування на тестових стендах, а потім просування в релізний репозиторій. Сервіс Artifactory є єдиною точкою поширення всіх артефактів збирання між командами та іншими сервісами.
Якщо дуже спростити і узагальнити нашу релізну схему, то вона включає такі етапи:
- кроссплатформенна збірка продукту,
- деплой на тестові стенди,
- запуск функціональних та інших тестів,
- просування протестованих збірок у релізні репозиторії на Artifactory,
- публікація релізних збірок на сервери оновлень,
- доставка збірок та оновлень на продакшн,
- запуск інсталяції та оновлення продукту.
Розглянемо для прикладу технологічну модель цієї типової релізної схеми (далі просто Модель) у вигляді функціональної IDEF0-моделі. У ньому відбито основні етапи нашого CI-процесу. У IDEF0-моделях використовується так звана ICOM-нотація (Input-Control-Output-Mechanism) для опису того, які ресурси використовуються на кожному етапі, на підставі яких правил та вимог виконується робота, що виходить на виході та які механізми, сервіси чи люди реалізують конкретний етап.
На кліку картинка відкриється в повному розмірі
Як правило, у функціональних моделях легше декомпозувати та деталізувати опис процесів. Але зі зростанням числа елементів зрозуміти в них щось стає дедалі складнішим. А в реальній розробці є ще й допоміжні етапи: моніторинг, сертифікація продуктів, автоматизація робочих процесів та інші. Саме через проблему масштабування ми відмовилися від такого опису.
Народження надії
В одній книжці натрапили на старі радянські карти описи технологічних процесів (які, до речі, застосовуються і зараз на багатьох держпідприємствах та у вузах). Стривайте, стривайте, адже в нас теж технологічний процес!.. Є етапи, результати, метрики, вимоги, показники та інше… Чому б не спробувати застосувати технологічні карти і до наших продуктових конвеєрів? З'явилося почуття: «Ось воно! Ми намацали потрібну ниточку, настав час за неї гарненько потягнути!»
У простій таблиці ми вирішили по стовпчиках фіксувати продукти, а по рядках - технологічні етапи та кроки продуктового конвеєра. Етапи - це щось велике, наприклад етап збирання продукту. А кроки - це щось дрібніше і детальніше, наприклад крок завантаження вихідного коду на складальний сервер або крок компіляції коду.
На перетинах рядків та стовпців карти ми проставили статуси для конкретного етапу та продукту. Для статусів визначили безліч станів:
- Немає даних - або недоцільно. Потрібно провести аналіз затребуваності етапу у продукті. Або аналіз вже проведено, але етап на даний момент не потрібний або економічно не обґрунтований.
- відкладено - або неактуально зараз. Етап у конвеєрі потрібний, але сил на реалізацію цього року немає.
- Заплановано. Етап заплановано для реалізації цього року.
- реалізовано. Етап у конвеєрі реалізований у необхідному обсязі.
Заповнення таблиці розпочали попроектно. Спочатку класифікували етапи та кроки одного проекту та зафіксували статуси за ними. Потім взяли наступний проект, зафіксували статуси у ньому та додали відсутні у попередніх проектах етапи та кроки. У результаті отримали етапи та кроки всього нашого виробничого конвеєра та їх статуси у конкретному проекті. Вийшло щось схоже на матрицю компетенцій продуктового конвеєра. Таку матрицю назвали технологічною картою.
За допомогою технологічної карти ми метрологічно обґрунтовано узгоджуємо з командами плани робіт на рік та цільові показники, яких хочемо спільно досягти: які етапи додаємо цього року у проект, а які залишаємо на потім. Також у процесі роботи у нас можуть з'явитися покращення етапів, які ми виконали лише для одного продукту. Тоді ми розширюємо нашу карту і вносимо це покращення як етап чи новий крок, потім проводимо аналіз щодо кожного продукту та з'ясовуємо доцільність тиражування покращення.
Нам можуть заперечити: «Це все, звичайно, добре, тільки згодом кількість кроків і етапів стане дуже великою. Як бути?"
Ми ввели стандартні та досить повні описи вимог для кожного етапу та кроку, щоб усередині компанії вони розумілися всіма однаково. Згодом, при впровадженні покращень, крок може бути поглинений в іншому етапі чи кроці — тоді вони «схлопнуться». При цьому всі вимоги та технологічні нюанси вписуються у вимоги узагальнюючого етапу чи кроку.
Як оцінити ефект від тиражування рішень? Ми використовуємо дуже простий підхід: початкові капітальні витрати на реалізацію нового етапу ми відносимо на річні загальнопродуктові витрати, а потім ділимо на всіх при тиражуванні.
Частини розробки вже відображені як етапи та кроки на карті. Ми можемо вплинути зменшення вартості товару через використання автоматизації для типових етапів. Після цього вважаємо зміни якісних характеристик, кількісних метрик і одержуваний командами профіт (у людино-годинах або машино-годинах економії).
Технологічна карта виробничого процесу
Якщо взяти всі наші етапи та кроки, закодувати тегами і розгорнути в один ланцюжок, то він вийде дуже довгим і незрозумілим (якраз, той самий «хвіст пітона», про який ми говорили на початку статті):
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Це етапи збирання продуктів [Build], їх деплою на тестові сервери [Deploy], тестування [Test], просування збірок у релізні репозиторії за підсумками тестування [Promote], генерації та публікації ліцензій [License], публікації [Publish] на сервері оновлень GUS та доставки до серверів оновлень FLUS, інсталяції та оновлення компонентів продуктів на інфраструктурі замовника засобами Product Configuration Management [Install], а також збирання телеметрії [Telemetry] із встановлених продуктів.
Крім них можна виділити окремі етапи: моніторинг стану інфраструктури [InfMonitoring], управління версіями вихідного коду [SourceCodeControl], підготовки складального оточення [Prepare], управління проектами [Workflow], забезпечення команд засобами комунікації [Communication], сертифікації продуктів [Certification] та забезпечення самодостатності CI процесів [CISelfSufficiency] (наприклад, незалежності збірок від інтернету). Десятки кроків у наших процесах навіть не розглядатимемо, бо вони дуже специфічні.
Буде набагато легше зрозуміти та окинути поглядом весь виробничий процес, якщо уявити його у вигляді технологічної карти; це таблиця, у якій рядками записані окремі виробничі етапи і декомпозовані кроки Моделі, а, по стовпцям — опис те, що робиться кожному етапі чи кроці. Основний акцент зроблено на ресурсах, які забезпечують кожен етап, та розмежування зон відповідальності.
Карта для нас – це своєрідний класифікатор. Вона відбиває великі технологічні частини виробництва товарів. Завдяки їй нашій команді автоматизаторів стало легше взаємодіяти з розробниками та спільно планувати впровадження етапів автоматизації, а також розуміти, які трудовитрати та ресурси (людські та «залізні») для цього будуть потрібні.
Усередині нашої компанії карта автоматично генерується із jinja-шаблону у вигляді звичайного HTML-файлу, а потім викладається на сервер GitLab Pages. Скриншот з прикладом повністю згенерованої карти можна переглянути .
На кліку картинка відкриється в повному розмірі
Якщо сказати коротко, то технологічна карта - це узагальнена картина виробничого процесу, де відображено чітко класифіковані блоки з типовою функціональністю.
Структура нашої технологічної карти
Карта складається з кількох частин:
- Область заголовків - тут знаходиться загальний опис карти, вводяться базові поняття, визначаються основні ресурси та результати виробничого процесу.
- Інформаційна панель - тут можна керувати відображенням даних по окремих продуктах, наводиться зведення по реалізованих етапах і кроків загалом по всіх продуктах.
- Технологічна карта - табличний опис технологічного процесу. На карті:
- наведено всі етапи, кроки та їх коди;
- дано короткий та повний опис етапів;
- вказані вхідні ресурси та послуги, що використовуються на кожному етапі;
- вказані результати кожного етапу та окремого кроку;
- вказано зону відповідальності за кожним етапом та кроком;
- визначено технічні ресурси, наприклад HDD (SSD), RAM, vCPU, та людино-годинник, необхідний підтримки робіт на даному етапі, як на даний момент — факт, так і в майбутньому — план;
- кожному за продукту зазначено, які технологічні етапи чи кроки йому реалізовані, плануються до впровадження, неактуальні чи реалізовані.
Прийняття рішень на основі технологічної карти
Вивчивши карту, можна зробити деякі дії - в залежності від ролі співробітника в компанії (керівник розробки, менеджер продукту, розробник або тестувальник):
- зрозуміти, які етапи відсутні у реальному продукті чи проекті, та оцінити необхідність їх впровадження;
- розмежувати зони відповідальності між кількома відділами, якщо працюють над різними етапами;
- домовитися про контракти на входах та виходах етапів;
- інтегрувати свій етап робіт у загальний процес розробки;
- точніше оцінити потреба у ресурсах, які забезпечують кожен із етапів.
Резюмуючи все сказане вище
Технологічна карта універсальна, розширювана та легко підтримується. Розробляти та супроводжувати опис процесів у такому вигляді набагато легше, ніж у суворій академічній IDEF0-моделі. Крім того, табличне опис простіше, звичніше і краще структуровано, ніж функціональна модель.
За технічну реалізацію кроків у нас відповідає спеціальний внутрішній інструмент CrossBuilder — інструмент прошарок між CI-системами, сервісами та інфраструктурою. Розробнику не потрібно пиляти свій велосипед: у нашій CI-системі достатньо запустити один із скриптів (так званий task) інструменту CrossBuilder, який правильно його виконає з урахуванням особливостей нашої інфраструктури.
Підсумки
Стаття вийшла досить довгою, але це неминуче в описах моделювання складних процесів. Насамкінець хочеться коротко зафіксувати наші основні ідеї:
- Мета впровадження ідей DevOps у нашій компанії — послідовне зниження собівартості виробництва та супроводу продуктів компанії в кількісних показниках (людино-годиннику або машино-годиннику, vCPU, RAM, Disk).
- Спосіб зниження загальної собівартості розробки - мінімізація вартості виконання типових серійних завдань: етапів та кроків технологічного процесу.
- Типове завдання — це завдання, вирішення якого автоматизоване повністю або частково, не викликає труднощів у виконавців і не потребує значних витрат.
- Виробничий процес складається з етапів, етапи розбиті на неподільні кроки, які є типовими завданнями різного масштабу та обсягу.
- Від розрізнених типових завдань ми дійшли складних технологічних ланцюжків та багаторівневих моделей виробничого процесу, які можуть бути описані функціональною IDEF0-моделлю або більш простою технологічною картою.
- Технологічна карта - це табличне уявлення етапів та кроків виробничого процесу. Найголовніше: карта дозволяє побачити весь процес повністю, великими шматками з можливістю їх деталізації.
- На основі технологічної карти можна оцінити необхідність впровадження етапів у тому чи іншому продукті, розмежувати зони відповідальності, домовитися про контракти на входах та виходах етапів, точніше оцінити потребу в ресурсах.
У наступних статтях ми докладніше розповімо у тому, якими технічними інструментами реалізуються ті чи інші технологічні етапи нашій карті.
Автори статті:
- - Керівник відділу автоматизації (DevOps) компанії Positive Technologies
- - Зам. керівника відділу автоматизації (DevOps) компанії Positive Technologies
Джерело: habr.com