Agreement on Service Level (SLA)
Agreement on Service Level (SLA) is an agreement between a service provider and a customer for the provision of a specific service. SLA reflects the minimum level at which the service is provided by the provider. The agreement also describes the minimum support level that the provider offers to the customer in case of service quality deterioration or cessation. SLAs may also specify preliminary conditions, limitations, costs, penalties, etc.
In RR Tech Service Management system, all SLA details are defined in the service offering associated with the SLA. Therefore, registering a new SLA involves:
- the customer,
- the service offering with the specified level of service provision,
- the service instance used by the provider to deliver the service to the customer,
- the start date of the SLA.
SLA applies to users of the service. You can define coverage for:
- all persons registered in the RR Tech Service Management system space belonging to the customer;
- all persons working within a specific organization or any of its subsidiaries;
- all persons working within a specific site;
- all persons working within a specific organization and located in a specific site;
- persons selected manually;
- all persons linked as users with the configuration item (CI) of the service instance used to deliver the service;
- all members of teams using this service instance for supporting other service instances, for which these teams are also responsible.
Through the above point, it is possible to indicate that a service instance has been received by the service provider for supporting one or more other instances of this provider’s services. For example, an application development team needs to create a development environment for a new service. To create a service instance that will become the development environment, the application development team requests the Astra Linux team to provide a new service instance of Astra Linux, and the database management team – a new database service instance of Oracle. For this, the application development team selects a service offering for Astra Linux and a service offering for Oracle.
The Astra Linux team makes the new service instance of Astra Linux available, and the database management team configures a new Oracle database instance on it. After this, the application development team can add their software to complete the creation of a new service instance.
Child Service Instances
The application development team needs to know what level of service a new Astra Linux service instance provides. To do this, the Astra Linux team registers a new SLA for the new service instance of Astra Linux and links it to the service offering selected by the application development team. This SLA specifies that its action applies to the support team of the new service instance. The database management team registers a similar SLA for the new database service instance. This allows participants in the application development team to use RR Tech Service Management for submitting requests for new Astra Linux and database service instances, and ensures that new SLAs are used to track the actual level of service provided by these two service instances.
After registering these two SLAs, the new Astra Linux and database service instances are linked to the new application service instance as ‘child’ service instances. This means that for the normal functioning of the new development service instance, access to Astra Linux and database service instances is required. This linking of service instances establishes a hierarchy of services that RR Tech Service Management uses to determine the impact of an incident affecting a child service instance on its parent service instance.
Impact Definition
Customers can specify in their SLAs (or OLA, or supporting contracts) whether a reduction in performance of the parent service instance will result from a reduction in performance of a child instance. This helps RR Tech Service Management determine the impact of service instances located higher in the hierarchy. In most cases, the parent service instance will not function if one of its child instances does not function. In the example above, the development service instance ceases operation if one of the Astra Linux or database service instances stops functioning. There are situations where the state of a parent service instance deteriorates if one of its child instances becomes unavailable. For example, the reporting function of a service runs on a separate Astra Linux service instance. If this Astra Linux service instance ceases to function, reporting becomes unavailable, but the core functionality of the service continues to operate properly.
SLA Administration
One SLA is set for each combination of service instance and customer using it.
SLAs are always registered between two organizations. The customer and provider organizations may belong to the same space or different ones. In the second case, trust relationships must be established between the provider and customer spaces to create an SLA.
If a customer organization's SLA refers to another space, the service level manager role in that space can specify a customer representative and SLA coverage.
Only a service level manager role in the space can administer that SLA.
On the Service Level Agreement (SLA) Fields page, you can find recommendations on how to use each field in the SLA form.
Paid SLAs
The concept of a paid SLA has been introduced to help service providers use RR Tech Service Management data more effectively for invoicing their customers via integration with their invoice creation tool.
In this case, an SLA is linked to a service offering and effort classes. When an operator registers the time spent on fulfilling a request, RR Tech Service Management checks whether a paid SLA is active for that request. If so, the associated effort classes from the service offering linked to a paid SLA are displayed. If not, the effort classes associated with the operator’s timekeeping table for the organization to which the operator belongs are displayed.