В Puppet подготовили новый отчет State of DevOps Report 2020. Он сфокусирован на платформенном подходе к доставке ПО и применении принципов DevOps для управления изменениями. Авторы рассматривают, как по мере развития этих практик в компаниях совершенствуется культура DevOps.
Обсуждая тему, исследователи вводят понятие «внутренней self-service платформы». Под ней понимается система, которую используют для автоматизации доставки IT-сервисов конечным пользователям. Такая платформа включает в себя различные решения, которые могут быть развернуты как в облаке, так и на традиционной инфраструктуре.
Внутренние self-service платформы позволяют продуктовым командам работать эффективнее. Им необязательно быть экспертами в инфраструктуре и хорошо разбираться в каждом из инструментов, они могут сосредоточиться на продукте и задачах бизнеса.
Компании с высокой культурой DevOps чаще используют self-service платформы
Высокий уровень DevOps напрямую коррелирует с использованием self-service платформ:
- 63% респондентов рассказали, что в их компании используют хотя бы одну внутреннюю self-service платформу.
- В 60% компаний, использующих внутренние платформы, от 2 до 4 таких платформ.
- Компании с высоким уровнем DevOps в 6 раз чаще используют self-service платформы, чем организации с низким уровнем.
Компании с высоким уровнем DevOps используют различные решения для самообслуживания:
- внутреннюю инфраструктуру;
- инфраструктуру в публичных облаках;
- среды разработки;
- шаблоны развертывания;
- ведение журнала аудита.
Для развития self-service платформы требуется отдельная команда
Организации, практикующие DevOps, выделяют для развития и обслуживания self-service платформ отдельные команды. В отличие от продуктовых, которые отвечают за непрерывную доставку конкретного продукта, такие команды занимаются только внутренними платформами. В частности, поддерживают инфраструктуру, среды, конвейеры развертывания и другие решения.
При этом самая большая управленческая ошибка — рассматривать построение платформы как ограниченный по времени проект. То есть выделять для работы высококвалифицированных специалистов, а позднее перекидывать их на другие задачи.
Исследователи предупреждают: так делать не стоит. Если вы хотите реализовать платформенный подход, нужно рассматривать платформу как продукт, требующий постоянной разработки и финансирования. Тогда в дальнейшем вы получите серьезное конкурентное преимущество для бизнеса.
Продуктовое мышление влияет на степень внедрения DevOps
Уровень развития DevOps коррелирует с тем, как в компании относятся к self-service платформе: как к продукту или как к проекту. В организациях с высоким уровнем DevOps продуктовое мышление встречается почти в 2 раза чаще, чем в компаниях со средним уровнем.
Если вы относитесь к платформе как к продукту, то с самого начала развиваете ее так же, как и клиентский продукт. То есть собираете пользовательские сценарии и ожидания, создаете дорожную карту продукта, выбираете показатели успеха, опрашиваете пользователей и постоянно улучшаете платформу.
Культура DevOps растет по мере развития внутренних self-service платформ
Развитие платформ самообслуживания коррелирует с развитием культуры DevOps в организации. Чтобы внедрить высшие практики DevOps, нужна зрелая платформа, а для технических решений, характерных для высших этапов, требуются новые практики. В исследовании выделяют пять этапов развития DevOps: от внедрения до самообслуживания. На каждом из них появляются свои технические решения.
По мере развития DevOps компании чаще используют облака
Организации с высоким уровнем DevOps чаще применяют облачные решения:
- 56% компаний с высоким уровнем DevOps разворачивают инфраструктуру в публичном облаке. На низком уровне ее используют только 40%.
- 46% платформенных команд с высоким уровнем DevOps отвечают в том числе за облачные сервисы провайдера, на низком уровне DevOps их 32%.
В виде облачных сервисов можно получить большинство решений для автоматизации. Например, ключевой практикой на пятом этапе развития DevOps исследователи называют микросервисную архитектуру. При использовании этого подхода части приложения разбивают на блоки, которые можно разрабатывать и обновлять независимо друг от друга. Микросервисы упаковывают в контейнеры, а для управления ими используют системы оркестрации.
Читать также
Зачем крупным компаниям микросервисы, контейнеры и Kubernetes
Решение для управления контейнерами можно получить в виде облачного сервиса. Например, платформа Mail.ru Cloud Solutions предоставляет как сервис систему оркестрации Kubernetes, сертифицированный CNCF.
Причем в нем реализовано автомасштабирование — по мере изменения нагрузки сервис сам добавляет дополнительные ноды или освобождает бездействующие. Решение страхует вас на случай внезапного роста нагрузки, например, во время распродаж и помогает оптимизировать расходы — облачному провайдеру вы платите только за используемые мощности.
По мере развития DevOps растет уровень управления изменениями
Эффективность управления изменениями увеличивается по мере того, как в компании растет уровень DevOps. Организации с высокой культурой почти в 3 раза чаще эффективно управляют изменениями, чем компании с низким уровнем.
Вот что в основном характеризует успешные компании:
- Высокая степень автоматизации тестирования и развертывания.
- Высокая степень автоматизации снижения рисков.
- Гибкие и автоматизированные процессы согласования.
- Влияние сотрудников на управление изменениями.
Для быстрого устранения критических уязвимостей нужна полная интеграция обеспечения безопасности
Полная интеграция обеспечения безопасности в процесс доставки программного обеспечения позволяет быстрее устранять критические уязвимости
Исследование показало:
45% компаний, у которых обеспечение безопасности интегрировано в процесс разработки, могут исправлять критические уязвимости в течение одного дня. Среди организаций с низкой интеграцией обеспечения безопасности так могут только 25%.
Полная интеграция обеспечения безопасности в процесс доставки ПО в итоге приводит к тому, что все проверки безопасности и соответствия проводятся в self-service режиме. У компаний, которые полностью интегрировали систему безопасности, самообслуживание встречается в 2 раза чаще.
На облачной платформе MCS можно подключить сетевое сканирование инфраструктуры. Этот сервис найдет возможные уязвимости и защитит от хакерских атак.
Ключевые выводы из исследования о состоянии DevOps
- Компании с высоким уровнем DevOps в 6 раз чаще используют self-service платформы, чем организации с низким уровнем.
- К внутренней платформе стоит относиться как к продукту, а не как к ограниченному по времени проекту.
- Организации с высоким уровнем DevOps чаще используют облачные решения. Например, инфраструктуру в публичном облаке разворачивают 56% компаний с высоким уровнем DevOps.
- По мере развития DevOps растет эффективность управления изменениями.
- Полная интеграция безопасности в процесс доставки ПО позволяет быстрее устранять критические уязвимости
Автор: Ольга Мокшина
Источник: https://mcs.mail.ru/blog/state-of-devops-report-2020
Читайте также статьи по теме:
DevOps: определение и задачи
Зачем крупным компаниям микросервисы, контейнеры и Kubernetes: как эти три технологии выводят IT на новый уровень
Чем на самом деле занимается DevOps-инженер и зачем вам его нанимать