Инфраструктура као код: како превазићи проблеме користећи КСП

Здраво, Хабр! Претходно сам се жалио на живот у Инфраструктури као парадигму кода и нисам нудио ништа за решавање тренутне ситуације. Данас се враћам да вам кажем који приступи и праксе ће вам помоћи да побегнете из понора очаја и усмерите ситуацију у правом смеру.

У претходном чланку „Инфраструктура као шифра: прво познанство“ Изнео сам своје утиске о овој области, покушао да размислим о тренутној ситуацији у овој области, па чак и сугерисао да би стандардне праксе познате свим програмерима могле да помогну. Можда се чини да је било много притужби на живот, али није било предлога за излаз из тренутне ситуације.

Ко смо, где смо и какве проблеме имамо

Тренутно смо у Сре онбоардинг тиму, који се састоји од шест програмера и три инфраструктурна инжењера. Сви покушавамо да напишемо инфраструктуру као код (ИаЦ). Ово радимо зато што у основи знамо да пишемо код и имамо историју да смо били „надпросечни“ програмери.

• Имамо низ предности: одређену позадину, познавање пракси, способност писања кода, жељу за учењем нових ствари.
• А ту је и један опуштени део, што је такође минус: недостатак знања о инфраструктурном хардверу.

Технолошки скуп који користимо у нашем ИаЦ-у.

• Терраформ за креирање ресурса.
• Пакер за склапање слика. Ово су Виндовс, ЦентОС 7 слике.
• Јсоннет да направи моћну изградњу дроне.ио, као и да генерише пацкер јсон и наше терраформ модуле.
• Азуре.
• Ансибле приликом припреме слика.
• Питхон за помоћне услуге и скрипте за обезбеђивање.
• И све то у ВСЦоде-у са додацима које деле чланови тима.

Закључак из мог последњи чланак била је оваква: Покушао сам да (пре свега себи) улијем оптимизам, хтео сам да кажем да ћемо испробати нама познате приступе и праксе како бисмо се изборили са тешкоћама и сложеностима које постоје у овој области.

Тренутно се боримо са следећим проблемима ИаЦ-а:

• Несавршеност алата и средстава за развој кода.
• Споро распоређивање. Инфраструктура је део стварног света и може бити спора.
• Недостатак приступа и праксе.
• Нови смо и не знамо много.

Екстремно програмирање (КСП) у помоћ

Сви програмери су упознати са екстремним програмирањем (КСП) и праксама које стоје иза тога. Многи од нас су радили са овим приступом и био је успешан. Па зашто онда не искористити принципе и праксе које су тамо постављене за превазилажење инфраструктурних изазова? Одлучили смо да узмемо овај приступ и видимо шта ће се десити.

Провера применљивости КСП приступа у вашој индустријиЕво описа окружења за које је КСП веома погодан и како се оно односи на нас:

1. Динамички променљиви софтверски захтеви. Било нам је јасно шта је крајњи циљ. Али детаљи се могу разликовати. Ми сами одлучујемо где треба да таксирамо, тако да се захтеви периодично мењају (углавном сами). Ако узмемо СРЕ тим, који сам ради аутоматизацију, а сам ограничава захтеве и обим посла, онда се ова тачка добро уклапа.

2. Ризици узроковани пројектима са фиксним временом који користе нову технологију. Можемо наићи на ризике када користимо неке нама непознате ствари. И ово је 100% наш случај. Цео наш пројекат је био коришћење технологија са којима нисмо били у потпуности упознати. Генерално, ово је стални проблем, јер... У инфраструктурном сектору се стално појављују многе нове технологије.

3,4. Мали проширени развојни тим који се налази заједно. Аутоматска технологија коју користите омогућава јединичне и функционалне тестове. Ове две тачке нам не одговарају баш. Прво, нисмо уиграна екипа, а друго, има нас деветоро, што се може сматрати великом екипом. Мада, према неким дефиницијама „великог“ тима, много је 14+ људи.

Погледајмо неке КСП праксе и како оне утичу на брзину и квалитет повратних информација.

КСП принцип повратне спреге

По мом схватању, повратна информација је одговор на питање, да ли радим праву ствар, идемо ли тамо? КСП има божанску шему за ово: временску повратну спрегу. Занимљиво је да што смо нижи, брже смо у могућности да натерамо ОС да одговори на неопходна питања.

Ово је прилично интересантна тема за дискусију, да је у нашој ИТ индустрији могуће брзо добити ОС. Замислите колико је болно радити пројекат шест месеци и тек онда сазнати да је грешка на самом почетку. Ово се дешава у пројектовању и у било којој конструкцији сложених система.

У нашем случају ИаЦ-а, повратне информације нам помажу. Одмах ћу направити мало прилагођавање горњег дијаграма: план издања нема месечни циклус, већ се јавља неколико пута дневно. Постоје неке праксе везане за овај циклус ОС-а које ћемо детаљније размотрити.

Важно: повратне информације могу бити решење за све горе наведене проблеме. У комбинацији са КСП праксама, може вас извући из понора очаја.

Како се извући из понора очаја: три праксе

Тестови

Тестови се помињу два пута у КСП повратној спрези. Није само тако. Они су изузетно важни за целокупну технику екстремног програмирања.

Претпоставља се да имате јединичне и тестове прихватања. Неки вам дају повратне информације за неколико минута, други за неколико дана, тако да им је потребно више времена за писање и ређе се прегледају.

Постоји класична пирамида тестирања, која показује да би требало да буде више тестова.

Како се овај оквир примењује на нас у ИаЦ пројекту? У ствари... никако.

• Јединичних тестова, упркос чињеници да би их требало бити пуно, не може бити превише. Или тестирају нешто врло индиректно. У ствари, можемо рећи да их уопште не пишемо. Али ево неколико апликација за такве тестове које смо могли да урадимо:
  1. Тестирање јсоннет кода. Ово је, на пример, наш цевовод за монтажу дронова, који је прилично компликован. Јсоннет код је добро покривен тестовима.
     Користимо ово Оквир за тестирање јединица за Јсоннет.
  2. Тестови за скрипте које се извршавају када се ресурс покрене. Скрипте су написане у Питхон-у, па се на њима могу писати тестови.
• Потенцијално је могуће проверити конфигурацију у тестовима, али ми то не радимо. Такође је могуће конфигурисати правила конфигурације провере ресурса преко тфлинт. Међутим, тамо су провере једноставно превише основне за терраформ, али многе тестне скрипте су написане за АВС. А ми смо на Азуре-у, тако да ово опет не важи.
• Тестови интеграције компоненти: зависи од тога како их класификујете и где их стављате. Али у основи раде.

  Овако изгледају тестови интеграције.

  
  
  Ово је пример када се праве слике у Дроне ЦИ. Да бисте дошли до њих, морате сачекати 30 минута да се формира Пацкер слика, а затим сачекати још 15 минута да прођу. Али они постоје!

  Алгоритам за верификацију слике

  1. Пакер прво мора у потпуности да припреми слику.
  2. Поред теста налази се терраформ са локалним стањем, који користимо за постављање ове слике.
  3. Приликом расклапања користи се мали модул који лежи у близини како би се олакшао рад са сликом.
  4. Када се ВМ примени са слике, провере могу да почну. У основи, провере се обављају аутомобилом. Проверава како су скрипте функционисале при покретању и како функционишу демони. Да бисмо то урадили, преко ссх-а или винрм-а се пријављујемо на новоподигнуту машину и проверавамо статус конфигурације или да ли су услуге покренуте.

• Слична је ситуација и са интеграцијским тестовима у модулима за терраформ. Ево кратке табеле која објашњава карактеристике таквих тестова.

  
  
  Повратне информације о цевоводу су око 40 минута. Све се дешава веома дуго. Може се користити за регресију, али за нови развој је генерално нереално. Ако сте веома, веома спремни за ово, припремите скрипте за покретање, онда можете то смањити на 10 минута. Али ово још увек нису јединични тестови, који раде 5 комада за 100 секунди.

Одсуство тестова јединица приликом склапања слика или терраформ модула подстиче пребацивање посла на засебне сервисе који се једноставно могу покренути преко РЕСТ-а или на Питхон скрипте.

На пример, морали смо да се уверимо да се виртуелна машина региструје у сервису када се покрене СцалеФТ, а када је виртуелна машина уништена, сама се избрисала.

Пошто имамо СцалеФТ као услугу, принуђени смо да радимо са њим преко АПИ-ја. Тамо је био написан омот који можете повући и рећи: „Уђи и избриши ово и то“. Чува сва потребна подешавања и приступе.

За ово већ можемо писати нормалне тестове, пошто се не разликује од обичног софтвера: нека врста апихе се исмеје, повучеш је и видиш шта ће се десити.

Резултати тестова: Јединично тестирање, које би требало да да ОС за минут, не даје. А врсте тестирања које се налазе више у пирамиди су ефикасне, али покривају само део проблема.

Програмирање у пару

Тестови су, наравно, добри. Можете их написати много, могу бити различитих врста. Они ће радити на свом нивоу и дати нам повратне информације. Али проблем са лошим тестовима јединица, који дају најбржи ОС, остаје. У исто време, и даље желим брз ОС са којим је лако и пријатно радити. О квалитету добијеног раствора да и не говоримо. На срећу, постоје технике које могу пружити још бржу повратну информацију од јединичних тестова. Ово је програмирање у пару.

Када пишете код, желите да добијете повратне информације о његовом квалитету што је пре могуће. Да, можете све да запишете у грану са карактеристикама (да не бисте ништа покварили никоме), направите захтев за повлачење у Гитхуб-у, доделите га неком чије мишљење има тежину и сачекајте одговор.

Али можете чекати дуго. Људи су сви заузети, а одговор, чак и ако га има, можда није најквалитетнији. Претпоставимо да је одговор стигао одмах, рецензент је одмах схватио целу идеју, али одговор ипак долази касно, после чињенице. Волео бих да је раније. То је оно чему је програмирање у пару намењено – одмах, у тренутку писања.

Испод су стилови програмирања у пару и њихова примењивост у раду на ИаЦ-у:

1. Цлассиц, Екпериенцед+Екпериенцед, схифт би тимер. Две улоге - возач и навигатор. Двоје људи. Они раде на истом коду и мењају улоге након одређеног унапред одређеног временског периода.

Хајде да размотримо компатибилност наших проблема са стилом:

• Проблем: несавршеност алата и алата за развој кода.
  Негативан утицај: потребно је више времена да се развије, успоравамо, темпо/ритам рада се губи.
  Како се боримо: користимо различите алате, заједнички ИДЕ и такође учимо пречице.
• Проблем: Спора имплементација.
  Негативан утицај: повећава време потребно за креирање радног дела кода. Досадно нам је док чекамо, руке нам се пружају да урадимо нешто друго док чекамо.
  Како се боримо: нисмо то превазишли.
• Проблем: недостатак приступа и праксе.
  Негативан утицај: нема знања како то учинити добро, а како лоше. Продужује пријем повратних информација.
  Како се боримо: међусобна размена мишљења и праксе у раду у пару готово решава проблем.

Главни проблем са коришћењем овог стила у ИаЦ-у је неуједначен темпо рада. У традиционалном развоју софтвера, имате веома уједначен покрет. Можете провести пет минута и написати Н. Проведите 10 минута и напишите 2Н, 15 минута - 3Н. Овде можете да проведете пет минута и напишете Н, а онда потрошите још 30 минута и напишете десети део Н. Овде не знате ништа, заглавили сте, глупи. Истрага одузима време и одвлачи пажњу од самог програмирања.

Закључак: у свом чистом облику није погодан за нас.

2. Пинг-понг. Овај приступ подразумева да једна особа пише тест, а друга ради имплементацију за њега. Узимајући у обзир чињеницу да је са јединичним тестовима све компликовано и да морате да напишете интеграцијски тест за који је потребно много времена за програмирање, сва лакоћа пинг-понга нестаје.

Могу рећи да смо покушали да одвојимо одговорности за дизајнирање тест скрипте и имплементацију кода за њу. Један учесник је смислио сценарио, у овом делу посла он је био одговоран, имао је последњу реч. А други је био одговоран за имплементацију. Добро је испало. Квалитет скрипте овим приступом се повећава.

Закључак: авај, темпо рада не дозвољава коришћење пинг-понга као праксе програмирања парова у ИаЦ-у.

3.Стронг Стиле. Тешка пракса. Идеја је да један учесник постане навигатор директиве, а други преузме улогу покретача извршења. У овом случају, право на доношење одлука има искључиво навигатор. Возач само штампа и може утицати на оно што се дешава речју. Улоге се дуго не мењају.

Добро за учење, али захтева јаке меке вештине. Овде смо посустали. Техника је била тешка. А не ради се чак ни о инфраструктури.

Закључак: потенцијално се може искористити, не одустајемо од покушаја.

4. Мобинг, ројење и сви познати али ненаведени стилови Ми то не сматрамо, јер Нисмо пробали и немогуће је о томе говорити у контексту нашег рада.

Општи резултати коришћења програмирања у пару:

• Имамо неуједначен темпо рада, што је збуњујуће.
• Налетели смо на недовољно добре меке вештине. А предметна област не помаже у превазилажењу ових наших недостатака.
• Дуги тестови и проблеми са алатима отежавају упарени развој.

5. Упркос томе, било је успеха. Осмислили смо сопствену методу „Конвергенција - Дивергенција“. Укратко ћу описати како то функционише.

Имамо сталне партнере на неколико дана (мање од недељу дана). Заједно радимо један задатак. Неко време седимо заједно: један пише, други седи и посматра тим за подршку. Онда се разиђемо неко време, свако ради неке самосталне ствари, па се поново окупимо, синхронизујемо се врло брзо, урадимо нешто заједно и поново се разиђемо.

Планирање и комуникација

Последњи блок пракси кроз који се решавају проблеми ОС је организација рада са самим задацима. Ово такође укључује размену искустава која је ван рада у пару. Погледајмо три праксе:

1. Циљеви кроз стабло циљева. Организовали смо целокупно управљање пројектом кроз дрво које иде бесконачно у будућност. Технички, праћење се врши у Миру. Постоји један задатак - то је средњи циљ. Од њега иду или мањи циљеви или групе задатака. Сами задаци потичу од њих. Сви задаци се креирају и одржавају на овој табли.

Ова шема такође пружа повратне информације, које се дешавају једном дневно када се синхронизујемо на митинзима. Имати заједнички план пред свима, али структуриран и потпуно отворен, омогућава свима да буду свесни шта се дешава и колико смо напредовали.

Предности визуелне визије задатака:

• Узрочност. Сваки задатак води ка неком глобалном циљу. Задаци су груписани у мање циљеве. Сам домен инфраструктуре је прилично технички. Није увек одмах јасно какав специфични утицај, на пример, писање рунбоок-а за прелазак на други нгинк има на пословање. Када је циљна карта у близини, постаје јасније.
  
  Узрочност је важно својство проблема. Он директно одговара на питање: „Да ли радим праву ствар?“
• Паралелизам. Има нас деветоро и једноставно је физички немогуће бацити све на један задатак. Ни задаци из једне области можда нису увек довољни. Принуђени смо да паралелизирамо рад између малих радних група. Истовремено, групе седе на свом задатку неко време, могу да буду појачане неким другим. Понекад људи испадају из ове радне групе. Неко иде на одмор, неко прави извештај за ДевОпс конф, неко напише чланак на Хабру. Знати који циљеви и задаци се могу радити паралелно постаје веома важно.

2. Замена презентатора јутарњих састанака. Код станд-уп-а имамо овај проблем - људи раде многе задатке паралелно. Понекад су задаци лабаво повезани и нема разумевања ко шта ради. А мишљење другог члана тима је веома важно. Ово су додатне информације које могу променити ток решавања проблема. Наравно, обично је неко са вама, али савети и савети су увек корисни.

Да бисмо побољшали ову ситуацију, користили смо технику „Промена водећег станд-уп-а“. Сада се ротирају према одређеној листи, и то има свој ефекат. Када је ваш ред, приморани сте да зароните и разумете шта се дешава да бисте водили добар Сцрум састанак.

3. Интерни демо. Помоћ у решавању проблема из програмирања у пару, визуелизација на дрвету проблема и помоћ на јутарњим састанцима су добри, али нису идеални. Као пар, ограничени сте само својим знањем. Стабло задатака помаже да се глобално разуме ко шта ради. А водитељ и колеге на јутарњем састанку неће уронити дубоко у ваше проблеме. Сигурно би им нешто могло недостајати.

Решење је пронађено у демонстрирању обављеног посла једни другима, а затим у дискусији о томе. Састајемо се једном недељно по сат времена и показујемо детаље о решењима задатака које смо урадили у протеклој недељи.

Током демонстрације потребно је открити детаље задатка и обавезно демонстрирати његов рад.

Извештај се може спровести коришћењем контролне листе.1. Уђите у контекст. Одакле задатак, зашто је уопште био потребан?

2. Како је проблем раније био решен? На пример, било је потребно масивно кликање мишем или је било немогуће било шта учинити.

3. Како га побољшавамо. На пример: „Види, сада постоји сцриптосик, ево реадме-а.“

4. Покажите како то функционише. Препоручљиво је директно имплементирати неки кориснички сценарио. Желим Кс, радим И, видим И (или З). На пример, поставим НГИНКС, запушим УРЛ и добијем 200 ОК. Ако је радња дуга, припремите је унапред да бисте је могли показати касније. Препоручљиво је да га не разбијате превише сат времена пре демонстрације, ако је ломљив.

5. Објасните колико је успешно решен проблем, које потешкоће остају, шта није завршено, која су побољшања могућа у будућности. На пример, сада ЦЛИ, онда ће бити потпуна аутоматизација у ЦИ.

Препоручљиво је да сваки говорник задржи 5-10 минута. Ако је ваш говор очигледно важан и трајаће дуже, координирајте ово унапред на каналу за преузимање.

После дела лицем у лице увек се води дискусија у нити. Овде се појављује повратна информација која нам је потребна о нашим задацима.

Као резултат, спроводи се анкета како би се утврдила корисност онога што се дешава. Ово је повратна информација о суштини говора и важности задатка.

Дуги закључци и шта даље

Можда се чини да је тон чланка помало песимистичан. Ово није у реду. Два нижа нивоа повратних информација, односно тестови и програмирање у пару, раде. Није тако савршено као у традиционалном развоју, али има позитиван ефекат од тога.

Тестови, у свом тренутном облику, пружају само делимичну покривеност кода. Многе конфигурационе функције остају непроверене. Њихов утицај на стварни рад при писању кода је мали. Међутим, постоји ефекат од интеграцијских тестова и они вам омогућавају да неустрашиво вршите рефакторинг. Ово је велико достигнуће. Такође, са померањем фокуса на развој у језицима високог нивоа (имамо питхон, иди), проблем нестаје. И не треба вам пуно провера за „лепак“; довољна је општа провера интеграције.

Рад у пару више зависи од конкретних људи. Ту је фактор задатака и наше меке вештине. Код неких људи то иде веома добро, код других иде горе. Дефинитивно има користи од овога. Јасно је да чак и ако се правила рада у пару не поштују довољно, сама чињеница заједничког извршавања задатака позитивно утиче на квалитет резултата. Лично, рад у пару ми је лакши и пријатнији.

Начини утицаја на ОС вишег нивоа – планирање и рад са задацима прецизно производе ефекте: квалитетну размену знања и бољи квалитет развоја.

Кратки закључци у једном реду

• ХР практичари раде у ИаЦ-у, али са мање ефикасности.
• Ојачајте оно што функционише.
• Осмислите сопствене компензационе механизме и праксе.

Извор: ввв.хабр.цом