Тимур Гильмуллин: «DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»::Журнал СА 11.2017
www.samag.ru
     
Поиск  
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Сетевой агент
О журнале
Журнал «БИТ»
Информация для ВАК
Звезды «СА»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Форум
Вакансии
Спроси юриста
Игры
Контакты
   
Слайд шоу  
Представляем работы Виктора Чумачева
Виктор Чумачев – известный московский художник, который сотрудничает с «Системным администратором» уже несколько лет. Именно его забавные и воздушные, как ИТ, иллюстрации украшают многие серьезные статьи в журнале. Работы Виктора Чумачева хорошо знакомы читателям в России («Комсомольская правда», «Известия», «Московские новости», Коммерсант и др.) и за рубежом (США, Германия). Каждый раз, получая новый рисунок Виктора, мы в редакции улыбаемся. А улыбка, как известно, смягчает душу. Поэтому смотрите на его рисунки – и пусть у вас будет хорошее настроение!
1001 и 1 книга  
19.03.2018г.
Просмотров: 3259
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 1497
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 1778
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 846
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 1392
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

Дискуссии  
17.09.2014г.
Просмотров: 17993
Комментарии: 3
Красть или не красть? О пиратском ПО как о российском феномене

Тема контрафактного ПО и защиты авторских прав сегодня актуальна как никогда. Мы представляем ...

 Читать далее...

03.03.2014г.
Просмотров: 20711
Комментарии: 1
Жизнь под дамокловым мечом

Политические события как катализатор возникновения уязвимости Законодательная инициатива Государственной Думы и силовых структур, ...

 Читать далее...

23.01.2014г.
Просмотров: 29403
Комментарии: 3
ИТ-специалист будущего. Кто он?

Так уж устроен человек, что взгляд его обращен чаще всего в Будущее, ...

 Читать далее...


  Опросы

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Тимур Гильмуллин: «DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»

Архив номеров / 2017 / Выпуск №11 (180) / Тимур Гильмуллин: «DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»

Рубрика: Разработка /  DevOps

Тимур Гильмуллин:
«DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»

В гостях у «Системного администратора» Тимур Гильмуллин, руководитель группы поддержки процессов разработки, Positive Technologies

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

Окончил Елабужский государственный педагогический университет по специальности математика и информатика. Кандидат технических наук. Работает в Positive Technologies с 2012 года. Начал свою карьеру с ведущего инженера-тестировщика, занимался автоматизацией тестирования крупных продуктов компании: MaxPatrol, MaxPatrol SIEM, PT Application Firewall, WebEngine. С 2014 года перешел в зарождающийся DevOps-отдел ведущим инженером-автоматизатором. Занимался интеграцией сервисов разработчиков с CI-системами, стандартизацией сборочных окружений, помогал с построением процессов автотестирования в командах, разработкой тестовых фреймворков для функционального, нагрузочного, приемочного тестирования и их интеграцией в общие процессы разработки.

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

Автор научных статей и блога по автоматизации процессов разработки и тестирования. Организатор, ведущий и докладчик на конференции Op!DevOps! Сооснователь и контрибьютер открытого сообщества Open DevOps Community по разработке опенсорс-инструментов автоматизации (под MIT-лицензией).

– Расскажите о своей работе в 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 – основная система организации Continuous Integration;
  • GitLab – система хранения исходного кода;
  • Artifactory – система хранения собранных бинарных версий компонент и продуктов.

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

Рисунок 1. Типовая схема проекта

Рисунок 1. Типовая схема проекта

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

Рисунок 2. Система Continuous Integration

Рисунок 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, обеспечивается серийность всех внедряемых инструментов, поэтому разработчики могут эффективнее работать, используя готовые шаблоны автоматизации.

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

Почему выбрали 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-отдел помогает разработчикам решать конкретные задачи:

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

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

– На ваш взгляд, есть ли преимущество 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. Схема ролей

Рисунок 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 как сервиса – ведь это стремление к лучшему.

Подготовил Игорь Штомпель


Комментарии
 
  22.03.2018 - 06:03 |  mayduavongts

Thanks for sharing, nice post! Post really provice useful information! http://anthaison.vn/sp/may-dua-vong-tu-dong-ts/

  22.03.2018 - 06:04 |  mayduavongts

Cảm ơn bạn đã chia sẻ, đăng bài tốt đẹp! Post thực sự provice thông tin hữu ích! http://anthaison.vn/sp/may-dua-vong-tu-dong-ts/

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru