Как работает команда DevOps в Positive Technologies

Всем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки Positive Technologies. Внутри компании нас неформально называют DevOps-отделом. Мы занимаемся автоматизацией внутренних процессов и помогаем разработчикам и тестировщикам. В прошлой статье я уже писал, как выстроен карьерный рост у инженеров, а сегодня хочу рассказать про «внутреннюю кухню» — о том, что делают DevOps-инженеры у нас в компании. Вы узнаете, что лежит в основе идей DevOps, какие плюсы дает бизнесу работа по принципам DevOps и как при этом изменяется процесс разработки.

Как мы понимаем идеи DevOps

Мы не претендуем на идеальную реализацию всех идей DevOps, для этого есть специализированные компании и гуру в этой области, а у нас в Позитиве своя специфика разработки в области ИБ и свои процессы автоматизации.

Как мы понимаем работу по принципам DevOps и в чем их ключевые отличия от классического подхода к разработке? Для начала разберемся, как когда-то шла разработка ПО не только в нашей компании, а в целом в отрасли.

Команда программистов (Dev) писала код и сама делала его сборку, команда тестировщиков (QA/QC) тестировала то, что им отдали программисты, а далее команда администраторов (IT) вручную устанавливала это на «боевые» серверы. Обычные проблемы такого подхода: «Я код написал, сохранил, дальше не моя задача!», «Я баг протестировал в старой версии, а новую мне никто не давал!», «Я ваше приложение установил, оно не работает, что с ним делать, я не знаю, спрашивайте разработчиков!». А если это была распределенная команда с сотрудниками в разных часовых поясах, то при таком подходе разработка затягивалась на месяцы и годы. Чтобы решить эти проблемы, нужно было объединить всех участников в едином и понятном для них процессе.

Понятие Development Operations (или DevOps) включает в себя не только инструменты разработки и сервисы, но также методики и лучшие практики их использования. Иногда бывает, что даже на уровне руководителей разработки звучат мнения: «Пусть ваши DevOps-инженеры просто настроят нам деплой (или CI)!» или «А вот в других компаниях DevOps-инженеры занимаются <подставить нужное>, вы тоже должны делать это!». Это говорит о том, что работу DevOps-инженеров часто понимают как смешение различных ролей. Инженеры, работающие по принципам DevOps, помогают «подружить» между собой всех, кто участвует в процессе разработки ПО, и объединить их совместный труд в рамках общего производственного конвейера. Они смотрят на все процессы «сверху», при этом направления работ у таких инженеров динамически меняются и подстраиваются под реальность продуктовой разработки, чтобы предлагать наиболее подходящие решения под конкретные задачи.

Вот пример подобной гибкости из нашего опыта. В последние два года к поддержке направлений Dev и Ops для наших DevOps-инженеров добавились работы по внедрению инструментов безопасной разработки в уже существующие сборочные CI-конвейеры, то есть мы занялись развитием Sec-направления. Об этом мы подробно рассказывали в статье о том, как внедряли анализатор кода PT Application Inspector в продуктовый конвейер: для этого пришлось разработать методику и выстроить архитектуру решения, развернуть серверную и клиентскую части, разработать скрипты для работы с API PT AI и шаблоны сканирования для интеграции с CI (их можно найти в опенсорсе). Как сейчас работает PT AI в сборочном конвейере, мы показали на вебинаре.

Были в моей практике и нетривиальные инженерные задачи, например нужно было помочь тестировщикам нашего веб-сканера автоматически отсеивать false-позитивы найденных уязвимостей для одного из этапов тестирования. Для этого пришлось создать полноценную математическую модель и внедрить в CI нейро-нечеткий классификатор собственной разработки. Также мы внедряли систему нагрузочного тестирования на базе Яндекс.Танк, когда это еще не стало мейнстримом :) Но такие задачи достаточно редки, и они не совсем типичны для работы DevOps-инженера.

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

Плюсы, которые дает бизнесу работа по принципам DevOps

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

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

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

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

Какие проблемы разработки может помочь решить DevOps-команда

Как я отметил ранее, одна из основных задач DevOps-инженера — упрощение взаимодействия между командами разработки (Dev) и эксплуатации (Ops, обычно эту роль выполняет IT-подразделение). Они могут сделать совместный труд разработчиков и IT-инженеров более эффективным и продуктивным, обеспечивая обмен информацией и технологиями между ними.

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

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

Как идет разработка по принципам DevOps

Основные шаги

Процесс разработки сильно зависит от специфики работы каждой конкретной компании. У нас в Positive Technologies, являющейся вендором программных продуктов в сфере информационной безопасности, все решения от DevOps-инженеров — типовые, масштабируемые и построены на шаблонах. Для всех CI/CD-проектов общие шаги остаются неизменными: разработчик делает git-коммит и запускается автоматическая сборка в GitLab CI (building) — далее запускается автоматическое развертывание на тестовые серверы (deploying) — выполняются функциональное и прочие виды автотестирования (testing) — сборка продвигается в релизный репозиторий на Artifactory (promoting) — публикация компонентов и инсталляторов на корпоративный сервер обновлений GUS (publishing) — распространение через FUS-серверы в интернете (delivering) — установка или обновление продукта на инфраструктуре заказчиков (installing/updating).

На каждом шаге DevOps-инженеры помогают разработчикам и тестировщикам решать множество конкретных технических задач, например:

• подготовить и настроить проекты в GitLab для хранения кода и конфигураций;

• подготовить пулы сборочных серверов;

• разработать сборочные конфигурации, используя типовые шаблоны;

• сохранить артефакты сборки (компоненты и инсталляторы) в репозитории на Artifactory;

• создать сценарии автоматического развертывания тестового окружения на виртуальных машинах;

• разработать конфигурации для развертывания компонент и инсталляторов на тестовых серверах;

• помочь тестировщикам с подготовкой тестовых конфигураций и запуском в них тестовых сценариев;

• продвинуть сборку, то есть переместить ее в хранилище успешно протестированных артефактов;

• опубликовать сборку на корпоративном Update-сервере;

• помочь с написанием сценариев для развертывания сборки на «боевом» сервере;

• помочь с техническими деталями лицензирования и сбора телеметрии от установленных продуктов.

Инструменты для поддержки автоматизации

Как правило, инструменты для автоматизации разработки выбираются из потребностей решаемых задач. У нас за 7 лет эволюции CI/CD-конвейера сложилась устойчивая связка из трех базовых сервисов, предоставляемых для разработчиков и тестировщиков по умолчанию: GitLab как хранилище кода, GitLab CI для реализации CI/CD вместе с пулами сборочных агентов и Artifactory как хранилище собранных компонент и инсталляторов, а также кеширующий прокси для внешних репозиториев различного типа.

Разработчики пишут в основном на C++, C# и Python. Тестировщики пишут SaltStack или Ansible сценарии для подготовки тестового окружения, используют py.test, Selenium, RobotFramework, Яндекс.Танк, JMeter и собственные фреймворки для реализации различных видов тестов. Отчеты по тестам публикуются в сервисах TestRail или Allure.

Для работы с внешними заказчиками используется набор сервисов Supply Lab собственной разработки: GUS-сервер для публикации успешно протестированных релизов инсталляторов и пакетов обновлений, FUS-серверы для автоматической доставки релизов и License-сервер для работы с лицензиями. Подготовка окружения и развертывание продуктов компании на конечных серверах заказчиков производится либо самописными инсталляторами, либо также с использованием сценариев на SaltStack или Ansible.

Для ведения проектной работы мы предоставляем командам трекеры на выбор: TFS, YouTrack или Jira. Организовать связанную работу всех перечисленных сервисов, трекеров и интегрировать в них результаты труда продуктовых команд — также задача наших DevOps-инженеров.

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

Кроме того, наши DevOps-инженеры используют опенсорс-решения и сами пишут небольшие инструменты для интеграции с сервисами разработки (проект DevOpsHQ в GitHub).

Итоги

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

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

Автор: Тимур Гильмуллин, заместитель руководителя отдела технологий и процессов разработки в Positive Technologies