Неодамна присуствував на DevOpsForum 2019, чиј домаќин беше Logrocon. На оваа конференција, учесниците се обидоа да најдат решенија и нови алатки за ефективна интеракција помеѓу бизнисот и специјалистите за услуги за развој и информатичка технологија.
Конференцијата беше успешна: имаше навистина многу корисни извештаи, интересни формати на презентации и многу комуникација со говорниците. И особено е важно што никој не се обиде да ми продаде ништо, нешто за што во последно време се виновни говорниците на големите конференции.
Извадок од говорите на Рајфајзенбанк, Алфастрахование, искуството на Манго Телеком во имплементирањето на автоматизацијата и други детали под резимето.
Јас се викам Јана, работам како тестер, се занимавам со автоматизација, како и DevOps, и сакам да одам на конференции и состаноци. Во текот на изминатите две години, бев на конференциите на Олег Бунин (HighLoad++, TeamLead Conf), Jug настани (Heisenbug, JPoint), TestCon Москва, DevOps Pro Moscow, Big Data Moscow.
Пред сè, привлекувам внимание на програмата на конференцијата. Помалку гледам на што ќе биде извештајот, а повеќе на говорникот. Дури и ако извештајот испадне дека е многу технолошки и интересен, не е факт дека ќе можете да примените некои од најдобрите практики од извештајот во вашата компанија. И тогаш ви треба звучник.
Светло на крајот од гасоводот кај Рајфајзенбанк
Обично, ловам звучници на страна што ме интересираат. На 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 со директорот за развој во Alfastrakhovanie
Шлагот на тортата DevOpsForum 2019 за мене беше едночасовната пленарна сесија со експерти од DevOps. Четири учесници на сесијата беа поканети да ги разгледаат DevOps од различни агли: Антон Исанин (Alfstrakhovanie, директор за развој), Наилија Замашкина (Fintech Lab, оперативен директор), Олег Егоркин (Rostelecom, Agile тренер) и Антон Мартјанов (независен експерт, погледна во DevOps од деловна гледна точка).
Експертите седнаа поблиску до луѓето и тогаш работите почнаа да се случуваат: цел час учесниците од публиката ги поставуваа своите прашања, а експертите го земаа рапот. Понекогаш имаше вистински дебати. Прашањата беа многу различни, на пример: дали воопшто се потребни инженери DevOps, зошто не можат да бидат обучени како системски администратори, дали DevOps треба да се нуди на сите, која е неговата вредност итн.
Потоа разговарав лично со Антон Исанин. Разговаравме за потребата да се донесе културата на DevOps во секој дом и ја откривме темната страна на трансформацијата на DevOps.
Ајде да замислиме дека сите се собраа и одлучија дека DevOps е потребен и на производот и на бизнисот и на тимот. Ајде да го спроведеме. Сè успеа. Издишивме. DevOps нè приближи до клиентот, сега можеме брзо да ги исполниме сите негови желби. Како резултат на тоа, имаме голем оддел за оперирање со строги регулативи и барања, кој постојано наоѓа дефекти на производот и создава еден куп барања. Покрај тоа, на сите дефекти им е доделен статус „итно“, дури и ако клиентот неочекувано сакал да го обои копчето жолто наместо зелено. Проектот расте, бројот на изданија расте и, соодветно, бројот на дефекти и недоразбирања на новата функционалност од страна на клиентите. Ops вработува уште 10 луѓе за да бидат во тек со пријавувањето дефекти, а развојот ангажира уште 15 за да биде во тек со нивното затворање. И наместо да воведува нови функции, тимот работи со бескрајни SD, објаснувајќи ја функционалноста на корисникот и поддршката во исто време. Како резултат на тоа, и Опциите и развојот се во бизнис, но клиентот и бизнисот се незадоволни: новите функции се заглавени. Излегува дека DevOps се чини дека постои, но се чини дека не постои.
Во однос на потребата од имплементација на DevOps, Антон јасно изјави дека тоа директно зависи од обемот на бизнисот. Ако сервисирањето на еден клиент годишно и носи милијарда на компанијата, DevOps не е потребен (под услов да не треба редовно да објавувате нови промени на овој клиент). Сè е покриено со чоколадо. Но, ако бизнисот расте и се појават повеќе клиенти, тогаш треба да се усогласите. Како по правило, во компанијата првично нема кул Ops. Прво го сечеме производот и дури потоа разбираме дека за да може производот да работи, треба да внимаваме на серверите и да ги следиме набавките. Тоа е кога Ops доаѓа во битие. Останува да се разбере дека Ops, како посебна поделба, ќе започне да поставува еден куп бариери за развој и сите испораки ќе почнат да застојат. Тоа е, во овој случај, културата на DevOps е веќе релевантна, но не смееме да заборавиме на нејзината темна страна.
Извор: www.habr.com