Кто такой devops и как им стать

Стать инженером DevOps в 2021 году: подробное руководство

Что касается нынешнего ИТ-рынка, среда DevOps — один из лучших вариантов для ИТ-специалистов с точки зрения заработной платы и карьерного роста. И мне довольно часто задают вопрос: «Как стать инженером DevOps?»

В этом блоге я попытаюсь ответить на него на примере своего собственного опыта работы DevOps в различных организациях.

Многие утверждают (включая меня), что нет ничего похожего на “DevOps Engineer” или “DevOps Team”, потому что это не вещь. Однако сейчас все в отрасли уже привыкли к термину «инженер DevOps», и если вы понимаете философию DevOps, эти названия не имеют большого значения.

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

DevOps (обособленное сочетание разработки и эксплуатации) — это культура, движение или практика, которая подчеркивает сотрудничество и общение как разработчиков программного обеспечения, так и других специалистов в области информационных технологий (ИТ) при автоматизации процесса доставки программного обеспечения и изменений инфраструктуры.

Из этого определения ясно, что DevOps не зависит от каких-либо инструментов или технологий. Это философия, согласно которой разные ИТ-команды должны работать вместе для достижения лучших и быстрых результатов за счет постоянной обратной связи.

Вот интересный график тенденций, показывающий популярность DevOps за последние 5 лет.

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

Кроме того, проект или конвейер, разработанный командой, должен обеспечивать небольшие обновления или выпуски без серьёзного ручного вмешательства. Этого можно добиться только в том случае, если произойдет культурный сдвиг в работе команды.

Как стать инженером DevOps

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

В этой статье объясняется, как вам следует подготовиться к использованию инструментов и технологий для адаптации и работы в культуре DevOps.

В этой статье я рассмотрел многие темы. Новичок не может быть мастером всего. Однако наличие достаточного количества знаний в этих областях поможет вам продолжить карьеру в DevOps.

Поймите культуру DevOps

Прежде всего, необходимо понять культуру DevOps. Всё дело в объединении людей для эффективной работы над общей целью.

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

Люди перестанут указывать пальцем на различные проблемы, как только поймут, что в случае задержки или проблемы с реализацией проекта все его участники несут одинаковую ответственность.

Как только вы начнете практиковать культуру DevOps, вы перестанете говорить, что «это синоним CI/CD и автоматизации».

Узнайте больше о системах *nix

Мы живем в эпоху, когда не можем жить без систем Linux/Unix. Вы должны лучше понять и получить практические знания о различных дистрибутивах Linux, широко используемых организациями (RHEL, Centos, Ubuntu, CoreOS и т.д.).

Согласно тематическому исследованию Linux Foundation, 90 % рабочей нагрузки в публичных облаках обрабатывается на Linux.

Вот еще одно интересное исследование Redhat, в котором показаны различные дистрибутивы Linux, используемые в публичных облаках:

Теперь у вас есть достаточно причин, по которым вам стоит сосредоточиться на Linux.

Когда дело доходит до Linux, это всё про терминал, графический интерфейс менее предпочтителен в мире *nix.

Для запуска Linux-серверов вы можете использовать VirtualBox или AWS/GCP/Azure и множество других облачных платформ.

Начать изучение можно со следующего:

Разберитесь в процессе загрузки Linux.

Установите и настройте веб-серверы (Apache, Nginx, Tomcat и т.д.). И узнайте, как работают веб-серверы.

Узнайте, как работают процессы Linux.

Узнайте, как работает SSH.

Почитайте о различных файловых системах.

Изучите ведение системного журналирования, мониторинга и устранения неполадок.

Узнайте о важных протоколах (SSL, TLS, TCP, UDP, FTP, SFTP, SCP, SSH).

Научитесь управлять сервисами и попробуйте создать сервис самостоятельно (Initd, Systemd).

Попробуйте разместить статические и динамические сайты на веб-серверах.

Настройте балансировщики нагрузки и реверс-прокси (Nginx, HAproxy и т.д.).

Сломайте что-нибудь и научитесь устранять неполадки.

Разберитесь, как работают компоненты инфраструктуры

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

Сети

Внешний и локальный DNS

Хранилище

Отказоустойчивость(HA)

Безопасность

Технология единого входа(SSO)

Балансировщики нагрузки

Балансировка на разных уровнях модели OSI (L4, L7)

Алгоритмы балансировки нагрузки

Могло быть и больше пунктов, но я выделил только ключевые компоненты ИТ-инфраструктуры.

Научитесь автоматизировать

Автоматизация стала важным аспектом каждой организации. Мы больше не создаем серверы вручную. Мы это автоматизируем.

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

Для среды разработки

Для обслуживания инфраструктуры

CLI (соответствующего облачного провайдера)

Для управления конфигурацией

Управление образами ВМ

Контейнеры, распределенные системы и Service Mesh

Внедрение контейнеров растет день ото дня. Организация, в которой вы работаете, может сейчас не использовать контейнеры. Однако лучше всего иметь практические знания о таких технологиях, как Docker. Это даст вам некоторое конкурентное преимущество перед коллегами.

Как только вы изучите Docker, можете попробовать его инструменты кластеризации и оркестрации, такие как Kubernetes, Docker Swarm и т.д. Эти платформы лучше всего подходят для архитектуры на основе микросервисов.

Вот интересная тенденция использования Kubernetes по данным Datadog:

А вот пятилетняя тенденция роста поисковых запросов по Kubernetes:

Кроме того, многие инженеры проявляют интерес к изучению Kubernetes, и в 2021 году немало людей получат сертификаты по этой технологии (CA, CKAD и CKD).

Service mesh — это выделенный слой инфраструктуры с низкой задержкой для обеспечения взаимодействия между сервисами. Он даёт массу возможностей для межсервисного взаимодействия: балансировки нагрузки, шифрования трафика, авторизации, трассировки, обнаружения сервисов (service discovery) и использования паттерна автоматического выключения (circuit breaker), с которым можно ознакомиться тут. Service mesh — это сложная тема, когда дело касается распределенных систем. Если вы новичок в работе с инструментами для контейнеров, вы можете изучить это после получения хороших знаний об архитектуре на основе микросервисов.

Журналирование и мониторинг

Журналирование и мониторинг — очень важные аспекты инфраструктуры.

Большинство приложений, развернутых в инфраструктуре, будут создавать журналы. Основываясь на дизайне архитектуры, журналы будут передаваться и храниться в отдельном слое инфраструктуры.

Каждая компания будет иметь отдельный уровень инфраструктуры под журналирование. Обычно используются такие стеки, как Splunk, ELK и Graylog. Кроме того, существует несколько SaaS-компаний, таких как Loggly, которые предоставляют инфраструктуру для централизованного хранилища журналов.

Разработчики, системные администраторы и команда безопасности используют системные журналы для мониторинга, диагностики неполадок, аудита приложений и инфраструктуры.

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

Также на основании правил, настроенных в системах мониторинга, будут срабатывать оповещения. Например, оповещение может быть в виде уведомления в Slack или Telegram, задачи в Jira, простого email, SMS-сообщения или даже звонка на телефон. Все схемы оповещения могут разниться от компании к компании.

Как инженер DevOps, вы должны иметь доступ к журналам и уметь устранять неполадки во всех средах (Dev, QA, Stage, Prod). Понимание регулярных выражений очень важно для построения запросов в любом инструменте централизованного хранилища журналов.

Понимание лучших практик в сфере кибербезопасности (DevSecOps)

DevSecOps — ещё одна область, связанная с интеграцией практик безопасности на каждом этапе DevOps. Википедия говорит:

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

Обзор инфобезопасности в 2020 показывает распределение разных кибератак по регионам:

В облачных средах криптомайнинг является распространенной атакой. В основном это происходит, когда секреты облачного доступа хранятся плохо, так что хакеры получают к ним доступ.

Когда дело доходит до DevOps, управление секретами для приложений и компонентов инфраструктуры должно соответствовать стандартным методам обеспечения безопасности.

А вот основные стандартные практики DevSecOps, опубликованные Redhat:

Hashicorp Vault — отличный инструмент для управления секретами. Существует множество рабочих процессов для управления секретами среды.

Изучайте программирование

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

Например, для написания конвейера Jenkins в декларативном виде (как код) требуется знания Groovy; кастомный модуль Ansible требует знания Python; для написания оператора Kubernetes требуется опыт работы с Go.

Обратите внимание на следующие языки программирования, которые часто используются для написания скриптов или небольших программ:

Go действительно становится популярным в сфере DevOps. Его используют многие инструменты. Например, Kubernetes и Terraform написаны на Go. JFrog исследовал внедрение Go во время GopherCon, и 18 % респондентов заявили, что используют этот язык для работы, связанной с DevOps.

Изучите Git, научитесь документировать, узнайте о GitOps

Очень важно применять систему контроля версий ко всему, что вы делаете (кроме паролей и секретов). Git — лучший инструмент для этого. Для него доступно множество руководств, и изучение важных операций с Git не займет много времени.

Вы можете начать с Github или Bitbucket в качестве удаленного репозитория кода.

А как только вы поймете Git, изучите GitOps. Что этот такое?

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

Ещё очень важно документировать всё, что вы делаете. Каждый репозиторий должен иметь файл README, лучше объясняющий ваш код. Хорошая документация поможет не только вам, но и тем, кто попытается использовать вашу кодовую базу.

Освойте непрерывный жизненный цикл доставки приложений

Когда дело доходит до жизненного цикла доставки приложений, вам необходимо знать три важных концепции.

Continuous Integration (Непрерывная интеграция)

Continuous Delivery (Непрерывная доставка)

Continuous Deployment (Непрерывное развертывание)

Научитесь использовать инструменты CI/CD, такие как Jenkins, Gitlab CI, Travis CI и т.д. Вот хорошее графическое представление процесса CI/CD:

DevOps vs SRE

SRE — еще одна развивающаяся тема в сообществе DevOps. Это набор практик и философий, разработанных Google. Вот что компания говорит о DevOps и SRE:

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

Я рекомендую изучить официальные документы от Google:

Читать, читать и еще раз читать

Нет ничего лучше для приобретения знаний, чем чтение. Прочтите хотя бы один технический блог DevOps, связанный с инженерией. Следите за всеми значимыми инженерными блогами, такими как Netflix, Twitter, Google и т.д. Узнайте, как они используют правильный набор инструментов, стратегии развертывания и свои последние проекты с открытым исходным кодом.

Заключение

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

А теперь мне интересно услышать от вас:

Что из культуры DevOps вы применяете на практике у себя?

Каков путь становления DevOps инженером вы прошли?

В любом случае, делитесь вашими мыслями об этой статье в комментариях.

Источник

Кто такой DevOps и как им стать: план обучения

Авторизуйтесь

Кто такой DevOps и как им стать: план обучения

Кто такой DevOps-инженер, чем занимается и как им стать — рассказывает Василий Озёров, руководитель международной команды Fevlake и SVP of Infrastructure в Airpush Inc.

В этой статье я постараюсь рассказать о том, что требуется ИТ-специалисту, чтобы стать DevOps-инженером. Но сначала несколько слов о себе, чтобы познакомиться поближе. Меня зовут Василий, работаю SVP of Infrastructure в одной из рекламных компаний, владею собственным бизнесом и на досуге пишу в свой канал Хмельной DevOps.

С Unix системами я познакомился в далеком 2005 году, ещё будучи учеником лицея. О да, те незабываемые ночи, проведенные за установкой FreeBSD и компиляцией KDE из исходников. К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера.

И вот, наконец, я попал в геймдев компанию, где и начал свою карьеру DevOps-специалиста. Активное взаимодействие разработчиков и команды эксплуатации погрузили меня в доселе невиданный мир. До этого момента путь кода от разработчика на продакшн виделся мне огромной черной бездной, в которой было невозможно ничего разглядеть.

3–5 декабря, Онлайн, Беcплатно

Но, окунувшись в неё с головой, я понял, что все не так уж и страшно. Я увидел, как приложения собираются, как тестируются, как уходят в продакшн, где их видит весь интернет. Давайте приподнимем завесу тайны и посмотрим, как же стать успешным DevOps-инженером.

Что такое DevOps?

DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. Это культура, методика, если угодно. DevOps-движение возникло в 2008 году и было призвано решить накопившиеся проблемы. Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации.

Разработчики считали, что если код запустился у них локально, то нет проблем — можно запускать в продакшен. Если всё же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть разработчики разбираются». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую страдало качество конечного продукта. Сильно накладывало отпечаток ещё и то, что за один релиз выкатывалось очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.

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

В целом можно выделить ещё несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах.

В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд-инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps-специалисту остаётся проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.

Что должен знать DevOps-инженер?

Строго говоря, никаких специальных требований к DevOps-студенту не предъявляется, но вход в профессию будет намного легче, если вы с порога обладаете некоторыми навыками.

Senior System Administrator

Или хотя бы Middle. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open files, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.

Networking — CCNA

Очень важная вещь, хотя про это забывают многие разработчики. Я считаю, что нельзя писать онлайн-сервисы, не понимая, как работает сеть. Никто не говорит, что надо заучивать семь уровней модели OSI, но точно потребуется знать, как работает IP, TCP/UDP и, конечно, протокол уровня приложения — например, HTTP, HTTP/2. Это сохранит вам кучу нервов выискивая причины ошибки Connection Refused.

Junior Developer

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

Многие могут не согласиться со мной, аргументируя это тем, что код должен писать разработчик. Но, простите, если вы не понимаете, как создаётся программный продукт, то как вы будете автоматизировать его сборку, тестирование и депплой? Сможете ли вы заметить узкое место в архитектурном решении до того, как оно попадет на продакшн?

Чтобы ответить на эти вопросы, все же необходимо немного углубиться в основные понятия. С чего начать:

Junior DBA

На самом деле это входит в предыдущий пункт, но я все же решил его вынести отдельно. Поскольку все текущие проекты в любом случае используют базы данных, было бы неплохо уметь писать SQL запросы, использовать explain и понимать, как работают и зачем нужны index‘ы. Ну и до кучи посмотреть на популярные NoSQL решения.

Судя по моей личной статистике, чаще всего в DevOps приходят люди из эксплуатации, поскольку у разработчиков обычно не прокачан первый скилл из списка. Но я знаю два случая из жизни, когда senior developers становились DevOps, потому что им надоело, как работает эксплуатация. И, к слову, помимо технических навыков вам точно потребуются некоторые софт скилы. Как минимум вы будете очень много общаться со всеми заинтересованными сторонами. Также вы будете продвигать новые идеи и технологии, что потребует от вас умения ясно и четко доносить свои мысли и умение спорить. Про стрессоустойчивость писать не буду, но терпение вам точно понадобится, поскольку внедрить новую крутую технологию зачастую невозможно в течение одного дня.

Как стать DevOps-инженером?

Вообще DevOps-инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: Ruby, Python, Go или написать на чистых плюсах? А как мы будем доставлять изменения в продакшен, чтобы не поломать работающие системы?

Главное, что надо понимать, — DevOps-специалист обладает действительно хорошим кругозором. Чтобы его расширить необходимо постоянно заниматься самообучением. Ниже я привел примерные шаги, которые помогут вам вырасти из, например, системного администратора в DevOps-инженера. Запомните: список всего лишь указывает направление, оттачивать навыки придётся вам самим.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps-специалиста — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на Go? Теперь пишем на Ruby. Использовали Jenkins? Берём TeamCity. Поднимали Kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Заключение

Да, стать DevOps-инженером с нуля не так-то просто, серебряной пули не существует. Не существует её и в любой другой области. Всегда придётся изучать, читать, пробовать. Но после 10-ой итерации вы войдёте во вкус. Вы не будете пропускать ни одной интересной софтинки, станете изучать и пробовать всё новое и неизведанное. А новое и неизведанное — это всегда круто. Кто бы там что ни говорил, дерзайте!

Источник

Зачем нужен 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-направлении на сайте.

Источник