Service nach Wunsch
Service Level Agreements (SLA) sind eigentlich Stand der Technik und sollen für eine reibungslose Zusammenarbeit zwischen externen oder auch internen Serviceerbringer und -Nutzer sorgen. Wie kommen aber diese beiden Parteien zu einer derartigen Übereinkunft, wie geht man bei der Erstellung derselben vor, wie handhabt man in der Praxis einen SLA-orientierten Betrieb und welche Rolle spielt die Netzwerk-Analyse?
Praxisbericht eines SLA-orientrierten Betriebes am Beispiel der Siemens A&D
Im Folgenden soll das am Beispiel eines Rechenzentrenkonsolidierungsprojekts der Siemens A&D dargestellt werden. Dabei wurde ein Metropolitan-Area-Network für rund 30.000 Anwender an acht Standorten realisiert.
Der Bericht ist in folgende Abschnitte unterteilt:
* Netzwerk-Qualitätsmerkmale eines MANs,
* Festlegung der Kennwerte,
* Nachweisbarkeit der Qualitätskennwerte per Netzwerkanalyse,
* Erfahrungsbericht und
* Fazit.
Netzwerk-Qualitätsmerkmale eines MANs
Qualität ist definiert als "Eignung für den vorgesehenen Zweck". Woran genau macht man aber nun fest, ob das MAN für den vorgesehenen Zweck geeignet ist? Im Fall der Siemens A&D sollten Rechenzentrum und übrige Infrastruktur eine bestehende Lösung ersetzen, aber die Betriebskosten signifikant senken.
Dazu war ein Architekturneuansatz erforderlich. Dies bedeutet, dass die Infrastruktur des Metropolitan Area Networks (MAN) komplett neu zu erstellen und in den laufenden Betrieb des Unternehmensbereichs zu integrieren war.
Die Definition des Leistungsumfangs sowie der Qualitäten der neuen Infrastruktur waren entscheidend für das Design der technischen Lösung (Top-Down-Entwurf). Die Designer des MAN forderten mit Recht eine möglichst präzise Beschreibung funktionellen und qualitativen Anforderungen an das MAN. Diese Anforderungen wurden aus den Projektzielen des RZ-Konsolidierungs-Projektes abgeleitet. Es hatte zum Ziel, Betriebskosten einer bislang dezentralen und inhomogenen IT-Lösung durch Zentralisierung und Standardisierung signifikant zu senken. Gleichzeitig mussten die bislang durch langjährige Optimierung erreichten Servicequalitäten erhalten, eher noch gesteigert werden.
Da das MAN für die Erbringung der RZ-Services eine zentrale Architektur-Komponente darstellt, verwundert es nicht, dass es höchsten Ansprüchen an Funktionalität und Qualität gerecht werden muss.
Wie sind diese Qualitäten und Funktionalitäten innerhalb der Anforderungen präzise zu formulieren?
Wie immer am Anfang eines jeden SLA-Prozesses standen sich Bedarf und Bedürfnisse der Nutzer ("wie viel IT braucht der Mensch"), sowie die betriebstechnischen Randbedingungen für Beschaffung und Betrieb ("wie viel IT ist wirtschaftlich und ökonomisch machbar") gegenüber.
Ausgangspunkt waren die Anforderungen der Systemarchitekten des RZ zum Erreichen der Projektziele. Daraus abgeleitet wurde schnell klar, was vom MAN erwartet wurde. Zuallererst musste es in der Lage sein, die geforderten Datenströme für die Applikationen des RZ-Warenkorbes nebst angemessenen Reserven für Wachstum bereitzustellen. Für RZ-Zwecke (Replikation der Daten aus Redundanzgründen) wurden ebenfalls erhebliche Bandbreiten benötigt. Diese Forderung wurde in Bandbreite (GBit/s) ausgedrückt.
Eine weitere Anforderung war, für Anwendungen eine möglichst kurze Signallaufzeit ("Latency oder Delay") bereitzustellen, um Transaktionszeiten von nahezu LAN-Qualität anbieten zu können, und so dem Anwender vor Ort trotz Zentralisierung vergleichbare Verhältnisse wie vorher bieten zu können. Diese Anforderung mündete in Vorgaben für Delay.
Neben den Datenströmen des RZs waren auch die Belange von fertigungs- und entwicklungsnahen Verfahren sowie sonstigem Datenverkehr zwischen Standorten zu berücksichtigen. Diese Datenströme sollten aber diejenigen für das Rechenzentrum nicht so beeinflussen, dass deren Qualitäten beeinträchtigt wären. Daraus ergab sich die Anforderung an definierte Bandbreitenaufteilung für die jeweiligen Verkehrsarten, sowie die Anforderung an Transparenz über die tatsächliche Bandbreitennutzung.
Schließlich stellt das MAN den zentralen Knotenpunkt im RZ Design dar und somit bezüglich der Verfügbarkeitsbetrachtung ein hochsensibles Element. Dies mündete in eine Anforderung an "durchlaufenden Betrieb" (also keine regelmäßigen Wartungszeiten) und eine definierte Mindestverfügbarkeit.
Wann ist "gut? gut genug?
Nachdem die Kriterien:
* Bandbreite
* Delay
* Definierte Bandbreiten für definierte Verkehrsströme
* Transparenz der Bandbreiten-Nutzung
* Durchlaufender Betrieb
* Hohe Verfügbarkeit
feststanden, war die nächste Frage "wie viel wovon"? Gut und schnell ließen sich die benötigten Bandbreiten aufgrund der bekannten Mengengerüste definieren. Aber der Rest? Der erste Wunsch war natürlich "so gut wie möglich":
* Bandbreite mehrere GBit/s
* Delay mit LAN-Qualität also
* Feingranulare Bandbreitendefinition
* "zero planned downtime"
* 100 Prozent Verfügbarkeit
Bereits die ersten Planungsgespräche zeigten (wie erwartet), dass einige Anforderungen aus physikalischen Gründen (Lichtgeschwindigkeit in Lichtwellenleitermedien), andere aus finanziellen Gründen (Bandbreite ist nach wie vor teuer, und den Kosten für Verfügbarkeit sind ebenfalls keine Grenzen gesetzt) nicht sinnvoll umsetzbar waren.
Wie immer, wenn Einflüsse kontrovers sind, also sich nicht gleichzeitig in vollem Umfang realisieren lassen, müssen sich die Partner in interaktiven Schritten eine "Kompromissformel" erarbeiten.
Das heute auf der Basis von Gigabit Ethernet (CWDM) und einer "Dark Fibre" Strecke mit redundanter Trassenführung umgesetzte MAN, bot einen akzeptablen Kompromiss zwischen Kosten und Qualität/Funktionalität.
Somit wurden die Kennwerte:
* Bandbreite 1 GBit/s
* Delay je nach Distanz zwischen 1 und 12,5ms
* drei Bandbreiten-Zonen für drei Verkehrsarten (RZ-Daten, Standort/RZ-Daten,
* Standort/Standortdaten)
* "zero planned downtime"
* Verfügbarkeit von 99,99 Prozent
als für "gut genug" und wirtschaftlich tragbar definiert und vertraglich festgeschrieben.
Neben den hier beschriebenen SLA-Kriterien enthält das konkrete Agreement auch Festlegungen zu betrieblichen Belangen, wie Rechte und Pflichten beider Parteien sowie die Pflege (Änderungswesen, Anpassungen entsprechend der Mengengerüste, Fristen etc.).
Ist die Leistung im Betrieb so gut wie vereinbart?
Für den Nachweis der vertraglich vereinbarten Leistungen dienen ebenfalls die oben beschriebenen Qualitätskriterien. Damit diese aber überprüfbar, dokumentierbar und möglichst unstrittig sind, empfiehlt es sich, für jedes Kriterium eine Messvorschrift und eine Maßnahme bei nicht einhalten des Kriteriums anzugeben. Auch die Definition der Messvorschrift bedarf einer sorgfältigen Überlegung und intensiver Diskussionen.
Ausgehend von den oben beschriebenen Qualitätskriterien sind die geeignete Detailtiefe und Abdeckung zu betrachten.
Darunter fallen Punkte wie:
* Gilt für die Ermittlung ein Mittelwert, ein Perzentil oder eine obere Grenze?
* Werden alle Strecken vermessen oder nur die "betriebsführende"
* Laufen die Messungen kontinuierlich oder nur zu bestimmten Zeiten
* Wie oft darf ein Schwellwert verletzt werden, bis eskaliert wird?
* Wie stark darf die Messung den Betrieb beeinträchtigen?
Hierfür ist der Stand der Netzwerk-Analyse (was ist wie messbar), die Automatisierbarkeit von Messungen und des Reportings, sowie der Aufwand dafür zu betrachten. Die Tool-Entscheidung fiel auf "StableNet Enterprise" des Unternehmens Infosim.
Betriebsergebnis nach der SLA-Einführung
Im Rahmen des Projekts wurden die genannten Netzwerk-Qualitätskriterien in den Liefervertrag für das MAN aufgenommen und bei der Abnahme überprüft. Dafür und für die kontinuierliche Überprüfung wurde beim Aufbau des MAN eine Infrastruktur in Form von Einrichtungen, Prozessen und Ressourcen geschaffen und bereitgestellt.
Damit war es in der Betriebseinführungsphase möglich, Schäden zu vermeiden, Schadenswirkungen zu verringern und die Prozesse vorbeugend zu verbessern. Der Betrieb kann nunmehr auf mehr als ein Jahr Betrieb im Rahmen des SLA zurückblicken. Bewährt haben sich die Maßnahmen für Definition, Verhandlung und Umsetzung von Qualitätskriterien durch:
* Klare Abnahmekriterien zwischen Kunde und Lieferant
* Begleitung der Systemeinführung und von "Changes" im Betrieb
* Sachliche Diskussion von Störungen
* Zielgerichtete Optimierung des Designs im Sinne von Kosten/Nutzen für die Anwender
* Klar definierte Vertragsgrundlagen
Wesentliche Ergebnisse der SLA-Einführung sind:
* Transparenz über die Nutzung des MAN (Top Talkers, Volumen nach Anwendungen, Lastprofile pro Tag, Woche und Monat)
* Schnelle Alarmierungen bei Detaileffekten, die zwar nicht den SLA gefährden, aber schnelle Reaktion erfordern (zum Beispiel Redundanz-Umschaltungen)
* Klar dokumentierte Nachweise zu Sachverhalten, die nicht auf MAN-Defekte, sondern auf Applikationen im Feld, oder auf Ursachen außerhalb der Verantwortung der MAN-Betreiber zurückzuführen sind (zum Beispiel nicht abgesprochene Inbetriebsetzungen von Verfahren, missbräuchliche Benutzung etc.)
* Kundenfreundliche Informationsmöglichkeiten über den aktuellen Systemzustand durch Verfügbarkeit der SLA-Information im Intranet
Fazit
Service Level Agreements (SLA) erleichtern und verbessern eine Zusammenarbeit zwischen externen als auch internen Service Erbringer und Service Nutzer wesentlich. Studien belegen, dass derzeit 89 Prozent der IT-Verantwortlichen die Steigerung der Produktivität als wichtigstes Ziel der Investitionen sehen. Dazu kann ein SLA-orientierter Betrieb maßgeblich beitragen. Es sollte frühzeitig die Gelegenheit genutzt werden, auch ohne explizite Aufforderung seitens der Servicenutzer frühzeitig SLAs einzuführen, um Ihre Ziele zur Produktivitäts- und Qualitätssteigerung definieren, messen, nachweisen und erzielen zu können.
Lesen Sie mehr zum Thema
