Seite 2 - Anwenderbericht: Dokumentation und Servicemanagement bei der QSC AG

Lesezeit
2 Minuten
Bis jetzt gelesen

Seite 2 - Anwenderbericht: Dokumentation und Servicemanagement bei der QSC AG

11.01.2012 - 13:00
Veröffentlicht in:
Wartung und Pflege von IT ist perfekt planbar
Heute arbeitet das Werkzeug reibungslos und unterstützt die Service- und Betriebs-Teams bei der Planung von Wartungsfenstern, bei Deployments oder Rollouts. So gibt es bei QSC beispielsweise den Prozess "Release- und Deployment-Management". In dessen Ablauf lassen sich unter anderem alle Arten von Wartungsfenstern mit Hilfe von i-doit sowohl gut planen, als auch einfach und schnell abwickeln. Heinemann dazu: "In jedem dieser Fälle ist die Analyse dessen, welche Auswirkungen die Wartungen auf die Verfügbarkeit der Business Services haben, innerhalb der CMDB Pflicht, weil wir die Betroffenen ja informieren müssen. Und bei den Mitteilungen gilt der Grundsatz: den Verteilerkreis so groß wie nötig und so klein wie möglich! Da leistet uns die CMDB als gute Planungsgrundlage wertvolle Unterstützung."

Des Weiteren hat QSC mit dem Werkzeug auch einige Prozesse neu aufgesetzt, unter anderem den "Configuration-Management-Prozess". Damit ist der IT-Betrieb nicht nur besser gewartet und gepflegt, sondern die IT lässt sich insgesamt besser planen und strukturieren. Für die Verantwortlichen ist die CMDB damit auch der Einstieg in ITIL. So ist für die Zukunft geplant, Serviceprozesse und weitere Dinge rund um i-doit aufbauen.


Bild 2: Besonders viel Wert legt die QSC AG auf die in i-doit implementierte Abbildung der Cluster-Vitalität

Störungsmeldung inklusive betroffene Komponenten und Anwender
Die CMDB ist neben der proaktiven Wartungsfenster-Nutzung auch bei jeder Art von Störung die zentrale Anlaufstelle, um reaktiv nachzusehen, wo der gemeldete Fehler stecken könnte. Denn Besonderheit bei der Modellierung der Lösung ist, dass darin festgehalten wurde, wie die Anwender  überhaupt beispielsweise auf E-Mail zugreifen, also mobil, im LAN der QSC oder über VPN im Home Office. Ebenfalls ist dargestellt, welche Nutzergruppen in welcher Form auf E-Mail zugreifen, wer also bei einer Störung möglicherweise mit betroffen ist. Somit nutzt der Mitarbeiter im Service Desk die CMDB und dort insbesondere die grafische Darstellung über den CMDB Explorer, um dem Melder die richtigen Fragen zu stellen. Damit kann sich der Service Desk wesentlich gezielter und schneller an die Problemlösung machen.

Demnach wird die CMDB also zur Auswirkungsanalyse (Auf welche Weise wirken sich Wartungsarbeiten auf die Business Services aus?), zur Ursachenanalyse (Wo liegt der gemeldete Fehler?) und für die Planung von IT-Services (Wie stellen wir die Infrastrukturelemente zusammen, um IT-Services neu, besser oder effizienter zu erbringen?) genutzt. Darüber hinaus kommt die Planbarkeit mittels der CMDB auch für die Verschlankung der Wartungsprozesse zum Einsatz. Das Unternehmen konnte Wartungsfenster zusammenlegen, redundante Tätigkeiten vermeiden oder doppelte Wege reduzieren. Zudem lässt sich einfach feststellen, welche Wartungsthemen artverwandt sind und sich bündeln lassen. Durch die Dokumentation von Abhängigkeiten werden sich gegenseitig ausschließende Tätigkeiten erkannt und mögliche Folgefehler und Störungen vermieden.

Integration von Netzmanagement- und Ticketing-Informationen
Wenn das ebenfalls im Unternehmen zum Einsatz kommende freie Monitoring-Tool Nagios einen Serverausfall meldet, hat die QSC-IT prinzipiell die Möglichkeit, innerhalb der CMDB mit dieser Information zu sehen, welcher Business Service davon betroffen ist. Diese Verknüpfung ist bis dato zwar nicht realisiert, statt dessen ist allerdings bereits der Nagios-Link zu einem Serversystem in i-doit hinterlegt. Damit kann ein Admin oder Helpdesk-Mitarbeiter sich durchklicken und den Status des Servers in Nagios sehen.

Die automatische Anzeige des aktuellen Status eines solchen Configuration Items in der CMDB wurde deshalb nicht umgesetzt, weil der aktuelle Live-Status nicht zur Konfiguration gehört, sondern das fehlerfreie Normalbild darstellen soll. Für QSC soll die CMDB keine Live-Stati liefern, sondern eine Darstellung dessen, wie die Infrastruktur sein muss, wenn alles in Ordnung ist. Was Heinemann zufolge im nächsten Integrationsschritt allerdings unbedingt hinzukommen soll, ist das Trouble Ticketing. Hier hatte QSC unter der Vorgänger-CMDB bereits eine Zusammenschaltung mit einem freien Ticketing-Tool und möchte diese Verbindung auch in der neuen Konstellation haben.

Fazit: Professionalisierung des IT-Betriebs
Das Resümee in Bezug auf den Nutzen der Software fällt nach den Worten von Heinemann ebenso nüchtern wie positiv aus: "Es gibt keine Einsparungen von Kosten - das kann man mit einer CMDB generell nicht erreichen. Vielmehr können wir eine deutliche Service-Verbesserung registrieren, unsere Kunden besser bedienen, haben weniger Reklamationen, können Störungen schneller und effizienter beseitigen und erhalten insgesamt einen stabileren Betrieb. i-doit hat uns zu einem professionelleren IT-Betrieb verholfen."

In Bezug auf zu erwartende Trends bei CMDB und ITSM gibt Heinemann zu bedenken, dass IT in Zukunft nur noch dann erfolgreich sein kann, wenn sie das Wissen der Mitarbeiter so gut wie möglich transparent macht. Hier könne eine CMDB wertvolle Unterstützung leisten, weil sie Wissen aus Köpfen in Systeme transferiere und für alle verfügbar mache. Zudem werde das Cloud Computing ganz neue Anforderungen an die IT und ihre Dokumentation stellen.


         <<Vorherige Seite                          Seite 2 von 2





Konrad Buck/ln

Ähnliche Beiträge

Netzwerkverwaltung an der Medizinischen Universität Wien

Die IT-Abteilung der Medizinischen Universität Wien betreibt das Netzwerk der Universität, wozu die Betreuung von rund 10.000 Anschlüssen sowie Hunderten Endgeräten und Servern gehört. Für diese Aufgabe wurde eine neue Informations- und Planungssoftware für Kabelmanagement und Netzwerkdokumentation implementiert. Das neue Werkzeug ist flexibel, skalierbar und deckt die steigenden Sicherheitsanforderungen voll ab.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (2)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.