Привіт, Хабре! Раніше я скаржився на життя в парадигмі Infrastructure as code і нічого не пропонував для вирішення ситуації, що склалася. Сьогодні я повернувся, щоб розповісти, які підходи та практики допоможуть вирватися з безодні розпачу та вирулити ситуацію у правильне русло.
У попередній статті я ділився своїм враженням від цієї сфери, намагався розмірковувати про поточну ситуацію в цій галузі і навіть припустив, що стандартні, відомі всім розробникам практики можуть допомогти. Могло здатися, що там було багато скарг на життя, але не було пропозицій щодо виходу із ситуації.
Хто ми, де ми та які у нас проблеми
Зараз ми знаходимося в Sre Onboarding Team, яка складається із шести програмістів та трьох інженерів інфраструктури. Усі ми намагаємося писати Infrastructure as code (IaC). Робимо ми це, тому що в принципі вміємо писати код і в анамнезі є розробниками рівня «вищого за середній».
- Ми маємо набір плюсів: певний бекграунд, знання практик, уміння писати код, бажання вчитися новому.
- І є провисаюча частина, вона ж мінус: брак знань щодо матчу інфраструктури.
Стек технологій, які ми використовуємо у нашому IaC.
- Terraform для створення ресурсів.
- Packer для збирання іміджів. Це Windows, CentOS 7 образи.
- Jsonnet робити потужну збірку в drone.io, а також для генерації packer json і наших модулів тераформа.
- Azure.
- Ansible при готуванні образів.
- Python для допоміжних сервісів та скриптів провіженінгу.
- І все це у VSCode з плагінами, розшареними між учасниками команди.
Висновок з моєї був такий: я намагався вселити (насамперед у себе) оптимізм, хотів сказати, що ми пробуватимемо відомі нам підходи та практики для того, щоб боротися з труднощами та складнощами, які є у цій сфері.
Зараз ми боремося з такими проблемами IaC:
- Недосконалість інструментів, засобів розробки коду.
- Повільне розгортання. Інфраструктура – це частина реального світу, а може бути нешвидким.
- Нестача підходів та практик.
- Ми новенькі та багато чого не знаємо.
Екстремальне програмування (XP) поспішає на допомогу
Всім розробникам добре знайоме екстремальне програмування (XP) та ті практики, які за ним стоять. Багато хто з нас працював за таким підходом, і він був вдалий. То чому б не скористатися принципами та практиками, закладеними там, щоб подолати труднощі інфраструктури? Ми вирішили застосувати цей підхід і подивитися, що з цього вийде.
Перевірка застосування підходу ХР до вашої сфериНаводжу опис середовища, для якого добре підходить XP, і як це співвідноситься з нами:
1. Dynamically changing software requirements. Нам було зрозуміло, якою є кінцева мета. Але в деталях можна варіювати. Ми самі вирішуємо, куди нам треба вирулити, тому вимоги періодично змінюються (здебільшого нами самими). Якщо брати команду SRE, яка сама робить автоматизацію, і сама обмежує вимоги і scope робіт, то цей пункт лягає добре.
2. Ризики спричинені fixed time projects using new technology. У нас можуть виникнути ризики при використанні якихось невідомих речей. І це 100% наш випадок. Весь наш проект – це використання технологій, з якими ми не були знайомі. Взагалі, це стала проблема, т.к. у сфері інфраструктури постійно з'являється безліч нових технологій.
3,4. Малий, co-located розширений розвиток team. Технологія ви можете використовувати для автоматизованих unit і функціональних tests. Ці два пункти не зовсім підходять нам. По-перше, ми не колоцьована команда, по-друге, нас є дев'ять осіб, що може вважатися великою командою. Хоча, за певними визначеннями «великої» команди, багато – це 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