Как войти в мир DevOps: рецепт для новичков и не очень

DevOps — молодое направление на стыке разработки и системного администрирования. Оно появилось только в 2000-е годы, но уже сейчас без него немыслим ни один крупный проект. О том, как войти в DevOps, рассказал ведущий инженер DevOps Группы «Иннотех» Илия Карин.

Илия Карин

Ведущий инженер DevOps Группы «Иннотех»

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

О начале карьерного пути

Ещё во время учёбы начал работать в кол-центре одного интернет-провайдера на позиции специалиста технической поддержки. Там я понял, что трудиться в техподдержке хоть и забавно, но не очень интересно. После вуза устроился системным администратором. Занимался поддержкой пользователей, серверов, маршрутизаторов и другого железа. Сейчас это называется модным словосочетанием фулстек-админ.

Сисадмином был около семи лет. Успел получить опыт работы с хелпдеск-отделами, дошёл до проектирования и внедрения собственной архитектуры, оптимизировал ИТ-инфраструктуру в компаниях, набирал и обучал людей для формирования 1–3-й линий техподдержки.

В какой-то момент услышал новое слово DevOps. Далее последовали полтора года интенсивного самообучения. И я стал девопс-инженером. Сейчас курирую работу специалистов в группе автоматизации процессов разработки цифровых решений. Мы занимаемся автоматизацией доставки ПО до контуров тестирования, продакшена и так далее. Развиваем DevOps-практики, делаем так, чтобы всем жилось лучше и комфортнее.

Из кого получаются хорошие DevOps-инженеры

Есть шуточное определение, что DevOps — это сисадмин на стероидах. Путь в девопс хорошо складывается, когда уже есть обширные знания по инфраструктуре, опыт работы с архитектурой компании в целом — где и какие лучше использовать решения как на уровне ПО, так и железа, когда лучше on premise, а когда стоит присмотреться к public cloud, где лучше старый добрый SQL, а где есть смысл в современных noSQL базах, когда rabbit/Kafka будут полезны, а не вредны, когда лучше мелкий скрипт на bash, а когда уже «внесите Ansible», когда iops, inode и прочие термины не пустой звук.

Необязательно, что в DevOps вырастают из сисадминов. Ещё один путь — это выход из разработки. Например, идёт человек работать разработчиком ПО, но позже по какой-то причине понимает, что это ему это не очень подходит, тянет к инфраструктуре и дебагу, связанным с инфрой. Идеальный выбор при таком раскладе — переход из разработки в DevOps/SRE.

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

Чтобы работать с DevOps практиками, нужно свободно чувствовать себя и в рамках идеологии контейнеризации, понимать её не как единственный docker containers, но и разбираться в других системах: Linux Containers, Podman и так далее. Podman постепенно выходит на первый план, но в целом он очень похож на Docker.

Далее, осваивать оркестрацию с помощью альтернатив Kubernetes: Docker Swarm, Rancher, Nomad и OpenShift. OpenShift — это платное решение от Red Hat, основывающееся на k8s с приятными и удобными бонусами от RedHat, второе по популярности после Kubernetes.

Какая градация есть у DevOps-инженеров

Джуны должны знать Linux. Хотя бы поверхностно разбираться в kernel, уверенно работать с командной строкой, системой SELinux и утилитой iptables.

Из инструментов придётся освоить Docker, Kubernetes, Ansible, Helm, Git, Zabbix, ELK, Nexus, Prometheus и Grafana. Для работы с базами данных неплохо изучить MySQL, PostgreSQL, Microsoft SQL Server.

Мидлы по щелчку пальцев должны быть способны сделать всё что угодно с сервером или виртуальной машиной на Linux. Например, провести удалённый запуск команд, правильно назначить права на пользователей, настроить политику на SELinux и фильтры в iptables, написать скрипты автоматизации, всё сломать и быстро починить.

Сеньор будет отличаться масштабом. Он смотрит не на отдельную машину, а на ИТ-инфраструктуру в целом. Решает задачи уровня «как поднять и сконфигурировать окружение с помощью Ansible и Terraform», «как настроить интеграцию со смежными системами и учесть все нюансы реализации».

Советы новичкам

Важно понимать, как работают git-инструменты, *nix-системы, сети, базы данных. Изучать, как собирается код, что происходит после сборки кода, какую роль играет информационная безопасность в разработке ПО — это дополнительное направление, именуемое DevSecOps.

Рекомендую книги:

• «Паттерны Kubernetes» O’REILLY;
• «Linux Bible» Кристофера Негуса;
• Эндрю Таненбаума — у него есть учебники и про сети, и про операционные системы.

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

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

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