IT-Kosten senken durch Anwendungsüberwachung und Netzwerkmanagement

Transkript

1 IT-Kosten senken durch Anwendungsüberwachung und Netzwerkmanagement Zusammenfassung: Im Zeitalter des schnellen Wechsels und des starken Konkurrenzdruckes auf den Weltmärkten müssen die IT-Abteilungen Infrastrukturen bereitstellen, die es dem Unternehmen ermöglichen, flexibel auf die Anforderungen zu reagieren. Immer mehr IT- Abteilungen greifen wegen des dabei herrschenden enormen Kostendruckes zu Netzwerkmanagementtools, um die Qualität der bereitgestellten Dienste über die Zeit zu erfassen und entsprechendes Einsparpotenzial zu ermitteln. In diesem Artikel wird ein Vorgehensmodell für die Einführung eines Netzwerkmanagementtools beschrieben und Hinweise auf Stolpersteine im Laufe des Einführungsprozesses gegeben. Stichworte: Netzwerkmanagement, Anwendungsmanagement, Reporting, Datenhistorie, Überwachung, Analyse, Netzwerk HBT GmbH Hamburg 1 Einleitung Netz- und Anwendungsüberwachung Bestandsaufnahme des aktuellen Service Level Service Level Definition Service Level Monitoring Justierung des Service Level Fazit Autor: Dr. Dietmar Fiehn Seite 1

2 1 Einleitung Netzwerk- und Anwendungsmanagement wird oft als die Möglichkeit zur Einsparung von Kosten im IT-Betrieb gesehen. In Zeiten knapper finanzieller Mittel ist die Verlockung daher groß, mit der Investition in ein entsprechendes Tool zumindest mittelfristig die Betriebskosten im Rechenzentrum zu senken. Leider ist es mit dem Kauf eines Tools nicht getan. In jedem Fall ist für das Erreichen nachhaltiger und wesentlicher Spareffekte eine grundlegende Situationanalsyse erforderlich: 1. Was ist das Ziel? Im Allgemeinen sollen die Kosten des IT- Betriebes bei gleicher Qualität gesenkt werden. Andere Ziele wie die Erhöhung der Zuverlässigkeit, Schaffung einer Grundlage für Migrationen etc. sind ebenfalls hinreichend für die Einführung von Netzwerkmanagementsoftware. 2. Welche Parameter stehen zur Kostenreduktion zur Verfügung? In den meisten Fällen ist dies eine Einsparung von Servicezeit (d.h. Personalkosten) des Rechenzentrums für die Betreuung von Anwendungen, des Netzes, der Kunden / inhouse User. Möglich ist aber auch, durch Anpassung von Verträgen zum Einkauf von IT-Leistungen bei Dritten die Betriebskosten zu senken. 3. Welche Betriebsparameter sind signifikant zur Bestimmung der "Qualität" der IT-Dienstleistung? Klassische Werte sind: o Verfügbarkeit und Verlässlichkeit eines Dienstes o Antwortzeit für eine Transaktion X bei Dienst Y o Datendurchsatz eines Netzwerkabschnittes o Fehlererkennungs- und -behebungszeit o Häufigkeit von Fehlern Diese Daten sind auch wichtig zur Analyse von unspezifischen Fehlern: Das Netz ist heute aber wieder langsam. Man muss bei der Bestimmung der Betriebsparameter die Sicht der Beteiligten unterscheiden: Der Anwender sagt: Der Zugriff auf das Intranet muss bestimmten Kenngrößen entsprechen. Der Rechenzentrumsleiter muss daraus ALLE damit zusammenhängenden Dienste einbeziehen: Log-Server für Webserver-Logs, DNS für Namensauflösungen, Netzauslastung, geplante Downtimes zum Einspielen von Patches usw. Das Erheben von Daten über den Zustand von Systemen sollte ggf. mit dem Betriebsrat abgestimmt werden. Insbesondere, wenn die Gefahr besteht, dass personenbezogene Daten gesammelt werden oder zumindest der Anschein besteht. Autor: Dr. Dietmar Fiehn Seite 2

3 4. Wer ist für den Betrieb der betroffenen Komponenten verantwortlich?... und wie ist die Rollenaufteilung zwischen diesen Personen? 5. Welche Zuständigkeiten, Prozesse und Rollen innerhalb einer Abteilung und abteilungsübergreifend existieren? Die Stichworte aus ITIL sind hier Helpdesk, Incident-, Change- und Problemmanagement. In diesem Abschnitt werden aber auch die Zuständigkeiten von Personen für einzelne Prozessschritte erfasst und dokumentiert. Wurden diese Fragen beantwortet, sind das Ziel und die Stellparameter zur Erreichung des Ziels hinsichtlich der Änderungen an den Betriebsprozessen im Wesentlichen beschrieben. Diese Stellparameter müssen nun auf ihre Wirksamkeit und ihr Sparpotenzial abhängig von der konkreten Betriebsumgebung überprüft werden. Dieser Prozess kann nur individuell angepasst auf die jeweilige Situation durchgeführt werden. Beispiel für ein Ergebnis dieser Analyse ist die folgende Liste. Diese Liste ist NICHT repräsentativ und kann in anderen Szenarien auch anders ausfallen. 1. Helpdesk, Incident- und Problemmanagement (5.) Alle RZ-Mitarbeiter bieten First-, Second- und Third-Level-Support für Anwender 2. Zuständigkeiten nicht geklärt (5.) Die Fehleranalyse ist zeitaufwändig, da zurückliegende Änderungen dezentral entschieden, durchgeführt aber nicht dokumentiert werden (Change- Management). 3. Betriebsparameter nicht klar (3.) Die Fehleranalyse ist zeitaufwändig, da nicht genügend Informationen über den Zustand der Anwendungen und des Datennetzes vorliegen (Netz- und Anwendungsüberwachung). 4. Zuständigkeiten nicht geklärt (5.) Die täglichen Probleme durch eine (erkannte) strukturelle Schwäche des Netzes/der Anwendungen binden Ressourcen. Die Behebung der Strukturschwäche benötigt vorübergehend weitere Ressourcen ("Aktivierungsenergie" für Modernisierungsprojekte, Problem-Management). Zu sehen ist, dass viele Prozesse nicht klar strukturiert sind und somit die Abläufe nicht stringent, effizient und zielführend sind. Somit geht viel Zeit durch entstehende Reibungsenergie verloren, weil die Aufgaben nicht sauber getrennt sind. Möglicherweise sind die Abläufe auch implizit klar, jedoch ökonomisch nicht optimal. Wichtig am Ergebnis ist, dass die Einführung eines Netzwerkmanagementtools nicht isoliert betrachtet werden kann. Als ein Baustein des Netz- und Anwendungsmanagements kann es aber auch Grundlage für weitere Optimierungsschritte sein. Das Einführen eines Netzwerkmanagementtools ist nur ein Schritt von mehreren. Autor: Dr. Dietmar Fiehn Seite 3

4 Auf diesen Analyseprozess sollte in einem Projekt zur Optimierung des IT-Betriebes nicht verzichtet werden, um weiteres Optimierungspotenzial aufzudecken und gegebenenfalls mit zu nutzen. Die folgenden Seiten beschäftigen sich mit dem Prozess zur Einführung einer Netzund Anwendungsüberwachungssoftware. Die Aspekte des Managements hinsichtlich der aktiven Einstellung von Netzkomponenten, wie sie z.b. HP OpenView mitbringt, werden hier nicht betrachtet. 2 Netz- und Anwendungsüberwachung Der Begriff Netz- und Anwendungsüberwachung wird zur Zeit in vielen Veröffentlichungen verwendet. Bevor wir ihn selbst ebenfalls verwenden und die einzelnen Schritte für die erfolgreiche Installation einer Überwachungssoftware erläutern, geben wir eine Definition des Begriffes Netzwerkmanagement an, wie wir ihn verstehen: Das Netzwerkmanagement bildet die Voraussetzung für den Betrieb eines Netzes. Bedingt durch die Komplexität größerer Netze müssen diverse Kontroll- und Wegefunktionen mittels eines Netzwerkmanagement- Systems ausgeführt werden. Zu den Aufgaben des Netzwerkmanagements gehören daher u.a. das Sammeln von Informationen über die Nutzung des Netzes durch die angeschlossenen Stationen, die Erstellung von Berichten und Statistiken für die Planung, den Betrieb, den Ausfall und die Wartung, die Konfiguration des Netzes und damit verbundene Konfigurationsänderungen, die Leistungs-, Ereignis- und Fehlerüberwachung. In Verbindung mit der offenen Kommunikation legte die ISO fünf Funktionsbereiche für das Netzwerkmanagement fest: Fehler-Management (Fault), Leistungs-Management (Performance), Konfigurations-Management (Configuration), Abrechnungs-Management (Accounting) und Sicherheits- Management (Security). 1 Eine Netz- und Anwendungsüberwachung ist somit nur ein Bestandteil des Netzwerkmanagements. Sie enthält typischerweise nicht das Konfigurations-, Abrechnungs- und Sicherheitsmanagement Die Installation einer Netz- und Anwendungsüberwachungssoftware wird in folgende Schritte aufgeteilt: 1. Bestandsaufnahme des aktuellen Service Level 2. Service Level Definition 3. Service Level Monitoring 4. Justierung des Service Level Mit dem Begriff der Dienstgüte soll hier allgemein die durch Kennzahlen quantifizierte Qualität eines beliebigen Dienstes bezeichnet werden. 1 Quelle: Siemens Online Lexikon, siehe auch Kerner, H.: Rechnernetze nach OSI, guter Überblick auch in Arbeitspapiere WI Nr.3 von Schwickert, Uni Mainz. Autor: Dr. Dietmar Fiehn Seite 4

5 Je nach Projekt können die Schritte 1. und 2. entfallen, wenn entsprechende Ergebnisse bereits vorliegen. Ziel der Einrichtung eines Tools ist im Allgemeinen die Qualität des IT-Betriebes zu quantifizieren und zu dokumentieren. Letztendlich ist das natürlich nur die Vorraussetzung für das eigentliche Ziel: die Dienstleistung zu verkaufen oder Kosten für ihre Erbringung gezielt zu senken. 2.1 Bestandsaufnahme des aktuellen Service Level Vorraussetzung für die Bestandsaufnahmen der aktuell angebotenen Dienstgüte ist eine Liste von Geräten und den von ihnen erbrachten Diensten. Hilfreich ist, diese Liste baumartig zu führen, da man so leicht logische Abhängigkeiten modellieren kann. Mit dieser Liste kann ein geeignetes Überwachungstool parametriert werden, dass anhand der konkreten Anforderungen ausgesucht werden kann. Beide Vorgänge, das Aussuchen und das Parametrieren, kann je nach Tool und Komplexität der Liste zwischen Tagen und mehreren Wochen dauern, denn der Markt ist groß und die Unterschiede oftmals nur gering. Neben den Anforderungen aus der Liste der zu überwachenden Geräte und Dienste können Netz- und Anwendungsüberwachungssysteme auch sicherheitsrelevante Aufgaben übernehmen. Durch ihren Zugang zu den aktiven Netzkomponenten können z.b. neu angeschlossene und möglicherweise nicht authorisierte Geräte gemeldet werden. Eine weitere Entscheidungshilfe für die Auswahl eines Tools ist die Tabelle der Ü- berwachungstechniken mit ihren jeweiligen Eigenschaften (siehe Tabelle 1) Techniken Eigenschaften Überwachung des Netzverkehrs Überwachung von Systemparametern Clientseitige Anwendungsüberwachung durch simulierte Transaktion Clientseitige Anwendungsüberwachung durch GUIbasierte Lösungen Client/Serverseitige Anwendungsüberwachung durch Anwendungsinstrumentierung Client/Serverseitige Anwendungsüberwachung durch Anwendungsbeschreibung Dienstorientierte Parameter Tatsächlich erfahrener QoS Detailreiche Information Allgemein anwendbar Geringer Aufwand Echtzeitüberwachung O O O + ++ O O O O O Tabelle 1: Techniken der Überwachung und ihre Eigenschaften Autor: Dr. Dietmar Fiehn Seite 5

6 Typischerweise erfolgt die Auswahl nun anhand einer individuell erstellten Score- Card, die Fragen zu dem Tool stellt, die mit ja / nein oder mit einer Scala zwischen 0 und 10 zu beantworten ist (siehe kurzes Beispiel in Tabelle 2). Diese Score-Card kann ergänzt werden um eine Spalte mit den geforderten Mindestpunkten für eine bestimmte Zeile. Nr Merkmal Checkpunkt Bewertung (1-10) 1 Bedienbarkeit a) Kontextsensitive Hilfe 25 b) Erwartungskonforme Menustruktur 25 c) Erwartungskonforme Bezeichnungen 25 d) Übersichtliche Masken 25 2 Zukunftssicherheit a) Strategie des Toolherstellers 20 b) Verbreitungsgrad 5 c) Schnittstellen 20 d) Erweiterbarkeit 15 e) XYZ-Anwendung wird unterstützt 20 f) Netztopologie wird überwacht 15 g) Referenzen 5 3 Reports a) Optischer Eindruck 20 b) Informationsgehalt 20 c) Parametrierbarkeit (Zeitachse, Inhalt) 10 d) Konfigurierbarkeit 10 e) Interpretation 20 f) Einbindung in Workflows 15 g) Automatisierbarkeit 5 4 Konfigurierbarkeit a) Logische Abhängigkeiten 15 b) Indiv. Zusammenstellen einer Übersicht 20 c) Alarmierungspfade getrennt von Priorität 10 d) Kombination von Messungen für Alarm 5 e) Beobachterpositionen wechselbar 10 f) Übliche Werte bei Überwachungen 20 g) Speichern indiv. Einstellungen 20 5 Sonstiges a) Pressestimmen 20 Ergebnis b) Konform zu internen Bestimmungen 30 c) Strategische Bedeutung des Tools und des Toolherstellers im eigenen Portfolio Gewicht Ergebnis Tabelle 2: Ausschnitt einer Score-Card zur Bewertung von Überwachungstools Wichtig ist, dass diese Score-Card von mehreren Personen, optimalerweise von allen, die mit diesem Tool arbeiten müssen, ausgefüllt werden. Dies kann auch abschnittweise geschehen, also die Abteilung, welche die Reports des Tools auswertet, beantwortet die Frage zu den Reports, die Fragen zur Bedienbarkeit werden von einer Gruppe B beantwortet. Das Ergebnis wird nun jeweils gewichtet und am Ende 50 Autor: Dr. Dietmar Fiehn Seite 6

7 steht eine Bewertung, die ein Ranking der Tools zulässt und Grundlage für eine Entscheidung sein kann. Richten Sie nun nach Kauf und Installation des ausgewählten Tools die Überwachungen ein, z.b. folgende: Prozessorlast Abweichung der Systemzeit zur Firmen-Standardzeit Inhalte, Größe, Zugriffsrechte, Eigentümer, Änderungszeitpunkt von Dateien und ggf. von Verzeichnissen Festplattenplatz Funktion des Domain-Name-Server Funktion eines FTP-Servers Funktion eines HTTP-Servers Funktion eines Mail-Servers Funktion eines Datenbank-Servers Funktion eines Application-Servers Erreichbarkeit im Netz über PING Protokollierung einer SNMP-Variablen Angemeldete Systeme in Ihrem Netzwerk Nutzung von Ethernet-Redundanzen (Spanning Tree Protokoll) Traffic-Auslastung eines Netzabschnittes Temperatur im Serverraum / Serverschrank Offenzeiten sicherheitsrelevanter Türen Weitere... Einmal eingerichtet, sammelt dieses Tool nun die Informationen, die zur Festschreibung des Ist-Zustandes der angebotenen Dienstgüte benötigt werden. 2.2 Service Level Definition Liegen zu einem Zeitpunkt die gesammelten Daten eines hinreichend langen Zeitraumes ausgewertet in Form von Reports vor, kann nun aus dem Ist-Zustand auf den Soll-Zustand geschlossen werden. Alternativ, wenn keine Datensammlung gemäß Schritt 1. durchgeführt wurde, kann ein Soll-Zustand festgelegt werden, der aus der Erfahrung des Rechenzentrumsleiters abgeleitet wurde. Dies ist als Startpunkt einer iterativen Festlegung des Service-Levels zulässig, wenn keine geschäftsrelevanten Dienste quantitativ erfasst werden. Von Schätzungen über die Mindest- oder Soll- Qualität von Diensten, die das Kerngeschäft eines Unternehmens betreffen, sollte Abstand genommen werden. Die Güte dieser Dienste sollte unbedingt mit einem verlässlichen Messwerkzeug über eine Zeitspanne ermittelt und dokumentiert werden, um zuverlässige Aussagen treffen zu können. Beim Festlegen der Dienstgüte sollte auf die unterschiedliche Sichtweisen geachtet werden: Der Dienstleister wird intern im allgemeinen eine deutlich feinere Aufteilung vornehmen, als er extern vermittelt. Für seinen Kunden ist es auch unerheblich, welchen internen technischen Aufwand der Anbieter treiben muss, um den -Dienst mit einer Zuverlässigkeit von 99.99% anzubieten. Autor: Dr. Dietmar Fiehn Seite 7

8 Beim Beschreiben der Zuverlässigkeit gibt es u. a. folgende Parameter: 1) Anzahl der Ausfälle pro Zeiteinheit (max. und Durchschnitt) 2) Dauer der Ausfälle (max. und Durchschnitt) 3) Antwortzeit für eine Transaktion (max. und Durchschnitt) 4) Prozentualer und absoluter Anteil der Benutzer, die im vereinbarten Bereich der Dienstgüte arbeiten können (min. und Durchschnitt) 5) Abhängigkeiten von Tageszeit, Wochentag, Feiertag 6) Übergabepunkt der Dienstleistung Beim quantitativen Beschreiben einer Dienstgüte muss beachtet werden, dass viele Anwender eher etwas wie die gefühlte Qualität eines Dienstes ausdrücken können als konkrete Zahlen (siehe Abbildung 1). Auch wenn diese vorliegen, kann es sein, dass der Wunsch nach einer Verbesserung nicht konkretisiert werden kann. Während einer Verhandlung über die Soll-Qualität einer Dienstleistung muss dies berücksichtigt werden. Keinesfalls darf diese unpräzise und nicht messbare Beschreibung jedoch stehen bleiben. Entweder der Dienstleister oder der Kunde muss einen konkreten Vorschlag machen, der wie oben beschrieben, dann Ausgangspunkt für eine iterative Anpassung ist. Abbildung 1: Service-Qualität Modell Bei der quantitativen Festlegung der Dienstgüte darf die Beschreibung der Konsequenzen nicht fehlen: Was passiert, wenn die Vereinbarungen nicht eingehalten Autor: Dr. Dietmar Fiehn Seite 8

9 werden? Hier bietet der Gesetzgeber noch wenig Hilfreiches, so kann bei 100%er Nichterfüllung des Vertrages auch nur 100% des Entgeldes einbehalten werden, was jedoch bei Weitem nicht dem Schaden entspricht, den der Kunde hat. Die Bandbreite, wann der Vertrag als nicht erfüllt gilt, ist in der Praxis deutlich geringer, die konkrete Ausprägung ist Verhandlungssache. So ist es bei einer praktischen Verfügbarkeit von 98% bei vereinbarten 99.99% durchaus angemessen wesentliche Teile des Entgeldes einzubehalten. Dies ist Verhandlungssache und kann in beiderseitigem Einvernehmen frei festgelegt werden. Mit dieser formalen Beschreibung der angebotenen Dienstgüte (Service Level) kann nun verhandelt werden: Welchen finanziellen Aufwand bedeuten Steigerungen in der Verarbeitungsgeschwindigkeit? Was muss in eine Erhöhung der Zuverlässigkeit investiert werden? Alles Kennzahlen sind dokumentiert, jetzt können z.b. Ausfälle und schwache Server als Bottleneck erkannt und gezielt verstärkt werden. 2.3 Service Level Monitoring Der Anbieter der Dienstleistung hat mit der Schließung eines Vertrages, eines Service Level Agreements, den Auftrag erhalten, eine bestimmte Dienstgüte bereit zu stellen. Ein Bestandteil des Vertrages ist der sogenannte Gefahrenübergang, der aussagt, ab welcher Stelle z.b. des Datennetzes der Kunde die Dienstleistung annimmt und die an dieser Stelle erbrachte Leistung akzeptiert oder eben ablehnt. Der weitere Transport innerhalb des Kundennetzes obliegt dann der Verantwortung des Kunden. Diese Trennung gilt natürlich nur für externe Dienstleister, interne sind im Allgemeinen für die Erbringung der Dienste bis zum Abnehmer, also die Arbeitsplätze der Mitarbeiter zuständig. Der Anbieter der Dienstleistung ist aus zweierlei Gründen an der Überwachung seiner Dienste interessiert: Zum einen möchte er selbst wissen, welche Qualität seine Dienste aktuell und zu einem bestimmten Zeitpunkt in der Vergangenheit haben, zum anderen ist es üblich, dass der Diensteanbieter dem Kunden zum Monats- oder Quartalsende einen Report erstellt, aus dem die gelieferte Dienstequalität ersichtlich ist. Sinnvoll ist es, wenn der Kunde ebenfalls ein Werkzeug hat, mit dem er die Aussagen des Anbieters verifizieren kann. Hier bieten sich kleine und schlanke Tools an, die keinen Overhead hinsichtlich eines System-Managements mit sich bringen. Abbildung 2: Überwachungsergebnis außerhalb der erlaubten Schranken Die Einrichtung eines Überwachungstools ist leider nur die eine Seite der Überwachung der Dienstgüte beim Betrieb. Die andere Seite ist festzulegen, was passiert, wenn die Dienstgüte außerhalb der zulässigen Schranken liegt, wobei an dieser Stelle nicht die juristischen Folgen, sondern die internen Schritte zur Behebung des Schadens gemeint sind. Verletzte Schranken können alle Dienstgüteparameter sein, die vereinbart wurden: Zu viele Benutzer oberhalb der mittleren Antwortzeit, Transaktionszeit zu hoch, Daten- Autor: Dr. Dietmar Fiehn Seite 9

10 durchsatz zu gering, usw. Es können aber auch Betriebsparameter sein, die gar nicht in dem Vertrag enthalten sind, jedoch Vorraussetzung für einen fehlerfreien Betrieb sind. Solche Parameter sind zum Beispiel die Temperatur im einem Serverschrank, oder die Anzahl der wartenden Prozesse auf einem Server. Schon bei der Messung oder spätestens jetzt, bei der Überwachung der Dienstgüte müssen Geschäftsprozesse z.b. für die Eskalation von Problemen geschaffen werden: Welche Personen bekommen zu welchen Zeiten mit welcher Dringlichkeit und welchem Benachrichtigungskanal und welcher geforderten Reaktionszeit welche Meldung zugestellt? Was sind die dann erforderlichen Schritte? Viele Fragen können aus dem Service-Level-Agreement abgeleitet werden: Die Dringlichkeit, die Zeiträume, in denen Meldungen über drohende oder bereits eingetretene SLA-Verletzungen zugestellt werden, usw. Wichtig ist, dass diese Prozesse explizit geschaffen oder in Form einer Prozessbeschreibung festgehalten werden, denn nur so lassen sich nicht abgedeckte Zeiträume oder Tätigkeiten erfassen, dokumentieren und die Lücken schließen. 2.4 Justierung des Service Level Der Dienstleister kann auf neue Herausforderungen durch veränderte Rahmenbedingungen z.b. bei der Anforderung neuer Dienstleistungen durch den Kunden, eingehen, indem er den beschriebenen Prozess nicht einmal sondern immer wieder durchläuft. Hilfreich ist die regelmäßige Überprüfung (monatlich oder zum Ende eines viertel Jahres), ob die eingerichtete Konfiguration im Überwachungstool noch der Wirklichkeit entspricht. Nachlässigkeit in der Pflege des Überwachungstools ist ähnlich gefährlich, wie Autofahren ohne Versicherung: Alles ist in Ordnung, bis es irgendwo ein Problemchen gibt, dass sich durch diese Nachlässigkeit als ein ausgewachsenes Problem herausstellen kann. Das Überwachungstool ist eine Lebensversicherung, deren Prämien regelmäßig gezahlt werden müssen, damit sie im Ernstfall helfen kann. Die Pflege des Überwachungstools sollte daher "Chefsache" mit Priorität 1 sein. Alle Änderungen und turnusmäßigen Überprüfungen in den Einstellungen sollten darüber hinaus protokolliert werden, sofern es Ihr Tool nicht für sie macht. So können übrigens auch mögliche Seiteneffekte durch die Überwachung anhand eines zeitlichen Zusammenhanges festgestellt werden. Ebenfalls turnusmäßig sollte eine automatische Prüfung der Konfiguration auf Vollständigkeit erfolgen: Sind alle Server erfasst? Gibt es irgendwo Geräte im Netz, die Dienste anbieten, die nicht autorisiert sind? Diese Fragen zielen auch in die Richtung einer Inventarisierung der Dienste und Geräte, müssen aber nur in offenen Netzen gestellt werden, in denen Benutzer entsprechende Freiheiten haben. 2.5 Fazit Das Einführen eines Netz- und Anwendungsüberwachungstools ist nicht durch den Kauf eines Tools getan, schon gar nicht durch den Kauf eines Tools, dass jeder in der Branche hat. Bei allem Respekt zu Best-Practice Reports von Marktforschungs- Autor: Dr. Dietmar Fiehn Seite 10

11 unternehmen, sollte man sich fragen, ob eines der anderen erwähnten Tools in dem Report nicht auf einen selbst doch besser passt. Wichtiger als das Aufspringen auf den Mainstream ist, dass die eigenen Bedürfnisse wirtschaftlich abgedeckt werden. Wenn dass nicht der Fall ist, oder das installierte Tool unpassend zur gewohnten Arbeitsweise ist, ist es sehr wahrscheinlich, dass nach dem anfänglichen Enthusiasmus die oben empfohlenen Pflegehinweise langsam aber stetig zurückgefahren werden. Die Eingangsfrage, die hier diskutiert wurde, lautete Wie kann man mit der Installation einer Netz- und Anwendungsüberwachung Geld sparen? Die Antwort lautet erwartungsgemäß Ja und zwar aus folgenden Gründen: 1. Die Auslastungen von Geräten und Leitungen ist genau bekannt. Investitionen in Hardware können so gezielt eingesetzt werden, um die wirklichen Bottlenecks zu beheben. Das Stichwort lautet Right-Sizing von Hardware statt Gießkannenprinzip 2. Zugekaufte Dienstleistungen können durch das Wissen über deren tatsächlicher Nutzung knapper ausgelegt werden und sind somit preisgünstiger. 3. Durch genaues Wissen über die einzelnen Systeme und ihrem Zustand können Fehler effizienter behoben werden. Neben der Einhaltung vereinbarter Service Level verbessert dies das Image des Anbieters und bildet eine solide Vertrauensbasis mit dem Kunden. 4. Über die genaue Protokollierung der Dienstgüten und der Spezifikation eines Service Levels können bei Störungen der für das Kerngeschäft relevanten IT- Dienste Servicearbeiten gezielt priorisiert werden. Die Servicemannschaft kann kleiner ausfallen, als bei einer nicht priorisierbaren Störungsbehebung. Ein gutes Beispiel für eine gezielte Kostenreduktion, die auf Grundlage der Messungen eines entsprechend parametrierten Überwachungstools möglich ist, ist die gezielte Bremsung und Priorisierung von IP-Verkehr auf den Datenleitungen (Traffic- Shaping). So lassen sich unternehmenskritische Anwendungen auf einer ausgelasteten Datenleitung priorisieren und weniger wichtige Anwendungen, die auch eine geringere Bandbreite verkraften, zurückdrängen. So können tarifierte Übertragungsvolumen eingehalten oder anstehende Bandbreiten- oder Trafficerweiterungen wirtschaftlich justiert werden. Technisch handelt es sich beim Traffic-Shaping um eine Parametrisierung von Protokollen zur Bestimmung des Übertragungsverhaltens für bestimmte Dienste. Router der neueren Generation verfügen oft schon über Mechanismen zur Beeinflussung der Faktoren wie Latenzzeit und Bandbreite, um diese Ziele zu erreichen. Traffic- Shaping ist also letztendlich eine Maßnahme zur Reduzierung oder Verzögerung von Investitionen, die oft bereits mit vorhandener Hardware durchgeführt werden kann. Weitere Beispiele für eine Kostensenkung, die durch den Einsatz eines Überwachungstools möglich sind, können sein: 1. Die Datenleitung zu einer Filiale ist nur durch das Backup nachts zu 100% ausgelastet. Hier könnte eine günstigere, schmalbandigere Leitung ausreichen, wenn dass Backup länger laufen darf. Autor: Dr. Dietmar Fiehn Seite 11

12 2. Die Übertragungszeit einer Datei im internen Netz wird durch die Anbindung des Fileservers an den Backbone begrenzt. Die Traffic-Analyse zeigt hier regelmäßig Auslastungen von 90% über einen längeren Zeitraum. Der Server selbst ist nicht ausgelastet, hier kann eine schnellere Netzverbindung für genau diesen Server das Problem lösen 3. Der Gesamt-Traffic durch einen Switch erreicht dessen maximale Bandbreite. Er ist somit das Bottleneck für niedrige Antwortzeiten, dass ausgetauscht oder aufgerüstet werden muss. Autor: Dr. Dietmar Fiehn Seite 12