🥇Инфраструктура како код: Како да ги надминете проблемите со XP

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

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

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

Во моментов сме во Sre Onboarding Team, кој се состои од шест програмери и тројца инфраструктурни инженери. Сите ние се обидуваме да ја напишеме инфраструктурата како код (IaC). Ова го правиме затоа што во основа знаеме да пишуваме код и имаме историја на „надпросечни“ програмери.

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

Технолошкиот куп што го користиме во нашиот IaC.

Тераформа за создавање ресурси.
Пакер за склопување слики. Ова се слики од Windows, CentOS 7.
Jsonnet за да направи моќна верзија во drone.io, како и да генерира пакувач json и нашите тераформски модули.
Лазур.
Обезбеден при подготовка на слики.
Python за помошни услуги и скрипти за обезбедување.
И сето тоа во VSCode со приклучоци споделени помеѓу членовите на тимот.

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

Во моментов се бориме со следниве IaC проблеми:

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

Екстремно програмирање (XP) за спас

Сите програмери се запознаени со Екстремното програмирање (XP) и практиките што стојат зад него. Многумина од нас работеа со овој пристап, и тој беше успешен. Па зошто да не ги искористите принципите и практиките наведени таму за да ги надминете инфраструктурните предизвици? Решивме да го преземеме овој пристап и да видиме што ќе се случи.

Проверка на применливоста на пристапот XP во вашата индустријаЕве опис на околината за која е добро прилагодена XP и како таа се поврзува со нас:

1. Динамично менување на софтверските барања. Ни беше јасно која е крајната цел. Но, деталите може да варираат. Ние самите одлучуваме каде треба да таксираме, така што барањата периодично се менуваат (главно сами). Ако го земеме тимот на SRE, кој ја прави самата автоматизација и самиот ги ограничува барањата и обемот на работа, тогаш оваа точка добро се вклопува.

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

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

Ајде да погледнеме некои практики на XP и како тие влијаат на брзината и квалитетот на повратните информации.

Принцип на јамка за повратни информации на XP

Според моето разбирање, фидбекот е одговорот на прашањето дали ја правам вистинската работа, одиме ли таму? XP има божествена шема за ова: јамка за временска повратна информација. Интересното е што колку сме пониски, толку побрзо можеме да го натераме ОС да одговори на потребните прашања.

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

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

Важно: повратните информации можат да бидат решение за сите проблеми наведени погоре. Во комбинација со XP практиките, може да ве извлече од бездната на очајот.

Како да се извлечете од бездната на очајот: три практики

Тестови

Тестовите се споменуваат двапати во циклусот за повратни информации на XP. Не е само така. Тие се исклучително важни за целата техника на Екстремно програмирање.

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

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

Како оваа рамка се применува за нас во проект за IaC? Всушност... никако.

Единиците тестови, и покрај фактот дека треба да ги има многу, не можат да бидат премногу. Или многу индиректно тестираат нешто. Всушност, можеме да кажеме дека воопшто не ги пишуваме. Но, еве неколку апликации за такви тестови што можевме да ги направиме:
1. Тестирање jsonnet код. Ова, на пример, е нашиот цевковод за склопување на дронови, кој е доста комплициран. Кодот jsonnet е добро покриен со тестови.
  Ние го користиме ова Рамка за тестирање на единицата за Jsonnet.
2. Тестови за скрипти кои се извршуваат кога ресурсот започнува. Скриптите се напишани во Python, и затоа може да се напишат тестови на нив.
Потенцијално е можно да се провери конфигурацијата во тестовите, но ние не го правиме тоа. Исто така, можно е да се конфигурираат правилата за конфигурација на ресурси за проверка преку тфлинт. Сепак, проверките таму се едноставно премногу основни за тераформи, но многу тест скрипти се напишани за AWS. И ние сме на Azure, така што ова повторно не важи.
Тестови за интеграција на компоненти: зависи од тоа како ги класифицирате и каде ги ставате. Но, тие во основа функционираат.
Вака изгледаат тестовите за интеграција.

Ова е пример кога се градат слики во Drone CI. За да стигнете до нив, треба да почекате 30 минути за да се формира сликата на Packer, а потоа да почекате уште 15 минути за да поминат. Но, тие постојат!
Алгоритам за проверка на сликата
1. Пакер мора прво целосно да ја подготви сликата.
2. До тестот има тераформа со локална состојба, која ја користиме за да ја распоредиме оваа слика.
3. Кога се расплетува, се користи мал модул што лежи во близина за да се олесни работата со сликата.
4. Откако ќе се распореди VM од сликата, може да започнат проверките. Во основа, проверките се вршат со автомобил. Проверува како функционирале скриптите при стартување и како функционираат демоните. За да го направите ова, преку ssh или winrm се најавуваме во новоподигнатата машина и го проверуваме статусот на конфигурацијата или дали услугите се отворени.
Слична е ситуацијата и со тестовите за интеграција во модулите за тераформ. Еве кратка табела која ги објаснува карактеристиките на таквите тестови.

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

Отсуството на Unit тестови при составување слики или тераформни модули поттикнува префрлање на работата на одделни сервиси кои едноставно може да се извршуваат преку REST или на Python скрипти.

На пример, требаше да се увериме дека кога ќе се стартува виртуелната машина, таа самата се регистрира во услугата ScaleFT, и кога виртуелната машина беше уништена, таа сама се избриша.

Бидејќи го имаме ScaleFT како услуга, принудени сме да работиме со него преку API. Имаше напишано обвивка што можеш да ја повлечеш и да кажеш: „Влези и избришете го ова и она“. Ги зачувува сите потребни поставки и пристапи.

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

Резултати од тестовите: Тестирањето на единицата, кое треба да го даде ОС за една минута, не го дава. И типовите на тестирање повисоки во пирамидата се ефективни, но покриваат само дел од проблемите.

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

Тестовите се, се разбира, добри. Можете да напишете многу од нив, тие можат да бидат од различни типови. Тие ќе работат на нивните нивоа и ќе ни дадат повратни информации. Но, проблемот со лошите Unit тестови, кои го даваат најбрзиот оперативен систем, останува. Во исто време, сè уште сакам брз ОС со кој е лесен и пријатен за работа. Да не зборуваме за квалитетот на добиеното решение. За среќа, постојат техники кои можат да дадат дури и побрза повратна информација од единечните тестови. Ова е програмирање во парови.

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

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

Подолу се прикажани стиловите на програмирање парови и нивната применливост при работа на IaC:

1. Класичен, искусен+искусен, поместување по тајмер. Две улоги - возач и навигатор. Двајца луѓе. Тие работат на истиот код и ги менуваат улогите по одреден однапред одреден временски период.

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

Проблем: несовршеност на алатките и алатките за развој на код.
Негативно влијание: потребно е подолго да се развие, успоруваме, темпото/ритамот на работа се губи.
Како се бориме: користиме различни алатки, заеднички IDE и учиме и кратенки.
Проблем: бавно распоредување.
Негативно влијание: го зголемува времето потребно за создавање на работен дел од кодот. Досадно ни е додека чекаме, рацете ни подаваат да направиме нешто друго додека чекаме.
Како се бориме: не го надминавме.
Проблем: недостаток на пристапи и практики.
Негативно влијание: нема знаење како тоа да се направи добро и како да се направи лошо. Го продолжува приемот на повратни информации.
Како се бориме: меѓусебната размена на мислења и практики во работата во парови речиси го решава проблемот.

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

Заклучок: во својата чиста форма не ни одговара.

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

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

Заклучок: за жал, темпото на работа не дозволува користење на пинг-понг како практика за програмирање парови во IaC.

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

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

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

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

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

Имаме нерамномерно темпо на работа, што е збунувачки.

Наидовме на недоволно добри меки вештини. И предметната област не помага да се надминат овие наши недостатоци.

Долгите тестови и проблемите со алатките го отежнуваат развојот на спарените.

5. И покрај ова, имаше успеси. Дојдовме до наш сопствен метод „Конвергенција - дивергенција“. Накратко ќе опишам како функционира.

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

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

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

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

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

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

Каузалност. Секоја задача води кон некоја глобална цел. Задачите се групирани во помали цели. Самиот домен на инфраструктурата е доста технички. Не е секогаш веднаш јасно какво специфично влијание има врз бизнисот, на пример, пишувањето книга за мигрирање во друг nginx. Имајќи ја целната картичка во близина, станува појасно.

Каузалноста е важно својство на проблемите. Тоа директно одговара на прашањето: „Дали ја правам вистинската работа?
Паралелизам. Ние сме деветмина и едноставно е физички невозможно да ги фрлиме сите на една задача. Можеби и не секогаш се доволни задачите од една област. Принудени сме да ја паралелизираме работата меѓу малите работни групи. Во исто време, групите седат на својата задача извесно време, тие можат да бидат засилени со некој друг. Понекогаш луѓето отпаѓаат од оваа работна група. Некој оди на одмор, некој прави извештај за DevOps conf, некој пишува статија на Habr. Знаењето кои цели и задачи може да се направат паралелно станува многу важно.

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

За да ја подобриме оваа ситуација, ја користевме техниката „Промена на водечкиот штанд-ап“. Сега тие се ротираат според одредена листа и тоа има свој ефект. Кога ќе дојдете на ред, вие сте принудени да се нурнете и да разберете што се случува за да одржите добар состанок на Scrum.

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

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

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

Извештајот може да се спроведе со помош на листа за проверка.1. Влезете во контекст. Од каде дојде задачата, зошто воопшто беше потребна?

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

3. Како го подобруваме. На пример: „Види, сега има скриптосик, тука е читањето“.

4. Покажете како функционира. Препорачливо е директно да се имплементира некое корисничко сценарио. Сакам X, правам Y, гледам Y (или Z). На пример, го распоредувам NGINX, го пушам URL-то и добивам 200 ОК. Ако дејството е долго, подгответе го однапред за да можете да го покажете подоцна. Препорачливо е да не го кршите премногу еден час пред демото, доколку е кревко.

5. Објаснете колку успешно е решен проблемот, какви потешкотии остануваат, што не е завршено, какви подобрувања се можни во иднина. На пример, сега CLI, тогаш ќе има целосна автоматизација во CI.

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

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

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

Долги заклучоци и што е следно

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

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

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

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