In our search for measures of delivery performance that meet these criteria, we settled on four: delivery lead time, deployment frequency, time to restore service, and change fail rate.
This is one of the main points of the book in terms of what you should be measuring. The key thing all this achieves is making changes faster. If changes can be made quickly then developers can ship much easier. You can deploy and roll back changes faster means they’ve less risk when they go out. This gives you speed. If you’ve to take days or weeks to think about what change you can make and how you need to make it, then it slows down everything and in fact increases the risk of the change. Instead look to reduce the risk and increase the speed. Proper monitoring for the changes should exist so they can be detected and rolled back quickly.
In continuous delivery, we invest in building a culture supported by tools and people where we can detect any issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve.
A key goal of continuous delivery is changing the economics of the software delivery process so the cost of pushing out individual changes is very low.
For lots of metrics you should avoid making a particular metric the goal as you’re likely to end up with everyone optimising for that. This is probably no exception so you’ve to be careful how you go about implementing this in the real world.
Overall a decent book to get a high level overview of software engineering. Some bits of the book have become out of date because it is now common sense but I guess that’s a good indicator for the book.