 |
|
|
|
Тимур Гильмуллин: «DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»
Тимур Гильмуллин: В гостях у «Системного администратора» Тимур Гильмуллин, руководитель группы поддержки процессов разработки, Positive Technologies
– Расскажите о своей работе в Positive Technologies. – Отдел DevOps в компании Positive Technologies занимается автоматизацией и поддержкой процессов разработки всех наших продуктов: системы контроля защищенности и соответствия стандартам MaxPatrol 8, решения для управления событиями и информацией ИБ (MaxPatrol SIEM), системы управления инцидентами кибербезопасности АСУ ТП – PT Industrial Security Incident Manager, защитного экрана уровня приложений PT Application Firewall, анализатора кода PT Application Inspector, системы выявления вредоносных файлов и ссылок PT MultiScanner и др. Кроме того, мы разрабатываем внутренние вспомогательные инструменты, проводим технические воркшопы и обучение различным технологиям разработчиков из других отделов. – Что для вас «работа по принципам DevOps»? – Мы считаем, что «работа по принципам DevOps» и обязанности соответствующих отделов автоматизации сильно зависят от специфики работы конкретной компании. Специфика работы нашей компании накладывает на нас обязанность по организации поставки конечным заказчикам коробочного продукта и поддержке нескольких версий каждого продукта одновременно. Ключевым принципом для нас является DevOps as a Service. DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину, очень динамичную и технологичную. И мы должны оперативно приносить этитехнологии нашим разработчикам. Кроме того, мы делаем работу программистов и тестировщиков более комфортной, эффективной и продуктивной, а также сохраняем и распространяем знания и технологии внутри компании. На данный момент наш отдел отвечает за весь конвейер по серийному производству продуктов компании и сопутствующую инфраструктуру от сборки отдельных компонент продуктов и интеграционных сборок и до их отправки натестирование на наших серверах и доставки обновлений на географически распределенную инфраструктуру серверов обновлений и затем на инфраструктуру заказчиков. Несмотря на большой объем задач, с ними справляется всего 16человек (11 решают задачи Continuous Integration и 5 – задачи Continuous Delivery). – Что представляет собой модель Continuous Integration в вашей компании? – Positive Technologies – мультипродуктовый вендор в области информационной безопасности. Продукты Positive Technologies поставляются по традиционным моделям (в виде устанавливаемого ПО), SaaS, виртуальные и bare metal appliance. Continuous Integration – только один из процессов, соединяющих разработчиков и конечных пользователей продуктов. Инфраструктура Continuous Integration в Positive Technologies состоит из связки трех базовых сервисов:
Отдельное внимание уделено разработке типовых проектов для системы непрерывной интеграции. Это позволило добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями в TeamCity. Все проекты при этом выглядят типовыми: они включают в себя конфигурацию сборок, артефакты которых попадают в артефакторий, после чего осуществляется их развертывание, тестирование и продвижение в релизный репозиторий проекта (см. схему на рис. 1).
Рисунок 1. Типовая схема проекта Мы развиваем нашу систему Continuous Integration более двух лет, и в настоящий момент она выглядит следующим образом. Помимо стандартных конфигураций для сборки, деплоя, тестирования и продвижения сборок, сейчас у нас добавилась система публикации протестированных релизных сборок на Global Update-серверы, откуда они распространяются дальше вплоть до инфраструктуры заказчика (см. схему на рис. 2).
Рисунок 2. Система Continuous Integration Более подробно о том, как мы строили нашу систему Continuous Integration и как она выглядела на начало 2017 года, можно прочитать по ссылке: https://habrahabr.ru/company/pt/blog/313616/. – Какие сервисы используете для разработки? – Мы перепробовали множество различных сервисов и инструментов, и со временем эволюционным путем сложился их определенный набор. Для решения задач нашего отдела мы используем: TeamCity и GitLab CI (CI-системы), GitLab (хранилище кода), Artifactory (хранилище бинарных артефактов), SaltStack (сценарии автоматизации), Docker (окружения для сборок), SonarQube (анализатор кода), UpSource (код-ревью), TeamPass (безопасное хранилище секретов), VMware (средства виртуализации), Zabbix (мониторинг инфраструктуры), TestRail (хранилище тестранов), Kubernetes (управление контейнерами Linux) etc. – Какие инструменты используете для разработки (среды, ОС и т.п.)? – Следуя за разработчиками нашей компании, нам приходится автоматизировать процессы в основном под Linux (Debian, Ubuntu) и Windows (2003-2016). Соответственно, языковая экспертиза у нас, так же как и у разработчиков, – этоPython 3.*, C#, batch/bash. – Какое ПО предпочитаете для повседневного использования (браузеры, почтовые клиенты, редакторы и т.п.)? – Из почтовых клиентов по корпоративному стандарту мы используем Outlook/OWA и Skype for Business, во всем остальном мы не ограничены регламентами, поэтому все используют то, что им удобно: браузеры Chrome, Thunderbird (Mozilla), Opera; файловые менеджеры Total Commander, FAR, ConEmu и обычный shell; редакторы MS Word, Notepad++ и, конечно, vim; ssh-клиенты Putty, WinSCP; снифферы и анализаторы трафика (tcpdump, windump, burpsuite etc); изIDE любим PyCharm, Visual Studio, WebStorm; для целей виртуализации используем vSphere Client и VirtualBox. – Как происходила автоматизация в вашей компании? С чего начинали? Почему выбрали именно TeamCity+GitLab+Artifactory? – Для нас толчком стало понимание, что централизованные решения и высокий уровень организации автоматизации разработки – это лучше, чем «творческий хаос» обычной разработки. Кроме того, любая автоматизация призвана сокращать себестоимость процесса разработки и внедрения. В компаниях, где есть выделенная служба DevOps, обеспечивается серийность всех внедряемых инструментов, поэтому разработчики могут эффективнее работать, используя готовые шаблоны автоматизации.
Почему выбрали GitLab, TeamCity, Artifactory? Как принято говорить, так исторически сложилось. Нам нужно было где-то хранить код, организовывать сборки, хранить артефакты сборок. Отдельные решения существовали всегда. GitLab мы начали использовать очень давно из-за его удобства по сравнению с svn, который у нас был раньше. Преимущества GitLab в том, что в нем проще делать мержи изменений. Что касается Artifactory, то ему нет альтернативы для хранения бинарей (компонент и инсталляторов). Впрочем, можно использовать файловые шары или MS SharePoint, но это скорее для тех, кто не ищет легких путей, а не для автоматизаторов . На TeamCity мы перешли после долгого периода эксплуатации и сборок на MS TFS. Переезд долго тестировался, обкатывался на небольших продуктах, а затем стал массовым. Основная причина – необходимость в простых типовых решениях и масштабируемости сборочной и тестовой инфраструктуры для многокомпонентных продуктов, написанных на различных языках программирования. TFS этого нам дать не мог. Подробнее о наших «первых шагах» можно прочитать в статье в блоге: https://habrahabr.ru/company/pt/blog/310584/. – Какие проблемы в используемых решениях в ходе реализации CI/CD были обнаружены? Чего вам не хватает в функциональности этих решений? – Все проблемы по сервисам мы фиксируем в нашей базе знаний DevOps. Обобщить проблемы каждого конкретного сервиса в пределах одной статьи довольно сложно, поэтому отмечу только наиболее показательные, например для CI-системы TeamCity. На данный момент все сборочные конфигурации в TeamCity сопровождаются только силами нашего отдела. Мы вносим изменения по заявке от разработчиков, чтобы избежать проблем с поломкой конфигураций из-за незнания наших шаблонов и инструментов. Также разработчики периодически хотят запускать аналогичный сборочный процесс на собственной машине для отладки. Кроме того, наша команда следит за сборочным окружением на серверах, где установлены агенты TeamCity. У разработчиков к ним нет доступа во избежание внесения несанкционированных изменений на серверах, а также и для упрощения локализации возможных проблем с запускаемыми на серверах сборками. Таким образом, нам не хватает возможности делегирования сборочного процесса в команды, используя подход build as a code. У TeamCity нет простого для использования DSL (специфического языка описания сборки. Хотелось бы, чтобы код описания сборки хранился в репозитории рядом с кодом продукта (как, например, в Travis CI). Эту проблему сейчас нам приходится решать путем разработки своей собственной системы сборки – CrossBuilder. Планируется, что она предоставит разработчикам возможность давать простое описание сборки, хранить и изменять его в своем проекте, а также не будет зависеть от используемой CI-системы, реализуя сборку через систему плагинов. Кроме того, эта система позволит запускать сборки локально. Проблему с внесением изменений в сборочные окружения, как и многие другие, мы решили для Linux с переходом на docker-образы, за подготовку которых, в том числе хранение dockerfiles, команды отвечают самостоятельно. Этопозволило выделить нам пул однотипных сборочных Linux-серверов, на каждом из которых может запуститься сборка любой команды в собственном окружении. Для Windows аналогичную схему мы только начинаем прорабатывать исейчас проводим эксперименты. – Не могли бы привести пример того, как выстраиваете и сопровождаете на практике CI/CD? – Как я уже отмечал ранее, все решения, предоставляемые нашей DevOps-командой, – типовые, масштабируемые и построенные на шаблонах. Несмотря на то что языки, используемые командами, алгоритмы сборки и особые пожелания укоманд различны, общая схема остается неизменной (смотрите схему из вопроса про Continuous Integration): коммит в git – сборка – деплой на тестовые серверы – функциональное и прочие виды автотестирования – продвижения сборки встабильные – публикация на GUS – распространение через FUS на инфраструктуре заказчика – установка или обновление продукта на конкретных серверах у заказчика. На каждом этапе этого процесса DevOps-отдел помогает разработчикам решать конкретные задачи:
Каждый этап мы контролируем через систему мониторинга. После отладки процесса в случае сбоя разработчики могут написать заявку в нашу службу, мы постараемся локализовать проблему и исправить ее. – На ваш взгляд, есть ли преимущество Open Source при использовании методологии DevOps? – Особых преимуществ не вижу. На эту тему множество споров, но каждый раз приходится выбирать, что лучше: коробочное решение, заточенное под конкретные цели, или решение as is, которое придется допиливать и поддерживать, нопредоставляющее широкие возможности кастомизации. – Процесс языковой экспертизы. Как организован? Особенности? – Основные используемые языки разработки в нашей компании – это C# и Python. В нашем отделе разработка ведется в основном на Python. Для разработки типовых модулей, например скриптов-метараннеров для TimCity, у нас предусмотрен регламент, который четко описывает все шаги разработки, начиная от именования скриптов, методов, код-стиля и заканчивая правилами подготовки юнит-тестов на новый модуль и функционального тестирования новой сборки devops-tools (наши внутренние скрипты для автоматизации всех сервисов). В процессе разработки скриптов мы придерживаемся стандартной модели git-flow (http://nvie.com/posts/a-successful-git-branching-model) с релизными ифича-сборками. Перед мерджем код в ветках обязательно проходит код-ревью (автоматический, при помощи SonarQube, и ручной от коллег). – Расскажите про мониторинг. – В нашей команде выделены ответственные за направление работ, связанное с мониторингом: от заявки на подключение сервера или сервиса на мониторинг до конечного красивого дашборда системы управления (графики, метрики, система оповещения), предоставляемого в команды. Функциональные обязанности этой группы: настройка и предоставление службы мониторинга как сервиса, предоставление типовых шаблонов для мониторинга серверов и служб различных типов, проектирование иерархической системы мониторинга, прогнозирование нехватки ресурсов. Мы используем систему мониторинга Zabbix. Для упрощения постановки служб на мониторинг мы решили разграничить зоны ответственности между командой DevOps, разработчиками и тестировщиками, а также написали собственные инструменты для взаимодействия с Zabbix (zabbixtools https://github.com/devopshq/zabbixtools) и используем подход monitoring as code. Расскажу на примере: так, если у нас есть хост, который нужно мониторить, то тестировщик назначает ему определенную роль. У каждого хоста – только одна роль, в которой может быть несколько профилей для мониторинга процессов, служб, API и другие – их предоставляет команда DevOps (см. рис. 3).
Рисунок 3. Схема ролей Для упрощения конфигурирования было решено реализовать систему, при которой Zabbix забирает с целевого сервера как можно больше данных о наблюдаемых показателях. Чтобы упростить настройку, в zabbixtools используется функциональность Low Level Discovery (LLD). Это позволяет вносить любые настройки мониторинга на самом отслеживаемом сервере, а не в админке Zabbix. Подробнее о том, как мы внедряли систему мониторинга, можно прочитать в блоге: https://habrahabr.ru/company/pt/blog/325276. – Принимаете ли участие в конференциях, встречах и т.п.? В каких ближайших мероприятиях планируете принять участие? – Раньше я часто посещал различные профильные конференции, например от Yandex, но не выступал на них. Остальные сотрудники отдела постоянно посещают конференции и митапы в Москве и Санкт-Петербурге. К сожалению, сейчас работа по развитию нашего DevOps-отдела занимает все свободное время, но я стараюсь посещать мероприятия, которые проводит наша компания, одно из таких – международный форум по практической безопасности Positive Hack Days (https://www.phdays.ru). Кроме того, мы сами проводим воркшопы по автоматизации не только внутри компании, но и внешние, например, в прошлом году провели первый митап Op!DevOps! 2016 (https://www.ptsecurity.com/ru-ru/about/news/110230). Посмотреть, очем мы рассказывали на митапе, можно по ссылке: https://www.youtube.com/playlist?list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn. В этом году 21 октября мы провели Op!DevOps! 2017 в закрытом формате. Мы пригласили ограниченное число инженеров из других компаний для обмена опытом. Мы хотим делиться с коллегами тем, что умеем, и слушать о том, что умеют они. Согласитесь, ведь полезно обсудить сложную задачу с понимающим коллегой. Все, что мы делаем, – открытые инструменты для сообщества Open DevOps Community (https://github.com/devopshq). Приглашаем всех пользоваться, улучшать, делиться знаниями и подходами. – Поделитесь интересными, запомнившимися случаями из опыта реализации DevOps? – Сложно выделить какой-то один случай, ведь, как правило, запоминаются авралы и их разрешение. Мы не приветствуем авралы, а любим четко запланированную работу по выстроенному процессу – когда все стабильно, предсказуемо, ожидаемо, а в случае форс-мажоров предусмотрены запасные варианты. По такому принципу мы из года в год стараемся строить наш сервис. Нам интересно работать с любыми задачами по автоматизации: выстраивать CI/CD, обеспечивать отказоустойчивость релизных сборочных процессов, заниматься мониторингом и оптимизацией ресурсов, а также помогать людям выстраивать процессы в командах и разрабатывать полезные инструменты. Для нас значим последовательный процесс построения DevOps как сервиса – ведь это стремление к лучшему. Подготовил Игорь Штомпель |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
