Исследования и оценка DevOps
Исследовательская группа в Google Cloud
Команда DORA является частью Google Cloud

DevOps Research and Assessment (сокращенно DORA ) — это команда, входящая в состав Google Cloud , которая занимается опросами общественного мнения инженеров -программистов с целью проведения исследований для движения DevOps . [1]

Команда DORA была основана Николь Форсгрен , Джезом Хамблом и Джином Кимом . [2] [3] Они проводили исследования для DevOps- компании Puppet , а затем стали независимой командой (при этом Puppet продолжила выпускать отчеты новой командой). [4] [5]

Несмотря на то, что основатели ушли, команда DORA продолжает публиковать исследования в форме ежегодных отчетов о состоянии DevOps . [6]

Отчеты о состоянии DevOps

Команда DORA начала публиковать отчеты о состоянии DevOps в 2013 году. [7] [8] В последнем отчете DORA о состоянии DevOps, опубликованном в 2023 году, было установлено, что культура и клиентоориентированность являются залогом успеха, в то время как ИИ обеспечивает ограниченные преимущества. [9] [10]

Четыре ключевых показателя DORA

В целях исследования они используют четыре ключевых показателя, иногда называемых показателями DORA , для оценки эффективности работы команд. [11] [12]

Четыре показателя следующие: [13] [14]

  • Время выполнения изменений — время на реализацию, тестирование и доставку кода для функции (измеряется от первого подтверждения до развертывания)
  • Частота развертывания — количество развертываний за определенный период времени.
  • Коэффициент неудачных изменений — процент неудачных изменений по сравнению со всеми изменениями (независимо от успеха)
  • Среднее время восстановления ( MTTR ) — время, необходимое для восстановления обслуживания после сбоя производства.

Используя эти показатели производительности, команда может оценить, как практики (например, аутсорсинг ) и факторы риска влияют на показатели производительности для инженерной команды. [15] [16] Эти показатели можно грубо измерить с помощью психометрии [17] или с помощью коммерческих услуг. [18]

Ограничения

Эти показатели использовались организациями для оценки эффективности работы каждой команды, и в октябре 2023 года команда DORA выступила с предупреждением против такого подхода. [1] [19]

Некоторые специалисты утверждают, что использование четырех ключевых метрик DORA в качестве цели в инженерных командах способствует сосредоточению на неправильных стимулах. [20] [21] Например, Джеймс Уокер, генеральный директор Curiosity Software, утверждает, что «метрики не являются окончательным путем к успеху DevOps» и что их использование для сравнения команд вызывает трудности. [22]

Исследование, проведенное ученым-компьютерщиком Джунадом Али и британской социологической фирмой Survation, показало, что как инженеры-программисты (при создании систем программного обеспечения), так и общественное мнение (при использовании систем программного обеспечения) обнаружили, что другие факторы имеют гораздо большее значение, чем результаты, которые рассматривались как «четыре ключевых показателя» (которые в конечном итоге измеряют скорость решения проблем и скорость исправления ошибок и используются для создания выводов в книге), а аппетит к риску и вознаграждению различается от сектора к сектору. [23] [24] [25] [26] [27]

Али также раскритиковал исследование на том основании, что авторитетные фирмы по опросам общественного мнения, которые соблюдают правила таких организаций, как Британский совет по опросам общественного мнения, должны публиковать свои полные результаты и таблицы необработанных данных, чего команда DORA не сделала, и, кроме того, что спонсоры опроса (Google Cloud и ранее Puppet) создают продукты, которые имеют корыстную заинтересованность в том, чтобы инженеры-программисты доставляли быстрее (несмотря на исследования, указывающие на высокий уровень выгорания среди инженеров-программистов), что в конечном итоге подтвердили результаты исследования. Несмотря на то, что авторы утверждают, что скорость доставки и качество программного обеспечения идут рука об руку, Али привел несколько контрпримеров; включая сравнительно высокое качество авиационного программного обеспечения, несмотря на нечастые изменения, в отличие от быстрой разработки приложений , которая была пионером в программном обеспечении, что привело к скандалу в британском почтовом отделении , и гибкой разработки программного обеспечения, которая использовалась в программном обеспечении, ответственном за отзывы автомобилей Toyota в 2009–2011 годах . [28] [29] [30]

Разработчик программного обеспечения Брайан Финстер также обсудил, что, поскольку корреляция не подразумевает причинно-следственную связь , организации, которые в исследовании считаются «высокоэффективными», на самом деле не являются таковыми, поскольку они сосредоточены на показателях DORA, а вместо этого сосредоточены на предоставлении ценности пользователям, и утверждает, что показатели следует использовать как «конечные индикаторы плохого здоровья, а не индикаторы того, что все идет хорошо». [31] [32]

Ускорение (книга)

Accelerate: Наука бережливого программного обеспечения и DevOps: Создание и масштабирование высокопроизводительных технологических организаций
Крышка
АвторНиколь Форсгрен , Джез Хамбл, Джин Ким
ЯзыкАнглийский
ПредметDevOps
ИздательIT-революция
Дата публикации
2018
Место публикацииСоединенные Штаты
Страницы156 (мягкая обложка)
НаградыПремия Синго [33] [34]
ISBN9781942788331
OCLC1035781633

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performanceing Technology Organizations — книга по программной инженерии, написанная в соавторстве Николь Форсгрен , Джезом Хамблом и Джином Кимом во время их работы в команде DORA. [35] В книге рассматривается, как команды разработчиков программного обеспечения, использующие Lean Software и DevOps, могут измерять свою производительность, а также то, как производительность команд разработчиков программного обеспечения влияет на общую производительность организации. [36] [14]

В книге обсуждаются их исследования, проведенные в рамках команды DORA для ежегодного отчета State of DevOps Reports . В общей сложности авторы рассмотрели 23 000 точек данных из различных компаний разных размеров (от стартапов до предприятий), коммерческих и некоммерческих, как с устаревшими, так и с современными системами. [37] [38] [39]

24 основные возможности

Авторы выделяют 24 практики по улучшению поставки программного обеспечения, которые они называют «ключевыми возможностями», и группируют их в пять категорий. [40]

Непрерывная поставка

  • Используйте контроль версий для всех производственных артефактов
  • Автоматизируйте процесс развертывания
  • Внедрить непрерывную интеграцию
  • Используйте методы разработки на основе trunk-based
  • Внедрение автоматизации тестирования
  • Поддержка управления тестовыми данными
  • Сдвиг влево на Безопасность
  • Внедрение непрерывной доставки (CD)

Архитектура

  • Используйте слабосвязанную архитектуру
  • Архитектор для расширенных команд

Продукт и процесс

  • Собирайте и реализуйте отзывы клиентов
  • Сделайте поток работы видимым через поток создания ценности
  • Работа небольшими партиями
  • Поощряйте и поощряйте командные эксперименты

Бережливое управление и мониторинг

  • Иметь облегченные процессы утверждения изменений
  • Мониторинг приложений и инфраструктуры для принятия обоснованных бизнес-решений
  • Проактивная проверка работоспособности системы
  • Улучшайте процессы и управляйте работой с помощью ограничений на незавершенное производство (WIP)
  • Визуализируйте работу для контроля качества и общения в команде

Культурный

  • Поддерживайте генеративную культуру
  • Поощряйте и поддерживайте обучение
  • Поддержка и содействие сотрудничеству между командами
  • Предоставляйте ресурсы и инструменты, которые делают работу значимой
  • Поддерживайте или воплощайте трансформационное лидерство

Ссылки

  1. ^ ab Pariseau, Beth. "Отчет Google DORA DevOps предостерегает от неправильного использования метрик - TechTarget". Качество программного обеспечения . TechTarget . Получено 20 мая 2024 г. .
  2. ^ Чан, Розали. «GitHub только что нанял лучшего исследователя DevOps из Google Cloud». Business Insider . Получено 20 мая 2024 г.
  3. ^ Хамбл, Джез (2 февраля 2019 г.). «Путешествие ДОРЫ: Исследование». Medium . Получено 20 мая 2024 г. .
  4. ^ "Состояние DevOps в 2023 году". Splunk-Blogs . Получено 5 января 2024 г.
  5. ^ Андерсон, Тим (6 октября 2022 г.). «Отчет о состоянии DevOps 2022: для безопасного программного обеспечения культура команды важнее технологий». Devclass . Получено 5 января 2024 г.
  6. ^ Визард, Майк (5 октября 2023 г.). «Последний отчет DORA подчеркивает важность культуры DevOps». DevOps.com . Получено 20 мая 2024 г.
  7. ^ «История отчетов DevOps — Puppet by Perforce». www.puppet.com . Получено 20 мая 2024 г. .
  8. ^ Маклеллан, Чарльз. «DevOps: что это такое и как это может помочь вашему бизнесу?». ZDNET . Получено 20 мая 2024 г.
  9. ^ Кернер, Шон Майкл (6 октября 2023 г.). «Отчет о состоянии DevOps от Google DORA 2023 показывает, что культура и ориентация на пользователя являются ключом к успеху». ITPro Today: ИТ-новости, инструкции, тенденции, примеры из практики, советы по карьере и многое другое . Получено 20 мая 2024 г.
  10. ^ Андерсон, Тим (10 октября 2023 г.). «Спонсируемый Google опрос DevOps показывает ограниченные преимущества ИИ, возвращение элитных команд». Devclass . Получено 20 мая 2024 г.
  11. ^ Mellifera, Nočnica (12 февраля 2024 г.). «Неправильный способ использования метрик DORA». The New Stack . Получено 20 мая 2024 г.
  12. ^ Эткин, Дилан (1 августа 2023 г.). «Почему разработчики программного обеспечения предпочитают метрики DORA». InfoWorld . Получено 20 мая 2024 г.
  13. ^ "Вы элитный исполнитель DevOps? Узнайте с помощью проекта Four Keys". Блог Google Cloud . Получено 5 апреля 2021 г.
  14. ^ ab Drugeot, Constance (30 марта 2021 г.). «Почему важна оценка DevOps и как ее правильно сделать?». DevOps Online . Получено 5 апреля 2021 г.
  15. ^ Джонсон, Эмили. «Исследование: аутсорсинг DevOps может вам дорого обойтись». InformationWeek . Получено 5 апреля 2021 г.
  16. ^ Додди, Лакшми (1 апреля 2021 г.). «Краткое содержание книги: Ускорение — Николь Форсгрен, Джин Ким, Джез Хамбл». Medium . Получено 5 апреля 2021 г. .
  17. ^ Линдерс, Бен; Хамбл, Джез. «Вопросы и ответы по книге Accelerate: Building and Scaling High Performance Technology Organizations». InfoQ . Получено 5 апреля 2021 г.
  18. ^ «Что такое метрики DORA и как они улучшают работу команд разработчиков? | Dev Interrupted Powered by LinearB». linearb.io . 17 июня 2021 г. . Получено 20 мая 2024 г. .
  19. ^ МакМюррей, Алекс (8 сентября 2023 г.). «Бывшие разработчики финансового отдела высмеивают показатели мониторинга McKinsey». eFinancialCareers . Получено 20 мая 2024 г.
  20. ^ "Perverse Instimations and DORA metrics". The Disco Blog . 19 февраля 2024 г. Получено 20 мая 2024 г.
  21. ^ «Хотите продуктивных инженеров? Начните с доверия, а не с метрик — Multitudes». www.multitudes.co . Получено 20 мая 2024 г.
  22. ^ "Все неправильно с метриками DORA - блог Aviator". 18 января 2023 г. Получено 20 мая 2024 г.
  23. ^ "75% инженеров-программистов столкнулись с ответными мерами в последний раз, когда они сообщили о правонарушении - ETHRWorldSEA". ETHRWorld.com . Получено 5 января 2024 г. .
  24. ^ Саран, Клифф. «Инженеры-программисты беспокоятся о том, чтобы высказываться». ComputerWeekly.com . Получено 5 января 2024 г. .
  25. ^ Вуллакотт, Эмма (21 ноября 2023 г.). «Возмездие на рабочем месте мешает инженерам-программистам открыто говорить о халатности». ITPro . Получено 5 января 2024 г.
  26. ^ Митчелл, Шон. «Неэтичные действия, распространенные в британской индустрии разработки программного обеспечения». IT Brief UK . Получено 5 января 2024 г.
  27. ^ Тернер, Грэм (20 ноября 2023 г.). «Отчет: Инженеры-программисты сталкиваются с негативной реакцией за сообщение о правонарушениях». Digit .
  28. ^ «Обзор правил раскрытия информации». Британский совет по опросам общественного мнения . Получено 5 января 2024 г.
  29. ^ Хьюз, Оуэн. «Разработчики истощены. Вот что нужно изменить». ZDNet . Получено 5 января 2024 г. .
  30. ^ Али, Джунаде (8 апреля 2024 г.). Как защитить себя от компьютеров-убийц: от почтового скандала до искусственного интеллекта . Engprax Ltd. ISBN 978-1068605710.
  31. ^ Финстер, Брайан (29 марта 2021 г.). «5 Minute DevOps: The Metrics are Liing». Medium . Получено 5 января 2024 г. .
  32. ^ Камминс, Холли. "Холли Камминс о X". X.com . Получено 5 января 2024 г.
  33. ^ "IT Revolution объявляет о победе книги 'Accelerate' в премии Shingo Publication Award". markets.businessinsider.com . Получено 5 апреля 2021 г. .
  34. ^ «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performance Technology» Николь Форсгрен, доктор философии, Джез Хамбл, Джин Ким, Стив Белл и Карен Уитли Белл получили премию Shingo Publication Award». Shingo Institute . 4 февраля 2020 г. Получено 5 апреля 2021 г.
  35. ^ «Список рекомендуемой литературы редакторов InfoQ 2018 года: Часть первая». InfoQ . Получено 5 апреля 2021 г. .
  36. ^ Bloomberg, Jason. «Цифровой инфлюенсер Николь Форсгрен: внедрение науки в DevOps». Forbes . Получено 5 апреля 2021 г.
  37. ^ Оверби, Стефани. «7 советов по «ускорению» DevOps». TechBeacon . Получено 5 апреля 2021 г.
  38. ^ Линдерс, Бен; Хамбл, Джез. «Вопросы и ответы по книге Accelerate: Building and Scaling High Performance Technology Organizations». InfoQ . Получено 5 апреля 2021 г.
  39. ^ Мангот, Дэйв (17 марта 2021 г.). «Get good at deliverying software» (Научитесь хорошо поставлять программное обеспечение). CIO . Получено 5 апреля 2021 г. .
  40. ^ «24 ключевых возможности для улучшения доставки программного обеспечения».
  • КОНСАЛТИНГ В ОБЛАЧНЫХ И DEVOPS-ПРОЦЕССАХ
  • QCon Plus (17–28 мая): будьте в курсе новых тенденций в области программного обеспечения. Вопросы и ответы по теме. Accelerate: создание и масштабирование организаций, занимающихся высокопроизводительными технологиями.
Взято с "https://en.wikipedia.org/w/index.php?title=DevOps_Исследования_и_Оценка&oldid=1255310877"