Using Service Level Agreements | Performance and Fault Management: A Practical Guide to Effectively Managing Cisco Network Devices (Cisco Press Core Series)

Depending on your organization, service level agreements (SLAs) may be necessary. An SLA is an agreement between the network provider and the customer that guarantees a level of service and calls out damages if a service level is not met. For internal customers, damages may be in the form of losing a quarterly bonus for not meeting the SLA. The agreement can be between you and your Frame Relay service provider (where you are the customer) or between you and your company's accounting department (where you are the network provider). SLAs center around a set of policies and must be realistically achievable.

SLAs are business agreements that define a set of policies and business objectives that must be met and the consequences if they are not met. The SLA must translate into concrete data that is measurable and can be reported.

Traditionally, service levels were measured in terms of services being delivered: response time, availability, and mean time to repair. In today's distributed networks, however, service levels are really more like "technical performance levels" because the measurements are based on concrete variables available from the devices, such as interface utilization or ping response times. The advantage of measuring technical performance levels is that the data is more easily collected and reported. The disadvantage is that technical performance is more difficult to associate with business objectives.

In reality, measuring traditional service levels is difficult to do in today's distributed networks, and using technical performance measures is a good solution in place of doing nothing at all.

Part of the SLA is specifying the cost that will be required in order to make the network capable of delivering the requested level of service. Although this can become politically sticky, it tends to be a great method to have another part of the business validate and justify any network modifications you may put forward.

Using the Baseline to Define SLAs

When drafting SLAs between your IT group and other internal business units, the baseline plays an important role in drafting achievable SLAs. The baseline allows you to proactively measure and monitor the factors that contribute to the service level. That is, it allows you to set realistic service goals, which is an important consideration because there will be consequences for not meeting an agreement.

For instance, suppose that you specify a service level of response time less then 250ms across each of your remote office's WAN links. However, your baseline analysis reveals that the average response time is slightly higher than 250ms with peaks greater than 500. In this case, the original service level suggestion is unrealistic and should be revised.

Sometimes, an SLA can be measured with concrete data and reporting adherence is achievable. For example, response time can be measured using ICMP pings, and quantitative reports can demonstrate whether the response time service level was met.

Using Operational Concepts to Define SLAs

Whereas baseline data focuses narrowly on network performance, your network's operational concept is a document that broadly defines the network's role and goals in relation to the overall success of the organization. Both resources are important in defining SLAs.

Network management is a complex business operation that is an essential support function for the entire business organization. Thus, it is essential that the network demonstrate network management's importance to the organization, both tactically and strategically. Today, managing network environments requires a well-defined operational concept that includes detailed performance and capacity goals. This up-front definition of network performance and capacity goals helps you to address the problem of measuring the actual service levels that the network is delivering to the user's desktop.

The key requirement of the network management operational concept is that it will provide a business foundation upon which you can build precise definitions of the variables needed or the features desired in your network. It is, therefore, through the development of this document that you can enhance the overall effectiveness of your organization. Not going through the process of developing an operational concept for network management can lead to a lack of goals or to goals that are constantly shifting due to customer demands.

The focus of this document is to form the long-range operational planning activities for network management and operation. It will also provide guidance for the development of all subsequent definition documentation, such as service level agreements. Obviously, this initial set of definitions cannot focus too narrowly on managing specific network problems. Rather, it should focus on those issues that emphasize the network's importance to the overall organization and the network costs (such as monthly WAN service fees) that must be managed. Some of the objectives that can be included in an operational concept document are as follows:

Identify those characteristics essential to efficient use of the network infrastructure
Identify the services/applications that the network supports
Initiate end-to-end service management
Initiate performance-based metrics to improve overall service
Collect and distribute performance management information
Support strategic evaluation of the network with feedback from users

In other words, the network management operational concept should focus on the overall organizational goals and your philosophy to meet those goals. The document therefore consists of the higher-level definitions of the network's missions, mission objectives, system goals, organizational involvement, and overall operational philosophy.

As a network manager, you are often in the position of trying to unify the inconsistent performance expectations of your users. For instance, if the primary requirement for the network is the transfer of large files from one location to another, you will want to focus more on high throughput and less on the response times of interactive users.

One of the things that you must be careful of during the creation of the network management operational concept is not to limit your view of performance without careful thought. For instance, look at the load levels that are being used when testing a network. Often, the load is based on very small packets and the throughput on very large packets. Although either of these performance tests may produce a very positive picture, traffic load may not present a true picture of performance for your network (depending on your network). Your network's performance should be studied under as many workload conditions as possible, and the performance should be documented.

Finally, ensure that you are not making unrealistic expectations of your network performance. This usually comes from misunderstanding the details of networking protocols or of the applications. Often, if you are experiencing poor performance, the fault may not be in the network but rather in poor application design. The baseline analysis should help you isolate the cause.

The following six steps are used in developing and documenting the network management operational concept:

Step 1. Define the network management goals in general business terms.

Step 2. Identify appropriate variables needed to further refine the network management goals in technical terms.

Step 3. Define the variables in terms of data type.

Step 4. Define the types of statistical and data manipulation valid against the defined data types.

Step 5. Define a process for the performance evaluation lifecycle.

Step 6. Redefine the goals based on the metrics defined previously.