I got a question yesterday from a large organization's IT leadership asking for recommendations on how to report infrastructure uptime to a governing board. The answer? Your governing board doesn't care.
I got a question yesterday from a large organization's IT leadership asking for recommendations on how to report infrastructure uptime to a governing board. The answer? Your governing board doesn't care.Sure, they indirectly care about infrastructure uptime. But what they really care about is service availability to the people who drive the business. If service management has taught us anything, it's that it's about the service. The techie bits matter, but they only matter to the folks in IT.
Your governing board doesn't care that the switch was up 99.99% of the time. And they don't care if your database is optimized and running efficiently. What they care about is how those items affect the business.
Good reporting systems include incidents that disrupt -- in any way -- user systems. They don't include outages that affect, for example, secondary links that are down. Of course, IT is still going to act on these incidents, but if it doesn't affect an end user, it's missing the point to record it.
It's a double edged sword. You get to not report on stuff that only affects IT; but, you must also report on anything that affects an end user. Many IT shops don't do this, and they're masking what could be an incipient user-land rebellion or an opportunity to improve IT services to users.
Here's what I mean. Let's say your Nagios or WhatsUp console is reporting that your Exchange server is up, up, up. It's reachable by ICMP, and synthetic transactions to all the relevant services are working great. However, there's an issue where users get an hourglass and can't do anything after they've been connected for 60 seconds. Outage, no? Outage, YES. Management doesn't care whether it's desktop related, infrastructure related, or application related.
15 years ago, I wrote in great enthusiastic support of service monitoring. And, I still think that IT needs to do it. Infrastructure management is an important part of service management. But in a service management context, service monitoring isn't enough.
Your service desk needs to be the central point of reporting for outages. Reporting "99.99%" infrastructure uptime doesn't tell the story. And frankly, since the service desk is typically an independent organization from your infrastructure and application group, it's a reliable third party that can help tell the real story of user impact.
How do you get started? Well, most service desks allow you to classify tickets as incidents or service requests. To gain intelligence about what the incident is, you should consider classifying these incidents by impact level (for example, no service, significant disruption, or reduced or intermittent) and scope (for example, enterprise-wide, departmental, workgroup). Collecting multi-dimensional data will allow you to tell the real story. Finally, most service desks allow you to track how long it took to close the incident.
These dimensions will allow you to present an outage report that actually means something to an executive instead of some infrastructure uptime mumbo-jumbo that doesn't tell the whole story.
Jonathan Feldman is an InformationWeek Analytics contributor who works with IT governance in North Carolina. Comment here or write to him at email@example.com.
How Enterprises Are Attacking the IT Security EnterpriseTo learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
IT Strategies to Conquer the CloudChances are your organization is adopting cloud computing in one way or another -- or in multiple ways. Understanding the skills you need and how cloud affects IT operations and networking will help you adapt.