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

Кто мы и что мы делаем

Positive Technologies ― мультипродуктовый вендор в области информационной безопасности. Продукты Positive Technologies поставляются по традиционным моделям (в виде устанавливаемого ПО), SaaS, виртуальных машин и «bare metal appliance». Наш отдел, неформально называемый у нас отделом DevOps, занимается автоматизацией и поддержкой процессов разработки всех наших продуктов: сетевого сканера ИБ XSpider, системы контроля защищенности и соответствия стандартам MaxPatrol 8, решения для управления событиями, активами и инцидентами ИБ MaxPatrol SIEM, системы управления инцидентами кибербезопасности АСУ ТП ― PT ISIM, защитного экрана уровня приложений PT Application Firewall, анализатора кода PT Application Inspector, многопоточной системы выявления вредоносного контента PT MultiScanner и всех остальных продуктов компании.

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

На данный момент наш отдел отвечает за весь конвейер по серийному производству продуктов компании и сопутствующую инфраструктуру, начиная от сборки отдельных компонент продуктов и интеграционных сборок, до их отправки на тестирование на наших серверах и доставку обновлений на географически распределенную инфраструктуру серверов обновлений и затем ― на инфраструктуру заказчиков. Несмотря на большой объем задач, с ними справляется всего 16 человек (10 человек решает задачи Continuous Integration и 6 — задачи Continuous Delivery), при этом количество людей, участвующих в разработке продуктов, более 400.

Ключевым принципом для нас является «DevOps as a Service». DevOps в современном IT уже давно выделился в самостоятельную инженерную дисциплину — очень динамичную и технологичную. И мы должны оперативно приносить эти технологии нашим разработчикам и тестировщикам. Кроме того, мы делаем их работу более комфортной, эффективной и продуктивной. Также мы разрабатываем внутренние вспомогательные инструменты, регламентируем и автоматизируем процессы разработки, сохраняем и распространяем технологические знания внутри компании, проводим технические воркшопы и делаем еще много всего полезного.

О наших первых шагах в развитии идей DevOps у нас в компании можно почитать в статье «Миссия выполнима: как развить DevOps в компании со множеством проектов».

Модель Continuous Integration и Continuous Delivery

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

Continuous Integration ― это лишь один из процессов, соединяющих разработчиков и конечных пользователей продуктов. Инфраструктура Continuous Integration в Positive Technologies развивалась вокруг связки из трех базовых сервисов:

• TeamCity — основная система организации Continuous Integration;
• GitLab — система хранения исходного кода;
• Artifactory — система хранения собранных бинарных версий компонент и продуктов.

Исторически сложилось так, что для хранения кода, организации сборок и хранения их артефактов мы выбрали GitLab, TeamCity, Artifactory. GitLab мы начали использовать очень давно из-за его удобства по сравнению с svn, который у нас был раньше. Преимущества GitLab были в том, что в нем стало проще применять изменения (merge). Что касается Artifactory, то ему нет серьезной альтернативы для хранения бинарей (компонент и инсталляторов). Впрочем, можно использовать файловые шары или MS SharePoint, но это, скорее, для тех, кто не ищет легких путей, а не для автоматизаторов. На TeamCity мы перешли после долгого периода эксплуатации и сборок на MS TFS. Переезд долго тестировался, обкатывался на небольших продуктах, и лишь затем его провели полностью. Основная причина — необходимость в простых типовых решениях и масштабируемости сборочной и тестовой инфраструктуры для многокомпонентных продуктов, написанных на различных языках программирования. TFS этого нам дать не мог.

Отдельное внимание мы уделили разработке типовых проектов для системы непрерывной интеграции. Это позволило нам добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями в TeamCity. Все проекты при этом выглядят одинаково: они включают в себя конфигурации для сборок, артефакты которых попадают в Artifactory, оттуда их можно взять для развертывания, тестирования и продвижения в релизный репозиторий проекта (см. схему на рисунке 1). Подробнее об используемой терминологии и организации типового CI-процесса мы написали в статье «DevOps best practices: рекомендации по организации конфигураций в TeamCity».



Рисунок 1. Базовые элементы типового проекта для релизной схемы сборок с продвижениями (по клику откроется в полном размере)

Мы развивали нашу систему Continuous Integration более двух лет, и к настоящему моменту, помимо стандартных конфигураций для сборки, деплоя, тестирования и продвижения сборок, мы дополнили ее разработанной нами системой Continuous Delivery, названной SupplyLab, для публикации протестированных релизных сборок на Global Update-серверы, откуда они забираются и распространяются через Front Update-серверы дальше, вплоть до инфраструктуры заказчиков, на которой разворачиваются и обновляются.

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

коммит в git — автоматическая сборка — деплой на тестовые серверы — функциональное и прочие виды автотестирования — продвижение сборки в стабильные — публикация на GUS — распространение через FUS на инфраструктуре заказчика — установка или обновление продукта на конкретных серверах.

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

• обеспечить хранение кода в системе GitLab (выделить им проект);
• разработать сборочную конфигурацию на базе одного из типовых шаблонов и обеспечить хранение собранных артефактов в системе Artifactory;
• реализовать конфигурации для деплоя артефактов на серверах тестировщиков и помочь им с реализацией тестовых конфигураций;
• в случае успешного тестирования — «продвинуть сборку» — то есть, переместить ее в хранилище протестированных артефактов в Artifactory, для чего также создается специальная конфигурация;
• далее сборка может быть опубликована на Global Update сервере компании, откуда автоматически будет распространена на FUS-серверы у заказчиков;
• при помощи скриптов инсталляции, реализованных на базе SaltStack, сборка развернется на конкретном сервере.

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



Рисунок 2. Верхнеуровневая IDEF0-модель процессов Continuous Integration и Continuous Delivery в компании Positive Technologies

Подробнее о том, как мы строили и развивали нашу систему CI/CD в начале 2017 года, — в статье «Личный опыт: как выглядит наша система Continuous Integration».

Немного о мониторинге

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

Мы используем систему мониторинга Zabbix. Для упрощения постановки служб на мониторинг, мы решили разграничить зоны ответственности между командой DevOps, разработчиками и тестировщиками, а также написали собственные инструменты для взаимодействия с Zabbix (zabbixtools) и используем подход «monitoring as code». Поясним на примере: так, если у нас есть тестовый стенд, который нужно мониторить, то тестировщик назначает ему определенную роль. У каждого хоста — только одна роль, в которой может быть несколько профилей для мониторинга процессов, служб, API и другие — их предоставляет команда DevOps (см. отношения между сущностями Zabbix на рисунке 3).



Рисунок 3. Модель отношений между сущностями в Zabbix

Для упрощения конфигурирования реализована система, при которой Zabbix забирает с целевого сервера как можно больше данных о наблюдаемых показателях. Для этого в zabbixtools используется функциональность Low Level Discovery (LLD). Это позволяет вносить любые настройки мониторинга на самом отслеживаемом сервере, а не в админке Zabbix. Файлы настроек сохраняются и обновляются при этом через git.

Про внедрение системы мониторинга можно почитать в статье «Zabbix для DevOps: как мы внедряли систему мониторинга в процессы разработки и тестирования».

Недостатки в функциональности используемых нами решений для CI/CD

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

На данный момент все сборочные конфигурации в TeamCity сопровождаются только силами нашего отдела. Мы вносим изменения в них по заявке от разработчиков, чтобы избежать проблем с поломкой ими конфигураций из-за незнания наших шаблонов и инструментов. Также наша команда следит за окружением на сборочных серверах — агентах TeamCity. У разработчиков к ним нет доступа. Мы ограничили его для того, чтобы избежать внесения несанкционированных изменений на серверах и для упрощения локализации возможных проблем и отладки сборок: раз есть гарантия, что конфигурации и окружение не меняются самовольно, значит проблема может быть либо в коде, либо сетевая. Получается, что мы не можем предоставить разработчикам возможность самостоятельно отлаживать на TeamCity сборочный процесс и настраивать окружение на сборочном агенте.

Таким образом, первая проблема заключается в том, что нам не хватает возможности делегирования сборочного процесса в команды, используя подход «build as a code». У TeamCity нет простого для использования DSL (специфического языка описания сборки). Хотелось бы, чтобы код описания сборки хранился в репозитории рядом с кодом продукта, как, например, в Travis CI. Сейчас эту проблему мы решаем путем разработки своей системы сборки — CrossBuilder. Планируется, что она предоставит разработчикам возможность давать простое описание сборки, хранить и изменять его в своем проекте, а также не будет зависеть от используемой CI-системы, реализуя сборку через систему плагинов. Кроме того, эта система позволит запускать сборки локально, через standalone-клиент.

Вторую проблему с внесением изменений в сборочные окружения, как и многие другие инженеры, мы решили для Linux с переходом на docker-образы, за подготовку которых, в том числе хранение dockerfiles, команды отвечают самостоятельно. Это позволило выделить нам пул однотипных сборочных Linux-серверов, на каждом из которых может запуститься сборка любой команды в собственном окружении. Для Windows аналогичную схему мы только начинаем прорабатывать и сейчас проводим эксперименты.

Наш инструментарий

Мы перепробовали множество различных сервисов и инструментов и со временем эволюционным путем сложился их определенный набор. Для решения задач нашего отдела мы используем: TeamCity и GitLab CI как CI-системы, GitLab для хранения кода, Artifactory как хранилище бинарных артефактов и проксирующий репозиторий, SaltStack для автоматизации сценариев развертывания окружений, Docker для изолированного сборочного окружения, SonarQube для анализа качества кода, UpSource для проведения командного код-ревью, TeamPass для безопасного хранения секретов, VMware как средство виртуализации, Zabbix для мониторинга всей нашей инфраструктуры, TestRail для хранения результатов тестранов, Kubernetes для управления контейнерами Linux и некоторые другие.

Из почтовых клиентов по корпоративному стандарту мы используем Outlook/OWA и Skype for Business, во всем остальном мы не ограничены регламентами, поэтому все используют то, что им удобно: браузеры Chrome, Thunderbird (Mozilla), Opera; файловые менеджеры Total Commander, FAR, ConEmu и обычный shell; редакторы MS Word, Notepad++ и, конечно, vim; ssh-клиенты Putty, WinSCP; снифферы и анализаторы трафика (tcpdump, windump, wireshark, burpsuite etc); из IDE любим PyCharm, Visual Studio, WebStorm; для целей виртуализации используем vSphere Client и VirtualBox.

Следуя за разработчиками нашей компании нам приходится автоматизировать процессы в основном под Linux (Debian, Ubuntu) и Windows (2003-2016). Соответственно, языковая экспертиза у нас такая же, как и у разработчиков, — это Python, C#, batch/bash. Для разработки типовых модулей, например, скриптов-метараннеров для TeamCity, у нас предусмотрен регламент, который четко описывает все шаги разработки: начиная от именования скриптов, методов, код-стиля и заканчивая правилами подготовки юнит-тестов на новый модуль и функционального тестирования всей сборки devops-tools (наши внутренние скрипты для автоматизации). В процессе разработки скриптов мы придерживаемся стандартной модели git-flow с релизными и фича-сборками. Перед тем как слить ветки, код в них обязательно проходит код-ревью: автоматический, при помощи SonarQube, и ручной от коллег.

Открытое сообщество Open DevOps Community на GitHub

Особых преимуществ для организации CI/CD процессов на базе open-source решений мы не видим. На эту тему множество споров, но каждый раз приходится выбирать, что лучше: коробочное решение, заточенное под конкретные цели, или решение «as is», которое придется допиливать и поддерживать, но предоставляющее широкие возможности кастомизации. Однако, в прошлом году на завершении нашего митапа Op!DevOps! 2016 мы рассказали о том, что нам разрешили выкладывать часть кода инструментов компании в open-source. Тогда мы только анонсировали сообщество DevOps-разработчиков Open DevOps Community. А уже в этом году, на митапе Op!DevOps! 2017 мы подвели промежуточные итоги по его развитию.

В этом сообществе мы пытаемся объединить труд различных специалистов в единую систему лучших практик, знаний, инструментов и документации. Мы хотим делиться с коллегами тем, что умеем сами, а также перенимать их опыт. Согласитесь, ведь бывает так полезно обсудить сложную задачу с понимающим коллегой. Все, что мы делаем, — открытые инструменты. Приглашаем всех пользоваться ими, улучшать, делиться знаниями и подходами в DevOps. Если у вас есть идеи или инструменты для автоматизации чего-либо, давайте делиться ими через сообщество Open DevOps Community под MIT-лицензией! Это модно, почетно, престижно.

Цель сообщества Open DevOps Community — сформировать открытые готовые решения для управления полным циклом процесса разработки, тестирования и смежных процессов, а также доставки, развертывания и лицензирования сложных, многокомпонентных продуктов.

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

• crosspm — универсальный менеджер для скачивания пакетов для сборок многокомпонентных продуктов, по правилам, заданным в манифесте (подробнее на видео по ссылке);
• vspheretools — инструмент для управления виртуальными машинами на vSphere прямо из консоли, с возможностью подключения в качестве API-библиотеки в Python-скриптах (подробнее на видео по ссылке);
• YouTrack Python 3 Client Library — Python-клиент для работы с API YouTrack;
• TFS API Python client — Python-клиент для работы с API MS TFS;
• Artifactory — Python-клиент для работы с API хранилища бинарных данных Artifactory;
• FuzzyClassificator — универсальный нейронечеткий классификатор произвольных объектов, свойства которых могут быть оценены на нечеткой измерительной шкале (подробнее на видео и в статье).

Каждый инструмент имеет автоматическую сборку в Travis CI с выкладкой в PyPI-репозиторий, где их можно найти и установить через стандартный механизм: python pip install.

Готовятся к публикации еще несколько инструментов:

• CrossBuilder — система организации кросс-платформенных сборок Build As a Code, наподобие Travis CI, но не зависящая от используемой CI-системы (TeamCity, Jenkins, GitLab-CI);
• ChangelogBuilder — генератор release notes с описанием изменений по продукту, который получает и агрегирует данные из различных трекеров: TFS, YouTrack, GitLab, Jira (подробнее на видео по ссылке);
• pyteamcity — доработанный python-клиент для работы с API TeamCity;
• MSISDK — SDK для создания msi-пакетов для инсталляторов.
• SupplyLab — система для публикации, хранения, доставки, развертывания и лицензирования продуктов и обновлений для них (подробнее на видео).

Мы приглашаем всех желающих к участию в развитии сообщества! У нас есть типовой проект ExampleProject, в котором содержатся общая структура и подробная инструкция по созданию собственного проекта в сообществе. Достаточно его скопировать и сделать свой проект по аналогии (см. шаги для подготовки на рисунке 4).



Рисунок 4. Несколько простых шагов для подготовки своего инструмента к публикации в Open DevOps Community

Ретроспектива и планы на будущее

Подходит к концу 2017 год и уже можно провести небольшой ретроспективный анализ проделанной нашей командой работы по развитию идей DevOps в Positive Technologies:

1. 2014 год — осознание того, что на имеющихся у нас тогда технологиях (svn, SharePoint, TFS) далеко не уедешь, после чего были начаты работы по исследованию и пилотированию новых CI/CD-систем.
2. 2015 год — подготовлены и настроены типовые сценарии и процессы, построен каркас системы DevOps на базовой связке TeamCity + GitLab + Artifactory (подробнее на видео).
3. 2016 год — активное наращивание объемов сборочных и тестовых конфигураций (до +200 в месяц!), перевод всех процессов на типовую релизную схему сборок с продвижениями, обеспечении стабильности и отказоустойчивости сборочной инфраструктуры.
4. 2017 год — закрепление успехов и стабилизация роста проектов, качественный переход на удобство использования всех сервисов, предоставляемых DevOps-командой. Немного подробнее:
   • по статистике, только за ноябрь 2017 для имеющихся сейчас ~4800 активных сборочных конфигураций на нашей инфраструктуре было запущено ~110000 сборок, общей длительностью ~38 мес., в среднем по 6.5 мин. на сборку;
   • 2017 год мы впервые в нашем отделе начали с годовым планом, в который входили нестандартные задачи, выходящие за обычную рутину, с которой может справиться один инженер, и решение которых потребовало значительных трудозатрат, совместных усилий и экспертизы;
   • завершили перевод сборочных окружений в docker и выделили два единых пула сборщиков под windows и linux, вплотную подошли к описанию сборок и инфраструктуры на DSL (для парадигм build as a code и infrastructure as code);
   • стабилизировали систему доставки обновлений SupplyLab (немного статистики по ней: заказчики выкачали ~80Тб обновлений, опубликовано 20 релизов продуктов и ~2000 пакетов обновлений).
   • в этом году мы стали рассматривать свои производственные процессы с точки зрения используемых технологических цепочек и получения так называемого конечного полезного результата (КПР).
     

Так зачем же нужен отдел автоматизации в нашей компании? Мы так же, как и другие подразделения, работаем на конечный полезный результат, поэтому основная цель, преследуемая от внедрения идей DevOps в наши производственные процессы, — это обеспечить последовательное снижение себестоимости производства КПР.

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

У нас продуктовая компания и исходя из ее будущих потребностей были определены глобальные задачи для нашего отдела на 2018 год:

1. Обеспечение стабильности процессов разработки за счет:
   • соблюдения SLA по сборкам и времени решения типовых задач
   • профилирования и оптимизации «узких» мест по всем направлениям работ и процессам в командах;
     
   • ускорения локализации проблем в сложных производственных цепочках за счет более точной диагностики и мониторинга).
     
2. Регулярное проведение вебинаров о существующих наработках, чтобы переиспользовать решения в продуктах и обеспечить серийность производства.
   
3. Перевод на серийное дублирование процессов и инструментов в командах. Например, ускорение подготовки типовых сборочных проектов, в первую очередь, за счет CrossBuilder.
4. Ввод в эксплуатацию системы управления составом релиза и качеством собранных компонент и инсталляторов, за счёт использования возможностей CrossPM и DevOpsLab.
5. Разработка DevOpsLab — системы автоматизации и делегирования типовых задач в проектные команды. Например, продвижение пакетов и инсталляторов, генерация типовых сборочных, деплойных и тестовых проектов, управление ресурсами проектов, выдача прав, простановка меток качества компонент и инсталляторов.
   
6. Разработка типового и тиражируемого процесса поставки наших продуктов через систему обновлений SupplyLab.
   
7. Перевод всей инфраструктуры на использование парадигмы infrastructure as code. Например, подготовить типовые сценарии развертывания виртуальных машин и окружения на них, разработать классификацию машин по потребляемым ресурсам, учет и оптимизация использования виртуальных ресурсов.
   

Вместо заключения

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

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

P.S. А вот немного наших Telegram-стикеров для DevOps-ов.

Статья подготовлена на основе интервью в журнале Системный администратор и доклада на Op!DevOps! 2017 (слайды).

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