Прывітанне, Хабр! Раней я скардзіўся на жыццё ў парадыгме Infrastructure as code і нічога не прапанаваў для рашэння якая склалася сітуацыі. Сёння я вярнуўся, каб расказаць, якія падыходы і практыкі дапамогуць вырвацца з бездані роспачы і выруліць сітуацыю ў правільнае рэчышча.
У папярэднім артыкуле я дзяліўся сваім уражаннем ад гэтай сферы, спрабаваў разважаць аб бягучай сітуацыі ў гэтай галіне і нават выказаў меркаванне, што стандартныя, вядомыя ўсім распрацоўшчыкам практыкі, могуць дапамагчы. Магло падацца, што там было шмат скаргаў на жыццё, але не было прапановаў па выхадзе з сітуацыі.
Хто мы, дзе мы і якія ў нас праблемы
Цяпер мы знаходзімся ў Sre Onboarding Team, якая складаецца з шасці праграмістаў і трох інжынераў інфраструктуры. Усе мы спрабуем пісаць Infrastructure as code (IaC). Які робіцца мы гэта, таму што ў прынцыпе ўмеем пісаць код і ў анамнезе з'яўляемся распрацоўнікамі ўзроўня «вышэй сярэдняга».
- У нас ёсць набор плюсаў: пэўны бэкграўнд, веданне практык, уменне пісаць код, жаданне вучыцца новаму.
- І ёсць частка, якая правісае, яна ж мінус: недахоп ведаў па матчы інфраструктуры.
Стэк тэхналогій, якія мы выкарыстоўваем у нашым IaC.
- Terraform для стварэння рэсурсаў.
- Packer для зборкі іміджаў. Гэта Windows, CentOS 7 выявы.
- Jsonnet, каб рабіць магутную зборку ў drone.io, а таксама для генерацыі packer json і нашых модуляў тэраформы.
- Блакітны.
- Ansible пры гатаванні вобразаў.
- Python для дапаможных сэрвісаў, а таксама скрыптоў правіжэнінгу.
- І ўсё гэта ў VSCode з плягінамі, размаляванымі паміж удзельнікамі каманды.
Выснова з маёй быў такі: я спрабаваў усяліць (у першую чаргу ў сябе) аптымізм, хацеў сказаць, што мы будзем спрабаваць вядомыя нам падыходы і практыкі для таго, каб змагацца з цяжкасцямі і складанасцямі, якія ёсць у гэтай сферы.
Цяпер мы змагаемся з такімі праблемамі IaC:
- Недасканаласць інструментаў, сродкаў да распрацоўкі кода.
- Павольнае разгортванне. Інфраструктура - гэта частка рэальнага свету, а ён можа быць няхуткім.
- Недахоп падыходаў і практык.
- Мы новенькія і шмат чаго не ведаем.
Экстрэмальнае праграмаванне (XP) спяшаецца на дапамогу
Усім распрацоўнікам добра знаёма экстрэмальнае праграмаванне (XP) і тыя практыкі, якія за ім стаяць. Многія з нас працавалі па такім падыходзе, і ён быў удалы. Дык чаму б не скарыстацца прынцыпамі і практыкамі, закладзенымі там, каб перамагчы цяжкасці інфраструктуры? Мы вырашылі прымяніць гэты падыход і паглядзець, што з гэтага выйдзе.
Праверка дастасавальнасці падыходу ХР да вашай сферыПрыводжу апісанне асяроддзя, для якога добра падыходзіць XP, і як гэта суадносіцца з намі:
1. Dynamically changing software requirements. Нам было зразумела, якая канчатковая мэта. Але ў дэталях можна вар'іраваць. Мы самі вырашаем, куды нам трэба выруліць, таму патрабаванні перыядычна мяняюцца (у асноўным намі ж самімі). Калі браць каманду SRE, якая сама робіць аўтаматызацыю, і сама ж абмяжоўвае патрабаванні і scope прац, то гэты пункт кладзецца добра.
2. Risks caused by fixed time projects using new technology. У нас могуць узнікнуць рызыкі пры выкарыстанні нейкіх невядомых нам рэчаў. І гэта на 100% наш выпадак. Увесь наш праект - гэта выкарыстанне тэхналогій, з якімі мы не былі да канца знаёмыя. Наогул, гэта сталая праблема, т.я. у сферы інфраструктуры ўвесь час з'яўляецца мноства новых тэхналогій.
3,4. Малы, co-located пашыраны развіццё тэхніка. Тэхналогія вы можаце выкарыстоўваць для аўтаматных сістэм і функцыянальных вынікаў. Гэтыя два пункты не зусім нам падыходзяць. Па-першае, мы не калацыраваная каманда, па-другое, нас дзевяць чалавек, што можа лічыцца вялікай камандай. Хоць, па шэрагу азначэнняў "вялікай" каманды, шмат - гэта 14 + чалавек.
Разгледзім некаторыя практыкі з XP і тое, як яны ўплываюць на хуткасць і якасць зваротнай сувязі.
Прынцып цыкла зваротнай сувязі ў XP
У маім разуменні зваротная сувязь - гэта адказ на пытанне, ці правільна я раблю, ці туды мы ідзем? У ХР на гэты конт ёсць чароўная схемка: цыкл зваротнай сувязі па часе. Цікавасць заключаецца ў тым, што чым ніжэй мы знаходзімся, тым хутчэй мы маем магчымасць атрымаць АС, каб адказаць на неабходныя пытанні.
Гэта даволі цікавая тэма для абмеркавання, што ў нас у IT індустрыі можна хутка атрымаць АС. Уявіце, як балюча складана рабіць які-небудзь праект паўгода і толькі потым даведацца, што ў самым пачатку была закладзена памылка. Такое бывае і ў праектаванні, і ў любой пабудове складаных сістэм.
У нашым выпадку IaC нам дапамагае зваротная сувязь. Адразу ўношу невялікую карэкціроўку ў схему вышэй: рэліз-план маем не месячны цыкл, а адбываецца некалькі разоў на дзень. Да гэтага цыклу АС прывязаны некаторыя практыкі, якія мы разгледзім падрабязней.
Важна: зваротная сувязь можа стаць вырашэннем для ўсіх заяўленых вышэй праблем. У сукупнасці з практыкамі XP, яна можа выцягнуць з бездані роспачы.
Як выцягнуць сябе з бездані роспачы: тры практыкі
тэсты
Тэсты згадваюцца двойчы ў цыкле зваротнай сувязі XP. Гэта ня проста так. Яны вельмі важныя для ўсёй тэхнікі экстрэмальнага праграмавання.
Мяркуецца, што ты маеш Unit і Acceptance tests. Адны даюць табе фідбэк за колькі хвілін, іншыя за колькі дзён, таму яны пішуцца даўжэй, а праганяюцца радзей.
Ёсць класічная піраміда тэсціравання, якая паказвае, што нейкіх тэстаў павінна быць больш.
Як гэта схема дастасавальная да нас у праекце IaC? Насамрэч… ніяк.
- Unit-тэстаў, нягледзячы на тое, што іх павінна быць вельмі шмат, не можа быць вельмі шмат. Альбо яны вельмі ўскосна нешта тэсціруюць. Фактычна можна сказаць, што мы іх не пішам увогуле. Але вось некалькі ўжыванняў для такіх тэстаў, якія ў нас усё ж атрымалася зрабіць:
- Тэставанне кода на jsonnet. Гэта, напрыклад, наш пайплайн зборкі ў drone, які дастаткова складзены. Код на jsonnet добра пакрываецца тэстамі.
Мы выкарыстоўваем гэты . - Тэсты на скрыпты, якія выконваюцца пры старце рэсурса. Скрыпты на Python, а значыць, і тэсты на іх можна пісаць.
- Тэставанне кода на jsonnet. Гэта, напрыклад, наш пайплайн зборкі ў drone, які дастаткова складзены. Код на jsonnet добра пакрываецца тэстамі.
- Патэнцыйна магчымая праверка канфігурацыі ў тэстах, але мы не які робіцца так. Яшчэ ёсць магчымасць наладкі праверкі правіл канфігуравання рэсурсаў праз . Аднак, проста для тэраформа там занадта базавыя праверкі, але шмат праверачных сцэнарыяў напісана для AWS. А мы на Azure, таму гэта зноў не падыходзіць.
- Кампанентныя інтэграцыйныя тэсты: тут залежыць ад таго, як ты іх класіфікуеш і куды раскладваеш. Але яны ў прынцыпе працуюць.
Вось так выглядаюць інтэграцыйныя тэсты.
Гэта прыклад пры зборцы выяў у Drone CI. Каб да іх дайсці, трэба 30 хвілін чакаць, пакуль збярэцца імідж Packer, потым яшчэ хвілін 15 чакаць, пакуль яны пройдуць. Але яны ёсць!Алгарытм праверкі выяў
- Спачатку Packer павінен прыгатаваць выяву цалкам.
- Побач з тэстам ёсць тэраформ з лакальным стейтам, якім мы гэтую выяву разгортваем.
- Пры разгортванні выкарыстоўваецца невялікі модуль, які ляжыць побач, каб прасцей было працаваць з выявай.
- Калі з выявы разгорнута VM, можна пачаць праверкі. У асноўным праверкі ажыццяўляюцца на машыне. Правяраецца, як адпрацавалі скрыпты пры старце, як працуюць дэманы. Для гэтага праз ssh ці winrm мы заходзім на толькі што паднятую машыну і правяраем стан канфігурацыі ці падняліся ці сэрвісы.
- Падобная сітуацыя з інтэграцыйнымі тэстамі і ў модулях для тэраформы. Вось кароткая табліца, якая тлумачыць асаблівасці такіх тэстаў.
Зваротная сувязь на пайплайне ў раёне 40 хвілін. Усё адбываецца вельмі доўга. Можна выкарыстоўваць для рэгрэсу, але для новай распрацоўкі ўвогуле нерэальна. Калі вельмі-вельмі да гэтага падрыхтавацца, падрыхтаваць running, скрыпты, то можна скараціць да 10 хвілін. Але гэта ўсё роўна не Unit-тэсты, якія за 5 секунд 100 штук.
Адсутнасць Unit-тэстаў пры зборцы выяў або модуляў тэраформа падштурхоўвае перакладаць працу на асобныя сэрвісы, якія проста можна тузануць па REST, ці на Python-скрыпты.
Напрыклад, нам трэба было зрабіць так, каб пры старце віртуальнай машыны яна рэгістравала сябе ў сэрвісе. , а пры знішчэнні віртуалкі выдаляла сябе.
Так як ScaleFT у нас як сэрвіс, мы вымушаны працаваць з ім праз API. Там была напісана абгортка, якую можна тузануць і сказаць: «Зайдзі і выдалі тое і тое». Яна захоўвае ўсе неабходныя наладкі і доступы.
На гэта ўжо можам пісаць нармальныя тэсты, бо гэта ніяк не адрозніваецца ад звычайнага софту: макаецца нейкая апіха, ты торгаеш, і глядзім, што адбываецца.
Вынікі па тэстах: Unit-тэставанне, якое павінна даваць АС за хвіліну, не дае яго. А больш высокія па пірамідзе віды тэсціравання даюць эфект, але закрываюць толькі частку праблем.
Парнае праграмаванне
Тэсты - гэта, вядома, добра. Іх можна пісаць шмат, яны могуць быць розных відаў. Яны будуць працаваць на сваіх узроўнях і даваць нам зваротную сувязь. Але праблема з дрэннымі Unit-тэстамі, якія даюць самую хуткую АС, застаецца. Пры гэтым працягвае жадацца хуткай АС, з ёй лёгка і прыемна працаваць. Не гаворачы ўжо аб якасці атрыманага рашэння. На шчасце, ёсць тэхнікі, якія дазваляюць даць яшчэ хутчэйшы feedback, чым модульныя тэсты. Гэта парнае праграмаванне.
Пры напісанні кода хочацца атрымаць зваротную сувязь аб яго якасці як мага хутчэй. Так, можна напісаць усё ў фіча-галінцы (каб не паламаць нічога нікому), зрабіць pull request у гітхабе, прызначыць на кагосьці, чыё меркаванне мае вагу, і чакаць адказу.
Але чакаць можна доўга. Людзі ўсё занятыя, а адказ, нават калі і будзе, можа быць не самым высокім па якасці. Выкажам здагадку, што адказ прыйшоў адразу, рэўювер маментальна зразумеў усю задуму, але адказ усё роўна прыходзіць са спазненнем, постфактум. А хочацца раней. Вось парнае праграмаванне і нацэлена на гэта - каб адразу, у момант напісання.
Далей прыводжу стылі парнага праграмавання і іх дастасавальнасць у працы над IaC:
1. Classic, Доследны+вопытны, змена па таймеры. Дзве ролі - driver and navigator. Два чалавекі. Яны працуюць над адным кодам і мяняюцца ролямі праз пэўны загадзя пазначаны прамежак часу.
Разгледзім спалучальнасць нашых праблем са стылем:
- Праблема: недасканаласць інструментаў, сродкаў да распрацоўкі кода.
Негатыўны ўплыў: даўжэй распрацоўваць, мы запавольваемся, збіваецца тэмп/рытм працы.
Як змагаемся: ужывальны іншы тулінг, агульны IDE і яшчэ вучым шорткаты. - Праблема: павольнае разгортванне.
Негатыўны ўплыў: павялічвае час на стварэнне які працуе кавалка кода. Нудзімся падчас чакання, рукі цягнуцца заняцца чымсьці іншым, пакуль чакаеш.
Як змагаемся: не перамаглі. - Праблема: недахоп падыходаў і практык.
Негатыўны ўплыў: няма ведання, як рабіць добра, а як дрэнна. Падаўжае атрыманне зваротнай сувязі.
Як змагаемся: узаемаабмен меркаванняў і практык у парнай рабоце амаль вырашае праблему.
Галоўная праблема прымянення гэтага стылю ў IaC у няроўным тэмпе працы. У традыцыйнай распрацоўцы ПЗ у цябе вельмі раўнамернае рух. Ты можаш выдаткаваць пяць хвілін і напісаць N. Выдаткаваць 10 хвілін і напісаць 2N, 15 хвілін - 3N. Тутака ж можна выдаткаваць пяць хвілін і напісаць N, а потым выдаткаваць яшчэ 30 хвілін і напісаць дзясятую частку ад N. Тут ты нічога не ведаеш, у цябе затык, тупняк. Разбіральніцтва займае час і адцягвае ад непасрэдна праграмавання.
Выснова: у чыстым выглядзе нам не падыходзіць.
2. Ping-pong. Гэта падыход мяркуе, што адзін удзельнік піша тэст, а іншы робіць для яго рэалізацыю. З улікам таго, што з Unit-тэстамі ўсё складана, і даводзіцца пісаць доўгі па часе праграмавання інтэграцыйны тэст, уся лёгкасць ping-pong'а сыходзіць.
Магу сказаць, што мы спрабавалі падзел абавязкаў па праектаванні сцэнара тэста і рэалізацыі кода пад яго. Адзін удзельнік прыдумляў сцэнар, у гэтай частцы працы ён быў адказным, за ім было апошняе слова. А іншы быў адказны за рэалізацыю. Гэта атрымлівалася добра. Якасць сцэнара пры такім падыходзе павялічваецца.
Выснова: нажаль, тэмп працы не дазваляе выкарыстоўваць ping-pong, як практыку парнага праграмавання ў IaC.
3. Strong Style. . Ідэя ў тым, што адзін удзельнік становіцца дырэктыўным навігатарам, а другі бярэ ролю выконваючага драйвера. Пры гэтым права рашэнняў выключна за навігатарам. Драйвер толькі друкуе і словам можа паўплываць на тое, што адбываецца. Ролі не мяняюцца доўгі час.
Добра падыходзіць для навучання, але патрабуе моцных soft skills. На гэтым мы і запнуліся. Тэхніка ішла складана. І справа тут нават не ў інфраструктуры.
Выснова: патэнцыйна можа прымяняцца, мы не пакідаем спробы.
4. Mobbing, swarming і ўсе вядомыя, але не пералічаныя тут стылі не разглядаем, т.я. не спрабавалі і сказаць пра гэта ў кантэксце нашай працы не атрымаецца.
Агульныя вынікі па выкарыстанні pair programming:
- Маем нераўнамерны тэмп працы, які збівае.
- Мы ўперліся ў недастаткова добрыя soft skills. А прадметная вобласць не садзейнічае пераадоленню гэтых нашых недахопаў.
- Доўгія тэсты, праблемы з інструментамі робяць парную распрацоўку вязкай.
5. Нягледзячы на гэта, былі і поспехі. Мы прыдумалі ўласны метад «Зыходжанне - разыходжанне». Каротка апішу, як ён працуе.
У нас ёсць пастаянныя партнёры на некалькі дзён (менш за тыдзень). Мы робім адну задачу разам. Нейкі час мы сядзім разам: адзін піша, другі сядзіць і назірае, як сапарт цім. Потым мы разыходзімся на нейкі час, кожны робіць нейкія незалежныя рэчы, потым зноў сыходзімся, сінхранізуемся вельмі хутка, робім нешта разам і зноў разыходзімся.
Планаванне і зносіны
Апошні блок практык, праз якія вырашаюцца праблемы АС - гэта арганізацыя работ з самімі задачамі. Сюды ж уваходзіць і абмен досведам, які знаходзіцца па-за парнай працай. Разгледзім тры практыкі:
1. Задачы праз дрэва мэт. Агульнае вядзенне праекта мы арганізавалі праз дрэва, якое бясконца адыходзіць у будучыню. Тэхнічна вядзенне робіцца ў Miro. Ёсць адна задача - яна прамежкавая мэта. Ад яе ідуць альбо драбнейшыя мэты, альбо групы задач. Ад іх ужо самі задачы. Усе задачы ствараюцца і вядуцца на гэтай дошцы.
Гэтая схема таксама дае зваротную сувязь, якая адбываецца адзін раз у дзень, калі мы сінхранізуемся на мітынгах. Наяўнасць перад усімі агульнага плана, пры гэтым структураванага і цалкам адкрытага, дазваляе кожнаму быць у курсе таго, што адбываецца, і як далёка мы прасунуліся па прагрэсе.
Перавагі візуальнага бачання задач:
- Прычыннасць. Кожная задача вядзе да нейкай глабальнай мэты. Задачы групуюцца па драбнейшых мэтах. Дамен інфраструктуры сам па сабе даволі тэхнічны. Не заўсёды адразу зразумела, які канкрэтна ўплыў на бізнэс аказвае, напрыклад, напісанне ранбука па міграцыі на іншы nginx. Наяўнасць побач мэтавай карткі робіць гэта больш зразумелай.
Прычыннасць - важная ўласцівасць задач. Яно непасрэдна адказвае на пытанне: "А ці то я раблю?" - Паралельнасць. Нас дзевяць чалавек, і накідвацца ўсім на адну задачу немагчыма проста фізічна. Задач з адной вобласці таксама не заўсёды можа хапіць. Мы змушана раўналежым працу паміж дробнымі працоўнымі групамі. Пры гэтым гурты некаторы час сядзяць на сваёй задачы, іх могуць узмацніць кімсьці яшчэ. Ад гэтай працоўнай групы часам адвальваюцца людзі. Нехта сыходзіць у адпачынак, нехта робіць даклад для канферэнцыі DevOps conf, нехта піша артыкул на Хабр. Ведаць, якія мэты і задачы могуць рабіцца раўналежна становіцца вельмі важна.
2. Зменныя вядучыя ранішніх мітынгаў. На стэндапах атрымалася такая праблема - шмат задач людзі робяць паралельна. Часам задачы слаба злучаны і няма разумення, хто што робіць. А меркаванне яшчэ аднаго члена каманды вельмі важнае. Гэта дадатковая інфармацыя, якая здольна змяніць ход рашэння задачы. Вядома, звычайна з табой у пары нехта ёсць, але кансультацыя і падказкі заўсёды не лішнія.
Каб гэтую сітуацыю палепшыць, мы прымянілі тэхніку «Змена вядучага стэндпапа». Цяпер яны раціруюцца па пэўным спісе, і гэта мае свой эфект. Калі да цябе даходзіць чарга, ты змушаны пагрузіцца і зразумець што адбываецца, каб добра правесці скрам-мітынг.
3. Унутранае дэма. Дапамога ў рашэнні задачы ад парнага праграмавання, візуалізацыя на дрэве задач і дапамога на скраму-мітынгах па раніцах - добра, але не ідэальна. У пары вы абмежаваны толькі сваімі ведамі. Дрэва задач дапамагае глабальна зразумець, хто і што робіць. А вядучы і калегі на ранішняй сустрэчы не пагрузяцца глыбока ў твае праблемы. Ужо сапраўды могуць нешта і прапусціць.
Рашэнне было знойдзена ў дэманстраванні зробленых работ адзін аднаму і наступным абмеркаванні іх. Мы збіраемся раз на тыдзень на гадзіну і паказваем дэталі рашэнняў па задачах, якія рабілі за апошні тыдзень.
У працэсе дэманстрацыі трэба раскрыць дэталі задачы і абавязкова прадэманстраваць яе работу.
Даклад можна весці па чэк-лісце.1. Увядзіце ў кантэкст. Адкуль узялася задача, навошта гэта ўвогуле было патрэбна?
2. Як вырашалася задача да гэтага? Напрыклад, патрабавалася масавае мышакліканне, ці ж наогул было немагчыма нешта зрабіць.
3. Як мы паляпшаем гэта. Напрыклад: "Глядзіце, зараз ёсць скрыптосік, вось рыдмі".
4. Пакажыце, як гэта працуе. Пажадана прама ажыццявіць які-небудзь сцэнар карыстача. Жадаю X, раблю Y, бачу Й (або Z). Напрыклад, дэплою NGINX, курлю url, атрымліваю 200 OK. Калі дзеянне доўгае, падрыхтуйце загадзя, каб потым паказаць. Пажадана за гадзіну да дэма ўжо не разломваць асоба, калі далікатнае.
5. Растлумачце, наколькі ўдала вырашана праблема, якія цяжкасці засталіся, што не дароблена, якія ўдасканаленні магчымыя ў далейшым. Напрыклад, зараз cli, потым будзе поўная аўтаматыка ў CI.
Пажадана кожнаму спікеру ўкласціся ў 5-10 хвілін. Калі ваш выступ загадзя важны і зойме больш часу, загадзя ўзгадніце гэта ў канале sre-takeover.
Пасля вочнай часткі абавязкова ідзе абмеркаванне ў трэдзе. Вось тут і з'яўляецца тая неабходная нам зваротная сувязь па сваіх задачах.
Па выніку праводзіцца апытанне для выяўлення карыснасці таго, што адбываецца. Гэта ўжо адваротная сувязь па сутнасці выступлення і важнасці задачы.
Доўгія высновы і што далей
Можа здацца, што тон артыкула некалькі песімістычны. Гэта не так. Два нізавыя ўзроўні атрымання зваротнай сувязі, а менавіта тэсты і парнае праграмаванне, працуюць. Не так дасканала, як у традыцыйнай распрацоўцы, але пазітыўны эфект ад гэтага ёсць.
Тэсты, у бягучым іх выглядзе, даюць толькі частковае пакрыццё кода. Шмат функцый канфігурацыі аказваюцца не пратэставанымі. Уплыў іх на непасрэдную працу пры напісанні кода нізкае. Аднак эфект ад інтэграцыйных тэстаў ёсць, і менавіта яны дазваляюць бязбоязна праводзіць рэфактарынгі. Гэта вялікае дасягненне. Таксама з пераносам фокусу на распрацоўку ў высокаўзроўневых мовах (у нас python, go) праблема сыходзіць. А на «клей» шмат праверак і не трэба, дастаткова агульнай інтэграцыйнай.
Праца ў пары больш залежыць ад канкрэтных людзей. Ёсць фактар задачы і нашыя soft skills. З кімсьці атрымліваецца вельмі добра, з кім горш. Карысць ад гэтага сапраўды ёсць. Ясна, што нават пры недастатковым выкананні правіл парнай працы, сам факт сумеснага выканання задач дадатна ўплывае на якасць выніку. Асабіста мне ў пары працуецца прасцей і прыемней.
Больш высокаўзроўневыя спосабы ўплыў на АС – планаванне і праца з задачамі сапраўды даюць эфекты: якасны абмен ведаў і паляпшэнне якасці распрацоўкі.
Кароткія высновы адным радком
- Практыкі ХР працуюць у IaC, але з меншым ККД.
- Узмацняйце тое, што працуе.
- Прыдумляйце свае кампенсаторныя механізмы і практыкі.
Крыніца: habr.com