BA SLA Definitions 5.0.6-de -...

Basisdokument SLA-Definitionen Enterprise Customers

Swisscom (Schweiz) AG

© Swisscom (Schweiz) AG Enterprise Customers

Dok-ID: SLA-Definitionen Version: 5.0.6 Datum: 01.02.2018 2/14

SLA

- Def

init

ione

n

C

D

Inhaltsverzeichnis 1 Einführung................................................................................................................. 3 2 Definitionen ............................................................................................................... 3 2.1 SLA Varianten .............................................................................................................. 3 2.2 Generische Kriterien zur Definition der Servicequalität ............................................................. 4 2.3 Best Effort ................................................................................................................. 4 2.4 Zeitzonen .................................................................................................................. 5 2.5 Feiertagsregelung ......................................................................................................... 5 2.6 Suspend Time .............................................................................................................. 5 3 Standard Service Level Parameters (SSLP) .......................................................................... 5 3.1 SSLP Operation Time ..................................................................................................... 5 3.1.1 Definition .................................................................................................................. 5 3.1.2 Maintenance Windows .................................................................................................... 6 3.1.2.1 Provider Maintenance Windows der Swisscom Datacenter .......................................................... 6 3.1.2.2 Provider Maintenance Window der Netzwerke zwischen Standorten des Kunden und Swisscom .............. 7 3.1.2.3 Service-spezifische Provider Maintenance Windows ................................................................. 7 3.1.2.4 Kunden-Individuelle Maintenance Windows ........................................................................... 7 3.1.3 Emergency System Changes ............................................................................................. 8 3.2 SSLP Support Time ........................................................................................................ 8 3.2.1 Definition .................................................................................................................. 8 3.2.2 Einsätze ausserhalb Support Time ...................................................................................... 8 3.3 SSLP Availability........................................................................................................... 9 3.3.1 Definition .................................................................................................................. 9 3.4 SSLP Process .............................................................................................................. 10 3.4.1 Incident Management Prozess .......................................................................................... 10 3.4.2 Service Request Prozess................................................................................................. 11 3.4.3 Service Fulfillment Prozess ............................................................................................. 12 3.5 SSLP Performance ........................................................................................................ 12 3.6 SSLP Security ............................................................................................................. 12 3.7 SSLP Continuity ........................................................................................................... 13 4 Service Level und Mengen Reporting ............................................................................... 14 5 End-to-End Lösungen .................................................................................................. 14



SLA

- Def

init

ione

n

C

D

1 Einführung Im vorliegenden Dokument werden die SLA-Varianten und die verwendeten Standard Service Level Parameter für die Qualitätsdefinition der ICT Services von Swisscom (Schweiz) AG - nachfolgend Swisscom genannt - fixiert. Sie bilden die Basis für die Service Level in den Leistungsbeschreibungen und in den Verträgen, die Steuerung während der Leistungserbringung und den abschliessenden Leistungsnachweis (Service Level Reporting).

Die folgenden Standard Service Level Parameters (SSLP) sind die serviceneutralen, generischen Kriterien für die Definition der verschiedenen Key Performance Indicators (KPI):

Standard Service Level Parameters

3.1 - SSLP Operation Time 3.4 - SSLP Process 3.7 - SSLP Continuity

3.2 - SSLP Support Time 3.5 - SSLP Performance

3.3 - SSLP Availability 3.6 - SSLP Security

2 Definitionen 2.1 SLA Varianten

Je Service wird in der Leistungsbeschreibung festgelegt, welche Leistungen, KPIs und Zielwerte angeboten werden. Sie bilden die standardisierten Servicebausteine aus dem Swisscom Service Portfolio für die Zusammensetzung der individuellen Kundenlösung und für die Service Level Targets. Es ist sichergestellt, dass die einzelnen Services analog einem Baukastensystem zusammengesetzt werden können. Die Rahmenbedingungen bezüglich der Handhabung von Service Level Vereinbarungen und der damit definierten Leistungen werden in den Leistungsbeschreibungen und/oder im Vertrag festgehalten.

Je nach Wertschöpfungstiefe der Kundenlösung kommen verschiedene Arten von Service Level Agreements (SLA) zur Anwendung:

A) + B) Standard SLA je Service mit Zielwert gemäss Angebot in der Leistungsbeschreibung C) + D) Individuelle SLAs für Service Packages oder Business Services mit Zielwerten gemäss

Anforderungen

Die folgende Grafik zeigt mögliche Kombinationen von Services (SAIP, BSAIP).

SAIP Je Service wird in der Leistungsbeschreibung der Service Access Interface Point (SAIP) standardmässig definiert. Er legt fest, wo welche Leistungen mit welchem Service Level Target erbracht und im Service Level Report nachgewiesen werden.

C2-i

nter

nal:

Gra

fike

n“S

LA D

efin

ition

s”,

SLA-

Fram

ewor

k EN

T,

Ger

ald

Schi

ller,

ENT

-CO

O-O

RC-P

FA u

nd C

hiri

stia

nVo

rlet

, EN

T-CO

O-P

PX-O

EX

Service Gruppierung

Service A Service B

Kunde

ICT Leistungen für Business Prozess

Service X ServiceService Y

Service Gruppierung

BSAIP

BSAIP

Service Package

Service A Service B

Kunde

Service Gruppierung

C) Mehrere Services mit SLA auf Ebene Service Package

D) Mehrere Services mit SLA auf Ebene Business Service

Kunde

Service A

Kunde

Service A

SAIP

Service B

A) Einzelner Servicemit SLA

B) Mehrere Servicesmit SLA je Service

Indikativer Nachweis (Option)Service Level relevanter Nachweis

Business Service

Wer

tsch

öpfu

ngst

iefe



SLA

- Def

init

ione

n

C

D

BSAIP Für die Service Packages und Business Services werden gemäss individuellen Kundenanforderungen der Business Service Access Interface Point (BSAIP) definiert. Er legt fest, wo welche Leistungen mit welchen Zielwerten und welcher Business Impact Logik im Monitoring angewendet und im Service Level Reporting nachgewiesen wird. Der BSAIP wird in der Leistungsbeschreibung oder im Vertrag definiert. Ergänzende indikative Informationen auf unteren Ebenen sind optional in einem erweiterten Reporting Service erhältlich. Falls kein übergreifendes SLA vereinbart wird, erfolgt der Nachweis standardmässig auf dem einzelnen Service.

Die Qualitätsdefinitionen und die individuelle Business Impact Logik werden in einem Servicebaum abgebildet (Service Impact Modell) und die Werte auf den verschiedenen Ebenen vereinbart. Dabei kommen die Standard KPIs und je nach Bedürfnis weitere KPIs zum Einsatz.

Der Leistungsnachweis erfolgt monatlich im Standard Service Level Reporting und Mengen Reporting. Es werden SLA-relevante und indikative Reportinformationen unterschieden.

2.2 Generische Kriterien zur Definition der Servicequalität Für jeden Service werden in der Leistungsbeschreibung und für die individuellen Service Packages/Business Services im Vertrag die folgenden Punkte definiert:

§ die angebotenen KPIs und Zielwerte welche die unterschiedlichen qualitativen Anforderungen an einen SAIP/BSAIP darstellen;

§ die Messverfahren, welche zur Überprüfung der Einhaltung der Service Level Parameters dienen; § den Standard Service Level Report, welcher die periodische Auswertung der vereinbarten Service Levels

zum Nachweis der durch Swisscom erbrachten Leistungen belegt.

Die folgende Abbildung veranschaulicht ein SLA, welches Leistungsdefinitionen, Key Performance Indicators und Service Level Targets umfasst:

Diese Punkte bilden die Basis für das Leistungsversprechen und für den Nachweis der erbrachten Leistungsqualität im Service Level Reporting.

2.3 Best Effort Das bedeutet, dass sich Swisscom in angemessener und branchenüblicher Weise mit den ihr zur Verfügung stehenden Ressourcen um die Leistungserbringung bzw. Störungsbehebung bemüht, ohne jedoch eine Zusicherung abzugeben. Gewährleistungs-, Schadenersatz- und allfällige Konventionalstrafen-Ansprüche sind bei Best Effort ausgeschlossen. Der Kunde kann Störungen über den Standard Incident Prozess melden. Falls kein Service Level Target festgelegt ist, gilt die Qualitätsdefinition „Best Effort“.

Service Level Leistungen mit dem Zielwert „Best Effort“ werden nicht gemessen und demzufolge auch nicht in einem Service Level Report aufgeführt. Allfällige Ausnahmen sind in der jeweiligen Leistungsbeschreibung festgehalten.



SLA

- Def

init

ione

n

C

D

2.4 Zeitzonen Falls nicht ausdrücklich an entsprechender Stelle festgehalten oder vereinbart, beziehen sich die Zeitangaben auf die Schweizer Zeitzone.

2.5 Feiertagsregelung Nationale und allgemeine Feiertage in der Schweiz: 1. Januar, Auffahrt, 1. August, 25. Dezember. Je nach vereinbarten SAIP gelten ergänzend die gesetzlichen, kantonalen Feiertage. Individuelle Abweichungen, insbesondere für internationale Standorte, werden in den betreffenden Verträgen definiert.

2.6 Suspend Time Die „Suspend Time“ ist die Zeitperiode, während der die Störungsbehebung oder das Request Fulfillment ruht und welche nicht in die Service Level Berechnung einbezogen wird. Gründe dafür sind z.B.:

§ Serviceausfälle und Request Fulfillment ausserhalb der vereinbarten Support Time § Der Ausfall fällt in ein Provider Maintenance Window, in ein kundenspezifisches Maintenance Window

oder in einen angekündigten Serviceunterbruch. § Ursache einer Störung liegt in der Behebung eines externen System-Fehlers oder in einem Unterbruch

des Internet, dessen Behebung nicht in die Leistungsverpflichtung von Swisscom fällt. § Swisscom beweist, dass weder sie noch ihre Hilfspersonen ein Verschulden an der Störung trifft. § Bei einem Fehlalarm. Der Incident wird mit der Begründung „False Alert“ geschlossen. § Zeitspannen mit reduzierter Leistungsfähigkeit (latency / transmission delay, throughput packet loss),

wenn Messungen von Swisscom belegen, dass die vertraglich spezifizierten Werte erreicht worden sind. § Der Kunde oder durch ihn beigezogene Dritte verfügen über Berechtigungen, welche potenziell die SLA-

Einhaltung beeinträchtigen können (namentlich Root-/Admin-Rechte auf den von Swisscom betriebenen Systemen).

§ Der Kunde ist im Rahmen seiner Mitwirkungspflichten nicht verfügbar, um die Störungsbehebung durchzuführen, zu unterstützen oder abzuschliessen. Beispielsweise kann der Incident Management Prozess nicht eingehalten werden wegen fehlender Erreichbarkeit/Zutrittsmöglichkeit, kein Ansprechpartner oder Bestätigung des Kunden. Dies gilt insbesondere auch dann, wenn die Angaben zu den Kontaktpersonen des Kunden von diesem nicht aktualisiert worden sind.

§ Die Beistellpflichten des Kunden sind nicht erfüllt. § Während der Entstörung wird der Kunde als Verantwortlicher für den Fehler identifiziert, wie

beispielsweise bei: § Applikationen, Ausstattungen oder Einrichtungen, welche nicht zum vereinbarten Serviceumfang

gehören (dies gilt namentlich auch für vom Kunden beigestellte Betriebsmittel, wie z.B. im Falle von Fehlern in vom Kunden lizenzierter Software) oder Leistungen von Drittprovider, die nicht vertraglich von Swisscom beigezogen wurden.

§ Fehler vor Ort: z.B. Hausinstallation, kundenseitiges Netzwerk, Strom, Kälte, unsachgemässe Behandlung durch Kunden usw.

§ Abwesenheit des Kunden/User zu einem vereinbarten Termin. § Die Verschiebung des Termins seitens Kunde.

3 Standard Service Level Parameters (SSLP) 3.1 SSLP Operation Time

3.1.1 Definition Der Parameter „SSLP Operation Time“ ist die Zeitperiode, in der alle für die Leistungserbringung relevanten ICT Komponenten in Betrieb stehen, in der Regel sind dies 7 Tage x 24 Stunden, exkl. Maintenance Windows. Die Einhaltung der Operation Time wird nicht rapportiert.

SSLP Operation Time In Leistungsbeschreibung Bedeutung

Beispielwerte1 Mo-So 00:00-24:00 Montag – Sonntag, 00:00–24:00 Uhr inkl. Feiertage exkl. Maintenance Windows

1 Die konkreten Zielwerte werden je Service in der Leistungsbeschreibung definiert.



SLA

- Def

init

ione

n

C

D

3.1.2 Maintenance Windows „Maintenance Windows“ dienen zur Reservation von Zeiträumen für Wartungsaktivitäten seitens Swisscom. Es handelt sich dabei um Zeitabschnitte, welche nur bei konkretem Bedarf genutzt werden. Swisscom ist bestrebt, die notwendigen Serviceunterbrüche so kurz wie möglich zu halten.

Swisscom unterscheidet zwischen:

§ Provider Maintenance Windows der Swisscom Datacenter § Provider Maintenance Windows der Netzwerke zwischen Standorten des Kunden und Swisscom § Service-spezifische Provider Maintenance Windows § Kunden-Individuelle Maintenance Windows

Bemerkungen:

§ Auf Kundenseite sollten während diesen Zeiten keine Wartungsarbeiten geplant werden. § Während der Wartungsfenster werden grundsätzlich keine Incident Tickets geführt. § Am Schluss der Wartungsarbeiten werden die Funktionalitäten derjenigen Services durch Swisscom

getestet/geprüft, welche in ihrer Verantwortung liegen. Die übrigen Leistungen – ausserhalb der Verantwortung von Swisscom - müssen durch den Kunden getestet werden.

3.1.2.1 Provider Maintenance Windows der Swisscom Datacenter Die „Provider Maintenance Windows“ der Swisscom Datacenter (PMW-DC) dienen zur Reservation von Zeiträumen für Wartungsaktivitäten in den Räumlichkeiten von Swisscom.

In einem Datacenter sind die folgenden drei Arten von Provider Maintenance Windows (PMW) möglich:

PMWs der Swisscom Datacenter (PMW-DC)

Typ Beschreibung Reserviertes Zeitfenster Service-Unterbrüche

General Für Wartungsarbeiten an der DC-Infrastruktur2.

Pro Jahr - 8 Wochenende jeweils Sa 18:00 – So 18:00 Uhr

In der Regel keine/kurze Serviceunterbrüche.

Connectivity Für Wartungsarbeiten am Netzwerk innerhalb der Swisscom-Datacenter.

Pro Jahr - 4 Wochenende mit je 3 Nächten: Fr 22:00 – Sa 06:00 Uhr und Sa 22:00 – So 07:00 Uhr und So 22:00 – Mo 06:00 Uhr

In der Regel <1 Stunde

Backup Für Wartungsarbeiten an der Backup-Infrastruktur.

Wöchentlich Mi 14:00-17:00 Uhr

In der Regel kein Serviceunterbruch3

Diese Wartungsfenster gelten für alle Leistungen, welche innerhalb der Swisscom Datacenter produziert werden und ergänzen die servicespezifischen Wartungsfenster, sofern in der Leistungsbeschreibung oder im Vertrag nicht anders festgehalten.

Der Prozess für die Planung von PMW-DC General und Connectivity verläuft wie folgt: In der Planungsphase wird der Kunde von Swisscom über die PMW-DC Planung informiert und die Termine bis 31. Oktober des Vorjahres in der PMW-DC- und Release-Jahresplanung festgelegt:

2 Gebäude, Heizung-Lüftung-Klima, Stromversorgung usw. 3 Service-Unterbrüche entstehen beispielsweise im Fall eines notwendigen Restores während des PMW-DC-Backup



SLA

- Def

init

ione

n

C

D

Vor jedem Wartungsfenster erfolgt eine Detailplanung, in der die bevorstehenden Wartungsarbeiten, die konkreten Serviceunterbrüche und die geplante Dauer definiert und mit dem Kunden abgestimmt werden. Der Kunde hat dann 28 Kalendertage Zeit, um den System Change von seiner Seite her freizugeben. Im nächsten Change Advisory Board (CAB) wird der System Change definitiv freigegeben.

Für das PMW-DC Backup Wartungsfenster ist keine Abstimmung mit dem Kunden vorgesehen, da kein Einfluss auf die Serviceleistung besteht.

3.1.2.2 Provider Maintenance Window der Netzwerke zwischen Standorten des Kunden und Swisscom Das Provider Maintenance Window der Netzwerke zwischen Standorten des Kunden und Swisscom (PMW-NWK) ist derjenige Zeitbereich, welcher grundsätzlich von Swisscom für Wartungsarbeiten an der Netzwerkplattform ausserhalb der Datacenter verwendet wird.

PMW der Netzwerke zwischen Standorten des Kunden und Swisscom (PMW-NWK)

Connectivity Für Wartungsarbeiten an Swisscom Netzwerken ausserhalb der Datacenter.

Wöchentlich So 02:00–06:00 Uhr

Die Konnektivität kann, muss aber nicht zwingend, während solcher Wartungsarbeiten beeinflusst sein. Innerhalb des Wartungsfensters geplante Unterbrüche, die voraussichtlich länger sein werden als die in der jeweiligen Leistungsbeschreibung spezifizierten Zeiten und alle ausserordentlichen Wartungsfenster werden den Kunden vorgängig mitgeteilt. Wird dies nicht spezifiziert, dann erfolgt keine besondere Kommunikation von Wartungsarbeiten an den Kunden.

3.1.2.3 Service-spezifische Provider Maintenance Windows Das Provider Maintenance Window der einzelnen Services (PMW-S) dient der Wartung der servicespezifischen Infrastruktur. Sie ist in den Leistungsbeschreibungen festgehalten.

Service-spezifische Wartungsfenster (PMW-S)

Service Plattform

Für Wartungsarbeiten an den Swisscom Plattformen, welche zur Erbringung der Service-Leistungen eingesetzt werden.

Ist in der Leistungsbeschreibung des jeweiligen Service spezifiziert.

Wenn nicht in der Leistungsbeschreibung anders festgehalten, erfolgt keine Abstimmung mit dem Kunden.

3.1.2.4 Kunden-Individuelle Maintenance Windows Kundenindividuelle Maintenance Windows (IMW) für kundenspezifische ICT-Infrastrukturen und Applikationen werden gegenseitig abgestimmt und vereinbart.

Kunden-Individuelle Maintenance Windows (IMW)

Individual Für Wartungsarbeiten an Kunden-spezifischen ICT-Infrastrukturen und Applikationen an Kundenstandorten.

Nach Vereinbarung

Wenn nicht in einem entsprechenden Swisscom-Service enthalten, werden diese auf Projektbasis unter Berücksichtigung des zusätzlichen Aufwandes spezifiziert, vereinbart und in Rechnung gestellt.

- 10.08.20xx - 2 KT

Umsetzung PMW-Abschluss

Serviceunterbruch (Std.-bereich)

Wartungsarbeiten Tests

Alle Provider Services stehenwieder bereit.

Bereit zum Stoppen der Provider Services =

kundenseitige Services sind gestoppt.

CABVeröffentlichung DraftPMW-DC- & Release-Jahresplanung

... ...Std.

Veröffentlichungdefinitive

PMW-DC- & Release-

Jahresplanung

Vernehmlassung, Verhandlung + Konsolidierung

31.10.20xx

Planungsphase für nächstes Jahr PMW-Detailplanung

Freeze

-1 KT- 5 KTX - 28 KT

Kundewirdinfor-miert

X

(KT = Kalendertage)

1. Kunde gibt Change frei

2. Der Name der Person auf Kundenseite ist bekannt, welche die Tests durchführt.



SLA

- Def

init

ione

n

C

D

3.1.3 Emergency System Changes Im Betrieb ergeben sich in der Praxis - zusätzlich zu den PMW - für alle ICT-Komponenten kurzfristige Bedürfnisse für Emergency System Changes. Swisscom behält sich das Recht vor, ausserplanmässig dringende Emergency System Changes z.B. Security Patches sofort durchzuführen.

Die Kunden werden - soweit möglich - kurzfristig vor der Ausführung des Change Request informiert. Der Kunde hat für seine dedizierten Systeme ein Veto-Recht4 und kann einen alternativen Termin für das Einspielen definieren. Sollte der Kunde ein Veto einlegen, trägt der Kunde alle damit zusammenhängenden Risiken selbst. Nach der Durchführung eines Emergency System Changes erfolgt eine Abschlussmeldung an den Kunden.

3.2 SSLP Support Time 3.2.1 Definition

Der Parameter „SSLP Support Time“ definiert die Zeitperiode (von – bis), während der

§ bei einer Störung qualifiziertes Personal für Interventionen zur Wiederherstellung von Services bereitsteht und daran arbeitet; d.h. während dieser Zeit werden die vertraglich vereinbarten Service Level Zielwerte (Qualität) sichergestellt;

§ im Service Level Reporting die Service Level relevanten Abweichungen ausgewertet und nachgewiesen werden.

Während dieser Zeit werden ausserdem

§ Prozess- und andere personenbezogene Dienstleistungen erbracht (z.B. bei Anwendung im Rahmen von Professional Services, Consulting usw.)

Der Zeitraum ausserhalb der Support Time gilt immer als Suspend Time.

Für den Parameter „SSLP Support Time“ stehen je nach Service und Angebotsmodell verschiedene Profile bereit.

SSLP Support Time In Leistungsbeschreibung Bedeutung

Beispielwerte1 Mo-Fr 07:00-18:00 Montag bis Freitag von 07:00 bis 18:00 Uhr

Mo-Fr 06:00-22:00 Sa 08:00-12:00

Montag bis Freitag von 06:00 bis 22:00 Uhr und Samstag von 08:00 bis 12:00 Uhr

Mo-So 00:00-24:00 Montag bis Sonntag von 00:00 bis 24:00 Uhr

Feiertage sind von der Support Time generell ausgeschlossen, ausser bei „Mo-So 00:00-24:00“, welche alle Feiertage mit abdeckt. Abweichungen von dieser Regel werden in der entsprechenden Leistungsbeschreibung festgehalten.

In einem Business Service muss die Support Time aller betroffenen Services den gleichen oder einen höheren Wert gemäss Anforderungen haben.

3.2.2 Einsätze ausserhalb Support Time Falls durch den Kunden ein temporärer Einsatz ausserhalb der Support Time gewünscht wird, ist dies vertraglich getrennt zu regeln. Die Unterstützung während der temporär angeordneten Einsätze unterliegt nicht den Bestimmungen zur Messung der Service Level.

4 Bei Systemen, die durch mehrere Kunden gemeinsam genutzt werden, kann kein Vetorecht angeboten werden.



SLA

- Def

init

ione

n

C

D

3.3 SSLP Availability 3.3.1 Definition

Der Parameter „SSLP Availability“ bezeichnet die Verfügbarkeit des vertraglich vereinbarten Service am definierten SAIP (Service Access Interface Point) oder BSAIP (Business Service AIP). Im aktiven Service Level Management Prozess wird eine Störung einer Infrastruktur Komponente automatisch erkannt, protokolliert und je nach Support Time die Intervention gestartet. Im Incident Management Prozess wird die Zeit einer Störung zwischen „Start Time Stamp“ und „Service restored/wiederhergestellt (Time Stamp)“ erfasst und für den Nachweis „Einhaltung der vereinbarten Verfügbarkeit“ im Service Level Report bereitgestellt (s. nachfolgende Grafik). Workarounds gelten als temporäre Störungsbehebung; wenn der Kunde den Service nutzen kann, gilt er in dieser Zeit als verfügbar.

Die folgende Darstellung zeigt die Relation der verschiedenen Zeiten für den SSLP Availability:

a) KPI Service Downtime [h:m]

Der KPI Service Downtime ermittelt die Summe der Service Outage Time [h:m] während der Support Time, exkl. Suspend Time in einer Berichtsperiode. Für geschäftsnahe Services & Business Services wird üblicherweise die Service Downtime in h:m als KPI verwendet:

SSLP Availability KPI Service Downtime [h:m]

Formel Service Downtime in h:m = ∑ Service Outage Time - ∑ Suspend Time

Beispielwerte1 1 h

b) KPI Service Availability [%]

Bei infrastrukturorientierten Services wird üblicherweise die Verfügbarkeit als Service Availability in % ausgewiesen. Der KPI Service Availability rechnet die aufsummierte Service Downtime [h:m] um in %, in Bezug zur Operation Time während einer Berichtsperiode.

«Support Time» z.B. Mo-Fr 07:00-18:00

«Support Time» z.B. Mo-Fr 07:00-18:00 (Interventionen & Serviceversprechen)

07:00

«Operation Time» 7x24h (Systeme laufen, exkl. vereinbarte Wartungsfenster)

Daten für Service Level

Reportingerfasst !

Ticket schliessen

Infoan User:Servicewieder-

hergestellt

Event

Die für den Service Level Availabilityrelevante Service Downtime (netto)

«Suspend Time» z.B. (1) Zeit ausserhalb «Support Time» (2) Protokollierte Begründung z.B. Nicht-Erreichbarkeit oder

nicht erfüllte Mitwirkungspflicht auf Kundenseite usw.(3) Angekündigte Provider Maintenance Windows

07:00 18:00

Service Downtime SuspendTime

18:00

Service Downtime

SuspendTime

Service Downtime

Kunden-Info +Nachbearbeitung

Service Outage Time

IncidentPending

ServiceLevelbased

Start TimeStamp =TØ

Service restored/

wieder-hergestellt

(Time Stamp)



SLA

- Def

init

ione

n

C

D

SSLP Availability KPI Service Availability [%]

Formel Service Availability in % = Operation Time - (∑ Service Outage Time - ∑ Suspend Time)

Operation Time×100 5

Beispielwerte1 99.5%

c) KPI Service Outages [#]

Der KPI Service Outages definiert die maximal erlaubten, Service Level relevanten Ausfälle pro Berichtsperiode:

SSLP Availability KPI Service Outages [#]

Formel Service Outages = Anzahl Service Level-relevanter Ausfälle

Beispielwerte1 1

3.4 SSLP Process Der Parameter „SSLP Process“ definiert Standard-KPIs, um Prozessleistungen (z.B. ITIL, Geschäftsprozesse) üblicherweise im reaktiven Service Level Management Umfeld zu messen, zu steuern und zu reporten.

3.4.1 Incident Management Prozess Im Incident Management Prozess werden Störungsmeldungen des Kunden als Incident registriert und ausgewertet.

Die folgende Darstellung zeigt das Verhältnis der verschiedenen Zeiten für den Incident Management Prozess:

Die Berechnung der Einhaltung der Service Level je Incident erfolgt aufgrund der Auswertung der Incident Tickets (exkl. Suspend Time) der einzelnen Störungen und wird je Kalendermonat ausgewiesen:

5 Bei der Operation Time werden in der Berechnung die Anzahl Tage je Mt. (28, 29, 30, 31) unterschieden.



SLA

- Def

init

ione

n

C

D

a) KPI Incident Intervention Time [h:m, BD]

Der KPI Incident Intervention Time definiert die Zeitdauer je Incident zwischen Time Stamp “create Ticket” bis “Work in Progress”, exkl. Suspend Time:

SSLP Process – Incident Management Process KPI Incident Intervention Time [h:m, BD]

Formel Intervention Time [h:m, BD] je Incident =

Time Stamp “Work in Progress” - Time Stamp “Create Ticket” - ∑ Suspend Time(s)

Beispielwerte1 4 h, EONBD / EO3BD6

b) KPI Incident Intervention Time On Site [h:m, BD]

Der KPI Incident Intervention Time On Site definiert die Zeitdauer je Incident zwischen Time Stamp “create Ticket” bis “Arrived at Site”, exkl. Suspend Time:

SSLP Process – Incident Management Process KPI Incident Intervention Time On Site [h:m, BD]

Formel Intervention Time On Site [h:m, BD] je Incident =

Time Stamp “Arrived at Site” - Time Stamp “Create Ticket” - ∑ Suspend Time(s)


c) KPI Incident Time to Resolve [h:m, BD]

Der KPI Incident Time to Resolve Ticket definiert je Incident die Zeitdauer, die zur Service Wiederherstellung gebraucht wurde, exkl. Suspend Time:

SSLP Process – Incident Management Process KPI Incident Intervention Time To Resolve [h:m, BD]

Formel Time to Resolve [h:m, BD] je Incident = Incident Total Duration - ∑ Suspend Time(s)


3.4.2 Service Request Prozess Service Requests werden von Mo-Fr 08:00-17:00 Uhr ausgeführt. Ausnahmen sind in der jeweiligen Leistungsbeschreibung aufgeführt.

Für den Service Request Prozess sind die folgenden KPIs definiert.

a) KPI IMACD Confirmation Time [h:m]

Der KPI IMACD Confirmation Time definiert die Zeitdauer bis zur Bestätigung für einen IMACD-Service Request.

SSLP Process – Service Request Process KPI IMACD Confirmation Time [h:m]

Formel IMACD Confirmation Time [h:m] =

Time Stamp “Request Confirmed” - Time Stamp “Request Created” - ∑ Suspend Time(s)

Beispielwerte1 0:30 h, 1 h

6 EONBD = End Of Next Business Day; EOxBD = End of x Business Days unter Berücksichtigung der Support Time



SLA

- Def

init

ione

n

C

D

b) KPI IMACD Fulfillment Time [h:m, BD]

Der KPI IMACD Fulfillment Time definiert die Zeitdauer bis zur Ausführung eines IMACD-Service Requests:

SSLP Process – Service Request Process KPI IMACD Fulfillment Time [h:m, BD]

Formel IMACD Fulfillment Time [h:m, BD] =

Time Stamp “Request Completed” - Time Stamp “Request Created” - ∑ Suspend Time(s)

Beispielwerte1 6 h, EO2BD6

3.4.3 Service Fulfillment Prozess

c) KPI Ready for Service (RFS) [Date]

Der KPI Ready for Service definiert den vereinbarten Bereitstellungstermin:

SSLP Process – Service Fulfillment Process KPI Ready for Service (RFS) [Date]

Beispielwerte1 01.02.2018

Ready for Service definiert das von Swisscom bestätigte Datum, an dem eine vertraglich vereinbarte Leistung betriebsbereit sein wird. Das genaue Datum kann vertraglich vereinbart werden.

3.5 SSLP Performance Der Parameter „SSLP Performance“ gibt Auskunft über den Status der Auslastung, den Durchsatz, die Messungen und Antwortzeiten von Referenztransaktionen und die Mengen (Aktivitäten, Transaktionen). Für solche Performance-Messungen werden je nach Bedarf im Rechenzentrum von Swisscom oder/und auf Kun-denseite ergänzende Techniken wie Probes, Agenten, Recorder und/oder Roboter sowie Monitoring Systeme eingesetzt.

Die Vereinbarung der Messkriterien, des Messverfahrens, der Aufbereitung des Reports und die Konditionen werden in der Leistungsbeschreibung oder im Vertrag individuell geregelt.

3.6 SSLP Security Der Parameter „SSLP Security“ umfasst mehrere Schutzstufen, welche den unterschiedlichen ICT Sicherheitsbedürfnissen Rechnung tragen. Die definierten Schutzstufen beschreiben Sicherheitsmassnahmen zur Umsetzung der folgenden Schutzziele: Vertraulichkeit (Confidentiality), Integrität (Integrity), Verbindlichkeit (Obligation) und Verfügbarkeit (Availability).

Die folgende Darstellung stellt die Anforderungen an Schutzbedürfnisse mit den IT Security Levels gegenüber:

IT Security Levels

IT

IT

• Elementare Security Bedürfnisse

• Ergänzende Security Bedürfnisse(Lösung aus Service Porfolio)

• Individuelle Security Bedürfnisse(Lösung ausserhalb Service Portfolio)

Anforderungen:

Security LevelBasic (ITSLB)

Security Level Advanced (ITSLA)

IT Security LevelCustomized (ITSLC)



SLA

- Def

init

ione

n

C

D

3.7 SSLP Continuity Der Parameter „SSLP Continuity“ definiert nach dem Übergang vom Incident Management ins Continuity Management, wie lange maximal die Wiederherstellungszeit dauert und wie gross der maximale Datenverlust ist.

Die folgende Darstellung stellt die verschiedenen Zielwerte im Kontext des Continuity Managements dar:

Der Übergang vom Incident Management zum Continuity Management ist ein Business-Entscheid (im Weiteren als «Krisenfall» bezeichnet). Diese Entscheidung kann sowohl vom Kunden wie auch von Swisscom abhängig von der Kritikalität der Situation getroffen werden.

Die folgenden Voraussetzungen müssen für den Übergang ins Continuity Management gegeben sein:

1. Swisscom kann die Serviceleistung nicht mehr erbringen (auch nicht mit einem Workaround) und 2. die vereinbarten Service Level sind verletzt worden (und die Verantwortung liegt bei Swisscom) und 3. es ist keine Lösung der Störung absehbar

Swisscom unterscheidet zwischen den folgenden drei Arten von Continuity, welche je nach Service angeboten werden können (siehe jeweilige Leistungsbeschreibung):

§ ICT Service Continuity (ICTSC) ICTSC umfasst ergänzende Funktionen z.B. zusätzliche HW-/SW-/Geo-Redundanz und/oder prozessuale Massnahmen zu einem bestimmten Service. ICTSC hat zum Ziel, im Krisenfall die Wiederherstellung eines Service innert vereinbarten Zeiten (KPI RPO/RTO) sicherzustellen.

§ ICT Business Continuity (ICTBC) ICTBC stellt gemäss definierten Kundenanforderungen die Beratung, die Planung, das Testen und im Krisenfall die Wiederherstellung der involvierten ICT Services zu Gunsten der Geschäftsfähigkeiten auf Kundenseite gemäss vereinbarten Wiederherstellungszeiten (KPI RPO/RTO) sicher. ICT Business Continuity wird durch ein Value Added Service von Swisscom erbracht.

§ Customer Business Continuity (BC) Aus Sicht des Kunden hält BC alle Massnahmen fest, die notwendig sind, um den Geschäftsbetrieb umgehend nach einem Krisenfall sicherzustellen. BC beinhaltet alle organisatorischen, personellen und technischen Schritte. Die Massnahmen helfen Kerngeschäfte nach Eintritt des Notfalls schnellstmöglich weiterzuführen, um den Schaden zu minimieren. Die Verantwortung des kundenseitigen Business Continuity Management liegt beim Kunden. Swisscom kann diesen Prozess mit individualisierten separat vereinbarten ICT-Lösungen unterstützen, welche mit geeigneten ICTBC und/oder ICTSC Konfigurationen die BC-Anforderungen des Kunden erfüllen.

Zur Spezifikation des Qualitätsversprechens von Continuity werden die folgenden KPIs eingesetzt:

tStörung

LetzteDaten-

Sicherung

RTO(max. Wiederherstel-lungszeit der letzten

Datensicherung)

Übergang zu Continuity

Management

RPO(max.

Datenverlust)

Wiederherstellungs-Zeitpunkt

Normaler Betrieb

Niedrige Bedeutung

Mittlere Bedeutung

HoheBedeutung

ICT Krise Desaster Katastrophe

Incident Management(Fokus SLA Availability)

Continuity Management(Fokus „Recovery Time“)



SLA

- Def

init

ione

n

C

D

§ RTO (Recovery Time Objective) bestimmt die vereinbarte maximale Zeitspanne für die Wiederherstellung eines dem Kunden gelieferten Service nach dem Übergang ins Continuity Management. RTO wird in maximal Anzahl Stunden ab dem Zeitpunkt nach dem Übergang ins Continuity Management angegeben.

§ RPO (Recovery Point Objective) definiert den maximal in der Vergangenheit zurückliegende Zeitpunkt, auf den ein System nach dessen Wiederherstellung konsistent wieder aufgesetzt wird. Hierzu kommen je nach Anforderung Wiederherstellungsmechanismen wie Backup, Mirroring usw. zum Einsatz. RPO wird maximal Anzahl Stunden - ab dem Ereignis-Zeitpunkt zurückgerechnet - angegeben.

SSLP Continuity KPI RTO [h] KPI RPO [h]

Formel RTO [h:m, BD] = Time Stamp “Wiederherstellungs-Zeitpunkt des ICT Service” - Time Stamp “Übergang Continuity Management”

RPO [h:m, BD] = Time Stamp “Störung” - Time Stamp “Letzte Datensicherung”

Beispielwerte1 4 h; Near 0

ICT Business Continuity (ICTBC) wird in der Leistungsbeschreibung des entsprechenden Value Added Service von Swisscom spezifiziert.

Die Customer Business Continuity Anforderungen werden im entsprechenden Vertrag geregelt.

Für das Continuity Management gilt eine Support Time von Mo-So 00:00-24:00.

4 Service Level und Mengen Reporting Swisscom liefert für die Standard Services einen monatlichen Service Level und Mengen Report als Qualitäts- und Mengennachweis gemäss Definitionen in der Leistungsbeschreibung. Das Standard Reporting basiert auf einer Berichtsperiode von einem Kalendermonat und wird elektronisch zur Verfügung gestellt.

Individuelle Reporting-Bedürfnisse können - nach vorgängiger Machbarkeitsklärung der Kundenanforderungen - kostenpflichtig mit ergänzenden Value Added Services - auch mit anderen Berichtsperioden - bedient werden.

5 End-to-End Lösungen Damit Swisscom die Service Level Versprechen im Rahmen von End-to-End-Lösungen gewährleisten kann, müssen die nachstehend aufgeführten Bedingungen eingehalten werden:

§ Alle von einer End-to-End-Lösung erfassten Services müssen in der (alleinigen) vertraglichen Verantwortung von Swisscom stehen.

§ In einer End-to-End-Lösung (Service Package oder Business Service mit BSAIP) beeinflussen alle involvierten Services die E2E-Service Level. Deshalb müssen diese Services den gleichen oder einen höheren Service Level Wert gemäss Anforderungen an das E2E-SLA haben, z.B. Applikation und Server und Datenbank: Availability ≥ 99,3% oder Service Downtime ≤ 2h.

§ Ein E2E-SLA bedingt ein aktives Monitoring und Management des Business Services; dies kann mit ergänzenden Value Added Services beauftragt werden.

BA SLA Definitions 5.0.6-de -...

Documents

Transcript of BA SLA Definitions 5.0.6-de -...