Как перейти в 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 тулов
CNCF Landscape: 955 проектов — https://landscape.cncf.io/
Обязательно нужно знать 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 обязательные книги
Google SRE books
Для того, чтобы в полной мере узнать об инженерных практиках и иметь возможность выбрать правильную в нужный момент, стоит прочитать все три, хотя бы по диагонали.
- Site Reliability Engineering — теория для девопсов, поможет всегда знать как правильно делать, и выходить сухим из воды.
- The Site Reliability Workbook — практика, позволит не набивать своих шишек, а учиться на ошибках других.
- Building Secure & Reliable Systems — практики для работы в команде безопасно и продуктивно (так, как это делают в Google).
Читать строго в этой последовательности.
Осознаем свою ценность
DevOps — это о коммуникации и взаимодействии в первую очередь. Поймите, где ваша сила.
Разработчик, который переходит в DevOps, может быть очень полезен. Вот почему:
- вы точно знаете, что можно выкосить из этапа сборки приложения;
- с легкостью можете поправить код конфигурации, аргументы;
- можете быстро и качественно добавить новые метрики или новую библиотеку;
- более «понятно» продать tracing, rate limits или autoscaling команде разработки;
- можете починить баг в любой опенсорс-девопс-туле (мало кто из девопсов может);
- знаете отличия между инкапсуляцией и полиморфизмом.
У тестировщиков вообще все карты в обоих рукавах:
- опыт автоматизации и знание языков программирования;
- понимание, как правильно тестировать инфраструктурные изменения;
- опыт взаимодействиями с разработчиками;
- характерный склад ума, который позволит просчитать большинство edge-кейсов перед деплоем в прод;
- знание всего девопс-тулсета для мониторинга (конечно, ведь вам не раз приходилось!).
Резюмируя: инженеру из любой области будет интересно в DevOps, и команда только выиграет от такого свежего члена команды. Новый опыт, другой фокус, желание закатать рукава — это основная ценность и очень важная составляющая.
kubectl apply -f joboffer.yaml
Дальше остается только применить полученные знания и получить предложение о работе. В сообществах программистов бытует мнение, что DevOps много зарабатывают просто так — это, конечно, не так. Я очень верю, что эта статья сориентирует в космосе вариантов свитчинга в DevOps и приведет к нужному результату.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: