Delivering Quality Infrastructure: Going Beyond Technology

1. Delivering Quality Infrastructure: Going Beyond Technology TNC 2007 Victor Reijs, HEAnet Ann Harding, HEAnet

2. 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

3. HEAnet approach – offer Service Level Agreements • Synchronise expectations and ability to deliver quality SYN Needs SYN + ACK Needs + Agreement NREN CLIENT SERVER CLIENT ACK Agreement

4. 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

5. 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

6. 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

7. HEAnet SLA Processes (3/3) Existing Performance Data Client Expectations Room for Improvement Clearly Understood Metrics Provider Contracts Tolerance for Non-compliance Factors Determining SLA Terms

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

15. 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

16. 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!

17. Thanks • HEAnet Strategy Implementation CS1 • HEAnet Network Operations Team • Terena TF-LCPM