Delivering Quality Infrastructure:

Going Beyond Technology

TNC 2007Victor Reijs, HEAnetAnn Harding, HEAnet

Background• NRENs deliver quality infrastructure

– A reasonable assumption but how do we prove it?

• NREN clients have to provide internal service level agreements to their users– How can NRENs help with this?

• Multidomain projects want known levels of service– Time to make commitments about quality

SYN

SYN + ACK

ACK

CL

IEN

T

CL

IEN

T

SE

RV

ER

NR

EN

Needs

Needs +

Agreement

Agreement

• HEAnet approach – offer Service Level Agreements

• Synchronise expectations and ability to deliver quality

HEAnet SLA Development• Aim:

– Identify an appropriate set of operational benchmarks and service metrics to measure our performance for clients.

– Benchmark against other NRENs– Benchmark operational performance on an ongoing basis

• Outputs:– Processes for management of SLAs– Templates– Improved network management tools– 2007 SLA figure recommendations

HEAnet SLA Processes (1/3)

• SLAs provided to HEAnet Clients – On initial provision of an SLA eligible service by

HEAnet– Annually, as part of the Client Service Agreement

Process– New services must be considered for SLA and

terms from the specification, dependent contracts and client expectations used

HEAnet SLA Processes (2/3)• SLAs reviewed and updated

– Existing SLA Terms must be reviewed based on performance and signed off in the quarter before the Client Service Agreements are to be issued

– SLA scope and terms may be reviewed given a significant change in the way a service is provided

– Appropriate actions for non-compliance are included in the terms

HEAnet SLA Processes (3/3)

Factors Determining SLA Terms

Client Expectations

Provider Contracts

Tolerance for Non-compliance

Room for Improvement

Clearly Understood

Metrics

Existing Performance

Data

SLA Processes Lessons Learned

• Keep it simple and manageable– Minimise work for administration– Integrate into existing processes– Use existing Client Service Agreement roles and

contacts

• Factors for deciding on terms vary– Most influential are not always technical

• All future services to be ‘SLA aware’– Designed with a Service Level Specification

HEAnet SLA Templates

• SLA to client – Document format to issue SLA figures to clients

• SLA service terms– Document format to design & update SLAs

annually

• RFO report – Document format to issue RFO reports to clients in

event of non-compliance

HEAnet SLA Format (1/2)• Service description

– This describes in formal terms the service the SLA is being offered on and how this is defined

• Indicators– Conditions determining success or failure of the objective,

expressed as concisely as possible• Limitations

– There may be limitations—for example, scheduled maintenance —that may affect the SLA. These limitations should be noted so that the expectation of the service is practical

• Problem Management – Provide the contact and escalation points for the service

HEAnet SLA Format (2/2)• Reporting

– What reports will be run to support the SLA, when, by whom, how will the reports be distributed, and what indicators will be measured?

• Reviews – Define the review period and the process for any formal

changes and reviews—for example, who must agree in order for a change to be made to the SLA

• Exclusions – Any variations to the general service that render it

inelligible for an SLA or particular part of SLA e.g. ISDN backup does not equate to service resilience

SLA Format Lessons Learned• Keep It Simple & Clear

– Easy for tech contacts to see at a glance– Ensure timely escalations

• Client or internally initiated

• Encourage takeup of quality services– Exclude poorer performing technologies– Demonstrate value of resilience

• Emphasis on improvement, not punishment!– Penalty based on work rather than cash refund is possible,

and in HEAnet’s case, preferable

Tools• Least problematic area

– Monitoring and measurement a long term NOC task

• Used existing installation of Nagios– Scales to three decimal places – Updated usage processes for maintenance

• Only one lesson learned– Technology to measure and implement was the

easiest part

SLA recommendations 2007• SLAs to be offered on new and existing services

• IP connectivity• Hosting• Point to point services• Support

• Decision based on• Client/community interest• Market competition• Demonstrating value/difference

• Lessons Learned• Getting user/client input was the biggest difficulty!• Feedback positive on existing service levels• Issue of SLAs seen as a routine expectation

Conclusions• Technology is the ‘easy’ bit

– Shared expectations is more important than scientific levels of measurement accuracy

– Services are good quality

• Values are NREN and service-specific– To whom is the NREN accountable for quality?– Quality expectations often lower than actual performance

• Better to take the initiative– Possibility of international co-operation– Your stakeholders may already be expecting this– Be active in more than technology!

Thanks

• HEAnet Strategy Implementation CS1

• HEAnet Network Operations Team

• Terena TF-LCPM