Нещодавно я відвідала DevOpsForum 2019, яку влаштовував Logrocon. На цій конференції учасники намагалися знайти рішення та нові інструменти для ефективної взаємодії бізнесу та спеціалістів з розробки та інформаційно-технологічного обслуговування.
Конференція вдалася: було реально багато корисних доповідей, цікаві формати виступів та купа спілкування з доповідачами. І особливо важливо, що мені ніхто нічого не намагався продати, аніж останнім часом грішать спікери на великих конференціях.
Вижимання з виступів Райффайзенбанку, Альфастрахування, досвід Манго Телеком при впровадженні автоматизації та інші подробиці під катом.
Мене звуть Яна, я працюю тестувальником, займаюся автоматизацією, а також DevOps і обожнюю ходити на конференції та мітапи. За останні два роки я була на конференціях Олега Буніна (HighLoad++, TeamLead Conf), на заходах Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Насамперед я звертаю увагу на програму конференції. Найменшою мірою дивлюся на те, про що буде доповідь, більшою мірою — на спікера. Навіть якщо доповідь виявиться дуже технологічною та цікавою, не факт, що ти зможеш застосувати якісь best practices з доповіді у себе в компанії. І тоді тобі потрібний спікер.
Світло в кінці пайплайну в Райффайзенбанку
Зазвичай, я влаштовую полювання за цікавими мені спікерами в кулуарах. На DevOpsForum 2019 у поле мого інтересу потрапив доповідач із Райффайзенбанку Михайло Біжан. Під час виступу він розповів, як вони поступово підсаджують свої команди на DevOps, навіщо їм це потрібно та як продати бізнесу ідею DevOps-трансформації. Ну і загалом, говорив про те, як побачити світ наприкінці пайплайну.
Михайло Біжан, директор з автоматизації у Райффайзенбанку
Зараз у них у компанії не «тру DevOps». Тобто він тру, але не у всіх командах. При впровадженні DevOps вони спираються на готовність команд як з точки зору конкретних інженерів, так з точки зору потреби продукту і зрілості тієї платформи, на якій цей продукт побудований. Мишко розповів, як пояснити бізнесу навіщо потрібний DevOps.
У банківського сегмента є кілька драйверів зростання: вартість послуг та розширення клієнтської бази. Підвищення вартості послуг – не дуже хороший драйвер, а ось зростання клієнтської бази – навпаки. Якщо конкуренти випускають об'єктивно крутий продукт, то всі клієнти йдуть туди, потім згодом ринок вирівнюється. Тому виведення ринку нових продуктів і швидкість їх виведення — основна річ, яку орієнтуються банки. Саме для цього і потрібний DevOps, і бізнес це розуміє.
Наступне важливе зауваження: DevOps не завжди зменшує час до ринку. DevOps не може працювати один, це лише частина процесу створення та виведення продукту на ринок від розробки до продакшена (від коду до клієнта). Але все, що стосується коду, прямого відношення до DevOps немає. Тобто маркетологи можуть роками вивчати ринок та все життя наздоганяти конкурентів. Необхідно швидко розуміти, що потрібно клієнту і планувати реалізацію тієї чи іншої фічі — часто цього не вистачає для того, щоб DevOps працював і компанія досягала мети. Тому в першу чергу в Райффайзенбанку домовилися з бізнесом про те, що необхідно навчитися використовувати DevOps. Автоматизація заради автоматизації не дуже допоможе у боротьбі нових клієнтів.
Загалом, Мишко вважає, що DevOps потрібно впроваджувати, але з розумом. І треба бути готовим до того, що на початку трансформації у команди падатиме продуктивність, вона зароблятиме менше грошей, зате потім це виправдається.
Автоматизація тестування в «Манго Телеком»
Ще один цікавий для мене як для тестувальника доповідь зробив Єгор Маслов із «Манго Телеком». Презентація називалася "Автоматизація повного циклу тестування в SCRUM команді". Єгор вважає, що DevOps створений саме для SCRUM, але в той же час впровадити DevOps в SCRUM-команду досить проблематично. Так виходить тому, що SCRUM-команда весь час кудись біжить, ніколи відволікатися на нововведення та перебудовувати процес. Проблема також у тому, що SCRUM не передбачає виділення у команді суб-команд (команда тестувальників, команда розробників тощо). Ну і крім того, для автоматизації існуючого процесу потрібна документація, а в SCRUM найчастіше документація відсутня повністю — «продукт важливіший за якусь писанину».
Після переходу на SCRUM тестувальники стали радитися з розробниками, як тестувати фічі. Поступово обсяг функціоналу збільшувався, документація була відсутня, і вони почали ловити багато багів у тому функціоналі, в якому не було покриття тестами і взагалі вже не зрозуміло, хто і коли його тестував. Двома словами — розбрід і хитання. Вирішили перейти на автоматизацію тестування. Але й тоді трапився повний фейл. Вони залучили аутсорсних спеціалістів для автоматизації, які писали на невідомому для штатних тестувальників стеку. Фреймворк для автотестів, звичайно, працював, але після того, як аутсорсери пішли, він прожив два тижні. Далі була спроба запровадження автотестування номер два. Вона почалася з того, що все потрібно будувати всередині компанії, самотужки (правильний вектор: нарощуйте експертизу всередині), в рамках SCRUM, і в процесі створення документації. Стек для автоматизації повинен дорівнювати стеку продукту (ось тут прям плюсую, ну не тестуйте ви проект на JavaScript чимось іншим). Наприкінці спринту вони влаштовували демо того, як працює автотест за участю всієї команди (корисно). Таким чином, підвищувалися залучення до процесу автоматизації всіх членів команди, а також довіра до автотестів і шанс на те, що цей автотест точно використовуватиметься (а не буде закоментований через місяць через постійні провали).
До речі, на DevOpsForum 2019 працював відкритий мікрофон — давно відомий і, на мій погляд, корисний формат виступів. Ходиш ти такий, слухаєш доповіді, а потім вирішуєш, що в рамках конференції варто обговорити тему чи проблему, поділитися релевантним досвідом вирішення завдання.
Ще я зауважила те, що організатори зробили потік коротких доповідей. Кожна доповідь триває не більше 10 хвилин, потім йдуть питання. Таким чином можна охопити одразу багато тем і чіплятися із запитаннями до спікерів, які зацікавили.
Між доповідями прогулялася стендами партнерів конференції і потягла/виграла багато всякої всячини. Ех, люблю я роздатку!
Круглий стіл та питання DevOps з директором з розробки в Альфастрахування
Вишнею на торті DevOpsForum 2019 для мене стала годинникова пленарна сесія з експертами DevOps. Було запрошено чотирьох учасників сесії, які мали подивитися на DevOps з різних сторін: Антон Ісанін (Альфастрахування, директор з розробки), Наїля Замашкіна (Фінтех Лаб, операційний директор), Олег Єгоркін (Ростелеком, Agile-коуч) та Антон Мартьянов (незалежний) експерт, дивився на DevOps з погляду бізнесу).
Експерти сіли ближче до народу і тут помчало: цілу годину учасники із зали ставили свої запитання, а експерти віддувались. Іноді виходили справжні дебати. Питання були різні, наприклад: чи потрібні взагалі DevOps-інженери, чому не можна виростити їх із системних адміністраторів, чи треба всім пропонувати DevOps, в чому його цінність і так далі.
Потім я поспілкувалася з Антоном Ісаніним особисто. Обговорили необхідність нести культуру DevOps у кожний будинок та розкрили темну сторону DevOps трансформації.
Припустимо, що всі зібралися і вирішили, що DevOps потрібен як продукту, так і бізнесу та команді. Помчали впроваджувати. Все вийшло. Видихнули. DevOps зробив нас ближче до клієнта, тепер ми швидко зможемо виконувати усі його хотіння. У результаті маємо великий підрозділ Ops зі строгими регламентами та вимогами, і він постійно фігачить дефекти на продукт, створює купу заявок. Причому всі дефекти йдуть зі статусом терміново, навіть якщо клієнту несподівано захотілося розфарбувати кнопку в жовтий колір замість зеленого. Зростає проект, зростає кількість релізів і кількість дефектів і нерозуміння нової функціональності клієнтами. Ops наймає ще 10 людей, щоб встигати репортувати дефекти, а технологія наймає ще 15, щоб встигати їх закривати. І замість того, щоб впроваджувати нові фічі, команда працює з нескінченними SD'шками, пояснюючи функціонал користувачеві та й сапорту за одне. У результаті і Ops, і технологія при справі, але покупець і бізнес незадоволені: нові фічі застряють. Виходить, DevOps начебто є, а начебто його й немає.
Про необхідність впроваджувати DevOps Антон однозначно заявив, що це залежить від масштабів бізнесу. Якщо обслуговування одного клієнта на рік приносить компанії мільярд – DevOps не потрібний (за умови, що тобі не потрібно викочувати цьому клієнту нові зміни регулярно). Все й так у шоколаді. Але якщо бізнес зростає, з'являється більше клієнтів, то треба вже відповідати. Як правило, крутого Ops у компанії спочатку немає. Спочатку ми пиляємо продукт, а тільки потім розуміємо, щоб продукт працював, потрібно стежити за серверами, стежити за постачанням. Тоді і з'являється Ops. Залишається зрозуміти, що Ops як окремий підрозділ почне виставляти купу бар'єрів для розробки і всі поставки почнуть буксувати. Тобто в даному кейсі культура DevOps вже актуальна, тільки слід не забувати про її темну сторону.
Джерело: habr.com