Service Level Agreement noris network AG

Transkript

1 Service Level Agreement noris network AG Thomas-Mann-Straße Nürnberg Seite 1 von 11

2 Inhalt 1 Über dieses Dokument 3 2 Definitionen Incident Annahme Qualifizierung Verfügbarkeit Hardwareverfügbarkeit Softwareverfügbarkeit Verfügbarkeit von dedizierten Systemen Ausfallzeit Workaround 7 3 Service Level Verfügbarkeit der Infrastruktur Verfügbarkeit der Services Verfügbarkeitsklassen von individuell betriebenen Systemen Betriebszeit Administrationszeit Reaktionszeiten Wiederherstellungszeiten Wiederherstellungszeit von Services der Verfügbarkeitsklasse HR Wiederherstellungszeit von Services der Verfügbarkeitsklasse HA und FT Wartungsfenster Sicherheitsupdates und Patches Regelmäßige Sicherheitsupdates und Patches Außerplanmäßige Updates Service Requests 11 4 Verletzung der Service Level 11 5 Haftungsausschluss und Abgrenzung 11 6 Salvatorische Klausel 11 Seite 2 von 11

3 1 Über dieses Dokument Die noris network AG erbringt im Rahmen des jeweiligen Einzelauftrages verschiedene IT- Dienstleistungen gemäß der Auftragsbeschreibung und der AGB. Das Service Level Agreement der noris network AG enthält die transparente Definition der Mindeststandards für die Qualität der von noris network angebotenen Services (Produkte, Lösungen und Dienstleistungen). Zur eindeutigen Definition des Service Level Agreements werden im Folgenden die Verfügbarkeiten von Systemen und Infrastruktur, sowie die Zeiten für Betrieb, Administration, Reaktion und Wiederherstellung klar erläutert. Das Service Level Agreement ist zusammen mit der Auftragsbestätigung und den AGB wesentlicher Bestandteil des Vertrags zwischen dem Kunden und der noris network AG. Soweit nicht abweichend vereinbart, gilt für bestehende und zukünftige Vertragsverhältnisse zwischen der noris network AG und dem Kunden die zum Zeitpunkt des Abschlusses des Vertrags oder des Vertragsteils jeweils aktuelle Version dieser Vereinbarung. Alle relevanten Begriffe bezüglich Fehlerklassen, Verfügbarkeit und Ausfallzeiten etc. werden im Anschluss detailliert spezifiziert. Seite 3 von 11

4 2 Definitionen 2.1 Incident Ein Incident ist eine Störung oder eine Minderung der Qualität im Betrieb eines bereitgestellten Services. Jeder Incident wird im Rahmen des Incident Management Prozesses mit folgenden Schritten bearbeitet: Annahme, Qualifizierung, Bearbeitung Eskalation und Nachverfolgung Annahme Die Meldung eines Incidents kann entweder per oder telefonisch, sowohl durch den Kunden, als auch automatisiert durch das Monitoring erfolgen. Jeder Incident erhält dabei eine eindeutige Ticketnummer im Ticketsystem. Mit der Anlage des Tickets gilt der Incident als angenommen. Während der gesamten Dauer des Incidents bleibt dieses Ticket geöffnet um den Ablauf aller Maßnahmen darin zu dokumentieren Qualifizierung Im Rahmen der Qualifizierung werden die Kategorie und die Priorität einer Störung ermittelt. Die Kategorie ergibt sich aus den betroffenen Komponenten (z. B. Netzwerk, oder eine bestimmte Applikation). Anhand der Kategorie wird nach Lösungen für die Störung gesucht und ggf. die fachliche Eskalation durchgeführt. Die richtige Kategorie ist entscheidend für eine schnelle Fehlerbehebung. Die Einstufung der Priorität erfolgt nach der im Folgenden aufgezeigten Matrix: Priorität Dringlichkeit (Urgency) Auswirkung (Impact) 1* hoch hoch 2* hoch gering 3 gering hoch 4 gering gering * Für eine Vergabe der Priorität 1 oder 2 durch den Kunden muss die Meldung telefonisch erfolgen Seite 4 von 11

5 2.2 Verfügbarkeit Dem Kunden kann auf Wunsch ein Report mit einem maximalen Intervall von einem Monat über die Verfügbarkeit seines Services auf unten stehender Berechnungsbasis zur Verfügung gestellt werden. Die Erstellung der Reports erfolgt ab dem Folgemonat der Beantragung. Die einzelnen Berichte werden über das Jahr kumuliert. Verfügbarkeit in % = (Ausfallzeit *100 / Bezugszeit) Bei der Berechnung der prozentualen Systemverfügbarkeit wird nach kaufmännischen Grundsätzen auf eine Nachkommastelle gerundet. Die Bezugszeit ergibt sich aus dem Produkt (Tage des Betrachtungszeitraums * Betriebszeit) Die Betriebszeit beträgt dabei 24 Stunden. Der Betrachtungszeitraum ist alternativ ein Jahr oder ein Monat. Als Ausfallzeiten gelten die Ausfälle im Betrachtungszeitraum, jedoch nur außerhalb von Wartungsfenstern. Beispiel: Bezugszeit = 0-24 Uhr = 24 Stunden/Tag * 30 Tage/Monat im Monat Juni = 720 Stunden Bei einem Service Level-relevanten Ausfall innerhalb des Betrachtungszeitraumes von 2 Stunden (außerhalb Wartungsfenster) ergibt sich nach der oben genannten Formel Verfügbarkeit in % = (2 * 100 / 720) eine Verfügbarkeit von 99,7 %. Die vereinbarte Verfügbarkeit wird ab der Produktivsetzung des Systems berechnet (d. h. ab Übergabe in den Regelbetrieb) und bezieht sich alternativ auf den Kalendermonat oder auf das Kalenderjahr. In Rumpfmonaten bzw. -jahren zählt die Zeit vor bzw. nach dem Produktivbetrieb für die Berechnung der Verfügbarkeit zum Betrachtungszeitraum. Die Verfügbarkeit eines Services, der über Netzwerk zur Verfügung gestellt wird, wird am Router- Ausgang des Auftragnehmer-Rechenzentrums bzw. an den entsprechenden Netzwerkkomponenten gemessen Hardwareverfügbarkeit Bei einer Hardware handelt es sich um ein einzelnes Gerät, welches durch noris network als Service bereitgestellt wird. Die Hardware ist dann verfügbar, wenn unbeschadet kleiner Störungen das Betriebssystem und die Applikationen ohne Fehler der Klasse Priorität 1 und 2 ausgeführt werden können. Der Ausfall einzelner Komponenten kommt bei redundant ausgeführter Hardware zur Berechnung von Verfügbarkeiten dann in Betracht, wenn die wesentlichen Funktionen der Hardware nicht gegeben sind Softwareverfügbarkeit Bei einer Software handelt es sich um eine Applikation, die auf einer oder mehreren Hardware- Komponenten läuft und dem Kunden als Service bereitgestellt wird. Die Software ist dann verfügbar wenn unbeschadet kleiner Störungen die wesentlichen Funktionen ohne Fehler der Klasse Priorität 1 und 2 ausgeführt werden können. Der Ausfall einzelner Komponenten kommt bei redundant ausgeführter Software zur Berechnung von Verfügbarkeiten dann in Betracht, wenn die wesentlichen Funktionen der Software nicht ausgeführt werden können. Seite 5 von 11

6 2.2.3 Verfügbarkeit von dedizierten Systemen Ein dediziertes System besteht aus Komponenten mit unterschiedlicher Funktionalität, durch deren Zusammenwirken dem Kunden ein oder mehrere Services bereitgestellt werden. Systeme sind dann verfügbar wenn unbeschadet kleiner Störungen die wesentlichen Funktionen ohne Fehler der Klasse Priorität 1 und 2 ausgeführt werden können. Der Ausfall einzelner Komponenten kommt bei redundant ausgeführten Systemen zur Berechnung von Verfügbarkeiten dann in Betracht, wenn die wesentlichen Funktionen des Systems nicht ausgeführt werden können. 2.3 Ausfallzeit Bei der Berücksichtigung von Ausfallzeiten in der Verfügbarkeitsberechnung wird unterschieden zwischen Service-Level-relevanten und nicht-service-level-relevanten Ausfällen. Die Ausfallzeit ist der Zeitraum ab Beginn der Störungsmeldung bis zur Wiederherstellung aller wesentlichen Funktionen bzw. bis zur Bereitstellung eines Workaround. Die Beendigung der Ausfallzeit durch die Bereitstellung eines Workaround ist dann gewährleistet, wenn keine Störung der Fehlerklasse Priorität 1 oder 2 mehr vorliegt. Nicht-Servicelevel-relevante Ausfallzeiten sind: Ausfallzeiten aufgrund von höherer Gewalt (insbesondere Krieg, Streik, Naturkatastrophen), Sabotage und vergleichbarer, nicht vom Auftragnehmer zu vertretender Gründe Ausfallzeiten aufgrund von Viren- oder Hackerangriffen, Ausfallzeiten, die von der noris network AG nicht direkt zu vertreten sind, insbesondere Angriffe auf die Netz- bzw. Mailinfrastruktur der noris network AG (DDoS-Attacken/Viren), wenn der Auftragnehmer seinen vertraglichen Verpflichtungen zum Schutz der Systeme nachgekommen ist oder der Auftraggeber den Ausfall zu vertreten hat (z. B. unterbleibende Mitwirkungspflichten des Auftraggebers) Ausfallzeiten, die auf Ausfälle von Teilen des Internets sowie externe DNS, Routingprobleme die außerhalb der Kontrolle der noris network AG liegen, zurückzuführen sind Ausfallzeitverlängerungen, die aufgrund einer Blockierung des Konsole- bzw. Remote-Zugangs durch den Auftraggeber verursacht wurden Ausfallzeiten aufgrund von Vorgaben des Software-Herstellers oder der Qualität der beigestellten Software, sofern der Auftragnehmer seiner Sorgfaltspflicht nachweislich nachgekommen ist Ausfallzeiten aufgrund von Software-Fehlern in den Applikationen Ausfallzeiten aufgrund von geplanten Unterbrechungen für Wartungsarbeiten, die in den vereinbarten Wartungsfenstern liegen Der Ausfall eines der redundanten Systeme gilt nicht als Ausfallzeit, wenn dadurch die vereinbarte Gesamtverfügbarkeit der Systemlösung nicht verringert oder signifikant beeinträchtiget wird. Ausfallzeiten die durch ausbleibende Mitwirkungspflicht des Kunden oder vom Kunden beauftragter Dritter verursacht wurden. Ausfallzeiten aufgrund von Fehlbedienung seitens des Kunden Seite 6 von 11

7 Ausfallzeiten durch Verschulden des Kunden wegen fehlerhafter oder unzureichender Wartung der kundeneigenen Hard- oder Software. Ausfallzeiten, die auf unsachgemäße Benutzung oder Reparatur, oder nicht den Richtlinien des Herstellers oder der noris network AG entsprechenden Installation, Betrieb oder Pflege zurück zu führen sind. Ausfallzeiten aufgrund eines fehlerhaften Verhaltens einer dritten Komponente außerhalb des Wirkungsbereichs der noris network AG. Nicht-Servicelevel-relevante Ausfallzeiten im Rahmen der oben angegebenen Punkte gelten als verfügbare Zeiten. Die in diesem Dokument vereinbarten Wiederherstellungszeiten gelten nur für Servicelevel-relevante Ausfallzeiten. 2.4 Workaround Bereitstellung eines Workaround bedeutet die Wiederherstellung der Funktionalität der vereinbarten Leistungsmerkmale mittels einer adäquaten Umgehungslösung. Seite 7 von 11

8 3 Service Level 3.1 Verfügbarkeit der Infrastruktur Die Verfügbarkeit der Infrastruktur hängt von den drei maßgeblichen Faktoren Stromversorgung, Klimatisierung und Netzwerkanbindung ab. In diesem Zusammenhang gewährleistet die noris network AG folgende Mindestwerte: Stromversorgung 99,991 % p. a. Klimatisierung 99,991 % p. a. * Backbone 99,991 % p. a. * Die Verfügbarkeit der Klimatisierung gilt als gewährleistet, wenn sich die Umgebungsbedingungen hinsichtlich Temperatur und relativer Luftfeuchtigkeit der Zuluft in den Rechenzentren im Rahmen der in Class A1 for Enterprise Servers and Storage Products empfohlenen Werte, der 2011 Thermal Guidelines for Data Processing Environments des ASHRAE Technical Committee, befinden. 3.2 Verfügbarkeit der Services Gemäß dem hohen Qualitätsanspruch von noris network wird für alle Services eine Mindestverfügbarkeit gewährleistet. Dementsprechend sind alle Services den noris network Verfügbarkeitsklassen zugeteilt, welche sich an den Availability Environment Classification (AEC) Klassen der Harvard Research Group (HRG) orientieren. Die Zuordnung zu den Verfügbarkeitsklassen ist aus der Artikelnummer ersichtlich. Sollten Services abweichende Verfügbarkeiten aufweisen, wird dies explizit in der jeweiligen Leistungsbeschreibung angegeben. Abweichend von den unten angegebenen Standard-Verfügbarkeiten können andere Angaben individuell vereinbart werden. Verfügbarkeitsklassen für Services: Verfügbarkeitsklasse Verfügbarkeit Suffix der Artikelnummer Highly Reliable (HR) 99,5 % p. a. * High Availability (HA) 99,8 % p. a. -HA Fault Tolerant (FT) 99,9 % p. a. -FT * Services ohne Suffix am Ende der Artikelnummer werden der Verfügbarkeitsklasse HR zugeordnet 3.3 Verfügbarkeitsklassen von individuell betriebenen Systemen Bei individuell betriebenen Systemen handelt es sich um Setups, die aus einer oder mehreren Komponenten bestehen und deren Zusammenwirken zur Erbringung eines Services führt. Sofern nicht anders vereinbart, sind individuell betriebene Systeme mit nicht redundantem Aufbau der Verfügbarkeitsklasse Highly Reliable zugeordnet. Bei vollständig redundantem Aufbau wird das individuell betriebene System der Verfügbarkeitsklasse High Availability zugeordnet. Seite 8 von 11

9 3.4 Betriebszeit Die Betriebszeiten betragen 24 Stunden an 7 Tagen der Woche. Die Betriebszeiten gelten soweit an anderer Stelle nichts anderes angegeben für Hardware, Software, Backbone, Hosted Services und die gesamte Infrastruktur der Rechenzentren. 3.5 Administrationszeit Die Administrationszeiten sind montags bis freitags (außer an gesetzlichen Feiertagen, sowie jährlich dem und ) von 08:00 bis 18:00 Uhr. 3.6 Reaktionszeiten Als Reaktionszeit gilt der Zeitraum zwischen der Eröffnung einer Störungsmeldung (auch automatisiert) im Ticketsystem der noris network AG und der ersten qualifizierten Maßnahme zur Störungsanalyse und Störungsbehebung. Beim Auftreten von Störungen werden definierte Reaktionszeiten vorgegeben. Diese sind wie folgt: * während der Administrationszeit 3.7 Wiederherstellungszeiten Priorität 1 Priorität 2 Priorität 3 Priorität 4 Reaktionszeit 30 Minuten 60 Minuten 2 Stunden* 8 Stunden* Die Wiederherstellungszeit ist der Zeitraum ab Eröffnung einer Störungsmeldung (auch automatisiert) bis zur Beseitigung der Störung oder der Bereitstellung eines Workaround. Die Wiederherstellungszeiten gelten nur für Servicelevel-relevante Ausfallzeiten. Die Zeit bis zur Bereitstellung eines Workaround bzw. die Zeitspanne bis zum Status Fehlerbehebung permanent abgeschlossen bezieht sich nur auf den Gegenstand der geschuldeten und abgenommen Leistung Wiederherstellungszeit von Services der Verfügbarkeitsklasse HR Für die Wiederherstellung eines ungestörten Systemzustandes sind für Services der Verfügbarkeitsklasse Highly Reliable folgende Zeiten während der Administrationszeiten vorgegeben: Zeit der Wiederherstellung, bzw. Bereitstellung eines Workaround Priorität 1 Priorität 2 Priorität 3 Priorität 4 8 Stunden 16 Stunden 2 Arbeitstage* 10 Arbeitstage* Seite 9 von 11

10 3.7.2 Wiederherstellungszeit von Services der Verfügbarkeitsklasse HA und FT Für die Wiederherstellung eines ungestörten Systemzustandes sind für Services der Verfügbarkeitsklassen High Availability und Fault Tolerant folgende Zeiten während der Betriebszeiten vorgegeben: Zeit der Wiederherstellung, bzw. Bereitstellung eines Workaround Priorität 1 Priorität 2 Priorität 3 Priorität 4 4 Stunden 8 Stunden nächster Arbeitstag* 5 Arbeitstage* * Arbeitstage entsprechen den Administrationszeiten montags bis freitags (außer an gesetzlichen Feiertagen, sowie jährlich dem und ) von 08:00 bis 18:00 Uhr. 3.8 Wartungsfenster Regelmäßige Servicearbeiten an der Infrastruktur werden im Zeitraum von Sonntag auf Montag von 00:00 Uhr bis 05:00 Uhr durchgeführt. Die Durchführung der von der noris network AG zu leistenden Arbeiten wird durch Kunden uneingeschränkt gewährleistet. Tätigkeiten im Wartungsfenster werden nach Möglichkeit vorher angekündigt. Die noris network AG ist berechtigt, nach schriftlicher Vorankündigung das Wartungsfenster zu verschieben. Unbeschadet hiervon bleibt die Möglichkeit, zur Behebung von Störungen oder zur Abwendung von drohenden Störungen jederzeit auch außerhalb des Wartungsfensters tätig zu werden. Die noris network AG ergreift alle zumutbaren Maßnahmen zur Minimierung von Betriebsunterbrechungen, sollten diese dennoch während des Wartungsfensters auftreten, sind diese zu dulden, wenn diese zeitlich angemessen sind. Dem Kunden entsteht hierdurch kein Anspruch auf Schadensersatz oder auf eine Gutschrift. 3.9 Sicherheitsupdates und Patches Bei den von noris network betriebenen Systemen wie z. B. Betriebssystem, Middleware, Datenbanken oder Anwendungen werden alle aus Gründen der Betriebssicherheit, -stabilität oder -integrität erforderlichen Updates und/oder Patches in der Regel selbstständig durch noris network installiert. Sollten seitens des Herstellers Sicherheitsupdates und Patches für ein System nicht oder nicht mehr zur Verfügung gestellt werden, kann noris network die Betriebsstabilität und -sicherheit nicht gewährleisten. Hierüber wird der Kunde schriftlich informiert Regelmäßige Sicherheitsupdates und Patches Sicherheits-Updates und Patches werden, sofern nicht anders mit dem Kunden vereinbart, regelmäßig einmal monatlich in einem dafür vorgesehenen Wartungsfenster (Patchday) im Rahmen des Standard- Change-Verfahrens eingespielt. Der Patchday findet an einem Donnerstag zwischen 0:00 Uhr und 5:00 Uhr statt und wird dem Kunden mindestens eine Woche vorher angekündigt Außerplanmäßige Updates Dringende Sicherheitsupdates können auch außerplanmäßig durchgeführt werden; Betriebsunterbrechungen sind hierbei insoweit zu dulden, als dass dadurch ein größerer Schaden abgewendet werden kann und das Verschulden dafür nicht bei noris liegt. Außerplanmäßige Updates werden über das Emergency-Change-Verfahren durchgeführt und dem Kunden vorher angekündigt. Seite 10 von 11

11 3.10 Service Requests Service Requests sind typischerweise Anfragen zu Betriebszuständen, Reports, Auswertungen etc. Sie werden während der Administrationszeit durchgeführt. 4 Verletzung der Service Level Sollte der Fall eintreten, dass die vereinbarten Service Level für einen Service nicht erfüllt wurden, kann durch den Kunden innerhalb von einem Monat nach Ablauf des von der Nichteinhaltung betroffenen Kalendermonats eine Gutschrift für den betroffenen Service schriftlich beantragt werden. Die Höhe der Gutschrift beträgt bis zu 5 % des monatlichen Rechnungsbetrages des betroffenen Services je 0,1 % Unterschreitung der festgelegten Verfügbarkeit p. a. Werden die festgelegten Reaktionszeiten nicht eingehalten, gewährt die noris network AG eine Gutschrift in Höhe von bis zu 100,00 EUR pro Vorfall. Werden vereinbarte Wiederherstellungszeiten nicht eingehalten, gewährt die noris network AG eine Gutschrift in Höhe von bis zu 500,00 EUR pro Vorfall. Die maximale Höhe der Gutschrift beträgt grundsätzlich 100 % einer Monatsmiete des betroffenen Services. 5 Haftungsausschluss und Abgrenzung Sofern die oben genannten Service Level nicht erfüllt werden, ist eine Haftung der noris network AG nur dann gegeben, wenn die noris network AG die Nichteinhaltung allein zu vertreten hat. Die noris network AG haftet insbesondere nicht für: fälschlicherweise gemeldete Ausfälle, die dem Kunden durch Fehler in internen oder externen Überwachungs-/Monitoring Diensten gemeldet werden. nicht-servicelevel-relevante Ausfallzeiten, wie unter 2.3 definiert 6 Salvatorische Klausel Sollten einzelne Bestimmungen dieses Service Level Agreements ganz oder teilweise nicht rechtswirksam oder nicht durchführbar sind oder werden, so wird hierdurch die Gültigkeit der übrigen Bestimmungen des jeweiligen Vertrags nicht berührt. Seite 11 von 11