Was SLAs für Software as a Service (SaaS) enthalten sollten

Verfügbarkeit von SLAs

„Grundsätzlich könnte man denken, ein SLA wäre so etwas wie der Service Level, also eine Garantie für die Verfügbarkeit. Mit Verfügbarkeit beziehungsweise Availability ist gemeint, wie oft der Service ausfällt“, sagt Golden.

Verfügbarkeiten werden als Verhältnis von Uptime – der Zeit, die der Service verfügbar ist – zur Gesamtzeit, also Uptime plus Downtime gemessen: Uptime/ (Uptime + Downtime) und mit drei, vier oder fünf Neunen ausgedrückt: 99,9 oder 99,99 oder 99,999 Prozent. Einfache Services erreichen Verfügbarkeiten von 99,9 Prozent – was einen Zugriffsverlust von 8,7 Stunden pro Jahr bedeutet.

Die nächst höhere Verfügbarkeitsstufe ist eine Ausfallsicherheit von 99,99 Prozent. Dies entspricht einer Downtime von etwa 50 Minuten pro Jahr. Auch dies ist für manche Einsatzgebiete zu viel. Als magischer Wert gelten „Five-Nine“: 99,999 Prozent Verfügbarkeit. Das bedeutet weniger als fünf Minuten Ausfall pro Jahr.

„Eine Sache, die man dabei im Auge behalten sollte, ist folgende: Wenn ein Anbieter sich nach mehr Neunen – und somit nach geringeren Ausfallzeiten – streckt, dann steigen damit in der Regel auch die Kosten“ sagt Golden.

Neben der Verfügbarkeit sollten auch die bereitgestellten Business-Funktionen betrachtet werden. „Es ist wichtig, dass sich SLAs stärker an Business-Values ausrichten, die Sie von SaaS erwarten“, sagt Bill Corrington, Cloud Strategy Lead bei Stony Point Enterprises. „Dies ist allerdings eine echte Herausforderung, da die Verkäufer dies nicht wollen.“

Corrington nutzt E-Mail as a Service und sagt: „E-Mail as a Service ist eigentlich sehr komplex. Wenn Sie kein internes Routing und keine Kontakte konfiguriert haben, werden Sie keine E-Mail geliefert bekommen. Das System läuft, aber die E-Mail wird nicht ausgeliefert“, sagt er. In diesem Fall rät er zu einer SLA, die den Anteil von ausgelieferten E-Mails festlegt.

Ausfallzeiten in einem SLA

Das E-Mail-Beispiel zählt im Sinne der Service Provider nicht als Ausfallzeit. Deshalb ist es wichtig, Ausfallzeiten in einer SLA genau zu definieren.

„Die Leute fragen sich, was als Downtime zählt: Nur ungeplante Ausfallzeiten oder auch geplante Ausfallzeiten für Wartung oder Aktualisierung der Systeme: Aus der Sicht des Providers ist klar, dass letzteres nicht als Ausfallzeit zählt“, sagt Golden.

Der Kunde sieht das anders. Egal, welche Ursache ein Ausfall hat: Wenn das System down ist, wird der Kunde dafür sicherlich nicht zahlen wollen. Eine Sache, die immer in einem Basisvertrag stehen sollte, ist die Höhe der Entschädigung im Falle der Nichtverfügbarkeit des Service. Also zum Beispiel: Wenn der Service nicht verfügbar ist, erstatten wir Ihnen die Kosten für den Service für eine Anzahl X von Stunden. Was dabei allerdings so gut wie nie thematisiert wird, sind die durch den Ausfall verpassten Geschäftstransaktionen wie etwa Verkäufe. „Vielleicht möchten Sie so etwas in die SLA integrieren, aber kein Anbieter wird dem zustimmen. Eine solche Verpflichtung wird kein Provider eingehen“, sagt Golden.

Mittlere Wartungsdauer und mittlere Antwortzeit

Eine SLA sollte auch das Thema Schweregrade (Severity Level) definieren, und eine mittlere Wartungsdauer und eine mittlere Antwortzeit festlegen, sagt Corrington. Wenn zum Beispiel ein Severity 1 Level kritisch ist – was bedeutet, dass das System heruntergefahren ist – sollte die mittlere Antwortzeit und die mittlere Wartungszeit weniger als ein Severity 3 Level sein.

Ebenso sollten die Service Level Agreements auf der Grundlage Ihrer Benutzer festgelegt werden, sagt Corrington. „Ein zentraler Punkt ist, zu erkennen, dass Sie einige Benutzer haben, die wichtiger sind als andere“, sagt er. Diese „VIP“ Benutzer sollten Vorrang vor anderen haben, wenn es um Fragen der Fehlersuche geht. Wenn Sie zum Beispiel eine E-Mail-SaaS-Lösung verwenden und ein VIP User wie ein Division Vice President kann an einem Samstagmorgen auf seinem Smartphone keine E-Mails mehr versenden, dann sollte dieses Problem als Severity 1 angesprochen werden.

„Der Verkäufer muss anhand der Namen oder Titel verstehen, wer diese Leute sind. Und der Verkäufer muss verstehen, dass sie die richtigen SLAs benötigen“, sagt Corrington.

„Einer der großen Unterschiede beim Übergang von interner, On Premise IT zu externer, Cloud-basierter IT ist die Kontrollspanne“, sagt Corrington. Wenn es ein Problem mit Ihrem internen E-Mail-System gibt, wissen Sie, dass Sie Ihren System-Administrator anrufen können, sagt er. Bei SaaS hingegen können Sie nicht erwarten, dass Sie mit jemanden über die Infrastruktur sprechen können, der volle Administratorrechte hat.

Die Lösung des Problems: „Sie brauchen auf Verkäuferseite jemanden in der Management-Kette, der Maßnahmen ergreifen kann. Es ist wichtig, dies verstanden und dokumentiert zu haben. Sie wollen sich schließlich nicht wie in der Warteschleife eines Call Centers fühlen“, sagt Corrington.

Eine Warnung vor SLAs

Schließlich ist es auch noch wichtig, die SaaS SLAs in die richtige Perspektive zu rücken. „Man sollte die Existenz eines SLAs nicht mit der tatsächlichen, realen Performance der SaaS-App verwechseln“, sagt Golden. „Das SLA eliminiert nicht die Notwendigkeit, das System zu beurteilen.“

Mit anderen Worten: Sie sollten nicht davon ausgehen, dass der Dienst wirklich zur Verfügung steht, da das SLA das so festgeschrieben hat. Bewerten Sie den Service eigenverantwortlich für sich selbst. Bedenken Sie dabei: Welche Erfahrungen haben andere Kunden bei diesem Punkt gemacht? Wie gut stellt der Provider diesen Service bereit? Welche Pläne hat der Provider im Falle einer Katastrophe? Hat der Anbieter ein Disaster-Recovery-System, das sofort ausgeführt werden kann?

„Das SLA kontrolliert nicht, was tatsächlich geliefert wird“, sagt Golden. „Stattdessen geht es darum, welche Ausbeute Sie am Ende des Tages haben. Im Endeffekt möchten Sie nie über das SLA diskutieren. Weil Sie einfach nur wollen, dass der Service zur Verfügung steht.“

 Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!