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.
The Agile ArchiveWhen it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
2014 Analytics, BI, and Information Management SurveyITís tried for years to simplify data analytics and business intelligence efforts. Have visual analysis tools and Hadoop and NoSQL databases helped? Respondents to our 2014 InformationWeek Analytics, Business Intelligence, and Information Management Survey have a mixed outlook.