Erläuterung und Erweiterung des SLA-Gesprächs

Service Level Agreements (SLAs) gibt es in vielen Formen und Beschreibungen, die ein grundlegendes Niveau an akzeptablen Erfahrungen versprechen. In der Regel haben SLAs eine messbare Komponente, d.h. eine Kennzahl oder einen Leistungsindikator.

Nehmen wir zum Beispiel die Mindestgeschwindigkeit auf Autobahnen. Normalerweise steht auf dem Schild "Mindestgeschwindigkeit 45 mph". Ich dachte immer, die Schilder seien dazu da, um diejenigen, die durch die Höchstgeschwindigkeit von 70 mph verwirrt sind (und diese für das Minimum halten), davon abzuhalten, diejenigen zu überfahren, die verwirrt sind und 45 mph für die Höchstgeschwindigkeit halten.

Es hat sich herausgestellt, dass das Konzept der "Mindestgeschwindigkeit" in einigen Bundesstaaten der USA durchgesetzt wird, um zu verhindern, dass jemand den Verkehrsfluss behindert. Diejenigen, die sich noch an die alte Fernsehserie "Beverly Hillbillies" erinnern, werden sich fragen, ob die Oma, die in einem Schaukelstuhl auf einem Haufen Gerümpel in einem Lastwagen mit offener Ladefläche sitzt und quer durchs Land fährt, ein gutes Beispiel für "Behinderung des Verkehrsflusses" bei jeder Geschwindigkeit ist. Obwohl, so wie der alte Lastwagen aussieht, könnte er wahrscheinlich auch nicht die Mindestgeschwindigkeit von 45 mph einhalten.

In der Welt der IT gibt es alle möglichen Dinge, die den Fluss der Datenübertragung, Datenverarbeitung und/oder Datenspeicherung "behindern" können. Es gibt zwar nichts so Offensichtliches wie eine Oma auf einem alten Lastwagen, aber es gibt häufig wichtige Leistungsindikatoren (KPIs), die darauf hinweisen, wenn die Dinge nicht nach Plan laufen.

Was SLAs der alten Schule vermissen lassen

In der Vergangenheit konzentrierten sich IT-SLAs auf ein Modell der Zuverlässigkeit, Verfügbarkeit und Servicefähigkeit (RAS). Obwohl es sich nicht direkt auf bestimmte Ereignisse/Hindernisse für eine optimale IT-Leistung bezieht, ist RAS zur Norm geworden:

• Zuverlässigkeit - Diese "Sache von Interesse" sollte nicht kaputt gehen, aber sie wird es. Lassen Sie uns eine Zahl nennen.
• Verfügbarkeit - Diese "Sache von Interesse" muss ständig verfügbar sein. Das ist nicht wirklich praktisch. Lassen Sie uns eine Zahl nennen.
• Wartungsfreundlichkeit - Wenn das "Ding von Interesse" kaputt geht oder nicht verfügbar ist, muss es sofort wieder in Betrieb genommen werden können. In der realen Welt wird das nicht passieren. Lassen Sie uns eine Zahl nennen.

In der IT-Branche gibt es viele kreative Variationen des oben beschriebenen Grundthemas, aber RAS ist der Kern dieser Sache, die man SLA-Leistung nennt. Das Problem bei diesem Ansatz aus Sicht des Endbenutzers ist, dass er den Zweck des SLA verfehlt, nämlich die Produktivität/Nutzbarkeit der "Sache von Interesse" sicherzustellen. Im Falle eines Desktops bedeutet dies, dass sichergestellt werden muss, dass der Desktop den Anforderungen des Endbenutzers gerecht wird. Die Produktivität/Nutzbarkeit des Endbenutzers wird also optimiert, wenn der Desktop zuverlässig, verfügbar und wartungsfähig ist... aber ist er das wirklich? Betrachten Sie die folgenden alltäglichen Szenarien:

• Der Desktop ist 100 % der Zeit verfügbar, aber 50 % der Zeit erfüllt er nicht die Anforderungen des Endbenutzers, z. B. hat er nicht genügend Speicher, um eine Excel-Tabelle mit ihren riesigen, speicherfressenden Makros auszuführen.
• Eine kritische Anwendung stürzt immer wieder ab, aber jeder Anruf beim Service Desk endet mit der Frage: "Ist es jetzt so weit?" Nach dem unvermeidlichen "Nein" antwortet der Service Desk: "Bitte rufen Sie wieder an, wenn die Anwendung nicht funktioniert." Diese Art von Verhalten führt häufig dazu, dass Anwender entmutigt wird und eine fehlerhafte Anwendung durch häufige Neustarts einfach weiter verwendet. Es führt auch zu einem falschen Gefühl der "Zuverlässigkeit", weil der Benutzer einfach aufhört, den Service Desk anzurufen, was dazu führt, dass weniger Vorfälle aufgezeichnet werden.
• Die Leistung eines Systems wird ohne ersichtlichen Grund zu verschiedenen Tageszeiten zum Stillstand gebracht. Wenn der Anrufer den Service Desk erreicht, kann es sein, dass sich das System schlecht verhält oder auch nicht. Unabhängig davon kann der Anrufer nur berichten: "Mein System läuft langsam". Der Servicedesk kann fragen: "Tut es das jetzt?" Wenn die Antwort "Ja" lautet, können sie sich möglicherweise in das System einloggen und mit grundlegenden Tools einen Blick darauf werfen, nur um festzustellen, dass keine der System-KPIs in Frage gestellt werden (d. h. CPU, Arbeitsspeicher, IOPs, Speicherplatz, alle sind in Ordnung). In diesem Szenario hat das zugrunde liegende Problem möglicherweise nichts mit dem Desktop oder der Anwendung zu tun. Nehmen wir an, dass es sich um die Netzwerklatenz zum Home-Laufwerk des Benutzers handelt, und verkomplizieren wir die Sache noch dadurch, dass die hohe Latenz nur während der Spitzenzeiten des Netzwerkverkehrs auftritt. Dies liegt eindeutig außerhalb des Anwendungsbereichs des traditionellen RAS-Ansatzes für das SLA-Management. Das Ergebnis: wieder ein Anrufer, der wahrscheinlich lernt, schlechte Leistung einfach zu tolerieren und sein Bestes mit einer suboptimalen Arbeitsplatzerfahrung zu geben.

Um die Endbenutzererfahrung zu verbessern, sollten Sie sie messen

Wie kann man also den traditionellen RAS-Ansatz für das SLA-Management verbessern? Warum überwacht man nicht die Messgrößen, die bekanntermaßen starke Indikatoren für einen gesunden/nicht so gesunden Arbeitsplatz sind? In dieser SLA-Welt bilden objektive, beobachtbare Systemleistungskennzahlen die Grundlage für die Messung des Zustands eines Systems. Wenn beispielsweise die CPU unzureichend ist, sollten Sie diese Kennzahl verfolgen und feststellen, inwieweit sie die Produktivität des Endbenutzers beeinträchtigt. Dann machen Sie dasselbe für mehrere KPIs. Das Ergebnis ist eine sehr aussagekräftige Zahl, die angibt, wie viel Zeit eines Benutzers durch eine schlechte Systemleistung beeinträchtigt wird.

Bei SLAs, die auf beobachtbaren System-KPIs basieren, sind Abweichungen von der Basislinie leicht zu beobachten, sobald eine Basislinie festgelegt ist. Sich einfach nur auf das Zählen von Systemausfällen und Störungen zu konzentrieren, trifft nicht den Kern dessen, was eine IT-Abteilung erreichen möchte. Wir alle wollen nämlich, dass der Endbenutzer einen ausgezeichneten Arbeitsbereich vorfindet, der nicht durch irgendeine Art von "behindertem Fluss" beeinträchtigt wird. Das Endergebnis dieses vorgeschlagenen, auf KPIs und RASs basierenden SLA-Ansatzes sind produktivere Endanwender Anwender. In künftigen Blogs werde ich näher darauf eingehen, wie verschiedene Branchen ein KPI-basiertes SLA-Governance-Modell in die Praxis umsetzen.

Erfahren Sie mehr über die Maximierung der Benutzerproduktivität