The main goals of DevOps are velocity, quality and application performance. You want to ship code as fast and often as possible. How fast you can do this will vary wildly based on your type of product, team, and risk tolerance.
Even if you don’t track any DevOps metrics around your velocity, you should at least measure how you are doing on quality. Perhaps you try to ship when you can, and you don’t really care how fast exactly. However, you always care about quality. The last thing you want is to be chasing production fires all the time.
The third piece of the equation is performance. You could argue that it is also at odds with your goals of high velocity and quality. Performance is also related to quality, but perhaps a little different
DevOps is all about continuous delivery and shipping code as fast as possible. You want to move fast and not break things. By tracking these DevOps metrics, you can evaluate just how fast you can move before you start breaking things.
- Deployment frequency – Tracking how often you do deployments is a good DevOps metric. Ultimately, the goal is to do more smaller deployments as often as possible. Reducing the size of deployments makes it easier to test and release.
- Change volume
- Deployment time – This might seem like a weird one, but tracking how long it takes to do an actual deployment is another good metric
- Lead time – Lead time as the amount of time that occurs between starting on a work item until it is deployed. This helps you know that if you started on a new work item today, how long would it take on average until it gets to production.
- Customer tickets – The best and worst indicator of application problems is customer support tickets and feedback.
- Automated test pass % – To increase velocity, it is highly recommended that your team makes extensive usage of unit and functional testing.
- Defect escape rate – Your defect escape rate is a great DevOps metric to track how often those defects make it to production.
- Availability – Depending on your type of application and how you deploy it, you may have a little downtime as part of scheduled maintenance.
- Service level agreements – Track your compliance with your SLAs.
- Failed deployments – Reversing a failed deployment is something we never want to do, but it is something you should always plan for. If you have issues with failed deployments, be sure to track this metric over time. This could also be seen as tracking mean time to failure (MTTF).
- Error rates – Good exception handling best practices are critical for good software.
- Bugs – Identify new exceptions being thrown in your code after a deployment
- Production issues – Capture issues with database connections, query timeouts, and other related issues.
- Application usage and traffic – the amount of transactions or users accessing your system
- Mean time to detection (MTTD)
- Mean time to recovery (MTTR)