Ich arbeite für ein kleines Entwicklungshaus, das immer häufiger gebeten wird, auf der Grundlage bestimmter Konfigurationen formelle SLAs für unsere Produkte zusammenzustellen.
Aus Entwicklungssicht bin ich damit einverstanden. Es macht jedoch keinen Sinn, wenn ich sage, dass wir bestimmte Ziele aus Softwaresicht erreichen werden, wenn sie aus Hardware-/Plattformsicht nicht realistisch sind – den Kunden ist nur die allgemeine Systemverfügbarkeit wichtig.
Worauf sollte ich aus Plattformsicht achten? Welche Art von Metriken und Ebenen gibt es?
Und wo liegen die Fallstricke (aus Softwaresicht würde ich mich zum Beispiel nie auf einen festen Zeitpunkt festlegen – ich habe keine Ahnung, ob ich das ganze Produkt neu schreiben muss, um etwas zu korrigieren, daher ist die Aussage, dass wir das Problem in 5 Tagen beheben können, möglicherweise unmöglich – worauf sollte ich mich aus Hardware-/Betriebssystem-/Plattformsicht nicht festlegen)?
Antwort1
Ich verfüge auf diesem Gebiet über umfangreiche Erfahrung; ich arbeite viel für einige Fortune-5-Unternehmen, die ihre Rechenzentren wie ein ISP für die verschiedenen Unternehmensabteilungen betreiben, die Hosting- und Supportdienste benötigen.
Sie verfügen normalerweise über zwei Kennzahlen, die als SLA (Service Level Agreement) und OLA (Operational Level Agreement) bezeichnet werden.
SLAs werden durch die Art der verwendeten Hardware eingehalten. Wenn wir über SLAs sprechen, verwenden wir Ebenen, um sie zu beschreiben. SLA-1 bedeutet null Ausfallzeit, SLA-2 bedeutet etwa bis zu 1 Stunde Ausfallzeit, SLA-3 bedeutet 8 Stunden usw. SLAs werden durch die Verwendung redundanter Geräte eingehalten. In einem Unternehmen verwenden wir viel Cisco, um eine hohe Verfügbarkeit zu gewährleisten (Cisco CSMs und GSS-Geräte). Wenn wir über SLA-Ebenen sprechen, sprechen wir im Allgemeinen über HA (High Availability) und DR (Disaster Recovery). In Situationen, in denen ein Unternehmen über mehrere Rechenzentren verfügt, ist die HA-Komponente normalerweise ein Attribut pro Rechenzentrum, während DR ein Attribut über alle Rechenzentren hinweg ist; beide werden in Bezug auf RPO (Recovery Point Objective) und RTO (Recovery Time Objective) gemessen, um die SLA-Ebene zu bestimmen.
OLAs geben im Grunde an, wie schnell jemand (ein Mensch) auf ein Ereignis reagiert, das manuelle Eingriffe/Korrekturmaßnahmen erfordert. OLAs werden normalerweise auch anhand der Reaktionszeiten gemessen; sie verwenden dieselben RTO/RPO-Ziele. Ein Unternehmen, das ich berate, verwendet 6 Ebenen für seine OLA-Kennzahlen. Die ersten 3 Ebenen sind hier ein Beispiel dafür:
OLA-1: RTO 0 < 2 Stunden OLA-2: RTO >= 2 & <= 4 Stunden OLA-3: RTO >= 24 Stunden & <= 30 Tage, wenn kein Rechenzentrumsausfall vorliegt, wenn Rechenzentrumsausfall > 30 Tage.
Die Faktoren, die die OLA- und SLA-Kennzahlen bestimmen, sind sogenannte CIA-Bewertungen. CIA steht für Vertraulichkeit, Integrität und Verfügbarkeit. Daten für eine Anwendung sollten von der Geschäftseinheit klassifiziert werden, die für die besagte Anwendung bezahlt. Die CIA hilft dabei, festzulegen, wie OLA und SLA aussehen sollten. Jeder Teil der CIA-Stufe erhält eine Zahl von 1 bis 3. Eine CIA-Bewertung von 1-1-1 wäre beispielsweise „Streng vertraulich“, „Höchste Integritätsstufe“ und „Höchste Verfügbarkeitsstufe“. Eine CIA-Bewertung von 3-3-3 ist die niedrigste Stufe, die Sie erreichen können. Eine CIA-Bewertung von 3-3-3 entspricht also normalerweise einer SLA- und OLA-Stufe von 6, wobei SLA-6 und OLA-6 die niedrigste (längste Reaktionszeit) sind, die garantiert wird.
Die Ableitung einer CIA-Bewertung läuft normalerweise darauf hinaus, herauszufinden, wie viel Geld ein Unternehmen verliert, wenn die Daten gestohlen werden (Vertraulichkeit), kompromittiert werden (Integrität) oder wenn Systeme ausfallen (Verfügbarkeit). Ein Unternehmen, das 10 Millionen Dollar verlieren könnte, wenn vertrauliche Daten gestohlen werden, könnte also eine C-Bewertung von 1 haben. Wenn der Datenverlust nicht kritisch ist und das Unternehmen beispielsweise nur 1.000 Dollar kosten würde, könnte es stattdessen eine C-Bewertung von 3 haben.
So handhaben die großen Unternehmen, die ich beraten habe, solche Dinge typischerweise.
Antwort2
Ich würde mich bei Hardwareproblemen nicht auf eine bestimmte Zeit festlegen, genauso wenig wie bei Software. Man weiß nie, wann man auf einen Anbieter warten muss, um einen kritischen Fehler zu beheben. Was SLA-Levels angeht, habe ich festgestellt, dass sie in der Regel in der Form lauten: „Jemand wird innerhalb von X Stunden an Ihrem Problem arbeiten.“ X hängt natürlich davon ab, wie viel sie bezahlen, aber meiner Erfahrung nach scheint irgendwo zwischen 1 und 8 Stunden normal zu sein.
Antwort3
Wenn Sie aufgefordert werden, ein SLA für die Behebung von Hardwareproblemen bereitzustellen, bei denen Ihre Software installiert ist, lautet die Antwort „Nein“. Sie können sich zu einer Reaktionszeit verpflichten, aber ohne Kontrolle über den gesamten Hardware-/Betriebssystem-/Software-Stack können Sie sich nicht zu einer Lösungszeit verpflichten.
Vielleicht sagt Ihnen Ihr Kunde auf eine ungeschickte Art und Weise, dass er wirklich ein gehostetes Angebot für Ihr Produkt benötigt? Auf diese Weise kann er die internen Probleme, über die er sich Sorgen macht, vermeiden und Ihnen einfach einen Scheck ausstellen.
Antwort4
Beim Abschluss eines SLA ist zu bedenken, dass das SLA allein absolut nichts bedeutet und zusammen mit den Strafen, die bei Nichteinhaltung des SLAs gelten, beachtet werden muss.
Beispielsweise gewährt uns unser ISP 100 % SLA für das Netzwerk, aber das Höchste, was wir zurückbekommen, ist unsere monatliche Rechnung, die wirklich niedrig ist, da die Bandbreite heutzutage billig ist und bei weitem nicht an die Summe heranreicht, die wir verlieren, wenn das Netzwerk ausfällt.
Außerdem steht in den Verträgen normalerweise, wie schnell jemand auf das Problem reagiert, nie, wie lange es tatsächlich dauern wird, es zu beheben. Wenn Sie sich also zu kurzen Reaktionszeiten verpflichten müssen, setzen Sie einfach einen Praktikanten in die Nachtschicht ein, der die Tickets für Sie mischt, bis Sie aufwachen, und los geht‘s.
Meiner Erfahrung nach bedeutet diese ganze SLA-Sache in der Praxis sehr, sehr wenig, wenn überhaupt etwas.