7 снежня прайшла трэцяя канферэнцыя , арганізаваная маскоўскім DevOps-супольнасцю пры падтрымцы Mail.ru Cloud Solutions. Акрамя дакладаў вядучых практыкаў DevOps, удзельнікі маглі наведаць кароткія матывавальныя Lightning Talks, воркшопы і пагутарыць у апенспэйсах.
Мы сабралі важныя інсайты з шасці выступаў і правялі інтэрв'ю з некалькімі спікерамі, каб даведацца аб тым, што засталося за рамкамі дакладаў.
Унутры:
- Барух Садагурскі, JFrog: «Няхай софт цячэ ад вендара да карыстача, як вадкасць»
- Павел Селіванаў, Southbridge: «У Dev і Ops адна агульная задача – рабіць прадукт, які працуе»
- Уладзімір Страценка, X5 Retail Group: "DevOps у Enterprise – гэта распрацоўка без болю і пажараў"
- Сяргей Пузыроў, Facebook: "Production Engineer клапоціцца аб сэрвісе ў цэлым: каб і карыстальнікам, і распрацоўшчыкам было добра"
- Міхаіл Чынкоў, AMBOSS: "Па шляху DevOps не можа ісці адно падраздзяленне, па ім павінна ісці ўся кампанія"
- DevOps-энтузіясты Расбанка: "1000 дзён, каб укараніць DevOps у крывавым энтэрпрайзе"
1. Барух Садагурскі, JFrog: «Няхай софт цячэ ад вендара да карыстача, як вадкасць»
Фейлы пры абнаўленні софту здараюцца кожную гадзіну і ва ўсіх. Вось толькі адна страшная гісторыя з выступу: Knight Capital пасля няўдалага абнаўлення страцілі 440 млн долараў за гадзіну.
Барух распавёў пра DevOps-патэрны бесперапынных абнаўленняў, якія дапамогуць пазбегнуць правалаў і нянавісці карыстальнікаў:
Лакальны адкат - трымайце папярэднюю версію софту на дэвайсе, каб адкаціцца ў выпадку чаго. Гэта абароніць вас, калі ўсё будзе так дрэнна, што не атрымаецца даслаць патч па паветры.
Абнаўленні па паветры - лепш бесперапынныя. Інакш будзе, як з распрацоўшчыкамі Jaguar: з-за бага ў тармазной сістэме, якую нельга было абнавіць па паветры, прыйшлося адклікаць аўтамабілі з продажу. Гэта было балюча і дорага.
Бесперапынныя абнаўленні - абнаўляйце софт бесперапынна, як толькі гатовая новая фіча. Пры рэдкіх абнаўленнях фічы групуюцца, крытычнае абнаўленне можа чакаць некрытычныя. Як у Тэсла - абнаўленне, якое павінна было пафіксіць выпадковае тармажэнне, чакала абнаўлення гульні ў шахматы.
Аўтаматызаваны дэплоймент - заменіце людзей машынамі, бо людзі дрэнна ўмеюць выконваць руцінныя дзеянні.
Частыя абнаўленні - дапамагаюць выпрацаваць звычку і пазбавіцца ад страху. Рэдкія абнаўленні ператвараюцца ў аўральную падзею.
Веданне стану аксэсуара - тэстуйце абнаўленні, а не ўстаноўку з нуля. Гэта важна, бо абнаўленні могуць паводзіць сябе па-рознаму ў залежнасці ад стану девайса.
Канарэечныя рэлізы - выкочвайце абнаўленні невялікай колькасці карыстачоў і назірайце. Гэта зніжае шкоду, калі нешта пойдзе не так.
Абнаўленні без недаступнасці - Хай кліенты заўважаюць толькі новыя фічы, а не застаюцца без сэрвісу на некалькі тыдняў, пакуль вы выкаціце абнаўленне.
Мы пагаварылі з Барухам Садагурскім аб тым, як адрозніваецца погляд на DevOps у расійскім і заходнім IT, ці хутка Cloud будзе ўсё рабіць за нас і ці ўсе праграмныя сэрвісы скацяцца ў схему aaS.
2. Павел Селіванаў, Southbridge: «У Dev і Ops адна агульная задача – рабіць прадукт, які працуе»
Укараненне Kubernetes не дапаможа дасягнуць DevOps, і нават наадварот - можа ўсё зламаць. Павел распавёў, чаму тэхналогіі (нават самыя крутыя) не могуць вырашыць усе вашыя праблемы:
Складанасць праекта пераехала за межы кода. Раней было складанае прыкладанне: узаемадзеянне ўнутры праекта і складаная распрацоўка, але простая структура - адміністратар разгарнуў, усё працуе. Перайшлі да мікрасэрвісаў: кожны сэрвіс — простае прыкладанне, зносіны па стандартных пратаколах і хуткая распрацоўка, але структура праекта стала больш складанай. Складанасць праекта з мікрасэрвіснай архітэктурай нікуды не падзелася - яна пераехала за межы кода. Цяпер за яе адказвае DevOps-інжынер.
Распрацоўнікі не жадаюць змен пасля ўкаранення DevOps. У выніку воркфлоў з Kubernetes працягвае выглядаць як перакіданне задач ад Dev да Ops праз сцяну, толькі ўжо не метафарычную такой сцяной становіцца Git. Распрацоўнік туды змяшчае код і працуе як раней, а ў адмінаў ёсць Kubernetes, CI/CD і ўсё астатняе.
Аднак распрацоўнікам трэба прыняць змены. Сітуацыя, калі распрацоўшчыкі не ведаюць, што робяць адміны, а адміны не ведаюць, што адбываецца ў распрацоўшчыкаў, стварае праблемы.
Калі ў распрацоўшчыкаў нічога не памянялася, яны не ўсведамляюць, што праца прыкладання іх адказнасць - розныя тэхнічныя хітрыкі працаваць не будуць.
З прыходам DevOps і Kubernetes у распрацоўцы шматлікае памяняецца. Dev павінны быць кампетэнтныя ў Ops, і наадварот. У гэтых адмыслоўцаў свае спецыфічныя навыкі, але яны павінны быць у курсе працы адзін аднаго. Dev і Ops трэба пасябраваць да ўкаранення Kubernetes, інакш вы паламаць тое, што ёсць.
Павел Селіванаў распавёў аб тым, што будзе з Kubernetes праз 5 гадоў і на чым будаваць тэхналагічны стэк сучаснаму стартапу - глядзіце інтэрв'ю:
3. Уладзімір Страценка, X5 Retail Group: "DevOps у Enterprise – гэта распрацоўка без болю і пажараў"
Кампаніі прыходзяць да DevOps-трансфармацыі, калі разумеюць, што распрацоўка занадта павольная і не адпавядае рэаліям, у іх з'яўляецца жаданне распрацоўваць лепш і выкочваць хутчэй.
Уладзімір распавёў, як гэта адбываецца, і ў чым тут падвох:
- Спачатку кампаніі наймаюць DevOps-інжынера. Гэта Senior System Administrator, ён займаецца разгортваннем рэлізу ў вытворчасць, стандартызацыяй асяроддзя распрацоўкі, наладай інфраструктуры, выяўленнем і фіксам розных праблем, аўтаматызацыяй працэсаў і іншымі тэхнічнымі задачамі.
- Потым аднаго DevOps-інжынера ўжо не хапае, і кампанія наймае DevOps-каманду. Гэта цэнтр кампетэнцый, які арганізуе намаганні разрозненых інжынераў, дазваляе засяродзіць іх у адным напрамку.
- Насамрэч, DevOps-інжынер і DevOps-каманды – гэта антыпатэрны DevOps-трансфармацыі. Бо DevOps – гэта пра практыкі і культуру, акрамя таго, існуюць імплементацыі DevOps у тэхналагічных кампаніях (SRE, Production Engineering).
Што ж рабіць? Найняць часовую DevOps-каманду, якая дапаможа рэалізаваць DevOps-трансфармацыю, будзе несці практыкі, вырошчваць культуру распрацоўкі і тэхналагічную культуру.
Калі бізнэс уступае ў гульню і ўкладваецца ў DevOps, магчымыя некалькі варыянтаў развіцця падзей: усё разваліцца на ўзлёце; застанецца як SRE/Production Engineering або Embedded Ops; пяройдзе да BizOps, калі працэсы абапіраюцца на бізнес-метрыкі.
Уладзімір Страценка распавёў нам пра тое, наколькі «крывавы» DevOps у энтэрпрайзе на самой справе і як укараняюць практыкі ўнутры буйнога рытэйла. Глядзіце інтэрв'ю:
4. Сяргей Пузыроў, Facebook: "Production Engineer клапоціцца аб сэрвісе ў цэлым: каб і карыстальнікам, і распрацоўшчыкам было добра"
Facebook - велізарная кампанія, з вялікай колькасцю кампанентаў, сервераў, людзей, дата-цэнтраў. Нягледзячы на вялізныя памеры, ён вельмі хуткі - распрацоўшчыкі могуць выкочваць сэрвісы мноства раз у дзень. Таксама Facebook хутка расце, і справа не толькі ў росце колькасці карыстальнікаў і сервераў, павялічваецца таксама колькасць распрацоўшчыкаў, што ўскладняе працэсы.
Сяргей распавёў, чым займаецца Production Engineer у Facebook:
- Production Engineer шмат кадзіць, у яго павінны быць сістэмныя веды: аперацыйных сістэм, файлавых сістэм, баз дадзеных, сетак і таго падобнага. Павінен быць досвед працы з размеркаванымі сістэмамі і Reliability Engineering, гэта значыць у падтрымцы надзейнасці працы прадукта. Ён павінен быць on-call, гэта значыць даступным для выкліку ў любы час.
- Production Engineer адрозніваецца ад Software Engineer прасунутымі скіламі ў эксплуатацыі, але, у сутнасці, з'яўляецца падвідам Software Engineer. Software Engineer больш кадзяць, у іх могуць быць дадатковыя скілы, звязаныя, напрыклад, з апрацоўкай дадзеных. У Facebook такія адмыслоўцы таксама павінны быць on-call, што для шматлікіх становіцца непрыемнай неспадзеўкай.
- Піраміда запатрабаванняў Production Engineer у кампаніі пачынаецца з маніторынгу сервераў і іх жыццёвага цыклу, гэта значыць атрыманне новага жалеза, яго налада, увод у эксплуатацыю. Наступны ўзровень - тое ж самае на ўзроўні сэрвісаў: маніторынг сэрвісаў і іх жыццёвага цыклу. Затым ідзе бясшвоўнае маштабаванне і пашыраны маніторынг. Да аўтаскейлінгу пераходзяць пасля таго, як жыццёвы цыкл сэрвісу аўтаматызаваны. І ў канцы трэба займацца цюнінгам, каб маштабаванне было эфектыўным, кампанія эканоміла грошы і рэсурсы.
5. Міхаіл Чынкоў, AMBOSS: "Па шляху DevOps не можа ісці адно падраздзяленне, па ім павінна ісці ўся кампанія"
Міхаіл лічыць, што DevOps – гэта бесперапыннае развіццё. Нельга ўкараніць нейкія інструменты і на гэтым спыніцца. Якія праблемы перашкаджаюць кампаніям стаць DevOps і як укараняць практыкі?
Розніца ў разуменні DevOps. Кананічны дэвопс, як яго бачаць евангелісты, трымаецца на 5 слупах:
- культура - фокус на людзях і калабарацыя;
- аўтаматызацыя - дэлегаванне руціны ў workflow;
- lean - акцэнт на дастаўцы каштоўнасці карыстачу;
- sharing - бесперапынны абмен ведамі;
- метрыкі і атрыманне зваротнай сувязі з іх дапамогай.
У кампаніях звычайна робяць акцэнт толькі на аўтаматызацыі і дастаўцы каштоўнасці карыстачу. А вось культура, абмен ведамі і метрыкі DevOps, па якіх можна адсочваць развіццё, ідуць на другі план.
Праблемы стандартызацыі DevOps. Прадуктовыя мэты розныя ва ўсіх кампаній, іх нельга стандартаваць. Стан DevOps у кампаніі залежыць ад самой кампаніі, але многія гэтага не разумеюць і лічаць, што дастаткова наняць DevOps-інжынера.
Чаму мы яшчэ не DevOps? Ёсць дзве ключавыя праблемы. У Enterprise – павольнае развіццё арганізацыі, складанасці са зменай вектара ў галовах тысяч супрацоўнікаў. У стартапах - адсутнасць крыніц ведаў, праблема з вылучэннем рэсурсаў на трансфармацыю.
Стадыі развіцця DevOps у кампаніі:
- першая - інфраструктура ў воблаку, але ніхто не ведае, як яна працуе, акрамя аднаго-двух адмінаў;
- другая - інфраструктура празрыстая і зразумелая ўсім інжынерам, але працэсы не пастаўлены на паток;
- трэцяя - інжынеры самастойна запускаюць і чыняць live-сэрвісы;
- чацвёртая - інжынеры па жаданні кантрыб'юць у core інфраструктуры, празрысты код у воблаку, дэплой па кнопцы.
Ідэальная схема - усе маюць аднолькавы доступ да інфраструктуры, усе інжынеры атрымліваюць доступ да проду і разумеюць, што яны робяць.
Зачыніўшы ўсе культурныя і тэхнічныя гештальты, DevOps-трансфармацыя кампаніі будзе ўлічваць зваротную сувязь ад бізнес-метрык і метрык платформы.
6. DevOps-энтузіясты Расбанка: "1000 дзён, каб укараніць DevOps у крывавым энтэрпрайзе"
Юры Буліч, Дзіна Мальцава, Яўген Панкоў з Расбанка распавялі, як яны прыйшлі да DevOps за тры гады. Было дзве мэты: вырашыць канкрэтныя праблемы ў канкрэтных камандах і ўкараніць цэнтралізаваныя інструменты.
Вось якіх вынікаў дасягнулі:
Вынікі для прадуктовых каманд: у 30 разоў хутчэй зборка, у 6 разоў хутчэй ўстаноўка, да 30% эканоміі на поўным цыкле. Атрымалі магчымасць па кнопцы каціць у прадукты
Вынікі для платформенных каманд: у 10 разоў хутчэй зборка і ўстаноўка, на 87% павялічылася колькасць установак, 46% - пакрыццё аўтатэстамі. Перастала быць вузкім месцам інтэграцыйная каманда
Такім чынам, як укараніць DevOps-практыкі ў крывавым энтэрпрайзе?
Спачатку ўкараніць пілотны праект: выбраць каманды, вырашыць, як рэалізаваць архітэктуру і абраць прылады. Выбіралі прылады з адчыненай ліцэнзіяй, з наяўнасцю ўсталёўкі ў слоіку і экспертызы працы з імі. У Расбанку адначасова з DevOps-платформай разгортвалі прыватнае воблака, і гэта дапамагло на старце. У воблаку можна было за 15 хвілін атрымаць патрэбныя рэсурсы па кнопцы, раней такі працэс мог займаць тыдзень.
У банках і іншым энтэрпрайзе трэба загадзя прапрацаваць абмежаванні з камандай інфармацыйнай бяспекі і знайсці рашэнне, якое дазволіць укараніць змены.
Пасля пілота ўдалае рашэнне трэба маштабаваць.
- Важна максімальна распрастаць канвеер, выключыўшы з яго лішнія звёны, вылучыць пастаўшчыкоў каштоўнасці, а астатнія кампаненты прыбраць. Прамежкавыя звёны - гэта антыпатэрны. Напрыклад, у Расбанку ў шэрагу каманд не склалася ўнутраная распрацоўка, засталася толькі знешняя. Гэта прывяло да з'яўлення выдзеленай DevOps-каманды, якая забяспечвала перадачу кода ад вонкавых распрацоўнікаў да ўнутраных. Праблему вырашылі, убудаваўшы знешнюю распрацоўку ў CI/СD, каб яны не проста перадавалі код ад сябе ў банк, але і адказвалі за яго поспех.
- У мадэль сталасці ўключылі элементы DevOps-практык, пералічылі прылады, улічылі асаблівасці працы з вонкавымі пастаўшчыкамі – у далейшым гэта дапамагло хутка нарэзаць бэклог задач пры ўкараненні ў новых камандах.
- Патрэбен Governance у выглядзе мяккага кантролю і рэкамендацый. Добра працуе DevOps Handbook - гэта набор арганізацыйных і інструментальных характарыстык, якія дапамагаюць камандам правільна выкарыстоўваць платформу.
- Варта адразу надаваць увагу культуры, тады шмат якія змены пройдуць хутчэй і прасцей. Расціце ўнутранае кам'юніці, праводзіце мітапы, тэхнічныя воркшопы, трэнінгі, fun-актыўнасці. Гэта дае плён: людзі дзеляцца практыкамі, глядзяць, хто і што зрабіў, ведаюць, куды звярнуцца, ёсць хайп і здаровая канкурэнцыя ўнутры кампаніі.
- Няма сэнсу працаваць з тымі, хто не залучаны ў працэс, з камандамі, якія не даспелі, лепш укладвацца ў зацікаўленыя каманды і лаяльных людзей.
- Абранае рашэнне павінна быць зручным для тых інжынераў, якія ім карыстаюцца.
- Вонкавая распрацоўка - гэта не блокер, там таксама можна ўкараняць практыкі, галоўнае, каб было жаданне ў самой каманды.
Яшчэ крыху карысці
Спіс кніг, якія варта пачытаць тым, хто ў DevOps, ад Аляксандра Чысцякова, vdsina.ru:
- Ірына Якуценка «Воля і самакантроль».
- Daniel Kahneman "Thinking, Fast and Slow".
- Barbara Oakley "A Mind for Numbers".
- Максім Дарафееў «Джэдайскія тэхнікі».
- Viktor Frankl "Man's Search for Meaning".
Сачыце за абнаўленнямі
Мы таксама любім DevOps. Сачыце за анонсамі серый і @Kubernetes, а таксама іншых мерапрыемстваў Mail.ru Cloud Solutions, у нашым канале Telegram:
Крыніца: habr.com
