Что такое devops для чайников
Принципы и культура DevOps: руководство для начинающих
Примечание — Это адаптированный перевод статьи Beginner’s Guide into the field of DevOps Адита Моди, инженера по облачных сервисам и энтузиаста DevOps. Повествование ведётся от лица автора оригинала.
Что общего у компаний Flipkart, Amazon, Spotify, Netflix, Hotstar и Uber, кроме того, что все они — технологические гиганты с оборотами в миллиарды долларов? Все они строят бизнес на разработке программного обеспечения (ПО). Почему эти компании успешнее, чем их конкуренты? Они выстроили процессы так, что могут решить любые технические проблемы за считанные минуты и выпускать обновления, не прекращая процесс тестирования и разработки. Как им это удалось? Основа их технического успеха — использование методологии DevOps. Она помогает автоматизировать процессы, повысить их эффективность и сократить время на внедрение изменений или решение технических проблем.
Наверное вы подумали, что внедрение DevOps могут позволить себе только гиганты. Позвольте возразить — это не дорого, если учесть, какую выгоду DevOps может принести компании в долгосрочной перспективе. DevOps — это сочетание культурных принципов, подходов и инструментов, которые увеличивают скорость создания приложений и сервисов. Методология помогает ускорить разработку и оптимизацию продуктов по сравнению с традиционными процессами создания софта и управления инфраструктурой. DevOps повышает качество обслуживания клиентов и помогает компании эффективнее конкурировать на рынке.
Почему важен DevOps
Софт и интернет преобразили мир и все его сферы — от шопинга и развлечений до банковского дела. Теперь приложения не просто поддерживают бизнес — они становятся неотъемлемой его частью на каждом этапе. С помощью программ компании взаимодействуют с клиентами и повышают эксплуатационную эффективность, преобразуя каждое звено цепочки создания стоимости: логистику, коммуникации и эксплуатацию.
На протяжении XX века промышленные производители товаров меняли подход к проектированию, производству и доставке продуктов благодаря промышленной автоматизации. Теперь современным компаниям необходимо переосмыслить и изменить подход к созданию и распространению программного обеспечения.
Преимущества DevOps
Скорость
DevOps ускоряет внедрение новых функций для клиентов, позволяет лучше адаптироваться к изменениям рынка и эффективнее достигать целей, которые стоят перед бизнесом. Например, микросервисный подход и непрерывная доставка кода помогают командам быстрее брать сервис под контроль и оперативнее обновлять его.
Быстрое обновление
Увеличьте частоту и скорость релизов, чтобы быстрее обновлять и улучшать продукт. С одной стороны, это позволяет оперативно реагировать на потребности клиентов, с другой — создает дополнительные конкурентные преимущества. Практики непрерывной интеграции и непрерывной доставки (их суть объясню ниже) помогают автоматизировать процесс выпуска релизов, от сборки до развертывания.
Надежность
Контролируйте качество обновлений и изменений инфраструктуры — такой подход сделает продукт надежнее и поможет сохранить лояльность пользователей. Практики непрерывной интеграции и непрерывной доставки позволяют проверить каждое обновление на работоспособность и безопасность. А мониторинг и ведение журналов — следить за производительностью в режиме реального времени.
Масштабируемость
DevOps упрощает управление разработкой и поддержку инфраструктуры: это обеспечивает стабильную работу софта при любых масштабах и помогает контролировать сложные системы с минимальными рисками. Например, практика «инфраструктура как код» повышает эффективность управления средами разработки, тестирования и производства, а также обеспечивает их воспроизводимость.
Интенсив по DevOps: На Хекслете есть большая программа «DevOps для программистов». Подробнее почитать о ней можно тут.
Оптимизация совместной работы
Культурная модель DevOps предполагает сопричастность и ответственность: это означает, что команды разработки и эксплуатации работают в тесном контакте друг с другом, разделяют большинство обязанностей и объединяют свои рабочие процессы. Такой подход повышает эффективность работы и экономит время: разработчики быстрее передают дела инженерам по эксплуатации, а при написании кода не приходится ориентироваться на среду, в которой он будет запущен.
Практики DevOps
Непрерывная интеграция (CI)
Это практика разработки, при которой все изменения в коде регулярно объединяют в центральном репозитории, где происходит автоматическая сборка и тестирование. Ключевая задача непрерывной интеграции — быстрее находить и исправлять ошибки, повышать качество продукта и сокращать время на проверку и выпуск обновлений.
Непрерывная доставка (CD)
Еще одна практика разработки, в соответствии с которой при любых изменениях в коде выполняется автоматическая сборка, тестирование и подготовка к окончательному выпуску. Непрерывная доставка расширяет практику непрерывной интеграции за счет того, что все изменения кода после стадии сборки развертываются в тестовой и в рабочей среде. Если практика реализована верно, у разработчиков всегда будет готовая к развертыванию версия продукта, прошедшая стандартизированную процедуру тестирования.
Микросервисная архитектура (MA)
Это подход к разработке, который предполагает создание приложения из набора небольших сервисов. Каждый сервис отвечает за отдельно взятый процесс и обменивается данными с другими службами через программный интерфейс на базе HTTP (API). Сервисы привязаны к целям бизнеса — каждый из них решает отдельно взятую задачу. Для их написания используют разные среды или языки программирования, а развертывать их можно независимо — по одному или группой.
Инфраструктура как код (IaC)
Это практика DevOps, при которой управление инфраструктурой происходит с помощью кода и методов разработки — управления версиями и непрерывной интеграции. Облачная модель на основе API позволяет разработчикам и системным администраторам взаимодействовать с инфраструктурой на программном уровне при любом масштабе, вместо того, чтобы устанавливать и настраивать ресурсы вручную.
Такой подход позволяет инженерам работать с инфраструктурой так же, как они работают с кодом приложения. Это позволяет быстро развернуть инфраструктуру и серверы или установить на них последние обновления.
Управление конфигурациями (CM)
Разработчики и системные администраторы пользуются кодом, чтобы автоматизировать настройку операционной системы и хоста, или выполнить эксплуатационные задачи.
Эта практика делает изменение конфигурации более воспроизводимым и стандартизованным. Кроме того, она освобождает разработчиков и системных администраторов от необходимости вручную настраивать операционные системы, системные приложения или серверное программное обеспечение.
Политика безопасности как код
Практика, которая опирается на инфраструктуру как код, но использует ее принципы для определения политики безопасности и требований к ней. Инфраструктура описывается кодом, в котором содержатся правила — следить за их выполнением можно автоматически.
В такой ситуации компаниям легче управлять изменениями и экономить ресурсы: теперь не нужно прописывать разрешения безопасности для приложений при их перемещении между средами разработки и контроля качества вручную. Ресурсы, которые не соответствуют требованиям, помечаются автоматически.
Мониторинг и ведение журналов
Компании отслеживают метрики и ведут журналы событий — это помогает оценить, как производительность приложения и инфраструктуры влияет на опыт конечного пользователя продукта. Если собирать, упорядочивать и анализировать эти данные, найти источник проблем или неожиданных изменений в работе кода становится проще.
Важность мониторинга постоянно растет: пользователи хотят, чтобы сервисы были доступны круглосуточно — для этого все обновления должны работать корректно. Сбор и анализ метрик и журналов событий помогает компаниям эффективнее контролировать стабильность своих продуктов.
Обмен данными и совместная работа
Расширение взаимодействия и обмен данными между техническими подразделениями в компании — одни из ключевых культурных принципов DevOps. Практика физически объединяет ключевые рабочие процессы и наделяет группы разработки и эксплуатации равной ответственностью за конечный результат.
Строгое соблюдение культурных принципов упрощает и ускоряет взаимодействие между группами разработки, эксплуатации и другими подразделениями внутри компании (например, маркетинга или продаж). Такой подход помогает всей компании сосредоточиться на конкретных целях и проектах.
Сколько зарабатывают специалисты по внедрению практик DevOps
DevOps — одно из самых популярных IT-направлений. Судя по объявлениям на hh.ru, в Москве доступно более 2 тыс. вакансий по запросу DevOps. На них приходится более 5 тыс. резюме от 3,9 тыс. соискателей.
Зарплаты специалистов в Москве варьируются от 70 тыс. рублей до 400 тыс. рублей в месяц, в целом по России — от 25 тыс. рублей. По подсчетам Хабр Карьеры, во втором полугодии 2020 года средняя медианная зарплата в России инженера, который работает с DevOps, составляла 155 тыс. рублей.
Будущее DevOps
В мире DevOps в ближайшие годы произойдет множество изменений. Вот наиболее заметные:
DevOps постепенно становится востребованной концепцией — у технологических компаний нет другого выхода, кроме как развиваться и ускорять процессы. Однако прежде, чем методология DevOps будет использоваться в глобальном масштабе, пройдет еще 5-10 лет.
DevOps
Что такое DevOps?
Согласно определению, DevOps представляет собой процесс разработки программного обеспечения и изменения организационной культуры с целью ускорения доставки ПО и повышения качества кода за счет автоматизации и интеграции усилий команд разработки и эксплуатации ИТ-систем, которые исторически работали отдельно друг от друга или в разрозненных средах.
На практике передовые процессы и культуры DevOps выходят за рамки разработки и эксплуатации: все заинтересованные стороны, включая специалистов по платформам и инфраструктуре, безопасности, соблюдению нормативных требований, регулированию, управлению рисками, руководителей отдельных бизнес-направлений, конечных пользователей и заказчиков, вовлекаются в жизненный цикл разработки ПО.
DevOps отражает текущий этап эволюции жизненного цикла доставки ПО на протяжении последних 20 с лишним лет — от выпуска приложений с гигантским объемом кода раз в несколько месяцев или даже лет до итерационных обновлений компонентов или функций ежедневно или несколько раз в день.
В конечном итоге задача DevOps — удовлетворить растущий спрос со стороны пользователей ПО на регулярное появление новых функций, бесперебойную работу и доступность.
История появления DevOps
До 2000 года в основном применялась каскадная модель разработки и обновления ПО c последовательной реализацией масштабных проектов. У разработчиков ПО могло уйти несколько месяцев на создание больших блоков нового кода, затрагивавших все приложение или большую его часть. Из-за огромного числа изменений для интеграции нового кода требовалось еще несколько месяцев.
Последующее тестирование кода с участием специалистов по обеспечению качества (QA), безопасности и эксплуатации занимало еще какое-то время. В результате новые версии ПО, обновления или исправления ошибок выходили с интервалом в несколько месяцев или даже лет. Такой способ доставки компонентов методом «большого взрыва» (big bang) обычно сопровождался сложными, рискованными планами развертывания, трудностями при планировании синхронизации с системами выше и ниже уровнем, а также большими надеждами на то, что бизнес-требования не изменятся существенным образом спустя несколько месяцев, когда продукт будет готов к развертыванию в рабочей среде.
В целях ускорения разработки и повышения качества коллективы разработчиков начали применять гибкие методологии разработки программного обеспечения, которые носят итерационный, а не линейный характер и фокусируются на более мелких и частых обновлениях базы исходного кода приложения. Одним из важнейших представителей данной группы методологий является CI/CD или непрерывная интеграция и непрерывная доставка. Согласно принципам CI/CD, небольшие фрагменты нового кода добавляются в базу исходного кода каждую одну-две недели, с последующей автоматической интеграцией, тестированием и подготовкой к развертыванию в рабочей среде. Гибкая модель разработки ПО заменила метод «большого взрыва» на серию «небольших шагов», ограничив при этом риски.
Чем больше гибкие методики разработки ускоряли процессы разработки и доставки программного обеспечения, тем очевиднее становилось, что разрозненные ИТ-операции — предоставление ресурсов системы, настройка, приемочное тестирование, управление и мониторинг — являются узкими местами в жизненном цикле доставки ПО.
Таким образом, методология DevOps возникла на основе Agile. Новые процессы и инструменты позволили перенести принципы непрерывной итерации и автоматизации CI/CD на остальные этапы жизненного цикла доставки ПО. Это дало возможность наладить тесное сотрудничество между отделами разработки и эксплуатации на каждом шаге.
Принцип работы DevOps: жизненный цикл DevOps
Рис. 1. Жизненный цикл DevOps
Жизненный цикл DevOps, который иногда называют конвейером непрерывной доставки в линейном представлении, является последовательностью итерационных, автоматизированных процессов разработки (или рабочих процессов), выполняемых в рамках более крупного, автоматизированного и итерационного жизненного цикла разработки, с целью оптимизации сроков доставки ПО высокого качества. Названия рабочих процессов и их количество могут отличаться от команды к команде, но обычно выделяют шесть этапов:
Между этими рабочими процессами существует еще три важных этапа:
Непрерывное тестирование: в классическом жизненном цикле DevOps существует отдельный этап «тестирования», расположенный между этапами интеграции и развертывания. Однако современная концепция DevOps позволяет выполнять отдельные элементы тестирования на этапе планирования (разработка через реализацию поведения), разработки (модульное тестирование, контрактное тестирование), интеграции (статический анализ кода, сканирование CVE, проверка соблюдения стандартов кодирования), развертывания (дымовое тестирование, тестирование защиты от несанкционированного доступа, конфигурационное тестирование), эксплуатации (хаос-тестирование, тестирование на соответствие) и обучения (A/B-тестирование). Тестирование — эффективный способ обнаружения рисков и уязвимостей, позволяющий принять, минимизировать или устранить риски.
Безопасность: если каскадная модель разработки и гибкие методологии присоединяют рабочие процессы безопасности уже после доставки или развертывания, то DevOps стремится решать вопросы безопасности с первого этапа (планирования), когда для этого достаточно минимальных усилий и затрат, а затем непрерывно в течение всего последующего цикла разработки. Такой подход к обеспечению безопасности получил название сдвиг влево (shift left) (см. Рис. 1). Поскольку попытки реализовать эту идею не всегда заканчивались успешно, возникла концепция DevSecOps (см. ниже).
Соблюдение нормативных требований: рекомендуется включать процессы нормативного контроля и управления рисками с самых ранних этапов жизненного цикла разработки. В регулируемых отраслях часто требуется обеспечить определенный уровень контролируемости, трассируемости и доступа в отношении способов доставки компонентов и управления ими в операционной среде. Для этого конвейер непрерывной доставки и среда выполнения должны поддерживать планирование, разработку, тестирование и применение политик. Возможность проведения аудита мер по обеспечению соблюдения нормативных требований играет чрезвычайно важную роль для сторонних аудиторов.
Культура DevOps
Общепринято, что методы DevOps не работают без создания соответствующей культуры DevOps — особого организационного и технического подхода к разработке программного обеспечения.
На организационном уровне DevOps требует постоянного взаимодействия, совместной работы и солидарной ответственности всех заинтересованных сторон — не только сотрудников отделов разработки ПО и эксплуатации ИТ-систем, но и специалистов по безопасности, нормативному контролю, регулированию, управлению рисками и руководителей отдельных бизнес-направлений — для быстрого и непрерывного внедрения инноваций, а также обеспечения изначально высокого качества ПО.
В большинстве случаев лучшим способом решить эту задачу является устранение разрозненности и реорганизация отделов в межфункциональные, автономные команды DevOps, которые могут реализовать проект от начала и до конца, т. е. от этапа планирования до сбора обратной связи, без передачи работы или ожидания утверждений от других команд. В контексте гибкой методологии разработки солидарная ответственность и совместная работа являются фундаментом для сохранения единого фокуса в команде, что дает ценные результаты на выходе.
На техническом уровне DevOps требует приверженности идеям автоматизации, обеспечивая успешное продвижение проектов между рабочими процессами, а также обратной связи и оценки для непрерывного ускорения процессов, повышения качества и производительности ПО.
Инструменты DevOps: создание цепочки инструментов DevOps
В DevOps и культуре DevOps особое внимание уделяется инструментам, обеспечивающим асинхронный режим совместной работы, безупречную интеграцию рабочих процессов DevOps и максимальную автоматизацию всего жизненного цикла DevOps. Ниже перечислены категории инструментов DevOps:
DevOps и облачная разработка
Облачная разработка — подход к созданию приложений, опирающийся на фундаментальные технологии облачных вычислений. Цель облачной разработки — обеспечить согласованные, оптимальные процедуры разработки приложений, развертывания, управления и настройки производительности в общедоступных, частных и мультиоблачных средах.
Как правило, современные облачные приложения:
Во многих отношениях облачная разработка и DevOps созданы друг для друга.
Например, разработка и обновление микросервисов, т. е. итеративная доставка небольших блоков кода в небольшую базу исходного кода, идеально подходит для коротких жизненных циклов DevOps. Было бы сложно справиться со сложной микросервисной архитектурой без процедур развертывания и эксплуатации DevOps.Согласно недавнему опросу, проведенному IBM среди разработчиков и ИТ-руководителей, 78% пользователей микросервисов планируют вкладывать больше времени, денег и усилий в развитие микросервисной архитектуры, а 56% организаций, не использующих микросервисы, планируют их внедрение в ближайшие два года. Дополнительная информация о преимуществах и сложностях микросервисов представлена на следующем интерактивном изображении:
∞ Основы методологии DevOps
Что было до DevOps
Разработка (development) и эксплуатация (operations) продолжительное время были изолированными модулями. Код писали программисты, а системные администраторы отвечали за его развертывание и интеграцию. В рамках одного проекта специалисты работали отдельно, поскольку связь между двумя разрозненными хранилищами была ограничена.
Этот метод работал с 1970 года, пока доминировала каскадная модель процесса разработки программного обеспечения, известная как Waterfall. Методика предполагала последовательный переход между этапами без пропусков и возвращений на предыдущие стадии.
Схема методологии Waterfall
Со временем Waterfall была раскритикована за недостаточную гибкость, а ее основная цель – формальное управление проектом, приносила ущерб срокам, стоимости и качеству.
Agile применяется к организации работы небольших групп, которые создают продукт короткими итерациями (от двух до четырех недель). Каждая итерация выглядит как программный проект, который включает все типовые задачи: планирование, анализ требований, проектирование, программирование, тестирование, документирование. В конце итерации заказчик получает рабочий продукт.
Схема подхода Agile
Методология Agile критиковали за отсутствие управления требованиями. Заказчик может выставить новые требования в конце каждой итерации, что противоречит архитектуре уже созданного продукта. Частые изменения и усовершенствования продукта могут привести к массовому рефакторингу и плавающей стоимости проекта в итоге.
Идея и культура DevOps
Культура DevOps предполагает, что каждый из членов команды ответственен за конечный результат. Базируется она на нескольких основных положениях:
Принципы DevOps
В 2010 году Дэймоном Эдвардсом и Джоном Уиллисом была разработана модель CAMS, ключевые идеи которой стали принципами DevOps. Согласно ей, развитие DevOps идет в трех направлениях: люди, процессы и инструменты. При этом важна поддержка каждого пункта на всех этапах развития.
Аббревиатура CAMS расшифровывается следующим образом:
Классические бизнес-модели в IT разделяют специалистов по разработке и эксплуатации на две отдельные группы. До появления DevOps они общались на разных языках, ведь перед разработчиками стояла задача быстро внедрять инновации, а операционный персонал отвечал за поддержание стабильной среды и инфраструктуры.
Конкурирующие рабочие цели создавали между специалистами по разработке и эксплуатации недопонимание, поэтому основная задача DevOps – изменить бизнес-культуру, разделить ответственность двух групп и объединить их профессиональные навыки.
Следуя пути DevOps, код требуется переводить из стадии разработки в производство непрерывно в автоматическом режиме, поэтому автоматизацию можно считать синонимом DevOps.
В идеале автоматизировать нужно почти все:
Автоматизация упрощает рабочие процессы, сокращает количество сбоев и откатов, уменьшает количество ошибок, которые возникают при ручной настройке. Повышение эффективности, улучшение производительности и польза для конечного потребителя – главные преимущества автоматизации.
Измерение необходимо для постоянного предложения ценности и улучшений. В DevOps важно отслеживать ключевые показатели, которые зависят от целей проекта.
Измерять нужно показатели следующих процессов:
DevOps способствует развитию только в том случае, если конкретные показатели собираются и анализируются непрерывно.
DevOps подразумевает тесное сотрудничество специалистов по разработке и эксплуатации. Большое внимание уделяется прозрачности и открытости в коллективе. Чем больше знаний распространяется между сотрудниками, тем больше обратной связи они получают – это помогает улучшить их работу в целом.
DevOps и Agile
По сути DevOps объединяет две разрозненные команды (разработку и эксплуатацию), чтобы обеспечить быстрые выпуски программного обеспечения. Agile ориентирован на сотрудничество небольших команд друг с другом для быстрого реагирования на изменчивые потребности пользователей.
Основные различия между DevOps и Agile:
Жизненный цикл DevOps
Выделим основные этапы проекта, следующего принципам DevOps:
Эти этапы гарантируют оптимизацию всех процессов разработки, от предложения до производства и поставки.
На первом этапе происходит планирование и кодирование программного обеспечения, а также формируется видение проекта.
Непрерывная интег рация
На этом этапе чаще всего применяется Jenkins. Когда в репозитории Git происходят изменения, Jenkins извлекает обновленный код и готовит сборку. Упакованный код переходит к следующему этапу и пересылается либо на рабочий, либо на тестовый сервер.
На этапе непрерывного тестирования разрабатываемое программное обеспечение проверяется на наличие ошибок. Автоматическое тестирование позволяет разработчикам экономить силы и время.
Автоматическое тестирование выполняет Selenium, а отчеты генерирует TestNG. Весь этап можно автоматизировать с помощью инструмента непрерывной интеграции Jenkins. В конце, протестированный код повторно отправляется на этап непрерывной интеграции для обновления исходного кода.
Когда код развертывается на производственных серверах, важно получить корректный результат на всех серверах.
Управление конфигурацией – ключевой процесс на этом этапе. Он обеспечивает точное развертывание приложения и поддерживает согласованность конфигураций на всех серверах.
Не менее важную роль на данном этапе играют инструменты контейнеризации. Vagrant и Docker обеспечивают согласованность в различных средах – от разработки и тестирования, до подготовки и производства.
Важный этап жизненного цикла DevOps, на котором в реальном времени отслеживается производительность приложения. Для этого автоматически собираются определенные показатели телеметрии и метаданных, а также настраиваются оповещения об отклонениях в работе.
Непрерывный мониторинг помогает поддерживать доступность сервисов. Он также определяет угрозы и основные причины повторяющихся системных ошибок, а проблемы безопасности автоматически решаются в момент появления.
Активное участие в непрерывном мониторинге участвуют операционные группы. Они наблюдают за действиями пользователей, проверяют системы на предмет необычного поведения и отслеживают наличие ошибок.
Постоянная обратная связь
Чтобы оценить результаты изменений в конечном продукте, необходимо получить обратную связь от клиентов. Процесс разработки приложения обновляется с учетом их отзывов – после этого разработчики начинают вносить изменения в продукт. Когда отзывы становятся положительными, открывается путь для выпуска новых версий, либо для поддержки приложения.