Head of Infrastructure в компании SQUAD Олег Миколайченко рассказал Highload о том, что делать, если вы уже сформировавшийся разработчик, полноценный инженер, но захотели перейти в профессию DevOps. Интереса к ней много, что неудивительно, ведь зарплаты там достигают $5000.
Часто «локально» все работает, даже когда в Kibana видно кучу ошибок с прода. В этом могут быть виноваты все (бизнес, девопсы, разработчики), и это нужно чинить в первую очередь.
Development environment должен быть создан теми же инструментами и из той же кодовой базы. Как описывать инфраструктуру как код, будем учить дальше — сейчас разбираемся, как она в целом работает.
Это может быть Kubernetes, AWS EKS, или даже EC2-инстансы под балансировщиком нагрузки — что угодно. На этом этапе нужно полностью дать себе ответ на вопрос — как выглядит production-окружение? Как оно действительно работает?
Как проверить, что вы поняли, как работает инфраструктура:
Полезные хаки:
На этом этапе вы уже победили, так как по итогам в худшем случае окажетесь Staff Engineer, который понимает в деталях, как работает приложение и как работает production. Теперь вы — центр знаний и путь коммуникации с DevOps. Вас любят девопсы, ваша команда и тестировщики.
На первом этапе вы разобрались, что и как работает, сделали общую архитектуру проекта, нарисовали пару важных графиков и частично оптимизировали CI — теперь билды проходят быстрее и ведут себя стабильнее.
Самое время разобраться в Infrastructure as a Code, а именно — понять, каким образом настроили инфраструктуру.
Опираясь на мой опыт, могу сказать что с вероятностью 80% вы увидите Terraform + Ansible, а с 20% — разные тулы (CloudFormation, Pulumi, Chef, Puppet, Crossplane и т.д.). Опытные девопсы скажут, что Ansible — это не IaC, а Crossplane — вообще GitOps для IaC, но мы сейчас это упустим и будем считать, что эти тулы делают одно и то же — позволяют описывать инфраструктуру в коде.
Дальше идем с тестовую лабораторию и делаем следующее:
И добавляем теории:
И дальше стоит попросить доступ в Terraform-репозиторий. Цель — более детально изучить, как настроена инфраструктура. На этом этапе вы уже сделали для девопсов архитектуру, обучили свою команду и ускорили CI. Проблем быть не должно.
Полезные хаки:
Дальше добавляем кастомные метрики, которые могут помочь понять, в каком состоянии находится приложение: RPS, тайминги на операции, counter на завершенные задачи, количество ошибок + все, что может показаться вам полезным.
Базовый вариант — использовать Prometheus SDK, продвинутый — OpenTelemetry. В 99% случаев у вас уже будет Prometheus (или еще Datadog/New Relic, но запущен процесс миграции в Prometheus), поэтому лучше начать реализацию с первого варианта и «продавать» второй.
Сделайте дашборд в Grafana на основе этих метрик. Все переменные должны быть шаблонизированы (кластер, окружение). Спросите о обратной связи и улучшите дашборд.
Дальше посмотрите, как сделать алерты для оповещений. Базово — Alertmanager в Slack, продвинуто — Alertmanager → PagerDuty → роутинг оповещений между членами команды и severity.
Разберитесь, как именно работает мониторинг и как сделать, чтобы с вашего приложения собирались метрики. Посмотрите, куда они попадают и сколько хранятся.
Обязательно нужно знать Kubernetes — это основная платформа для микросервисов и будет такой до 2030 года, дальше — будет видно. Советую начинать с Kubernetes by Example, потом можно сдать CKA-сертификацию (она будет полезна, так как включает hands-on-экзамен — это значит, что нельзя просто заучить правильные ответы).
Вместе с Kubernetes вы разберетесь:
Сначала может показаться, что Kubernetes — самое ужасное, что случалось в вашей жизни. Потом может прийти мысль, что это как разработка на YAML с чтением документации. И только на третьем этапе приходит осознание, что это — отличный оркестратор. С огромным количеством багов и еще большим набором инструментов для разных задач.
Нужно выучить Linux Administrator Roadmap.
Для того, чтобы в полной мере узнать об инженерных практиках и иметь возможность выбрать правильную в нужный момент, стоит прочитать все три, хотя бы по диагонали.
DevOps — это о коммуникации и взаимодействии в первую очередь. Поймите, где ваша сила.
Разработчик, который переходит в DevOps, может быть очень полезен. Вот почему:
У тестировщиков вообще все карты в обоих рукавах:
Резюмируя: инженеру из любой области будет интересно в DevOps, и команда только выиграет от такого свежего члена команды. Новый опыт, другой фокус, желание закатать рукава — это основная ценность и очень важная составляющая.
Дальше остается только применить полученные знания и получить предложение о работе. В сообществах программистов бытует мнение, что DevOps много зарабатывают просто так — это, конечно, не так. Я очень верю, что эта статья сориентирует в космосе вариантов свитчинга в DevOps и приведет к нужному результату.
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…