Здравей, Хабр! Преди това се оплаквах от живота в парадигмата на инфраструктурата като код и не предлагах нищо за разрешаване на текущата ситуация. Днес се върнах, за да ви кажа какви подходи и практики ще ви помогнат да избягате от бездната на отчаянието и да насочите ситуацията в правилната посока.
В предишна статия Споделих впечатленията си от тази област, опитах се да разсъждавам върху текущата ситуация в тази област и дори предположих, че стандартните практики, известни на всички разработчици, могат да помогнат. Може да изглежда, че имаше много оплаквания от живота, но нямаше предложения за изход от настоящата ситуация.
Кои сме, къде сме и какви проблеми имаме
В момента сме в Sre Onboarding Team, който се състои от шестима програмисти и трима инфраструктурни инженери. Всички се опитваме да напишем инфраструктура като код (IaC). Правим това, защото основно знаем как да пишем код и имаме история на разработчици „над средното ниво“.
- Имаме набор от предимства: определен опит, познаване на практики, способност за писане на код, желание да научим нови неща.
- И има провиснала част, която също е минус: липса на познания за инфраструктурния хардуер.
Технологичният стек, който използваме в нашия IaC.
- Terraform за създаване на ресурси.
- Пакер за сглобяване на изображения. Това са изображения на Windows, CentOS 7.
- Jsonnet за създаване на мощна компилация в drone.io, както и за генериране на packer json и нашите terraform модули.
- Лазурен.
- Ansible при подготовката на изображения.
- Python за спомагателни услуги и скриптове за осигуряване.
- И всичко това във VSCode с плъгини, споделени между членовете на екипа.
Заключение от моето беше така: опитах се да вдъхна (преди всичко в себе си) оптимизъм, исках да кажа, че ще опитаме познатите ни подходи и практики, за да се справим с трудностите и сложностите, които съществуват в тази област.
В момента се борим със следните проблеми на IaC:
- Несъвършенство на инструментите и средствата за разработване на код.
- Бавно разгръщане. Инфраструктурата е част от реалния свят и може да бъде бавна.
- Липса на подходи и практики.
- Ние сме нови и не знаем много.
Екстремното програмиране (XP) на помощ
Всички разработчици са запознати с Extreme Programming (XP) и практиките, които стоят зад него. Много от нас са работили с този подход и той е успешен. Така че защо да не използваме принципите и практиките, изложени там, за преодоляване на инфраструктурните предизвикателства? Решихме да използваме този подход и да видим какво ще се случи.
Проверка на приложимостта на XP подхода към вашата индустрияЕто описание на средата, за която XP е много подходящ, и как тя се отнася към нас:
1. Динамично променящи се софтуерни изисквания. Беше ни ясно каква е крайната цел. Но подробностите могат да варират. Ние сами решаваме къде трябва да таксираме, така че изискванията се променят периодично (главно от нас). Ако вземем екипа на SRE, който прави самата автоматизация и сам ограничава изискванията и обхвата на работа, тогава тази точка пасва добре.
2. Рискове, причинени от проекти с фиксирано време, използващи нова технология. Може да се сблъскаме с рискове, когато използваме някои непознати за нас неща. И това е 100% нашият случай. Целият ни проект беше използването на технологии, с които не бяхме напълно запознати. Като цяло това е постоянен проблем, защото... През цялото време в инфраструктурния сектор се появяват много нови технологии.
3,4. Малък, съвместно разположен разширен екип за разработка. Автоматизираната технология, която използвате, позволява тестове на модули и функционални тестове. Тези две точки не ни устройват съвсем. Първо, ние не сме координиран екип, и второ, ние сме девет души, което може да се счита за голям екип. Въпреки че според някои дефиниции за „голям“ екип много са 14+ човека.
Нека да разгледаме някои XP практики и как те влияят на скоростта и качеството на обратната връзка.
Принцип на обратната връзка на XP
По мое разбиране обратната връзка е отговорът на въпроса, правилно ли постъпвам, отиваме ли там? XP има божествена схема за това: времева обратна връзка. Интересното е, че колкото по-ниско сме, толкова по-бързо можем да накараме ОС да отговори на необходимите въпроси.
Това е доста интересна тема за обсъждане, че в нашата ИТ индустрия е възможно бързо да получите операционна система. Представете си колко болезнено е да правиш проект шест месеца и едва тогава да разбереш, че е имало грешка в самото начало. Това се случва при проектирането и при всяко изграждане на сложни системи.
В нашия случай на IaC обратната връзка ни помага. Веднага ще направя малка корекция в диаграмата по-горе: планът за освобождаване няма месечен цикъл, но се появява няколко пъти на ден. Има някои практики, свързани с този цикъл на ОС, които ще разгледаме по-подробно.
Важно: обратната връзка може да бъде решение на всички проблеми, посочени по-горе. В комбинация с XP практики, може да ви измъкне от бездната на отчаянието.
Как да се измъкнете от бездната на отчаянието: три практики
тестове
Тестовете се споменават два пъти в обратната връзка на XP. Не е просто така. Те са изключително важни за цялата техника на екстремно програмиране.
Предполага се, че имате Unit и Acceptance тестове. Някои ви дават обратна връзка за няколко минути, други за няколко дни, така че писането им отнема повече време и се преглеждат по-рядко.
Има класическа тестова пирамида, която показва, че трябва да има повече тестове.
Как тази рамка се прилага за нас в IaC проект? Всъщност... никак.
- Единичните тестове, въпреки факта, че трябва да има много от тях, не могат да бъдат твърде много. Или тестват нещо много индиректно. Всъщност можем да кажем, че изобщо не ги пишем. Но ето няколко приложения за такива тестове, които успяхме да направим:
- Тестване на jsonnet код. Това например е нашият конвейер за сглобяване на дронове, който е доста сложен. Кодът на jsonnet е добре покрит от тестове.
Ние използваме това . - Тестове за скриптове, които се изпълняват при стартиране на ресурса. Скриптовете са написани на Python и следователно могат да се пишат тестове върху тях.
- Тестване на jsonnet код. Това например е нашият конвейер за сглобяване на дронове, който е доста сложен. Кодът на jsonnet е добре покрит от тестове.
- Потенциално е възможно да проверим конфигурацията в тестове, но ние не го правим. Възможно е също така да конфигурирате правила за конфигуриране на ресурс за проверка чрез . Въпреки това, проверките там са просто твърде елементарни за terraform, но много тестови скриптове са написани за AWS. И ние сме на Azure, така че това отново не е приложимо.
- Тестове за интегриране на компоненти: зависи от това как ги класифицирате и къде ги поставяте. Но по принцип работят.
Ето как изглеждат интеграционните тестове.
Това е пример при изграждане на изображения в Drone CI. За да ги достигнете, трябва да изчакате 30 минути, за да се образува изображението на Packer, след което да изчакате още 15 минути, за да преминат. Но те съществуват!Алгоритъм за проверка на изображението
- Packer трябва първо да подготви напълно изображението.
- До теста има тераформа с локално състояние, която използваме, за да разположим това изображение.
- При разгъване се използва малък модул, разположен наблизо, за да се улесни работата с изображението.
- След като виртуалната машина бъде внедрена от изображението, проверките могат да започнат. По принцип проверките се извършват с автомобил. Той проверява как са работили скриптовете при стартиране и как работят демоните. За да направим това, чрез ssh или winrm влизаме в новоповдигнатата машина и проверяваме статуса на конфигурацията или дали услугите работят.
- Подобна е ситуацията и с интеграционните тестове в модулите за terraform. Ето кратка таблица, обясняваща характеристиките на такива тестове.
Обратната връзка по тръбопровода е около 40 минути. Всичко се случва за много дълго време. Може да се използва за регресия, но за ново развитие като цяло е нереалистично. Ако сте много, много подготвени за това, подгответе изпълнявани скриптове, тогава можете да го намалите до 10 минути. Но това все още не са Unit тестове, които правят 5 броя за 100 секунди.
Липсата на модулни тестове при сглобяване на изображения или тераформирани модули насърчава прехвърлянето на работата към отделни услуги, които могат просто да се изпълняват чрез REST, или към скриптове на Python.
Например трябваше да се уверим, че когато виртуалната машина стартира, тя се регистрира в услугата , а когато виртуалната машина беше унищожена, тя се изтри.
Тъй като имаме ScaleFT като услуга, ние сме принудени да работим с нея чрез API. Там беше написана обвивка, която можете да издърпате и да кажете: „Влезте и изтрийте това и това.“ Той съхранява всички необходими настройки и достъпи.
Вече можем да напишем нормални тестове за това, тъй като не се различава от обикновения софтуер: някакъв апиха се подиграва, издърпвате го и вижте какво ще се случи.
Резултати от тестовете: Единичният тест, който трябва да даде ОС за минута, не го дава. И видовете тестване по-високо в пирамидата са ефективни, но покриват само част от проблемите.
Програмиране по двойки
Тестовете, разбира се, са добри. Можете да напишете много от тях, те могат да бъдат от различни видове. Те ще работят на своите нива и ще ни дадат обратна връзка. Но проблемът с лошите юнит тестове, които дават най-бързата ОС, остава. В същото време все още искам бърза ОС, с която да се работи лесно и приятно. Да не говорим за качеството на получения разтвор. За щастие има техники, които могат да осигурят дори по-бърза обратна връзка от модулните тестове. Това е програмиране по двойки.
Когато пишете код, искате да получите обратна връзка за неговото качество възможно най-бързо. Да, можете да напишете всичко в разклонение за функции (за да не счупите нищо за никого), да направите заявка за изтегляне в Github, да я присвоите на някой, чието мнение има тежест, и да изчакате отговор.
Но можете да чакате дълго време. Хората са заети, а отговорът, дори и да има, може да не е от най-високо качество. Да предположим, че отговорът дойде веднага, рецензентът мигновено разбра цялата идея, но отговорът все още идва късно, след факта. Иска ми се да беше по-рано. Това е целта на програмирането по двойки – веднага, в момента на писане.
По-долу са двойките стилове на програмиране и тяхната приложимост при работа с IaC:
1. Класически, опитен+опитен, смяна по таймер. Две роли – шофьор и навигатор. Двама души. Те работят върху един и същ код и сменят ролите си след определен предварително определен период от време.
Нека разгледаме съвместимостта на нашите проблеми със стила:
- Проблем: несъвършенство на инструментите и инструментите за разработка на код.
Отрицателно въздействие: отнема повече време за развитие, забавяме се, губи се темпото/ритъмът на работа.
Как се борим: използваме различни инструменти, обща IDE и също така научаваме преки пътища. - Проблем: Бавно внедряване.
Отрицателно въздействие: увеличава времето, необходимо за създаване на работеща част от кода. Отегчаваме се, докато чакаме, ръцете ни се протягат да направим нещо друго, докато чакаме.
Как се борим: не го преодолехме. - Проблем: липса на подходи и практики.
Отрицателно въздействие: няма знания за това как да се направи добре и как да се направи лошо. Удължава получаването на обратна връзка.
Как се борим: взаимният обмен на мнения и практики при работа по двойки почти решава проблема.
Основният проблем при използването на този стил в IaC е неравномерното темпо на работа. При традиционното разработване на софтуер имате много равномерно движение. Можете да отделите пет минути и да напишете N. Отделете 10 минути и да напишете 2N, 15 минути - 3N. Тук можете да прекарате пет минути и да напишете N, а след това да отделите още 30 минути и да напишете една десета от N. Тук не знаете нищо, задръстени сте, глупако. Разследването отнема време и отвлича вниманието от самото програмиране.
Извод: в чист вид не е подходящ за нас.
2. Пинг-понг. Този подход включва един човек да напише теста, а друг да го изпълни. Като вземем предвид факта, че всичко е сложно с модулните тестове и трябва да напишете интеграционен тест, който отнема много време за програмиране, цялата лекота на пинг-понга изчезва.
Мога да кажа, че се опитахме да разделим отговорностите за проектиране на тестов скрипт и внедряване на код за него. Един участник излезе със сценария, в тази част от работата той беше отговорен, той имаше последната дума. А другият отговаряше за изпълнението. Получи се добре. Качеството на скрипта с този подход се увеличава.
Заключение: уви, темпото на работа не позволява използването на пинг-понг като практика за програмиране по двойки в IaC.
3.Силен стил. . Идеята е единият участник да стане навигатор на директивата, а вторият да поеме ролята на водача на изпълнението. В този случай правото на вземане на решения принадлежи изключително на навигатора. Драйверът само печата и може да повлияе на случващото се с дума. Ролите не се сменят дълго време.
Добър за учене, но изисква силни меки умения. Тук се запънахме. Техниката беше трудна. И дори не става въпрос за инфраструктура.
Заключение: потенциално може да се използва, не се отказваме да опитваме.
4. Мобинг, роене и всички известни, но не изброени стилове Не го разглеждаме, т.к Не сме го пробвали и е невъзможно да говорим за това в контекста на нашата работа.
Общи резултати от използването на програмиране по двойки:
- Имаме неравномерно темпо на работа, което е объркващо.
- Сблъскахме се с недостатъчно добри меки умения. И предметната област не помага за преодоляването на тези наши недостатъци.
- Дългите тестове и проблемите с инструментите затрудняват разработката по двойки.
5. Въпреки това имаше успехи. Измислихме собствен метод „Конвергенция – Дивергенция“. Ще опиша накратко как работи.
Имаме постоянни партньори за няколко дни (по-малко от седмица). Заедно изпълняваме една задача. Седим заедно известно време: единият пише, другият седи и наблюдава екипа за поддръжка. След това се разпръсваме за известно време, всеки прави някакви независими неща, след което се събираме отново, синхронизираме се много бързо, правим нещо заедно и след това отново се разпръсваме.
Планиране и комуникация
Последният блок от практики, чрез които се решават проблемите на ОС, е организацията на работа със самите задачи. Това включва и обмен на опит, който е извън работата по двойки. Нека да разгледаме три практики:
1. Цели чрез дървото на целите. Организирахме цялостното управление на проекта чрез дърво, което върви безкрайно в бъдещето. Технически, проследяването се извършва в Miro. Има една задача - тя е междинна цел. От него тръгват или по-малки цели, или групи от задачи. Самите задачи идват от тях. Всички задачи се създават и поддържат на тази дъска.
Тази схема осигурява и обратна връзка, която се получава веднъж на ден, когато се синхронизираме на митинги. Наличието на общ план пред всички, но структуриран и напълно открит, позволява на всеки да е наясно какво се случва и докъде сме напреднали.
Предимства на визуалната визия на задачите:
- Причинност. Всяка задача води до някаква глобална цел. Задачите са групирани в по-малки цели. Самата инфраструктурна област е доста техническа. Не винаги е веднага ясно какво конкретно въздействие, например, писането на runbook за мигриране към друг nginx има върху бизнеса. Наличието на целевата карта наблизо го прави по-ясно.
Причинно-следствената връзка е важно свойство на проблемите. Той директно отговаря на въпроса: „Правя ли правилното нещо?“ - Паралелизъм. Ние сме девет и е просто физически невъзможно да натоварим всички с една задача. Задачите от една област също не винаги могат да бъдат достатъчни. Принудени сме да паралелизираме работата между малки работни групи. В същото време групите изпълняват задачата си известно време, те могат да бъдат подсилени от някой друг. Понякога хората отпадат от тази работна група. Някой отива на почивка, някой прави доклад за DevOps conf, някой пише статия в Habr. Знанието какви цели и задачи могат да се изпълняват паралелно става много важно.
2. Заместващи водещи на сутрешните срещи. При стендъпите имаме този проблем – хората изпълняват много задачи паралелно. Понякога задачите са хлабаво свързани и няма разбиране кой какво прави. А мнението на друг член на екипа е много важно. Това е допълнителна информация, която може да промени хода на решаване на проблема. Разбира се, обикновено има някой с вас, но съветите и съветите винаги са полезни.
За да подобрим тази ситуация, използвахме техниката „Промяна на водещото изправяне“. Сега те се редуват по определен списък и това дава своето отражение. Когато дойде ваш ред, вие сте принудени да се потопите и да разберете какво се случва, за да проведете добра Scrum среща.
3. Вътрешна демонстрация. Помощта при решаването на проблем от програмирането по двойки, визуализацията върху дървото на проблемите и помощта при срещите за схватка сутрин са добри, но не идеални. Като двойка сте ограничени само от знанията си. Дървото на задачите помага да се разбере глобално кой какво прави. И водещият и колегите на сутрешната среща няма да се потопят дълбоко в проблемите ви. Със сигурност може да пропуснат нещо.
Решението беше намерено в демонстрирането на свършената работа един на друг и след това да я обсъдим. Срещаме се веднъж седмично за един час и показваме подробности за решенията на задачите, които сме изпълнили през изминалата седмица.
По време на демонстрацията е необходимо да разкриете подробностите на задачата и не забравяйте да демонстрирате нейната работа.
Докладът може да се извърши с помощта на контролен списък.1. Влезте в контекста. Откъде дойде задачата, защо изобщо беше необходима?
2. Как беше решен проблемът преди? Например, изискваше се масивно щракване с мишката или изобщо беше невъзможно да се направи нещо.
3. Как го подобряваме. Например: „Вижте, сега има scriptosik, ето readme.“
4. Покажете как работи. Препоръчително е директно да се приложи някакъв потребителски сценарий. Искам X, правя Y, виждам Y (или Z). Например, внедрявам NGINX, изпушвам URL адреса и получавам 200 OK. Ако действието е дълго, подгответе го предварително, за да можете да го покажете по-късно. Препоръчително е да не го разбивате твърде много час преди демонстрацията, ако е крехко.
5. Обяснете колко успешно е решен проблемът, какви трудности остават, какво не е завършено, какви подобрения са възможни в бъдеще. Например, сега CLI, след това ще има пълна автоматизация в CI.
Препоръчително е за всеки говорител да бъде 5-10 минути. Ако речта ви е очевидно важна и ще отнеме повече време, координирайте това предварително в канала за превземане.
След частта лице в лице винаги има дискусия в темата. Тук се появява обратната връзка, от която се нуждаем за нашите задачи.
В резултат на това се провежда проучване, за да се определи полезността на случващото се. Това е обратна връзка за същността на речта и важността на задачата.
Дълги заключения и какво следва
Може да изглежда, че тонът на статията е малко песимистичен. Това е грешно. Две по-ниски нива на обратна връзка, а именно тестове и програмиране по двойки, работят. Не толкова перфектно, колкото при традиционното развитие, но има положителен ефект от него.
Тестовете в сегашната си форма осигуряват само частично покритие на кода. Много функции за конфигуриране в крайна сметка не са тествани. Влиянието им върху действителната работа при писане на код е слабо. Въпреки това има ефект от интеграционните тестове и те ви позволяват безстрашно да извършвате преработки. Това е голямо постижение. Също така, с изместването на фокуса към разработката на езици от високо ниво (имаме python, отидете), проблемът изчезва. И нямате нужда от много проверки за „лепилото“; обща проверка на интеграцията е достатъчна.
Работата по двойки зависи повече от конкретни хора. Има факторът задача и нашите меки умения. При някои хора се получава много добре, при други по-зле. Определено има ползи от това. Ясно е, че дори правилата за работа по двойки да не се спазват в достатъчна степен, самият факт на съвместно изпълнение на задачите има положителен ефект върху качеството на резултата. Лично за мен работата по двойки е по-лесна и приятна.
Начините на по-високо ниво за въздействие върху ОС - планирането и прецизната работа със задачите произвеждат ефекти: висококачествен обмен на знания и подобрено качество на разработката.
Кратки изводи в един ред
- HR практиците работят в IaC, но с по-малка ефективност.
- Укрепете това, което работи.
- Измислете свои собствени компенсаторни механизми и практики.
Източник: www.habr.com