Exploring Service Reliability Management

Service Reliability Management (SRM) provides a self-serve, guided experience for teams to manage service health. The experience is built using the Service Operations Workspace application and combines ITOM and ITSM capabilities into a single workflow.

SRM overview

Optimize service health with site reliability engineering (SRE) practices. SRM is a single operations workspace that empowers teams to improve the reliability of digital services with SRE.

• Use on-call escalations to respond to issues in a timely manner.
• Reduce setup friction with guided self-service to onboard distributed teams with separated data, empowered access, and minimal governance from central IT.

When SRM is installed, several plugins and applications are also activated. For more information, see Plugins or applications installed with ITOM AIOps.

SRM users

Table 1. Users

Users	Description	Contains Roles
admin	ServiceNow administrators manage, configure, and maintain the ServiceNow platform. In SRM, they can access and work in the Service Operations Workspace Admin Center. Only administrators can do the following: Install SRM. Add and manage SRM administrators. Create and manage integration users.	All
SRM administrator [srm_admin] Note: This role differs from the ServiceNow admin role.	SRM administrators can manage account settings, configurations, and users. Administrators can perform the following actions: Access, create, edit, or delete all SRM configurations. Add or manage integrations. Create integrations with Application Performance Monitoring (APM) tools. Set up and maintain reliability metrics. Set up and maintain error budget policies.	Manager Responder
SRM manager [srm_manager]	Managers oversee a team of SREs. Managers assign SREs to the team on-call schedule, monitor their performance, and create procedures to handle incidents and develop solutions. Managers promote resilience across all the systems and the DevOps workflows. Managers can perform the following actions within the context of their teams: Define and set up teams, on-call schedules, and services. Add and delete users such as responders and managers for the teams they're a part of. Add or manage integrations. Create Integrations with Application Performance Monitoring (APM) tools. Set up and maintain reliability metrics. Set up and maintain error budget policies.	Responder
SRM responder [srm_responder]	A Service Reliability Engineer (SRE) that uses SRM to perform everyday tasks. Responders are the individuals who are on call and diagnose and remediate incidents. Responders can only access configurations that they’re a part of. They can only access the alerts or incidents for which they have permissions. SREs can perform the following actions, within the context of their teams: Set up services, teams, and integrations. Confirm their on-call schedules. Manage incident and alert records. Update teams that they’ve created. Add other responders. Create integrations with Application Performance Monitoring (APM) tools. Set up and maintain reliability metrics. Set up and maintain error budget actions.	Inherits 17 roles including the following: cmdb_read sn_sow.sow_user sn_sow_srm.srm_responder workspace_user slo_operator

For more information, see SRM roles and responsibilities.

SRM workflow

1. Product teams in IT or Lines of Business continuously deliver new service instances and technology management services. Example: New customer billing portal.
2. Along with SLO Management, teams can register services and define service level objectives (SLOs), helping them reach business outcomes. Example: 95% monthly availability for the billing portal.
3. Monitoring integrations are set up by the teams to collect the real-time health of these services. Example: Cloud Observability.
4. Monitoring creates service level indicators (SLIs) impacting alerts when services are underperforming. Automation groups and enriches. Example: Billing portal latency is exceeding 7 s.
5. When the alerts indicate an outage or customer-impacting degradation, incidents are created and on-call notifications notify appropriate team resources. Example: A Billing SRE team is notified via phone of a latency issue on the billing portal.
6. After teams collaboratively diagnose and remediate incidents, they identify action items for improving the system's resilience. Example: The Billing team decides to add additional web server capacity.
7. Management continually reviews SLO performance, helps to prevent changes when the error budget is exhausted, and prioritizes improvement initiatives for underperforming services.

SRM benefits

Benefit	Feature	Users
Team-based experience	Working with SRM teams	SRM administrators, managers, and responders
Service registration	Working with SRM services	SRM administrators, managers, and responders
Prebuilt integrations	Working with integrations in SRM	SRM administrators, managers, and responders
Measure service health	Reliability metrics in SLO Management	SRM administrators, managers, and responders
On-call coverage	Create an SRM on-call schedule	SRM administrators, managers, and responders
Remediate high severity alerts and incidents	Working with SRM reliability tasks	SRM administrators, managers, and responders

What to explore next

To learn more about configuring and using SRM, see:

• Configuring Service Reliability Management
• Using Service Reliability Management
• Service Reliability Management reference

• Get started with Service Reliability Management
  Service Reliability Management (SRM) accelerates your path to viewing service health in the context of service level objectives and incident resolution. Helps IT Operations and DevOps teams deliver on the promise of agility, performance, and uptime.
• SRM incidents
  Track and collaborate on incidents in the Incidents tab, helping you and your teams resolve issues efficiently.