Как перейти в DevOps, где зарабатывают по $5000, из других IT-профессий

Head of Infrastructure в компании SQUAD Олег Миколайченко рассказал Highload о том, что делать, если вы уже сформировавшийся разработчик, полноценный инженер, но захотели перейти в профессию DevOps. Интереса к ней много, что неудивительно, ведь зарплаты там достигают $5000.

Изучаем, как работает платформа в деталях

Часто «локально» все работает, даже когда в Kibana видно кучу ошибок с прода. В этом могут быть виноваты все (бизнес, девопсы, разработчики), и это нужно чинить в первую очередь.

Development environment должен быть создан теми же инструментами и из той же кодовой базы. Как описывать инфраструктуру как код, будем учить дальше — сейчас разбираемся, как она в целом работает. 

Это может быть Kubernetes, AWS EKS, или даже EC2-инстансы под балансировщиком нагрузки — что угодно. На этом этапе нужно полностью дать себе ответ на вопрос — как выглядит production-окружение? Как оно действительно работает?

Как проверить, что вы поняли, как работает инфраструктура: 

• произошел Aha-момент;
• понятно, что происходит после merge в git;
• вы нашли метрику, на основе которой работает автоскейлинг;
• графики на Grafana имеют какой-то смысл;
• Jenkins такой же страшный и непонятный, но уже меньше.

Полезные хаки: 

• пытаемся нарисовать архитектуру в draw.io и добавить как плагин в Confluence (скорее всего, такой архитектуры там нет, поэтому всем будет полезно);
• dev-окружение полностью повторяет production, но намного меньше (это нужно для того, чтобы «локально» тоже не работало);
• для каждой неизвестной технологии формируем базовое понимание, в идеале — пару слов, которые точно описывают предназначение (например, Istio — коммуникация между сервисами, AWS ALB — балансировщик HTTP/HTTPS, CloudFront — обычный CDN и т.д.).

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

Инфраструктура как код (IaC)

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

Самое время разобраться в Infrastructure as a Code, а именно — понять, каким образом настроили инфраструктуру.

Опираясь на мой опыт, могу сказать что с вероятностью 80% вы увидите Terraform + Ansible, а с 20% — разные тулы (CloudFormation, Pulumi, Chef, Puppet, Crossplane и т.д.). Опытные девопсы скажут, что Ansible — это не IaC, а Crossplane — вообще GitOps для IaC, но мы сейчас это упустим и будем считать, что эти тулы делают одно и то же — позволяют описывать инфраструктуру в коде.

Дальше идем с тестовую лабораторию и делаем следующее:

• настраиваем первый сервер на HCL в Terraform;
• настраиваем первую базу данных и пользователей в ней;
• настраиваем firewall, SSH-ключи;
• масштабируем первый сервер в пачку серверов;
• добавляем их все в балансировщик.

И добавляем теории: 

• что такое Terraform state;
• как заимпортить существующие ресурсы в Terraform-код;
• зачем нужен state lock;
• как сделать удобный модуль;
• какие удобные линтеры добавить (tfsec, tflint и т.д.).

И дальше стоит попросить доступ в Terraform-репозиторий. Цель — более детально изучить, как настроена инфраструктура. На этом этапе вы уже сделали для девопсов архитектуру, обучили свою команду и ускорили CI. Проблем быть не должно. 

Полезные хаки: 

• вся инфраструктура должна быть в коде, до самого маленького сеттинга;
• нет, как с юнит-тестами не получится, потом не напишем;
• в любимую IDE уже есть HCL-плагин;
• на любую задачу уже есть готовый опенсорс-модуль.

Мониторим приложение

Дальше добавляем кастомные метрики, которые могут помочь понять, в каком состоянии находится приложение: RPS, тайминги на операции, counter на завершенные задачи, количество ошибок + все, что может показаться вам полезным.

Базовый вариант — использовать Prometheus SDK, продвинутый — OpenTelemetry. В 99% случаев у вас уже будет Prometheus (или еще Datadog/New Relic, но запущен процесс миграции в Prometheus), поэтому лучше начать реализацию с первого варианта и «продавать» второй.

Сделайте дашборд в Grafana на основе этих метрик. Все переменные должны быть шаблонизированы (кластер, окружение). Спросите о обратной связи и улучшите дашборд.

Дальше посмотрите, как сделать алерты для оповещений. Базово — Alertmanager в Slack, продвинуто — Alertmanager → PagerDuty → роутинг оповещений между членами команды и severity.

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

Изучаем Kubernetes + 100500 тулов

Обязательно нужно знать Kubernetes — это основная платформа для микросервисов и будет такой до 2030 года, дальше — будет видно. Советую начинать с Kubernetes by Example, потом можно сдать CKA-сертификацию (она будет полезна, так как включает hands-on-экзамен — это значит, что нельзя просто заучить правильные ответы).

Вместе с Kubernetes вы разберетесь:

• в типах деплойментов (Recreate, Rolling Update, Canary, Blue/Green) + научитесь их реализовывать;
• в типах сервисов, селекторах, ингрессах;
• в упаковке приложений в helm;
• в автоскейлинге нод, подов, и задач;
• в kube-prometheus-operator — one love;
• в том, какие задачи решают тулы в CNCF.

Сначала может показаться, что Kubernetes — самое ужасное, что случалось в вашей жизни. Потом может прийти мысль, что это как разработка на YAML с чтением документации. И только на третьем этапе приходит осознание, что это — отличный оркестратор. С огромным количеством багов и еще большим набором инструментов для разных задач.

Linux

Нужно выучить Linux Administrator Roadmap. 

3 обязательные книги

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

1. Site Reliability Engineering — теория для девопсов, поможет всегда знать как правильно делать, и выходить сухим из воды.
2. The Site Reliability Workbook — практика, позволит не набивать своих шишек, а учиться на ошибках других.
3. Building Secure & Reliable Systems — практики для работы в команде безопасно и продуктивно (так, как это делают в Google).
   
   Читать строго в этой последовательности.

Осознаем свою ценность

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

Разработчик, который переходит в DevOps, может быть очень полезен. Вот почему: 

• вы точно знаете, что можно выкосить из этапа сборки приложения;
• с легкостью можете поправить код конфигурации, аргументы;
• можете быстро и качественно добавить новые метрики или новую библиотеку;
• более «понятно» продать tracing, rate limits или autoscaling команде разработки;
• можете починить баг в любой опенсорс-девопс-туле (мало кто из девопсов может);
• знаете отличия между инкапсуляцией и полиморфизмом.

У тестировщиков вообще все карты в обоих рукавах: 

• опыт автоматизации и знание языков программирования;
• понимание, как правильно тестировать инфраструктурные изменения;
• опыт взаимодействиями с разработчиками;
• характерный склад ума, который позволит просчитать большинство edge-кейсов перед деплоем в прод;
• знание всего девопс-тулсета для мониторинга (конечно, ведь вам не раз приходилось!).

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

kubectl apply -f joboffer.yaml

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