Всем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки 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