Defining Service Groups

Three Ways to Define Service Groups

1. Use Service Insight to discover IT Service endpoints and map their dependencies automatically.
2. Federate with Cherwell or ServiceNow CMDB.
3. Manually create your Service Groups.

For optimum service-oriented visibility of your critical services, we recommend that each of the following elements should be configured for each service group.

1. User Experience Checks.  At least one, and optimally four or more, User Experiences should be included with each service to incorporate the users’ perspective of the health and performance of the service.  These can also be utilized in event analysis to determine if downstream events have an impact on users or if they can be de-prioritized.
2. Service Outcome/Business Metrics.  Ultimately, every service should be producing some sort of Outcome, whether that’s completed backup jobs, completed transactions, revenue generation or some other measurable metric that communicates whether the service as a whole is performing and whether that performance is within expectations.  Please see Business Impact section of the User Guide for additional instruction on finding and configuring collection of these metrics.
3. Service Dependencies.  These are the underlying CIs that directly contribute to the service such as web servers, applications, databases, etc.  Please see the section on Service Insight for steps to discover service dependencies.
4. Shared Services.  These are the infrastructure elements that contribute to multiple services such as the network, power and air, storage, etc.  For easier inclusion into multiple Service Groups and configuration, you may want to create discrete Logical Groups for these shared services as they facilitate associating new assets to multiple Service Groups simply by associating them with a Logical Group that is already associated with these Service Groups.
5. Policies.  Policies allow you to define complex event logic to evaluate the health of the whole of the Service.  Multiple policies can be defined, we recommend at least including a general availability policy, a degraded performance policy and an outcome/dependency policy.  A Business Availability Policy can be used to control the Red-light/Green-light status of a given Service Group.
6. Service Level Agreements (SLAs).  Service Level Agreements blend one or more weighted policies together to match your documented business SLAs for each service.