🥇Infrastructure as Code: как да преодолеем проблемите с помощта на XP

Здравей, Хабр! Преди се оплаквах от живота в парадигмата Infrastructure as code и не предлагах решения на сложилата се ситуация. Днес се завръщам, за да споделя кои подходи и практики могат да ни помогнат да излезем от бездната на отчаянието и да насочим ситуацията в правилната посока.

В предишната статия «Infrastructure as code: първа среща» споделях впечатленията си от тази сфера, опитвах се да разсъждавам за текущата ситуация в областта и дори предполагах, че стандартните, известни на всички разработчици практики могат да помогнат. Можеше да изглежда, че там е имало много оплаквания, но не и предложения за изход от сложилата се ситуация.

Кои сме ние, къде сме и какви са нашите проблеми

В момента сме в Sre Onboarding Team, която се състои от шест програмисти и трима инженери в инфраструктурата. Всички ние се опитваме да пишем Infrastructure as code (IaC). Правим го, защото основно знаем как да пишем код и по произход сме разработчици от ниво «над средното».

Имаме набор от предимства: определен бекграунд, познания по практики, умения за писане на код и желание да учим ново.
И има част, която ни провисва, а именно недостатък: липса на знания относно инфраструктурната част.

Технологичен стек, който използваме в нашето IaC.

Terraform за създаване на ресурси.
Packer за изграждане на изображения. Това са Windows и CentOS 7 образи.
Jsonnet, за да създаваме мощни сборки в drone.io, а също и за генериране на packer json и нашите terraform модули.
Azure.
Ansible при подготовка на образи.
Python за помощни услуги, както и за скриптове за провиженинг.
И всичко това в VSCode с плъгини, споделени между участниците в екипа.

Изводът от моята предишна статия беше такъв: опитвах се да вдъхна (първо в себе си) оптимизъм, исках да кажа, че ще опитаме познатите ни подходи и практики, за да се справим с трудностите и предизвикателствата, които съществуват в тази сфера.

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

Несъвършенство на инструментите и средствата за разработка на код.
Бавно разгръщане. Инфраструктурата е част от реалния свят и той може да бъде бавен.
Липса на подходи и практики.
Ние сме нови и не знаем много.

Екстремно програмиране (XP) идва на помощ

На всички разработчици им е добре известно екстремалното програмиране (XP) и практиките, свързани с него. Много от нас са работили по този подход и той е бил успешен. Защо да не се възползваме от принципите и практиките, положени там, за да преодолеем трудностите в инфраструктурата? Решихме да приложим този подход и да видим какво ще излезе.

Проверка на приложимостта на подхода XP във вашата сфераПредставям описание на средата, за която XP е подходящ, и как това се отнася до нас:

1. Динамично променящи се софтуерни изисквания. За нас беше ясно каква е крайната цел. Но в детайлите могат да се променят. Ние сами решаваме накъде да тръгнем, затова изискванията периодично се променят (основно от нас самите). Ако вземем екипа SRE, който сам прави автоматизацията и сам ограничава изискванията и обхвата на работата, то този пункт е уместен.

2. Рискове, причинени от проектите с фиксирано време, използващи нова технология. Могат да възникнат рискове при използването на нещо, което не ни е познато. И това е 100% нашият случай. Целият наш проект е свързан с технологии, с които не сме напълно запознати. Всъщност това е постоянен проблем, тъй като в сферата на инфраструктурата постоянно излизат нови технологии.

3,4. Малък, съвместно разположен разширен екип за разработка. Технологията, която използвате, позволява автоматизирани единични и функционални тестове. Тези два пункта не са съвсем подходящи за нас. Първо, не сме екип с общо местоположение, а на второ място, ние сме девет души, което може да се счита за голям екип. Въпреки че според някои определения, „голям“ екип е 14+ души.

Нека разгледаме някои практики от XP и как те влияят на скоростта и качеството на обратната връзка.

Принцип на цикъла на обратна връзка в XP

Според мен обратната връзка е отговор на въпроса дали правя нещо правилно, накъде вървим? В XP по този въпрос има чудесна схема: цикъл на обратна връзка в хода на времето. Интересното е, че колкото по-долу сме, толкова по-бързо можем да получим обратна стойност, за да отговорим на необходимите въпроси.

Това е доста интересна тема за обсъждане, че в IT индустрията е възможно бързо да се получи обратна стойност. Представете си колко трудно е да правите някакъв проект половин година и чак след това да разберете, че в самото начало е била заложена грешка. Такова нещо се среща както в проектирането, така и при изграждането на сложни системи.

В нашия случай IaC ни помага обратната връзка. Веднага правя малка корекция в схемата по-горе: релизният план не е месечен цикъл, а се случва няколко пъти на ден. Към този цикъл ОС са привързани някои практики, които ще разгледаме по-подробно.

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

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

Тестове

Тестовете се споменават два пъти в цикъла на обратната връзка на XP. Това не е случайно. Те са изключително важни за цялата техника на екстремно програмиране.

Предполага се, че имаш Unit и Acceptance тестове. Едните дават обратна връзка за няколко минути, а другите за няколко дни, защото се пишат по-дълго, а се изпълняват по-рядко.

Има класическа пирамида на тестването, която показва, че определени тестове трябва да бъдат повече.

Как тази схема е приложима към нас в проекта IaC? Всъщност… никак.

Не може да има много Unit тестове, въпреки че те трябва да са много. Или те тестват нещо много косвено. Всъщност можем да кажем, че почти не ги пишем. Но ето няколко приложения за такива тестове, които все още успяхме да направим:
1. Тестване на кода на jsonnet. Например, нашият пайплайн за сборка в drone, който е доста сложен. Кодът на jsonnet е добре покрит с тестове.
  Използваме този Unit testing framework for Jsonnet.
2. Тестове на скриптове, които се изпълняват при стартиране на ресурса. Скриптовете са на Python, което значи, че тестовете на тях също могат да се пишат.
Потенциално, проверката на конфигурацията в тестовете е възможна, но ние не го правим. Има и възможност за настройка на проверка на правилата за конфигуриране на ресурси чрез tflint. Но просто за терраформ там има твърде основни проверки, а много проверъчни сценарии са написани за AWS. А ние сме на Azure, така че отново не е приложимо.
Компонентни интеграционни тестове: тук зависи от това как ги класифицираш и къде ги разполагаеш. Но те основно работят.
Така изглеждат интеграционните тестове.

Това е пример при сглобяване на образи в Drone CI. За да ги достигнеш, трябва да чакаш 30 минути за строежа на имиджа Packer, след това още 15 минути, докато преминат. Но те съществуват!
Алгоритъм за проверка на образите
1. Първо Packer трябва да приготви образа напълно.
2. Близо до теста има терраформ с локално състояние, с който разгръщаме този образ.
3. При разгръщането се използва малък модул, разположен наблизо, за да е по-лесно да се работи с образа.
4. Когато образът разгръща VM, могат да започнат проверките. Основно проверките се извършват на машината. Проверява се как са работили скриптовете при старта, как работят демоните. За целта през ssh или winrm влизаме на току-що стартираната машина и проверяваме състоянието на конфигурацията или дали са се стартирали услугите.
Подобна ситуация има и с интеграционните тестове и в модулите за терраформ. Ето кратка таблица, обясняваща особеностите на такива тестове.

Обратната връзка в пайплайна е около 40 минути. Всичко става много бавно. Може да се използва за регресия, но за нова разработка е просто нереално. Ако много добре се подготвите, подготвите running, скриптове, може да се съкрати до 10 минути. Но това все пак не е Unit-тестове, които за 5 секунди правят 100.

Липсата на Unit-тестове при изграждане на образи или модули за терраформ ни принуждава да прехвърлим работата на отделни услуги, които просто могат да се извикат по REST, или на Python-скриптове.

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

Тъй като ScaleFT е услуга, ние сме принудени да работим с нея през API. Направена е обвивка, която можем да извикаме и да кажем: „Влез и изтрий това и това“. Тя съдържа всички необходими настройки и достъпи.

На това вече можем да пишем нормални тестове, тъй като това не се различава от обикновен софтуер: моква се някакъв API, извикваш, и виждаш какво се случва.

Резюме на тестовете: Unit-тестуване, което трябва да предоставя ОС за минута, не го прави. А по-високите нива на тестуване дават ефект, но покриват само част от проблемите.

Партньорно програмиране

Тестовете са, разбира се, полезни. Можем да пишем много от тях, те могат да бъдат различни видове. Те ще работят на своите нива и ще ни дават обратна връзка. Но проблемът с лошите юнит тестове, които дават най-бързата ОС, остава. В същото време искаме бърза ОС, с която да работим лесно и приятно. Не говоря за качеството на полученото решение. За щастие, съществуват техники, които позволяват да получим дори по-бърза обратна връзка от модулите за тестиране. Това е парното програмиране.

Когато пишем код, искаме да получим обратна връзка за неговото качество възможно най-бързо. Да, можем да напишем всичко в функционалната клонка (за да не счупим нищо), да направим pull request в GitHub, да назначим някой, чийто мнение има значение, и да чакаме отговор.

Но чакането може да отнеме дълго време. Хората са заети, а отговорът, дори и да дойде, може да не е с най-високо качество. Да предположим, че отговорът е дошъл веднага, рецензентът е разбрал целия замисъл, но отговорът все още идва със закъснение, постфактум. А ние искаме по-рано. Затова парното програмиране е насочено именно към това – да осигури обратна връзка в момента на писане.

По-долу ще представя стиловете на парното програмиране и тяхното приложение при работа по IaC:

1. Класически, Опитен + Опитен, смяна по таймер. Две роли – шофьор и навигатор. Двама души. Те работят върху един и същи код и сменят ролите си на определен предварително зададен интервал от време.

Нека разгледаме съвместимостта на нашите проблеми със стила:

Проблема: несъвършенство на инструментите, средствата за разработка на код.
Негативно влияние: по-дълга разработка, забавяме се, нарушаваме темпа/ритъма на работа.
Как се борим: прилагаме други инструменти, общ IDE и също така учим шорткотове.
Проблема: бавно разгръщане.
Негативно влияние: увеличава времето за създаване на работещ фрагмент код. Нудим се по време на чакането, ръцете ни искат да се заемат с нещо друго, докато чакаме.
Как се борим: не можем да се справим.
Проблема: недостатък на подходи и практики.
Негативно влияние: няма знание как да се прави добро, а как лошо. Удължава получаването на обратна връзка.
Как се борим: обменът на мнения и практики в парната работа почти решава проблема.

Главният проблем при прилагането на този стил в IaC е неправилният темп на работа. При традиционната разработка на софтуер имаш много равномерен темп. Можеш да отделиш пет минути и да напишеш N. Да отделиш 10 минути и да напишеш 2N, 15 минути – 3N. Тук обаче можеш да отделиш пет минути и да напишеш N, а след това да отделиш още 30 минути и да напишеш десета част от N. Тук не знаеш нищо, имаш блокаж, застой. Разясняването отнема време и отвлича от самото програмиране.

Извод: в чист вид не е подходящо за нас.

2. Ping-pong. Този подход предполага, че един участник пише тест, а другият прави реализацията му. С оглед на факта, че с Unit тестовете всичко е сложно и се налага да се пише дълъг интеграционен тест, цялата лекота на ping-pong се губи.

Мога да кажа, че сме пробвали разделение на задълженията за проектиране на сценария за теста и реализацията на кода. Един участник измисля сценария, в тази част от работата той е отговорен, последната дума е негова. Другият е отговорен за реализацията. Това работи добре. Качеството на сценария с такъв подход се увеличава.

Извод: за съжаление, темпът на работа не позволява да използваме ping-pong като практика за парно програмиране в IaC.

3. Strong Style. Сложна практика.Идеята е, че един участник става директивен навигатор, а другият играе ролята на изпълнителен драйвър. При това правото на решенията е само на навигатора. Драйверът просто пише и може да влияе на случващото се с думи. Ролите не се сменят дълго време.

Подходящо е за обучение, но изисква силни софтуерни умения. На това се спънахме. Техниката беше сложна. И проблемът не е дори в инфраструктурата.

Извод: потенциално може да се прилага, не се отказваме.

4. Mobbing, swarming и всичките известни, но не изброени тук стилове не разглеждаме, тъй като не сме ги пробвали и не можем да кажем нищо в контекста на нашата работа.

Общи заключения относно използването на парно програмиране:

Имаме неравномерен темп на работа, който ни смущава.

Сблъскваме се с недостатъчно добри софтуерни умения. А предметната област не способства за преодоляване на тези недостатъци.

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

5. Въпреки това, имаше и успехи. Измислихме собствен метод „Схождение – разминаване“. Накратко ще опиша как работи.

Имаме постоянни партньори за няколко дни (по-малко от седмица). Правим една задача заедно. За известно време седим заедно: един пише, вторият седи и наблюдава, като е част от екипа за поддръжка. След това се разделяме за кратко, всеки изпълнява независими задачи, след което отново се събираме, много бързо синхронизираме, правим нещо заедно и отново се разпръскваме.

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

Последният блок от практики, чрез които се решават проблеми в ОС, е организацията на работата със самите задачи. Тук влиза и обмена на опит, който се случва извън двойната работа. Нека разгледаме три практики:

1. Задачи чрез дърво на целите. Общото управление на проекта организирахме през дърво, което безкрайно се разширява в бъдещето. Технически управлението става в Miro. Има една задача - тя е междинна цел. От нея излизат по-малки цели или групи от задачи. От тях вече идват самите задачи. Всички задачи се създават и управляват на тази дъска.

Тази схема също предоставя обратна връзка, която се осъществява веднъж на ден, когато се синхронизираме на срещи. Наличието на общ план пред всички, в същото време структуриран и напълно отворен, позволява на всеки да бъде наясно с текущото състояние и напредъка, който сме постигнали.

Предимства на визуализацията на задачите:

Причинност. Всяка задача води до глобална цел. Задачите се групират по по-малки цели. Доменът на инфраструктурата сам по себе си е доста технологичен. Не винаги е веднага ясно какво конкретно влияние оказва например написването на наръчник за миграция към друг nginx върху бизнеса. Наличието на целева карта до него прави това по-разбираемо.

Причинността е важно свойство на задачите. То пряко отговаря на въпроса: „Ако ли правя точно това?“
Паралелизъм. Ние сме девет души и е физически невъзможно всички да се накиприм за една задача. Задачите от една и съща област не винаги са достатъчни. Наложително е да разделим работа между малки работни екипи. Всеки екип работи известно време по своята задача, а може да получат и допълнителна помощ. От този работен екип понякога се отделят хора. Някои излизат в отпуск, други правят доклад за конференцията DevOps conf, трети пишат статия за Хабр. Знанието за целите и задачите, които могат да се изпълняват паралелно, става изключително важно.

2. Сменяеми водещи на утринните срещи. На стендапите се появи определен проблем – много задачи се изпълняват паралелно от хората. Понякога задачите слабо се свързват помежду си и няма яснота кой какво прави. Мнението на още един член на екипа е много важно. Това е допълнителна информация, която може да промени хода на решаването на задачата. Разбира се, обикновено екипът е в двойка, но консултацията и съветите винаги са полезни.

За да подобрим ситуацията, приложихме техниката "Смяна на водещия на стендапа". Сега те ротират по определен списък и това дава своя ефект. Когато дойде реда ти, си принуден да се потопиш и да разбереш какво се случва, за да проведеш добре скрам-срещата.

3. Вътрешно демо. Помощта при решаването на задачи чрез парно програмиране, визуализация на дървото на задачите и оказването на помощ на скрам-срещите сутрин е полезна, но не идеална. В двойка сте ограничени единствено от собствените си знания. Дървото на задачите помага да се разбере глобално кой какво прави. А водещият и колегите на утринната среща няма да се задълбочат в твоите проблеми. Сигурно губят нещо важено.

Решението беше намерено в демонстрация на извършените работи помежду си и последваща дискусия по тях. Събираме се веднъж седмично за час и показваме детайли за решенията по задачите, извършени през изминалата седмица.

По време на демонстрацията е необходимо да се разкрият детайлите на задачата и да се демонстрира работата ѝ.

Докладът може да се води по чек-лист.1. Въведете в контекст. От къде е дошла задачата, защо всъщност беше нужна?

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

3. Как подобряваме това. Например: "Вижте, сега има скрипт, ето ридми".

4. Покажете как работи това. Желателно е да осъществите някакъв сценарий на потребителя. Искам X, правя Y, виждам Й (или Z). Например, деплойвам NGINX, проверявам url, получавам 200 OK. Ако действието е дълго, подгответе предварително, за да го покажете. Желателно е един час преди демото да не нарушавате това, ако е кр Fragile.

5. Обяснете колко успешно е решен проблемът, какви трудности остават, какво не е завършено, какви подобрения са възможни в бъдеще. Например, сега е cli, после ще бъде пълна автоматика в CI.

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

След частта на живо задължително следва обсъждане в темата. Тук именно се появява необходимата обратна връзка за собствените ни задачи.

Накрая се провежда анкета, за да се установи полезността на събитието. Това е вече обратна връзка за самото представяне и важността на задачата.

Дълги изводи и какво следва

Може да изглежда, че тонът на статията е малко песимистичен. Това не е така. Двата основни начина за получаване на обратна връзка, а именно тестове и двойно програмиране, работят. Не напълно както в традиционната разработка, но позитивният ефект от това съществува.

Тестовете, в текущия им вид, предлагат само частично покритие на кода. Много функции на конфигурация остават не тествани. Влиянието им върху непосредствената работа при писането на код е ниско. Въпреки това, ефектът от интеграционните тестове е наличен и именно те позволяват безпрепятствени рефакторинги. Това е голямо постижение. С прехвърлянето на фокуса върху разработката в висококачествени езици (например python, go), проблемът изчезва. А относно

Работата в двойка зависи повече от конкретните хора. Налице е факторът задача и нашите софтуерни умения. С някои колеги работи много добре, с други по-лошо. Ползата от това очевидно съществува. Ясно е, че дори при недостатъчно спазване на правилата за работа в двойка, самият факт на съвместно изпълнение на задачи положително влияе на качеството на резултата. Лично за мен е по-лесно и приятно да работя в двойка.

По-високите способи за влияние върху операционната система – планирането и работата с задачите определено дават ефект: качествен обмен на знания и подобряване на качеството на разработката.