Monitoring im IT-Service-Management
Mehr Kontrolle für das ITSM
Wenn die IT-Abteilung davorsteht, sich von einem "Cost Center" zu einem "Profit Center" zu wandeln, dann spielt IT-Service-Management (ITSM) eine große Rolle in den täglichen Arbeitsabläufen. Hilfe auf dem Weg hin zu einer Service-orientierten "ITSM-Abteilung" kommt von ITIL (IT Infrastructure Library) mit Best-Practice-Empfehlungen, welche Prozesse in der IT sinnvoll sind. Wichtig für ein effizientes ITSM ist auch ein konsequentes Monitoring der IT. Dieser Beitrag gibt einen ersten Einblick in die grundlegenden Fragen, die bei der Einführung eines ITSM-orientierten Monitorings zu beachten sind, und zeigt, an welchen Stellen Probleme auftreten könnten.Neben einer vollständigen und hoffentlich aktuellen IT-Dokumentation und den manuell erstellten Anwender-Tickets im Helpdesk-System sollte das Monitoring Informationen automatisiert an den Helpdesk und gleichzeitig an eine weitere Stelle übergeben. Ziel ist es, anhand der definierten Services, der Service Level Agreements (SLAs) und der korrelierten Ereignisse zu vermeiden, dass unnötige Eskalationen erstellt und unnötige E-Mails verschickt werden. Rückmeldungen vom Service-Desk an das Monitoring sollten automatisiert oder manuell möglich sein. Datenqualität Grundsätzlich sollte bekannt sein, welche Informationen das Monitoring liefern soll, damit man den nachfolgenden Prozess oder die nachfolgenden Prozesse mit gehaltvollen Daten versorgen und aussagekräftige Reports erstellen kann. Will die IT-Organisation die Fachabteilungen in den Prozess integrieren und über das Monitoring mit Informationen versorgen, muss sie auch hier darauf achten, genügend aussagekräftige Daten zu sammeln. Dazu gehören vor allem CI-spezifische (Configuration Item), Service-, SLA- und Monitoring-spezifische Informationen. Entweder sind einige dieser Informationen manuell im System hinterlegt oder die vorgeschaltete CMDB (Configuration-Management Database) liefert sie, wenn möglich zyklisch. Von Vorteil ist hier ein Web-Service, der als Schnittstelle dient und konfigurierbar ist. Falls die Informationen im Überwachungssystem nicht hinterlegt sind oder keine CMDB vonnöten oder vorhanden ist, dann ist es auch möglich, sie im Service-Desk vorrätig zu halten. Dies entspricht zwar nicht den Vorgaben von ITIL, aber bekanntlich führen viele Wege nach Rom. Sizing Neben den Schnittstellen ist das Sizing eines Monitoring-Systems ein wichtiger Aspekt. Schließlich sollen die Informationen möglichst zeitnah, möglichst sogar in Echtzeit, beim Service-Desk landen. Deshalb ist eine genaue Planung der Monitoring-Landschaft sehr wichtig: Wie viele Systeme sollen mit wie vielen und welchen Services überwacht werden? Wie tiefgreifend will man überwachen? Überwache ich neben den spezifischen Details des Betriebssystems auch Applikationen? Sind Satellitensysteme erforderlich? Bei intensiver Datenbewegung ist I/O maßgeblich, dafür sind schnelle Platten Voraussetzung. Um Berichte zu erstellen, sollte man auch dabei an ein wenig mehr CPU denken. Weitere Fragen sind: Komme ich an alle Systeme einfach heran? Benötige ich unterschiedliche LDAP-Anbindungen, Rollen, Rechte etc.? Welche Datenbank ist vorhanden oder benötigt? Gibt es vom Hersteller eine Formel für das Sizing des Systems? Bedienbarkeit Nicht zu unterschätzen ist auch die Bedienbarkeit des Systems, schließlich soll es angenehm zu bedienen sein und möglichst viele Anforderungen abdecken. Folgende Fragen sollte man sich dabei stellen: Wie schnell wächst die IT-Landschaft, und wie schnell kann ich die neuen Systeme in das Monitoring einbinden (zum Beispiel mittels Templates)? Reicht eine "Quick and Dirty"-Lösung oder benötige ich mehr Flexibilität, mögliche Erweiterungen oder sogar eine mittel- oder langfristige Planung? Kann die eigene Entwicklungsabteilung zu Erweiterungen beitragen? Lassen sich Systeme in Services abbilden und die Ereignisse miteinander vernetzen? Am besten ist es, mit der Überwachung der wichtigsten Services und den verbundenen Services zu beginnen und von dort in die Tiefe zu gehen. Je mehr Informationen man über die Services erhält, umso aussagekräftiger lassen sich Fragen von Anwendern beantworten und kurz- und langfristige Ressourcenplanungen durchführen. Danach kann man die weniger priorisierten Services schrittweise in das System einbinden. So überfordert man auch nicht die Service-Desk-Kollegen mit neuen Hinweisen und Vorgehensweisen bei den Verfahren mit dem Incident-, Problem- und Change-Management.
Lesen Sie mehr zum Thema
