Евгений Боровиков: «Как сформировать эффективную DevOps-команду»
Новости рынка, редакционные обзоры, экспертные материалы и выпуски изданий. Выберите формат, который удобен вам.
Учитывая ваш большой опыт в DevOps, давайте начнем с создания и масштабирования таких команд — какие подходы вы используете в такой работе, и может быть есть ключевые правила?
Я бы начал с того, что создание DevOps-команды — это не про найм инженеров, умеющих писать Ansible playbook или деплоить в Kubernetes. Прежде всего это про формирование культуры, выстраивание ответственности и правильное позиционирование DevOps в структуре компании. В своей практике я использую два базовых формата командной организации: матричный продуктовый подход и выделенное специализированное подразделение.
В первом случае команда формируется вокруг конкретного продукта и включает специалистов из разных областей: разработчиков, инженеров, DevOps, аналитиков и даже маркетологов — в зависимости от задач. Такая команда автономна и несет ответственность за полный цикл разработки и вывода продукта.
Во втором варианте создается команда экспертов одного профиля — как правило, DevOps или инфраструктурных инженеров — которая решает сквозные задачи: поддержку, сопровождение, автоматизацию и инфраструктурное развитие сразу для нескольких команд или продуктов.
Выбор модели зависит от целей и зрелости бизнеса: если приоритет — скорость вывода продукта, подходит кросс-функциональная структура; если нужно системно решать инфраструктурные задачи, эффективнее работает центр компетенций. Безусловно, технические навыки важны, но ключевую роль играет способность человека органично встраиваться в команду.
На собеседованиях мы оцениваем не только экспертизу, но и личные качества: коммуникабельность, инициативность, критическое мышление. Если кандидат — глубоко компетентный, но ему сложно работать в коллективе, я стараюсь подобрать задачи, где он сможет реализовать свой потенциал с минимальной необходимостью взаимодействия. Такой индивидуальный подход помогает максимально раскрыть сильные стороны каждого члена команды — и в итоге выигрывает весь проект.
Как вы помогаете команде оставаться мотивированной и поддерживать высокий уровень вовлеченности?
При формировании команды я в первую очередь обращаю внимание на внутреннюю мотивацию человека развиваться именно в нашей области. Это гораздо важнее, чем просто опыт в резюме. Когда сотрудник по-настоящему увлечен своей работой, он быстрее погружается в процессы и стремится к росту. В ежедневной работе я стараюсь подбирать задачи так, чтобы они совпадали с интересами и сильными сторонами конкретного специалиста.
Уверен: если человек делает то, что ему неинтересно, на выходе будет посредственный результат — вне зависимости от уровня квалификации. Конечно, полностью избежать рутинных или не самых вдохновляющих задач невозможно. Но и здесь важно правильно расставить акценты: я объясняю, чему конкретно человек научится, решая эту задачу, и как это повлияет на его профессиональный рост. Часто именно такие «незаметные» задачи в итоге дают мощный апгрейд скиллов и делают инженера сильнее и конкурентоспособнее на рынке.
Расскажите, почему вы решили специализироваться на DevOps и инфраструктурной инженерии? Вы начинали карьеру с этих направлений?
Когда я начинал карьеру, самого термина DevOps еще не существовало. Мое базовое образование связано с радиосвязью, и оно дало мне прочную основу в понимании сетевых технологий. С этого все и началось. Далее я прошел путь от сетевого инженера до системного администратора, постепенно вовлекаясь в более широкие задачи: автоматизацию, CI/CD, инфраструктурные решения, а позже и в продуктовую разработку. Со временем это трансформировалось в тот стек компетенций, который сегодня называется DevOps. Сейчас я фактически выполняю роль мостика между разработкой и эксплуатацией, соединяя интересы технических команд с требованиями бизнеса.
Это позволяет выстраивать системы, которые одновременно устойчивы, масштабируемы и максимально адаптированы под продуктовые цели.
Я знаю, что вы работали DevOps Team Lead на крупном проекте для Сбера. Какие ключевые задачи вам удалось реализовать?
Да, одним из значимых проектов в моей практике стал внутренний образовательный продукт для онбординга сотрудников Сбера. Его цель заключалась в том, чтобы ускорить адаптацию новых сотрудников в подразделениях: мы создавали индивидуальные обучающие курсы под каждый департамент, где новичок знакомился с устройством команды, своими задачами и ключевыми проектами.
После прохождения курса и успешного тестирования сотрудник получал доступ к нужным ресурсам и мог быстро приступить к работе. DevOps-инженеры в этом проекте были встроены непосредственно в продуктовую команду. Это позволило обеспечить быструю обратную связь, гибкое взаимодействие с разработкой и тесную вовлеченность в полный цикл поставки продукта. Мы отвечали за автоматизацию процессов, настройку CI/CD, создание тестовых сред и стабильность релизов в инфраструктуре Сбера.
Отвечая за миграцию инфраструктуры проекта с частных серверов в Virtual Private Cloud, какие ключевые архитектурные решения вы принимали для обеспечения безопасности, отказоустойчивости и масштабируемости облачной среды?
Virtual Private Cloud (VPC) — это изолированная среда внутри публичного облака, которая позволяет выстраивать инфраструктуру компании с привычными подходами, но на базе абстракций, предоставляемых облачным провайдером. По сути, это привычная ИТ-инфраструктура, но с рядом преимуществ: автоматизация, готовые сервисы и снятие части операционной нагрузки. Например, можно использовать управляемые базы данных, балансировщики, хранилища и другие сервисы «из коробки». За счет этого архитектура становится легче, компактнее и быстрее разворачивается, чем при использовании «железа» в собственном дата-центре.
В облаке модель безопасности делится между клиентом и вендором. Провайдер может гарантировать, например, размещение ресурсов в нужных геозонах или физическую защищенность дата-центров. Но архитектурные решения, разграничение прав доступа, защита данных — все это по-прежнему ответственность компании.
Важно понимать: облако не избавляет от необходимости выстраивать политику безопасности, но делает ее реализацию проще и быстрее. Один из главных плюсов облака — гибкое масштабирование. Вы можете увеличить или уменьшить ресурсы за минуты, а не за недели, как в случае с физическим оборудованием. Это особенно критично для бизнесов с нестабильным паттерном потребления ресурсов.
Что касается отказоустойчивости, облачные платформы предоставляют встроенные механизмы: репликация данных, автоматическое переключение на резервные зоны при сбоях, алерты в случае рисков утечки или неправильной настройки. Например, если инженер случайно открыл доступ к чувствительным данным, система автоматически уведомит об этом.
Правила миграции в облако не отличаются принципиально от переноса инфраструктуры между собственными серверами: требуется аудит, планирование, поэтапная реализация. Просто часть задач (сетевые настройки, обеспечение отказоустойчивости, физическая безопасность) уже решена на стороне облачного провайдера. Именно поэтому миграция в облако — это не только про инфраструктуру, но и про перенос ответственности, процессов и мышления.
Как вы видите будущее DevOps, и какие технологии, на ваш взгляд, станут определяющими в ближайшие годы?
Я думаю, что в ближайшие годы будет усиливаться уже устоявшаяся тенденция: максимальная автоматизация рутинных процессов, особенно в области развертывания, конфигурации и управления инфраструктурой. Это позволяет не только оптимизировать расходы на команду, но и существенно ускорить delivery-цикл. Сейчас все больше команд делают ставку на декларативные подходы, где описывается не то, как выполнить задачу, а что должно быть получено в результате. И здесь особенно важную роль играет связка Terraform и Ansible.
Terraform позволяет описывать всю инфраструктуру как код (IaC) — от облачных ресурсов до сетевых политик — в виде декларативных конфигураций. Он отлично справляется с provisioning’ом.
Ansible дополняет его на уровне конфигураций — настройки ОС, пакеты, сервисы, deployment приложений. Он более гибок в пошаговой логике, и потому идеально работает после фазы инициализации от Terraform.
Эта комбинация уже стала промышленным стандартом для множества компаний, и, я уверен, ее роль только усилится. Особенно с ростом мультиоблачных архитектур, где нужна предсказуемость, повторяемость и быстрое масштабирование без ручных вмешательств.
Какие рекомендации вы бы дали инженерам, которые хотят развиваться в DevOps?
Если бы я сегодня начинал карьеру в DevOps, я бы сосредоточился на четырех ключевых направлениях, которые дают сильный фундамент и позволяют расти в профессии:
1. Освойте фундамент: Linux, сети, CI/CD
Начните с основ: уверенное владение Linux, понимание структуры ОС, прав доступа, работы системных служб. Добавьте к этому знание сетевых технологий (TCP/IP, NAT, DNS, HTTP) и принципов работы CI/CD. Вы должны понимать, как работает пайплайн от коммита до продакшена, и где могут возникать узкие места.
2. Инфраструктура как код: Terraform + Ansible
Terraform стал промышленным стандартом для управления инфраструктурой в облаках. Его декларативный подход позволяет строить устойчивые, масштабируемые решения. В связке с Ansible можно автоматизировать конфигурацию серверов, деплой и post-install сценарии. Эта пара покрывает практически весь жизненный цикл инфраструктуры.
3. Контейнеризация и Kubernetes
Понимание Docker и Kubernetes — must-have. Даже если вы не планируете становиться кластерным администратором, вам нужно понимать, как устроено развертывание контейнеризированных приложений, какие есть паттерны отказоустойчивости, как реализуется сервис-дискавери, управление ресурсами и мониторинг в k8s-среде.
4. Умение писать код, например, на Python или Go
DevOps-инженер — это не только shell скрипты. Умение писать качественный код на одном из языков — например, Python или Golang — критически важно. Вы будете писать кастомные инструменты, обертки для API, модули для пайплайнов, автоматизации, чат-ботов, health-чеков, и многое другое. Язык — это не цель, а средство, но владение им дает свободу действий и уверенность.
Опубликовано 17.03.2021
