Нядаўна я пабывала на 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 не заўсёды памяншае time to market. 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