Обзор отчета 2021 State of DevOps Report от Puppet

На днях вышел ежегодный отчет от Puppet про состояние DevOps в 2021 году. Отчет интересен тем, что он публикуется вот уже 10 лет и состоит из анализа ответов большого количества респондентов. Этот анализ позволяет оценить состояние дел в области DevOps сейчас, сравнить с прошлыми годами и понять какие есть тренды в приготовлении DevOps на текущий момент.

Отчет состоит из 11 частей, из которых первые восемь содержат основное содержимое, а последние три описывают составителей отчета, участников опроса и методику его проведения.

Если у вас есть только 5 минут, то их хватит, чтобы узнать содержимое отчета, прочитав часть

Executive Summary

В этой части тезисно подводятся итоги всего отчета. Тезисов всего 5 и вот они:

  • DevOps — это не не только автоматизация. Автоматизация — это необходимый, но не достаточный фактор
  • DevOps — это не только облака. Облака добавляют удобства работы с инфраструктурными сервисами, но одних их недостаточно
  • Идентичность команды и четкие парадигмы взаимодействия имеют значение. Здесь идет отсылка к концепциям из модели Team Topologies, авторы которой входят в список соавторов отчета. Подробнее про Team Topologies можно почитать в моих кратких обзорах: Teams as means of delivery, Team Topologies that work for flow, Evolving team interactions
  • Культурные, а не технические вопросы блокируют переход организаций со среднего уровня эволюции DevOps подходов на высший уровень
  • Платформенные команды — ключ к успеху на масштабе. Кстати, год назад я уже писал про платформенные команды

Теперь, когда основные моменты отчета озвучены пора переходить к последовательному его обзору и начать стоит с

Introduction

Puppet проводит этот опрос ежегодно уже 10 лет и DevOps подход за это время стал вездесущим. Изначально при появлении DevOps создатели не написали манифест по типу Agile Manifesto и это не недоработка, а так и было задумано. Суть была в том, чтобы участники движения не просто копировали подход, а участвовали в развитие комьюнити и шли от своих практических задач. Вот утверждение Патрика Дюбуа, который стоял у истоков движения

It’s taken me 10-plus years to come up with my own one-line definition of DevOps: “DevOps is whatever you do to bridge friction created by silos, and all the rest is engineering.” … then you’re just doing the engineering part and you’re not, in my opinion, doing the DevOps part.

В самом отчете много говорится о разнице между уровнями эволюции команд. Авторы отчета выделяют

  • 3 основных уровня: low, middle, high
  • 3 подуровня внутри middle уровня: low-mid, true-mid, high-mid

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

Кстати, эти метрики улучшались в организациях, практикующих DevOps (впервые связь с этими метриками появилась в отчете 2013 года)

  • Частота релизов (Deployment frequency)
  • Время изменения ( LTTC — Lead time for change)
  • Среднее время восстановления от ошибки (MTTR — Mean time to recovery)
  • Уровень ошибок при изменения (Change failure rates)

A decade of measuring DevOps

А вообще, понимание DevOps прошло большой путь за последние десят лет, подробнее можно посмотреть на рисунке ниже

И несмотря на то, что про DevOps теперь можно услышать походу даже от робота-пылесоса Puppet продолжает активно его изучать и писать

Because even though DevOps is everywhere, it’s rarely done well at scale, particularly in the enterprise.

Для успешной реализации DevOps подходов требуется поддержка на каждом уровне организации. Лучше всего работает подход с поддержкой топ-менеджментом трансформации снизу-вверх, когда благие начинания на уровне команд масштабируются на всю организацию.

Интересно, что в 2018 году был пик популярности терминов DevOps команда и DevOps инженер. Изначально были опасения, что часть организаций просто переименуют свой Ops-отдел и на этом принятие DevOps практик остановится. Но кое с чем этот нейминг помог: компании хотя бы узнали о трендах в инженерии ПО, а также зарплаты DevOps инженеров серьезно подросли. Не ясно с чем связано снижение популярности DevOps команд, возможно с тем, что теперь популярнее быть SRE командами. А вообще DevOps команда — это антипаттерн из подхода DevOps Topologies и есть ощущение, что

organizations that have less ambiguous team names, with more clearly defined responsibilities, are far more likely to have a higher performing IT function

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

А теперь перейдем к вкусному, а именно

Team identities & interaction paradigms

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

В этом разделе излагаются основные концепции Team Topologies — подробнее в обзорах книги: Teams as means of delivery, Team Topologies that work for flow, Evolving team interactions

Типы команд расшифровываются так:

  • Stream-aligned team — этот тип команд занимается одним значимым стримом работ, которым может быть продукт или сервис, набор фич или user journey.
  • Enabling team — цель этого типа команд в том, чтобы помочь stream-aligned teams в повышении их возможностей.
  • Complicated-subsystem team — этот тип команд отвечает за построение и поддержку частей системы, которые завязаны на специальные знания так, что большая часть членов команды должна быть специалистами в этой области знаний для понимания и изменения частей сложной подсистемы.
  • Platform team — цель этого типа команд в том, чтобы дать возможность stream-aligned командам доставлять свою работу с значительной долей автономии.

А их взаимодействия:

  • Collaboration (сотрудничество) — тесная совместная работа нескольких команд
  • X-as-a-Service — предоставление или потребление сервиса с минимальной потребностью в совместной работе
  • Facilitating — предоставление или принятие помощи для устранения препятствий в работе

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

Do we know what DevOps is yet?

За 10 лет со время старта опросов пройден большой путь. Теперь все знают сам термин и многие понимают его. Но этот раздел начинается с того, что не является DevOps:

  • DevOps — это не просто автоматизация. Автоматизация разблокирует DevOps, но DevOps не ограничивается ей. Часто фокус на автоматизации, так как это конкретная, понятная и техническая задача на небольшое количество задач. Суть в том, что технические задачи решать проще, чем организационные вопросы.
  • DevOps — это не просто облака. Из статистики ниже видно, что почти все используют облако, но многие используют его не слишком эффективно. Видно, что разница в метриках использования облака между high и low организациями отличается на порядок
  • DevSecOps — это DevOps … или нет. С точки зрения есть 2 взгляда на этот вопрос:
    1) Выделение Sec части отдельно из DevOps подхода и создание DevSecOps — это избыточный термин
    2) Индустрии нужен явный пинок относительно ИБ в процессы жизненного цикла, поэтому DevSecOps — это нужный термин

Теперь можно перейти к части, в которой объясняются причины почему организации застревают на mid уровне эволюции.

Stuck in the middle

Интересно, что большинство организаций застревают на mid уровне эволюции. Этот уровень можно поделить на 3 подуровня и дальше проанализировать почему организации не могут подняться выше по уровню зрелости.

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

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

  • аутентификация — 62%
  • оркестрация контейнеров — 60%
  • межсервисная аутентификация — 53%
  • tracing and observability — 49%
  • логирование запросов — 47%

Кроме этого на уровень эволюции организаций влияет отношение к рискам.

Забавно, что low-level организации обычно хотят избежать риска и релизятся редко и крупно. Но на самом деле маленькие и частые релизы сокращают риски, а крупные и редкие релизы на самом деле рискованнее. В итоге, отношение к риску разделяет организации по уровню. А в high-level организациях существует выстроенный Continuous Delivery пайплайн, который обеспечивает маленькие и частые релизы.

The result of all this is that those organizations that claim to be discouraging risk are actually following practices that increase risk, and many of their existing practices around risk management of infrequent deployments are simply risk management theater

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

В которой базовым уровнем являются основные исходные допущения, про которые не говорят напрямую, но на основании которых принимаются многие решения. Например, такими допущениями является отношение к риску в организации или любые другие допущения, которые используют при принятии решений (часто отклоняющих идеи), когда нет никаких логических обоснований в виде технических, финансовых или других аргументов против.

Следующий уровень — это признанные ценности, которые сформулированы в видении, миссии компании или на страничке “about us”. Эти задекларированные ценности могут отличаться от исходных допущений, что приводит к когнитивному диссонансу у сотрудников организации. Побеждают обычно исходные допущения.

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

Лидерам надо стараться внести изменения в базовые уровни, то есть менять основы культуры, а не артефакты, которые получаются на выходе. Для этого им стоит

  1. Объяснить команде почему статус кво теперь недостаточно хорош. Люди должны принять мысль о том, что требуется что-то поменять и это самый сложный шаг
  2. Пересмотреть подход кого и как нанимаем. Для изменений нужны люди с новыми идеями и горящими глазами
  3. Начать ежедневно подталкивать (nudge) поведение людей в командах в нужном направлении через похвалу, награды, признание

Изменить культуру сложно, но это определенно стоит начать делать.

Теперь стоит поговорить про

The (future) state of DevOps

В этом разделе авторы начинают свой рассказ про то, как будут выглядеть Ops команды в будущем. Два разных автора приводят разные советы. Один из них говорит, что ops’ам надо

  • понимать больше распределенные системы
  • применять практики программной инженерии к инфраструктурному скриптингу
  • soft skills

Другой эксперт говорит, что для ops’овых команды будут важны следующие скиллы:

  • Vendor engineering
  • Product engineering
  • Sociotechnical systems engineering
  • Managing the portfolio of technical investments

Также в компаниях с высоким уровнем DevOps принята платформенная модель, которая реализует модель self-service для разработчиков, которые улучшают developer experience. Для этого нужна поддержка топ-менеджмента, а также правильная структура и коммуникация команд (см. Team Topologies).

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

В организациях всех уровней есть legacy приложения, и для всех компаний важно правильно поддерживать legacy приложения.

For companies not “born” in the cloud, getting out of the DevOps starting gates and through the middle stage of adoption remains a challenge. These companies need to invest in the ability to grok legacy codebases and address modernization challenges as a critical KPI, just as critical as MTTR. The survival of their business depends on it.

А для для операционных ролей приводится такой совет

embrace the future of operations roles in a world where infrastructure is largely run by someone else, invest in the platform team approach to enable fast flow in your value stream-oriented development teams, and invest in your legacy environments so they are no longer a constant inhibitor of progress.

И в конце предлагается заменить отношение к legacy приложения путем переименования их в heritage:)

In some enterprise cultures, we’re now seeing legacy applications called “heritage” — meaning it’s what the business grew up with. We like this as an alternative to “legacy,” as it has fewer intrinsically negative connotations.

Дальше приходит время

Conclusion

В заключении автор всей серии отчетов Alanna Brown завершает весь отчет словами

We hope this year’s findings around evolutionary blockers, defining DevOps, and the role of platform teams help you scale your DevOps practices more broadly across your organization

Contributors

Здесь перечислены 16 авторов и соавторов этого отчета, а также спонсоры.

Who took the survey?

Опрос прошли 2657 человек, которые представляют разные индустрии, организации разного размера, в основном из США и Европы.

Methodology

Здесь изложена методология опроса, который проходил в марте-апреле 2021 года и для привлечения респондентов в который использовались два метода:

- Snowball sampling. Snowball sampling is a process in which respondents are encouraged to share a survey with their networks, causing the sample to grow (like a snowball rolling downhill).

- Panel sample. The snowball sample was supplemented by a third party panel, which reduces bias in our sample. Our third-party panel provider nurtures and maintains a quality, engaged membership panel built to support its market research clients and to benefit non-profit organizations. This panel provider’s unique approach to recruiting yields a highly engaged group of people who, as respondents, are dedicated to helping market research clients fulfill their information needs

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.