View an SRM service

View the services that your team owns and the services your organization has in SRM.

Before you begin

Role required: Responder, Manager, or Administrator

Procedure

1. Navigate to Workspaces > Service Operations Workspace.
   You are taken to your SRM homepage.

   Note:

   If you have other SOW applications, and depending on your assigned roles, that homepage may not be the SRM homepage. It is the SOW homepage instead, with SRM alerts and incidents included in your metrics. In that case, to view SRM specific areas, select SRM modules from the left navigation pane.
2. Select Services from the left navigation pane.
3. Open a service.

   

4. View the Service header.
   The top header contains service information for:

   • Class: Application or Technical Service.
   • Managed by Group: Team responsible for the service.
   • Discovery source: Manual Entry for all services created in SRM. For existing services the values for the field in your cmdb_ci table are used.
   • Updated: Date of the last update to the service record.

   The header also contains editable tags.

   Note:

   Tags can be imported from existing services. However, you can also create tags to categorize data and drive system logic using the tag icon . For more information on creating and viewing tags, see Manually create SRM tags.

   From all tabs you can Save any changesand, if necessary, Delete the service from SRM using the More actions menu in the header.

   Note:

   You cannot delete a service from SRM unless you also have the itil or sys_admn role. If a service is deleted, your SRM SLO and SLIs are removed, as well.
5. View the Overview tab.
6. Optional: Complete the Setup service checklist

   

   Note:

   Once completed, the Service setup checklist disappears. You can use the Up icon to minimize this section. Your choice carries across to all other SRM services.

   The checklist lets you start tracking how reliable your service is. The section contains:

   • Required Setup:
     • Service Details: Set a team on the managed by group and define a service owner on the service details.
     • Alert data source: Integrate with the APM tool your team is already using to monitor this service.
   • Additional features to expand monitoring:

     Improve service monitoring by setting up additional monitors. Set goals for a ‘reliable service’ (SLO) and decide how you want to measure your service health with SLI’s.

     • Create an SLO, an SLI, and Error budget policies for SRM.
     • View SLO and Service Level Indicators (SLIs)
7. View metric cards for Reliability, Critical SLOs, At risk SLOs, Stable SLOs.

   

   Note:

   If Reliability for one SLO moves from Stable to At RISK or Critical, the card updates to reflect that.

   Reliability bases its value on Measured reliability.

8. View the All service Level Objectives section.

   This section contains your SLOs, as well as, bar graph reports for Current open alerts, and Current open incident.

   Metrics for All service level objectives are:

   • Name: Name of the SLO.
   • Reliability: How reliable the service is.

     • Stable: All SLOs in this Service have more than 25% of the error budget still available.
     • At RISK: All SLOs in this Service Have EB left, and at least one SLO for this Service has less than 25% of the error budget left.
     • Critical: Any one SLOs in this Service has burnt through its error budget
   • Remaining error budget: Displays, in days and time, ow much error budget is left.
   • Remaining breach occurrences: Number of breaches left before the threshold is reached.
   • Error budget remaining percent: Percentage of the desired SLI performance.

     Error budget is calculated based on the provided Compliance period and Objective (percentage) when creating an SLO.

   • Burn rate: Percentage rate at which an error budget is consumed.
   • SLO type: Whether Duration or Count.
   • SLI type:
     Type of the SLI based on which the metrics are calculated. The available types of SLI are as follows:

     • Availability: Percentage of time your service is available. (Default)
     • Errors: Measurement of how frequently service error occurs.
     • Latency: Time taken to service a request. The actual amount of time that elapsed.
     • Saturation: Measurement of your system fraction, emphasizing the resources that are most constrained.
   • Measured reliability: Percentage reflecting how much Reliability has gone down as the Burn rate has gone up.
   • Compliance period:
     How long the SLO is set to last.

     • Month: The duration is considered to be the current month. For example, if the current date is 26th January, the duration will be considered from 1st January till 31st January.
     • Rolling 7 days: The duration is considered to be 7 days from the current date.
     • Rolling 30 days: The duration is considered to be 30 days from the current date. For example, if the current date is 26th January, the duration will be considered from 25th December.
     • Rolling 90 days: The duration is considered to be 90 days from the current date. For example, if the current date is 26th January, the duration will be considered from 25th October.
   • Objective (percentage): Percentage of the desired SLI performance.
   • Error budget: Displays in days and time, how much error budget there is.
   • Limit (occurrences): Number of limit breaches that have occurred.

   Current open alerts are reported as Count over Severity.

   Current open incidents are reported as Count over Priority.

9. View the Details tab.
   Service details are the same, whether it is an Application or Technical Service.

   Note:

   All fields are editable. Name is the only required field. Some fields are auto-populated from existing records.

   Tab	Description
   Name	Name of the service.
   Approval group	Team responsible for approvals. Add by search or edit using the text editor.
   Model ID	Asset identifier. Add by search or edit using the text editor.
   Support group	Team members responsible for Support activities. Add by search or edit using the text editor.
   Owned by	Service owner. May not be part of an SRM team. Add by search or edit using the text editor.
   Change group	Team responsible for changes. Add by search or edit using the text editor.
   Business criticality	How important this service is the business. Choices are: 1 - most critical (default) 2 - somewhat critical 3 - less critical 4 - not critical
   Managed by	Team manager responsible for the service. Add by search or edit using the text editor.
   Version	Version of the service.
   Location	Address where the service resides. Add by search or edit using the text editor.
   Used for	Purpose for the service. Choices are: Production (default) Staging QA Test Development Demonstration Training Disaster recovery
   Operational Status	Status for the service's ability to perform operational functions. Choices are: Operational Non-operational Repair in Progress DR Standby Ready Retired Pipeline Catalog
   Service classification	Classification. SRM only supports Application Service or Technical Service.
   Comments	Addition information about the service.
   Status	Status of the service. Choices are: Operational Non-operational Repair in Progress DR Standby Ready Retired Pipeline Catalog
   Managed By Group	SRM team managing the service. Add by search or edit using the text editor.

10. View the Related Alerts tab.
    Imported related alerts are all alerts associated with this service.

    Table 1. Service related alerts

    Tab	Description
    Number	Related alert identifier.
    Severity	Severity of the related alert.
    Short description	Description of the related alert.
    Acknowledged	Whether or not the alert has been acknowledged.
    Assigned to	The team member responsible for remediating the alert.
    Configuration item	Asset associated with the related alert.
    Source	Source of the related alert.
    Parent	Primary alert for the related alert.

11. View Service map tab.
    This feature displays a read-only node map if an applicable one exists in your instance. Otherwise it has not been implemented in SRM.
12. View the Reliability metrics tab.
    The service level objectives (SLO) set the goals for service reliability and the service level indicators (SLI) set the metrics to measure system health.

    Table 2. Service Reliability metrics

    Tab	Description
    Service level objective	Name of the SLO.
    SLI type	Type of the SLI based on which the metrics are calculated. The available types of SLI are as follows: Availability: Percentage of time your service is available. (Default) Errors: Measurement of how frequently service error occurs. Latency: Time taken to service a request. The actual amount of time that elapsed. Saturation: Measurement of your system fraction, emphasizing the resources that are most constrained.
    SLO type	Type of SLO based on which metric you choose. The available types of SLO are as follows: Duration: the amount of time the service spends without breaching. It is the only value available. Count: the number of occurrences in a given compliance period.
    Compliance period	How long the SLO is set to last. Month: The duration is considered to be the current month. For example, if the current date is 26th January, the duration will be considered from 1st January till 31st January. Rolling 7 days: The duration is considered to be 7 days from the current date. Rolling 30 days: The duration is considered to be 30 days from the current date. For example, if the current date is 26th January, the duration will be considered from 25th December. Rolling 90 days: The duration is considered to be 90 days from the current date. For example, if the current date is 26th January, the duration will be considered from 25th October.
    State	State of the SLO. Choices are: Draft: The SLO is not running in your instance yet. You can add new SLIs or update existing SLIs and you can delete the SLO. : The SLO is active in your instance. You can edit, retire or delete the SLO. Note: Editing an SLO in the running state retires it and a new copy is created. See Working with Reliability metrics Retired: The SLO is no longer running in your instance. You can reactive it.
    Objective (percentage)	Percentage or count of the desired SLI performance.
    Limit (occurrences)	Number of breaches left before the limit is reached. Used by Count SLI types.
    Service level indicator	Service Level Indicator (SLI) associated with this SLO.
    Error budget	Displays, in days and time, how much error budget there is. Error budget is calculated based on the provided Compliance period and Objective (percentage) when creating an SLO. For example, for an SLI type of Availability if you select Month and set Objective (percentage) to 95%, Error budget starts with 1 day which is 5% of the month. Basically, the service downtime should not be more 1 day a month.
    Remaining error budget	Displays, in days and time, how much error budget is left.
    Remaining breach occurrences	Number of breaches left before the limit is reached.

13. View the Integrations tab.
    Integrations that monitor events and SLO/SLI for this service.

    Note:

    If you are tracking reliability metrics, ensure that integration is also enabled.

    The card for the integration can be opened or the integration deactivated using the More actions icon .

    See Working with SRM integrations to add an integration to this section.
14. View the far right side panel contains options.
    These options are automatically loaded, if available.

    • Service Relationships: If there are existing relationships, they are displayed.
    • Infrastructure Relationships: If there are existing relationships, they are displayed.
    • Attachments: Manually added attachments related to the service.
    • Templates: If there are existing templates, they are displayed. Otherwise you can create them. See Manually create an SRM template for more information.