[Информационная безопасность] Как работает команда DevOps в Positive Technologies

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 3 месяца
Сообщений: 27286

news_bot ^® написал(а)
13-Апр-2021 16:31

Цитировать

Изображение: freepik.comВсем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки 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
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_devsecops, #_bezopastnost (безопастность), #_razrabotka (разработка), #_blog_kompanii_positive_technologies (
Блог компании Positive Technologies
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 14-Май 03:37
Часовой пояс: UTC + 5