В конце октября 2024 года вышел 10-й юбилейный отчет Accelerate State of DevOps 2024 от DORA и Google Cloud. Напомним, что исследование Accelerate State of DevOps проводится ежегодно с 2014 года, за 10 лет в исследовании приняли участие свыше 39 тысяч профессионалов по всему миру, работающих в компаниях различных размеров и отраслей. Авторы отчета - команда DORA (DevOps Research and Assessment), входит в Google Cloud и состоит из исследователей, архитекторов, консультантов, технических писателей, экспертов по UX и DX. В этом году отчет получился на 120 страниц, мы внимательно изучили новый отчет и подготовили краткий обзор.
Исследование в этом году сфокусировано на таких направлениях и практиках, как применение AI, Platform Engineering, Developer Experience, Transformational leadership и их влиянии на Software delivery performance, Reliability, Product performance, Team и Organizational performance, Productivity и Well-being.
Что интересного мы отметили:
1. В исследовании приняло участие 3000 профессионалов из 3-х основных индустрий Technology (36%), Financial Services (16%) и Retail/E-commerce (9%). Большинство участников (76%) работают в компаниях размером больше 100 сотрудников, 46% в компаниях больше 1000 сотрудников. Инженеров и руководителей практически поровну, 90% FTE (Full-time employee), в среднем имеют 16 лет опыта, 5 лет на текущей роли и 3 года в текущей команде. Участники исследования из 104 стран, топ-6 стран: США, Великобритания, Канада, Германия, Япония, Индия, есть участники из Китая и России;
2. В начале отчета даны хорошие определения ключевым терминам, практикам и метрикам используемым в исследовании, чтобы синхронизировать терминологию;
3. По изменениям в ключевых метриках: в прошлом году Time to Restore Service переименовали в Failed deployment recovery time, в этом - Change failure rate переименовали в Change fail rate и экспериментируют с 5-й метрикой Rework rate, а также изменили концепцию измерения Software Delivery Performance;
4. По изменениям в профилях эффективности команд: соотношение Elite (19%) и Medium (35%) осталось практически без изменений с прошлого года, профиль High сократился на 10%, а Low вырос с 17% до 25%;
5. По изменениям ключевых метрик в профилях: Change fail rate у профилей High вырос с 10% до 20%, у Medium сократился с 15% до 10%, у Low сократился c 64% до 40%. Также у Low профилей Deployment frequency и Change lead time увеличился до 6 месяцев;
6. Приведены результаты исследования применение AI практик и инструментов и их влияние на ключевые метрики, индивидуальную продуктивность и инженерные практики. Этому направлению отведено четверть отчета, отметим хорошо составленный набор задач для которых применяют AI инструменты и анализ доверия к результатам работы AI инструментов;
7. Отдельная секция посвещена Platform Engineering, авторы ссылаются на книгу Team Topologies, опыт компаний Spotify и Netflix, дают хорошее определение: "Platform engineering is a sociotechnical discipline where engineers focus on the intersection of social interactions between different teams and the technical aspects of automation, self-service, and repeatability of processes". Исследуют влияние внутренних платформ (Internal developer platform) на индивидуальную и командную продуктивность, на ключевые метрики и результаты в разрезе 1, 2 и 5 лет использования платформ;
8. Исследование затронуло применение продуктового подхода (User-centered approach) в командах, в отчете приведены результаты влияния на Developer Experience и ключевые метрики;
9. Из Transformational Leadership охвачены такие аспекты как: Vision, Inspirational communication, Intellectual stimulation, Supportive leadership, Personal recognition и их влияние на Employee burnout, Job satisfaction, Team performance и Organizational performance.
#insights #devops #dora #report
Исследование в этом году сфокусировано на таких направлениях и практиках, как применение AI, Platform Engineering, Developer Experience, Transformational leadership и их влиянии на Software delivery performance, Reliability, Product performance, Team и Organizational performance, Productivity и Well-being.
Что интересного мы отметили:
1. В исследовании приняло участие 3000 профессионалов из 3-х основных индустрий Technology (36%), Financial Services (16%) и Retail/E-commerce (9%). Большинство участников (76%) работают в компаниях размером больше 100 сотрудников, 46% в компаниях больше 1000 сотрудников. Инженеров и руководителей практически поровну, 90% FTE (Full-time employee), в среднем имеют 16 лет опыта, 5 лет на текущей роли и 3 года в текущей команде. Участники исследования из 104 стран, топ-6 стран: США, Великобритания, Канада, Германия, Япония, Индия, есть участники из Китая и России;
2. В начале отчета даны хорошие определения ключевым терминам, практикам и метрикам используемым в исследовании, чтобы синхронизировать терминологию;
3. По изменениям в ключевых метриках: в прошлом году Time to Restore Service переименовали в Failed deployment recovery time, в этом - Change failure rate переименовали в Change fail rate и экспериментируют с 5-й метрикой Rework rate, а также изменили концепцию измерения Software Delivery Performance;
4. По изменениям в профилях эффективности команд: соотношение Elite (19%) и Medium (35%) осталось практически без изменений с прошлого года, профиль High сократился на 10%, а Low вырос с 17% до 25%;
5. По изменениям ключевых метрик в профилях: Change fail rate у профилей High вырос с 10% до 20%, у Medium сократился с 15% до 10%, у Low сократился c 64% до 40%. Также у Low профилей Deployment frequency и Change lead time увеличился до 6 месяцев;
6. Приведены результаты исследования применение AI практик и инструментов и их влияние на ключевые метрики, индивидуальную продуктивность и инженерные практики. Этому направлению отведено четверть отчета, отметим хорошо составленный набор задач для которых применяют AI инструменты и анализ доверия к результатам работы AI инструментов;
7. Отдельная секция посвещена Platform Engineering, авторы ссылаются на книгу Team Topologies, опыт компаний Spotify и Netflix, дают хорошее определение: "Platform engineering is a sociotechnical discipline where engineers focus on the intersection of social interactions between different teams and the technical aspects of automation, self-service, and repeatability of processes". Исследуют влияние внутренних платформ (Internal developer platform) на индивидуальную и командную продуктивность, на ключевые метрики и результаты в разрезе 1, 2 и 5 лет использования платформ;
8. Исследование затронуло применение продуктового подхода (User-centered approach) в командах, в отчете приведены результаты влияния на Developer Experience и ключевые метрики;
9. Из Transformational Leadership охвачены такие аспекты как: Vision, Inspirational communication, Intellectual stimulation, Supportive leadership, Personal recognition и их влияние на Employee burnout, Job satisfaction, Team performance и Organizational performance.
#insights #devops #dora #report
🔥6❤1
В начале 2024 года вышел отчет по состоянию Site Reliability Engineering в индустрии — The SRE Report 2024. Это уже 6-е издание отчета, исследования проводятся с 2018 года рабочей группой, состоящей из сотрудников Catchpoint и приглашенных экспертов. В подготовке текущего отчета участвовали: Niall Murphy (автор книг Site Reliability Engineering и The Site Reliability Workbook), Alex Hidalgo (автор книги Implementing SLO), Alex Elman (Indeed), Sarah Butt (SentinelOne), Kurt Andersen (Clari, SREcon) и др. Про компанию Catchpoint известно, что они разрабатывают SaaS платформу для Digital Experience Monitoring, аналогами которой являются платформы от Datadog, Dynatrace и New Relic. Исследование проводилось в форме опроса, в котором в этом году приняло участие 433 представителя индустрии, большинство из Америки и крупных компаний (больше 1000 сотрудников) из следующих индустрий: Technology, Financial, Healthcare, Government и Professional services.
Что интересного мы отметили в отчете:
1. В небольших компаниях (до 100 инженеров) функция SRE централизована в одной команде, поддерживающей несколько сервисов. С ростом компании происходит разделение на продуктовые и платформенные команды, что приводит к изменению топологий и структуры SRE команды;
2. Основные трудности с которыми сталкиваются SRE команды: планирование бюджета и ресурсов, приоритизация и архитектура. При этом найм, взаимодействие с командами и прозрачность работы отмечают реже;
3. С точки зрения влияния SRE на бизнес (Business Value) отмечают следующие факторы: Операционная эффективность (Operational Efficiencies), Customer Satisfaction и Customer Experience, Repair Times и реже — соблюдение SLA и Velocity;
4. Наиболее сложными аспектами решения инцидентов выделяют диагностику и поиск проблем, эскалацию и координацию между участниками, извлечение уроков и обучение на инцидентах;
5. Основное внимание уделяется решению инцидентов, оказывающим значительное влияние на пользователей, инцидентам высокого уровня (High severity) и тем, которые видны публично;
6. В качестве областей для улучшения процессов надежности выделяют: смену фокуса с исправлений на обучение на инцидентах, установление связей между инцидентами, выполнение action items после разбора инцидентов;
7. Разбор инцидентов, проведение ретроспектив и подготовка постмортемов лидируются в основном представителями SRE команд и руководителями, отдельная выделенная incident team встречается редко и в больших компаниях. При этом половина участников отмечает что уделяют недостаточное время для разбора инцидентов;
8. Вне дежурств SRE команды тратят в среднем 50% времени на инженерную работу, 25% времени на операционную работу (Toil) и 15% на прерывания;
9. Большинство компаний используют от 2 до 5 различных инструментов и систем для мониторинга и наблюдаемости. Не только из-за разного функционала и сценариев использования, но часто в следствии дублирования. Количество инструментов увеличивается с ростом компании;
10. Кроме мониторинга внутренних сервисов подчеркивается важность мониторинга внешних сервисов, таких как BGP, CDN, SASE, SaaS, внешние DNS и API;
11. Наиболее часто используемые метрики для измерений: Uptime/Availability, Performance/Response time, Latency и Error rate. Saturation упоминается гораздо реже, а SLOs разделяют на два типа: Uptime SLOs и Performance SLOs.
#insights #sre #reliability #report
Что интересного мы отметили в отчете:
1. В небольших компаниях (до 100 инженеров) функция SRE централизована в одной команде, поддерживающей несколько сервисов. С ростом компании происходит разделение на продуктовые и платформенные команды, что приводит к изменению топологий и структуры SRE команды;
2. Основные трудности с которыми сталкиваются SRE команды: планирование бюджета и ресурсов, приоритизация и архитектура. При этом найм, взаимодействие с командами и прозрачность работы отмечают реже;
3. С точки зрения влияния SRE на бизнес (Business Value) отмечают следующие факторы: Операционная эффективность (Operational Efficiencies), Customer Satisfaction и Customer Experience, Repair Times и реже — соблюдение SLA и Velocity;
4. Наиболее сложными аспектами решения инцидентов выделяют диагностику и поиск проблем, эскалацию и координацию между участниками, извлечение уроков и обучение на инцидентах;
5. Основное внимание уделяется решению инцидентов, оказывающим значительное влияние на пользователей, инцидентам высокого уровня (High severity) и тем, которые видны публично;
6. В качестве областей для улучшения процессов надежности выделяют: смену фокуса с исправлений на обучение на инцидентах, установление связей между инцидентами, выполнение action items после разбора инцидентов;
7. Разбор инцидентов, проведение ретроспектив и подготовка постмортемов лидируются в основном представителями SRE команд и руководителями, отдельная выделенная incident team встречается редко и в больших компаниях. При этом половина участников отмечает что уделяют недостаточное время для разбора инцидентов;
8. Вне дежурств SRE команды тратят в среднем 50% времени на инженерную работу, 25% времени на операционную работу (Toil) и 15% на прерывания;
9. Большинство компаний используют от 2 до 5 различных инструментов и систем для мониторинга и наблюдаемости. Не только из-за разного функционала и сценариев использования, но часто в следствии дублирования. Количество инструментов увеличивается с ростом компании;
10. Кроме мониторинга внутренних сервисов подчеркивается важность мониторинга внешних сервисов, таких как BGP, CDN, SASE, SaaS, внешние DNS и API;
11. Наиболее часто используемые метрики для измерений: Uptime/Availability, Performance/Response time, Latency и Error rate. Saturation упоминается гораздо реже, а SLOs разделяют на два типа: Uptime SLOs и Performance SLOs.
#insights #sre #reliability #report
🔥6👍3🙏1