В 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Средний уровень DevOpsНизкий уровень DevOps
Высокий уровень продуктового мышления34%16%7%
Средний уровень продуктового мышления47%54%21%
Низкий уровень продуктового мышления19%30%72%

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

Культура DevOps растет по мере развития внутренних self-service платформ

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

1. Внедрение—   Группы разработки приложений применяют контроль версий.
—   Команды используют для развертывания стандартный набор операционных систем. 
2. Стандартизация—   Продукты развертывают в единой стандартной операционной системе.
—   Команды используют стандартный набор технологий.
3. Расширение—   Сотрудники могут выполнять работу без ручного одобрения извне.
—   Шаблоны развертывания используются повторно.
—   Изменения в инфраструктуре тестируют перед развертыванием в производственной среде. 
4. Доставка инфраструктуры автоматизирована—   Конфигурации системы автоматизированы.
—   Обеспечение автоматизировано.
—   Конфигурации системы находятся в управлении версиями.
—   Команды инфраструктуры используют контроль версий.
—   Конфигурации приложений находятся в управлении версиями.
—   Конфигурации политик безопасности автоматизированы.
5. Самообслуживание—   Реагирование на инциденты автоматизировано.
—   Ресурсы доступны через самообслуживание.
—   Приложения перестраивают под потребности бизнеса.
—   Группы безопасности участвуют в разработке и развертывании технологий.

По мере развития DevOps компании чаще используют облака

Организации с высоким уровнем DevOps чаще применяют облачные решения:

  • 56% компаний с высоким уровнем DevOps разворачивают инфраструктуру в публичном облаке. На низком уровне ее используют только 40%.
  • 46% платформенных команд с высоким уровнем DevOps отвечают в том числе за облачные сервисы провайдера, на низком уровне DevOps их 32%.

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

Решение для управления контейнерами можно получить в виде облачного сервиса. Например, платформа Mail.ru Cloud Solutions предоставляет как сервис систему оркестрации Kubernetes, сертифицированный CNCF.

Причем в нем реализовано автомасштабирование — по мере изменения нагрузки сервис сам добавляет дополнительные ноды или освобождает бездействующие. Решение страхует вас на случай внезапного роста нагрузки, например, во время распродаж и помогает оптимизировать расходы — облачному провайдеру вы платите только за используемые мощности.

По мере развития DevOps растет уровень управления изменениями

Эффективность управления изменениями увеличивается по мере того, как в компании растет уровень DevOps. Организации с высокой культурой почти в 3 раза чаще эффективно управляют изменениями, чем компании с низким уровнем.

Высокий уровень развития DevOpsСредний уровень развития DevOpsНизкий уровень развития DevOps
Высокий уровень управления изменениями22%15%8%
Средний уровень управления изменениями65%60%53%
Низкий уровень управления изменениями22%15%8%

Вот что в основном характеризует успешные компании:

  • Высокая степень автоматизации тестирования и развертывания.
  • Высокая степень автоматизации снижения рисков.
  • Гибкие и автоматизированные процессы согласования.
  • Влияние сотрудников на управление изменениями.

Для быстрого устранения критических уязвимостей нужна полная интеграция обеспечения безопасности

Полная интеграция обеспечения безопасности в процесс доставки программного обеспечения позволяет быстрее устранять критические уязвимости

Исследование показало:

45% компаний, у которых обеспечение безопасности интегрировано в процесс разработки, могут исправлять критические уязвимости в течение одного дня. Среди организаций с низкой интеграцией обеспечения безопасности так могут только 25%.

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

На облачной платформе MCS можно подключить сетевое сканирование инфраструктуры. Этот сервис найдет возможные уязвимости и защитит от хакерских атак.

Ключевые выводы из исследования о состоянии DevOps

  1. Компании с высоким уровнем DevOps в 6 раз чаще используют self-service платформы, чем организации с низким уровнем.
  2. К внутренней платформе стоит относиться как к продукту, а не как к ограниченному по времени проекту.
  3. Организации с высоким уровнем DevOps чаще используют облачные решения. Например, инфраструктуру в публичном облаке разворачивают 56% компаний с высоким уровнем DevOps.
  4. По мере развития DevOps растет эффективность управления изменениями.
  5. Полная интеграция безопасности в процесс доставки ПО позволяет быстрее устранять критические уязвимости