The other day I wrote a post about the process of problem resolution. This follows on.
one of my earliest mentors used to use this phrase almost every day.
“If you can’t measure it you can’t manage it”
If truth be known he used it so often we hated it. I find that the shoe is on the other foot and that it is me who uses this very same phrase (or variants of it) time and time again. In most cases I use it when talking about the resolution of problems.
My own variant on it is to say that if it can’t be measured it doesn’t exist. It’s a slightly provocative way of getting people to focus on the facts. Focus on the measurements that do exist, if they aren’t measured or can’t be measured they aren’t there. I find it’s a great way of getting people to focus on defining the problem rather than focusing on a set of issues. Most IT systems seem to have some issue or other.
When I first heard this phrase the issue of measurement was huge. The IT systems that we were trying to analyze were relatively simple single box systems. The metrics available to us were very limited. For the most part things either worked or they didn’t. When they didn’t there was a Hex Dump to grind through.
Today’s systems have a different problem. Today’s problem is deciding what to measure so that the system would keep working and not spend all of its time collecting metrics. The chances are that you haven’t been collecting the right information historically because it was too system intensive.
The skill of measurement and management is still, therefore, the same as it’s always been. You need to know what measure will tell you what and what it won’t tell you. Knowing that means that you need to know far more about a system than most people seem to want to know these days.
tags: problem_management, measurement
Discover more from Graham Chastney
Subscribe to get the latest posts sent to your email.
Graham Chastney 
The only comment I would make is to expand slightly and go off on a bit of a tangent. Situations which are emergencies need to be managed effectively, the measurement of factors which could have been instrumental to the cause may not be the best approach to a resolving that emergency quickly. I agree in post mortem that measurements should be examined but not necessarily the focus during an incident.
LikeLike
I would add that sometimes the addition of measurement, in an analogous Heisenberg manner, actually changes the thing being measured. This is definitely an issue in IT systems. The extra resources needed to measure things can often mean that the basic solution is underpower, underspecced, etc.
The best addition to some measurement is experience – and often that is deciding where and what to look at first. Though, this is not always the case – there are always exceptions.
Many of today’s complex systems are managed with equally complex tools. We have to build in rules to parse the meassurement data, we aggregate it, filter it, and all of these hopefully mean that we are alerted earlier to an impending issue as well as providing some repeatable scenarios that could be used to build self-healing tools. However, this takes time effort, and experience of the tools and the systems to be managed. Both of these stakeholders are often not brought together.
LikeLike
Thanks Stu. I agree – to a point.
If you have an incident you need to deal with the symptoms of the incident.
But you still need to be careful.
I recently had a friend we spilled some alkaline cleaner on his foot. This was in an industrial kitchen. One of his co-workers saw this as an emergency and without questioning what the spill was decided that the answer was water.
Water on an alkaline cleaner is the last thing you should do.
If they had done the appropriate amount of measurement he wouldn’t now have a very badly burnt foot.
LikeLike
Vince: I think that Heisenberg is a good analogy for the problem. I also considered referring to Schrödinger’s cat but couldn’t be bothered to explain why I was using it.
LikeLike