Exploring Service Reliability Management

  • Release version: Xanadu
  • Updated August 1, 2024
  • 3 minutes to read
  • Service Reliability Management (SRM) provides a self-serve, guided experience for teams to autonomously manage the health of their technical services. The experience is built using the Service Operations Workspace application and combines ITOM and ITSM capabilities into a single service operations workflow.

    SRM overview

    Optimize service health with Service Reliability Management (SRM) for teams in IT adopting 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 identified by your monitoring and ITOM alerts 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 activated, several plugins and applications are also installed. For more information, see Plugins or applications installed with ITOM Health.

    SRM users

    Table 1. Users
    Users Description Contains Roles
    admin

    A ServiceNow administrator is responsible for the administration, development, operation, education, and maintenance of the ServiceNow platform.

    Responsible for installation and can perform Service Operations Workspace Admin Center configuration of SRM.

    All
    Administrator [srm_admin]
    Note:
    Not 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 Indicators.
    • Set up and maintain Error Budget Policies.
    • Manager
    • Responder
    Manager [srm_manager] Managers oversee a team of SREs. Managers assign SREs to the team on-call schedule, monitor their performance, create procedures to deal with incidents, and develop solutions. Managers ensure 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 and teams, on-call schedules, and services.
    • Add and delete users such as responders, and managers for the teams the are a part of.
    • Add or manage integrations.
    • Create Integrations with Application Performance Monitoring (APM) tools
    • Set up and maintain Reliability Indicators.
    • Set up and maintain Error Budget Policies.
    Responder
    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

    Infographic showing how responders, managers, and administrators manage teams, register services, define SLO, monitor integrations, respond to notifications, and remediate incidents. For details, refer to the following description.
    1. Product teams in IT or Lines of Business continuously deliver new technical and application services. Example: New customer billing portal.
    2. Along with SLO Management, teams have access to implement themselves on SRM to register these services and define service level objectives (SLO) to ensure business outcomes. Example: 95% monthly availability for 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 indicator (SLI) impacting alerts when services are under-performing. 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 call of a latency issue on the billing portal.
    6. After incidents are collaboratively diagnosed and remediated, action items for improved resilience are captured. 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 under-performing services.

    SRM benefits

    Table 2. SRM benefits
    Benefit Feature Users
    Team-based experience Working with SRM teams Service Reliability Responder, Manager, and administrator
    Service registration Working with SRM services Service Reliability Responder, Manager, and administrator
    Prebuilt integrations Working with SRM integrations Service Reliability Responder, Manager, and administrator
    Measure service health Working with Reliability metrics Service Reliability Responder, Manager, and administrator
    On-call coverage Create your SRM On-call schedule Service Reliability Responder, Manager, and administrator
    Remediate high severity alerts and incidents Working with SRM reliability tasks Service Reliability Responder, Manager, and administrator