[Программирование, DevOps, Облачные сервисы] Проблемы в процессах непрерывной доставки и развертывании программного продукта

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 2 месяца
Сообщений: 27286

news_bot ^® написал(а)
04-Авг-2020 17:31

Цитировать

Статью подготовил Брюханов Константин, руководитель курса «CI/CD». В ней Константин раскрыл ряд проблемных моментов, связанных доставкой развертыванием кода программного продукта в IT-компаниях, и собрал рекомендации из числа лучших международных практик.
В айти-эксплуатации самым востребованным направлением является именно наладка и обеспечение непрерывной доставки и развертывания. Технологии и методологии постоянно развиваются, совершенствуются инструменты. В связи с этим последние требования к доставке и развертыванию включают в себя готовность и непрерывность тестирования изменений, подготовку и настройку тестовой среды для команды обеспечения качества.
Технологический прорыв и свободно-распространяемое ПО привели к тому, что подход к организации процессов CI/CD значительно изменился. Переход на новые принципы сильно повлиял на корпоративную культуру, востребованные навыки сотрудников и сами принципы работы в организациях, что привело к масштабным переменам в мире разработки ПО.
Облачные решения становятся все более приоритетными. Для непрерывной поставки ПО необходимо эффективное взаимодействие групп разработки, тестирования и эксплуатации, а облачная среда отлично подходит для такого взаимодействия.
Однако этап развертывания, выполняемый в сложной распределенной топологии, подвержен ошибкам и, как правило, требует ручного поиска и устранения неисправностей. Этап развертывания продуктов в рамках процесса непрерывной поставки часто создает узкие места и отрицательно влияет на эффективность процесса DevOps.
Непрерывная поставка позволяет достичь автоматизации тестирования инкрементальных изменений ПО и оперативного развертывания обновлений максимально эффективными и безопасными методами. Такой подход дает пользователям уверенность, что в производственной среде используется самая свежая версия кода, и изменения, вносимые программистами, могут попадать к клиентам за считанные часы или даже минуты.
Рассмотрим наиболее общий сценарий реализации CI/CD в проекте:

Команда разработки выпускает новую версию продукта (новый функционал или исправление ошибок предыдущего релиза).
Сервис непрерывной интеграции (CI) проверяет новый код рядом тестов, включающих несколько уровней тестирования, такие как синтаксические, модульные и регрессионные тесты.
В случае успеха сервис непрерывной интеграции готовит новую сборку программного продукта и совершает системный вызов к сервису, осуществляющему непрерывную доставку (CD).
Совместно с сервисом непрерывного развертывания (часто, этот функционал выполняет один и тот же сервис) автоматическим образом поднимается сущность, отвечающая за промежуточное развертывание (staging), где в условиях близких к производственным проводятся дополнительные интеграционные, дымовые и нагрузочные тесты.
После успешного проведения stage-тестов система CI/CD доставляет новую версию продукта на производственные мощности, где выполняется бесшовное развертывание параллельной инсталляции продукта.
Пользовательский трафик переключается на новую версию ПО.

Данный сценарий является наиболее общим и покрывает большинство нужд команд разработки и эксплуатации, но всё же имеет некоторые проблемы, например:

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

Стоит заметить, что перечисленные выше проблемы могут возникнуть даже в близкой к идеальной среде, но одна из основных сложностей внедрения методологии DevOps состоит в том, что нет единой картины, как должен выглядеть процесс непрерывной доставки и развертывания продукта. Многие IT-компании знают о DevOps слишком мало, иногда и вовсе не понимают этой методологии, в других же уже есть исторически сложившиеся решения, поверх которых приходится выстраивать новые процессы. С учетом высоких требований к квалификации Devops-специалистов, и их нехваткой на рынке труда работодатель зачастую вынужден использовать уже имеющиеся у него ресурсы и отдавать Devops-задачи начинающим инженерам. Как итог, в системе получается еще больше слабых мест.
При использовании CI/CD без правильного понимания методологии, без аналитического подхода к построению инфраструктуры и методов доставки кода вытекают следующие проблемы:
1. Человеческий фактор. Первый и самый существенный риск связан с человеческим фактором. Представим себе ситуацию, когда необходимо настроить ещё несколько серверов, аналогичных существующим. Если специалист, который производил предыдущие установки или настройки в данный момент недоступен по каким-либо причинам (болен, уволился и т.д.) и не подготовил подробных инструкций, то ситуация значительно осложняется. В этом случае каждый новый специалист должен изучить весь процесс настройки сервера полностью, при этом у него нет права на ошибку. А кроме того, нельзя точно оценить, сколько времени уйдет на настройку, и гарантировать ее успех.
Сюда же относятся риски связанные с тем, что автор метода допустил ошибку, забыл покрыть тестами процессы или просто-то что-то не учел, а его преемник этого не заметил.
Не стоит также забывать, что нередко в компаниях разрабатываются несколько проектов, а отдел IT-эксплуатации обычно один, и один инженер эксплуатации обслуживает несколько проектов. Если нет единой схемы и концепции, то процессы в разных командах будут выстроены по-разному, что значительно затруднит последующее развитие Devops в компании и сделает высокий порог вхождения инженера эксплуатации в другой проект, где уже используются процессы, отличные от тех, с которыми он работал ранее.
2. Неидемпотентные сценарии. Идемпотентность является важнейшим атрибутом сценариев непрерывной доставки и развертывания кода особенно в условиях развертывания инфраструктуры. Инженер должен быть уверен, что каждый раз при выполнении сценариев результат будет однозначно гарантированным, ожидаемым и неизменным при повторном проигрывании того же сценария. Зачастую при внедрении Devops в компании инженеры стараются разработать бизнес-решение и могут не учесть идемпотентность или же просто не знать об этом требовании. В этом случае компания получает бомбу замедленного действия, т.к. существует вероятность доставить на производственные мощности неожидаемый код. Например, если кто-то обновил модуль системы управления конфигурациями для одного проекта, и тем самым повлиял на остальные, где этого не ожидают.
3. Хранение чувствительных данных и организация доступа. Один из самых важных моментов в Devops-подходе к хранению секретных данных, ограничению прав, организации сетевого и пользовательского доступа. До сих пор нет единых принятых практик и инструментов, позволяющих решить эту проблему, и инженерам приходится каждый раз проводить исследования в зависимости от текущей организации инфраструктуры и принятых методов ограничения доступа. По этой причине внедрение методологии Devops на предприятии усложняется тем, что нельзя однозначно найти решение под свой частный случай, а применение чужих практик не всегда гарантирует безопасность.
4. Определенная модель бюджетирования, более подходящая для Waterfall методологии.
5. Высокие требования к безопасности. Следовательно, невозможно разместить инфраструктуру национальных IT-проектов в зоне ответственности коммерческих, иностранных компаний, например, Amazon, Microsoft.
6. Большой объем «legacy code», «legacy infrastructure», которые необходимо поддерживать. Необходимость интеграции с большим количеством устаревших систем.
Таким образом процесс построения Devops на предприятии может сопровождаться рядом проблем и не всегда решать задачи, для которых создан.
Первым важным шагом является отказ от отношения к серверам, как трудно настраиваемому, уникальному элементу инфраструктуры, переход от ручной настройки сервера к автоматизированному, централизованному управлению инфраструктурой. Процесс настройки каждого сервера должен быть описан в виде конфигурации, легко читаемой, изменяемой, и готовой к многократному безопасному переиспользованию, обеспечивающему однозначный гарантированный результат. Примерами промышленных систем-оркестраторов являются Chef или Ansible. Данные системы позволяют управлять большим количеством серверов с минимальными затратами.
Следующим важным шагом является применение автоматизированного тестирования, чтобы для как можно большего покрыть функционал разрабатываемого кода (как программного, так и инфраструктурного). Иначе говоря, имея развернутую инфраструктуру, но без автоматизированного тестирования, узким местом процесса разработки будет своевременная проверка функционала. Автоматизирование процесса тестирования должно начинаться с собственно написания кода ПО (модульное тестирование), применения первичных тестов на сервере, который отвечает за сборку ПО, а также тест конфигурации серверов. Это позволит снизить нагрузку на команду обеспечения качества ПО и значительно снизит время прохождения ПО на конвейере.
Заключительным логичным шагом является централизованный сбор и анализ лог-файлов со всех серверов для своевременного оповещения всех заинтересованных лиц и проактивном наблюдении за состоянием инфраструктуры в целом.
Приведенные выше рекомендации позволят построить устойчивую масштабируемую инфраструктуру, способную работать в интенсивном процессе разработки. Внедрение DevOps требует вовлеченности в процесс каждого участника от отделов тестирования и разработки до менеджеров и отдела эксплуатации. На каждом этапе требуется постоянный ретроспективный анализ процесса, ведь в результате случайных ошибок при изменении конфигурации полностью останавливается работа систем. Необходимо улучшать телеметрию, чтобы эффективнее обнаруживать ошибки и осуществлять восстановление, а так же для защиты конвейера развертывания и достижения целей по изменению управления. Это позволит получать максимальную поддержку со стороны руководства при внедрении инициатив DevOps, создать более оживленную и дружелюбную рабочую среду, чтобы любой участник смог учиться в течение всего времени — это не только поможет каждому исполнителю достичь целей, но и приведет организацию к успеху.
За 3 месяца на нашем онлайн-курсе «CI/CD» вы сформируете понимание архитектуры облачных провайдеров, изучите автоматизацию анализа кода и поиска уязвимостей и научитесь настраивать процессы сборки, тестирования и установки приложения от трех крупнейших провайдеров. Программа рассчитана на специалистов с опытом администрирования — специальный вступительный тест поможет сориентироваться, хватит ли вам подготовки для обучения.
Читать ещё:

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_programmirovanie (Программирование), #_devops, #_oblachnye_servisy (Облачные сервисы), #_ci/cd, #_devops, #_oblachnye_servisy (облачные сервисы), #_analiz_koda (анализ кода), #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_programmirovanie (
Программирование
), #_devops, #_oblachnye_servisy (
Облачные сервисы
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 28-Апр 03:49
Часовой пояс: UTC + 5