Publication Summary¶
| Title | Availability Management Policy |
|---|---|
| Author(s) | Alessandro Cardinali |
| Issued by | CEO |
Version doc. Review freq. |
0.1 Yearly |
| Date of issue | December 11, 2023 |
| Owner | Alessandro Cardinali |
| Document status | Draft – Final Draft - Final |
| Approval Date | n/a |
| Classification | Internal |
Change Log
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | December 11, 2023 | First draft document | |
| 1.0 | December 20, 2023 | ||
Contents
2 Availability management policy 9
2.1 Availability requirements and targets 9
2.2 Designing for availability 9
2.3 Availability monitoring and reporting 10
Introduction¶
Information processing facilities are increasingly critical to the services that Soon Technologies B.V. provides internally and to its customers, and we are constantly developing new and better ways to use IT to become more effective in our business processes. However, this increasing dependency means that when those IT systems are not available the impact to the business and its customers is very significant. Much work has already been done to make a major failure of IT systems less likely; risk assessments have been carried out which have resulted in a significant number of recommendations, many of which have now been carried out, with the remainder planned in the near future.
The purpose of this document is to set out how availability requirements will be gathered, targets set and how actual availability will be measured and reported. This will assist in identifying the correct level of redundancy that is appropriate for our IT infrastructure.
The following documents are relevant to this policy:
-
ICT Continuity Plan
-
ICT Continuity Exercising and Testing Schedule
Availability management policy¶
Availability requirements and targets¶
Requirements for the availability of information processing facilities will be established in conjunction with system owners and other interested parties and will consist of the following aspects:
-
Maximum time to restore service (in days/hours)
-
Access rights to the services (who will have access, at what times and from which locations)
-
Service response times (in seconds for interactive work and days/hours for batch-type work)
-
End-to-end availability of the services (percentage availability during stated hours)
These requirements will be documented, and targets set as input to business continuity planning activities.
Care will be taken to ensure that the targets agreed are measurable and if any additional tools are required in order to track performance against these targets, they will be subject to the approval of a business case. Where possible, an end-to-end definition of availability will be used i.e. from the user to the service, including all local and wide area networks and supporting hardware and software in between.
The requirements and targets will be reviewed at least annually as part of the management review cycle and any changes agreed and reflected within the documentation. As part of this review it will be decided to what extent targets should be amended each year to demonstrate continual improvement.
Designing for availability¶
For new services, availability requirements will be captured as input to the design stage and appropriate resilience will be built into new services to meet these requirements. Where appropriate, full use should be made of the availability features of cloud services, including the configuration of load balancers, elastic computing resources and availability zones.
Service acceptance testing will be carried out to ensure that these requirements can be met before the service becomes live. A full report will be produced from this testing stating to what extent targets were achieved and what actions need to be taken (if any) to meet availability requirements.
Availability monitoring and reporting¶
Procedures and tools will be put in place to record the actual availability of key services for which targets are specified. Where these are end-to-end measurements, the mechanism of calculating availability will be agreed with the customer of the service so that a common understanding of how figures are arrived at is reached.
[Service Provider] will also monitor the availability of key components that support the services provided so that data is available for analysis when investigating the causes of service outages.
Availability statistics will be published as part of the management reporting cycle and will refer back to the targets agreed. Where a target has not been met, some indication of the reason and actions that are to be taken will be given.
Non-availability¶
Planned¶
Where it is necessary for [Service Provider] to withdraw a service as part of planned activities, the length of notice will be agreed. This may be for scheduled maintenance or for the implementation of changes that have been approved as part of the change management process.
Planned unavailability will be communicated to all users via the intranet. Warning emails will also be sent out in the run up to the scheduled outage.
Unplanned¶
In the event of a service needing to be withdrawn as a result of an incident, [Service Provider] will make all reasonable endeavours to keep users informed of the status and likely restoration of the service.
The causes of unplanned non-availability will be investigated, and a report produced stating what will be done to prevent a reoccurrence. Any improvements identified will be managed through the change management process.
Availability plan testing¶
In conjunction with the business continuity testing schedule, availability plans will be tested on a regular basis and on major changes to services to ensure they remain effective. Reports will be produced from these activities and improvements identified.
Impact of changes¶
As part of the change management process, all change requests will be assessed for implications to availability plans and these plans will be amended appropriately as part of the change. This will ensure that availability plans do not become out of date as the IT environment develops.