Delivering Quality Infrastructure: Going Beyond Technology TNC 2007 Victor Reijs, HEAnet Ann 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 CLIENT SERVER NREN Needs + 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