Introduction to NonStop Operations Management
Operations Documentation
Introduction to NonStop Operations Management–125507
4-3
Creating Service-Level Agreements
•
The acceptable level of service when the system is stressed, such as during peak
workloads, partial equipment failures, and medium-term increases in workload.
Creating Service-Level Agreements
When creating service-level agreements, following a few simple steps can help ensure
that the operations services provided match the needs and expectations of your users.
For each service, the following steps should be performed with the user (or someone
representing the user):
1. Define the business need.
2. Establish quality requirements.
3. Establish measurements for the service.
4. Follow up and adjust the process.
Step 1—Define the Business Need
The first step in creating a service-level agreement involves determining what business
need or goal you are trying to meet with the service. For instance, by implementing
automation to detect and recover from problems before problems affect end users, you
can reduce help-desk phone calls. This service helps meet the business goal of
improving staff efficiency.
Step 2—Establish Quality Requirements
For each service you provide, there will be a number of requirements that the user will
consider critical such as availability, reliability, performance, service levels, data
integrity, data security, and ease of operations.
Decide with the user the requirements that apply to the specific service. Be sure to
define the requirements with sufficient detail for someone else to understand.
Step 3—Establish Measurements for the Service
Once you and the user have agreed upon the requirements for a service you are
providing, you further refine the agreement by including measurements for each of the
requirements.
It is best to specify measurable requirements only. If you specify a requirement you
can’t measure, it will be difficult to determine whether you are fulfilling the
requirements. For example, an agreement that specifies that the users must be satisfied
with the system response time is difficult to fulfill, since it is difficult to measure user
satisfaction. A better agreement would specify a specific response-time goal as
measured by time. Some other examples include:
•
An availability requirement: response time to a device-down call will be under 10
minutes.
•
A reliability requirement: application release will not include any modules that have
not been through post-development QA.