Serio Blog

Friday, 10 Nov 2006

This is my penultimate post on the subject of Availability statistics. The earlier post on this was Accessing Availability Statistics.

If you’ve read an understood everything up to this point (then give yourself a gold star) you’ll want to know how you can access Availability data.

This information is available through the SerioClient Chapter called ‘Performance’ (click the link underneath ‘Tools’). If you open a Performance Chapter you’ll see the following graphs that you can use:

  • Availability – Item
  • Availability – System
  • Downtime – Item (Monthly)
  • Downtime – Item (Monthly User Based)
  • Downtime – Item (Weekly)
  • Downtime – Item (Weekly User Based)
  • Downtime – System
  • Downtime – System (User Based)

All of these graphs take the ingredients I’ve mentioned before – the Availability SLA, and the Incidents logged against the Item or System – and compute your downtime data for you. All you need to have is accurate Incident records.

Let’s look at these Graphs more closely.

Availability Item, Availability System

These reports express Availability as a percentage over a monthly date range, going back from the report start date a total of 6 months and in so doing allowing the trend of Availability to be discovered. For each month, and for each Item or System , Serio computes the maximum possible Availability based on your SLA in minutes (MAXh), and then computes the amount of downtime (DOWNh) . It then expresses downtime (or more accurately, Availability) as a percentage using this formulae

PCT = ((MAXh – DOWNh) / MAXh) * 100

for each Item or System. As criteria for the graph, you need to supply two items of information:

Impact – So that the calculation of DOWNh is made solely on the basis of Incidents that are related to system unavailability.

Item Type Category (for the Availability Item graph). This is so you can restrict your graph to particular classes of Item (for instance ‘Enterprise servers’).

This style of graph has an interesting side effect – it can make what would otherwise be considered poor availability look quite good.

I’ll complete this post early next week by covering the Downtime reports, and what ‘User based’ means.

In the meantime, have a peaceful weekend, if that’s your thing. Otherwise have a riotous weekend.

Wednesday, 08 Nov 2006

Are you getting the most out of your Serio Knowledgebase? The Serio Knowledgebase is an excellent resource for assisting your Helpdesk/Service Desk in resolving Incidents. Here are a few tips to help you use it more effectively.

Finding Incidents with the Knowledgebase

The Knowledgebase is a great tool for locating Incidents when you remember what they are about, or roughly when they occurred, but can't seem to find them when searching under the appropriate problem area category or customer.

To find Incidents with the Knowledgebase,

  1. Choose 'Manage Incidents' from the SerioClient menu.
  2. Switch to the 'Knowledgebase Query' tab page.
  3. In the Search Phrase box, enter a word or phrase that you think will identify the Incident you are looking for (e.g. Print Problem). Click on 'Search Now!'.

Narrowing Down your Search

If you get too many results, there are lots of ways that you can narrow down your search.

  1. You can put your search phrase into double quotation marks, e.g. "print problem". This restricts Serio to searching for Incidents which contain the exact phrase print problem in their Description or Action History. Without the double quotation marks, Serio can match Incidents that contain either the word print or the word problem.
  2. You can use the keywords and and not in your search phrase. For example, the query print and problem will only match Incidents that contain both words, while the query print and not problem will match Incidents that contain the word print but not problem.
  3. You can narrow your search with criteria. For example, to restrict to searching for Incidents logged in June 2006:

i. Choose 'Incident/Problem/Change' from the 'Search for' drop-down menu, then select 'Incident' from the 'Equal to' drop-down menu, and click the 'Add' button.

ii. Choose 'Month' from the 'Search for' drop-down menu, then select 'Jun' from the 'Equal to' drop-down menu, and click the 'Add' button.

iii. Choose 'Year' from the 'Search for' drop-down menu, then type 2006 in the 'Equal to' field, and click the 'Add' button.

Having refined your search, click 'Search Now!' again.

Choosing Incidents to Work on

Now you have a list of Incidents that you are interested in, how do you start working on these?

  1. Right click on the list of Knowledgebase articles that Serio has found (left pane).
  2. Choose 'Add Issue to Select List' or 'Add All' to select the Incidents you want to work on.
  3. Click on 'Find Incidents'.

There's another good post over at Verso on the subject of Serio and the Service Catalog. This links into George's posts below about Availability statistics (where the subject of representing Key Services in the CMDB is discussed).

Tuesday, 07 Nov 2006

Monday, 06 Nov 2006

This post continues the topic of obtaining Availability statistics through Serio. The previous posts were ‘Using Serio to obtain availability statistics’ and ‘More on Availability statistics’.

To recap, I’ve said that:

  • you need to consider how you want your Availability data presented (and I gave 2 examples)
  • you need to define your Key Services
  • create a Service Level Agreement (SLA) for each of your Key Services
  • decide how you wish to represent your Key Services in the Configuration Management Database (CMDB).

Having done all of that, you now need to associate your SLAs directly with the Items (if you are using Items) or Services (if you are using Systems). This enables Serio to understand what the target Availability for the Key Service is question is (9:00 to 17:00 Mon-Fri, or 24-hours for example). If you didn’t know that you can associate SLAs directly with Items and Systems, you can – simply edit the Item or System in question and make the association directly.

We are almost ready to gather some statistics at this point, except for one thing.

Recall that I wrote about you need to be clear on what Unavailability means, or is defined as? Sometimes it is obvious (the Key Service is not functioning at all) but in other cases the service might be partly available. For instance, you might have an email system that can send emails within your organisation, but cannot send or receive them externally – does this constitute Unavailability? If you send a lot of emails to customers, or use emails for receiving customer orders, the answer is likely to be ‘yes’. Whatever the case in your organisation, have a clear definition of Unavailability.

This is important because you need to tell Serio what Incidents record Unavailability, and this is done through Impact. If you don’t have one already, create an Impact called ‘System down’. Use this Impact when record Incidents that result in Unavailability – this is how Serio filters routine Incidents from those that indicate a loss of service.

The other ingredient you need to add to the mix if the Key Service itself, represented in the Incident by either an Item or a System.

If we look at what is going into the Incident mix when you log an Incident, you can start to see how your Availability data is produced:

  • The Key Service on which we want Availability data, represented either by an Item or a System
  • The SLA for the Key Service (which we attach directly)
  • Something to tell us this is an Unavailability Incident (the ‘System Down’ Impact
  • A start date and time (when we logged the Incident) and an end date and time (when we resolve it)

I’ll look in my next post at how you use all of the ingredients above to produce meaningful statistics.

Friday, 03 Nov 2006

Over the the Verso blog there are a couple of very useful posts about an ITSM topic that is often either neglected or misunderstood - the Service Catalog. The posts are What is a Service Catalog and Getting your Service Catalog started.

Serio has an excellent repository for Service Catalog information that allows you to log Incident, Problems and Changes against services from the Catalog, and to use that as the basis for reporting (for example Availability reporting). This repository is referred to as Systems.

You can find out how to create a System by using the Administrator HowTo guide (look under Configuration Management).

Thursday, 02 Nov 2006

Don't be shy - we welcome guest bloggers! If you want to write guest posts that will appear here we'd be delighted. It's a chance to share experiences and ideas with other Serio users, and include information about your own company and it's services.

An ideal article:

  • Follows the general trend of this blog - covering ITSM or using different aspect of the Serio tool
  • Is 300 to 400 words long (longer articles are OK, but it would need to be in multiple posts linked together as we often do)
  • Can be understood be people outside your organisation
  • Is a nice self-contained topic

You can sign off with a link to your company and information about the services it offers.

Interested? email georger __at__

Wednesday, 01 Nov 2006

Recall that I started a thread about obtaining Availability Statistics from Serio in my last post. I talked about identifying your Key Systems and thinking about the (Service Level Agreement) SLA you have with customers widely.

Recall also that if you want to access more of the theory there is a companion availability white paper available on our web site.

Having identified your Key Services, you need to think about what your Availability for the service should be. For example you might decide that your Billing System might need to be available Mon-Fri 9:00 to 17:00, excluding all public holidays. This is your 100% availability measure – if there is no downtime falling within these times, the Billing System is available 100%. You then need to create an SLA in Serio to represent this (I’ll call it an Availability SLA), and make a note of its name (it’s OK to re-use an existing SLA if one is to hand).

Tip: Make sure you are clear on what unavailability is. Sometimes it is obvious (flames coming from the back of the server) but there are other conditions where a given service is available but not performing correctly – maybe it is running very slowly. Think about what constitutes unavailability.

Having defined what your service times are, and with a strong understanding of what unavailability means you are ready to proceed.

You now need to think about how you are going to represent your Key Services in the Configuration Management Data Base (CMDB) – this is something you must have in order to obtain Availability statistics from Serio. There are two basic approaches you can take.

Represent Key Services as Items. In order words, create an Item that represents the service in the CMDB, or use a particular server already in the CMDB for unavailability Incidents (for instance, for your email service you might decide to use the email server itself).

Represent Key Services as Systems. This is my preferred approach – create a System that represents your Key Service (the System in Serio is a collection of Items that combine together in a structured way to deliver something of value to users).

Choose a method from those listed above, and apply it consistently. Then associate your Availability SLAs with the Items or Systems you are using for Availability purposes.

I’ll continue this thread with another post later in the week.

Monday, 30 Oct 2006

Those of our Serio’s customers who have employed me as a consultant, or those whose accounts I handle, probably know I have a few (OK, many) hobby horses. One of them is Service Level Agreements (SLA), and in particular thinking about the SLA both widely and in terms of business need. Or put another way, there is rather more to it than setting target response and resolve times for each Incident that the Helpdesk/Service Desk handles.

In particular, it is important to consider Availability. What I mean is this:

  • setting targets for the availability of key business systems
  • trying to ensure that those targets are met
  • reporting on what availability is actually met

At this point I should point out we have an Availability Management white paper that looks at a lot of the theory and background for you. If you are interested in the theory and more info generally on Availability Management check the white paper.

What I’m going to do in this and coming blogs is look at how Serio handles this and delivers Availability statistics.

So, you want accurate Availability statistics? First thing that you need to know is what systems or services you need statistics for (lets call them Key Services). It is often not easy to determine this, but I’ll assume you already have this information to hand. You will then need to have what the business requirement for Availability is for these Key Services, and there are a number of ways that you can express that. I've listed two examples below.

  • Downtime in hours. You might say that the maximum acceptable downtime for a Key Service is ‘4 hours per month’.
  • Uptime as a percentage. You might say that the target availability for a key service is 99% per month, meaning for your hours of operation the service is available 99% of the time. By the way, if that sounds good it still means around 2 hours actual loss of service per month on an 9:00 to 17:00 Mon-Fri SLA.

I’m going to continue this as a topic in coming posts.

Friday, 27 Oct 2006

Here’s a really nice but often unnoticed feature of SerioClient – speed logging (or logging an Incident in a few clicks). There are number of ways you can use this (for instance, repeat Incidents) but what I will write about is common Incidents. These are things such as password resets that you might have to perform 10 times a day.

Naturally you wish to log Incidents to record these, otherwise your reporting will be inaccurate. If you are logging Incidents such as this the usual way – by categorising and writing a description – you are going about it the long winded way.

Here’s how you would go about doing things the fast way.

  1. The next time some one calls for a password reset, log the Incident correctly as you do at the moment. Categorise it, and put in a decent description. Save the Incident.
  2. Look at the bottom of the screen. You see the link marked ‘Create Serio Alert’?. Click it. Give the Alert a name such as ‘Quick Password Reset’ then save it. (You only have to do steps 1 and 2 once) For the second (and all subsequent) password reset here is what you do.
  3. Select the customer details as normal.
  4. You’ll be taken onto the Incident Details screen. But look at the screen. See that there is a tab at the top marked ‘Serio Alerts’? Click this (or type Ctrl-2 shortcut).
  5. You will be able to see an Alert called ‘Quick Password Reset’. Select it an click save.
  6. Congratulations! You’ve just speed logged an Incident with a few clicks. It looks just like the Incident you created in step 1, but has a different customer.

Try it, it’s an easy way to log Incidents in a few clicks. Don’t forget to tell your colleagues what you’ve done, and how to use the Alert.