Что такое DevOps и зачем он нужен?
Почему полезно работать с DevOps, где применять эту технологию и какие существуют инструменты. Объясняет Алексей Климин из компании «Атвинта».
Фронтенд, Бэкэнд, Админ, DevOps. Обожаю все оптимизировать и автоматизировать. Постоянно ищу новые технологии и способы их внедрения.
Что это за технология
Термин DevOps образован от английских слов development и operations. Это подход, методология и даже культура и философия процесса разработки, при котором программисты, тестировщики и системные администраторы могут работать над продуктом быстрее и эффективнее. Подход помогает снизить ошибки при передаче проекта от разработчиков к тестировщикам и сисадминам и наладить между ними взаимодействие. В основе лежит идея, что разработка, тестирование и эксплуатация цифровых продуктов — это единый, бесшовный и циклический процесс.
Сама по себе тема DevOps довольно объемная. Это автоматизация процессов подготовки инфраструктуры как для разработки, так и для тестирования приложения, а также для его эксплуатации. Сюда же входят автоматизация деплоя и мониторинг.
Рассмотрим на примере заказной разработки веб-приложений, с какими проблемами сталкиваются разработчики и как их устранить с DevOps-подходом.
Вариант сервис-ориентированной архитектуры ПО, ориентированный на взаимодействие небольших, слабо связанных и легко изменяемых модулей — микросервисов.
Проблемы при работе без DevOps
Много действий при передаче на тестирование
Разработчик устанавливает у себя на машине все необходимое: язык программирования, на котором будет вестись разработка, например PHP 7.0, базу данных, MySQL 5.7 и веб-сервер, Apache. Какая операционная система и какие версии библиотек и зависимостей будут установлены на сервере, неизвестно.
После того как нужная функциональность приложения реализована, требуется ее протестировать.
Программист упаковывает в архив свой код, копию базы данных, информацию о требуемом ПО и инструкцию по установке всего необходимого для запуска и работы приложения. После этого он передает архив тестировщику.
QA-специалист устанавливает все необходимое на тестовый стенд, разворачивает приложение и принимается тестировать.
Если в процессе тестирования появляется новая версия разработки, то приходится повторять процедуру. Разработчику нужно снова создать архив, передать тестировщику; а тому, в свою очередь, снова развернуть приложение.
В результате таких многократно повторяющихся процедур ошибки наслаиваются, и QA- специалисту приходится дважды перепроверять одни и те же баги.
Несовместимость версий в тестовой среде и на сервере заказчика
Версия языка программирования может отличаться от той, на которой велась разработка. Могут различаться версии базы данных. И даже сама система управления базами данных может быть другой. И это не говоря о том, что пути до файлов и каталогов в коде самого приложения различаются, так как приложение на боевом сервере находится совершенно в другом месте, нежели на машине разработчика.
В итоге при использовании на продакшне другого веб-сервера приходится настраивать приложение заново. А это дополнительное время.
Как DevOps улучшает процесс разработки
У нас в digital-агентстве «Атвинта» я настроил процессы таким образом, что сборка проекта, запуск автотестов и деплой на тестовый сервер происходят автоматически, а на продакшн — полуавтоматически. Если какой-либо из этапов завершился неудачно, разработчик получит оповещение.
Эти технологии подходят при разработке веб-приложений, закрытых сервисов вроде корпоративных порталов и сервисов учета сделок для интернет-магазинов.
Для подготовки серверов используются инструменты наподобие Ansible. Они позволяют быстро настроить окружение, в котором приложение будет работать в автоматическом режиме. На это тратится несколько минут, а не несколько часов.
Для единообразия окружения используем инструмент Docker.
После того как разработчик сделал определенный функционал, он отправляет код в репозиторий. Там вступает в работу процесс, называемый Continuous Integration/Continuous Delivery — непрерывная интеграция и непрерывная доставка (далее CI/CD).
Если процесс сборки и автоматического тестирования прошел успешно, приложение разворачивается на тестовом сервере (staging server), где специалист по QA проводит ручное тестирование либо тестирование с применением инструментов вроде Selenium — для автоматизации действий веб-браузера в случае веб-приложения.
Даже если во время ручного тестирования возникли какие-либо ошибки, разработчик быстро вносит правки и выкатывает обновление. Даже если нужно повторять процедуру, это происходит быстро.
После успешного тестирования принимается решение о релизе, после чего достаточно нажать одну кнопку, чтобы выпустить новый релиз в продакшн.
DevOps-инженер также проводит работы по так называемому незаметному деплою, когда конечные пользователи даже не подозревают о том, что вышла новая версия.
Инструментарий для DevOps
Разнообразие инструментов DevOps невероятно велико, так что я перечислю лишь некоторые из них, которые применяю в своей работе.
Ansible — система управления конфигурациями, написанная на Python с использованием декларативного языка разметки (yaml) для описания конфигураций.
Была выбрана за низкий порог вхождения. Уже через пару часов можно написать рабочую конфигурацию.
GitLab — система контроля версий со встроенной CI/CD.
Выбрана, потому что можно развернуть на своем сервере и использовать бесплатно. Имеет большой функционал и интеграцию со множеством сторонних сервисов.
Для мониторинга нагрузки серверов используется довольно популярный стек: Grafana + InfluxDB + Telegraf.
Grafana — это платформа с открытым исходным кодом для визуализации, мониторинга и анализа данных.
InfluxDB — база данных для хранения собранной статистики.
Telegraf — агент, который устанавливается на сервер и пересылает метрики, а также логи в базу InfluxDB.
Кому и для чего применять
Применение методологии DevOps поможет наладить бизнес-процессы и ускорить выход обновлений.
DevOps — автоматизируй всё
Целью статьи является дать основные представления о DevOps и практиках, используемых при этой методологии. Тут не будет сложных терминов, конкретных продуктов и road map внедрения DevOps, но, надеюсь, будет интересно ознакомиться.
Как такового, определения DevOps нет, и все понимают эту методологию по-разному. Декларируемая цель – убрать барьеры между DEVelopment и OPerations. Поэтому часто DevOps понимают как то, что operations, QA и development находятся в одной команде, сидят в одном помещении, проводят общие митинги, общаются. Само по себе сближение и неформальное общение членов команды всегда полезно и уже это может привести к улучшению результатов. Но есть и формальные практики, следование которым позволяет улучшить поставку релизов, а значит и удовлетворение бизнеса.
Здесь описаны следующие:
Структура статьи построена следующим образом: перечислены практики, дано их описание, приведено Бизнес-Значение практики (то, как внедрение этого подхода улучшит жизнь бизнеса) и Измеримость (как можно измерить улучшение). И Бизнес-значение, и Измеримость также взяты из презентаций «DevOps-Fundamentals».
Ну что же, приступим. Процесс разработки и поставки ПО состоит из следующих шагов:
Начинается все с планирования. Планирование релиза, разработки, тестирования, развертывания. Пропустим этот шаг, так как development и operations в этом шаге не задействованы. После того, как разработчик закончил реализацию некоторого участка кода, он сохраняет (commit’ит) его в систему контроля версий. После этого вступает в дело первая практика:
Непрерывная интеграция (Continuous Integration)
Непрерывная интеграция (Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Wiki
Собственно, что такое Continuous Integration? Процесс происходит примерно так: разработчик, после того, как завершил свою задачу и отладился, сохраняет свои изменения в рабочюю копию (TFS, SVN, Git). Дальше в действие вступает некий робот (TFS, TeamCity, что-либо еще), отслеживающий изменение рабочей версии. Он видит, что рабочая копия изменилась и запускает сборку проекта. По результатам сборки, оповещается разработчик (и другие заинтересованные лица) о том, прошло все успешно или нет. Оповещение может быть через письмо, сообщение в трее, или отобразиться на web-странице. Таким образом, если сборка прошла с ошибкой, то разработчик сразу же узнает об этом.
Бизнес значение
Измеримость
Автоматическое тестирование (Automated Testing)
Автоматизированное тестирование – это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования ©.
После того, как сборка собрана, её нужно проверить. Наиболее быстро это можно сделать с помощью автоматических тестов. Для этого используются различные инструменты: это могут быть Unit тесты, UX тесты, интеграционные тесты. Главное условие – они не должны требовать участия человека. С помощью авто-тестов мы сразу получаем информацию о том, есть ли ошибки в нашей сборке. И сразу же можем начать их исправлять, не дожидаясь результатов ручного тестирования.
Бизнес значение
Измеримость
Инфраструктура как код (Infrastructure as Code)
Инфраструктура как код — это процесс управления и подготовки вычислительной инфраструктуры (процессы, физические сервера, виртуальные сервера и т.п.) и их конфигурации через машиннообрабатываемые файлы определений, а не физическую конфигурацию оборудования или использование конфигурационных инструментов Wiki.
Подход к конфигурированию приложений должен быть таким же, как и к коду. То есть конфигурационные файлы, переменные окружения, что-то еще должны храниться в централизованном хранилище или системе контроля версий, возможно, в той же самой, что и хранится код. И при конфигурировании приложения браться они должны именно оттуда. Соответственно, в случае необходимости изменить конфигурацию на сервере, ответственный сотрудник не заходит на него и меняет, например, соединение к БД, а меняет нужную переменную в хранилище, и оттуда она уже автоматически появляется на сервере.
Привычки (Habits)
Бизнес значение
Измеримость
Непрерывное развертывание (Continuous Deployment)
Непрерывная развертывание – объединение Continuous Integration (непрерывной интеграции) и Continuous Delivery (непрерывной поставки). Это следующий шаг после успешной сборки и успешного прохождения автоматических тестов (и, возможно, установки галочки «сборка готова к развертыванию» ответственным человеком). Если вы уверены в ваших тестах, их наборе и покрытии, при их успешном выполнении запускается автоматическая установка на соответствующую среду, тестовую или продуктовую. Разница между Continuous Integration, Delivery, Deployment хорошо описана тут: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/
Бизнес значение
Измеримость
Управление релизами (Release Management)
Управление релизом заключается в том, что мы определяем формальные критерии, готова ли сборка к установке на соответствующую среду. Примером критериев, по которым сборка готова, и, если они выполняются, автоматически запускается поставка (Continuous Deployment) могут быть:
Бизнес значение
Измеримость
Управление конфигурациями (Configuration Management)
Управление конфигурациями (Configuration Management) — это детальная запись и обновление информации, описывающей ПО и оборудование предприятия. Такая информация обычно включает версии и апдейты, которые были применены к установленному ПО, а также местоположение и сетевые адреса оборудования. ©
Здесь к формальному определению добавить особо и нечего. Все должно быть записано и подсчитано.
Бизнес значение
Измеримость
Нагрузочное тестирование (Load Testing)
Нагрузочное тестирование (load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству) Wiki
Часто происходит так, что, например, для web приложений, когда пользователь один (разработчик или тестировщик) страница быстро открывается у и хорошо реагирует на работу с ней. Но как только изменения попадают на продуктовый сервер, и эту же страницу начинают смотреть сотни, тысячи человек одновременно, страница долго грузится и перестаёт реагировать.
Проводя нагрузочное тестирование мы и определяем наличие проблем на раннем этапе, еще до попадания проблемной сборки на продуктовый сервер. Нагрузочное тестирование реализуется генерацией большого потока запросов к серверу и анализа поведения сервера.
Бизнес значение
Измеримость
Мониторинг быстродействия приложения Application Performance Monitoring
Мониторинг быстродействия приложения (application performance management) – это мониторинг и управление быстродействием и доступностью ПО. APM стремится выявлять и диагностировать проблемы быстродействия комплексно, для поддержания ожидаемого уровня обслуживания Wiki
Нагрузочное тестирование выявляет многие проблемы еще до того, как сборка попала на продуктовые сервера и с ней начали работать клиенты. Но, к сожалению, не всегда удается предугадать как действия пользователей, так и влияние разницы в ресурсах серверов на тестовой и продуктовой средах. Поэтому необходимо мониторить состояние и работу приложения на продуктовой среде. Этому и служит мониторинг быстродействия приложения.
От стесняшки до архитектора: какими бывают DevOps и как стать одним из них
Александр Крылов, DevOps-инженер, поделился своим опытом и личным взглядом на профессию. Он рассказал, чем девопсы отличаются друг от друга и что нужно включить в индивидуальный график обучения, чтобы стать одним из них.
В теории DevOps-инженером может стать любой, кто этого пожелает. Это не та профессия, где играет роль физическая предрасположенность к какому-то делу, как, допустим, у космонавта. Всё зависит от тяги к знаниям и способности обучаться, не лениться, не бояться задавать вопросы коллегам.
Александр Крылов
Крылов Александр, Lead DevOps services ПАО СК Росгосстрах, гик по жизни вокалист группы Terror Inside, любитель фантастики и всего, что связано с Unix.
Другой вопрос — сколько сил придётся потратить на новую специализацию. DevOps — методика на стыке технологий, поэтому прийти с улицы и внезапно стать сеньором не получится. Надо накопить теоретический и практический багаж.
Понятно, что лучше, когда есть опыт системного администрирования или разработки, это даёт на старте хороший трамплин. Но не у всех такой есть. Кроме того, DevOps — это не только технологии. Это культура взаимодействия, поэтому гибкие навыки тут тоже важны. Речь не про способность много говорить или любить тусовки, как часто воспринимают soft skills. Я считаю, что на DevOps-инженера можно обучиться в части теоретических знаний и использования инструментов, но культуру и процессы можно понять и прочувствовать, только работая в команде.
Увалень, интроверт, агрессор: опыт классификации девопсов
Градация среди инженеров по уровню задач, которые они решают, безусловно, есть. Это, конечно, стандартная база: junior, middle, senior. Но мои наблюдения показывают, что даже на этих уровнях различия между специалистами очень большие.
Junior — начинающий специалист, который либо только пришёл в профессию, либо имеет минимальный набор знаний. Моя дополнительная классификация джуниоров:
Студент — имеет теорию без практики, легко обучаем.
Увалень — владеет минимальным тулсетом и считает себя мидлом, при этом не развивается и может выполнять только минимальный набор задач. Чаще всего закрывает текучку.
Стесняшка — за такими нужен глаз да глаз. Они могут знать теорию, но боятся задавать вопросы, таким всегда необходим опытный коллега.
Админ — человек из админов, со знаниями, готов развиваться в автоматизацию, разработку и коллаборацию с другими подразделениями. Чаще всего такие быстро становятся мидлами, но не всегда доходят до сеньоров.
Middle — люди, имеющие опыт, побывали джунами. Не боятся задавать вопросы, могут быть автономными, в некоторых случаях сами ставить себе задачи. Но и среди них есть градации:
Разработчик-интроверт — он может быть хорошим специалистом, иметь прекрасные hard skills, но минимальный уровень гибких навыков, а потому над ним всегда должен быть сеньор или менеджер, который будет ему помогать.
Любитель поговорить — обладает хорошими гибкими навыками и чуть выше уровня junior hard skills, на чём и выезжает. Активен, участвует во всех встречах, летучках, созвонах, сборах требований. Очень часто такие специалисты становятся менеджерами.
Проджект — человек, обладающий неплохими гибкими навыками, неплохими hard skills, умеет делать проекты «от и до». Очень близок к сеньору.
Агрессор — обладает хорошими hard skills и уверенно варится в этом котле. Его часто отвлекают джуны от порой важных, а порой не очень, задач, отчего он всегда ворчит и ругается. Просто к нему нужен подход. Такие специалисты могут решать сложные задачи, и задача их руководителей — минимизировать общение с любознательными джунами и несознательными пользователями.
Ну и самое интересное — senior DevOps. Это люди, которые повидали такое на свете, о чём не стоит говорить в приличном обществе. Могут менторить, вести проекты от и до. Я общался с разными сеньорами:
Архитектор — занимается проектированием hardware и app уровнями систем, которые только начинают или планируют внедряться. За счёт опыта и сплита навыков hard и soft может один сделать проект от сотворения вселенной до продакшена.
Активист — этот в каждой бочке затычка. Он говорлив, активен, энергия бьёт ключом. Часто посещает конференции, слушает подкасты, читает разные порталы. Такие очень часто участвуют в пилотах новых продуктов, предлагают продукты для внедрения/пилотов. Входят в различные инициативные группы и комитеты, помогая выстроить процесс. Чаще всего являются лидами.
Суперразработчик — они могли прийти из разработки или руководить ею. Версионируют код, следят за бранчами, занимаются ревью. Поэтому часто погружаются в код и архитектуру ПО, из которого, порой, не вылезают. Могут решать низкоуровневые специализированные вопросы.
Главное, что можно сказать о переквалификации в DevOps — всё индивидуально.
В принципе, про любое образование и про любую карьеру можно так сказать. Вы можете тратить по восемь часов в день, бороздить просторы интернета и читать статьи по теме, но так ни к чему и не прийти за два года. А можете полгода по вечерам поработать над базой пару часов и стать неплохим джуниором. Безусловно, есть уникальные люди, которые всё схватывают на лету и являются хорошими специалистами-самоучками, но таких — малый процент.
Тут я рекомендую не искать серебряную пулю, а составить личный график саморазвития.
Так называемый ИПР, или индивидуальный план развития. Затем разделить его на временные рамки и далее следовать ему. Постепенно, двигаясь по вашему личному ИПР, вы будете набирать экспертизу и получать левел-апы. Опять же, такой подход работает в любом обучении.
С чего начать составлять индивидуальный график
Начинать всегда следует с того, что лучше всего получается. Каждому своё, ведь кто-то силён в разработке, кто-то в аналитике или архитектуре. Начинайте изучать программы и решать проблемы, используя свои сильные стороны, постепенно наращивая и компенсируя слабые. Где-то взаимодействуя с коллегами, где-то проходя курсы или практику из community.
Существует множество статей, докладов, выступлений на конференциях на тему того, что же должен знать девопс. Единого госэкзамена нет, но есть часть, которую можно объединить и выделить:
Опыт работы и понимания принципов работы Linux.
Понимание работы сетей, хотя бы на уровне сетевых протоколов и уровней TCP/IP.
Понимание принципов работы виртуализации и умение работать с ней.
Понимание работы контейнеров, умение их готовить.
Понимание разницы между монолитной и микросервисой архитектурой. Набор паттернов при построении архитектуры, анти-паттерны.
Понимание культуры и принципов взаимодействия в команде на базе agile, devops. Понимание подходов к организации разработки: kanban, scrum.
Понимание подходов CI\CD как на уровне процесса разработки, так и набора инструментов, которые этот процесс могут сопровождать, дополнять и развивать.
Понимание принципов работы с репозиторием, версионирования кода, подходов к разработке, например, стандартный gitflow.
Понимание безопасности кода, как можно использовать подходы к нему, включить в pipeline.
Подходы к тестированию кода, виды тестирования, тулзы для АТ: mock, системное, нагрузочное, регресс.
Подходы к тестированию инфраструктурного кода и автоматизации этого тестирования.
Базовые принципы и виды мониторинга, алёртинга, какие есть тулзы. Что такое LogTracing, подходы OpenTracing, OpenTelemetry.
Умение понимать, какие задачи стали рутинными, чтобы можно было их автоматизировать и перестать на них тратить время.
И два бонуса из не совсем технической части:
Не бояться задавать вопросы и быть готовым всегда развиваться, не бояться перемен.
Системный подход к решению проблем.
В какие языки надо погружаться
Конечно, качество собственного кода на работу девопса влияет напрямую и непосредственно. Начиная от качества кода ПО, с которым работают DevOps инженеры и покрытия этого кода тестами, заканчивая кодом, который они сами пишут и покрытия его тестами, например, инфраструктурного кода или ansible. Поэтому следует самому покрывать код тестами и проверками и стремиться внедрять в pipeline автоматизированные тесты проверки исходного кода приложения. А ещё лучше иметь и то, и другое, и QG на них, чтобы, если код не соответствует правилам, его нельзя было влить в релизную ветку. Чем при этом пользоваться?
Python — модно, молодёжно, используется в машинном обучении и нейросетях, а также всевозможной автоматизации. Работать с подходами MLOps, DataOps крайне интересно, но для них нужен большой багаж знаний.
Java, Kotlin, Spring boot — мир корпоративного ПО, где много интересных технологий, микросервисов и взаимодействия со всеми участниками процесса. Лучше всего подходит для начинающих, чтобы быстро втянуться в основные технологии CI\CD и того, что есть у многих крупных компаний.
Go — ещё более модно и молодёжно, но порой сыровато, и надо скушать много известной субстанции, чтобы приготовить некоторое ПО, написанное на нём, а также выстроить цикл разработки.
C# — чистые шарпы — это тоже модно и корпоративно, но дважды подумайте, прежде чем захотите связываться с windows-стеком разработки всего, что с ним связано. Часто на нём идёт какое-либо легаси или монолит.
C# net core — несколько лучше, чем чистый C#, больше новых технологий, используется далеко не во всех компаниях, кроссплатформенный, но не забывайте, что это windows, который приготовить на linux порой бывает крайне беспощадно. Часто используется либо в смешанных системах из монолита и микросервисов, либо в микросервисах. Если у вас крепкие нервы, то вам сюда.
Ну и замкнём круги ада некоторым легаси: C, C++, plsql, Delphi. В проекты, которые используют что-то из них, вы идёте исключительно на свой страх и риск. Вы окунётесь в тонну легаси, вендерлока и страданий. Только матёрые инженеры идут в этот путь, либо любители free bsd.
Как находить практику для обучения
DevOps, конечно, очень практическая штука. Задачи и инструменты у всех компаний разные. Но теория всё равно нужна, вариться в практике, не зная банальной терминологии и основ linux. — бессмысленно и беспощадно. Есть множество бесплатных практикумов, разборов установки тулсетов и решения проблем на YouTube, статьи на Хабре. Берите различные кейсы развёртывания систем и пробуйте. Берите репы githab и разворачивайте, настраивайте, ломайте, смотрите, что будет, лечите.
Но рано или поздно вам понадобится наставник — коллега, тимлид, который бы придумывал вам задания. Тут без практического навыка в работе либо ментора, который его имеет, дальше вы не пройдёте. Теория теорией, но практика, да ещё и в крупном enterprise — это небо и земля. Поэтому навыки и минимальный набор тулсетов развиваем на свободных, бесплатных, cloud free площадках, а остальное — либо у наставников, либо работая в этой сфере. Чем раньше вы начнёте это делать, тем лучше.
Говоря о людях, у которых есть теоретические знания, но нет практического опыта — всё индивидуально, и кто-то быстро выработает подходы к решению проблем, а кто-то будет буксовать и без менторства встанет на месте. Поэтому, возвращаясь к порогу входа в профессию DevOps, могу сказать, что он минимален, и почти каждый может им стать, но надо уметь работать в команде, не прокрастинировать и быть открытым новому.
Когда включать в план обучения гибкие навыки
Всем всегда рекомендую начать с прикладных навыков и развития hard skills, поэтому начинаем по следующим книгам:
Уорд Брайан. Внутреннее устройство Linux.
Арнольд Роббинс. Bash — карманный справочник для системного администратора.
Лорин Хоштейн. Запускаем Ansible.
Michael Duffy. DevOps Automation Cookbook
Марко Лушка. Kubernetes в действии.
Только после этого отправляйтесь учиться проджекту, гибким навыкам, процессам:
Проект «Феникс». Как DevOps устраняет хаос и ускоряет развитие компании. Ким Дж., Бер К., Спаффорд Дж.
The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Kim Gene, Debois Patrick, Willis John.
Теория игр. Авинаш Диксит.
Практика непрерывных апдейтов – Continius Delivery. Эбихард Вольф.
Дополнение от редакции:
Александр рассказал, как построить самостоятельный путь обучения в DevOps. Но если вам нужна помощь, заходите.
