Привет, Хабр! Раньше я жаловался на жизнь в Инфраструктуре как на парадигму кода и не предлагал ничего для решения сложившейся ситуации.
Сегодня я вернулся, чтобы рассказать вам, какие подходы и практики помогут вам вырваться из бездны отчаяния и направить ситуацию в правильное русло.
Серия статей об инфраструктуре как коде и нашем опыте в SRE: 1. Инфраструктура как код: первое знакомство.В предыдущей статье «Инфраструктура как код: первое знакомство» Я поделился своими впечатлениями об этой сфере, попытался поразмышлять о текущей ситуации в этой сфере и даже предположил, что могут помочь стандартные практики, известные всем разработчикам.2. Инфраструктура как код: как преодолеть проблемы с использованием XP. (Вы здесь).
3. Путь разработчика в SRE: зачем идти в инфраструктуру и что из этого получится.
Казалось бы, жалоб на жизнь было много, но предложений по выходу из сложившейся ситуации не было.
Кто мы, где мы и какие у нас проблемы
В настоящее время мы находимся в команде Sre Onboarding, которая состоит из шести программистов и трех инженеров по инфраструктуре.Мы все пытаемся написать инфраструктуру как код (IaC).
Мы делаем это, потому что в основном знаем, как писать код, и имеем опыт разработчиков «выше среднего».
- У нас есть набор преимуществ: определенный бэкграунд, знание практик, умение писать код, желание учиться новому.
- И есть провисающая часть, которая тоже является минусом: отсутствие знаний об инфраструктурном оборудовании.
- Терраформирование для создания ресурсов.
- Пакер для сборки образов.
Это образы Windows, CentOS 7.
- Jsonnet для создания мощной сборки вdrone.io, а также для создания упаковщика json и наших модулей terraform.
- Лазурный.
- Ansible при подготовке изображений.
- Python для вспомогательных служб и сценариев подготовки.
- И все это в VSCode с плагинами, которыми пользуются члены команды.
В настоящее время мы боремся со следующими проблемами IaC:
- Несовершенство инструментов и средств разработки кода.
- Медленное развертывание.
Инфраструктура — это часть реального мира, и она может работать медленно.
- Отсутствие подходов и практик.
- Мы новички и многого не знаем.
Экстремальное программирование (XP) спешит на помощь
Все разработчики знакомы с экстремальным программированием (XP) и практиками, лежащими в его основе.Многие из нас работали с этим подходом, и он оказался успешным.
Так почему бы не использовать изложенные там принципы и практики для решения инфраструктурных проблем? Мы решили применить этот подход и посмотреть, что получится.
Проверка применимости подхода XP к вашей отрасли Вот описание среды, для которой хорошо подходит XP, и ее отношение к нам: 1. Динамически меняющиеся требования к программному обеспечению.
Нам было ясно, какова конечная цель.
Но детали могут различаться.
Мы сами решаем, куда нам нужно рулить, поэтому требования периодически меняются (в основном мы сами).
Если взять команду SRE, которая сама занимается автоматизацией и сама ограничивает требования и объем работ, то этот момент подходит хорошо.
2. Риски, вызванные проектами с фиксированными сроками с использованием новых технологий.
Мы можем столкнуться с риском при использовании некоторых неизвестных нам вещей.
И это 100% наш случай.
Весь наш проект заключался в использовании технологий, с которыми мы не были до конца знакомы.
В общем, это постоянная проблема, потому что.
В инфраструктурном секторе постоянно появляется много новых технологий.
3.4. Небольшая расширенная команда разработчиков, расположенная в одном месте.
Автоматизированная технология, которую вы используете, позволяет проводить модульные и функциональные тесты.
Эти два пункта нас не совсем устраивают. Во-первых, мы не слаженная команда, во-вторых, нас девять человек, что можно считать большой командой.
Хотя, по некоторым определениям «большого» коллектива, это 14+ человек.
Давайте рассмотрим некоторые практики XP и то, как они влияют на скорость и качество обратной связи.
Принцип обратной связи XP
В моем понимании обратная связь – это ответ на вопрос, правильно ли я делаю, туда ли идем? В XP есть божественная схема для этого: петля обратной связи по времени.Интересно то, что чем ниже мы находимся, тем быстрее мы сможем заставить ОС отвечать на необходимые вопросы.
Это довольно интересная тема для обсуждения, что в нашей IT-индустрии можно быстро получить ОС.
Представьте, как больно полгода делать проект и только потом обнаружить, что в самом начале была ошибка.
Это происходит при проектировании и при любом построении сложных систем.
В нашем случае с IaC нам помогает обратная связь.
Сразу внесу небольшую корректировку в схему выше: план релизов не имеет месячного цикла, а происходит несколько раз в день.
Есть некоторые практики, связанные с этим циклом ОС, которые мы рассмотрим более подробно.
Важно: обратная связь может стать решением всех изложенных выше проблем.В сочетании с практиками опыта это может вытащить вас из бездны отчаяния.
Как вытащить себя из пучины отчаяния: три практики
Тесты
Тесты упоминаются дважды в цикле обратной связи XP. Это не просто так.Они чрезвычайно важны для всей техники экстремального программирования.
Предполагается, что у вас есть модульные и приемочные тесты.
Некоторые дают вам отзыв через несколько минут, другие — через несколько дней, поэтому на их написание уходит больше времени, и они проверяются реже.
Существует классическая пирамида тестирования, которая показывает, что тестов должно быть больше.
Как эта структура применима к нам в проекте IaC? На самом деле.
совсем нет.
- Юнит-тестов, несмотря на то, что их должно быть много, не может быть слишком много.
Или они что-то тестируют очень косвенно.
По сути, можно сказать, что мы их вообще не пишем.
Но вот несколько приложений для таких тестов, которые нам удалось сделать:
- Тестирование кода jsonnet. Это, например, наш конвейер сборки дронов, который довольно сложен.
Код jsonnet хорошо покрыт тестами.
Мы используем это Фреймворк модульного тестирования для Jsonnet .
- Тесты для сценариев, которые выполняются при запуске ресурса.
Скрипты пишутся на Python, поэтому на них можно писать тесты.
- Тестирование кода jsonnet. Это, например, наш конвейер сборки дронов, который довольно сложен.
- Потенциально можно проверить конфигурацию в тестах, но мы этого не делаем.
Также можно настроить проверку правил конфигурации ресурсов через тфлинт .
Однако проверки там слишком просты для terraform, а многие тестовые скрипты написаны для AWS. И мы находимся в Azure, так что это снова неприменимо.
- Интеграционные тесты компонентов: это зависит от того, как вы их классифицируете и где размещаете.
Но в принципе они работают. Вот как выглядят интеграционные тесты.
Это пример создания изображений в Drone CI. Чтобы до них добраться, нужно подождать 30 минут, пока сформируется образ Пакера, затем подождать еще 15 минут, чтобы они прошли.Но они существуют! Алгоритм проверки изображения
- Упаковщик должен сначала полностью подготовить изображение.
- Рядом с тестом есть терраформ с локальным состоянием, который мы используем для развертывания этого образа.
- При раскладывании используется небольшой лежащий рядом модуль, чтобы было удобнее работать с изображением.
- После развертывания виртуальной машины из образа можно начинать проверки.
В основном проверки проводятся на автомобиле.
Он проверяет, как работали скрипты при запуске и как работают демоны.
Для этого через ssh или winrm авторизуемся на только что поднятой машине и проверяем статус конфигурации и работоспособность служб.
- Упаковщик должен сначала полностью подготовить изображение.
- Аналогичная ситуация и с интеграционными тестами в модулях для terraform. Вот краткая таблица, поясняющая особенности таких тестов.
Обратная связь по конвейеру составляет около 40 минут. Все происходит очень долго.Его можно использовать для регресса, но для новых разработок это вообще нереально.
Если вы к этому очень и очень подготовлены, подготовите скрипты запуска, то можно сократить это время до 10 минут. Но это всё же не Unit-тесты, которые делают 100 штук за 5 секунд.
Например, нам нужно было сделать так, чтобы при запуске виртуальной машины она регистрировалась в сервисе.
МасштабFT , а когда виртуальная машина была уничтожена, она удалила себя.
Поскольку ScaleFT у нас есть как сервис, мы вынуждены работать с ним через API. Там была написана обертка, которую можно было потянуть и сказать: «Зайди и удали то и это».
В нем хранятся все необходимые настройки и доступы.
Мы уже можем писать для этого нормальные тесты, так как от обычного ПО оно ничем не отличается: мокается какая-то апиха, ты её дергаешь, и смотришь, что получится.
Результаты тестов: Юнит-тестирование, которое должно через минуту выдать ОС, не дает. А виды тестирования выше в пирамиде эффективны, но покрывают лишь часть проблем.
Парное программирование
Тесты - это, конечно, хорошо.Их можно написать много, они могут быть разных типов.
Они будут работать на своем уровне и давать нам обратную связь.
Но проблема с плохими модульными тестами, которые выдают самую быструю ОС, остается.
При этом мне все равно хочется быструю ОС, с которой легко и приятно работать.
Не говоря уже о качестве полученного решения.
К счастью, существуют методы, которые могут обеспечить еще более быструю обратную связь, чем модульные тесты.
Это парное программирование.
При написании кода хочется как можно быстрее получить обратную связь о его качестве.
Да, вы можете написать все в фиче-ветке (чтобы никому ничего не сломать), сделать пул-реквест в Github, назначить его тому, чье мнение имеет вес, и ждать ответа.
Но ждать можно долго.
Люди все заняты, и ответ, даже если он и будет, может быть не самого высокого качества.
Предположим, что ответ пришел сразу, рецензент мгновенно понял всю идею, но ответ все равно приходит с опозданием, постфактум.
Я бы хотел, чтобы это было раньше.
Именно на это и нацелено парное программирование – сразу, на момент написания статьи.
Ниже представлены стили парного программирования и их применимость при работе над IaC: 1. Классический, Опытный+Опытный, сдвиг по таймеру.
Две роли – водитель и штурман.
Два человека.
Они работают над одним и тем же кодом и меняются ролями через определенный заранее заданный промежуток времени.
Давайте рассмотрим совместимость наших проблем со стилем:
- Проблема: несовершенство инструментов и средств разработки кода.
Негативное влияние: на разработку уходит больше времени, мы тормозим, сбивается темп/ритм работы.
Как боремся: используем другой инструментарий, общую IDE, а также изучаем ярлыки.
- Проблема: медленное развертывание.
Негативное влияние: увеличивается время создания работающего фрагмента кода.
Нам скучно в ожидании, руки тянутся заняться чем-то другим, пока мы ждем.
Как мы боремся: мы не преодолели это.
- Проблема: отсутствие подходов и практик.
Негативное воздействие: нет знаний, как сделать хорошо и как сделать плохо.
Удлиняет получение обратной связи.
Как мы боремся: взаимный обмен мнениями и практиками в парной работе практически решает проблему.
При традиционной разработке программного обеспечения движение происходит очень равномерно.
Можно потратить пять минут и написать Н.
Потратьте 10 минут и напишите 2Н, 15 минут — 3Н.
Здесь можно потратить пять минут и написать N, а потом потратить еще 30 минут и написать десятую часть N. Здесь ты ничего не знаешь, ты застрял, тупой.
Расследование отнимает время и отвлекает от самого программирования.
Вывод: в чистом виде он нам не подходит.2. Пинг-понг.
Этот подход предполагает, что один человек пишет тест, а другой выполняет его реализацию.
С учетом того, что с Unit-тестами все сложно, и приходится писать интеграционный тест, который занимает много времени на программирование, вся легкость пинг-понга уходит. Могу сказать, что мы попробовали разделить обязанности по разработке тестового скрипта и реализации кода для него.
Сценарий придумал один участник, в этой части работы он был ответственным, за ним было последнее слово.
А другой отвечал за реализацию.
Все получилось хорошо.
Качество сценария при таком подходе повышается.
Вывод: увы, темпы работы не позволяют использовать пинг-понг в качестве практики парного программирования в IaC.3.Сильный стиль.
Идея в том, что один участник становится навигатором директив, а второй берет на себя роль драйвера исполнения.
В этом случае право принятия решений остается исключительно за штурманом.
Драйвер только печатает и может словом влиять на происходящее.
Роли долго не меняются.
Хорошо подходит для обучения, но требует сильных мягких навыков.
Вот тут мы и запнулись.
Техника была сложной.
И дело даже не в инфраструктуре.
Вывод: потенциально можно использовать, мы не оставляем попыток.4. Моббинг, роение и все известные, но не перечисленные стили.
Мы это не рассматриваем, т.к.
не пробовали и говорить об этом в контексте нашей работы невозможно.
Общие результаты по использованию парного программирования:5. Несмотря на это, успехи были.
- У нас неравномерный темп работы, что сбивает с толку.
- Мы столкнулись с недостаточно хорошими мягкими навыками.
И предметная область не помогает преодолеть эти наши недостатки.
- Длительные тесты и проблемы с инструментами затрудняют парную разработку.
Мы придумали свой метод «Схождение-Расхождение».
Кратко опишу, как это работает. У нас есть постоянные партнеры на несколько дней (меньше недели).
Мы вместе делаем одно задание.
Некоторое время сидим вместе: один пишет, другой сидит и наблюдает за командой поддержки.
Потом мы на какое-то время расходимся, каждый делает какие-то самостоятельные дела, потом снова собираемся вместе, очень быстро синхронизируемся, делаем что-то вместе и снова расходимся.
Планирование и общение
Последний блок практик, с помощью которых решаются проблемы ОС, — это организация работы с самими задачами.Сюда же относится и обмен опытом, выходящий за рамки парной работы.
Давайте рассмотрим три практики: 1. Цели через дерево целей.
Общее управление проектом мы организовали через дерево, уходящее бесконечно в будущее.
Технически отслеживание осуществляется в Миро.
Есть одна задача – это промежуточная цель.
Из него идут либо более мелкие цели, либо группы задач.
От них исходят сами задачи.
Все задачи создаются и поддерживаются на этой доске.
Эта схема также обеспечивает обратную связь, которая происходит раз в день, когда мы синхронизируемся на митингах.
Наличие общего плана перед всеми, но структурированного и полностью открытого, позволяет каждому быть в курсе того, что происходит и насколько далеко мы продвинулись.
Преимущества визуального видения задач:
- Причинность.
Каждая задача ведет к какой-то глобальной цели.
Задачи группируются в более мелкие цели.
Сфера инфраструктуры сама по себе весьма техническая.
Не всегда сразу понятно, какое конкретное влияние оказывает на бизнес, например, написание runbook по переходу на другой nginx. Наличие целевой карты рядом делает задачу более понятной.
Причинность — важное свойство проблем.Оно напрямую отвечает на вопрос: «Правильно ли я поступаюЭ»
- Параллелизм.
Нас девять человек, и бросить всех на одну задачу просто физически невозможно.
Заданий из одной области тоже не всегда может быть достаточно.
Мы вынуждены распараллеливать работу между небольшими рабочими группами.
При этом группы некоторое время сидят над своим заданием, их может подкрепить кто-то другой.
Иногда люди отпадают из этой рабочей группы.
Кто-то уходит в отпуск, кто-то делает доклад на DevOps конфу, кто-то пишет статью на Хабре.
Знание того, какие цели и задачи можно решать параллельно, становится очень важным.
На стендапах у нас есть такая проблема — люди параллельно выполняют множество задач.
Иногда задачи слабо связаны и нет понимания, кто что делает. И мнение другого члена команды очень важно.
Это дополнительная информация, которая может изменить ход решения проблемы.
Конечно, обычно с вами кто-то есть, но советы и подсказки всегда полезны.
Чтобы исправить эту ситуацию, мы использовали методику «Смена ведущего в стендапе».
Теперь они ротируются по определенному списку, и это дает свой эффект. Когда приходит ваша очередь, вы вынуждены погрузиться в работу и понять, что происходит, чтобы провести хорошее Scrum-совещание.
3. Внутренняя демонстрация.
Помощь в решении задачи по парному программированию, визуализация по дереву задач и помощь на scrum-совещаниях по утрам — это хорошо, но не идеально.
Вы как пара ограничены только своими знаниями.
Дерево задач помогает глобально понять, кто чем занимается.
А ведущий и коллеги на утренней встрече не будут глубоко погружаться в ваши проблемы.
Они наверняка могут что-то упустить.
Решение было найдено в демонстрации проделанной работы друг другу и последующем ее обсуждении.
Встречаемся раз в неделю на час и показываем детали решения задач, которые сделали за прошедшую неделю.
В ходе демонстрации необходимо раскрыть детали задачи и обязательно продемонстрировать ее работу.
Отчет можно составить с использованием контрольного списка.
1. Войдите в контекст. Откуда взялась задача, зачем она вообще была нужна? 2. Как решалась проблема раньше? Например, требовалось массированное нажатие мыши или вообще невозможно было что-либо сделать.
3. Как мы его улучшаем.
Например: «Смотрите, сейчас есть скриптосик, вот ридми».
4. Покажите, как это работает. Целесообразно напрямую реализовать какой-нибудь пользовательский сценарий.
Я хочу Х, делаю Y, вижу Y (или Z).
Например, разворачиваю NGINX, курю урл и получаю 200 ОК.
Если действие продолжительное, подготовьте его заранее, чтобы потом можно было показать.
Желательно не ломать его слишком сильно за час до демо, если он хрупкий.
5. Объясните, насколько успешно решена задача, какие трудности остались, что не выполнено, какие улучшения возможны в будущем.
Например, сейчас CLI, потом будет полная автоматизация в CI. Каждому выступающему желательно выдерживать 5-10 минут. Если ваше выступление заведомо важное и займет больше времени, согласуйте это заранее в канале sre-takeover. После очной части всегда происходит обсуждение в ветке.
Именно здесь появляется необходимая нам обратная связь по нашим задачам.
В результате проводится опрос для определения полезности происходящего.
Это обратная связь по сути выступления и важности задания.
Длинные выводы и что дальше
Может показаться, что тон статьи несколько пессимистичен.Это не верно.
Работают два нижних уровня обратной связи, а именно тесты и парное программирование.
Не так идеально, как при традиционной разработке, но положительный эффект от этого есть.
Тесты в их нынешнем виде обеспечивают лишь частичное покрытие кода.
Многие функции конфигурации остаются непроверенными.
Их влияние на реальную работу при написании кода невелико.
Однако эффект от интеграционных тестов есть, и они позволяют безбоязненно проводить рефакторинг.
Это большое достижение.
Также со смещением фокуса на разработку на языках высокого уровня (питон у нас есть, го) проблема уходит. И для «клея» не нужно много проверок; достаточно общей проверки интеграции.
Работа в паре больше зависит от конкретных людей.
Есть фактор задачи и наши мягкие навыки.
У кого-то это получается очень хорошо, у кого-то хуже.
Польза от этого определенно есть.
Понятно, что даже при недостаточном соблюдении правил парной работы сам факт совместного выполнения задач положительно влияет на качество результата.
Лично мне работать в паре легче и приятнее.
Более высокоуровневые способы воздействия на ОС — точное планирование и работа с задачами дают эффекты: качественный обмен знаниями и повышение качества разработки.
Короткие выводы в одну строку
- HR-практики работают в IaC, но с меньшей эффективностью.
- Укрепляйте то, что работает.
- Придумайте свои собственные компенсаторные механизмы и практики.
-
Гепарды
19 Oct, 24 -
5 Пищевых Устройств И Робот С Помидорами
19 Oct, 24 -
Стартап - Это Диагноз :)
19 Oct, 24 -
Новое Расширение "Лекз Ридер"
19 Oct, 24 -
Вечер Пятницы. Пришло Время Улыбаться!
19 Oct, 24
