Алексей Поляк, 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 отметили следующие различия между работой в крупной и небольшой компании:
- В большой компании инженер DevOps может сосредоточиться на задачах CI/CD. За поддержку базовых сервисов отвечают другие специалисты. В небольших же компаниях, задачи по администрированию всех этих сервисов, как правило, полностью или частично лежат на плечах DevOps-специалиста.
- В небольшой компании у специалиста появляется больше возможностей реализовать себя. Инженеры DevOps часто пересекаются с аспектами процесса разработки, что позволяет расширить кругозор, если специалист работает в стартапе.
- DevOps в небольшой компании со временем уходит в затяжную поддержку, а в крупной компании чаще возникают новые проекты.
Если вы хотите развиваться в профессии и работать в крупной компании, советуем обратить внимание на стек технологий, описанный инженерами DevOps в этой статье. Но мы уверены, что настоящий профессионал сумеет раскрыть свои навыки, независимо от масштаба компании и количества специалистов в ней.
Комментарии