∞ Дорожная карта DevOps-инженера в 2023 году

Подробная и актуальная дорожная карта по DevOps.

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

Много людей (включая меня) считают, что нет никаких «DevOps-инженеров» или «DevOps-команд». Тем не менее, в индустрии все уже привыкли к термину «DevOps-инженер», и если вы понимаете философию DevOps, то звания не имеют значения.

В конце статьи я добавил различные команды, в которые может вступить DevOps-инженер.

Существует много заблуждений насчёт того, что такое DevOps. Одним из таких заблуждений является «Автоматизация — это DevOps». Развития навыков, связанных с автоматизацией инфраструктуры, недостаточно, чтобы стать DevOps-инженером.

На основании вышеуказанного определения видно, что DevOps — это не про инструменты или технологии. Это философия, заставляющая разные IT-команды (разработчиков, платформенные команды, QA, Performance и т. д.) работать вместе, чтобы достичь лучших и более быстрых результатов с помощью непрерывного фидбэка.

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

Кто такой DevOps-инженер?

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

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

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

Например, по моему опыту работы DevOps-инженером, открытый диалог с различными командами решит гораздо больше проблем, чем тупое следование своду правил. (И поверьте мне, это сложнее, чем кажется 🙂).

Другая цель DevOps-инженеров — автоматизировать повторяющиеся задачи и уделять больше времени инженерии и инновациям.

Дорожная карта DevOps-инженера

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

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

Эта статья объяснит, как следует готовиться к становлению DevOps-инженером, практикующим соответствующую философию.

Понимание культуры DevOps

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

Следующей картинкой всё сказано.

Например, если вы DevOps-инженер, никогда не говорите «Это не моя работа», но говорите «Я посмотрю, что могу сделать». То, как вы ответите, значительно повлияет на совместную работу. (Это не значит, что нужно всем всё разжевывать и делать работу за других).

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

Люди перестанут скрывать правду и винить других за проблемы с проектом, как только поймут, что проблема в доставке проекта должна решаться совместными усилиями. Для примера можно взглянуть на blameless postmortem.

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

Я бы посоветовал прочитать State of DevOps Report от puppet. Это обязательный к прочтению отчёт о DevOps для инженеров и руководителей.

Книга

• Проект «Феникс». Как DevOps устраняет хаос и ускоряет развитие компании. Ким Джин, Бер Кевин
  

Научитесь использовать инструменты генеративного ИИ

Учитесь учиться.

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

Мы живём в эпоху множества технологических прогрессов с использованием инструментов ИИ. Будучи инженером, необходимо использовать инструменты генеративного ИИ по типу ChatGPT и Google Bard, чтобы без лишней траты времени понять основы. Это достигается за счёт того, что такие инструменты могут разговаривать с вами простым языком. А с плагинами ChatGPT можно вывести свою продуктивность на следующий уровень.

Так что делайте сложную работу с умом 🙂

Кроме того, я спросил ChatGPT, заменят ли инструменты ИИ DevOps-инженеров. Вот, что я получил в ответ.

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

Изучите Linux

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

Согласно The Linux foundation case study, 90% нагрузки на публичное облако работает на Linux.

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

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

Когда речь идёт о Linux, всё завязано на терминале, так как в мире *nix GUI менее предпочтителен. Вы можете использовать Virtual box с Vagrant или AWS/GCP/Azure, чтобы запустить сервера Linux.

Можно начать следующим образом.

1. Понять процесс загрузки Linux.
2. Понять systemd.
3. Установить и настроить веб-сервера (Apache, Nginx, Tomcat и пр.) и изучить, как они работают.
4. Изучить работу процессов Linux.
5. Научиться устанавливать HTTP-прокси.
6. Узнать, как работает SSH.
7. Изучить разные файловые системы.
8. Понять, как в Linux работают тома.
9. Изучить системное логирование, мониторинг и устранение неполадок.
10. Изучить важные протоколы (SSL, TLS, TCP, UDP, FTP, SFTP, SCP, SSH).
11. Научиться управлять сервисами и попробовать самостоятельно создать сервис (Initd, Systemd).
12. Разместить статические/динамические веб-сайты на веб-серверах и поиграть с настройками.
13. Понять разницу между балансировщиком нагрузки и обратным прокси.
14. Настроить балансировщики нагрузки и обратные прокси (Nginx, HA proxy и т. п.). Понять каждую конфигурацию и алгоритмы балансировки нагрузки.
15. Научиться оптимизировать производительность Linux.
16. Настроить базу данных и понять, как с ней работать.
17. Поломать что-нибудь и научиться устранять неполадки.

Связанные сертификаты

• Linux Foundation Certified System Administrator (LFCS)

Изучите работу компонентов инфраструктуры

Базовым строительным блоком любой организации является её инфраструктура. Она может быть расположена в облаке или в локальном дата-центре.

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

Есть большая разница между «Оно не работает, можете взглянуть?» и «Так, я провёл изначальную диагностику, и вот, что нашлось. Вы можете дальше изучить этот вопрос и помочь нам понять, в чём проблема?»

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

Сети:

1. Модель OSI/Модель TCP-IP
2. Сетевые топологии
3. Нотации CIDR
4. Работа с подсетями
5. Публичная сеть
6. Частная сеть
7. Статические/Динамические IP-адреса
8. Файервол
9. Прокси
10. NAT
11. Публичный и частный DNS
12. VPN
13. Протоколы IPv4 и IPv6

Хранение данных:

1. SAN
2. Резервное копирование
3. NFS
4. Объектное хранилище
5. IOPS/throughput/latency диска
6. Базы данных
7. Базы данных «ключ-значение»

Отказоустойчивость:

1. Кластеры
2. Механизмы аварийного переключения
3. Аварийное восстановление
4. Вертикальное масштабирование
5. Горизонтальное масштабирование

Технология единого входа:

1. Active Directory/LDAP
2. SAML

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

1. SSL-сертификаты
2. Инфраструктура открытых ключей
3. Нулевое доверие
4. Ротация паролей/секретов
5. Соответствие требованиям безопасности
6. Site-to-site VPN
7. Client-to-site VPN

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

1. L4-балансировщики
2. L7-балансировщики
3. Алгоритмы балансировки нагрузки
4. Обратный прокси

Есть и больше, но я выделил основные компоненты IT-инфраструктуры, которые вам могут попасться в повседневной работе.

Изучите облачные вычисления и виртуализацию

Облачные вычисление и виртуализация — основы практики DevOps на сегодняшний день.

Вы можете начать с изучения концепций виртуализации, используя такие инструменты, как Virtualbox и Vagrant (виртуализация второго типа). Это база облачных вычислений.

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

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

Большая часть публичной доли рынка облачных вычислений в данный момент принадлежит AWS. Вот последний отчёт от Statista.

Выберите любое публичное облако, предпочтительно AWS, и изучите все его главные инфраструктурные услуги. Попрактикуйтесь в них и поймите, как они работают.

Посмотрите видео AWS re:Invent и узнайте, как другие организации используют сервисы AWS для хостинга их приложений.

Поверьте мне, из этих видео можно многое почерпнуть, и никакое онлайн-обучение не даст столько же информации о том, как запускать рабочие нагрузки продакшена на AWS.

Если вы планируете сертифицироваться на GCP, посмотрите их видео Google Next.

Используйте сертификации, чтобы оценить свои знания выбранных платформ.

Изучите автоматизацию инфраструктуры

Мы больше не создаём серверы вручную. Инструменты автоматизации инфраструктуры стали неотъемлемой частью любой организации. Кроме того, все современные развёртывания инфраструктуры следуют модели неизменяемой инфраструктуры.

Согласно отчёту от Redhat, многие организации инвестируют в свои автоматизационные инициативы. Взгляните на следующие данные.

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

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

1. Vagrant
2. Docker Desktop
3. Minikube (k8s)
4. Minishift (k8s)
5. Kind (k8s)

Для подготовки инфраструктуры:

1. Terraform (предпочтительно)
2. Cloudformation для AWS
3. CLI (соответствующего облачного провайдера)
4. Pulumi

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

1. Ansible (предпочтительно)
2. Chef
3. Puppet
4. Saltstack

Управление контейнерами/образами ВМ:

1. Hashicorp Packer
2. Docker

Далее представлены мои советы по изучению инструментов автоматизации.

1. Узнайте основы из блога, официальной документации или курса. Любого, который вам комфортен.
2. Если вы хотите написать плейбук Ansible для Nginx, для начала вручную настройте Nginx и посмотрите, как работают компоненты и конфиги. Затем начните писать плейбук.
3. Убедитесь, что изучаете разработку инфраструктуры через тестирование. Для каждого инструмента автоматизации есть инструменты тестирования (Ansible-test, terratest и т. д.)
4. Модули сообщества — отличное подспорье в обучении. По ним можно научиться сложной логике.
5. При использовании модулей сообщества убедитесь, что знаете, что делает каждый блок кода.

Изучите оркестрацию контейнеров и распределённые системы

Распределённые системы — это основа современных масштабируемых инфраструктур. Вам необходимо понимать базовые концепции распределённых систем, потому что большая часть инструментов, которые вам понадобятся при работе с микросервисами, по своей природе являются распределёнными. Например, Kubernetes.

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

Как только поймёте Docker, можно начать изучение инструментов оркестрации контейнеров, например Kubernetes, DockerSwarm и т. д.

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

Вот интересный тренд использования Kubernetes от Datadog.

Следующее изображение показывает, как за пять лет увеличилась частота поиска для Kubernetes.

К тому же, многие инженеры и даже выпускники заинтересованы в изучении Kubernetes. В 2023 в нём сертифицируется множество человек. Вы можете взглянуть на наши гайды по экзаменам CKA, CKAD, и CKS. Вы можете выбрать лучший сертификат по Kubernetes в зависимости от того, с каким доменом хотите работать.

Service mesh (сервисная сетка) — это более сложная тема в сфере контейнеров. Если вы только начинаете, вам стоит изучить её после получения достаточных знаний об оркестровке контейнеров и микросервисной архитектуре. У CNCF имеется множество инструментов service mesh. Вы можете взглянуть на лучшие из них.

Логирование, мониторинг и наблюдаемость

Наблюдаемость, логирование и мониторинг — основополагающие аспекты инфраструктуры.

Все приложения в инфраструктуре дают логи и метрики. Логи пушатся и хранятся в инфраструктуре логирования на основании архитектуры и дизайна.

У каждой компании есть инфраструктуры логирования и мониторинга. Распространёнными стеками логирования являются Splunk и ELK. Кроме того, есть несколько SaaS-компаний наподобие Loggly, которые предоставляют инфраструктуру логирования.

Если говорить о мониторинге, есть такие open-source инструменты, как Prometheus и Nagios, и корпоративные инструменты, как AppDynamics, Datadog, SignalFx и пр. Вы можете взглянуть на наш блог о лучших open-source инструментах мониторинга.

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

В каждой организации критически важные приложения мониторят 24/7 с помощью панелей мониторинга. Обычно панели используют данные из источников логирования или метрики, сгенерированные приложением.

Также есть системы оповещения, которые используют правила оповещений, настроенные в системах мониторинга.

Как пример, оповещение может прийти в виде уведомления в Slack, тикета в Jira, оповещения на почте, тикета инцидента на ServiceNow или телефонного звонка xMatters. Рабочие процессы оповещений различны от организации к организации.

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

Книга

• Art of Monitoring [Электронная книга]
  

Изучите лучшие практики безопасности (DevSecOps)

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

Одной из обсуждаемых в DevSecOps тем является подход Shift Left Security. Это всего лишь применение практик безопасности на стадиях проектирования/разработки.

Вы можете ознакомиться с Шестью Столпами DevSecOps от Cloud Security Alliance.

Вот интересный обзор безопасности от 2020 года от Checkpoint, в котором показаны различные кибератаки по регионам.

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

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

Следующее изображение показывает ключевые практики DevSecOps, опубликованные Redhat.

Hashicorp Vault — это отличный инструмент для управления секретами. Там представлено множество воркфлоу для управления секретами среды.

Отчёт о безопасности State of API от Salt Security показывает, что наблюдается увеличение на 681% в количестве атак на API.

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

Скриптинг для DevOps-инженера необходим. В настоящее время во время собеседований в DevOps любая порядочная компания проводит предварительный раунд скриптинга/программирования.

Вот отрывок из официального блога google cloud, в котором говорится о навыках, необходимых для инженера облачных сервисов. В нём говорится «‎Код не подлежит обсуждению».

Тем или иным образом вы будете использовать программы и скрипты в процессе CI/CD. Вы можете выучить следующие распространённые скриптовые языки:

1. Bash/Shell
2. Python
3. Golang

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

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

Я бы предложил выбрать язык программирования и создать приложение с нуля. Когда я только начинал карьеру, я написал целое веб-приложение на Ruby on Rails, хотя разработка не была моей основной работой. Это до сих пор помогает мне понять многие концепции мира разработчиков. Даже парни из Google Cloud советуют то же самое.

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

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

Например:

1. pipeline as code в Jenkins требует понимания Groovy.
2. Кастомный модуль Ansible требует понимания Python.
3. Написание оператора Kubernetes требует опыта работы с Golang.

Если взглянуть на AWS CDK или инструмент IaC по типу Pulumi, язык программирования можно использовать для определения инфраструктуры и проведения разработки инфраструктуры через тестирование.

Golang быстро набирает популярность в сфере DevOps. По сути, такие инструменты, как Kubernetes и Terraform, написаны на Go.

JFrog исследовал внедрение Golang во время GopherCon, и 18% опрошенных сказали, что они используют Golang для работы, связанной с DevOps.

Я предоставил достаточно причин, по которым вам стоит изучить программирование, будучи DevOps-инженером.

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

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

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

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

Так что же это за GitOps? Вот как это объясняет gitops.tech:

Следующее изображение от weave works показывает полную историю GitOps.

Ещё одна важная вещь — это документирование всех важных вещей, что вы делаете. У каждого репозитория должен быть файл readme, в котором вы лучше объясняете свой код. Хорошая документация поможет не только вам, но и тем, кто попытается воспользоваться вашим кодом.

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

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

1. Непрерывная интеграция.
2. Непрерывная доставка.
3. Непрерывное развёртывание.

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

Научитесь пользоваться любыми из нижепредставленных CI/CD-инструментов.

Вот хорошее графическое изображение процесса CI/CD от bmc.

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

1. Процесс планирования.
2. Процесс согласования и визирования архитектуры командой архитекторов.
3. Визирование инфраструктуры и дизайна / инструментов приложения командой безопасности.
4. Оценка соответствия регуляторным требованиям по работе с данными.
5. Управление конфигурациями/секретами.
6. QA/тестирование производительности и получение соответствующих согласований.
7. Документирование и настройка мониторинга KPI.
8. Процесс управления изменениями.
9. Процесс управления релизами.
10. Деятельность по проведению оценки после внедрения.
11. Сценарии и стратегии отката к предыдущей версии.

Ресурсы

1. Continuous Deployment at Lyft

DevOps vs SRE

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

Вот, что Google говорит о DevOps и SRE:

Я советую эти официальные документы от Google для лучшего понимания SRE.

1. What is SRE?
2. SRE vs. DevOps: competing standards or close friends?

Различные виды «‎DevOps-команд»‎

Сегодня каждая организация называет людей, работающих с инфраструктурой/CI-CD, «DevOps-инженерами»‎ и делает их частью «команды DevOps»‎. Тем не менее, их обязанности различаются в зависимости от команд, на которые они работают.

Насчёт «DevOps-инженеров»‎ есть заблуждение, что они за всё ответственны. Это не так. Но для небольших команд может сработать.

На самом деле, если вас наняли как «DevOps-инженера», вы можете попасть в одну из следующих команд в организации:

1. Главная платформенная команда (платформенный инжиниринг): отвечает за снабжение инфраструктурой по требованию. Эта команда отвечает за поставку масштабируемых порталов и сервисов самообслуживания для разработчиков и других команд. Они займутся не приложениями, а базовыми платформами. Они обеспечат доступность производственных систем 24/7 с помощью непрерывной поддержки и мониторинга платформ. Кроме того, они будут работать над новым инструментарием и автоматизацией для удовлетворения будущих потребностей. Конечными потребителями этой команды будут команды разработчиков либо AppOps. Так что, это скорее общая обязанность.
2. Команда DevOps: хотя выражение «команда DevOps» смысла не имеет, организации используют его для обращения к команде эксплуатации. Эта команда обычно тесно сотрудничает с разработчиками и помогает нескольким командам разработки. Они отвечают за непрерывную доставку приложений.
3. Команда AppOps: эта команда является частью определённых инженерных команд, работающих над определённой программой в организации, обладающая хорошими знаниями в задействованной области. Например, платёжная команда. Эта команда занимается деплоем и управлением платёжными приложениями. Управлением платформой займутся главная платформенная команда или команды DevOps.
4. Команда SRE: эта команда занимается автоматизацией, доступностью, задержками, производительностью, управлением изменениями, мониторингом, экстренным реагированием и планированием мощностей. Они тесно сотрудничают с разработчиками для решения оперативных проблем. Эта команда состоит из инженеров с опытом разработки, работающих над инфраструктурой.
5. Выделенная команда поддержки: команды поддержки должны устранять неполадки/обрабатывать тикеты по продакшену и направлять проблемы соответствующих команд в зависимости от серьёзности. У этой команды есть дальнейшая классификация на уровни L1, L2 и L3.

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

Роли и обязанности DevOps-инженера

Каждая компания имеет различные роли и обязанности.

Вы можете задать следующие вопросы, чтобы понять, чем будете заниматься в качестве DevOps-инженера.

1. Каковы повседневные работы по проекту?
2. Есть ли какие нибудь активные задачи по автоматизации, или это проект по поддержке?
3. Какие инструменты DevOps сейчас используются на проекте?
4. В пайплайне есть новые работы по миграции или разработке?
5. Как выглядит дорожная карта проекта?
6. Как часто будет осуществляться on-call support? Будет ли за него компенсация?
7. Будут ли чередующиеся ночные смены?
8. Рабочее время фиксированное, или изменится при изменении проекта?
9. Есть ли культура работы по выходным?
10. Спросите про размер команды.. Вы же не хотите выгореть!

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

В общем, вот, что следует знать о повседневной работе DevOps-инженера.

1. DevOps-инженеры не создают пайплайны и автоматизируют каждый день. Большая часть работы над автоматизацией — это разовая деятельность.
2. DevOps-инженеры должны принимать участие в деятельности on-call для поддержки проекта. Хотя некоторые проекты являются исключениями.
3. Вы можете быть частью платформенной команды, команды приложения, команды поддержки.
4. Если вы в составе команды платформенной инженерии, непрерывная разработка и инновации являются частью создания инструментов платформы. Это будет чудесным учебным опытом.
5. Если вы в составе команды AppOps, вам придётся использовать инструменты, разработанные платформенной командой, и могут быть возможности расширить набор в соотвествии с требованиями. Но вы сможете принимать участие в ежедневных встречах и понять, что происходит на проекте.
6. Если вы в составе команды поддержки, вы получаете плейбук о том, как решать проблемы, но вероятность того, что вам удастся принять участие в обсуждении вопросов проектирования, не так велика.

Постарайтесь избегать ночных и чередующихся смен. Здоровье превыше всего.

Собеседования на позицию DevOps-инженера

За 10 лет я прошёл и провёл собеседования DevOps-инженеров для разных типов организаций. Требования могут меняться от организации к организации и от проекта к проекту.

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

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

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

FAQ для DevOps-инженера

Как попасть в DevOps?

Для DevOps нет единой дорожной карты. Если у вас есть опыт в разработке, QA, Performance или поддержке, вам следует изучить автоматизацию инфраструктуры и CI/CD. Если вы новичок, то для того, чтобы попасть в DevOps, нужно сконцентрироваться на программировании, концепциях ОС, облаке и контейнерах. Но прежде всего, надо выбрать реальный use case и поработать над ним, прежде чем появляться на собеседованиях. Здесь представлен список DevOps-задач.

Нужно ли программирование в DevOps?

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

Чем именно занимается DevOps-инженер?

Работа DevOps-инженера — это сотрудничество с разработчиками и кросс-функциональными командами для облегчения процесса CI/CD. А главное — это выделение времени инженерии для автоматизации повторяющихся задач. Помимо автоматизации инфраструктуры, DevOps-инженерам надо следить за устранением неполадок и мониторингом производственных и непроизводственных платформ и приложений.

Какие навыки нужны в DevOps?

Часто необходимыми для DevOps навыками являются программирование, концепции ОС, распределённые системы, сети, мониторинг, устранение неполадок, контейнеры, автоматизация инфраструктуры, управление конфигурациями, контроль версий и инструменты CI/CD, например Jenkins, GitlabCI, GitHub action, и т. д.

Каковы лучшие сертификаты для DevOps-инженера?

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

Заменят ли инструменты ИИ DevOps-инженеров?

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

Читайте блоги по DevOps

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

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

Подпишитесь на единомышленников на LinkedIn, Reddit, Medium, Quora, и т. п.

Ресурсы

1. How they DevOps
2. How they SRE

Документируйте ваши знания

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

Это поможет другим, а также создаст для вас бренд. Настройка блога на WordPress или Medium займёт меньше тридцати минут.

Или вы можете создать документацию репозитория на GitHub.

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

Я создал сообщество на DevOpsLearners для начинающих, где они могут публиковать свои блоги про облачные технологии/DevOps.

Заключение

Я поделился подробной и практичной дорожной картой DevOps, по которой вы можете начать карьеру DevOps-инженера. Убедитесь, что у вас есть хорошее понимание главных основ IT. Это значительно облегчит учебный процесс.

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

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

Источники

• https://devopscube.com/become-devops-engineer