Share This
Связаться со мной
Крути в низ
Categories
//Эксперты рассказывают о работе специалистов DevOps в крупных IT-компаниях

Эксперты рассказывают о работе специалистов DevOps в крупных IT-компаниях

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

eksperty rasskazyvajut o rabote specialistov devops v krupnyh it kompanijah 1a879b4 - Эксперты рассказывают о работе специалистов 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 человек, поэтому мы можем позволить себе самоорганизацию. Команда устанавливает лидеров, а мне остается вносить коррективы по направлению проекта в целом.

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

eksperty rasskazyvajut o rabote specialistov devops v krupnyh it kompanijah 1708007 - Эксперты рассказывают о работе специалистов DevOps в крупных IT-компаниях

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

  • 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 необходимо общаться со всеми членами команды для сбора пожеланий и обратной связи, а также, уточнения их планов и дедлайнов.

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

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

О сложностях

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

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

eksperty rasskazyvajut o rabote specialistov devops v krupnyh it kompanijah f622edf - Эксперты рассказывают о работе специалистов DevOps в крупных IT-компаниях

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

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

  • 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 в этой статье. Но мы уверены, что настоящий профессионал сумеет раскрыть свои навыки, независимо от масштаба компании и количества специалистов в ней.

  • 2 views
  • 0 Comment

Leave a Reply

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Свежие комментарии

    Рубрики

    About Author 01.

    Roman Spiridonov
    Roman Spiridonov

    Привет ! Мне 38 лет, я работаю в области информационных технологий более 4 лет. Тут собрано самое интересное.

    Our Instagram 04.

    Categories 05.

    © Speccy 2020 / All rights reserved

    Связаться со мной
    Close