Как стать DevOps-специалистом? Разбираем пять реальных требований

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

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

№1. Управление Linux-серверами и инфраструктурой с использованием IaC-инструментов

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

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

Другие преимущества Terraform и Ansible — простой синтаксис и понятное использование. Для примера, Puppet Server требует сильно больше времени и сил для настройки. У Ansible serverless архитектура, и в этом есть как плюсы (простота и скорость), так и минусы (поддержание актуальности конфигураций на парке серверов требует определённых навыков).

Даже если в вакансиях явно не указаны Terraform или Ansible, всё равно стоит в них разбираться. Например, у нас обязательным требованием является знание Ansible. Но навык работы с Terraform или эквивалентным решением — большой плюс, который может пригодиться в самый неожиданный момент.

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

№2. Опыт Gitlab CI: настройка доставки кода на Python, Go

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

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

№3. Опыт настройки и поддержки PostgreSQL, Kafka, Redis, Aerospike, Consul

Ключевые системы, которые нужно знать:

  • PostgreSQL — популярная реляционная база данных.
  • Kafka — брокер сообщений для потоковой обработки данных.
  • Consul — мощный инструмент для построения Service Discovery и не только.
  • Aerospike — высокопроизводительная NoSQL-база.
  • Redis — одна из самых популярных высокопроизводительных in-memory баз данных.

№4. Опыт с системами мониторинга и логирования: Prometheus, Grafana, Zabbix, ELK, Sentry

У нас есть всё вышеперечисленное и даже больше. Правда вместо Prometheus у нас Victoria Metrics.

На что обращать внимание при мониторинге? Это, конечно, четыре золотых сигнала:

  1. Задержка (Latency): время отклика системы.
  2. Трафик (Traffic): объём запросов.
  3. Ошибки (Errors): количество ошибок.
  4. Насыщенность (Saturation): загрузка ресурсов.

№5. Контейнеризация: Docker, docker-compose, Kubernetes, Helm

Docker — базовая технология для контейнеризации приложений. Все наши новые сервисы по умолчанию упаковываются в Docker-контейнеры перед тем, как выкатываться в development/production окружения.

У Docker очень простой порог входа. Контейнеризация была одной из первых задач всех новичков, приходящих в инфраструктурную команду. Это позволяло пройти весь путь от создания сервиса до его деплоя в прод. Если вам кажется, что это сложно, то стоит взять небольшой проект, например запуск веб-сервера Nginx. Парочка занимательных вечеров, и у вас всё получится!

Итоги

Главная мысль статьи — для наработки опыта нужно его нарабатывать 🙂 Для начала брать простые проекты, чтобы понять основы, а затем поднимать уровень сложности.