"Wenn das Problem da ist, dann ist es zu spät", urteilt Michael Weintraub* über Konzepte, bei denen Leistungsengpässe erst analysiert werden, wenn sie auftreten. Seiner Ansicht nach sollte Performance-Management die ganze Bandbreite vom Monitoring bis zum Auto-Operating abdecken - und zwar in Echtzeit.

Die einzige Definition für Performance-Management, die mir bisher gefallen hat, nennt als Generalkriterium den Grad der Erfüllung der Ziele. Solche Ziele sind etwa ein ausgewogenes Verhältnis zwischen kurzen Antwortzeiten und den Kosten, die man für einen solchen Service aufzubringen bereit ist. Performance muß unter wirtschaftlichen Gesichtspunkten betrachtet werden.

Die Konsequenzen müssen im voraus bedacht werden

Das Performance-Management erlaubt es dem Anwender den Erfüllungsgrad seiner Ziele zu planen, durch Messung Abweichungen zu erkennen, die Gründe dafür festzustellen und schließlich Gegenmaßnahmen einzuleiten. Bevor der Anwender jedoch etwas unternimmt, sollte er auch versuchen, die Konsequenzen von Eingriffen vorherzusehen.

In anderen Bereichen wie der Finanzplanung mit Tabellenkalkulation etwa ist das längst Alltag. Wenn ein Manager sich einen bestimmten Profit für das kommende Jahr vornimmt, wird er sich mit Hilfe eines Spreadsheet die betrieblichen Vorgänge anschauen, sprich messen, Erkenntnisse daraus ziehen und dann die Konsequenzen verschiedener Eingriffe durchspielen.

Performance-Management findet sowohl im Management statt, wo grundlegende Entscheidungen gefällt werden, als auch auf technischer Ebene. Dort werden die großen Fragestellungen zerlegt, um festzustellen, ob nicht noch Detail-Probleme zu berücksichtigen sind. Beide Bereiche müssen zusammenspielen.

Nehmen wir an, das Management hat als Ziel festgelegt, daß die Antwortzeiten von 95 Prozent aller Transaktionen unter 0,3 Sekunden liegen sollen. Mit Hilfe von Werkzeugen muß dann die Rechnerumgebung so modifiziert werden, daß diese Zeitvorstellungen erreicht werden.

Um das zu ermöglichen, muß zuerst festgestellt werden, was in der Umgebung überhaupt vor sich geht. Dafür sind Meßtools zuständig. Zusätzliche Werkzeuge analysieren die gewonnenen Daten. Das geschieht entweder ständig, im Nachhinein oder in regelmäßigen Abständen. Diese drei Verfahren ergänzen sich und sollten daher meiner Meinung nach gemeinsam genutzt werden.

So kann es verdeckte Trends geben, die auch in einer Woche nicht entdeckt werden, Techniker brauchen eventuell stündlich Erkenntnisse über den Systemstand, und Eingriffe können ständig vonnöten sein. Meiner Überzeugung nach ist es daher das oberste Gebot beim Performance-Management, ständig zu beobachten. Dem Benutzer sollten jedoch nur die Ausnahmesituationen angezeigt werden.

Das Ziel heißt Messung und Aktion in Echtzeit

Dafür ist ein Tool zuständig das Daten in für Menschen verständliche und nützliche Informationen umwandelt. Und dann gibt es noch die Werkzeuge, die auf Grund der Informationen geeignete Maßnahmen vorschlagen, die also die Informationen in Anwendungswissen ummünzen.

Ein System für das Performance-Management sollte "realtime" messen und sofort oder in festgelegten Abständen reagieren können oder doch wenigstens Handlungsvorschläge geben. Relativ neu sind Tools, die Eingriffe in den Systembetrieb vornehmen und in Richtung des sogenannten "Auto-Operating" zielen. Es gibt ganze Familien von Architekturen, die darauf ausgerichtet sind, Performance-Engpässe zu sehen, zu deuten und vielleicht auch automatisch darauf zu reagieren

Ein Beispiel für einen typischen Performance-Engpaß: Ein Unternehmen hat erkannt, daß auf seinen Platten zu viele In- und Output-Operationen stattfinden und darum die Antwortzeiten zu lang werden. In einem solchen Fall geht ein Systemtechniker oder ein Tool daran, festzustellen, welche Dateien auf den Platten sind, zu welchen Anwendungen sie gehören und welche Priorität die Files haben.

Das Beratungstool rät dann beispielweise, die Prioritäten zu verändern und einer weniger wichtigen Anwendung weniger CPU-Zeit zuzugestehen. Vielleicht rät das Tool jedoch auch, bestimmte Dateien auf verschiedene Platten zu legen, um die Zugriffe besser zu verteilen. Der Eingriff selbst geschieht dann durch den menschlichen oder aber direkt durch den Auto-Operator.

Während also bei den herkömmlichen Tools von der Messung bis zur Beratung der Mensch der einzige bleibt, der im Sinne von Systemeingriffen aktiv wird, nimmt beim Auto-Operating das entsprechende Werkzeug die Eingriffe vor. Angestrebt ist ein regelbasiertes, lernfähiges System, das mit dem Beratungstool gekoppelt ist. Das bedeutet, daß bei einem Vorfall der Mensch eine Meldung mit einem Behebungsvorschlag erhält, der, wenn er bestätigt wird, als Regel in das System aufgenommen wird.

Bei einem solchen Verfahren ist klar, daß die Tools für das Performance-Management ständig mitlaufen müssen. Nur so können Spitzenlasten, wie sie etwa bei Banken donnerstags wegen der längeren Öffnungszeiten oder einmal im Jahr am Weltspartag auftreten, berücksichtigt werden.

Die Performance-Management-Umgebung sollte sich weitgehend selbst regeln. Die einzelnen Technologien für eine solche Lösung sind zwar schon verfügbar, können aber noch nicht miteinander arbeiten. Sie müssen also noch integriert werden.

Aus Performance-Management wird Performance-Automation

Ein solches System wäre ein Schritt hin zur allseits diskutierten Automation des Rechenzentrums. Heute denkt man hier meist nur an die Automatisierung der Abläufe; zur Güte der Produktion gehört aber auch die Performance. Was ich beschrieben habe, könnte man daher als Performance-Automation bezeichnen.

Meine Thesen lauten: Erstens läßt sich die Performance nur an unternehmerischen Zielen messen. Und zum zweiten ist eine PerformanceManagement-Umgebung, wie ich sie beschrieben habe, nicht nur machbar, sondern sogar notwendig. Wer daran nicht schon heute arbeitet, wird später gewaltige Probleme bekommen.

Ein wesentliches Argument für ein ständig mitlaufendes Performance-Management-System ist, daß im Rechenzentrum nicht mehr erst dann reagiert werden kann, wenn die Probleme schon da sind, sondern daß man aktiv vorausplanen kann. Unerwartete Ereignisse treten ganz selten ein, weil die Zyklen, die Anwendungen und die Lastenverteilung bekannt sind. Kommende Lasten kann man also schon im voraus berücksichtigen. Damit wird es möglich, exakt zu planen, wie welche Hard- und Software möglichst optimal eingesetzt wird, um die gewünschten Antwortzeiten zu erhalten.