Troubleshooting at Scale: What DORA Metrics Miss
summary
Argues that global DORA metrics lag and proposes actionable Local DORA proxies like developer TTR (developers spend up to 70% of coding time troubleshooting) that correlate with deployment frequency and MTTR. Shows an IntelliJ plugin + Develocity pipeline and MCP server that groups 13 test failures into two root-cause groups, suggests fixes, applies changes, and turns red builds green in the demo, and claims faster builds and targeted CI prioritization.
AI-written summary · about
chapters (10)
- 0:00The importance of feedback loops in systems
- 2:40Categorizing metrics: effort, output, outcome, and impact
- 5:14Challenges with traditional DORA metrics and delayed feedback
- 7:11Introducing Developer Time to Restore (TTR) metrics
- 11:18The impact of AI on development and troubleshooting
- 13:58Leveraging AI and Develocity for automated troubleshooting
- 15:37Demo: AI-powered failure grouping in IntelliJ
- 17:16Demo: Using MCP servers for automated build fixes
- 21:24Benefits for infrastructure teams and proactive issue resolution
- 23:57Summary and conclusion on optimizing developer feedback loops
related talks
19mAccelerating Code Quality with DORA Metrics
37mCI/CD Observability, Metrics and DORA: Shifting Left and Cleaning Up!
22mDORA Metrics: The Key to DevOps Excellence
39mDev Team Metrics that Matter
28mAccelerating Success: How to Optimize Value Delivery with DORA
23mOptimizing Delivery with DORA Metrics: How We Prepared and Where to Start
30mAchieving DORA outcomes by building reliability
25mFrom Gut Feel to Evidence: What DORA Metrics Actually Tell Us