Ведущие инженеры DevOps из российских IT-компаний рассказали корреспондентке «Библиотеки программиста» о сложностях в работе, специфике общения с командой, а также поделились списками наиболее часто используемых инструментов. Обсудить

Евгений Ахметханов, Senior DevOps Engineer/Эксперт по интеграции

О рабочем бекграунде

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

Основой развития в сторону Development и Operations послужила позиция Release Engineer, которая, имела широкие обязанности.

В мои задачи, как Release Engineer, входило:

• оптимизация работы систем сборки, например, миграция с Apache Ant на Apache Maven;
• оптимизация скорости сборки продукта, за счет правильного построения генерации кода, разрешения зависимостей проекта, изначальной генерации скриптов миграции схемы БД;
• стандартные Operations – поддержка трекеров, развертывания стендов тестирования и их поддержка.

В дальнейшем я связал профессиональный путь с GameDev, начав с позиции Senior DevOps Engineer, которая позже трансформировалась в DevOps Manager. Помимо озвученных ранее задач добавилось полноценное управление различными средами заказчиков и расширение типов проектов. Это были: многосервисные платформы, оптимизация и деплой мобильной разработки, а также проекты по разработке сетевого программного обеспечения, среды для него, и игр с их специфическими платформами – PS, Xbox.

Должность DevOps Manager добавила в мои обязанности:

• планирование работ команды;
• обсуждения проектов с заказчиками;
• организацию процесса предпродажи, бюджетирование и прочие бюрократические аспекты.

О рабочем дне и иерархии в команде

Сейчас мой рабочий день начинается с:

• оценки статуса работ, которые выполняют команды разработки;
• отслеживания блокирующих факторов;
• помощи во взаимодействии внутри команды;
• отслеживания общего движения проекта.

Кроме того я отслеживаю корректность процесса разработки и функционирования всех систем поддержки и сред разработки.

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

Несмотря на то, что компания, в которой я работаю, достаточно большая (более 4 тыс. человек), мой проект изолирован, поскольку является первой попыткой компании выйти на in-house разработку. Стоит рассматривать этот проект как маленькую компанию, состоящую из 14 человек, так называемый стартап, пусть и с некоторыми ограничениями.

Исходя из моего опыта, самостоятельная и эффективная команда редко насчитывает более 15 человек.

О сложностях

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

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

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

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

Рабочие инструменты

• JIRA. Ведение проекта без трекера просто невозможно. Этот инструмент позволяет перераспределять нагрузку на ранних этапах, чтобы не заблокировать работу;
• Confluence. Инструмент для ведения документации;
• Bitbucket. Система управления контроля версий, код сервисов, конфигурация сред, все здесь;
• Slack. Инструмент для коммуникации команды;
• IDEA Ultimate. Интегрированная среда разработки программного обеспечения для многих языков программирования. Уже шесть лет веду разработку именно в этой среде, она для меня незаменима;
• Консоль – наше все.

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

Применительно к моему текущему месту работы:

• Gradle. Билд-фреймворк;
• Docker. Утилита формирования образов виртуализации уровня ОС, используется только для разработки;
• Docker-Compose. Используется в интеграционном тестировании и для разработки;
• Podman. Утилита управления OCI (Open Container Initiative) контейнерами (с Docker разработчики знакомы, а вот с Podman нет. При условии обратной поддержки Podman идеально дать разработчикам знакомые утилиты, а в средах использовать более эффективные);
• Helm. Инструмент для конфигурации сервисов Kubernetes;
• OKD. OpenShift (Kubernetes от RedHat);
• SaltStack. Инструмент для управления конфигурациями;
• Test-Kitchen. Инструмент для интеграционного тестирования конфигураций;
• Jenkins. Обеспечивает процесс непрерывной интеграции программного обеспечения;
• Nexus Repository. Хранилище бинарных артефактов;
• SonarQube. Статический анализатор исходного кода.

Список не полный, но основные сервисы и утилиты указаны.

Особенности работы DevOps-специалиста в крупной IT-компании

Рабочие процессы специалиста DevOps в крупной и в небольшой компании почти идентичны.

Отличия проявляются во внешнем взаимодействии, то есть в бюрократической составляющей рабочего процесса. Это зависит от уровня зрелости компании.

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

Алексей Поляк, Senior DevOps Engineer компании «Иннотех»

О рабочем бекграунде

В IT я уже порядка 12 лет. Начинал как администратор Windows, но почти сразу перешел в администрирование Linux. Во время работы постепенно росло понимание пагубности общепринятых на тот момент практик: ручного администрирования серверов и ручных деплоев на продакшн. Когда я вырос до позиции директора IT-департамента в одном из московских интеграторов, под моим руководством началось внедрение таких инструментов, как Ansible и Jenkins.

Через некоторое время почувствовал, что начинаю выгорать и решил что-то поменять в карьере. Уехал работать в Нидерланды на позицию Linux-администратора, но быстро понял, что роль простого исполнителя – не мое. Отработав контракт, уехал в Малайзию на позицию Senior DevOps Engineer. Там успешно перестроил CI/CD процессы для подразделения одного из международных IT-интеграторов. Проработал там больше года и принял решение вернуться в Россию, где за последние неполные два года успел потрудиться над несколькими интересными проектами.

О рабочем дне и иерархии в команде

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

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

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

Над проектом работает порядка тысячи специалистов, но он разбит на большое число независимых команд, в которых живет дух стартапа с поправками на специфику текущего заказчика (банк).

О сложностях

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

Сложность внутрикомандных коммуникаций растет по мере роста количества участников. Отчасти, это можно сглаживать за счет горизонтальных коммуникаций и делением проекта на составные части, которые могут поддерживаться относительно независимыми командами.

Рабочие инструменты

Стек технологий, которые я использую, стандартен:

• Openshift. Как способ оркестрации контейнеров и частная версия Kubernetes от Red Hat;
• Kubernetes. Популярная платформа для работы с микросервисами;
• Ansible. Система управления конфигурациями;
• Teamcity. Основа CI/CD. Неплохая замена Jenkins, когда его нельзя использовать, а возможностей GitLab CI/CD уже не хватает.
• Prometheus/Grafana. Инструменты для мониторинга, стандартный набор для мира микросервисов.
• SonarQube. Инструмент для анализа кода.
• Helm, Python, Kotlin. Как инструменты для обеспечения CI/CD пайплайнов.

Особенности работы DevOps-специалиста в крупной IT-компании

Особенностью работы специалиста DevOps в большой компании является то, что он может сосредоточиться на задачах CI/CD. Базовые сервисы (сеть, платформа контейнеризации, git, таск-трекер и прочее) поставляются как сервис, и за их поддержку отвечают отдельные люди.

В небольших компаниях задачи по администрированию всех этих сервисов, как правило, полностью или частично лежат на плечах специалиста DevOps. Это сильно отвлекает от процессов CI/CD, но при этом дает значительно больше свободы.

Михаил Алексеев, Lead DevOps Engineer компании InventUS

О рабочем бекграунде

Работал в компаниях: EMC (сейчас Dell), EPAM, «Газпром нефть». Начинал профессиональный путь с позиции Junior Software Developer, с уклоном в Build Engineering (помогал команде DevOps, в итоге, остался там работать).

В обязанности входило: написание утилит для внутреннего использования командами разработчиков и тестировщиков, автоматизирование рутинных задачи, работа с CI.

Предыдущее место работы – компания EPAM, где я был повышен до руководителя команды. Сейчас работаю на должности ведущего инженера команд DevOps в компании InventUS.

О рабочем дне и иерархии в команде

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

В компании работают руководители и сотрудники, ответственные за разработку отдельных продуктов/модулей. Я могу давать рекомендации, если замечаю узкие места в процессах. Считаю, что до 10 человек – оптимальное количество сотрудников для одного проекта.

Именно в небольшой компании у специалиста больше возможностей реализовать себя. Если мы говорим о специалистов DevOps (а не просто Ops), они часто пересекаются с аспектами процесса разработки: программирование, тестирование, управление продуктом. В стартапах такие пересечения выражены более ярко, что расширяет кругозор.

О сложностях

Сложностей на моем текущем месте работы не возникает. У каждой команды есть focal point (точка входа), с помощью которой можно донести необходимую информацию и решить все проблемные моменты.

Рабочие инструменты

Инструментов в арсенале специалиста DevOps крайне много. Если выделять какой-то один, это будет GitLab. Он покрывает много потребностей, возникающих в процессе разработки, например: управление версиями, управление жизненным циклом проблем, служба поддержки, CI/CD, переключение функций и другое.

Кирилл Кузнецов, Senior DevOps Engineer компании «Аркадия»

О рабочем бекграунде

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

О рабочем дне и иерархии в команде

Мой рабочий день начинается с просмотра календаря и таск-менеджера, после этого я провожу митинги с командой, решаю возникающие вопросы, задачи, и так по кругу. Считаю, что команда – это одно целое, поэтому коммуницирую с каждым в равной степени.

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

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

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

О сложностях

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

Заключение

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

1. Бюрократическая составляющая рабочего процесса доминирует в крупных компаниях. Сферу ответственности там пытаются разделить структурными подразделениями, что сохраняет управляемость командой, но размывает ответственность.
2. В большой компании инженер DevOps может сосредоточиться на задачах CI/CD. За поддержку базовых сервисов отвечают другие специалисты. В небольших же компаниях, задачи по администрированию всех этих сервисов, как правило, полностью или частично лежат на плечах DevOps-специалиста.
3. В небольшой компании у специалиста появляется больше возможностей реализовать себя. Инженеры DevOps часто пересекаются с аспектами процесса разработки, что позволяет расширить кругозор, если специалист работает в стартапе.
4. DevOps в небольшой компании со временем уходит в затяжную поддержку, а в крупной компании чаще возникают новые проекты.

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