Наскоро присъствах на DevOpsForum 2019, организиран от Logrocon. На тази конференция участниците се опитаха да намерят решения и нови инструменти за ефективно взаимодействие между бизнеса и специалистите по разработка и обслужване на информационни технологии.
Конференцията беше успешна: имаше наистина много полезни доклади, интересни презентационни формати и много комуникация с лекторите. И е особено важно, че никой не се опита да ми продаде нещо, нещо, за което лекторите на големи конференции са виновни напоследък.
Откъс от изказванията на Райфайзенбанк, Алфастрахование, Опитът на Mango Telecom в внедряването на автоматизация и други подробности под разреза.
Казвам се Яна, работя като тестер, занимавам се с автоматизация, както и с DevOps и обичам да ходя на конференции и срещи. През последните две години бях на конференциите на Олег Бунин (HighLoad++, TeamLead Conf), Jug събития (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
На първо място, обръщам внимание на програмата на конференцията. Гледам по-малко какво ще бъде докладът, а повече оратора. Дори ако докладът се окаже много технологичен и интересен, не е факт, че ще можете да приложите някои от добрите практики от доклада във вашата компания. И тогава имате нужда от високоговорител.
Светлина в края на тръбопровода в Райфайзенбанк
Обикновено търся оратори отстрани, които ме интересуват. На DevOpsForum 2019 лектор от Райфайзенбанк, Михаил Бижан, привлече интереса ми. По време на речта си той говори за това как те постепенно привличат своите екипи към DevOps, защо имат нужда от това и как да продадат идеята за трансформация на DevOps на бизнеса. Е, като цяло говорих за това как да видя светлината в края на тръбопровода.
Михаил Бижан, директор по автоматизация в Райфайзенбанк
Сега те нямат „DevOps“ в своята компания. Тоест работи, но не във всички отбори. При внедряването на DevOps те разчитат на готовността на екипите, както по отношение на конкретни инженери, така и по отношение на необходимостта от продукта и зрелостта на платформата, върху която е изграден този продукт. Миша каза как да обясни на бизнеса защо е необходим DevOps.
Банковият сегмент има няколко фактора за растеж: цена на услугите и разширяване на клиентската база. Увеличаването на цената на услугите не е много добър двигател, но увеличаването на клиентската база е обратното. Ако конкурентите пуснат обективно готин продукт, всички клиенти отиват там, след което с течение на времето пазарът се изравнява. Ето защо въвеждането на нови продукти на пазара и скоростта на въвеждането им е основното, върху което банките се фокусират. Точно за това е DevOps и бизнесът разбира това.
Следващата важна забележка: DevOps не винаги намалява времето за излизане на пазара. DevOps не може да работи сам, той е просто част от процеса на създаване и пускане на продукт на пазара от разработка до производство (от код до клиент). Но всичко преди кода не е пряко свързано с DevOps. Това означава, че търговците могат да изучават пазара с години и да прекарат целия си живот в догонване на конкурентите. Необходимо е бързо да разберете от какво се нуждае клиентът и да планирате внедряването на тази или онази функция - често това не е достатъчно, за да работи DevOps и компанията да постигне целта си. Затова, на първо място, Райфайзенбанк се съгласи с бизнеса, че е необходимо да се научи как да използва DevOps. Автоматизацията в името на автоматизацията няма да помогне много в борбата за нови клиенти.
Като цяло Миша вярва, че DevOps трябва да се внедри, но разумно. И трябва да сме подготвени за факта, че в началото на трансформацията производителността на екипа ще падне, ще спечели по-малко пари, но след това ще бъде оправдано.
Автоматизация на тестването в Mango Telecom
Друг интересен доклад за мен като тестер направи Егор Маслов от Mango Telecom. Презентацията беше наречена „Автоматизация на пълния цикъл на тестване в SCRUM екип“. Егор вярва, че DevOps е създаден специално за SCRUM, но в същото време въвеждането на DevOps в SCRUM екип е доста проблематично. Това се случва, защото екипът на SCRUM винаги работи някъде, няма време да се разсейва от иновации и да възстановява процеса. Проблемът се крие и във факта, че SCRUM не включва разделянето на подекипи в екипа (тестващ екип, екип за разработка и т.н.). Е, освен това, за автоматизиране на съществуващ процес е необходима документация, а в SCRUM най-често липсва пълна документация - „продуктът е по-важен от някакъв вид писане“.
След като преминаха към SCRUM, тестерите започнаха да се консултират с разработчиците как да тестват функциите. Постепенно обемът на функционалността се увеличи, нямаше документация и започнаха да хващат много бъгове във функционалността, която не беше обхваната от тестове и като цяло вече не беше ясно кой и кога я е тествал. С две думи - объркване и колебание. Решихме да преминем към автоматизирано тестване. Но дори и тогава имаше пълен провал. Те наемат външни специалисти по автоматизация, които пишат върху стек, непознат за вътрешните тестери. Рамката за автотестове работи, разбира се, но след напускането на външните изпълнители, това продължи две седмици. След това беше опит за въвеждане на автотест номер две. Започна с факта, че всичко трябва да бъде изградено в рамките на компанията, самостоятелно (правилният вектор: изграждане на експертиза вътрешно), в рамките на SCRUM и създаване на документация в процеса. Стекът за автоматизация трябва да е равен на стека на продукта (тук го добавям, не тествайте вашия JavaScript проект с нищо друго). В края на спринта те направиха демонстрация на това как работи автотестът с целия екип (полезно). По този начин се увеличи ангажираността на всички членове на екипа в процеса на автоматизация, както и доверието в автотестовете и шанса този автотест със сигурност да бъде използван (и да не се коментира след месец поради постоянни неуспехи).
Между другото, на DevOpsForum 2019 имаше отворен микрофон - отдавна познат и според мен полезен формат на речи. Разхождате се така, слушате доклади и след това решавате, че на конференцията си струва да обсъдите определена тема или проблем, споделяйки съответния опит в решаването на проблема.
Забелязах също, че организаторите направиха поток от кратки доклади. Всеки доклад продължава не повече от 10 минути, последван от въпроси. По този начин можете да обхванете много теми наведнъж и да задавате въпроси на лектори, които ви интересуват.
Между презентациите се разхождах из щандовете на партньорите на конференцията и откраднах/спечелих много неща. О, харесва ми раздаване!
Кръгла маса и проблеми с DevOps с директора по развитие в Alfastrakhovanie
Черешката на тортата на DevOpsForum 2019 за мен беше едночасовата пленарна сесия с експертите на DevOps. Четирима участници в сесията бяха поканени да разгледат DevOps от различни ъгли: Антон Исанин (Alfastrakhovanie, директор по развитието), Наиля Замашкина (Fintech Lab, оперативен директор), Олег Егоркин (Rostelecom, треньор на Agile) и Антон Мартянов (независим експерт, разгледа DevOps от бизнес гледна точка).
Експертите седнаха по-близо до хората и тогава нещата започнаха да се случват: в продължение на цял час участници от публиката задаваха своите въпроси, а експертите поеха удара. Понякога имаше истински дебати. Въпросите бяха много различни, например: необходими ли са изобщо DevOps инженери, защо не могат да бъдат обучени за системни администратори, трябва ли DevOps да се предлага на всички, каква е стойността му и т.н.
Тогава разговарях лично с Антон Исанин. Обсъдихме необходимостта да пренесем културата на DevOps във всеки дом и разкрихме тъмната страна на трансформацията на DevOps.
Нека си представим, че всички се събраха и решиха, че DevOps е необходим както на продукта, така и на бизнеса и екипа. Да отидем да го приложим. Всичко се получи. Издишахме. DevOps ни доближи до клиента, сега можем бързо да изпълним всички негови желания. В резултат на това имаме голям Ops отдел със строги регулации и изисквания, който постоянно намира дефекти в продукта и създава куп заявки. Освен това всички дефекти получават статус „спешен“, дори ако клиентът неочаквано иска да оцвети бутона в жълто вместо в зелено. Проектът се разраства, броят на версиите расте и съответно броят на дефектите и неразбирането на новата функционалност от страна на клиентите. Ops наема още 10 души, за да бъде в крак с докладването на дефекти, а Developments наема още 15, за да бъде в крак със затварянето им. И вместо да въвежда нови функции, екипът работи с безкрайни SD, обяснявайки функционалността на потребителя и поддръжка в същото време. В резултат на това и операциите, и разработката работят, но клиентът и бизнесът са недоволни: новите функции блокират. Оказва се, че DevOps изглежда съществува, но изглежда не съществува.
По отношение на необходимостта от внедряване на DevOps, Антон ясно заяви, че това зависи пряко от мащаба на бизнеса. Ако обслужването на един клиент годишно носи на компанията милиард, DevOps не е необходим (при условие, че не е необходимо редовно да въвеждате нови промени в този клиент). Всичко е покрито с шоколад. Но ако бизнесът се разраства и се появяват повече клиенти, тогава трябва да се съобразите. По правило в компанията първоначално няма готини операции. Първо изрязваме продукта и едва тогава разбираме, че за да работи продуктът, трябва да следим сървърите и да следим доставките. Тогава се появява Ops. Остава да се разбере, че Ops, като отделно подразделение, ще започне да поставя куп бариери пред развитието и всички доставки ще започнат да спират. Тоест, в този случай DevOps културата вече е актуална, но не трябва да забравяме за нейната тъмна страна.
Източник: www.habr.com