A core benefit xMatters brings to incident management and IT alerting is greatly reducing the amount of time it takes to connect information about a specific problem with the people who need it — meaning the people who can use that information to do something about the problem.
But what happens when neither you nor your incident commander know who's responsible for a given service? You'd have to look up the service owner somehow, and you often can't tell who owns a service just by looking at the names of your teams. After all, your digital services might be complex enough that different teams own different parts of the same product platform, or numerous enough that one team owns multiple services. Or perhaps your teams and groups are named after something fun and relatable, like local landmarks or (cough) lesser-known planets from the Star Wars franchise, and not for the services they manage. Wouldn't it be great if you could just send a notification that targeted a specific service instead of having to hunt down its ownership in a directory?
With xMatters and the new Service Catalog included in the upcoming Missile Command release, you can do exactly that!
The Service Catalog lets you add and define your services to match your organization's infrastructure and architecture, and then assign a group to take ownership of each service.
You can also add services right from a group's Overview page:
While a group can own multiple services, each service can only have one owner. This makes sure that when you identify the service at the root cause of an incident, there's no question about exactly who is responsible for that service.
Services and incident management
An important part of building and running a successful service is collecting accurate, detailed metrics about the service's performance and the teams supporting it. So the Incidents list indicates which services are impacted by each incident and allows you to quickly filter incidents by service:
Of course, incidents can often affect more than one service, so we've also made it easy to specify any impacted services when initiating an incident, and to include them on the Incident Console.
When an incident resolver is notified about an incident, they can quickly tell which services are impacted and why they're being engaged:
And, of course, details about impacted services are included in the Post-Incident Report and exported incident status reports.
Most organizations update or change their services fairly frequently based on new versions, ownership changes, or even new dependencies, and you might not have had a chance to update your services in the Service Catalog when an incident occurs. So what happens if an incident is impacting a service that isn't defined in the Service Catalog?
No problem! The services you can add as being impacted by an incident are not limited to the ones you've already defined. You can add the name of a new service right from the Incident Console and choose to add it to the Service Catalog immediately:
If the Initiate Incident step in your workflow or the incoming signal includes service names that don't match those defined in your Service Catalog, xMatters will still include them in the Impacted Services list on the Incident Console. Even better, xMatters remembers how often an undefined service has been impacted by incidents and will offer suggestion for services to add to your catalog:
This is really just a start for the ways you can use services in xMatters to improve your service reliability. And, we're continuing to build out the Service Catalog and adding even more functionality after the Missile Command release. I'm probably not allowed to give specifics, but let's just say you should keep an eye on this space for an explanation of the difference between upstream and downstream when talking about service dependencies.
Oops. I've said too much already.
Look for the Service Catalog in your xMatters instance, along with the entire Missile Command release, coming to production on August 17.