какие задачи выполняет система devops pipeline management
Что такое методология DevOps и кому она нужна
Разбираемся, в чём суть методологии и кому она может принести пользу.
Также поговорим о DevOps-специалистах: их задачах, зарплатах и навыках.
Фото Matt Moor / Flickr / CC BY-SA
Что такое DevOps
DevOps — это методология разработки ПО, задача которой наладить взаимодействие программистов и сисадминов в компании. Если ИТ-специалисты из разных отделов недопонимают суть задач друг друга, выпуск новых приложений и обновлений для них затягивается.
DevOps формирует «бесшовный» цикл разработки, тем самым помогая ускорить выпуск программного продукта. Ускорение достигается за счет внедрения систем автоматизации. Плюс программисты начинают участвовать в настройке серверов и поиске багов, например, они могут писать автоматизированные тесты.
Таким образом налаживается взаимодействие между отделами. Сотрудники начинают лучше понимать, какие этапы проходит программный продукт перед тем, как попасть в руки пользователя.
Когда разработчик понимает, с чем сталкивается администратор при настройке сервера, он постарается сгладить возможные «острые углы» в коде. Это сокращает количество багов при развертке приложения — по статистике оно уменьшается примерно в пять раз.
Кому нужна и не нужна методология
Многие ИТ-эксперты считают, что DevOps принесет пользу любой организации, которая занимается разработкой ПО. Это справедливо даже в том случае, если компания является простым потребители ИТ-сервисов и не разрабатывает собственные приложения. В этом случае внедрение DevOps-культуры поможет сконцентрироваться на инновациях.
Исключение составляют стартапы, но и здесь все зависит от масштабов проекта. Если ваша цель — запустить минимально жизнеспособный продукт (minimum viable product, MVP), чтобы протестировать новую идею, то можно обойтись и без DevOps. Например, основатель Groupon в начале работы над сервисом сам вручную размещал все предложения на сайте и собирал заказы. Никаких инструментов автоматизации он не использовал.
Внедрять методологию и инструменты автоматизации имеет смысл только тогда, когда приложение начинает набирать популярность. Это поможет наладить бизнес-процессы и ускорить выход обновлений.
Как внедрить DevOps
Далее — несколько рекомендаций для перехода на новую методологию.
Выявите проблемы в бизнес-процессах. Перед внедрением методологии выделите цели и проблемы организации. От них будет зависеть стратегия перехода на DevOps. Для этого составьте список вопросов, например:
Поменяйте культуру в компании. Важно убедить всех сотрудников изменить привычные способы работы и расширить свой спектр компетенций. Например, в Facebook все программисты отвечают за жизненный цикл приложения целиком: от написания кода до внедрения. Также в Facebook нет отдельного отдела тестирования — тесты пишут сами разработчики.
Начните с малого. Выберите процесс, который отнимает больше всего времени и сил при выпуске обновлений, и автоматизируйте его. Это может быть тестирование или процесс развертывания приложений. Эксперты советуют первым делом внедрить инструменты распределенного контроля версий. С ними проще управлять исходниками. Среди таких решений наиболее известны Git, Mercurial, Subversion (SVN) и CVS.
Также стоит обратить внимание на системы непрерывной интеграции, ответственные за сборку и тестирование конечного продукта. Примеры таких инструментов: Jenkins, TeamCity и Bamboo.
Оценивайте улучшения. Разработайте метрики эффективности внедренных решений и составьте чек-лист. Метриками могут служить частота релизов, время работы над программными функциями, количество багов в коде. Обсуждайте результаты не только с менеджерами, но и с остальной командой, занятой на проекте. Спрашивайте, каких инструментов не хватает. Учитывайте эти запросы при дальнейшей оптимизации процессов.
Критика DevOps
Хотя методология помогает организациям быстрее принимать решения, касающиеся разработки приложений, сокращает количество ошибок в ПО и поощряет сотрудников учиться новому, у неё есть и критики.
Есть мнение, что программисты не должны разбираться в деталях работы системных администраторов. Якобы DevOps приводит к тому, что в компании вместо специалистов по разработке или администрированию появляются люди, разбирающиеся во всем, но поверхностно.
Также считается, что DevOps не работает при плохом менеджменте. Если у команд разработчиков и администраторов нет общих целей, в этом виноваты менеджеры, которые не организуют взаимодействие между командами. Чтобы решить эту проблему, нужна не новая методология, а система оценки менеджеров на основе отзывов от подчиненных. Вот здесь можно почитать, какие вопросы следует включать в формы опросов для сотрудников.
Фото Ed Ivanushkin / Flickr / CC BY-SA
Кто такой DevOps-инженер
DevOps-инженер занимается внедрением методологии DevOps. Он синхронизирует все этапы создания программного продукта: от написания кода до тестирования и выпуска приложения. Такой специалист контролирует отделы разработки и администрирования плюс автоматизирует выполнение их задач, внедряя различные программные инструменты.
Фишка DevOps-инженера в том, что он совмещает множество профессий: админа, разработчика, тестировщика и менеджера.
Джо Санчес, DevOps-евангелист из VMware, компании-разработчика программного обеспечения для виртуализации, выделил ряд навыков, которыми обязан обладать DevOps-инженер. Помимо очевидного знания методологии DevOps, этот человек должен иметь опыт администрирования ОС Windows и Linux и опыт работы с инструментами автоматизации вроде Chef, Puppet, Ansible. Еще он должен уметь писать скрипты и код на паре-тройке языков и разбираться в сетевых технологиях.
DevOps-инженер отвечает за любую автоматизацию задач, связанных с настройкой и развертыванием приложений. На его плечи ложится и мониторинг программного обеспечения. Для решения этих задач он применяет различные системы управления конфигурациями, решения виртуализации и облачные инструменты для балансировки ресурсов.
Кто нанимает
DevOps-инженеры могут принести пользу любой организации, чья деятельность связана с разработкой приложений или управлением большим количеством серверов. DevOps-инженеров нанимают ИТ-гиганты вроде Amazon, Adobe и Facebook. Еще они работают на Netflix, Walmart и Etsy.
Не нанимают DevOps-инженеров только стартапы. Их задача — выпустить минимально жизнеспособный продукт, чтобы проверить новую идею. В большинстве случаев стартапы могут обойтись без DevOps.
Сколько платят
DevOps-инженеры зарабатывают больше всех в отрасли. Средний заработок таких специалистов по миру составляет от 100 до 125 тыс. долларов в год.
В США они получают 90 тыс. долларов в год (500 тыс. рублей в месяц). В Канаде им платят 122 тыс. долларов в год (670 тыс. рублей в месяц), а в UK — 67,5 тыс. фунтов стерлингов в год (490 тыс. рублей в месяц).
Что касается России, то московские компании готовы платить DevOps-специалистам от 100 до 200 тыс. рублей в месяц. В Санкт-Петербурге работодатели чуть щедрее — предлагают 160–360 тыс. рублей в месяц. В регионах указывают зарплату 100–120 тыс. рублей в месяц.
Как стать специалистом по DevOps
DevOps — это относительно новое направление в IT, поэтому устоявшегося перечня требований к DevOps-инженерам нет. В вакансиях среди требований на эту должность можно встретить как навыки администрирования Debian и CentOS, так и умение работать с дисковыми RAID-массивами.
На основании этого можно сделать вывод, что прежде всего DevOps-инженер должен иметь хороший технический кругозор. Такому человеку важно постоянно изучать новые инструменты и технологии.
Проще всего стать DevOps-инженером будет сисадмину или разработчику. У них уже есть ряд навыков, которые нужно просто развить. Главная задача — подтянуть минимальный набор знаний по DevOps, понять, как работать с инструментами автоматизации и заполнить пробелы в навыках администрирования, программирования и виртуализации.
Чтобы понять, где знаний пока не хватает, можно воспользоваться мини-википедией на GitHub или ментальной картой. Резиденты Hacker News также рекомендуют почитать книги «Проект „Феникс“» и «Руководство по DevOps» (которые мы упоминали выше) и «Философия DevOps. Искусство управления IT» под грифом O’Reilly Media.
Еще можно подписаться на рассылку Devops Weekly, почитать статьи тематического портала DZone и начать общаться с DevOps-инженерами в Slack-чате. Еще стоит изучить бесплатные курсы на Udacity или edX.
Выстраиваем процесс разработки и CI pipeline, или Как разработчику стать DevOps для QA
Вот приходишь ты работать в маленький стартап с американскими корнями…
Пока ещё маленький такой стартап, но зато с многообещающим продуктом и большими планами на завоевание рынка.
И поначалу, пока команда разработчиков совсем крошечная (до 10 человек), разработка кодовой базы ведётся в общем репозитории на GitHub Enterprise, с быстрым выделением мелких фич, бранчеванием от master, и быстрыми же циклами релизов с мержем фич-бранчей напрямую в тот же мастер. Лид команды пока что способен отследить, кто чего накоммитил, и каждый коммит не только прочитать, но и понять, правильно ли оно, или не очень. Таким образом, пулл реквесты открываются, и быстро мержатся самим же разработчиком с устного одобрения лида (или отклоняются им).
Для обеспечения целостности кодовой базы команда уповает на юнит- и интеграционные тесты, коих написана уже пара тысяч штук, и обеспечено покрытие порядка 60% (по крайней мере, для бэкэнда). Лид разработки тоже прогоняет у себя полный цикл тестов на мастере перед релизом.
Процесс выглядит как-то так:
КОММИТЫ » ТЕСТЫ ВРУЧНУЮ » РЕЛИЗ
Проходит пара месяцев. Стартап показывает жизнеспособность, инвестиции позволяют нарастить команду разработчиков до 15 человек. В основном приходят фронтэндеры, и начинают быстро расширять фасад, который видят и используют конечные пользователи. Тестируется фасад фронтерами прямо у себя на рабочих маках, они пишут какие-то кейсы на Selenium, но у лида разработки уже нет времени прогонять их перед релизом, потому что Selenium известен своей неспешностью.
И тут случаются два факапа, буквально один за другим.
Сначала один из бэкэндеров случайно делает push force в master (бедняга простыл, затемпературил, голова не соображала), после чего две недели работы всей команды приходится восстанавливать по коммитику из чудом уцелевших локальных копий — все давно уже привыкли первым делом, придя на работу, сделать себе pull.
Потом одна из крупных фич, разрабатываемая фронтерами примерно пару месяцев в отдельной ветке, и зелёная по всем UI тестам, после мержа в master резко окрашивает его в красный, и чуть-чуть не обрушивает работу всего продукта. Прошляпили breaking изменения в собственном API. И тесты никак не помогли их отловить. Бывает. Но непорядок.
Так перед стартапом встаёт в полный рост вопрос о заведении команды QA, да и вообще, регламентов работы с фич-бранчами и общей методикой разработки, вкупе с дисциплиной. А также становится очевидно, что код перед пулл реквестом должен ревьюить не только лид разработки (у него и без того дел полно), но и другие коллеги. Нормальная проблема роста, в общем-то.
Вот мы и пришли к пункту «Дано:».
Сначала настроим в амазоновском облаке головной инстанс TC (+ два бесплатных агента), повесим их слушать коммиты в гихабовском репозитории (на каждый PR гитхаб делает виртуальный HEAD — слушать изменения ну очень просто), и автоматические сборки с прогоном юнит-тестов пойдут практически сами собой. Как коммитнет кто-нибудь, так через пять минут и сборка в очередь становится. Удобно.
КОММИТЫ » ПУЛЛ РЕКВЕСТ » БИЛД + ТЕСТЫ » РЕЛИЗ
У гитхаба в то время был ещё весьма неприятный интерфейс для просмотра пулл реквестов, и комментарии там оставлять тоже было не айс. Больно уж длинную портянку экранов надо было проматывать. То есть, отобрать у членов команды право на мерж было можно, но обеспечить нормальное ревью кода без сторонних сервисов — никак. Вдобавок, хотелось ещё получить заодно вменяемую интеграцию с Джирой, чтобы фичи к таскам, а таски к фичам сами прикреплялись.
По счастью, у Atlassian есть подобное решение, называется оно BitBucket Server, а в то время ещё звалось Stash. Как раз позволяет делать всю такую интеграционную магию с другими атлассиановскими продуктами, и очень удобно для ревью кода. Решили смигрировать.
Вот только этот чудесный продукт, в отличие от гитхаба, виртуальных HEAD на каждый PR не создаёт, и тимсити после миграции стало нечего слушать. С post-commit hooks дело тоже не пошло по причине отсутствия у всех времени хорошенько с ними разобраться.
Забегая вперёд — когда время появилось, мне удалось переписать stash-watcher.sh по-человечески, забирая изменения через штатный REST, распарсивая JSON-ответ при помощи великой и могучей утилиты jq, — мега-вещь для любого девопса, делающего интеграцию тулзовин! — и дёргая TeamCity только тогда, когда это на самом деле надо. Ну, ещё заодно прописал скрипт системным демоном, чтобы он стартовал при перезагрузке сам. Амазоновские инстансы изредка надо бывает перестартовать.
Вот, сложилось два кусочка головоломки.
КОММИТЫ » ПУЛЛ РЕКВЕСТ » РЕВЬЮ КОДА || БИЛДЫ + ТЕСТЫ » РЕЛИЗ
За это время в команде возникли QA инженеры.
Бедненькие! За день переключаться локально между пятью фич-бранчами, собирать и запускать их вручную!? Да врагу такого не пожелаешь.
Признаюсь честно: я искренне люблю QA инженеров (особенно девушек). И, в общем-то, не я один. Даже коллеги из НЙ, изначально свято веровавшие в юнит-тесты, как оказалось, их любят. Только они об этом ещё не догадывались, когда расплывчато сформулировали задачку «надо как-нибудь исследовать такой вопрос, чтобы можно было автоматом запускать где-то у нас в облаке по экземпляру приложения на каждый бранч, ну, типа, чтобы бизнесу можно было глазами посмотреть, что конкретно там сейчас с разрабатываемой фичей происходит. Would you?»
— Окей, — сказал я (ну а кто ещё? Кто однажды вляпался в DevOps, тот и крайний), — Вот и пункт «Требуется:» прибыл.
Интересная задачка. Ведь если удастся настроить автоматический деплой по итогам билда, то одним махом можно обеспечить потребности и бизнеса, и наших бедных QA. Вместо того, чтобы мучиться со сборкой локально, они будут ходить в облако на готовый экземпляр.
Тут ещё надо сказать, что приложение представляет собой несколько WAR-контейнеров, которые запускаются под Apache Tomcat. WAR же, как известно, это обычный архив ZIP с особенной структурой директорий и манифестом внутри. И при сборке приложения его конфигурация (путь к базе, пути к REST endpoints других WAR, и всё такое прочее) зашивается куда-то внутрь ресурсов. А чтобы скормить WAR томкэту, надо прописать в конфигах, откудова его брать, по какому url, и на каком порту его развёртывать.
А если мы хотим запустить сразу много экземпляров одного и того же WAR? Конфигурить томкэт на лету, чтобы раскидывать их по разным портам или url-ам? И что делать с конфигами, зашитыми внутрь ресурсов WAR?
Какая-то дурная постановка вопроса.
Подсмотрев, что делает IDEA, пробуем повторить и улучшить этот алгоритм. Для начала, заводим в амазоновском облаке здоровущий виртуальный инстанс с сотнями дискового пространства (а в exploded виде наше приложение довольно жирное) и гигабайтами оперативы.
В билды на тимсити, которые собирают WAR, добавляем дополнительный шаг сборки, который по SSH перекидывает их на тот жирный амазоновский инстанс, и также по SSH дёргает скрипт на bash, делающий следующее:
КОММИТЫ » ПУЛЛ РЕКВЕСТ » РЕВЬЮ КОДА || БИЛДЫ + ТЕСТЫ » РАЗВЁРТЫВАНИЕ QA ЭКЗЕМПЛЯРА » QA ИНЖЕНЕРЫ ЕГО МУЧАЮТ » РЕЛИЗ
Так, минуточку, а наши любимые QA инженеры что, вручную будут, что ли, в облако по SSH ходить, томкэт из командной строки запускать? Как-то не супер. Можно бы автоматически его поднимать, но неудобно, так как фич-бранчей уже под 60, и память даже на самом жирном инстансе всё-таки не резиновая. Тормозить будет.
nginx у нас уже поднят, настроить в нём classic CGI — как два байта об файерволл. А что такое classic CGI? Это когда на стандартный вход какого-то бинарника подаётся HTTP-запрос со всеми заголовками, и ставятся некоторые переменные окружения, а со стандартного выхода забирается HTTP-ответ, также со всеми заголовками. Тоже проще пареной репы, всё это можно буквально руками сделать.
Руками? Так не написать ли мне обработчик директории /deployments на bash? Потому что, наверное, могу. Как напишу, да как выложу на list.dev.стартап.ком (доступен будет только из внутренней сети стартапа, как и все экземпляры)… Иногда хочется чего-нибудь не только полезного, но и слегка ненормального. Такого, как минимальный обработчик HTTP-запросов на bash.
Вот и написал. Реально, скрипт на bash, который при помощи awk, sed, grep, find, и такой-то матери пробегается по поддиректориям /deployments, и выцепляет, где в какой что лежит. Номер билда, номер гитовой ревизии, имя фич-бранча — вся эта фигня и так на всякий случай уже передавалась из TC вместе с WAR-ником.
Заработало с полпинка. Один недостаток — парсить входные команды вида list.dev.стартап.ком/refresh?start=d### при помощи регулярок bash и никсовых утилит всё же не очень удобно. Но это уже я сам виноват — придумал глобальные слэш-команды и знак-вопроса-действия для экземпляров. Да, и вызывались внешние утилиты там для 60 поддиректорий много сотен раз, отчего консолька работала небыстро.
Проходит ещё совсем немного времени, и набор тесткейсов разрастается до такой степени, что QA инженерам приходится насоздавать довольно много сущностей в базе экземпляра, чтобы пройти полный цикл регресса для крупной фичи. А это уже и не один день. И если за это время разработчик успел что-то накоммитить в ветку по итогам ревью кода, то база экземпляра будет после билда развёрнута заново, отчего сущности потеряются. Упс.
Добавляем возможность сделать моментальный снимок для задеплоенного экземпляра. Его привязываем уже к номеру гитовой ревизии (там циферки, по результатов экспериментов, вполне уникальные), и складываем в /deployments/s### (другая буква префикса, чтобы у экземпляров и снимков были разные пространства имён). Деплоим примерно тем же скриптом, что и с тимсити, только базу копируем не из дампа, а существующую.
Так QA инженеры получают возможность тестировать конкретную ревизию до посинения, за это время разработчик может коммитить в основную ветку исправления по ревью сколько нужно. Потом, перед релизом, проверяться будут уже только эти точечные изменения в основном экземпляре.
КОММИТЫ » ПУЛЛ РЕКВЕСТ » РЕВЬЮ КОДА || БИЛДЫ + ТЕСТЫ » РАЗВЁРТЫВАНИЕ QA ЭКЗЕМПЛЯРА || СНИМОК QA ЭКЗЕМПЛЯРА » QA ИНЖЕНЕРЫ ЕГО МУЧАЮТ » РЕЛИЗ
Ого! Всего-то за полгода с хаотического процесса, когда разработчики коммитят фичи кто во что горазд, мы пришли к логичной, стройной системе continuous integration pipeline, где каждый шаг регламентирован, и каждый инструмент максимально автоматизирован.
Стоит только разработчику создать PR, как процесс деплоймента тестового экземпляра уже, считай, запущен, и буквально через час (если повезёт — число параллельных фич-бранчей с ростом команды вскоре возросло до сотни, пришлось поднимать аж семь инстансов под TC) у QA будет готовая к тестированию фича. Гоняй хоть вручную, хоть скриптами через REST API, а если надо, то диагностируй её и разбирайся с багами при помощи консоли управления тестовыми экземплярами.
Ну а дальше уже лирика. Через некоторое время тормоза консоли всем надоели, и мне пришлось вспоминать молодость, переписав её с bash (жаль, вся ненормальность этого маленького проекта разом потерялась) на обычный скучный PHP (впрочем, не на Java же такие задачи делать, в самом деле), а один из фронтеров сподобился переделать UI из олдскульного plain HTML на вполне современное ангуляровское приложение. Впрочем, я настоял на сохранении интерфейса а-ля девяностые, просто по приколу. Добавилась возможность просмотра stdout и stderr у томкэта. Сделали специальный CLI интерфейс для вызова REST API прямо на месте, ну и ещё немножко маленьких полезняшек.
Жутко удобная штука получилась.*
Вы только посмотрите, какие счастливые лица у команды QA инженеров!
Напишите мне. С удовольствием рассмотрю предложения о работе в местах, где нужны матёрые (больше 10 лет опыта) специалисты с Primary Skill == Java, и возможностью иногда позаниматься подобного рода ненормальным программированием. Или процессами порулить. Можно всё сразу.
Только в Москву переехать не смогу. А вот поработать удалённо — с удовольствием.
Зачем нужен DevOps и кто такие DevOps-специалисты
Когда приложение не работает, меньше всего хочется услышать от коллег фразу «проблема на вашей стороне». В итоге страдают пользователи – а им всё равно, какая часть команды несет ответственность за поломку. Культура DevOps появилась как раз затем, чтобы сплотить разработку и поддержку и объединить их вокруг общей ответственности за конечный продукт.
Какие практики входят в понятие DevOps и зачем они нужны? Чем занимаются DevOps-инженеры и что они должны уметь? На эти и другие вопросы отвечают эксперты из EPAM: Кирилл Сергеев, системный инженер и DevOps-евангелист, и Игорь Бойко, ведущий системный инженер и координатор одной из DevOps-команд компании.
Зачем нужен DevOps?
Раньше между разработчиками и поддержкой (т. н. operations) существовал барьер. Звучит парадоксально, но у них были разные цели и KPI, хотя они и делали общее дело. Целью разработки было как можно быстрее реализовать бизнес-требования и добавить их в работающий продукт. Поддержка отвечала за то, чтобы приложение стабильно работало – а любые изменения ставят стабильность под угрозу. Налицо конфликт интересов – DevOps появился, чтобы его решить.
Что такое DevOps?
Вопрос хороший – и спорный: окончательно в мире об этом пока не договорились. В ЕРАМ считают, что DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.
Кирилл Сергеев: «Разработчики пишут код, тестировщики его проверяют, а администраторы устанавливают финальный продукт на производственное окружение. Долгое время эти части команды были несколько разрознены, а потом появилась идея объединить их общим процессом. Так появились DevOps-практики».
Настал тот день, когда разработчики и системные инженеры заинтересовались работой друг друга. Барьер между производством и поддержкой стал стираться. Так появился DevOps, в который входят практики, культура и порядок взаимодействия в команде.
В чем состоит суть DevOps-культуры?
В том, что ответственность за конечный результат лежит на каждом из участников команды. Самое интересное и сложное в философии DevOps – понять, что конкретный человек не просто отвечает за свой этап работы, а несет ответственность за то, как будет работать весь продукт. Проблема лежит не на чьей-то стороне – она общая, и каждый член команды помогает ее решить.
Важнейшее положение DevOps-культуры – именно решать проблему, а не просто применять DevOps-практики. Более того, эти практики внедряют не «на чьей-то стороне», а в весь продукт. Проекту нужен не сам по себе DevOps-инженер – ему нужно решение проблемы, а роль DevOps-инженера может быть распределена по нескольким членам команды с разной специализацией.
Какие бывают DevOps-практики?
DevOps-практики покрывают все этапы жизненного цикла ПО.
Игорь Бойко: «Идеальный случай – когда мы начинаем использовать DevOps-практики прямо при инициации проекта. Вместе с архитекторами мы планируем, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, выбираем платформу. Сейчас в моде микросервисная архитектура – для нее мы выбираем систему оркестрации: нужно уметь управлять каждым элементом приложения по отдельности и обновлять его независимо от других. Еще одна практика – это “инфраструктура как код”. Так называют подход, при котором инфраструктура проекта создается и управляется при помощи кода, а не через прямое взаимодействие с серверами.
Дальше мы переходим на этап разработки. Здесь одна из крупнейших практик – построение CI/CD: нужно помочь разработчикам интегрировать изменения в продукт быстро, мелкими порциями, чаще и безболезненней. CI/CD покрывает и проверку кода, и заливку мастера в кодовую базу, и разворачивание приложения на тестовых и продуктивных средах.
На этапах CI/CD код проходит через quality gates. С их помощью проверяют, чтобы код, который вышел с рабочей станции разработчика, соответствовал заданным критериям качества. Здесь добавляется юнит- и UI-тестирование. Для быстрого, безболезненного и фокусированного разворачивания продукта можно выбрать подходящий тип деплоймента.
DevOps-практикам есть место и на стадии поддержки готового продукта. Их применяют для мониторинга, обратной связи, безопасности, внедрения изменений. На все эти задачи DevOps смотрит с точки зрения постоянных улучшений. Мы сводим к минимуму повторяющиеся операции, автоматизируем их. Сюда же относятся миграции, расширение приложения, поддержка работоспособности».
Чем полезны DevOps-практики?
Если бы мы писали учебник по современным практикам DevOps, на его первой странице значились бы три пункта: автоматизация, ускорение релиза и быстрая обратная связь от пользователей.
Кирилл Сергеев: «Первое – это автоматизация. Все взаимодействия в команде мы можем автоматизировать: написали код – выкатили – проверили – установили – собрали фидбэк – вернулись в начало. Всё это – автоматически.
Второе – ускорение выхода релиза и даже упрощение разработки. Заказчику всегда важно, чтобы продукт вышел на рынок как можно скорее и начал приносить пользу раньше, чем аналоги конкурентов. Процесс доставки продукта можно бесконечно улучшать: сокращать время, добавлять дополнительные контрольные метки, совершенствовать мониторинг.
Третье – это ускорение обратной связи от пользователя. Если у него есть замечания, мы можем сразу же вносить корректировки и тут же обновлять приложение».
Как соотносятся понятия «системный инженер», «билд-инженер» и «DevOps-инженер»?
Они пересекаются, но относятся к немного разным сферам.
Системный инженер в ЕРАМ – это должность. Они бывают разных уровней: от джуниора до chief-специалиста.
Билд-инженер – это скорее роль, которую можно выполнять на проекте. Сейчас так называют людей, ответственных за CI/CD.
DevOps-инженером называют специалиста, который внедряет на проекте DevOps-практики.
Если суммировать всё это, получается примерно следующее: человек в должности системного инженера исполняет на проекте роль билд-инженера и занимается там внедрением DevOps-практик.
Чем именно занимается DevOps-инженер?
DevOps-инженеры собирают воедино все части, из которых состоит проект. Они знают специфику работы программистов, тестировщиков, системных администраторов и помогают упростить их работу. Они понимают потребности и требования бизнеса, его роль в процессе разработки – и строят процесс с учетом интересов заказчика.
Мы много говорили про автоматизацию – ею DevOps-инженеры занимаются в первую очередь. Это очень большой пункт, в который, помимо прочего, входит подготовка окружения.
Кирилл Сергеев: «Прежде чем внедрять обновления в продукт, их нужно протестировать на стороннем окружении. Его готовят DevOps-инженеры. Они же насаждают на проекте DevOps-культуру в целом: внедряют DevOps-практики на всех слоях своих проектов. Эти три принципа: автоматизация, упрощение, ускорение – они привносят всюду, куда могут дотянуться».
Что должен знать DevOps-инженер?
По большому счету, у него должны быть знания из разных областей: программирование, работа с операционными системами, базами данных, системами сборки и конфигураций. К ним добавляется умение работать с облачной инфраструктурой, системами оркестрации, мониторинга.
1. Языки программирования
DevOps-инженеры знают несколько базовых языков для автоматизации и могут, например, сказать программисту: «Давай ты будешь делать установку кода не руками, а с помощью нашего скрипта, который всё автоматизирует? К нему мы подготовим config-файл, его будет удобно читать и тебе, и нам – и мы в любой момент сможем его изменить. А еще мы будем видеть, кто, когда и для чего вносит в него изменения».
DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.
2. Операционные системы
DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.
3. Системы контроля версий
Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.
4. Облачные провайдеры
AWS, Google, Azure – особенно если мы говорим про Windows-направление.
Кирилл Сергеев: «Облачные провайдеры предоставляют нам виртуальные сервера, которые прекрасно ложатся на рельсы CI/CD.
Установка десяти физических серверов требует порядка ста ручных операций. Каждый сервер нужно вручную запустить, установить и настроить нужную операционную систему, установить наше приложение на этих десяти серверах, а потом десять раз всё перепроверить. Облачные сервисы заменяют эту процедуру десятью строчками кода, и хороший DevOps-инженер должен уметь ими оперировать. Так он экономит время, силы и деньги – и для заказчика, и для компании».
5. Системы оркестрации: Docker и Kubernetes
Кирилл Сергеев: «Виртуальные сервера разделены на контейнеры, в каждый из которых мы можем установить наше приложение. Когда контейнеров много, надо ими управлять: один включить, другой выключить, где-то сделать бэкапы. Это становится довольно сложным делом, для которого нужна система оркестрации.
Раньше каждым приложением занимался отдельный сервер – любые изменения в его работе могли повлиять на исправность приложения. Благодаря контейнерам приложения становятся изолированными и запускаются по отдельности – каждое на своей виртуальной машине. Если происходит сбой, не нужно тратить время на поиск причины. Проще уничтожить старый контейнер и добавить новый».
6. Системы конфигураций: Chef, Ansible, Puppet
Когда необходимо обслуживать целый парк серверов, приходится делать много однотипных операций. Это долго и сложно, а еще ручная работа повышает шанс ошибки. Тут на помощь приходят системы конфигураций. С их помощью создают скрипт, который удобно читать и программистами, и DevOps-инженерами, и системными администраторами. Этот скрипт помогает проводить одинаковые операции на серверах автоматически. Так ручных операций (и, следовательно, ошибок) становится меньше.
Какую карьеру может построить DevOps-инженер?
Развиваться можно и горизонтально, и вертикально.
Игорь Бойко: «С точки зрения горизонтального развития, у DevOps-инженеров сейчас самые широкие перспективы. Всё постоянно меняется, и наращивать навыки можно по самым разным направлениям: от систем контроля версий до мониторинга, от управления конфигурациями до баз данных.
Можно стать системным архитектором, если сотруднику интересно разобраться, как работает приложение на всех этапах своего жизненного цикла – от разработки до поддержки».
Как стать DevOps-инженером?
А также можно посмотреть актуальные тренинги по DevOps на сайте Тренинг-центра EPAM.
Больше информации о DevOps-направлении на сайте.