N2: Web Hosting and Infrastructure Service Level Agreement (SLA) guidance

1. Purpose of the Web Hosting and SLA document

The Service Level Agreement (SLA) is an essential tool for making plain the levels of maintenance and support that a digital research project can expect and for what period. It is advisable that no project should be made live and public unless there is a paid SLA in place.

This document would typically be drafted by the RSE Project Manager though it will almost certainly require input from Engineers/Developers and System Managers.

It should be made clear from the outset of a project that the SLA is a mandatory requirement for a publicly accessible web resource. Research teams might have very little concept of the volume of maintenance work that is required to keep a web resource:

• secure
• functional
• updated
• hosted
• available

2. Completing the Web Hosting and SLA

2.1. OVERVIEW section

This section is an opportunity to recap the nature of the project and say something about its impact and value. It might include details on usage.

2.1.1. Web Hosting Service Description

This section is used to determine the levels of service that the commissioning team can expect. One of the most complex judgements for this document is the length of the SLA that can be realistically offered. This can be complicated by Long Term Support (LTS) available for the software and frameworks that are used in the project. Converting a project to work with a new version of software may add considerable time to the maintenance work.

Example questions and prompts	Check
Where will the website be physically hosted?
What backup regime is in place?
How often will the servers be patched?
What is the procedure for renewing or reviewing this SLA?
Does any necessary upgrade of software cross major versions/releases of software?

See boilerplate text template for an example

2.1.2. Web Hosting

When calculating costs for an SLA the following factors should not be overlooked:

If using a virtual machine or cloud computing

• RAM cost
• CPU cost
• Disk space (for both storage and backup)
• Disk space forward planning (will the resource grow)

If using physical hardware

• Natural wear and tear
• Energy costs

Other considerations:

• Domain registration costs
• Software license purchase and renewal
• Operating system maintenance and upgrades (in person hours)
• Application maintenance (in person hours)
• Project administration
• Software breakages related to external factors such as browser changes or API changes

2.2. REVIEW

The RSE Engineers and RSE Systems Managers will have the best idea of the complexity of the software and its vulnerability to external factors. They will also have a good idea of any potential hazards on the horizon.