Поставили якось замовнику на один об'єкт систему електронного документообігу. А потім на інший об'єкт. І ще один. І на четвертий, і п'ятий. Захопилися настільки, що дійшли 10 розподілених об'єктів. Потужно вийшло… особливо коли ми дійшли до постачання змін. У рамках поставки на продуктивний контур на 5 сценаріїв системи тестування в результаті знадобилося 10 годин та 6-7 співробітників. Такі витрати змушували нас виконувати постачання якомога рідше. Через три роки експлуатації ми не витримали і вирішили приправити проект щіпкою DevOps.
Тепер все тестування проходить за 3 години, і в ньому бере участь 3 особи: інженер та два тестувальники. Поліпшення чітко виражаються у цифрах та ведуть до скорочення всіма улюбленого TTM. На наш досвід, замовників, яким може допомогти DevOps, набагато більше, ніж тих, хто про нього взагалі знає. Тому, щоб зробити DevOps ближче до людей, ми розробили простий конструктор, про якого розповімо докладніше у цьому пості.
Тепер розповімо докладніше. В одній енергетичній компанії на 10 великих об'єктах розгортається система технічного документообігу. У проектах такого масштабу без DevOps випливти непросто, адже велика частка ручної праці сильно затягує роботи і до того ж знижує якість — усі ручні роботи можуть призвести до помилок. З іншого боку, є проекти, де інсталяція одна, але потрібно, щоб усе працювало автоматично, постійно і безвідмовно, наприклад, ті ж самі системи документообігу у великих монолітних організаціях. Інакше внесе хто налаштування вручну, забуде про інструкцію з розгортання - а в результаті на проді настроювання загубиться і все впаде.
Зазвичай ми працюємо із замовником через контракт, і у цьому випадку наші інтереси трохи розходяться. Замовник дивиться на проект суворо у межах бюджету та ТЗ. Буває складно пояснити йому користь різних DevOps-практик, які не входять до ТЗ. А якщо він зацікавлений у швидких релізах із доданою цінністю для бізнесу, у вибудовуванні конвеєра з автоматизації?
На жаль, у роботі із заздалегідь затвердженою вартістю цей інтерес не завжди вдається намацати. У нашій практиці був випадок, коли довелося підхопити розробку за неохайним і неакуратним підрядником. Це був страх: актуальних вихідних кодів немає, кодова база однієї і тієї ж системи на різних інсталяціях різна, документація частково була відсутня, частково була жахливої якості. Зрозуміло, у замовника у своїй був управління вихідним кодом, складанням, релізами тощо.
Поки що про DevOps знають далеко не всі, але варто заговорити про його переваги, реальну економію ресурсів, очі спалахують у всіх замовників. Отже, запитів, що включають DevOps, згодом стає дедалі більше. Тут, щоб легко заговорити однією мовою із замовниками, нам потрібно швидко пов'язувати проблеми бізнесу та практики DevOps, які допоможуть побудувати відповідний конвеєр розробки.
Отже, у нас є набір проблем з одного боку, є знання, практики та інструменти DevOps з іншого. Чому б не поділитися досвідом із усіма?
Створюємо DevOps-конструктор
Свій маніфест має Agile. Своя методологія має ITIL. DevOps пощастило менше — шаблонами та стандартами він поки що не обріс. Хоча визначати ступінь зрілості підприємств, з оцінки їх методик розробки та експлуатації.
На щастя, відома компанія Gartner у 2014 році та проаналізувала ключові DevOps-практики та взаємозв'язки між ними. На основі цього випустила інфографіку:
Її ми взяли за основу свого . У кожній із чотирьох сфер є набір інструментів — ми зібрали їх у базу, виділили найпопулярніші, визначили точки інтеграції та відповідні механізми оптимізації. Усього вийшло 36 практик та 115 інструментів, Чверть з яких - відкрите або вільне ПЗ. Далі ми розповімо про те, що в нас вийшло у кожній сфері і для прикладу — про те, як це реалізовано у проекті зі створення технічного документообігу, з якого ми розпочали посаду.
процеси
У горезвісному проекті по СЕД система управління технічною документацією була розгорнута за тією ж схемою на кожному з 10 об'єктів. В інсталяцію входить 4 сервери: сервер бази даних, сервер додатків, повнотекстової індексації та управління змістом. В інсталяції вони працюють у рамках єдиного вузла, розміщуються у ЦОД на об'єктах. Усі об'єкти трохи різняться за інфраструктурою, але глобальній взаємодії це не заважає.
Спочатку ми відповідно до практик DevOps автоматизували інфраструктури локально, потім доводили поставку до тестового контуру, а потім до продуктива замовника. Кожен процес відпрацювали покроково. Параметри оточення зафіксовані в системі вихідних кодів, з урахуванням яких збирається дистрибутив для автоматичного оновлення. У разі змін у конфігурації інженерам потрібно просто внести до системи контролю версій відповідні зміни, і тоді автоматичне оновлення пройде без проблем.
Завдяки такому підходу процес тестування дуже спростився. Раніше у проекті були тестувальники, які тільки й робили, що вручну оновлював стенди. Зараз вони просто приходять, дивляться, що все запрацювало і займаються кориснішими справами. Кожне оновлення тестується автоматично – від поверхневого рівня до автоматизації бізнес-сценарію. Результати викладаються у вигляді окремих звітів у TestRail.
Культура
Безперервне експериментування краще пояснити на прикладі дизайну тестів. Протестувати систему, якої ще немає – творча робота. При написанні тест-плану потрібно зрозуміти, як протестувати правильно, якими гілками пройти. А ще знайти баланс між часом та бюджетом, щоб визначити оптимальну кількість перевірок. Важливо вибрати саме необхідні тести, продумати, як користувач взаємодіятиме з системою, врахувати оточення та можливі зовнішні чинники. Без безперервного експериментування не обійтись.
Тепер про культуру взаємодії. Раніше було дві протиборчі сторони — інженери та розробники. Розробники казали: «Нам все одно як це запускатиметься. Ви інженери, ви розумні, зробіть так, щоб він експлуатувався без збоїв». Інженери відповідали: «Ви, розробники, надто необережні. Давайте ви будете обережнішими, а ми будемо рідше ваші релізи ставити. Тому що ви щоразу дірявий код нам ставите і як нам взаємодіяти — незрозуміло». Це проблема культурної взаємодії, яка з точки зору DevOps вибудовується інакше. Тут у тебе і інженери, і розробники є частиною єдиної команди, яка націлена на змінний, але в той же час надійний софт.
У масштабах однієї команди фахівці налаштовані на допомогу один одному. Як було раніше? Готувалася, наприклад, якась товста інструкція з розгортання сторінок на 50. Інженер читав її, щось не розумів, матюкався і просив розробника о третій годині ночі прокоментувати. Розробник коментував і теж матюкався - у результаті ніхто не був радий. Плюс, природно, були якісь помилки, тому що в інструкції все не згадаєш. А зараз інженер разом із розробником пише скрипт автоматизованого розгортання інфраструктури прикладного ПЗ. І розмовляють вони одна з одною вже практично однією мовою.
Люди
Розмір команди визначається масштабами поновлення. Команда набирається при формуванні поставки, до неї входять охочі із спільної проектної команди. Потім пишеться план оновлення з відповідальними за кожен етап, у міру виконання команда звітує. Усі учасники команди взаємозамінні. У складі команди у нас також є розробник на підстрахування, але йому практично ніколи не доводиться підключатися.
Технології
У схемі за технологіями виділено кілька пунктів, але під ними знаходиться купа технологій — з їхніми описами можна випустити цілу книгу. Тож ми виділимо найцікавіше.
Інфраструктура як код
Зараз, напевно, цією концепцією нікого не здивуєш, але раніше опис інфраструктур залишали бажати кращого. , тестові середовища були унікальні, їх пестили і плекали, з них здували порошинки.
Нині ніхто не боїться експериментувати. Є базові образи віртуальних машин, є готові сценарії з розгортання середовищ. Усі шаблони та сценарії зберігаються в системі контролю версій та оперативно оновлюються. Раніше, коли потрібно було доставити пакет на стенд, при цьому з'являвся конфігураційний розрив. Зараз потрібно просто дописати рядок у вихідному коді.
Крім сценаріїв інфраструктури та пайплайнів, підхід Documentation as a Code застосовують і для документації. Завдяки цьому легко підключати нових людей до проекту, знайомити їх із системою за функціями, описаними, наприклад, у тест-плані, а також наново використовувати тест-кейси.
Безперервне постачання та моніторинг
Про DevOps ми розповіли, як вибирали інструменти для реалізації безперервного постачання та моніторингу. Найчастіше не потрібно нічого переписувати - достатньо використовувати раніше написані скрипти, правильно вибудувати інтеграцію між компонентами та зробити загальну консоль керування. І всі процеси можна буде запускати за однією кнопкою чи розкладом.
В англійській є різні поняття, Continuous Delivery та Continuous Deployment. Обидва можна перекласти як "безперервне постачання", але за фактом між ними є невелика різниця. У нашому проекті з технічного документообігу розподіленої енергетичної компанії використовується швидше Delivery — коли установка на прод йде по команді. У Deployment установка відбувається автоматично. Continuous Delivery у цьому проекті взагалі став центральною частиною DevOps.
Загалом, за допомогою збору певних параметрів можна чітко зрозуміти, чим корисні DevOps-практики. І донести це до керівництва, котре дуже любить цифри. Загальна кількість запусків, час виконання етапів сценарію, частка успішних запусків - все це безпосередньо впливає на улюблений time to market, тобто час від комміту в систему контролю версій до випуску версії на продуктивному середовищі. З використанням необхідних інструментів інженери отримують цінні показники поштою, а менеджер проекту бачить їх у дашборді. Так можна одразу оцінити користь нових інструментів. Приміряти їх до своєї інфраструктури можна за допомогою DevOps-конструктора.
Кому знадобиться наш ?
Не кривитимемо душею: для початку він став корисним нам. Як ми вже сказали, із замовником потрібно розмовляти однією мовою, і за допомогою конструктора DevOps ми можемо швидко накидати основу для такої розмови. Фахівці з бізнесу зможуть самі оцінювати, що їм потрібно, і таким чином швидше розвиватись. Ми постаралися зробити конструктор максимально докладним, додали купу описів, щоб будь-який користувач розумів, що вибирає.
Формат конструктора дозволяє врахувати вже наявні у компанії напрацювання з вибудовування процесів, автоматизації. Не треба все ламати і будувати заново, якщо можна вибрати лише рішення, які нормально інтегруються в існуючі процеси, які можуть просто заповнити прогалини.
Можливо, ваша технологія вже перейшла на більш високий рівень і наш інструмент здасться надто «капітанським». Але ми знаходимо його корисним для себе і сподіваємося, що він знадобиться комусь із читачів. Нагадуємо на конструктор - якщо що, схему ви отримуєте відразу після введення вихідних даних. Будемо вдячні за відгуки та доповнення.
Джерело: habr.com