Как практиковать DevOps

Шаг 1. Выберите компонент

Первый шаг — начать с малого. Выберите компонент, который в настоящее время находится в рабочей среде. Идеальный вариант — компонент с простой базой кода, небольшим количеством зависимостей и минимальной инфраструктурой. Он станет опытным полигоном, на котором команда приобретет первый опыт внедрения DevOps.

Шаг 2. Рассмотрите возможность внедрения гибкой методологии, например Scrum

DevOps часто сочетается с методологией гибкой работы, например со Scrum. Нет необходимости внедрять все обычаи и практики, связанные со Scrum. Три элемента scrum, которые, как правило, легко внедряются и быстро приносят пользу, — это бэклог, спринт и планирование спринта.

Команда DevOps может добавлять работу и определять ее приоритет в бэклоге Scrum, а затем переносить часть этой работы в спринт — фиксированный промежуток времени для выполнения определенного объема работы. Планирование спринта — это процесс принятия решения о том, какие задачи должны быть переданы из бэклога в следующий спринт.

Шаг 3. Используйте систему управления версиями на основе Git

Контроль версий — передовая практика DevOps, которая повышает эффективность совместной работы и ускоряет циклы релизов. Такие инструменты, как Bitbucket, позволяют разработчикам вести совместную работу, обмениваться ее результатами, объединять программный код и создавать его резервные копии.

Выберите модель ветвления. Краткий обзор этого понятия приводится в этой статье. Рабочий процесс GitHub — отличная отправная точка для команд, не имеющих опыта работы с Git, поскольку он прост для понимания и реализации. Зачастую выбор делается в пользу магистральной разработки, однако она требует большей дисциплины и затрудняет первые шаги в Git.

Шаг 4. Объедините управление версиями с отслеживанием работы

Объедините инструмент управления версиями с инструментом отслеживания работы. Когда все, что относится к конкретному проекту, собрано в одном месте, это экономит много времени разработчикам и руководству. Ниже приводится пример задачи Jira с обновлениями из репозитория системы управления версиями на основе Git. В задачах Jira есть раздел Development (Разработка), где собраны данные о работе, проделанной для решения задачи Jira в системе управления версиями. В показанной ниже задаче была одна ветка, шесть коммитов, один запрос pull и одна сборка.

Шаг 5. Напишите тесты

Для конвейеров CI/CD необходимы тесты, чтобы проверить правильность работы кода, развернутого в различных средах. Начните с написания модульных тестов для кода. В идеале предполагается покрытие кода на 90 процентов, однако на начальном этапе это нереально. Установите низкий базовый уровень покрытия и постепенно наращивайте его для модульных тестов. Для этого можно добавлять рабочие задачи в бэклог.

Применяйте разработку на основе тестирования при исправлении багов, обнаруженных в готовом коде. Когда находите баг, пишите модульные тесты, интеграционные тесты и (или) системные тесты, которые выдают результат «не пройдено» в средах, где существует этот баг. Затем исправляйте баг и проверяйте, успешно ли проходят тесты. Со временем этот процесс приведет к органическому увеличению охвата кода. Если баг обнаруживается в тестовой или промежуточной среде, тесты гарантируют, что при переходе в рабочую среду код будет функционировать правильно.

Поначалу это трудозатратно, однако важно. Тестирование позволяет командам увидеть влияние изменений кода на поведение системы, прежде чем конечные пользователи почувствуют эти изменения на себе.

Модульные тесты

Модульные тесты используются для проверки правильности исходного кода и должны выполняться в качестве одного из первых шагов в конвейере CI/CD. Разработчики должны писать тесты для развертываний в «зеленой» среде, проблемных входных данных и известных тупиковых ситуаций. При написании тестов разработчики могут имитировать входные данные и ожидаемые результаты.

Интеграционное тестирование

С помощью интеграционных тестов проверяется правильность взаимодействия двух компонентов друг с другом. Сымитируйте входные данные и ожидаемые результаты. Эти тесты — один из первых шагов в конвейере CI/CD перед развертыванием в любой среде. Чтобы эти тесты заработали, обычно необходим больший объем имитации, чем для модульных тестов.

Системные тесты

Системные тесты нужны, чтобы проверить комплексную эффективность системы и удостовериться, что она функционирует ожидаемым образом в каждой среде. Сымитируйте входные данные, которые может получить компонент, и запустите систему. Убедитесь, что система возвращает необходимые значения и правильно обновляет остальные свои части. Эти тесты следует запускать после развертывания в каждой среде.

Шаг 6. Создайте процесс CI/CD для развертывания компонента

При создании конвейера CI/CD рассмотрите возможность развертывания в нескольких средах. Если команда создает конвейер CI/CD, который выполняет развертывание только в одной среде, все будет жестко закодировано. Важно создавать конвейеры CI/CD для инфраструктуры и кода. Начните с создания конвейера CI/CD для развертывания необходимой инфраструктуры в каждой среде. Затем создайте еще один конвейер CI/CD для развертывания кода.

Структура конвейера

Этот конвейер начинается с запуска модульных и интеграционных тестов перед развертыванием в тестовой среде. Системные тесты выполняются после развертывания в среде.

Инфраструктура

Различия в инфраструктуре между средами затрудняют правильное выполнение программного обеспечения, работающего в этой среде. Для надлежащего выполнения ПО правила брандмауэра, пользовательские права, доступ к базе данных и другие компоненты уровня инфраструктуры должны находиться в известной конфигурации. Правильно повторить развертывание инфраструктуры вручную может быть сложно. Поскольку этот процесс включает множество этапов, попытка по памяти выполнить каждый шаг в правильном порядке с правильными параметрами может привести к ошибкам. Для устранения этих и других проблем инфраструктура должна быть определена в коде везде, где это возможно.

Определить инфраструктуру в коде можно с помощью различных инструментов, в том числе AWS CloudFormation, Terraform, Ansible, Puppet или Chef.

Напишите несколько конвейеров для развертывания инфраструктуры. Как и при написании кода, развертывание инфраструктуры полезно выполнять в виде модулей. По возможности разбивайте необходимую инфраструктуру на непересекающиеся подмножества. Предположим, что A, B, C и D — это абстрактное представление компонентов инфраструктуры, которые могут зависеть друг от друга. Например, A — экземпляр EC2, а B — корзина S3. Зависимости, в которых компонент инфраструктуры A — и только A — зависит от компонента B, скорее всего, должны находиться вместе в одном конвейере CI/CD. Зависимости, в которых A, B и C зависят от D, но независимы между собой, должны разбиваться на несколько конвейеров CI/CD. В этом случае создаются четыре независимых конвейера. В данном примере необходимо создать один конвейер для D, от которого зависят все три других компонента, и по одному конвейеру для A, B и C.

Программирование

Конвейеры CI/CD создаются для развертывания кода. Как правило, их просто реализовать, поскольку инфраструктура уже существует благодаря предшествующей работе. Здесь важны тестирование, повторяемость и возможность восстановления после неудачных развертываний.

Повторяемость — это возможность развертывать одно и то же изменение без ущерба для системы. Развертывание должно быть повторяемым и идемпотентным. Оно должно приводить систему в известную конфигурацию, а не применять модификатор к существующему состоянию. Применение модификатора нельзя повторить, так как после первого развертывания начальное состояние модификатора, необходимое для его правильной работы, изменится.

Простой пример неповторяющегося обновления — обновление файла конфигурации путем добавления в него данных. Не добавляйте строки в файлы конфигурации и не используйте подобный метод модификации. Если обновления выполняются путем добавления, в файле конфигурации могут оказаться десятки повторяющихся строк. Вместо этого замените файл конфигурации правильно записанным файлом из системы управления версиями.

Этот принцип также необходимо применять к обновлению баз данных. Обновление базы данных может быть сложным и требовать внимания к деталям. Крайне важно сделать процесс повторяемым и отказоустойчивым. Создавайте резервные копии непосредственно перед внесением изменений, чтобы обеспечить возможность восстановления.

Еще один вопрос заключается в том, как провести восстановление после неудачного развертывания. Развертывание завершилось неудачей, и система перешла в неизвестное состояние, либо развертывание прошло удачно, но сработали сигналы тревоги, и начали поступать заявки на устранение неполадок. Есть два основных способа решения этой проблемы. Первый способ —выполнить откат. Второй способ —использовать флажки возможностей и отключить некоторые из них, чтобы вернуться к заведомо рабочему состоянию. Дополнительные сведения о флажках возможностей приводятся в шаге 8 в этой статье.

Откат позволяет вернуться к известному рабочему состоянию в среде после обнаружения неудачного развертывания. Это необходимо планировать в самом начале. Прежде чем делать что-то с базой данных, создайте резервную копию. Убедитесь, что можно быстро развернуть предыдущую версию кода. Регулярно тестируйте процесс отката в тестовой или промежуточной средах.

Шаг 7. Добавьте мониторинг, сигналы тревоги и инструментарий

Команде DevOps необходимо отслеживать поведение запущенного приложения в каждой среде. Есть ли ошибки в журналах? Истекает ли время ожидания запросов к API? Происходят ли сбои в базах данных? Отслеживайте проблемы в каждом компоненте системы. Если в процессе наблюдения выявляется проблема, создайте заявку на устранение неполадки, чтобы кто-нибудь мог ее решить. В рамках решения напишите дополнительные тесты, которые могут выявить проблему.

исправление ошибок

Отслеживание проблем и их решение — это часть работы по эксплуатации программного обеспечения в рабочей среде. Команда с культурой DevOps отвечает за работу программного обеспечения и заимствует обязанности инженера по техническому обеспечению надежности сайта (SRE). Проведите анализ первопричин проблемы, напишите тесты, чтобы ее выявить, устраните ее и убедитесь, что теперь тесты выполняются успешно. Этот процесс поначалу часто требует больших трудозатрат, но в долгосрочной перспективе оправдывает себя, поскольку сокращает технический долг и обеспечивает операционную гибкость.

Оптимизация производительности

После наладки базового мониторинга состояния следующим часто выполняемым шагом становится настройка производительности. Проанализируйте работу каждой части системы и оптимизируйте запаздывающие части. Как отмечал Кнут, «преждевременная оптимизация — корень зла». Не оптимизируйте производительность всего подряд. Позаботьтесь только о самых медленных и дорогостоящих частях. Выявить такие компоненты можно с помощью мониторинга.

Шаг 8. Используйте флажки возможностей, чтобы выполнять канареечное тестирование

Чтобы обеспечить возможность канареечного тестирования, оберните каждую новую функцию во флажок возможности со списком разрешенных, в который входят тестовые пользователи. Код новой функции будет выполняться только для пользователей из списка разрешенных после развертывания в среде. Дайте новой функции как следует поработать в одной среде, прежде чем переносить ее в другую. Пока новая функция используется в какой-либо области, следите за показателями, сигналами тревоги и другими признаками, чтобы выявить проблемы. В частности, обратите внимание на рост количества новых заявок на устранение неполадок.

Устраните проблемы в одной среде, прежде чем передавать код в другую. Проблемы, обнаруженные в рабочих средах, следует решать так же, как и в тестовых или промежуточных средах. Как только вы определите первопричину проблемы, напишите тесты, чтобы выявить проблему, внесите исправление, проверьте успешность тестов и распространите исправление через конвейер CI/CD. При внедрении изменения в среде, в которой была обнаружена проблема, новые тесты будут пройдены и количество заявок на устранение неисправностей снизится.