Безопасная разработка: какую часть Sec занимает в DevSecOps

Всем привет! На Хабре вышла новая статья по теме безопасной разработки и DevSecOps: "Безопасная разработка: какую часть Sec занимает в DevSecOps". Сохраню тут копию.

Безопасная разработка: как жить в цифре, писать много кода и не стать жертвой хакеров

Хочу поделиться ссылкой на прошедшую 2 сентября 2021 года встречу пресс-клуба Positive Tech Press Club, на которых обсудили эволюцию угроз и технологий информационной безопасности. На встрече была затронута актуальная тема DevSecOps или безопасной разработки.

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

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

Разбор полётов

Как я говорил ранее, мы с коллегами, DevOps-инженерами, создали общедоступный репозиторий dohq-doc-templates, где лежат шаблоны инженерной документации. Они нужны для упрощения сопровождения различных регламентных работ. Шаблоны были созданы в процессе повседневной работы наших инженеров и автоматизаторов. Они могут пригодиться и вашим инженерам, для разработки регламентов и внутренней технической документации.

Сегодня расскажу про то, как мы ведём разбор полётов по техническим происшествиям.

Анализ и планирование работ по долгосрочным задачам

В нашем общедоступном репозитории dohq-doc-templates лежат шаблоны инженерной документации. Они нужны для упрощения сопровождения различных регламентных работ. Эти шаблоны были созданы в процессе повседневной работы DevOps-инженеров и автоматизаторов. Они могут пригодиться и вашим инженерам, для разработки регламентов и внутренней технической документации.

Сегодня поговорим про анализ и планирование работ по долгосрочным задачам. 

Технологическая карта производственного процесса

Продолжаю выкладывать в общедоступный репозиторий dohq-doc-templates шаблоны инженерной документации. Она нужна для упрощения и сопровождения различных регламентных работ. Шаблоны были созданы в процессе повседневной работы DevOps-инженеров и автоматизаторов. Они могут пригодиться и вашим инженерам, для разработки регламентов и внутренней технической документации.

Сегодня познакомлю вас с понятием "технологической карты производственного процесса".

Карта компетенций инженеров DevOps

Мы с коллегами из PT решили создать общедоступный репозиторий dohq-doc-templates, куда будем выкладывать шаблоны инженерной документации для упрощения и сопровождения различных регламентных работ. Они были созданы в процессе повседневной работы DevOps-инженеров и автоматизаторов. Шаблоны могут пригодиться и вашим инженерам, для разработки регламентов и внутренней технической документации.

Сегодня познакомлю вас с понятием "карты компетенций" инженеров DevOps, что это такое и как ей пользоваться.

DevSecOps. PT Application Inspector в разработке ПО: блокировка релиза

 

Вышла новая обзорная статья на Хабре по одному из направлений в DevSecOps: про то, как разработчики используют анализатор кода PT Application Inspector в релизном цикле разработки своих продуктов.

Оригинал статьи по ссылке, копия под катом.

Как работает команда DevOps в Positive Technologies

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

DevSecOps: как мы внедряли PT Application Inspector в наш продуктовый конвейер

Вышла новая обзорная статья на Хабре по одному из направлений в DevSecOps: про то, как мы внедряли анализатор кода PT Application Inspector в корпоративный сборочный конвейер.

Первоисточник: статья на Хабре. Копия под катом.

Чем занимается DevOps-инженер в команде современных разработчиков

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

Ключевая мысль статьи:

«В отличие от классических сисадминов мы не работаем по шаблонам и инструкциям 24×7×365, мы не техподдержка, в наши обязанности не входят поддержка «железной» части инфраструктуры и круглосуточное обеспечение работоспособности серверов. Я предлагаю считать DevOps-инженеров современными инженерами-технологами в производстве ПО. Такие специалисты квалифицированно решают не только задачи своей роли, но и видят весь производственный конвейер целиком, понимают, как результаты их работы будут использованы далее и интегрированы в общую производственную цепочку.»

Aptly. Как организовать контроль пакетов из внешних репозиториев и делегировать управление в продуктовые команды

Всем привет! Решил отрепостить и сюда тоже нашу совместную с коллегами из Positive Technologies Сашей Паздниковым и Никитой Драчёвым статью про Aptly: будет полезной тех-лидам от разработки. Оригинал размещён на Хабре по ссылке.

Сейчас многие компании работают без возможности прямого управления составом пакетов внешних репозиториев, даже если применяют зеркалирование, проксирование и кэширование. Это приводит к тому, что окружение выполнения постоянно меняется, в частности состав докер-образов меняется чаще, чем требуется производству.

Возможны ситуации, когда в состав разрабатываемого продукта могут попадать нежелательные изменения, которые содержатся во внешних зависимостях. Это особенно актуально во время сертификации продукта. Как следствие — затягивание сертификаций, сбои ночных тестов и интеграционного тестирования, поломки on-premise production (производственной среды, расположенной на собственных ресурсах организации) при накатывании хотфикса и прочее. В новой статье мы описали подход, который позволит избежать таких проблем.

Личный опыт: карьерный рост в DevOps-отделе компании разработчика ПО

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

Статья написана по материалам рассказа для митапа (2020-01-20), на который нас любезно пригласили коллеги из Hays для обмена опытом (можно посмотреть презентацию и текст).

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

Всем привет! На Хабре вышла наша совместная, с коллегой из DevOps (Сашей Паздниковым), статья "Управление хаосом: наводим порядок с помощью технологической карты".

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

x

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

Подробнее по ссылке.

Нагрузочное тестирование как сервис

Одна из проблем, с которой сталкиваются мультипродуктовые вендоры ПО, это дублирование компетенций инженеров разработчиков, тестировщиков и администраторов инфраструктуры в каждой команде. В том числе, это касается и дорогостоящих инженеров — специалистов в области нагрузочного тестирования. Вместо того, чтобы заниматься своими прямыми обязанностями и использовать свой уникальный опыт для выстраивания методологии проведения нагрузочного тестирования разрабатываемого продукта, подбирать оптимальные значения метрик, писать автотесты в соответствии с профилями нагрузки, инженерам зачастую приходится с нуля разворачивать тестовую инфраструктуру, настраивать инструменты нагрузки, самим встраивать их в CI-системы, настраивать мониторинг и публикацию отчётов.

Как решить некоторые проблемы с организацией тестирования вы можете прочитать в моей предыдущей статье: "Тестирование в общем сборочном конвейере: решение организационных проблем". В этой статье я расскажу про возможность интегрировать ваши нагрузочные тесты в общий CI-конвейер на GitLab CI используя концепцию "Нагрузочное тестирование как сервис" (Load testing as a service).  Также вы узнаете: как и какие докер-образы источников нагрузки Apache JMeter и Yandex.Tank можно использовать в CI-конвейере; как подключить источники нагрузки в свой проект при помощи шаблона .gitlab-ci.yml; как выглядит демо-пайплайн для запуска нагрузочных тестов и публикации результатов. Статья будет полезна инженерам по тестированию ПО и инженерам-автоматизаторам.

Тестирование в общем сборочном конвейере: решение организационных проблем

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

Статья может быть полезна тест-архитекторам, руководителям команд и отделов QC и QA, CI-инженерам, а также всем, кто сталкивался с проблемами внедрения процесса тестирования в разработку ПО.

Моделирование производственных процессов в ИТ-компании

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

Статья может быть полезна продуктовым менеджерам, руководителям команд и отделов, а также всем, кому интересно как устроен типовой процесс разработки программных продуктов, как выглядит технологическая карта и основные этапы Continuous Integration и Continuous Delivery.

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

Как мы в Positive Technologies внедряли идеи DevOps

Всем привет! Недавно на Хабре опубликовали мою статью "Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps" и интервью в журнале Системный администратор "Тимур Гильмуллин: «DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»".

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

Митап Op!DevOps! 2017

Открытое сообщество
DevOps-разработчиков
Open DevOps Community

Митап Op!DevOps! 2017 прошёл 21 октября в московском офисе компании Positive Technologies. Мы провели приятный субботний вечер и в узком, почти семейном кругу, обсудили проблемы автоматизации, которые удалось решить нашей DevOps-команде за прошедший год. Кроме того, мы рассмотрели некоторые технологии и инструменты, поделились планами развития DevOps в нашей компании.

Немного о докладах, видео и фоточки с митапа ниже.

Митап Op!DevOps! 2016

Митап Op!DevOps! прошёл 7 октября 2016 г. в Москве. На нём в формате фаст-трека были озвучены проблемы в области автоматизации разработки и тестирования, а также предложены методы и средства их решения.

Подробнее по ссылке: https://habrahabr.ru/company/pt/blog/310584/

Миссия выполнима: как развить DevOps в компании со множеством проектов

Открыта регистрация на митап Op!DevOps! 

Оригинал статьи на habrahabr: https://habrahabr.ru/company/pt/blog/310584/ (ссылка на регистрацию внизу статьи)

О пользе внедрения DevOps уже написано множество статей на Хабре и других ИТ-ресурсах, и она не ставится под сомнение. Это понятно: творческому беспорядку с подчас неочевидными зонами ответственности «обычной» разработки, где разные люди отвечают за код, бранчи, тестовые стенды, сборку и деплой и не очень-то хотят лезть на «поляну» коллег, противопоставляется высокий уровень организации.

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

Но мало просто захотеть работать «правильно», нужно еще каким-то образом к этому прийти. А здесь все совсем не так просто.