DE69923435T2

DE69923435T2 - System und verfahren zur optimierung der leistungskontrolle von komplexen informationstechnologiesystemen

Info

Publication number: DE69923435T2
Application number: DE69923435T
Authority: DE
Inventors: Willem Pieter ADRIAANS; Jan Arno KNOBBE; Marc Gathier
Original assignee: Perot Systems Corp; NTT Data Services Corp
Current assignee: NTT Data Services Corp
Priority date: 1998-03-06
Filing date: 1999-03-04
Publication date: 2005-07-07
Anticipated expiration: 2019-03-05
Also published as: EP1058886B1; AU2985999A; WO1999045468A1; ATE288106T1; EP1058886A1; US6311175B1; DE69923435D1

Description

Technisches Gebiet der Erfindung
Die vorliegende Erfindung betrifft komplexe Informationstechnologie-Systeme (IT) und im einzelnen Kontinuitäts-Analysetechniken zum Auffinden von Beziehungen zwischen komplexen Ereignissen, die in solchen Systemen auftreten, und noch spezieller Techniken zum Verbessern der Performance bzw. der Leistung von solchen IT-Systemen durch eine iterative System-Modellierung.
Hintergrund und Aufgaben der Erfindung
Mit der exponentiellen Zunahme von Computern und dem exponentiellen Anwachsen der Computerindustrie sind Informationstechnologie (IT)-Systeme zunehmend komplex und schwierig zu verwalten. Ein typisches IT-System kann selbst in einer kleinen Firma Dutzende von Computern, Druckern, Servern, Datenbanken, etc. enthalten, wobei jede Komponente irgendwie über interne Verbindungen mit anderen Komponenten verbunden sind. Ein vereinfachtes Beispiel eines intern verbundenen IT-Systems ist in der 1 gezeigt, das im nachfolgenden detaillierter beschrieben wird.
Obwohl intern verbundene Systeme, wie etwa das in der 1 gezeigte System, den Benutzern viele Vorteile, beispielsweise die gemeinsame Nutzung von Betriebsmitteln, bieten, wird das Verhalten dieser komplexen Systeme schwieriger vorherzusagen, wenn solche Systeme anwachsen und die Anzahl der internen Komponentenverbindungen zunimmt. Ferner beginnt die System-Performance bzw. System-Leistung, nachzulassen oder inkonsistent zu werden, in ihrer Natur wird sie sogar chaotisch. Das Hinzufügen oder Entfernen von einer Komponente, sogar einer dem Anschein nach kleinen Komponente, kann auf die Performance des gesamten Systems dramatische Folgen haben. Selbst ein Upgrade auf einer Komponente kann eine entfernt liegende, dem Anschein nach nicht in Beziehung stehende Komponente nachteilig beeinflussen. Das System und Verfahren der vorliegenden Erfindung betrifft Techniken, um das Verhalten von komplexen IT-Systemen besser vorherzusagen, und zwar indem System-Administratoren die Möglichkeit gegeben wird, Problembereiche, wie etwa Performance-Engpässe, zu identifizieren und diese zu korrigieren, bevor ein System oder eine Komponente eine Fehlfunktion aufweist.
Herkömmliche Ansätze zur Überwachung der System-Performance sind unzureichend, um auf einfache Weise in einem komplexen IT-System die Natur eines Performance-Problems zu erahnen, da jedwede bei der Überwachung gesammelten Daten beim Herausfinden der wahren Natur des Performance-Problems allgemein unbrauchbar sind. Das System und Verfahren der vorliegenden Erfindung stellt jedoch einen Mechanismus bereit, mit welchem System-Überwachungsdaten einfach zugänglich und zur Analyse der gegenwärtigen Performance und zum Vorhersagen der Zukunfts-Performance nutzbar gemacht werden. Die vorliegende Erfindung ermöglicht diese Analyse durch die Verwendung von Data-Mining-Prinzipien, die im nachfolgenden weiter beschrieben werden.
Im allgemeinen ist die Data-Mining-Technik eine Analyse von Daten, wie etwa eine Analyse von Daten in einer Datenbank, indem Hilfsprogramme bzw. Tools verwendet werden, die ohne eine Kenntnis der Bedeutung der analysierten Daten Tendenzen oder Muster von Ereignis-Eintritten ermitteln. Solche Analysen können strategische Information offenbaren, die in sehr großen in einer Datenbank gespeicherten Datenmengen verborgen ist. In typischer Weise wird die Data-Mining-Technik verwendet, wenn der Umfang der analysierten Information sehr hoch ist, wenn interessante Variablen durch komplizierte Beziehungen mit anderen Variablen beeinflusst werden, wenn sich die Bedeutung der Einfluss einer vorgegebenen Variable mit ihrem eigenen Wert ändert, oder wenn sich die Bedeutung bzw. der Einfluss der Variablen hinsichtlich der Zeit ändert. In Situationen wie diesen können herkömmliche statistische Analyse-Techniken und allgemeine Datenbank-Verwaltungssysteme eine Fehlfunktion aufweisen, oder in unangemessener Weise schwerfällig werden, wie es beim Analysieren eines IT-Systems auftreten kann.
Jedes Jahr kompilieren Firmen große Mengen von Information in Datenbanken, wodurch die Kapazitäten der herkömmlichen Daten-Analysetechniken weiter angespannt werden. Diese zunehmend anwachsenden Datenbanken enthalten nützliche Information hinsichtlich vieler Facetten des Geschäftsbetriebes der Firmen, einschließlich Information hinsichtlich der Entwicklung bzw. der Tendenz, die nur durch eine kritische Analyse der hier und da über die Datenbank (Datenbanken) verteilt eingestreuten Schlüsseldaten ausfindig gemacht werden können. Infolge des ungeheuren Volumens und/oder der Komplexität der verfügbaren Information, geht leider solche Information hinsichtlich der Entwicklung bzw. der Tendenz in typischer Weise verloren, wenn sie mittels manueller Interpretationsverfahren oder traditioneller Informations-Verwaltungssysteme nicht wiederherstellbar wird. Jedoch können als Werkzeug die Prinzipien der Data-Mining-Technik verwendet werden, um die innerhalb der Masse der insgesamt verfügbaren Information verdeckt verborgene Information hinsichtlich der Entwicklung bzw. der Tendenz aufzufinden.
Solche Data-Mining-Techniken werden in zunehmendem Maße in einer Vielzahl unterschiedlicher Fachgebiete verwendet, einschließlich im Bank-Gewerbe, Marketing-Gewerbe, in biomedizinischen Anwendungen und anderen Industrien. Versicherungsunternehmen und Bankunternehmen verwenden die Data-Mining-Technik zur Risiko-Analyse, indem Data-Mining-Verfahren beispielsweise bei der Ermittlung ihrer eigenen Anspruchs-Datenbanken für Beziehungen zwischen Client-Charakteristika und entsprechenden Ansprüchen verwendet werden. Versicherungsunternehmen haben ein naheliegendes Interesse an den Charakteristika ihrer Versicherungspolice-Inhaber, und zwar im einzelnen von jenen Versicherungspolice-Inhaber, die riskante oder nicht den Interessen der Gesellschaft entsprechende andere unsachgemäße Handlungen oder Verhaltensweisen aufweisen, und mit solchen Analysen sind diese Versicherungsunternehmen in der Lage, die den festgestellten Risiken entsprechenden Risikoprofile und Risikoprämien einzustellen.
A.J. Knobbe beschreibt in der Druckschrift "Data Mining for Adaptive System Management" (PROCEEDINGS OF THE FIRST INTERNATIONAL CONFERENCE ON THE PRACTICAL APPLICATION OF KNOWLEDGE DISCOVERY AND DATA MINING, PADD' 97, 23.-25. April 1997, S. 157-165, London, UK) den allgemeinen Stand der Technik hinsichtlich Data-Mining-Techniken für die adaptive Systemverwaltung.
Die Data-Mining-Technik hat ebenso einen großen Erfolg in direkten Marketing-Strategien gefunden. Direkte Marketing-Unternehmen sind in der Lage, Beziehungen zwischen persönlichen Attributen zu bestimmen, wie etwa zwischen dem Alter, dem Geschlecht, dem Wohnort, dem Einkommen und der Wahrscheinlichkeit, dass eine Person beispielsweise auf ein bestimmtes direktes Mailing reagieren wird. Diese Beziehungen können dann verwendet werden, um Personen mit der höchsten Wahrscheinlichkeit einer Antwort direkt anzumailen, wodurch die Aussichten sowie die potentiellen Profite der Firmen verbessert werden. Zukunfts-Mailing kann an Familien gerichtet werden, die ein bestimmtes Antwortprofil erfüllen und bekannte Verhaltensweisen aufweisen, ein Prozess, der auf unbestimmte Zeit wiederholt werden kann. In diesem Sinne lernt die Data-Mining-Analyse von jedem wiederholten Ergebnis, welches basierend auf einer Vergangenheitsanalyse von dem Verhalten der Kunden das Verhalten dieser Kunden voraussagt.
Auf die gleiche hierin dargestellte Art und Weise kann die Data-Mining-Technik ebenso bei der Vorhersage des Verhaltens der Komponenten eines komplexen Informationstechnologie-Systems (IT-Systems) eingesetzt werden, wie etwa bei der Vorhersage des Verhaltens der Komponenten von jenem in der 1 gezeigten System, oder bei der Vorhersage des Verhaltens der Komponenten eines etwas komplizierteren Systems, das in der Unternehmensumgebung gefunden wird. Zu den zuvor genannten ähnliche Ansätze mit geeigneten Modifikationen können verwendet werden, um zu ermitteln, wie die verschiedenen miteinander verknüpften Komponenten einander beeinflussen, was komplexe Beziehungen aufdeckt, die in dem IT-System bestehen.
Wie erläutert, werden innerhalb einer gemeinsamen IT-Infrastruktur, wie etwa innerhalb der in der 1 gezeigten Infrastruktur, vielfache Anwendungen betrieben. Häufig werden diese Anwendungen einige der gleichen Betriebsmittel ausnutzen. Es ist offensichtlich, dass das gemeinsame Nutzen der Betriebsmittel der IT-Infrastruktur bei verschiedenen Anwendungen unerwartete Interaktionen im Systemverhalten bewirken kann, und dass häufig solche unerwarteten Interaktionen, die nicht synergetisch sind, unerwünscht sind. Ein Beispiel hierfür sind vielfache Unternehmens-Anwendungen, die innerhalb eines IT-Systems einen Router gemeinsam nutzen. Zur Veranschaulichung belastet eine bestimmte Anwendung, beispielsweise ein E-Mail-Dienst, einen Router derart, dass andere Anwendungen nicht mehr hinreichend funktionieren. In diesem Beispiel ist es angemessen, zu erwarten, dass zahlreiche Anwendungen die Verwendung des Routers zeitweise gemeinsam nutzen. Traditionelle System-Management-Techniken können sich bei der Ermittlung, welche spezielle Anwendung einen Verlust der System-Performance hervorruft, als Problem erweisen. Dieses Beispiel erläutert weiter, weshalb ein Bedarf dahingehend besteht, verborgene Beziehungen zwischen IT-System-Komponenten und IT-System-Anwendungen aufzufinden, die in solchen Umgebungen ablaufen. Im Verlauf der Lösung dieses Problems, kann es in diesem Beispiel notwendig sein, den E-Mail-Verkehr zu einem anderen Router umzuleiten, um für die anderen Anwendungen eine angemessene Performance zu erzielen.
Im allgemeinen ist nun das herkömmliche IT-System-Management derart definiert, dass es sämtliche Aufgaben enthält, die ausgeführt werden müssen, um sicherzustellen, dass das Potential der IT-Infrastruktur einer Organisation bzw. eines Unternehmens die Nutzer-Anforderungen erfüllt. In der 2 ist ein traditionelles IT-System-Management-Modell dargestellt, welches im allgemeinen mit der Bezugsziffer 200 bezeichnet wird. Im wesentlichen gibt es Gruppen von System-Administratoren 210, die Kenntnis von der IT-Infrastruktur haben, welche sie verwalten, wie etwa von derjenigen in der 1 gezeigten und welche hierin allgemein mit der Bezugsziffer 220 bezeichneten IT-Infrastruktur. In typischer Weise ist die Kenntnis der Infrastruktur 220 unter dem mannigfaltigen Personal gestreut, das die System-Administratorgruppe 210 begründet. Die Gesamtheit dieser Kenntnis ist auf die Summe der individuellen Kenntnis der Administratoren begrenzt, wobei ausnahmslos viel Redundanz hinsichtlich der Kenntnis besteht. Diese Redundanz kann als Ineffizienz der Gesamtkenntnis-Basis betrachtet werden. Anders ausgedrückt wäre eine theoretisch maximale Kenntnis der Infrastruktur 220 nur dann realisiert, wenn jeder individuelle Administrator der Administratorgruppe 210 jene Kenntnis aufweist, die für den speziellen Administrator einzigartig ist. Während dies den Anschein einer unklaren Analyse der Effizienz von der Gruppe haben mag, ist es für das Unternehmen, das eine Gruppe von Administratoren finanzieren muss, von reeller Konsequenz. Darüber hinaus ist in typischer Weise diese Kenntnis nicht in einer auf einfache Weise aufrufbaren elektronischen Form gespeichert.
Wenn eine System-Überwachung in dem zuvor erwähnten traditionellen Managementsystem enthalten ist, dann ist diese Überwachung gewöhnlich auf Echtzeit-Daten, wie etwa auf die gegenwärtige Systembelastung und dergleichen, beschränkt. Ein Administrator kann eine solche Berichterstattung der Echtzeit-Daten aufmerksam verfolgen, und wenn herausgefunden wird, dass die überwachte Systembelastungen oder die überwachten Ereignisse mit Belastungen konsistent sind, dann erkennt der Administrator, dass er in Zusammenhang mit einer bevorstehenden System-Fehlfunktion oder in Zusammenhang mit einem Verlust der System-Performance steht, so dass der Administrator einen Teil der Belastung auf alternative Subsysteme der IT-Infrastruktur umleiten kann, um Probleme abzuwenden.
Häufig kann eine solche Echtzeit-Daten-Berichterstattung bei der Koordination mit einem System-Modell des IT-Systems verwendet werden, wobei die Daten des System-Modells gesammelt und berichtet werden. Das Modell weist gewöhnlich einen Computer-Algorithmus auf, der einen Code verwendet, welcher die Beziehungen zwischen verschiedenen Systemvorrichtungen verwaltet. Ein Problem bei solchen Modellen besteht jedoch darin, dass die bei der Modellierung des Systems verwendeten Beziehungen nur die erwarteten Interaktionen zwischen Komponenten und Subsystemen berücksichtigen. Von daher ist das Modell lediglich ein idealisiertes Modell des tatsächlichen Systems. Verborgene oder unerwartete Beziehungen, die zwischen Komponenten bestehen, werden nicht berücksichtigt. Wenn die Infrastruktur 220 modifiziert wird, muss darüber hinaus das Modell manuell verändert werden, um in dem Modell-Algorithmus neue Beziehungen einzufügen, um die durchgeführten Änderungen einzufügen, damit die durchgeführten Änderungen berücksichtigt werden.
In dem sogenannten Experten-System ist eine Verbesserung hinsichtlich dieses traditionellen Managementsystems umgesetzt. Ein Experten-System ist eine Gestaltung künstlicher Intelligenz, in welcher ein Computerprogramm eine Datenbank, die häufig als Kenntnisbasis bezeichnet wird, sowie eine Anzahl von Algorithmen enthält, die verwendet werden, um Fakten von der programmierten Kenntnis und neue Daten, die in das System eingegeben werden, zu extrapolieren. Die Kenntnisbasis ist eine Kompilierung der menschlichen Begutachtung, die verwendet wird, um beim Lösen von Problemen zu helfen, beispielsweise bei medizinischen Diagnosen. Jedoch ist die Verwendung des Experten-Systems durch die Qualität der Daten und der Algorithmen beschränkt, die über den menschlichen Experten in das System eingegeben werden.
In typischer Weise sind Experten-Systeme derart entwickelt, dass Kenntnis von einer Person oder von Personen, die in einem speziellen technischen Fachgebiet qualifiziert sind, akkumuliert und in einem auf einfache Weise abrufbaren Medium gespeichert werden. Auf diese Art und Weise haben Personen, die weniger qualifiziert sind als die Experten, deren Kenntnis innerhalb des Experten-Systems akkumuliert wurde, einen Zugriff auf solche Experten-Information. Auf diese Art und Weise kann ein Unternehmen menschliche und finanzielle Betriebsmittel einsparen, indem weniger qualifiziertes Personal einen Zugriff auf solche Experten-Systeme hat, anstatt dass der Experte erforderlich ist, um sämtliche derartige Situationen zu bearbeiten, die einen bestimmten Stand an Kenntnis erfordern.
Die Verwendung von solchen Experten-Systemen gestattet es, dass ebenso weniger qualifizierte Personen das Verhalten des IT-Systems analysieren können. Diese Systeme können verwendet werden, um bei der Fehlersuche in einem IT-System zu helfen, oder sie können verwendet werden, um mit der Unterstützung der System-Performance-Monitore bei der Vorhersage solcher Fehler mitzuhelfen; das heißt, eine Person mit einem Zugriff zu einem bei einem bestimmten IT-System angewandten Experten-System kann durch geeignete Monitore System- Belastungsparameter und dergleichen studieren und durch die Verwendung des Experten-Systems Abschätzungen der potentiellen Fehler infolge von System-Engpässen oder dergleichen machen.
Ein signifikanter Nachteil von Experten-Systemen liegt jedoch darin, dass sie nur schlecht ausgerüstet sind, um neu auftretende Probleme und Situationen zu bearbeiten. Auf diese Art und Weise ist es klar, dass Experten-Systeme in ihrem technischen Leistungsvermögen beim Lösen neuer Angelegenheiten begrenzt sind. Stattdessen erfordern Experten-Systeme ein vollständiges Modell von sämtlichen Ereignissen oder Fehlern, die in dem System auftreten können, welches modelliert wird.
Die vorliegende Erfindung ist eine Weiterentwicklung der zuvor beschriebenen herkömmlichen Technik. In einer Art und Weise, die ähnlich zu der Art und Weise ist, in welcher Data-Mining-Techniken angewandt werden, um beispielsweise das Verhalten der Kunden in dem Direkt-Marketing-Beispiel vorherzusagen, kann die Idee von solchen Techniken auf ähnliche Weise bei komplexen IT-Systemen zur Bestimmung und Vorhersage des Verhaltens von IT-Komponenten angewandt werden. Das System sowie Verfahren der vorliegenden Erfindung ermöglichen, wenn sie implementiert sind, die Ermittlung, wie die untereinander verknüpften Komponenten einander die Performance beeinflussen, was potentiell unerwartete Beziehungen zwischen verschiedenen Komponenten eines IT-Systems aufdeckt. Dieses wird erzielt, indem eine Kontinuitäts-Analyse verwendet wird, die in Verbindung mit den zuvor erwähnten Data-Mining-Techniken an historischen IT-System- und Subsystem-Zustandsdaten sowie an Simulations-Testdaten durchgeführt wird.
Es ist klar, dass mit den heutzutage vorhandenen, zunehmend untereinander verknüpften und komplexen IT-Infrastrukturen und mit der entsprechenden Zunahme der Wartungskosten solcher Systeme ein System und Verfahren zum Auffinden schädlicher Beziehungen zwischen verschiedenen Subsystemen und Elementen von solchen komplexen Netzwerken in einer im wesentlichen automatisierten Art und Weise mit Sicherheit ein wertvolles Werkzeug ist.
Ebenso liegt eine Aufgabe der vorliegenden Erfindung darin, eine automatisierte Einrichtung zum Akkumulieren des Sortimentes von Daten anzugeben, die durch eine geeignete Data-Mining-Technik analysiert werden können, so dass Performance-Modelle von komplexen IT-Systemen basierend auf periodischen Messungen von zuvor festgelegten Performance-Levels erzeugt oder aktualisiert werden können. Eine weitergehende Beschreibung hinsichtlich der Data-Mining-Techniken, die im Zusammenhang der vorliegenden Offenbarung angewandt werden, kann in der anhängigen Patentschrift der Anmelderin, dem US-Patent Nr. 6 393 387, eingereicht am 06. März 1998, mit dem Titel „System and Method for Model Mining Complex Information Technology Systems", gefunden werden.
Ein anderes erwünschtes Merkmal eines IT-Systems, wie etwa eines solchen Systems, das die Verbesserungen der vorliegenden Erfindung berücksichtigt, liegt darin, den Umfang des menschlichen Eingriffs zu reduzieren, der für das System erforderlich ist, um dynamische Systemänderungen anzupassen. Dieses wird in bevorzugter Weise durch eine Automatisierung erreicht.
Ferner ist es erwünscht, dass das System und das Verfahren der vorliegenden Erfindung die System-Performance mit Booleschen Attributen, das heißt mit RICHTIG oder FALSCH, analysiert.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung ist in den beiliegenden unabhängigen Patentansprüche definiert.
Die vorliegende Erfindung betrifft ein System sowie ein Verfahren zum automatischen Erzeugen von Leistungsmodellen eines Informationstechnologie-Systems (IT-System) durch Verwendung einer Kontinuitäts-Analyse, in bevorzugter Weise in Verbindung mit Data-Mining-Techniken. Ein adaptives System-Management ist als Realisierung eines proaktiven System-Managements mit adaptiven Techniken definiert, welche automatisch Modelle des Systems erzeugen und lernen können, die Wirkungen der Management-Aktionen zu planen und vorherzusagen, um die verschiedenen Benutzer-Anforderungen zu erfüllen. IT-Service-Level-Agreements (SLAs) bzw. IT-Regelungen eines Service Levels oder Performance-Anforderungen sind zuvor festgelegte Bedingungen bzw. Beschränkungen oder Schwellen, die in dem System untergebracht sind. Die Überwachung der Performance des Systems wird dann durchgeführt, von welcher Datenbanken der Systemszustands-Information ermittelt und gespeichert werden.
Eine Kontinuitäts-Analyse wird dann an dem IT-System oder Subsystem hiervon ausgeführt, und zwar indem SLA-Performance-Simulationen mit der System-Überwachungsaktivität synchronisiert werden, und indem beide in einer Historie-Datenbank akkumuliert werden. Dann wird als Eingabe für die Kontinuitäts-Analyse ein Modell der System-Umgebung verwendet. Die Umgebung kann über einen beliebigen Detail-Level definiert werden und ist in nicht notwendiger Weise ein fertiges oder konsistentes Modell des tatsächlichen Systems. Das System sowie das Verfahren der vorliegenden Erfindung werden in bevorzugter Weise mit einer Kollektion von Datenüberwachungen bzw. Daten-Monitoren implementiert, die durch das System hindurch angeordnet sind. Diese Monitore prüfen periodisch den Zustand der verschiedenen Elemente des Systems, wobei die überwachten Daten in einer Datenbank gespeichert werden.
Dann wird ein Testprogramm ausgeführt, wobei die Ausführung mit der relativen Überwachungsaktivität synchronisiert ist, um spezielle Aktionen des IT-Systems, die in Zusammenhang mit einem speziellen zuvor festgelegten Service-Level-Agreement (SLA) bzw. einer speziellen zuvor festgelegten Regelungen eines Service Levels stehen, zu simulieren. Das Ausführen der Testprogramme sowie die Überwachung von Handlungen werden in bevorzugter Weise automatisch und bei festen Zeitintervallen durchgeführt. Ergebnisse des Testprogramms sind Zeitmessungen der mit dem Service-Level-Agreement (SLA) bzw. der Regelung eines Service Levels in Beziehung stehenden Aktionen, die in bevorzugter Weise als reelle Zahlen ausgedrückt und in einer Datenbank mit einem Zeit-Kennzeichen sowie mit entsprechenden überwachten Systemdaten, oder äquivalent hierzu in einem Datenspeicher-Schema vom Matrix-Typ gespeichert werden. Eine zusätzliche Eingabe weist die Service-Level-Agreements (SLAs) selber auf. Diese Schwellenwerte werden verwendet, um die reellen Zahlen von dem Testprogramm in Boolesche Werte umzuwandeln, wobei diese Booleschen Werte anzeigen, ob oder ob nicht der zuvor festgelegte Schwellenwert überschritten wurde. Diese Boolesche Information wird dann ausgegeben, um den Einfluss der verschiedenen Überwachungswerte auf die als Ziel gesetzte Performance-Variable oder auf das als Ziel gesetzte Service-Level-Agreement (SLA) bzw. auf die als Ziel gesetzte Regelung eines Service Levels zu charakterisieren. Dann kann diese Information in einer Vielzahl von Weisen verwendet werden, einschließlich der Trend- bzw. Tendenz-Analyse, der Performance-Optimierung sowie der Überwachungs-Optimierung.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Unter Bezugnahme auf die nachfolgende detaillierte Beschreibung wird ein besseres Verständnis des Systems sowie des Verfahrens der vorliegenden Erfindung ermöglicht, wenn die Beschreibung in Verbindung mit den beigefügten Zeichnungen gelesen wird, in welchen folgendes gilt:
1 ist ein exemplarisches Netzwerksystem, bei welchem das System sowie das Verfahren der vorliegenden Erfindung verwendet werden kann;
2 ist ein Blockdiagramm eines herkömmlichen IT-System-Management-Verfahrens;
3 ist ein Blockdiagramm eines Systems sowie eines Verfahrens für das adaptive System-Management in Übereinstimmung mit der vorliegenden Erfindung;
4 ist ein Sample-Ausgabe-Entscheidungsbaum, welcher verschiedene System-Attribute verwendet;
5 ist ein Streudiagramm von Zugriffszeit-Attributen für ein herkömmliches System; und
6 ist ein zweiter Sample-Ausgabe-Entscheidungsbaum, welcher andere System-Attribute verwendet.
DETAILLIERTE BESCHREIBUNG DER GEGENWÄRTIG BEVORZUGTEN EXEMPLARISCHEN AUSFÜHRUNGSFORMEN
Nun wird im nachfolgenden unter Bezugnahme auf die beigefügten Zeichnungen, in welchen bevorzugte Ausführungsformen der Erfindung gezeigt sind, die vorliegende Erfindung vollständiger beschrieben. Jedoch kann diese Erfindung auf viele unterschiedliche Art und Weisen ausgeführt werden, und sie sollte nicht so ausgelegt werden, dass sie auf die hierin ausgeführten Ausführungsformen beschränkt ist; vielmehr sind diese Ausführungsformen nur dafür vorgesehen, dass diese Offenbarung genau und vollständig ist, und dass sie einem Fachmann den Kerngedanken der Erfindung vollständig vermittelt.
3 zeigt ein Modell eines adaptiven System-Management-Szenarios 300 in Übereinstimmung mit dem System und dem Verfahren der vorliegenden Erfindung. Die Anwendung der Data-Mining-Technik an einem Informationstechnologie (IT)-System, wie etwa an jenem in der 1 gezeigten und allgemein mit der Bezugsziffer 305 bezeichneten System, ist in der 3 gezeigt, in welcher das IT-System 100/305 mit zumindest einem Monitor 310 verbunden ist, der die Performance des IT-Systems 305 überwacht. Der Monitor 310 ist mit einer Historie-Datenbank 315 verbunden, die verwendet wird, um verschiedene Messungen der Performance an dem IT-System zu speichern. Die Historie-Datenbank 315 ist wiederum mit einer Anzahl von Lern-Algorithmen 320 verbunden. Elemente oder Ereignisse, die in Zusammenhang mit dem IT-System oder der Infrastruktur 305 stehen, werden über das gesamte System hinweg durch geeignete innerhalb der Monitore 310 untergebrachte Überwachungs-Schemata überwacht.
Daten von der zuvor erwähnten Überwachung werden durch die Monitore 310 weitergeleitet und in die Historie-Datenbank 315 eingegeben. Die Daten innerhalb der Historie-Datenbank 315, welche die am jüngsten aktualisierte Information hinsichtlich der Performance des IT-Systems 305 enthält, werden dann den speziellen Lern-Algorithmen 320 ausgesetzt. Die Lern-Algorithmen 320 können neue Muster oder Beziehungen zwischen diskreten Ereignissen erkennen, die in dem IT-System 305 auftreten. Die Lern-Algorithmen 320 aktualisieren dann ein adaptives Modell der hierin allgemein mit der Bezugsziffer 325 bezeichneten IT-Infrastruktur.
Die Management-Umgebung speichert sämtliche gesammelte Information und verwendet verschiedene Lern-Techniken, um das IT-System 305, welches verwaltet wird, kennenzulernen. Es sollte so verstanden sein, dass die zuvor erwähnten Lern-Algorithmen 320 für den Fachmann wohlbekannt sind. Diese Lern-Techniken ermöglichen es der Lern-Umgebung, dass sie sich selber an die verwaltete IT-Infrastruktur 325 besser anpasst. Sobald demgemäss zusätzliche Information hinsichtlich der IT-Infrastruktur 325 verfügbar ist, wird eine bessere Verwaltung der Systemumgebung möglich. Dann wird weitere Information gesammelt und gespeichert, so dass der Lernprozess fortfährt. Tatsächlich ist der gesamte mit dem System und Verfahren der vorliegenden Erfindung bereitgestellte Überwachungs-, Lern- und Anpassungsprozess kontinuierlich und iterativ.
Beim Entwerfen von solch einem dynamischen Lernmodell, wie es in der vorliegenden Erfindung offenbart wird, ist es zunächst notwendig, Schwellenwerte für verschiedene System-Performances zu definieren. Diese Schwellenwerte werden von nun an Service-Level-Agreements (SLA) bzw. Regelungen eines Service Levels genannt, die in der vorliegenden Erfindung einfach ein numerischer Schwellenwert sind, der verwendet wird, um von einer Anzahl System-Komponenten oder System-Elementen einen bestimmten Performance-Level zu beurteilen. Die Service-Level-Agreements (SLAs) bzw. die Regelungen eines Service Levels dienen dazu, numerisch formatierte Daten, die überwacht werden, in Boolesche Werte umzuwandeln, die anzeigen, ob oder ob nicht das Service-Level-Agreement (SLA) bzw. die Regelung eines Service Levels erfüllt wurde.
Als Beispiel für ein solches Service-Level-Agreement (SLA) bzw. für eine solche Regelung eines Service Levels wird nun auf eine Datenbank 105 in 1 Bezug genommen, die an einem System-Server 110 angesiedelt ist, so dass zahlreiche und diverse Nutzer die Datenbank 105 abfragen können. Beim Abfragen der Datenbank 105 ist es angemessen, dass zunächst über den Server 110 ein Login durchgeführt werden muss. Dieses Login kann jedoch auch über einen anderen Server und eine Datenbank konventionell durchgeführt werden, die in der 1 jeweils als Server 120 und Datenbank 115 gezeigt sind. Um entfernt gelegen auf die Datenbank 105 zugreifen zu können, wird von daher für einen Nutzer des Systems ein Login zunächst über die Datenbank 115 ausgeführt, wobei bei einem erfolgreichen Login diese Datenbank dem Benutzer Rechte dahingehend garantiert, auf die Datenbank 105 zuzugreifen. Für diese gesamte Operation kann ein Performance-Schwellenwert durch sachkundiges Management-Personal, welches in der 2 mit der Bezugsziffer 230 bezeichnet wird, eingerichtet werden. In typischer Weise wird solch ein Schwellenwert mit Kenntnis der Performance der Server 110 und 120, an welchen sich jeweils die Datenbanken 105 und 115 befinden, sowie mit einer allgemeinen Kenntnis des Datenverkehrs durch diese Server gebildet.
Für dieses Beispiel sei angenommen, dass die Anlaufzeit der Datenbank 105 ein angemessenes Maß der Performance der Datenbank 105 ist. Von daher könnte der als Ziel gesetzte Performance-Level der Datenbank 105, das heißt, ihr Service-Level-Agreement (SLA) bzw. die Regelung ihres Service Levels von den Zugriffszeiten von beiden Datenbanken 105 und 115 aufgebaut werden. Hier kann das Service-Level-Agreement (SLA) bzw. die Regelung des Service Levels mit SLA_A beschrieben werden, wobei A die Datenbank 105 darstellt. Da angenommen wird, dass die Zugriffszeit ein gutes Maß der Performance von solch einer Anwendung ist, weist die gesamte Zugriffszeit für die Datenbank 105 die Zugriffszeit der Datenbank 115 auf, da die effektive Ausführung der Datenbank 105 durch die Ausführung der Datenbank 115, die ebenso hierin durch den Bezugsindikator B bezeichnet wird, verlängert wird. Für diesen Fall kann die gesamte Zugriffszeit AT_AB für den Anlauf der Datenbank in der Summe der Anlaufzeiten der individuellen Datenbänke AT_A und AT_B gefunden werden, anders ausgedrückt, durch den folgenden Ausdruck: ATAB = ATA + ATB
Es sei angenommen, dass das Studium der individuellen Anwendungen und der Hardware, von welcher die Ausführung dieser Anwendungen ausgeführt werden, anzeigt, dass es für die Ausführung der Datenbank 115 angemessen ist, dass sie in nicht länger als einer Sekunde stattfindet, und dass es für die nachfolgende Ausführung der Datenbank 105 angemessen ist, dass sie in nicht mehr als zwei Sekunden stattfindet. Von dieser Information würde das Ziel für die gesamte Anlaufzeit der Datenbank 105 AT_AB für die Ausführung der Datenbank 105 nicht länger als drei Sekunden betragen. Dieser Schwellenwert zum Ausführen der Datenbank 105, der die erforderliche Zugriffszeit der Datenbank 115 aufweist, könnte dann für das Service-Level-Agreement (SLA) bzw. für die Regelung des Service Levels der Datenbank 105 definiert werden, was hierin mit SLA_AB bezeichnet wird. Dieses Service-Level-Agreement (SLA) würde entsprechend wie folgt aufgezeichnet werden:
SLA_AB ≤ 3 Sekunden
In einem Booleschen Format würde dieses Service-Level-Agreement (SLA) bzw. diese Regelung des Service Levels beispielsweise mit einem logischen Eins anzeigen, dass für das Ausführen der Datenbank 105 eine Zeit weniger als oder gleich drei Sekunden ausreicht, und beispielsweise mit einer logischen Null anzeigen, dass das Ausführen in einer Zeit, die drei Sekunden überschreitet, nicht ausreichend ist. Alternativ hierzu können individuelle Schwellenwerte für die Datenbanken 105 und 115 sowie ein durch einfaches Summieren der individuellen Schwellenwerte erzielter Schwellenwert für die Gesamt-Performance der Datenbank 105 wie folgt definiert werden:
SLA_A ≤ 2 Sekunden
SLA_B ≤ 1 Sekunde
SLA_AB ≤ 3 Sekunden
Beim Definieren von solchen Schwellenwerten sollte es offenkundig sein, dass, je höher die Anzahl der Service-Level-Agreements (SLAs) und der in der 3 gezeigten Monitore 310, welche das in der 1 gezeigte IT-System 100 überwachen, ist, desto besser das System ausgewertet werden kann. In idealer Weise würde die Mehrheit der Komponenten des IT-Systems 100 Service-Level-Agreements (SLAs) aufweisen, die in Zusammenhang mit ihnen stehen. In der Realität wirft jedoch eine aufwendige bzw. ausgedehnte System-Überwachung logische Probleme auf, die allgemein eher zu einfachere Modelle als zu kompliziertere Modelle führen. Wie es für den Fachmann ersichtlich ist, gilt nichtsdestotrotz, dass, je höher die Anzahl der Service-Level-Agreements (SLAs) ist, die innerhalb des IT-Systems 100 definiert und implementiert werden können, desto höher die Genauigkeit des Systemmodells und der Technik der vorliegenden Erfindung bei der Überwachung der System-Performance ist.
Um die zuvor erwähnten Data-Mining-Techniken und Lern-Algorithmen an Historie-Daten von dem IT-System 100 anzuwenden, ist es zunächst notwendig, die zuvor erwähnte Historie-Datenbank 315 so aufzubauen, wie es in der 3 gezeigt ist. Es wurde festgestellt, dass das bevorzugte Verfahren zum Speichern solcher Daten ein Verfahren in einem herkömmlichen relationalen Datenbankformat ist. In typischer Weise sind sämtliche Überwachungs-Daten von den Monitoren 310 zu einem zentralen Speicherort gerichtet, das heißt, zu der Historie-Datenbank 315. Jedoch sollte es so verstanden werden, dass jeder Monitor 310 seinen eigenen lokalen Speicher 330 aufweisen kann, um die Überwachungs-Daten temporär, das heißt, eine Minute, eine Stunde, etc. lang, zu speichern, und um sie dann zu der zentralen Historie-Datenbank 315 zu senden, wo die zuvor erwähnten Data-Mining- Anwendungen verwendet werden können, um die Daten zu analysieren.
Es sollte so verstanden sein, dass die Daten-Monitore 310 über die gesamte IT-Infrastruktur 100/305 hinweg bei verschiedenen Komponenten innerhalb des Systems angeordnet sein können. Die Überwachungs-Handlung kann an jedwede Anzahl von Komponenten, Anwendungen oder andere Betriebsmittel mit im allgemeinen der Gesamt-Effektivität der vorliegenden Erfindung gerichtet sein, wobei die Gesamt-Effektivität der vorliegenden Erfindung mit einer entsprechenden Zunahme in der Anzahl der verwendeten Monitore 310 erweitert ist. Diese Monitore 310 führen in bevorzugter Weise ihre spezielle Überwachungs-Handlung automatisch und bei speziellen Zeit-Intervallen durch, wodurch Daten periodisch gesammelt werden, beispielsweise jede Minute, jeweils alle zehn Minuten, jede Stunde, etc. Der Typ der Daten, die überwacht und in der Historie-Datenbank 315 gespeichert werden, kann allgemein als Zustand oder Verwendungs-Information auf einem Komponenten-Level, beispielsweise einer Harddisk, einer Datenbank, einem Server oder einem anderen Netzwerksegment, wie etwa die in der 1 gezeigten Komponenten, geschrieben werden. Beispielsweise kann ein Monitor 310, der verwendet wird, um Historie-Daten zu überwachen und auf eine bestimmte Harddisk zu schreiben, die freie Kapazität der Disk beschreiben, und zwar gleichgültig davon, ob oder ob nicht auf die Disk zugegriffen wird. In ähnlicher Weise können die von der Überwachung einer Datenbank gesammelten Daten die Anzahl der Zugriffe der Nutzer auf die Datenbank, das Abfrage-Volumen sowie die Zugriffszeit aufweisen.
Um die kontinuierliche Analyse an dem System 100 durchzuführen, ist es notwendig, über festgelegte und definierte Intervalle spezielle Systemfunktionen auszuwerten. Aus diesem Grund werden Testprogramme eingesetzt, um auszuwerten, ob das System 100 innerhalb eines oder mehrerer der zuvor erwähnten Service-Level-Agreements (SLAs) durchgeführt wird. Beispielsweise wäre es nicht effektiv, eine spezielle Aktion gegenüber ihrem Service-Level-Agreement (SLA) zu messen und auszuwerten, nur wenn diese Aktion von einer Person in dem Netzwerk durchgeführt wird. Solche Aktionen würden höchstwahrscheinlich pseudo-zufällig auftreten und von daher keine guten Hinweise auf die Gesamt-Performance des Systems 100 hinsichtlich der Zeit geben.
Um das System effektiver auszuwerten, werden Testprogramme verwendet, um jene Funktionen zu simulieren, die in Zusammenhang mit Service-Level-Agreement (SLAs) stehen. Bei der Verwendung von Testprogrammen in definierten Zeitmomenten können Kontinuitäts-Analysen an den Testdaten und den überwachten Daten als Funktionen der Zeit durchgeführt werden. Beispielsweise würde in dem Fall des für die Anlaufzeiten der Datenbanken 105 und 115 verwendeten Service-Level-Agreements (SLA) ein Testprogramm an der Server-Seite des Netzwerkes 100 eingerichtet werden, um eine Abfrage auf diese Datenbanken zu simulieren. Dieses Testprogramm würde in bevorzugter Weise automatisch und bei festgelegten Zeit-Intervallen ausgeführt werden. Darüber hinaus würde dieses Testprogramm im wesentlichen mit Überwachungs-Ereignissen synchronisiert sein, die in Zusammenhang mit der Auswertung der entsprechenden Service-Level-Agreements (SLAs) stehen.
Für das Beispiel des zuvor definierten Service-Level-Agreements SLA_AB ist ein Testprogramm erforderlich, um den Anlauf der Datenbank 105 mit dem darin enthaltenen Anlauf der Datenbank 115 zu simulieren. Es sollte so verstanden sein, dass das Testprogramm an der Server-Seite oder Client-Seite ausgeführt werden kann, wobei bevorzugt ist, dass das Testprogramm an beiden Seiten ausgeführt wird. Das Ausführen des Testprogramms an sowohl der Client-Seite als auch der Server-Seite erfordert jedoch separate Service-Level-Agreements (SLAs) an beiden Seiten des Systems. Um die Beschreibung zu vereinfachen, wird von nun an lediglich die Auswertung bei der Server-Seite betrachtet. Von daher wird ein Testprogramm oder eine Simulation an der Server-Seite ausgeführt, das bzw. die einen Zugriff auf die Datenbank simuliert. Indem dies so getan wird, muss zunächst die Datenbank 115 ein Login akzeptieren. Dieses Login ist in der Simulation enthalten. Das Testprogramm führt den Login sowie die Datenbank-Abfrage durch, wobei die Anlaufzeit der Datenbank 115 und die Anlaufzeit der Datenbank 105 aufgezeichnet wird. Die von dem Testprogramm aufgezeichneten Anlaufzeiten sind hinsichtlich ihrer Natur allgemeine numerische Werte und werden nachfolgend durch die zuvor beschriebenen Vergleiche mit den zugehörigen Service-Level-Agreements (SLAs) in Boolesche Werte umgewandelt. Für dieses Beispiel sei angenommen, dass bei der Ausführung des Testprogramms im Hinblick auf einen Zugriff auf die Datenbank 105 für die Anlaufzeit der Datenbank 115 eine Zeit von 1,25 Sekunden aufgezeichnet wurden, während für die nachfolgende Anlaufzeit der Datenbank 105 eine Zeit von 1,5 Sekunden aufgezeichnet wurde. Die Zugriffszeiten AT auf beide Datenbanken würde ähnlich zu der nachfolgend angegebenen Zeit aufgezeichnet werden:
AT_B = 1,25
AT_A = 1,5
Die gesamte Anlaufzeit der Datenbank 105, einschließlich der vorausgesetzten Anlaufzeit der Datenbank 115, ist einfach die Summe der beiden Anlaufzeiten, das heißt es gilt: AT_AB = 2,75 Sekunden.
Die zuvor definierten zugehörigen Service-Level-Agreements (SLAs) werden erneut wie folgt nachfolgend gegeben:
SLA_A ≤ 2 Sekunden
SLA_B ≤ 1 Sekunde
SLA_AB = SLA_A + SLA_B ≤ 3 Sekunden
Dem Versagen, die Anforderungen von einem Service-Level-Agreement (SLA) zu erfüllen, kann ein Boolesches Low, das heißt einem Falsch oder einer logischen Null zugeordnet werden, und Performances, welche das entsprechende Service-Level-Agreement (SLA) erfüllen, sind einem Booleschen High, das heißt einem Wahr oder einer logischen Eins, zugeordnet. Die numerischen Ergebnisse des Testprogramms können dann durch Vergleiche mit ihren entsprechend zugehörigen SLA-Schwellenwerten in Boolesche Attribute umgewandelt werden. Indem dies so getan wird, werden den Ergebnissen des Testprogramms des gegenwärtigen Beispiels jeweils wie folgt Booleschen Werten zugeordnet:
Erfüllt Performance von A das SLA_A ? = WAHR
Erfüllt Performance von B das SLA_B ? = FALSCH
Erfüllt Performance von AB das SLA_AB ? = WAHR
Wie zuvor angedeutet, zeigt die Bezugsziffer A die Datenbank 105 an, und die Bezugsziffer B zeigt die Datenbank 115 an.
Diese Booleschen Testprogramm-Attribute werden dann, beispielweise in einem logischen Format, in typischer Weise zusammen mit ihren numerischen Duplikaten in der zuvor erwähnten Historie-Datenbank 315 gespeichert, wie es aus dem Fachgebiet der relationalen Datenbank bekannt ist. In bevorzugter Weise sind den numerischen Werten und den Booleschen Werten jeweils separate Felder innerhalb der Datenbank 315 zugeordnet, wie es ebenso aus dem Fachgebiet der relationalen Datenbank bekannt ist. Diesen Aufzeichnungen ist ein Taktgeber- oder Zeit-Kennzeichen zugeordnet, das die Position in der Historie anzeigt, bei welcher diese Testdaten gesammelt wurden. Diesem Zeit-Kennzeichen ist in bevorzugter Weise in der Historie-Datenbank ein separates Feld für jede Aufzeichnung oder für jedes Überwachungs-Ereignis zugeordnet. Da die System-Überwachung mit der Ausführung des zuvor beschriebenen Testprogramms synchronisiert ist, werden gleichzeitig mit Ergebnissen des Testprogramms Überwachungsdaten des Systemzustands gespeichert. Diese Überwachungsdaten nutzen effektiv gemeinsam mit den Ergebnissen des Testprogramms das Zeit-Kennzeichen.
Eine endgültige Eingabe ist ein Modell eines Original-Systems, auf welches das System und Verfahren der vorliegenden Erfindung aufbaut, wobei die Genauigkeit und die Performance des in der 1 dargestellten unterliegenden Systems 100 verbessert werden. Es sollte so verstanden sein, dass das Modell des IT-Systems 100 in bevorzugter Weise derart entwickelt ist, dass es die Funktionen unterstützt, für welche die Service-Level-Agreements (SLAs) definiert sind. Ebenso sollte es so verstanden sein, dass das Modell allerdings bei irgendeinem Level definiert sein kann, und dass es nicht notwendig ist, dass das Modell vollständig oder konsistent ist, wie es der Fall für Experten-Systeme ist.
Infolge der iterativen Anpassungsfähigkeit des Gesamtsystems und infolge des Verfahrens der vorliegenden Erfindung, in welcher sich das Modell automatisch re-definiert und über die Zeit korrigiert, ist dieses richtig.
Nachdem die diskutierten Eingaben betrachtet wurden, kann nun die Ausgabe des Systems sowie das Verfahren der vorliegenden Erfindung nun werden. Sobald hinreichende Historien-Daten gesammelt und in der Datenbank 315 gespeichert sind, können Data-Mining-Techniken, die einem Fachmann bekannt sind, an dieser Ansammlung der überwachten Daten sowie an ihren zugehörigen Testdaten angewandt werden. Dann werden Data-Mining-Techniken an diesen Daten angewandt, und es werden die verschiedenen Beziehungen zwischen den überwachten Systemzustands-Daten und den Daten über Test-Performance-Erfolg oder -Fehler aufgedeckt. Diese neuentdeckten Beziehungen werden dann verwendet, um das bestehende IT-Modell zu aktualisieren, wodurch die Modell-Adaptivität erreicht wird. Dieses eindeutige Merkmal der vorliegenden Erfindung, das heißt, die Möglichkeit der vorliegenden Erfindung, dass sich das System von selber anpasst, wird verwendet, um das System zu überwachen und zu modellieren, wodurch es möglicht ist, dass das Originalmodell unvollständig oder inkonsistent ist.
In der Ausgabe wird in bevorzugter Weise ein Entscheidungsbaum-Algorithmus verwendet, wobei der Boolesche Wert, der von den Testprogramm-Daten und dem entsprechenden Service-Level-Agreement (SLA) abgeleitet wird, als Ziel-Attribut des Entscheidungsbaumes verwendet wird. Obwohl für einen Fachmann Entscheidungsbaum-Einführungsverfahren wohlbekannt sind, wird die 4 hierin angegeben, um die Verwendung dieser Verfahren darzustellen. Im Betrieb werden eine als Ziel gesetzte Ziel-Komponente entweder durch einen Administrator oder autonom zur Analyse ausgewählt und ein Entscheidungsbaum 400 erzeugt. Diese Ziel-Komponente bildet einen Stamm-Knotenpunkt 405 des Entscheidungsbaumes 400 aus.
Das in der 4 dargestellte spezielle Beispiel zeigt einen Entscheidungsbaum 400 für eine Abfrage von der zuvor erwähnten Datenbank 115(B) der 1, wo für die Analyse die Performance der Abfrage (Abfrage B) durch das System 100 als Ziel genommen wird. Die bei dem Ziel-Element 405 genannten 50% zeigen an, dass dieses Ziel derart festgelegt wurde, um in 50% der Fälle erfüllt zu werden, das heißt, das Ziel-SLA (Zugriffszeit geringer als oder gleich eine Sekunde) wurde zur Hälfte der Zeit erfüllt. Der numerische Wert, der der Erfolgs-Prozentzahl folgt, das heißt die 800, ist einfach ein Hinweis auf die Anzahl der Fälle, bei welchen über eine vorgegebene Zeitperiode Zustandsdaten aufgezeichnet wurden. Anders ausgedrückt bedeutet dies, dass bei diesem Stamm-Level der Analyse in 800 Abfragen der Datenbank 115 das zuvor erwähnte Ziel-SLA von einer Sekunde lediglich zur Hälfte der Zeit erfüllt wurde.
Die Zweige des Entscheidungsbaumes 400 von dem Stamm-Knotenpunkt 405, das heißt, ein oberer Zweig oder Element 410 sowie ein unterer Zweig oder Element 415, weisen ebenso überwachte Werte und ihre erfasste Beziehung zu dem Performance-Erfolg oder -Fehler des Ziel-Elementes 405 auf. Das obere Elemente 410 des ersten Zweiges zeigt beispielsweise die Wirkung der Anzahl der Netzwerk-File-Server (NFS)-Dämonen an dem Erfolg oder Fehler des Ziel-Elementes 405 an. Der Zweig 410 zeigt an, dass, wenn die Anzahl der NFS-Dämonen größer als zehn ist, das Ziel-Element 405 (über eine Abtastgröße von 350) so aufgefunden wurde, dass es eine hinnehmbare Performance von 90% der Zeit aufweist. Die Auswertung, ob die Performance des Ziel-Elementes 405 akzeptabel ist, wird gemäß den zuvor diskutierten Verfahren festgelegt, und zwar im einzelnen gemäß der Verfahren der Definition und Auswertung der Performance-Schwellenwerte oder Service-Level-Agreements (SLAs).
Der untere Zweig 415 von dem Stamm-Knotenpunkt 405 zeigt an, dass, wenn die Anzahl der NFS-Dämonen zehn oder geringer ist, das Ziel-Element 405 (über eine Abtastgröße von 450) eine akzeptable Performance von lediglich 20% der Zeit aufweist. Wie es in der 4 gezeigt wird, ist der untere Zweig 415 ferner in Unterzweige 420 aufgeteilt, die zusätzliche System-Attribute bezüglich des Ziel-Elementes 405 bezeichnen. Der Unterzweig 420 zeigt an, dass, wenn die Anzahl der NFS-Dämonen geringer als oder gleich zehn und die Anzahl der Anmeldungen an die Datenbank 115 größer als vier ist, die Performance des Ziel-Elementes 405/Datenbank 115 (über eine Abtastgröße von 20) nur 1% der Zeit akzeptabel ist, was deutlich ein System-Betriebsmittel-Problem demonstriert. Der andere Unterzweig 425 zeigt an, dass, wenn die Anzahl der NFS-Dämonen zehn oder geringer und die Anzahl der Datenbank-Logins vier oder geringer ist, das Ziel-Element 405 (über eine Abtastgröße von 430) eine akzeptable Performance von 40% der Zeit aufweist.
Da in der in 3 dargestellten Historie-Datenbank 315 die Boolesche Auswertung der Testprogramme mit zugehörigen überwachten Systemzustands-Daten aufgezeichnet werden, und infolge der Booleschen Werte der SLA-Parameter, die in dem Entscheidungsbaum als Ziel-Attribute verwendet werden, beschreibt der Entscheidungsbaum 400 den Einfluss der Überwachungswerte und von daher den Einfluss von Systemkomponenten-Zuständen auf die Ziel-Attribute. Faktoren an Systemkomponenten-Zuständen, welche die System-Performance beeinflussen, treten am deutlichsten nahe an dem Stamm-Knotenpunkt 405 des Baumes 400 in Erscheinung. Dieses kann in dem in der 4 gezeigten Beispiel gesehen werden, wo der erste Zweig erkennbar einen Hinweis hinsichtlich der am stärksten kausalen Beziehungen gibt, welche die Performance des Ziel-Elementes 405 beeinflussen.
Jedoch sollte es so verstanden sein, dass die zuvor erwähnte Abhängigkeitsbeziehung zwischen der Anzahl der NFS-Dämonen und der Anmeldungen an die Datenbank 115 eine hohe Assoziation aufweist, das heißt, die zuvor erwähnten Abtastungen bzw. Proben der Zustände des Systems 100 weisen eine strenge Korrelation auf. Die Ergebnisse des Entscheidungsbaumes 400 können eine Stütze für ein bestehendes Modell des Systems 100 bereitstellen, welches bereits diese Abhängigkeiten identifiziert hat, oder sie können eine neue Beziehung aufdecken, die in dem Modell nicht definiert ist. Auf diese Art und Weise kann das System-Modell aktualisiert und re-definiert werden, um das Verhalten des Systems 100 besser zu beschreiben. Eine weitergehende Beschreibung hinsichtlich der Verwendung der zuvor erwähnten Data-Mining-Prinzipien in einem Modell-Mining-Zusammenhang wird in der zuvor erwähnten anhängigen Patentanmeldung der Anmelderin gefunden.
Als ein anderes Beispiel der Verwendung der zuvor erwähnten Entscheidungsbäume ist in der 5 eine Streudiagramm-Darstellung von überwachten Werten innerhalb des IT-Systems 100 über die Zeit, im einzelnen über die System-Zugriffszeiten auf die Datenbank 115, gezeigt. Wie es anhand der Darstellung ersichtlich ist, nimmt die Performance über einige Wochen lang ab, mit Hauptzugriffszeiten, die um Faktor zwei, drei und sogar vier zunehmen, obwohl die Performance gut war (die meisten Werte lagen bei einer Sekunde). Von daher wird das zugehörige Service-Level-Agreement (SLA) für die Zugriffs-Datenbank 115 in zunehmendem Maße nicht erfüllt, und eine Analyse der System-Performance ist notwendig, um die Quelle bzw. Quellen des Problems herauszufinden.
Es wird nun auf die 6 Bezug genommen, wo ein anderer Entscheidungsbaum 600 gezeigt wird, der bei der Bewertung der Auswirkungen von verschiedenen System-Attributen sowie bei einer Festlegung der Gesamt-Performance oder der „Gesundheit" des zuvor erwähnten Systems 100 verwendet wird, wie etwa eines Systems, welches die in der 5 gezeigten Performance-Probleme an den Tag legt. Unter Bezugnahme auf den Entscheidungsbaum 600 ist es ersichtlich, dass das wichtigste Attribut in diesem IT-System 100 für eine Abfrage auf die Datenbank 115/B (Stamm-Knotenpunkt 602) die Größe des verfügbaren Funkruf-Raum bzw. Paging-Space ist, ein indirekt beeinflusstes Attribut. Abfragen auf die Datenbank 115 (in einer Abtastgröße von 3.749) resultierten in diesem unterabgerichteten System 100 in einer 41,5%-Erfolgsrate.
Die Zweige des Entscheidungsbaumes 600 von dem Stamm-Knotenpunkt 602, das heißt, ein oberer Zweig oder Element 604 und ein unterer Zweig oder Element 608, definieren ferner Boolesche Attribute für den Paging-Space. Beispielsweise bezeichnet der Knotenpunkt 604, dass, wenn der Paging-Space größer als ein 685,5-Systemwert ist, das Ziel-Element 602, das heißt, die Abfrage auf die Datenbank 115, zu 75,9 der Zeit (über eine Abtastgröße von 1.229) erfüllt wird, und der Knotenpunkt 608 zeigt an, dass, wenn der Paging-Space kleiner als oder gleich 685,5 beträgt, das Attribut des Ziel-Elementes 602 zu 24,7 der Zeit (über eine Abtastgröße von 2.520) erfüllt wird. Eine Aussage kann bereits von dem Entscheidungsbaum 600 getroffen werden, das heißt, die Performance-Verbesserung kann erhöht werden, indem einfach die Hardware erhöht wird, im einzelnen Harddisks und Speicher, wodurch die Möglichkeit, dass der 685,5-Schwellenwert erhöht wird, zunimmt.
Der obere Zweig 604 in 6 ist ferner in zwei Unter-Zweige eingeteilt, das heißt, in einen oberen Unter-Zweig 610 sowie in einen unteren Unter-Zweig 612. Wenn der zentrale Prozessor (CPU) von einem der Server, wie etwa von dem Server, der die Gateway-Datenbank 115 bedient, weniger als 63% von seiner Verfügbarkeit untätig ist (Unter-Zweig 610), dann fällt die Performance auf 36,2 ab (in einer Abtastgröße von 381). Anders ausgedrückt, bedeutet dies, dass wenn die CPU aktiver wird, die System-Performance dementsprechend darunter leidet. Wenn im umgekehrten Fall die CPU zu höher als oder gleich 63% untätig ist, was eine höhere CPU-Verarbeitungs-Performance anzeigt (Unter-Zweig 612), nimmt die System-Performance deutlich auf 94% zu (in einer Abtastgröße von 848). Wie obig beschrieben, wird die Performance-Verbesserung erzielt, indem die Prozessor-Verfügbarkeit sichergestellt wird, beispielsweise indem ein leistungsstärkerer Prozessor oder zusätzliche Prozessoren installiert werden.
Es sollte so verstanden sein, dass die in den 4 und 6 dargestellten vorangehenden Beispiele bloß hypothetische Beispiele und lediglich dafür beabsichtigt sind, die Funktionalität der vorliegenden Erfindung zu demonstrieren. Entscheidungsbäume, die in der vorliegenden Erfindung verwendet werden, würden auf gleiche Weise eine höhere Anzahl an Zweigen und Beziehungen, die durch diese Zweige dargestellt werden, involvieren. Ferner sollte es ersichtlich sein, dass separate Entscheidungsbäume für jedes individuelle, für die Bewertung als Ziel gesetztes Attribut existieren werden, und dass verschiedene Attribute als Ziel gesetzt werden können, was verschiedene Entscheidungsbäume erzeugt, die einen weiteren Einblick in die Funktionalität des Systems 100 bieten, wie es demonstriert wird, wenn die 4 und 6 verglichen werden.
Ferner sollte es so verstanden sein, dass eine Trend- bzw. Tendenz-Analyse durchgeführt werden kann, um potentielle Systemfehler bei einer oder mehreren Zielkomponenten zu einem Zukunfts-Zeitpunkt vorherzusagen. Im einzelnen kann eine Regressions-Analyse an den Parametern, die nahe an dem Stamm-Knotenpunkt, beispielsweise 405 oder 602, liegen, durchgeführt werden, um vorherzusagen, ob oder ob. nicht die Systemkomponente in einem „schlechten" Zweig des Entscheidungsbaumes verbleiben wird, das heißt, ob die Komponente beständig unter der Performance arbeitet. Ebenso sollte es so verstanden sein, dass eine konventionelle Regressions-Analyse bei der Durchführung dieser Vorhersagen verwendet werden kann, beispielsweise indem ein Least-Square-Verfahren verwendet wird, um eine gerade (oder andere) Linie zu berechnen, die die verfügbaren Daten am besten anpasst, wie etwa die Knoten-Parameter in dem Entscheidungsbaum. Dann kann eine zukünftige System-Performance der als Ziel gesetzten Komponenten extrapoliert und die erforderlichen Vorhersagen gemacht werden.
Jedoch liegt bei dem zuvor genannten Schema ein Problem darin, dass ein Attribut durch andere Attribute überschattet wird. Eine Überschattung tritt auf, wenn verschiedene Attribute eine ähnliche Aufteilung für das Ziel-Attribut (die Anfrage auf die Datenbank 115) bewirken. Das bessere Attribut, das heißt, das Attribut, welches die Natur des Zieles besser beschreibt, würde in dem Entscheidungsbaum so erscheinen, als ob die Wirkung des Aufteilens an dem gleichen Attribut entfernt sei. Dieses Ereignis könnte von daher von dem Entscheidungsbaum Attribute aussparen, die äußerst indikativ für die Gesundheit des Gesamtsystems 100 sein können, wie etwa Attribute, die durch das lokal bessere Attribut überschattet werden. Bei einem Versuch, die Wirkungen der Attribut-Überschattung zu vermeiden, kann eine Attribut-Liste konstruiert werden, die jene Attribute identifiziert, welche die besten Indikatoren für die Gesundheit des Systems an den Tag legen. Solch eine Attribut-Liste kann ausgebildet werden, indem wiederholt ein Entscheidungsbaum der Tiefe 1 konstruiert und das erste Attribut des Baumes in die Attribut-Liste gesetzt wird, wobei gleichzeitig das eingeführte Attribut von einer Eingangs-Attribut-Liste entfernt wird. Anders ausgedrückt und unter Bezugnahme auf die 4 und 6 würden die Attribute für Paging-Space und NFS-Dämonen zusammen mit irgendwelchen anderen korrelierten Attributen in die Liste eingeführt werden.
Wie diskutiert, kann eine Anzahl von Vorteilen mit der Erzeugung der zuvor erwähnten Entscheidungsbäume realisiert werden, beispielsweise die Trend- bzw. Tendenz-Analyse zur Vorhersage von zukünftigen Systemfehlern und zum Durchführen von schützenden Wartungsarbeiten. Eine Performance-Optimierung wird leicht bei der Bewertung der Ausgabe der Entscheidungsbäume erkannt, beispielsweise die Zunahme im Speicher und in Dämon-Betriebsmitteln. Da Parameter, die nahe an dem Stamm des Entscheidungsbaumes liegen, im allgemeinen den größten Einfluss auf die Performance haben, sollte es so verstanden sein, dass verschiedene Aktionen vorgeschlagen werden können, um jene Parameter optimal zu beeinflussen. Die Optimierung des Monitors 310 ist ein anderer Vorteil, der von der Implementierung der Prinzipien der vorliegenden Erfindung realisiert werden kann. Basierend auf einer Analyse der Baum-Entscheidungen können verschiedene Monitore 310 mehr oder weniger relevant als andere Monitore hinsichtlich eines bestimmten Service-Level-Agreements (SLA) sein. Die Positionen von diesen Monitoren 310 oder die Monitor-Frequenz der Datenerfassung kann dann entsprechend eingestellt werden, um eine bessere Analyse des Systems 100 zu ermöglichen.
Mit der Funktionalität der vorliegenden Erfindung, die nun beschrieben worden ist, kann ein zusätzliches Verständnis mit weiterer Bezugnahme auf das in der 1 gezeigte System 100 erreicht werden, in welcher die vorliegende Erfindung verwendet werden kann. Indem ein geeignetes Überwachungsschema zur Abfrage der Datenbanken 105 oder 115 erdacht wird, ist es ersichtlich, dass Monitore 310, die Systemzustands-Information aufnehmen, zumindest bei Nutzer-Workstations 140 und 145, bei welchen die Abfragen durchgeführt werden, bei einem Netzwerk-Hub 135 sowie bei den zuvor beschriebenen Servern 110 und 120 erwünscht sein werden. Zustands-Information würde bei einem Minimum dieser Standorte erwünscht sein, da sämtliche direkt in dem Zweig der erforderlichen Kommunikation involviert sind. Mit Monitoren, die bei den zuvor erwähnten Standorten angeordnet sind, würde es möglich sein, Service-Level-Agreements (SLAs) für die Performance von sowohl der Client-Seite als auch Server-Seite zu definieren.
Da ferner eine Aufgabe der vorliegenden Erfindung darin liegt, versteckte oder unerwartete Beziehungen aufzudecken, kann ein Monitor 310 ebenso bei einem Drucker 155 angeordnet sein, der die Workstations 140 und 145 bedient und der mit dem Testprogramm des Service-Level-Agreements (SLA) zur Abfrage der Datenbank 115 oder 105 synchronisiert ist. Obwohl es für den Drucker 155 nicht in typischer Weise erwartet wird, dass er in irgendeiner Beziehung zu der Performance der Workstations 140 und 145 des Nutzers steht, welche die Datenbanken 115 oder 105 abfragen, ist der Drucker 155 physikalisch mit den Workstations 140 und 145, die selber durch das Netzwerk 100 mit den Servern 110 und 120 gekoppelt sind, sowie mit einem anderen Server 160 und potentiell mit vielen weiteren Komponenten über das Netzwerk-Hub 135 gekoppelt. Solch eine Kopplung kann als eine Minimum-Anforderung für funktionelle Interaktion zwischen verschiedenen Elementen des Netzwerkes 100 betrachtet werden. Zusätzlich sei angenommen, dass ein Netzwerk-Drucker 165, der das Netzwerk 100 bedient, nur während bestimmter Stunden des Tages online ist. Während der Stunden, in welchen der Netzwerk-Drucker 165 online ist, würde es erwünscht sein, Zustands-Information von diesem Drucker zu überwachen, um das Service-Level-Agreement (SLA) zu bewerten, das in Zusammenhang mit den abgefragten Datenbanken 105 oder 115 steht.
Obwohl die zuvor erwähnten Service-Level-Agreements (SLAs) hinsichtlich der Server-Seite definiert wurden, zeigt eine Betrachtung der 1, warum es erstrebenswert ist, dass separate Service-Level-Agreements (SLAs) und entsprechende Testprogramme zusätzlich an der Client-Seite definiert sind. Für ein clientseitiges Service-Level-Agreement (SLA), beispielsweise für ein Service-Level-Agreement (SLA) zur Abfrage der Datenbank 105 mit dem Performance-Schwellenwert, der als jene Zeit definiert ist, die für das Anlaufen der Datenbank 105 von einer anfänglichen Nutzer-Anfrage gemessen wird, wird erkannt, dass diese Service-Level-Agreements (SLAs) nicht identisch sein werden. Für dieses clientseitige Service-Level-Agreement (SLA) würde es notwendig sein, der Verzögerung Rechnung zu tragen, die von der clientseitigen Workstation, entweder 140 oder 145, durch den Hub 135 zu dem Server 135 auftritt. Da dieser Kommunikationsweg nicht durchquert wird, wenn von der Server-Seite gemessen wird, ist es angemessen, zu erwarten, dass der Schwellenwert an der Client-Seite für diesen Fall etwas größer als der Schwellenwert der Server-Seite ist. Indem ferner ein clientseitiges Service-Level-Agreement (SLA) vorliegt, das in Zusammenhang mit der gleichen Funktion wie ein Service-Level-Agreement (SLA) steht, das definiert ist, um eine serverseitige Funktion zu bewerten, kann zusätzliche Information aufgedeckt werden. Indem in diesem Beispiel Überwachungsdaten an der clientseitigen Information genommen werden und indem separate Service-Level-Agreements (SLAs) sowie separate Testprogramme, die an der Client-Seite definiert sind, vorliegen, würde Information aufgedeckt werden, die Beziehungen zwischen der speziellen Funktion, den involvierten Servern und Workstations sowie dem Netzwerk-Hub 135 bestimmen könnte. Indem die Testfunktion nur für die Server-Seite definiert und betrieben wird, können die gleichen Beziehungen aufgefunden werden, solange eine Handlung überwacht wird, die Workstation-Zustände und Hub-Zustände enthält, jedoch können solche Beziehungen schneller bestimmt werden, indem Service-Level-Agreements (SLAs) und zugehörige Testprogramme sowohl an der Server-Seite als auch Client-Seite eingeschlossen werden.
In Übereinstimmung mit der vorangehenden Beschreibung, gibt es Service-Level-Agreements (SLAs), die an der Client-Seite und Server-Seite für die beispielhafte Datenbank-Abfragen innerhalb der in der 1 dargestellten Architektur definiert sind, wenn sämtliche Elemente des Netzwerkes 100 funktionieren und überwacht werden. Von daher wird es Testprogramme geben, welche die Client-Seite und Server-Seite einführen, welche diese Anfragen von ihren entsprechenden Seiten des Netzwerkes 100 simulieren. Darüber hinaus sind diese Testprogramme in vorteilhafter Weise mit den zuvor erwähnten Überwachungsaktivitäten bei den zuvor spezifizierten Standorten synchronisiert, welche sämtlich Elemente des Netzwerkes 100, die in der 1 dargestellt sind, begründen.
Jedoch ist das oben Genannte nicht beabsichtigt, um vorzuschlagen, dass bei der Ausführung von jedem definierten SLA-Testprogramm eine Zustandsüberwachung bei jedem verfügbaren Monitor 310 durchgeführt wird. Wenn beispielsweise der Netzwerk-Drucker 165 bei gesteuerten und speziellen Intervallen offline geschaltet wird, ist es nicht notwendig, Zustands-Information an diesem Element aufzunehmen, wenn irgendwelche Testprogramme ausgeführt werden. Darüber hinaus würden auf gleiche Weise Netzwerk-Elemente existieren, die als physikalisch (oder andersartig) von diesen in bestimmten Funktionen involvierten Elementen entkoppelt identifiziert werden. Wenn solche entkoppelten Elemente hinreichend identifiziert sind, wird in der Ausführung des Testprogramms eine Überwachung der Handlung an diesen Elementen nicht notwendig sein.
Durch die Beschreibung der vorliegenden Erfindung hindurch werden im wesentlichen zwei Funktionen sowie die Entwicklung von Schwellenwerten (Service-Level-Agreements SLAs), die Überwachungs-Aktivität sowie die Analyse von solchen Daten, betrachtet. Jedoch sollte es ersichtlich sein, dass die vorliegende Erfindung mehr als solche Funktionen enthalten kann, und zwar mit zugehörigen Testprogrammen, Schwellenwerten, zugehörigen synchronisierten Element-Zustands-Überwachungen und anschließender Analyse und Modell-Modifikation, wie es von einem Fachmann verstanden wird.
Wie beschrieben, kann eine weitere Beschreibung hinsichtlich zusätzlicher Merkmale der bevorzugten Ausführungsformen der vorliegenden Erfindung der anhängigen Patentanmeldung der Anmelderin entnommen werden.

Claims

Verfahren zum Optimieren der Funktions- bzw. Leistungskontrolle in einem Informationstechnologiesystem, welches eine Vielzahl von miteinander verbundener Knotenpunkte aufweist, wobei das Verfahren die folgenden Verfahrensschritte aufweist: (a) Ausführen einer Kontinuitäts-Analyse an dem System; (b) automatisches Erzeugen einer Vielzahl von Funktions- bzw. Leistungsmodellen des Systems basierend auf Testprogrammdaten und vordefinierten Leistungspegeln; (c) kontinuierliches Überwachen bei einer Vielzahl von den Knotenpunkten der Funktion bzw. Leistung des Systems bei der entsprechenden Vielzahl der Knotenpunkte; (d) Erfassen über eine festgelegte Zeitperiode von System-Leistungsdaten an dem System bei den entsprechenden Knotenpunkten; (e) Anwenden einer Vielzahl von Data-Mining-Techniken an den erfassten System-Leistungsdaten und ihren zugehörigen Testprogrammdaten; (f) Erzeugen eines Entscheidungsbaums unter Verwendung der erfassten System-Leistungsdaten und der vordefinierten Leistungspegel, wobei der Entscheidungsbaum eine Vielfalt von Entscheidungs-Knotenpunkten aufweist, von welchen jeder der Entscheidungs-Knotenpunkte einer Komponente des Systems entspricht; (g) Vergleich einer Vielzahl von Beziehungen innerhalb des Systems zwischen den System-Leistungsdaten und den Testprogrammdaten; (h) Modifizieren der Verfahrensschritte des kontinuierlichen Überwachens und des Erfassens der System-Leistungsdaten bei einer Vielzahl von Knotenpunkten, wobei die Modifikation iterativ die Funktions- bzw. Leistungskontrolle des Systems optimiert; und (i) automatisches Aktualisieren eines adaptiven System-Modells gemäß neu entdeckten Beziehungen.
Verfahren nach Anspruch 1, in welchem die Verfahrensschritte (a) bis (i) mehrfach wiederholt werden, wobei die Funktions- bzw. Leistungskontrolle des Systems weiter optimiert wird.
Verfahren nach Anspruch 1, welches ferner vor den Verfahrensschritten des kontinuierlichen Überwachens und des Erfassens den folgenden Verfahrensschritt aufweist: Erzeugen eines Testprogramms gemäß zumindest einer Dienstgütevereinbarung, wobei die Vielzahl der Knotenpunkte zum Überwachen und zum Erfassen der Leistungsdaten gemäß der zumindest einen Dienstgütevereinbarung ausgewählt werden.
Verfahren nach Anspruch 3, in welchem sich das Testprogramm innerhalb des Systems eine Ziel-Komponente zur Zielgruppe nimmt, wobei die Ziel-Komponente von der Gruppe ausgewählt wird, die aus einem System-Hardwarebetriebsmittel sowie einer System-Softwareanwendung besteht.
Verfahren nach Anspruch 4, in welchem die Ziel-Komponente im Wesentlichen einem Stamm-Entscheidungsknotenpunkt des Entscheidungsbaums entspricht.
Verfahren nach Anspruch 4, in welchem die mittels des Testprogramms zur Zielgruppe genommene Ziel-Komponente eine Unterleistung erbringende Systemkomponente ist, wobei der Verfahrensschritt des Modifizierens die Verfahrensschritte des kontinuierlichen Überwachens und Erfassens der Leistungsdaten an der die Unterleistung erbringenden Systemkomponente modifiziert.
Verfahren nach Anspruch 1, in welchem der Verfahrensschritt des Modifizierens die Periodizität der kontinuierlichen Überwachung und Erfassung der Leistungsdaten modifiziert.
Verfahren nach Anspruch 7, in welchem die Periodizität nach der Modifikation zunimmt.
Verfahren nach Anspruch 7, in welchem die Periodizität nach der Modifikation abnimmt.
Verfahren nach Anspruch 1, welches ferner den Verfahrensschritt des Speicherns der Leistungsdaten aufweist.
Verfahren nach Anspruch 10, in welchem die Leistungsdaten mit einer zugehörigen Zeitmarke gespeichert werden.
Verfahren nach Anspruch 10, in welchem die Leistungsdaten in einer relationalen Datenbank gespeichert werden.
Verfahren nach Anspruch 1, in welchem der Verfahrensschritt des Erzeugens des Entscheidungsbaums eine Entscheidungsbaum-Induktion aufweist.
Verfahren nach Anspruch 1, in welchem die Leistungsdaten eine entsprechende Vielzahl von Zustandsinformation bei der Vielzahl der Knotenpunkte aufweisen.
Verfahren nach Anspruch 14, in welchem die Leistungsdaten ferner eine entsprechende Vielzahl der Systeminformation bei der Vielzahl der Knotenpunkte aufweisen.
Verfahren nach Anspruch 15, in welchem die Systeminformation eine Vielzahl von Dienstgütevereinbarungen aufweist.
Verfahren nach Anspruch 1, in welchem in dem Verfahrensschritt des Erfassens die Leistungsdaten bei speziellen Zeitintervallen erfasst werden.
Verfahren nach Anspruch 17, in welchem die speziellen Zeitintervalle zum Erfassen der Leistungsdaten von der Gruppe ausgewählt werden, die aus Tagen, Stunden, Minuten und Sekunden besteht.
Verfahren nach Anspruch 1, in welchem die in dem Verfahrensschritt des Erfassens erfassten Leistungsdaten einen Wert aufweisen, der von der Gruppe ausgewählt ist, die aus reellen Zahlen, Ganzzahlen und Boole'schen Zahlen besteht.
Verfahren nach Anspruch 1, in welchem die in dem Verfahrensschritt des Erfassens erfassten Leistungsdaten in eine Vielzahl von Boole'sche Werte umgewandelt werden.
Verfahren nach Anspruch 20, in welchem die Vielzahl der Boole'schen Werte einer Vielzahl von Leistungs-Grenzkonditionen entsprechen.
Verfahren nach Anspruch 21, in welchem die Leistungs-Grenzkonditionen zuvor festgelegt sind.
Verfahren nach Anspruch 21, in welchem die Leistungs-Grenzkonditionen variabel sind.
Verfahren nach Anspruch 1, in welchem die in dem Verfahrensschritt des Erfassens erfassten Leistungsdaten bei speziellen Zeitintervallen über die vorgegebene Zeitperiode gemittelt werden.
Verfahren nach Anspruch 24, in welchem die gemittelten Leistungsdaten in zumindest einen Boole'schen Wert umgewandelt werden.
Verfahren nach Anspruch 25, in welchem der zumindest eine Boole'sche Wert zumindest einer Dienstgütevereinbarung innerhalb des Systems entspricht.
Verfahren nach Anspruch 1, in welchem in dem Verfahrensschritt des Erzeugens eine Regressions-Analyse an zumindest einer einem Ziel-Knotenpunkt des Entscheidungsbaums entsprechenden Ziel-Komponente durchgeführt wird, wobei die Leistung der zumindest einen Ziel-Komponente bei einer Zukunftszeit von einer Vielzahl von Parameter-Daten innerhalb einer Vielzahl der Entscheidungs-Knotenpunkte vorhergesagt wird.
Informationstechnologiesystem mit einer Vielfalt von miteinander verbundener Knotenpunkte, wobei das System folgendes aufweist: eine Funktions- bzw. Leistungseinrichtung zum Ausführen einer Kontinuitäts-Analyse an dem System; eine Erzeugungseinrichtung zum automatischen Erzeugen einer Vielzahl von Funktions- bzw. Leistungsmodellen des Systems, basierend auf Testprogrammdaten und vordefinierten Leistungspegeln; eine Überwachungseinrichtung, um bei der Vielzahl der Knotenpunkte die Leistung des Systems bei den jeweiligen Knotenpunkten kontinuierlich zu überwachen; eine Erfassungseinrichtung, um bei der Vielzahl der Knotenpunkte Leistungsdaten für das System bei speziellen Zeitintervallen zu erfassen; eine Data-Mining-Technik-Anwendungseinrichtung zum Anwenden einer Vielzahl von Data-Mining-Techniken an den erfassten System-Leistungsdaten und an ihren zugehörigen Testprogrammdaten; eine Entscheidungsbaum-Erzeugungseinrichtung zum Erzeugen eines Entscheidungsbaums unter Verwendung der erfassten System-Leistungsdaten und der vordefinierten Leistungspegel, wobei der Entscheidungsbaum eine Vielfalt von Entscheidungs-Knotenpunkten aufweist, von welchen jeder Entscheidungs-Knotenpunkt einer Komponente des Systems entspricht; eine Vergleichseinrichtung zum Vergleichen einer Vielzahl der Beziehungen innerhalb des Systems zwischen den System-Leistungsdaten und den Testprogrammdaten; eine Modifikationseinrichtung zum Modifizieren von jeweils der Überwachungs- und der Erfassungseinrichtung für die kontinuierliche Überwachung und Erfassung der Leistungsdaten; und eine Aktualisierungseinrichtung zum automatischen Aktualisieren eines adaptiven Systemmodells gemäß neu entdeckter Beziehungen.
System nach Anspruch 28, in welchem die Erfassungseinrichtung folgendes aufweist: eine Testprogramm-Erzeugungseinrichtung zum Erzeugen eines Testprogramms gemäß zumindest einer Dienstgütevereinbarung.
System nach Anspruch 29, in welchem sich das Testprogramm innerhalb des Systems eine Ziel-Komponente zur Zielgruppe nimmt.
System nach Anspruch 30, in welchem die Ziel-Komponente im Wesentlichen einem Stamm-Entscheidungsknotenpunkt des Entscheidungsbaums entspricht.
System nach Anspruch 31, in welchem die Ziel-Komponente von der Gruppe ausgewählt wird, die aus einem System-Hardwarebetriebsmittel und einer System-Softwareanwendung besteht.
System nach Anspruch 31, in welchem die Ziel-Komponente im Wesentlichen einem Stamm-Entscheidungsknotenpunkt des Entscheidungsbaums entspricht.
System nach Anspruch 33, in welchem die mittels des Testprogramms zur Zielgruppe genommene Ziel-Komponente eine Unterleistung erbringende System-Komponente ist, wobei die Modifikationseinrichtung die Überwachung und Erfassung der Leistungsdaten an der die Unterleistung erbringenden Systemkomponente mittels jeweils der Überwachungs- und Erfassungseinrichtung modifiziert.
System nach Anspruch 28, in welchem die Modifikationseinrichtung jeweils die Periodizität der Leistungsdaten-Überwachung und der Leistungsdaten-Erfassung mittels der Überwachungs- und Erfassungseinrichtung modifiziert.
System nach Anspruch 35, in welchem die Periodizität nach der Modifikation zunimmt.
System nach Anspruch 35, in welchem die Periodizität nach der Modifikation abnimmt.
System nach Anspruch 28, welches ferner eine Speichereinrichtung zum Speichern der erfassten Leistungsdaten aufweist.
System nach Anspruch 38, in welchem die Leistungsdaten mit einer zugehörigen Zeitmarke gespeichert werden.
System nach Anspruch 38, in welchem die Speichereinrichtung eine relationale Datenbank ist.
System nach Anspruch 28, in welchem die Entscheidungsbaum-Erzeugungseinrichtung den Entscheidungsbaum unter Verwendung einer Entscheidungsbaum-Induktion erzeugt.
System nach Anspruch 28, in welchem die Leistungsdaten eine entsprechende Vielzahl von Zustandsinformation bei der Vielzahl der Knotenpunkte aufweisen.
System nach Anspruch 42, in welchem die Leistungsdaten ferner eine entsprechende Vielzahl der Systeminformation bei der Vielzahl der Knotenpunkte aufweisen.
System nach Anspruch 43, in welchem die Systeminformation eine Vielzahl von Dienstgütevereinbarungen aufweist.
System nach Anspruch 28, in welchem die Erfassungseinrichtung die Leistungsdaten bei speziellen Zeitintervallen erfasst.
System nach Anspruch 45, in welchem die speziellen Zeitintervalle zum Erfassen der Leistungsdaten von der Gruppe ausgewählt werden, die aus Tagen, Stunden, Minuten und Sekunden besteht.
System nach Anspruch 28, in welchem die mittels der Erfassungseinrichtung erfassten Leistungsdaten einen Wert aufweisen, der von der Gruppe ausgewählt wird, die aus reellen Zahlen, Ganzzahlen und Boole'schen Zahlen besteht.
System nach Anspruch 28, wobei die mittels der Erfassungseinrichtung erfassten Leistungsdaten in eine Vielzahl von Boole'schen Werten umgewandelt werden.
System nach Anspruch 48, in welchem die Vielzahl der Boole'schen Werte einer Vielzahl von Leistungs-Grenzkonditionen entsprechen.
System nach Anspruch 49, in welchem die Leistungs-Grenzkonditionen zuvor festgelegt sind.
System nach Anspruch 50, in welchem die Leistungs-Grenzkonditionen variabel sind.
System nach Anspruch 28, in welchem die mittels solcher Erfassungseinrichtungen erfassten Leistungsdaten bei speziellen Zeitintervallen gemittelt werden.
System nach Anspruch 52, in welchem die gemittelten Leistungsdaten in zumindest einen Boole'schen Wert umgewandelt werden.
System nach Anspruch 53, in welchem der zumindest eine Boole'sche Wert zumindest einer Dienstgütevereinbarung innerhalb des Systems entspricht.
System nach Anspruch 28, in welchem die Entscheidungsbaum-Erzeugungseinrichtung eine Regressions-Analyse an zumindest einer Komponente des Entscheidungsbaums anwendet, wobei die Leistung der zumindest einen Ziel-Komponente bei einer Zukunftszeit von einer Vielzahl von Parameterdaten innerhalb einer Vielzahl der Entscheidungs-Knotenpunkte vorhergesagt wird.
Erzeugnis, welches ein Computer-nutzbares Medium mit einer hierin enthaltenen Computer-lesbaren Programmcode-Einrichtung zum Optimieren der Funktions- bzw. Leistungskontrolle von zumindest einem Knotenpunkt in einem Informationstechnologiesystem aufweist, wobei die Computer-lesbare Programmcode-Einrichtung in dem Erzeugnis folgendes aufweist: eine Computer-lesbare Programmcode-Einrichtung, um: (a) eine Kontinuitäts-Analyse an dem System durchzuführen; (b) eine Vielzahl von Funktions- bzw. Leistungsmodellen des Systems basierend auf Testprogrammdaten und vordefinierten Programmpegeln automatisch zu erzeugen; (c) bei einer Vielzahl von den Knotenpunkten die Leistung des Systems bei der entsprechenden Vielzahl der Knotenpunkte kontinuierlich zu überwachen; (d) über eine vorgegebene Zeitperiode Leistungsdaten an dem System bei den entsprechenden Knotenpunkten zu erfassen; (e) eine Vielzahl von Data-Mining-Techniken an den erfassten System-Leistungsdaten und an ihren zugehörigen Testprogrammdaten anzuwenden; (f) einen Entscheidungsbaum unter Verwendung der erfassten System-Leistungsdaten und der vordefinierten Leistungspegel zu erzeugen, wobei der Entscheidungsbaum eine Vielfalt von Entscheidungs-Knotenpunkten aufweist, von welchen jeder Entscheidungs-Knotenpunkt einer Komponente des Systems entspricht; (g) eine Vielzahl von Beziehungen innerhalb des Systems zwischen den System-Leistungsdaten und den Testprogrammdaten zu vergleichen; (h) die Verfahrensschritte der kontinuierlichen Überwachung und Erfassung der Leistungsdaten bei einer Vielzahl der Knotenpunkte zu modifizieren, wobei die Modifikation iterativ die Funktions- bzw. Leistungskontrolle des Systems optimiert; und (i) ein adaptives Systemmodell gemäß neu entdeckter Beziehungen automatisch zu aktualisieren.
Programmspeichervorrichtung, die mittels einer Vorrichtung lesbar ist und ein Programm mit Anweisungen zum Ausführen der Verfahrensschritte des Patentanspruchs 1 verschlüsselt.
Verfahren nach Anspruch 1, in welchem die neu entdeckten Beziehungen aufgedeckte oder unerwartete Beziehungen sind.
System nach Anspruch 28, wobei die neu entdeckten Beziehungen aufgedeckt oder unerwartete Beziehungen sind.
Verfahren nach Anspruch 1, in welchem das Erfassen der System-Leistungsdaten im Wesentlichen periodisch durchgeführt wird.
System nach Anspruch 28, in welchem das Erfassen der System-Leistungsdaten im Wesentlichen periodisch durchgeführt wird.