Contents Service Definition 3



Download 70.74 Kb.
Date09.01.2017
Size70.74 Kb.
#8278


scc-bid-template-cover-v22


SCC

LOT 2 – Platform PaaS

Secure Linux Platform (IL0)





Contents

Service Definition 3

An overview of the G-Cloud Service 4

Key Service Attributes 5

Information assurance 6

Details of the level of backup/restore and disaster recovery that will be provided 7

On-boarding and Off-boarding processes/scope. 8

Pricing (including unit prices, volume discounts (if any), data extraction) 11

Service management details 13

Service constraints 14

Service Roadmap 14

Service Levels (e.g. performance, availability, support hours, severity definitions) 17

Financial recompense model for not meeting service levels 20

Training 21

Ordering and invoicing process 22

Termination terms 23

Consumer responsibilities 24

Technical requirements (service dependencies and detailed technical interfaces, e.g. client side requirements, bandwidth/latency requirements) 25

Details of any trial service available. 26



Data Extraction 27


Service Definition


This is the minimum set of information that is expected in a service definition (suppliers may choose not to provide these aspects of a service, but do need to be clear in their service definition that they don’t).

An overview of the G-Cloud Service


This specific service shall deliver an IL0 platform service for Linux Managed Components, using a hardened, standardised Linux Operating System plus relevant management and security agents. The service shall include a guaranteed set of resources that can be defined at purchase; in addition the service shall provide both Burst and Elastic capabilities for CPU, Memory and Storage.

The platform shall deliver a capability for a customer to deploy OpenSource code or web applications built to operate under Apache or other platforms such as Ruby on Rails.

It shall be possible to add additional OpenSource components to this service such as MySQL Server for relational database functionality.

Depending upon the Impact Level required the service shall be connected to a number of networks, both internet and Government specific networks.

The service shall be backed up each evening and backup will be retained for 10 days.

The service shall be delivered from two UK data centres depending upon the availability SLA required.

Our service is built upon industry standard components and services and where Open Standards have been defined for a component they have been used.

Depending on options chosen some components shall be based upon Open Source Software. For example where Linux is the chosen service platform SCC shall provide a hardened Linux Operating System Build or deploy customers Linux build.




Key Service Attributes


Service Name

Secure Linux Platform (IL0)

Service Layer

PaaS

Cloud Deployment Model

Private

This service shall be delivered from an infrastructure platform that is private, in the context of it being available to the UK Government community only.



Networks to which the service is connected (directly)?

Internet, VPN or Point to Point


'API' access available, documented and supported?

No

API access to the service management tools shall not be available to The Customer or 3rd parties.



Services available to other suppliers so they can use them to provide services to government?

Yes

This service shall available to 3rd party suppliers such as ISVs in order for them to deliver platform or software services to government.



Data centre tier?

Tier 3+

The data centre conforms and exceeds the open uptime standards for a Tier 3 DC



Minimum Contract/Billing Period?

Month

The minimum commitment and minimum billing periods are both 1 Month.



Free option?

No

Trial Option?

No


Information assurance


Impact Level (IL) at which the G-Cloud Service is accredited to hold and process information

This service shall be delivered at Impact Level 0

The service shall be delivered from an un-accredited infrastructure and will not be connected to any of the Government Networks available.

It shall be the responsibility of the guest VM owner, SCC and the accreditor to ensure that code of connection compliance is adhered to.

SCC shall have the right to disable or remove services that can be proven to cause a security risk to the community as a whole.




Details of the level of backup/restore and disaster recovery that will be provided


The service shall be backed up to disk each day and backups will be retained for 10 days, this backup shall be limited to the Non-Persistent VMDK image of the VM and will not include additional Persistent storage that shall be connected to the service.

Recovery of a VM Image from backup shall be completed within 4 Hours from the point of request by The Customer through The Customer portal.

Where a customer has selected the 99.95% high availability service the VM Image shall be replicated in real time to the second data centre and compute resource shall be allocated in the eventuality that the primary site fails. Failover shall be initiated automatically by the virtualisation infrastructure.

Should higher levels of Backup be required they shall be added as an additional service from our Secure Backup Service and shall be defined during the initiation of that service.

Should Image Escrow be required by the customer it shall be available as an additional cost.



On-boarding and Off-boarding processes/scope.


On-boarding

The scope of this process covers the steps required to establish a new virtual machine within the SCC environment. The process caters for 3 integration scenarios:

Integration of an existing virtual machine from within The Customers estate

Integration of an existing physical machine from within The Customers estate

Creation of a new managed virtual machine within the SCC environment

In all cases initial discovery is required to determine the platform and resources that must be allocated from the environment to the managed server in order to define the setup activities and Charges associated with such.

This information established in discovery shall specify:

CPU Resources

Memory Resources

Network Interfaces

Non Persistent Disk Resources for core server (Persistent storage considered separately)

Setup activities and resources.

Existing servers shall need to be encapsulated within VMware virtual machine files (VMDK files) for incorporation into the platform.

Existing VMDK files can be provided by The Customer directly for incorporation into our platform.

Other virtual machine formats are to be converted to VMDK prior to presentation.

Physical servers must be migrated to VMDK format using an appropriate tool (e.g. VMware Converter)

For the latter two options SCC can provide a chargeable service to create the VMDK files.

Where data has been encapsulated within the VMDK file, the IL level must be assessed to ensure that an appropriate data transfer mechanism (i.e. encryption and security measures) is employed during the transfer of the virtual machine file to our environment. Transfer shall be achieved through providing the VMDK file on removable disk media (magnetic or optical) or transmission over a suitable network connection.

When new managed servers are to be created SCC shall deploy the server within the environment from a library of hardened approved server templates.

The resulting virtual machine shall then be validated for ensuring that it has been correctly integrated within the environment.

It should be noted that while the scope of this process caters for the virtual machine only the potential for invoking both storage and backup on-boarding processes exists in order that full integration can be achieved and that full compliancy can be achieved for The Customer off-boarding process. The storage and backup services have their own separate Service descriptions.

Off-boarding

The scope of this process covers the steps taken to remove a managed virtual machine from the SCC environment and return the virtual machine file to The Customer.



The virtual machine shall be assessed to determine if there is any data encapsulated within the virtual machine file and, if so, determine the IL applicable to the data. This will ensure that appropriate measures (security, encryption etc.) are applied when transferring the virtual machine file back to The Customer.

The virtual machine file, together with the associate virtual machine configuration file shall be supplied to The Customer using either removable disk or optical media (encrypted as appropriate)

The Customer shall be responsible for validating the integrity of the returned virtual machine file – note that this step refers to the confirmation that a valid VMDK file has been supplied – not that the virtual machine encapsulated within the file is correctly configured for any environment outside of SCC’s service provision.

Where a software license for the operating system or layered software within the VMDK file has been rented from SCC on our service provider license service the license key shall be removed prior to the return of the VMDK file.

SCC will then destroy all live and backup copies of the virtual machine file within our control and provide written confirmation to The Customer that this has been performed




Pricing (including unit prices, volume discounts (if any), data extraction)


The pricing for this service shall be based upon the units of compute, memory and storage consumed by the service with a variance made for the availability service level required:

1) On-boarding Charges

In all cases initial discovery is required to determine the platform and resources that must be allocated from the environment to the managed server in order to define the setup activities and Charges associated with such. Consequently these Charges shall be determined following completion of the discovery phase.



2) Baseline Service

The standard configuration for this Service will be:

CPU - Single Core 500mhz (2011 CPU type)

RAM - 4GB

DISK - 100GB

OS - Windows Server 2008 R2 or Red Hat Linux or Suse Linux

VM Type - VMware VMDK

CPU Burst - upto 2.5Ghz (single core, no reboot)

CPU Elasticity - upto 12 Cores (reboot(s) required)

RAM Elasticity – Up to 128Gb

DISK Elasticity – As required.

Managed Linux VM Costs- (within an IL0 Platform):



Service Component

Unit Cost Per Mth

Secure Virtual Managed Linux Machine (Single Site)

£242.00

Secure Virtual Managed Linux Machine (Failover Site)

£322.00

The availability options available shall be 99.9% (single DC) or 99.95% (failover to 2nd DC)

The service shall then be billed per unit per month in arrears with increments of 100mhz and 1Gb RAM bursting charged as an average across a month.

Data Extraction shall be charged dependent upon amount of data and media to be extracted to.

3) Service Options

In addition to the above standard configuration, the following service options can be procured by the Customer:



3a) Burst / Elasticity Charges

Virtual CPU Burst – up to double the capacity of the initially allocated CPU size, to the nearest full core.

CPU Elasticity – up to 12 Cores (reboot(s) required)

RAM Elasticity – Up to 128Gb

DISK Elasticity – As required

The service shall then be billed per unit per month in arrears with increments of 100mhz and 1Gb RAM bursting charged as an average across a month.



3b) Service Level Options

The availability options available shall be 99.9% (single DC) or 99.95% (failover to 2nd DC)



4) Off-Boarding Charges

Data Extraction for the extraction of the non-persistent VMDK file made available to download by the Customer. Should non-persistent or persistent data need to be extracted it shall be priced on a case by case basis and shall be charged dependent upon the amount of data and media to be extracted to.




Service management details


Connections

All data centre operations conform to ISO2001/2, ITIL and the Code of Conduct for Data Centre Operations. Additionally SCC maintains Code of Connection agreements with Government network services provider such as GCSX, Gsi and PSN



Self Service

The primary mechanism for service management shall be through The Customer portal where customers can self-serve basic functions for the service such as restarting virtual machines or powering down. In addition service status and billing reports shall be available in a pre-agreed format, should this be required.



SCC Service Desk

Where the Customer is unable to resolve the issue via the Customer Portal then SCC shall provide a telephone support capability for escalation directly as follows:



SCC Responsibilities

Within the Working Hours provide the SCC Service Desk as a point of contact within SCC for the Customer to log Incidents, receive Incidents via the Customer service desk, assign an individual reference number to each accepted Incident received and record, track and update accepted Incidents or Service Requests within the SCC incident management tool.



Customer Responsibilities

Report and provide the SCC Service Desk with all information it may reasonably require in order to resolve the Incident, ensure an Incident Owner or a nominated deputy is available during Working Hours. Provide the necessary resources to ensure that any changes to the Agreement are addressed and agreed with SCC via the Change Control Procedure in a timely manner.

Ensure all Users understand and comply with the various processes, policies and procedures of the Customer and as may be agreed between the parties from time to time.

Exclusions

The following are not provided as part of the SCC Service Desk and any materials and labour provided in these circumstances will be subject to agreement of the parties in writing and;



  1. Provided on a reasonable endeavours basis (i.e.outside of the Service Levels) unless agreed otherwise by SCC in writing, and

  2. Charged as Additional Ad-hoc Charges.

  3. Incidents and Service Requests received by the SCC Service Desk from the Customer service desk outside of Working Hours.

SCC will not be liable for failure to meet the SLA in the event 3rd Party Suppliers, other than those engaged by SCC fail to deliver services in accordance with their contractual commitments


Service constraints


The service shall be allocated a maintenance window between the hours of 22:00 and 06:00 the window shall be allocated during service initiation.

The service shall be change managed in accordance with SCC change schedules, change boards will sit bi-weekly and changes shall be carried out during the subsequent change window. A maximum of 4 changes during a month shall be included in the service.

Configuration changes that cause a reboot/downtime but are deemed urgent shall not impact SLAs and the associated charging mechanism.

The ability to add move or change the number of VMs in The Customer solution shall be achieved via the change request process and may be subject to appropriate financial approvals.

VMs shall be decommissioned via change control and images will be shut down but the images will be left in place for a further 24 hours after which point they will be destroyed.

All virtual backups will be destroyed and any physical backups will be returned to The Customer or destroyed.

Decommissioned machines shall be quarantined and can be restored to full operational state within 24 hours of being decommissioned.

Service Roadmap


For avoidance of doubt implementation of any of the planned Service improvements detailed herein will be subject to prior agreement by the Parties and may be subject to additional Charges.

The road map for this service shall follow two main paths;

The first being service improvement in terms of:

management

automation.

This can either drive down the cost, or improve the quality of service; including the security procedures, the service management and change request response times.

The second path is based on service functionality improvements or feature upgrades.

The Service improvements and upgrades that can be expected within this service are listed below but are not limited to this. The service is under constant review and development.



Service Improvement:

Real Time Management information - increase frequency and detail

Backup RTO - decrease time taken

Change request action - increase frequency available and reduce implementation time

Prune monitoring probes and feedback systems

Service Dashboards & reporting tools

Billing platform automation

Service Upgrade:

Support additional versions of Linux

Increase self-serve management functions

SSO Root IDM Authority for IL3





Service Levels (e.g. performance, availability, support hours, severity definitions)




The Services shall be provided by SCC in accordance with the following Service Levels;

Service Component

Service Level

Hours of Support

SLA Target

Secure Virtual Managed Linux Machine

Service Availability

24 Hours

99.9%

Secure Virtual Managed Linux Machine

Service Availability

24 Hours

99.95%

SCC shall determine the severity of an Incident in accordance with the following:

Severity Level

Description

Severity 1 (Critical)

The Service failure creates a serious business and financial exposure, causing a significant percentage of Users to be unable to work or perform an essential portion of their job, and there is no acceptable workaround to the problem (ie: the job cannot be performed in any other way).

Severity 2 (High)

The Service failure creates a significant business and financial exposure, causing a high (fixed) number of Users to be unable to work or perform some significant portion of their job, but there is an acceptable workaround to the problem in the short term (ie: the job can be performed in some other way).

Severity 3 (Medium)

The Service failure creates a low business and financial exposure to an isolated number of Users causing them to be unable to perform a portion of their job, but they are still able to complete most other tasks, or;

General Service related questions and requests for information.



Severity 4 (Low)

The Service failure creates a minimal business and financial exposure causing one or two User to be unable to perform a minor portion of their job, but they are still able to complete most other tasks.

There may be occasions where the Customer requires additional resource or focus to be applied to an Incident. In such circumstance the escalation procedure below shall apply;

Figure 1: Escalation levels within SCC.

UK Service General Manager

SCC Operations Manager

Service Delivery Manager

SCC Service Desk Team Leader

SCC DCS Operations Team Leader

SCC Service Desk Team

NOC Operations Team

Level 4

Level 3


Level 2

Level 1


The escalation activities and response timescales shall be as detailed in the table below. For avoidance of doubt the response timescales below are indicative only and do not supersede or replace the applicable Service Levels or SLA Targets specified in Clause 1 above.

Escalation Level

Response Activity

Escalation to Next Level Timescales

Level 1

The SCC Service Desk or NOC operations representative will acknowledge the Incident and advise on tests and actions required in order to resolve the Incident, consulting as necessary with other SCC representatives and/or 3rd parties. Should the SCC representative be unable to resolve the problem or provide an action plan suitable to the Customer, the Incident will be escalated to the respective team leader of either the NOC operations or Service Desk team.

Severity Level 1: 30 Minutes

Severity Level 2: 3 Working Hours

Severity Level 3: 6 Working Hours

Severity Level 4: Not Applicable



Level 2

The respective team leader will determine a suitable action plan and agree it with the Customer. The Service Delivery Manager will be notified. Third party manufacturers and/or suppliers may be contacted for additional technical support.

Severity Level 1: 1 Working Hour

Severity Level 2: 4 Working Hours

Severity Level 3: 8 Working Hours

Severity Level 4: Not Applicable



Level 3

If unresolved following Stage 2, the Incident will be escalated to the Service Delivery Manager who will involve all necessary resources, both internally and externally, to attempt to provide an acceptable resolution for the Customer. The SCC DCS’ Network Operations Manager will also be informed.

Severity Level 1: 2 Working Hours

Severity Level 2: 5 Working Hours

Severity Level 3: 9 Working Hours

Severity Level 4: Not Applicable



Level 4

If unresolved following Stage 3, then SCC DCS’ Network Operations Manager will take responsibility for the Incident and involve all necessary senior and management resources, both internally and externally, to ensure an acceptable resolution for the Customer. SCC DCS’ Professional Services Director will be appraised of the situation.

N/a





Financial recompense model for not meeting service levels


Service Credits

1.1 Subject to Clause 7.5 below, in the event that SCC fails to meet the SLA Target for any of the Service Components specified below during the period the Service Level report covers (“Report Period”), then the Service Credit mechanism in Clause 7.3 shall apply;

1.2 SCC shall provide a rebate of 1% of the affected Service Component Support Charge, which is applicable over the Report Period for every 1% below the SLA Target to a maximum of 10 % The applicable Service Credit shall be deducted off the next invoice due to the Customer.

1.3 Payment by SCC of Service Credits to the Customer shall be in full and final settlement of SCC’s liability to the Customer for failure to meet the Service Levels during the Report Period.




Training


There is no training associated with this service.


Ordering and invoicing process


SCC will provide ordering of G-Cloud services via their Lifecycle portal.

Customers will need to register all relevant details and will receive login details within 5 working days. This is a secure site and this mechanism will provide an account and password protected login.

A basket of G-Cloud services can be compiled, with quotations for those specific services. Once the Customer is satisfied that an order is complete it can then be converted into an order.

To place the order on SCC for delivery, against defined SLA’s, the Customer will click ‘checkout’ and complete the relevant details.

Once the services are enabled and confirmation of the ordered G-Cloud services is delivered to the Customer a monthly invoice in arrears will be generated against the order, via the registered Customer details on the Lifecycle portal.

Should the Customers usage of the Service increase beyond the contracted volumes during any period then this will be retrospectively invoiced, at the next month end, as additional services.




Termination terms

By consumers (i.e. consumption)

A G-Cloud service shall commence on the Effective Date and shall, unless specified otherwise in the Order Form, continue for the Initial Term and shall remain in force thereafter unless and until terminated by either Party giving to the other not less than 30 days written notice, but shall be subject to earlier termination as referenced within the Termination/Consequence of Termination section of the standard SCC G- Cloud terms and conditions.


By the Supplier (removal of the G-Cloud Service)

A G-Cloud service shall commence on the Effective Date and shall, unless specified otherwise in the Order Form, continue for the Initial Term and shall remain in force thereafter unless and until terminated by either Party giving to the other not less than 30 days written notice, but shall be subject to earlier termination as referenced within the Termination/Consequence of Termination section of the standard SCC G-Cloud terms and conditions.


Data restoration / service migration

Where data needs to be restored to the operational service from a backup, this shall be requested by the Customer through the Customer portal.

Recovery of a data from backup shall be completed within 4 Hours from the point of request by the Customer through the Customer portal.

Service migration shall be possible after completing the data extraction process at which point the data will be available in an appropriate format to migrate to an alternative service, should the Customer require assistance with this process SCC can provide migration service at additional cost.



Consumer responsibilities


The consumer responsibilities will be as follows:

Provide SCC with a VMDK Image and/or license keys and any other information reasonably required to enable the initial server build

In the event the Customer wishes to implement any operating systems software which is/ are not identified on the SCC supported operating system software list, then prior to such implementation the Customer must first agree such with SCC.

Procurement, maintenance and management of any Customer data communications lines not identified in the Order Form and/or Agreement.

Provision, maintenance and management as the case may be of any Customers software, operating systems, applications and data which resides on the SMTC Infrastructure.

Administration, management and control of Users access to the Customers applications and/or data stored on the SMTC Infrastructure.

Should SCC determine that the Customers usage of the SMTC Infrastructure is not compliant with best practice guidelines then the Customer must comply with SCC’s reasonable requests for change.

In the event the Customer requires the implementation of its own anti-virus software then this will be by mutual agreement with SCC. If SCC and the Customer agree to such implementation then the Customer shall ensure that anti-virus signatures are updated on a daily basis and anti-virus software upgrades, fixes, patches are installed as and when required, to minimise any degradation in the performance of the anti-virus




Technical requirements (service dependencies and detailed technical interfaces, e.g. client side requirements, bandwidth/latency requirements)


This service delivers a Virtual Machine (VM) shall include a hardened operating system built by SCC with all management and monitoring agents, backup agents and security agents or customer build that shall be reviewed and made compliant with SCC managed equivalent agents as part of bringing that build on to the SCC platform.

The build shall be fully managed by SCC and shall be subject to change through change control procedures. Customer software shall be loaded on to the machine in conjunction with SCC accredited and security cleared staff who shall responsible for all on-boarding activities associated with the delivery of a new service.

There shall be no direct access to the console of this VM by The Customer or 3rd Party.



Details of any trial service available.


There is no option to consume this service for a trial period.


Data Extraction


Suppliers will provide a “simple” and “quick” exit process to enable consumers to move to a different supplier for each of their G-Cloud Services and/or retrieve their data. Suppliers will commit to providing details of this, clearly and unambiguously in the Service Definition for each service. This will include, but not be limited to:

The data standards that will be in use (within the service).

This service shall deliver a single data standard and that is a VMDK Virtual Machine File.

A commitment to returning all consumer generated data (e.g. content, metadata, structure, configuration etc.) and a list of the data that will be available for extraction. Where there is a risk of confusion, data that will not be available for later extraction will also be published.


The return of customer VMDK files shall be performed with MD5 checksum in transit and shall rest on FIPS-140-2 compliant storage subsystem.

The formats/standards into which data will be able to be extracted and preferably a list other common services/technologies to which an export/import mechanism is available.


This service shall deliver a single data standard and that is a VMDK Virtual Machine File.

Import and Export of VMDK files shall be via an appropriate network to appropriate storage sub-system or via DVD media.

Import and Export of VMDK files directly to the platform from an customer laptops is possible where a customer is present at the data centre.


A price for the extraction of consumer generated data (or the migration to another service provider’s service).


Data Extraction shall be charged dependent upon amount of data and media to be extracted to.

Confirmation that the Supplier will purge and destroy (as defined in security accreditation for different ILs) consumer data from any computers, storage devices and storage media that are to be retained by the Supplier after the end of the subscription period and the subsequent extraction of consumer data (if requested by the consumer).


All data at rest contained within the SCC platform shall be purged or destroyed with standard service, volume, LUN deprecation procedures.

All data leaving the SCC platform shall be purged or destroyed using CESG approved white spacing prior to shipping.



Where a physical drive from a drive set fails then that drive shall be destroyed in accordance with CESG procedures.


scc-bid-template-cover-v22



Download 70.74 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page