ITSM

Schwachstellen der IT-Automation

30.03.2010 von Stefan Ueberhorst
Auf die automatisierte Konfiguration von IT-Komponenten folgt die der IT-Prozesse. Doch die Praxis sieht noch anders aus.
Foto: Fotolia.com/CW

"Einen Kubikmeter Rechenzentrum bitte!", spitzt Hewlett-Packard seine Vision von der automatisierten Servicemaschine zu. Dank erheblicher Fortschritte bei Virtualisierung, Run-Book Automation (RBA) und Workflow-Orchestrierung gelte inzwischen, so HP-Manager Markus Herber, dass es sich bei einem Rechenzentrum beziehungsweise einer gerade erforderlichen RZ-Erweiterung im Idealfall um einen generischen Ressourcen-Pool handele, der sich aus dem Stegreif aufsetzen lasse. Dabei bedeute der Begriff Pool gebündelte Software-, Rechen- und Speicherkapazitäten, die sich, ob physisch oder virtualisiert, regelgestützt über die Server-, Netz- und Storage-Silos hinweg dynamisch zuweisen lassen. Ohne dass der Betreiber auf bestimmte Workloads festgelegt wäre, erfolge die Provisionierung der neuen Ressourcen nachvollziehbar, wiederholbar und automatisiert via Self-Service-Portal durch die Fachabteilung oder den Kunden, so der HP-Mann.

Markus Herber, HP-Consultant.
Foto: HP

Angesichts der Tatsache, dass die RZ-Automation schon beinahe so alt ist wie die IT selbst, fragt man sich, weshalb Infrastrukturszenarien wie Utility Computing, Real Time Infrastructure, IT as a Service oder jüngst Cloud Computing erst jetzt heiß diskutiert werden. Einen Grund sieht HP-Consultant Herber darin, dass sich die IT-Automation von einer passiven oder analytischen zu einer prozessbasierenden aktiven Disziplin entwickelt habe. Zu den Automatismen auf Komponenten- oder Systemebene, die in der Praxis meist per Scripting umgesetzt werden, kommt heute unter dem Stichwort Run-Book Automation die IT-Prozess- und IT-Service-Ebene, die insbesondere im Bereich des Incident-, Change- und Configuration-Management ihren Dienst leistet. Erst wenn alle Ebenen ineinandergreifen, wird eine system- und herstellerübergreifende, automatisierbare Orchestrierung des IT-Betriebs möglich.

Centracon-Studie 2009




Der Weg über Application Templates

Ein Rezept dafür sieht HP in so genannten Applikations-Templates. Will ein Unternehmen beispielsweise eine SharePoint-Landschaft für 1000 Anwender einrichten, könnten solche Templates die IT-Abteilung bei der optimalen Konfiguration unterstützen, indem sie klare Handlungsanweisungen zur Zahl der benötigten Cores und ihrer Taktraten, zu RAM, Netzverbindungen, LUNs im SAN, zur Raid-Konfiguration und allen zugehörigen Instanzen bieten. Auf dieser Basis könnte dann die Provisionierung automatisch und in einem einzigen Zyklus erfolgen, einschließlich der Server-Konfiguration, des Betriebssystem-Deployments und der Einbindung der System-Management-Agenten.

Winfried Winkler, HP-Manager.
Foto: HP

Doch der Wandel des Rechenzentrums zu einer "Shared Services Engine" lässt sich nur mit einer tief reichenden, detaillierten Kenntnis aller beteiligten Komponenten vollziehen. Der Einsatz vorgefertigter Skripte erfordert es, dass ein System in all seinen technischen Spezifikationen bekannt ist. Zudem mahnt Winfried Winkler, ebenfalls HP-Manager, eine homogene beziehungsweise konvergente Infrastruktur an. Darunter versteht der Experte eine gemeinsame Verwaltung der bislang oft noch getrennt behandelten IT-Silos wie Server, Speicher und Netz.

Zwei Wege zur Konvergenz

Die Konvergenz der Infrastruktur entwickelt sich laut Winkler derzeit auf zwei Wegen. Zum einen setzten sich herstellerübergreifend entsprechende Standards durch. Als Beispiel nennt er den Speicherbereich, wo iSCSI die Nutzung des SCSI-Protokolls über IP-Netze ermöglicht hat. Damit seien die Barrieren zwischen SAN- und IP-Management eingerissen worden, so dass sich zahlreiche Optionen zur Bildung von flexiblen Speicher-Pools eröffnet hätten.

Als zweiten Weg nennt Winkler den unübersehbaren Trend großer IT-Anbieter in Richtung Komplettlösungen, deren Einzelkomponenten bereits ab Werk aufeinander abgestimmt sind. Da es heute noch an Standards fehle, würden die Großen der Branche nach allen Kräften eine Position anstreben, in der sie als Komplettanbieter für automatisierte Rechenzentren auftreten könnten. Damit stünden sich die Interessen der Anwender und Hersteller gegenüber: Während die einen freie Tool-Auswahl möchten und deshalb die Standardisierung schätzen, wollen die anderen den Kunden für sich und treten als technischer Unique Selling Point auf. Allein die konsequente Orientierung an Standards biete eine Gewähr dafür, dass die unumgänglichen Kompromisse hinsichtlich Automatisierungsgrad und Unabhängigkeit möglichst gering ausfallen.

Auf der nächsten Seite äußert sich Materna zum Thema IT-Automatisierung.

Kein Schweizer Messer für die Automation

Jochen Staub, Materna.
Foto: Materna

Doch der Konflikt hält sich in Grenzen. Zwar haben die Großen der Branche die Lücken in ihrem Portfolio für IT-Service-Management und Automation über Zukäufe von Spezialisten geschlossen und damit die Sorge aufkommen lassen, ein effizienter, prozessorientierter und in Teilbereichen automatisierter IT-Betrieb sei nur dann möglich, wenn man sich ausschließlich in der Tool-Umgebung eines einzigen Herstellers bewege. Tatsächlich trifft man in der Praxis jedoch auf heterogene ITSM-Landschaften, was den Aufwand für Schnittstellen und Anpassungen erhöht, aber die mit Itil-Standardprozessen arbeitenden Unternehmen vor keine schwerwiegenden Probleme stellt. Jochen Staub, Teamleiter Systems Management & Automation bei der Materna GmbH, warnt deshalb auch: "Lässt man die Mainframe-Seite einmal außen vor, gibt es selbst in einer reinen IBM- oder HP-Welt, wo Hardware und Service-Management-Werkzeuge aufeinander abgestimmt sein sollten, nicht das Schweizer Messer für alle Facetten der Automation."

Staub unterscheidet die Prozessebene (Run-Book Automation) von der technischen Automation auf Client-, Server- und Netzebene. Für jeden dieser vier Bereiche gebe es Spezialwerkzeuge, weshalb vor der Tool- beziehungsweise Herstellerauswahl ganz andere Fragen gestellt werden sollten. So zum Beispiel die nach den sich ständig wiederholenden Tätigkeiten in der IT, die überflüssigerweise von hochqualifizierten und teuren Fachkräften geleistet würden. Aufgrund der Personal- und Kostenbindung könnten viele neue Projekte und Anforderungen von den Unternehmen nicht angegangen werden. Ebenso sei eine Analyse der IT-Prozesse auf ihre Kosten, Fehlerhäufigkeit und Geschwindigkeit geboten, um etwa durch Automation eine höhere Kundenzufriedenheit, Performance und damit einen besseren Return on Investment zu erreichen.

Goldgräberstimmung versperrt den Blick

Auf Seiten der Anbieter herrsche bei der IT-Automation derzeit eine Art Goldgräberstimmung. Zu wenig wird dem Materna-Mann zufolge hinterfragt, was ein Kunde konkret erreichen will. Hinzu komme eine zum Teil unglückliche Namensgebung, die bei manchen Tools dazu verleiten könne, in ihnen Universalwerkzeuge zu vermuten. Anwender sollten sich deshalb nach einer detaillierten Analyse ihres Bedarfs genau kundig machen, in welchem der vier Automatisierungsbereiche ein Hersteller aktiv sei. Zwar ließen sich die meisten Werkzeuge so konfigurieren, dass sie auch benachbarte Automatisierungsaspekte berücksichtigten, aufgrund des hohen Aufwands werde dabei aber oft der ursprünglich angestrebte Nutzen verfehlt.

Ein Problem sei beispielsweise der Bruch zwischen dem Service-orientierten Run-Book und der technischen Automation von Client, Server und Netz. Die technische Automation setzt eine detaillierte Kenntnis der eingesetzten Infrastruktur voraus. Ob man Letztere mit techniknahen Werkzeugen automatisiert oder mit deutlich höherem Aufwand über eine Run-Book Automation, hängt von der Komplexität ab und ist letztlich eine Kosten-Nutzen-Frage, so Staub.

Auf der nächsten Seite beschreibt IBM drei Automatisierungshürden, die in der Praxis immer wieder anzutreffen sind.

Drei Hürden sind zu nehmen

Ferner empfiehlt Materna, im Vorfeld einer Tool-Entscheidung abzuklären, wo in der IT eines Unternehmens ohnehin schon automatisiert wird. Unterstützt wird er darin von Holger Dörnemann, Manager bei IBM Systems & Service Management. Der gelernte Informatiker weiß aus der Praxis, wie gerne ein ITler ein paar Handgriffe per Skript automatisiert. Schlimmstenfalls droht hier Wildwuchs, zumindest werden aber die mit jedem Release-Wechsel der Software notwendigen Skript-Anpassungen immer aufwendiger. Bedeutet es schon eine gewisse Schnittstellen-Arbeit, wenn man die ITSM-Werkzeuge unterschiedlicher Hersteller koppeln will, so wird ein Automatisierungsprojekt laut Dörnemann erst richtig komplex, wenn dann auch noch solche Eigenentwicklungen eingebunden statt abgelöst werden sollen.

Holger Dörnemann, IBM.
Foto: IBM

Für den IBM-Mann gibt es zwei weitere Gründe, weshalb in Deutschland immer noch relativ wenig prozessorientiert automatisiert wird: auf technischer Seite die mangelnde Standardisierung und auf organisatorischer ein allzu ausgeprägtes Bereichsdenken. Bei der Standardisierung gehe es darum, diejenigen Produkte in einem Unternehmen herauszufinden, die innerhalb einer Systemgattung nur vereinzelt vorkommen, dafür aber einen unverhältnismäßig hohen Administrationsaufwand erfordern. Dies gilt für alle technischen Komponenten. "Wer nicht standardisiert und glaubt, Automatisierung werde es schon richten, läuft große Gefahr zu scheitern. Ziel muss es sein, auf der technischen Seite die Variantenvielfalt einzudämmen", so Dörnemann.

Im organisatorischen Bereich beklagt der Manager den oft komplexen Abstimmungsbedarf. Wenn die Netz-, Server- und Client-Verwaltung in den Händen einzelner IT-Spezialisten beziehungsweise IT-Abteilungen liegt, dann wird es schwierig, diese für ein prozessübergreifendes Automatisierungsprojekt zusammenzubringen. Es kommt zwangsläufig zu Interessenkonflikten, denn unterschwellig spielt auch immer der Gedanke an Rationalisierung mit. Selbst in Unternehmen, die sich an Itil beziehungsweise Service-Management ausgerichtet haben, gebe es trotz definierter Standardprozesse oft noch zu viele Übergabestellen. Dörnemann: "Der Service steht im Vordergrund, nicht die Abteilungsgrenzen. Da muss etwas passieren."

Auf der nächsten Seite lesen Sie eine Kurzcharakteristik wichtiger Hersteller und ihrer Werkzeuge für IT-Service-Management.

Gartner definiert Automation

In ihrem Research Paper "Automation: A Taxonomy" vom August 2009 unterscheiden die Analysten von Gartner zwischen vier Varianten der Automation:

  • Passive/analytische Automation untermauert Entscheidungsprozesse durch passive Datensammlung und Auswertung.

  • Prozessbasierende Automation automatisiert den Workflow von Tasks und Prozessen.

  • Aktive Automation beinhaltet neben Datentransfers auch die Veränderungen verwalteter Objekte (Status, Laufzeitverhalten etc.).

  • Run-Book Automation integriert die drei zuvor genannten Automationsansätze zu einer Einheit.

Hersteller im Überblick

Nachdem die etablierten "Big Four" unter den ITSM-Herstellern - BMC, CA, HP, IBM - ihr Portfolio über Akquisitionen vor allem im Hinblick auf Automatisierung komplettiert haben, schicken sich nun zwei weitere Branchenriesen an, in diesem Markt mitzumischen: EMC und Microsoft. Dennoch bleibt für Drittanbieter reichlich Platz.

Da es kein "Schweizer Messer" für die Automatisierung der Service- und Komponentenebene gibt, lohnt sich im Vorfeld der Tool-Auswahl eine Analyse der jeweiligen Angebote. Hier eine kurze Beschreibung der Offerten:

Die altbekannten Großen

Die neuen Großen

Drittanbieter

Auch wenn sich die Global Player der Spezialisten bedient haben, um ihre ITSM-Suiten zu vervollständigen, bietet das Thema noch reichlich Platz für Drittanbieter, wie die folgenden zwei Beispiele zeigen.