DE102012223123B4 - Verhindern einer Fehlerausbreitung - Google Patents

Verhindern einer Fehlerausbreitung Download PDF

Info

Publication number
DE102012223123B4
DE102012223123B4 DE102012223123.4A DE102012223123A DE102012223123B4 DE 102012223123 B4 DE102012223123 B4 DE 102012223123B4 DE 102012223123 A DE102012223123 A DE 102012223123A DE 102012223123 B4 DE102012223123 B4 DE 102012223123B4
Authority
DE
Germany
Prior art keywords
client
command sequence
error
warning message
caused
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102012223123.4A
Other languages
English (en)
Other versions
DE102012223123A1 (de
Inventor
Nicola Milanese
Sandro Piccinini
Fabio De Angelis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE102012223123A1 publication Critical patent/DE102012223123A1/de
Application granted granted Critical
Publication of DE102012223123B4 publication Critical patent/DE102012223123B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Verfahren (100) zum Verhindern einer Ausbreitung eines Fehlers, der von einer Befehlsfolge in einer verteilten Client-Server-Umgebung verursacht wird, wobei das Verfahren aufweist- Ausführen (102) der Befehlsfolge in einem ersten Client, wobei die Befehle von einem Verwaltungssteuerungsserver bereitgestellt werden und auf Wartungsmaßnahmen hinweisen,- Ermitteln (104) eines von der Befehlsfolge verursachten Fehlers durch den ersten Client,- Erzeugen (106) einer Warnmeldung von dem ersten Client basierend auf dem ermittelten Fehler, wobei die Warnmeldung einen Hinweis auf die Befehlsfolge aufweist, und- Senden (108) der Warnmeldung, so dass ein zweiter Client über die Befehlsfolge informiert wird, die den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern.- Empfangen der Warnmeldung durch den zweiten Client, und- Durchführen einer Maßnahme auf der Grundlage der Warnmeldung, wobei das Durchführen einer Maßnahme aufweist- Ermitteln durch den zweiten Client, ob der zweite Client dieselbe Befehlsfolge empfangen hat, und- wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch ist mit der Befehlsfolge, die den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge ausgeführt hat, Ermitteln, ob ein Fehler durch die weitere Befehlsfolge verursacht wurde, und- wenn ein Fehler ermittelt wird, Erzeugen einer weiteren Warnmeldung basierend auf dem ermittelten Fehler und Senden der Warnmeldung, so dass ein weiterer Client über die Befehlsfolge informiert wird, welche den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern,- wenn kein Fehler ermittelt wird, Erzeugen einer Meldung mit Informationen über die weitere Befehlsfolge und Senden der Meldung, um einen weiteren Client zu informieren, die Warnmeldung zu löschen und die Befehlsfolge auszuführen, und- wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch ist mit der Befehlsfolge, die den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge nicht ausgeführt hat, Löschen der weiteren Befehlsfolge.

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung bezieht sich allgemein auf ein Verfahren zum Verhindern einer Fehlerausbreitung und auf ein Verhinderungsmodul.
  • Die Erfindung bezieht sich ferner auf ein Betriebssystem, ein Computersystem, ein Datenverarbeitungsprogramm und ein Computerprogrammprodukt.
  • HINTERGRUND DER ERFINDUNG
  • Im Bereich der verteilten Server-Client-Umgebungen kann das Systemmanagement für die Verwaltung von verteilten Systemen, darunter (im Allgemeinen konkret) Computersysteme, eingesetzt werden. Das Client-Server-Modell kann bei einer verteilten Anwendung verwendet werden, die Aufgaben oder Arbeitslasten zwischen Bereitstellern einer Ressource oder eines Dienstes, d.h. Servern, und Dienstanforderern, d.h. Clients, aufteilt. Oft tauschen Clients und Server Daten über ein Computernetzwerk auf getrennter Hardware aus, wobei jedoch beide, sowohl Client als auch Server, sich im gleichen System befinden können.
  • Solche Systeme können eine Richtlinienverwaltung (policy management) wie zum Beispiel in der Patentschrift US 2007 / 0 180 490 A1 beschrieben verwenden. In diesem Dokument werden ein System und ein Verfahren zum Bereitstellen von Schutzdiensten auf der Grundlage von Richtlinien beschrieben. Wenn eine neue Bedrohung festgestellt wird, werden eine oder mehrere Schutztechniken zum Schützen eines Wertes (asset) in Betracht gezogen, die Organisation verteilt Zuständigkeiten, um den Schutz des Wertes durchzuführen, und eine Richtlinie wird festgelegt. Nachdem die Richtlinie ausgearbeitet ist, wird ein Plan zum Schutz des Wertes ausgeführt und ein Richtlinienimplementierer wird entwickelt und/oder gekauft, verteilt, konfiguriert und verwaltet. Zuletzt werden die Richtlinie, ihre Durchsetzung und Wirksamkeit überprüft, um zu ermitteln, ob Änderungen erforderlich sind, und neue Anforderungen werden festgestellt, wonach der Lebenszyklus abgeschlossen ist. Eine Ausführungsform der Offenbarung stellt ein Verfahren zum gemeinsamen Nutzen einer richtlinienbezogenen Analyse bereit, einschließlich: Feststellen von mindestens einer Bedrohung, einer Schwachstelle und einem Fehler in einer Richtlinie, um eine Richtlinienanforderung zu schaffen; Analysieren der Richtlinienanforderung, um mindestens ein neues Richtlinienelement oder ein überarbeitetes Richtlinienelement zu schaffen; und gemeinsames Nutzen des mindestens einen neuen Richtlinienelements oder überarbeiteten Richtlinienelements.
  • Die Einhaltung spezifischer Richtlinien bei einem Wert ist heutzutage ein kritischer Aspekt für viele Unternehmen. Mehrere Produkte auf dem Markt befassen sich mit diesem Thema und verfolgen mehrere Ansätze, wobei die Lenkung entweder zentral über einen Server erfolgt oder ein Richtlinienansatz angewendet wird, bei dem jeder Agent für die Einhaltung der verteilten Richtlinie verantwortlich ist.
  • Zu einem Beispiel einer richtlinienbezogenen Architektur gehört die sogenannte BigFix-Technologie-Architektur, die vormals von BigFix Inc. vorgestellt wurde. Zu Schlüsselelementen der BigFix-Plattform für die Bereitstellung von Diensten zählen BigFix Agent, BigFix Server and Console, BigFix Fixlet-Nachrichten und BigFix Relays. Die BigFix-Plattform schafft eine Datenübertragungs- und Verwaltungsinfrastruktur zum Bereitstellen von Sicherheits- und Systemverwaltungsdiensten für vernetzte Desktop-, Laptop/Notebook- und Server-Computer. Durch die Zuweisung von Zuständigkeiten für Berichts- und Verwaltungsmaßnahmen an Endpunkten selbst, kann die BigFix-Plattform die Sichtbarkeit und Verwaltung von IT-Infrastrukturen einer großen Zahl von Desktop-, mobilen und Server-Computern sicherstellen. Der BigFix Agent befindet sich in verwalteten Einheiten und fungiert als allgemeine Richtliniensteuerkomponente, die mehrere Verwaltungsdienste bereitstellen kann. Ein einzelner BigFix Agent kann eine vielfältige und umfangreiche Reihe von Verwaltungsdiensten ausführen, die von Echtzeit-Berichten über den Client-Status, über Patch- und Software-Verteilung bis zur Durchsetzung von Sicherheitsrichtlinien reichen.
  • Die BigFix-Architektur dient dazu, Computer in einem gewünschten Zustand zu halten und das Fixlet-Konzept umzusetzen. Ein Fixlet - im weiteren Verlauf des Dokuments als „Fixlets“ bezeichnet - ist ein Objekt mit einer Relevanzanweisung und einer damit verbundenen Maßnahme, das zum Installieren von Software, Aktualisierungen und Patches sowie zum Konfigurieren von Computereigenschaften verwendet wird. Die Relevanz wird im Zusammenhang mit den Clients bewertet, um zu ermitteln, ob das Fixlet anwendbar ist. Wenn ein Administrator das Fixlet aktiviert, wird die Maßnahme durchgeführt, zum Beispiel bei allen irrelevanten Clients, deren Status in nicht anwendbar geändert wird.
  • In einer verteilten Umgebung können mehrere Fixlets täglich und manchmal in Folge aktiviert werden. Die Installationsreihenfolge kann offenkundig von besonderen externen Bedingungen abhängen, die im Wesentlichen auf der Erreichbarkeit jedes Clients in einem speziellen Zeitrahmen oder der dynamischen Zusammensetzung besonderer logischer Gruppen beruhen. Daher kann es vorkommen, dass eine bestimmte Installationsreihenfolge einen Fehler in einem spezifischen System verursacht, das gegebenenfalls auf eine besondere Installationsreihenfolge angewiesen ist.
  • Die Patentschrift US 2004 / 0 019 835 A1 beschreibt eine Fehlerbehandlung in einem Betriebssystem. Die beschriebenen Systeme und Verfahren können für Einzel- oder Multiprozessor-Computersysteme verwendet werden, um Fehler zwischen Hardware und Firmware- oder Software-Schichten koordiniert zu behandeln. Ein Computersystem beinhaltet einen nichtflüchtigen Speicher und mindestens einen Prozessor. In dem nichtflüchtigen Speicher ist eine Firmware-Fehlerbehandlungsroutine gespeichert. Die Firmware-Fehlerbehandlungsroutine dient zum Behandeln von Fehlern. Jeder Prozessor des mindestens einen Prozessors erkennt Fehler. Jeder Prozessor führt die Firmware-Fehlerbehandlungsroutine beim Erkennen eines Fehlers aus. Die ausgeführte Firmware-Fehlerbehandlungsroutine behandelt den Fehler. Die ausgeführte Firmware-Fehlerbehandlungsroutine protokolliert auch Fehlerinformationen in einem Protokoll. Die Systeme und Verfahren stellen eine koordinierte Fehlerbehandlung bereit, die die Fehlerbehebung verbessert, eine Eindämmung von Fehlern sicherstellt und die Verfügbarkeit des Systems gewährleistet.
  • In diesem Zusammenhang wurden bereits Dokumente mit ähnlichen Themen veröffentlicht. Der ITO-Security-Blog-Eintrag vom 27.6.2010
    (http://iotsecuritv.com/blog) beschreibt zum einen, dass die Firma IBM das Unternehmen BigFix Inc. erwirbt und zum anderen, welche Top Five Security Priorities das Industry Analyst Unternehmen Gartner für das Jahr 2010 voraussieht. In diesem Kontext wird auch teilweise auf die Patch-Management-Lösung von BigFix Inc. eingegangen.
  • Das Dokument „Patch Management: An Overview“ von Jason Antman, veröffentlich unter http://rutgerswork.jasonantman.com/stor1-school/2008/Fal108/547_470/\ project/antman-patchManagementAPA.pdf [abgerufen am 4.11.2014] beschreibt einen Überblick über das Thema Patch Management. Dabei wird auf acht unterschiedliche Verfahrensschritte sowie einen Rollout- und Backup-Plan eingegangen.
  • Das Dokument „Staged Deployment in Mirage, an Integrated Software Upgrade Testing and Distribution System‟ von Oliver Crameri et al, veröffentlicht in ACM SIGOPS Operating Systems Review. ACM, 2007. S. 221-236, http://dl.acm.org/\ citation.cfm?id=1294283 [abgerufen am 4.11.2014] beschreibt insbesondere eine Durchführung von Upgrades mittels des softwarebasierten Systems MIRAGE. Dabei wird insbesondere Wert darauf gelegt, dass innerhalb von Clustern eine oder wenige Maschinen den jeweiligen Upgrade zuerst testen, bevor es anderen Maschinen erlaubt wird, die Upgrade-Informationen herunterzuladen und zu testen.
  • Wenn jedoch ein Fehler oder eine Störung bei einem Client auftritt, der bzw. die durch eine Folge von Befehlen oder Fixlets verursacht wird, kann derselbe Fehler bei weiteren Clients auftreten. Dies kann zu einer Verbreitung des Fehlers führen, sollte die gleiche Reihenfolge von Fixlets von einer Vielzahl von Clients ausgeführt werden.
  • Es besteht daher gegebenenfalls der Bedarf nach einem verbesserten Verfahren zum Verhindern einer Ausbreitung von Fehlern, die durch solche Befehle verursacht werden.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Diesem Bedarf kann durch ein Verfahren zum Verhindern einer Ausbreitung eines Fehlers, ein Verhinderungsmodul, ein Computersystem, ein Betriebssystem, ein Datenverarbeitungsprogramm und ein Computerprogrammprodukt gemäß den unabhängigen Ansprüchen nachgekommen werden.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Im Rahmen dieser Anwendung gilt wie folgt:
    • Verteilte Client-Server-Umgebung - Die verteilte Client-Server-Umgebung kann ein Netzwerk von Clients und Server-Computern bezeichnen, das eine Client-Server-Anwendung ausführt, welche das Überwachen und Verwalten von gezielten IT-Systemen von einem zentralen Standort aus ermöglicht. Die Anwendung kann eine Fixlet®-Technologie verwenden, um zum Beispiel fehlerhaft konfigurierte Computer in der Umgebung zu identifizieren, und kann es berechtigten Benutzern ermöglichen, im Netzwerk festgestellte Probleme zu beseitigen.
  • Client - Client kann einen Computer in der verteilten Client-Server-Umgebung bezeichnen oder eine auf jedem Computer (Personal Computer, Server, Workstation, Desktop, Laptop usw.) installierte Anwendung in der Umgebung bezeichnen, die von der Client-Server-Anwendung verwaltet werden kann. Clients können auch als Agenten bezeichnet werden, und beide Begriffe sind gegebenenfalls austauschbar. Clients können Zugriff auf eine Reihe von sogenannten Fixlet-Nachrichten haben, die Sicherheitslücken, Schwachstellen und andere Konfigurationsprobleme erkennen können sowie Nachrichten über Maßnahmen, die von einem Verwaltungssteuerungsserver empfangene Korrekturmaßnahmen umsetzen können.
  • In den meisten Fällen kann der Client still im Hintergrund arbeiten, so dass Benutzer unter Umständen nicht merken, welche Maßnahmen gegebenenfalls in ihrem System stattfinden. Bei einer Ausführungsform können Clients bei einem UDP-Port (UDP = User Datagram Protocol) auf Nachrichten von dem Server warten, die anzeigen, dass gegebenenfalls aktualisierte Daten zum Abrufen bereitstehen. Die Clients können zum Beispiel HTTP zur Verbindung mit Servern verwenden, um Fixlets abzurufen und Ergebnisse über die Anwendung von Fixlets zurück zu einem Server zu schicken.
  • Verwaltungssteuerungsserver - Der Verwaltungssteuerungsserver kann zum Beispiel ein sogenannter BigFix-Server sein, der ein Steuerungszentrum und -Repository für verwaltete Systemkonfigurationsdaten, Software-Aktualisierungen und Patches sowie andere Verwaltungsinformationen bereitstellt. Der Verwaltungssteuerungsserver kann den Clients zum Beispiel Befehle bereitstellen, um beliebige Wartungsmaßnahmen durchzuführen.
  • Befehle - Befehle in diesem Zusammenhang können sich auf BigFix-Fixlet-Nachrichten beziehen, bei denen es sich um Befehle für die Clients zum Durchführen einer Verwaltungs- oder Berichtsmaßnahme handelt. Fixlet-Nachrichten können speziell für besondere Gruppen von Einheiten programmiert werden, um Verwaltungsmaßnahmen durchzuführen. Ein Fixlet kann mit anderen Worten ein Mechanismus sein, um eine problematische Situation auf einem Computer zu erfassen und zu beschreiben und eine automatische Lösung bereitzustellen. Eine Fixlet-Nachricht oder ein Befehl kann eine Bedingung (oder eine Relevanzanweisung) und eine Maßnahme aufweisen, wobei die Maßnahme des Befehls ausgeführt werden könnte, wenn die Bedingung erfüllt werden kann. Wie folgt verwendet, kann eine Befehlsfolge mindestens zwei Befehle oder Fixlet-Nachrichten bezeichnen, die ausgeführt werden.
  • Wartungsmaßnahmen - Wartungsmaßnahmen können eine Änderung kennzeichnen, die an einem System vorgenommen wird, um von Fixlets festgestellte Probleme zu beseitigen. Ein Fixlet, das ein Problem erkennt, kann mehrere unterschiedliche Abhilfemaßnahmen vorschlagen. Ein Fixlet kann zum Beispiel ein fehlendes Windows Service Pack erkennen und eine Maßnahme anbieten, um es herunterzuladen und auf den relevanten Systemen zu installieren. „Windows“ kann ein Betriebssystem von Microsoft Inc. bezeichnen.
  • Fehler - Ein Fehler kann in diesem Zusammenhang jede Art von Fehlfunktion oder Störung sein, die beim Client auftritt.
  • Warnmeldung - Eine Warnmeldung kann jede Art von Signal sein, das eine Warnmeldung bereitstellt. Die Warnmeldung kann Informationen über die Befehlsfolge aufweisen, die einen Fehler verursacht. Bei den Informationen kann es sich entweder um die Befehlsfolge oder um einen Hinweis auf die Befehlsfolge handeln, zum Beispiel eine Zahl.
  • Das oben beschriebene Verfahren zum Verhindern einer Fehlerausbreitung kann eine Reihe von Vorteilen bieten.
  • Es kann insbesondere die Verbreitung oder Ausbreitung von Fehlern vermeiden, die von der gleichen Ursache, z.B. einer besonderen Befehlsfolge, herrühren. Wenn eine besondere Folge daher eine Störung oder einen Fehler vor allem bei einer besonderen Hardware, die zu einem Client gehört, verursacht, kann die Installationshistorie als eine Warnung verwendet werden, die dazu dient, andere Clients zu informieren. Wenn ein Client somit aufgrund der besonderen Konfiguration ein Problem bei einem bestimmten Fixlet (d.h. einer Befehlsfolge) feststellt, kann er einen bzw. weitere Client(s) über dieses Problem informieren. Das Verfahren kann unter Verwendung der aktuellen BigFix-Architektur und mit Bereitstellung der zusätzlichen Fähigkeit implementiert werden, die Informationsfehler zu verbreiten, um eine neue dynamische Anwendbarkeitsbedingung festzulegen.
  • Durch die Anwendung des beschriebenen Verfahrens kann die Verbreitung von Fehlern in einer Gruppe von Computern oder Maschinen vermieden werden, die gegebenenfalls lange Zeit in einem problematischen Zustand verharren, bevor das Installationsproblem beseitigt wird.
  • Bei einer Ausführungsform des Verfahrens kann das Senden der Warnmeldung aufweisen, dass die Warnmeldung zu dem Verwaltungssteuerungsserver gesendet wird und die Warnmeldung von dem Verwaltungssteuerungsserver zu mindestens dem zweiten Client weitergeleitet wird.
  • Das Verfahren kann auf einem server-zentrierten Ansatz beruhen, bei dem ein Administrator eine Liste von Clients festlegen und diese zu jedem Client senden kann, wobei er diese Clients bei einem Fehler benachrichtigt oder es jedem Client ermöglicht, eine Art vertrauenswürdige Clients-Gruppe festzulegen. Wenn bei einer Ausführungsform ein Fixlet im ersten Client nicht installiert wird oder einen Fehler verursacht, kann die Folge der letzten x installierten Fixlets (wobei x ein Wert ist, der entweder manuell oder statistisch konfiguriert sein kann) zu einem oder mehreren Clients gesendet werden. Dies kann über den Server durchgeführt werden, wobei der erste Client die Warnmeldung an den Server senden kann und der Server den zweiten Client und schließlich weitere Clients informieren kann. Oder es kann direkt durchgeführt werden, indem der erste Client die Warnmeldung direkt an den zweiten Client und schließlich an weitere Clients sendet, zum Beispiel auf der Grundlage einer wie oben beschriebenen festgelegten Liste. Der erste Client kann den Server und/oder die gleichrangigen Clients über den Fehler informieren. Der Server kann alle empfangenen Folgen auf der Suche nach Mustern verarbeiten und auf der Grundlage der festgelegten Befehlsfolge alle Computer kennzeichnen, die künftig gegebenenfalls eine Störung aufweisen. Die Computer können zum Beispiel mit einer neuen Anwendbarkeit der Fixlets in Bezug auf einen Warnzustand gekennzeichnet sein.
  • Bei einer weiteren Ausführungsform kann das Verfahren weiterhin aufweisen, dass die Warnmeldung von dem zweiten Client empfangen wird und auf der Grundlage der Warnmeldung eine Maßnahme durchgeführt wird. Der zweite Client kann beliebige Maßnahmen durchführen, wie das Löschen der Befehlsfolge oder das Löschen der Warnmeldung.
  • Bei einer weiteren Ausführungsform kann das Durchführen einer Maßnahme aufweisen, dass der zweite Client ermittelt, ob der zweite Client die gleiche Befehlsfolge empfangen hat.
  • Der zweite Client kann prüfen, ob die vom ersten Client direkt oder indirekt über den Server empfangene Folge gegebenenfalls mit der im lokalen System gespeicherten Folge von Fixlets übereinstimmt. „Im System gespeichert“ kann bedeuten, dass der Client die Liste oder Befehlsfolge gegebenenfalls empfangen und gespeichert hat. Die Folge von Befehlen oder Fixlets kann bereits ausgeführt worden sein oder auch nicht.
  • Bei einer weiteren Ausführungsform kann das Verfahren zusätzlich aufweisen, dass die Warnmeldung gelöscht wird, wenn der zweite Client gegebenenfalls eine weitere Befehlsfolge empfangen hat, die sich von der ersten Befehlsfolge unterscheidet, welche den Fehler verursacht. Wenn die Liste oder Folge eine andere ist, können die Informationen, d.h. die Warnmeldung, gelöscht werden, da sie in diesem Fall nicht anwendbar sind.
  • Bei wieder einer weiteren Ausführungsform kann das Verfahren ferner aufweisen, dass weitere Befehlsfolgen gelöscht werden, wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch mit der Befehlsfolge ist, welche den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge nicht ausgeführt hat.
  • Wenn die Listen oder Folgen übereinstimmen, der Client jedoch die Befehle oder Fixlets, die die Störung oder den Fehler verursachen können, gegebenenfalls nicht ausgeführt hat, wäre es möglich, die Installation oder Ausführung der Befehle zu unterbrechen oder abzubrechen. Bei einer Ausführungsform kann die Folge von Befehlen oder Fixlets bereits auf dem Server mit „anwendbar mit Warnung“ gekennzeichnet sein, so dass der zweite Client gegebenenfalls über den möglichen Fehler informiert ist, bevor die Befehlsfolge abgerufen und gespeichert wird, womit eine Ausbreitung von Fehlern wirksam vermieden wird.
  • Bei einer bevorzugten Ausführungsform kann das Verfahren weiterhin aufweisen, dass ermittelt wird, ob ein Fehler durch die weitere Befehlsfolge verursacht wurde, wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch mit der Befehlsfolge ist, welche den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge ausgeführt hat.
  • Die Befehlsfolge kann gegebenenfalls einen Fehler verursacht haben oder auch nicht. Je nach Fall kann der zweite Client Abhilfemaßnahmen durchführen.
  • Bei einer Ausführungsform kann das Verfahren zusätzlich aufweisen, dass, wenn gegebenenfalls ein Fehler ermittelt wird, eine weitere Warnmeldung basierend auf dem ermittelten Fehler erzeugt wird und die Warnmeldung gesendet wird, um einen weiteren Client über die Befehlsfolge zu informieren, die den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern, oder wenn kein Fehler ermittelt wird, dass eine Meldung mit Informationen über die weitere Befehlsfolge erzeugt wird und die Meldung zum Informieren eines weiteren Client gesendet wird, die Warnmeldung zu löschen und die Befehlsfolge auszuführen.
  • Wenn die Folge von Befehlen oder Fixlets bereits erfolgreich vom zweiten Client installiert wurde, kann der Client weitere Clients benachrichtigen, die Informationen vom ersten Client zu löschen, da der Installationsfehler gegebenenfalls nicht von der Folge selbst verursacht wurde, sondern durch ein anderes Ereignis, zum Beispiel durch ein Hardware-Problem des ersten Client. Die Installation kann daher von weiteren Clients sicher ausgeführt werden.
  • Der zweite Client kann ferner eine Warnmeldung senden, wenn die Befehlsfolge auch beim zweiten Client einen Fehler verursacht haben sollte.
  • Darüber hinaus kann ein Betriebssystem so konfiguriert werden, dass es das Verfahren gemäß dem erfinderischen Verfahren wie oben beschrieben ausführt. Eine solche Integration in ein Betriebssystem kann den Vorteil haben, dass das Verfahren zum Verhindern einer Fehlerausbreitung unmittelbar nach der Installation sofort als eine neue Funktion des Betriebssystems durchgeführt werden kann. Es müssen keine zusätzlichen neuen Betriebssystemprogramme auf dem Computer installiert werden, um eine Ausbreitung von Fehlern zu verhindern, die von Wartungsbefehlen verursacht werden.
  • Es sei darauf hingewiesen, dass Ausführungsformen die Form einer kompletten Hardware-Ausführung, einer kompletten Software-Ausführung oder eine Ausführungsform haben können, bei der Hardware- und Software-Elemente enthalten sind. Bei einer bevorzugten Ausführungsform kann die Erfindung als Software umgesetzt sein, die Firmware, residente Software und Microcode enthält, ohne jedoch darauf beschränkt zu sein.
  • Bei einer anderen Ausführungsform kann ein Datenverarbeitungsprogramm zum Ausführen in einem Datenverarbeitungssystem bereitgestellt werden, das Teile eines Software-Codes zum Durchführen des Verfahrens wie oben beschrieben aufweist, wenn das Programm auf einem Datenverarbeitungssystem ausgeführt werden kann. Bei dem Datenverarbeitungssystem kann es sich um einen Computer oder ein Computersystem handeln.
  • Ausführungsformen können darüber hinaus die Form eines Computerprogrammprodukts haben, auf das von einem computerverwendbaren oder computerlesbaren Medium zugegriffen werden kann, das Programmcode für die Verwendung durch oder in Verbindung mit einem Computer oder einem System zum Ausführen von Befehlen bereitstellt. Ein computerverwendbares oder computerlesbares Medium kann im Sinne dieser Beschreibung eine beliebige Vorrichtung sein, die ein Mittel zum Speichern, Weiterleiten, Verbreiten oder Transportieren des Programms für die Verwendung durch oder in Verbindung mit dem System, der Vorrichtung oder Einheit zum Ausführen von Befehlen enthalten kann.
  • Bei dem Medium kann es sich um ein elektronisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem für ein Verbreitungsmedium handeln. Zu Beispielen für ein computerlesbares Medium können ein Halbleiter- oder ein Festkörperspeicher, ein Magnetband, eine herausnehmbare Computerdiskette, ein Schreib-Lese-Speicher (RAM), ein Nur-Lese-Speicher (ROM), eine starre Magnetplatte und eine optische Platte gehören. Zu aktuellen Beispielen für optische Platten gehören ein Compact-Disk-Nur-Lese-Speicher (CD-ROM), eine wiederbeschreibbare Compact-Disk (CD-R/W) und eine Blu-Ray-Disk.
  • Es sei ferner darauf hingewiesen, dass Ausführungsformen der Erfindung mit Bezug auf verschiedene Gegenstände beschrieben werden. Einige Ausführungsformen werden insbesondere mit Verweis auf Ansprüche beschrieben, die sich auf Verfahren beziehen, während andere Ausführungsformen mit Verweis auf Ansprüche beschrieben werden, die sich auf Vorrichtungen beziehen. Ein Fachmann wird aus dem Obenstehenden und der folgenden Beschreibung erkennen, dass zusätzlich zu einer beliebigen Kombination von Merkmalen, die zu einem Gegenstand gehören, auch eine Kombination von Merkmalen, die sich auf andere Gegenstände beziehen, insbesondere von Merkmalen der Ansprüche in Bezug auf Verfahren und Merkmalen der Ansprüche in Bezug auf Vorrichtungen als in diesem Dokument offenbart gilt, sofern nichts anderes angegeben ist.
  • Die oben definierten Aspekte und weitere Aspekte der vorliegenden Erfindung ergeben sich anhand der Beispiele von im Folgenden beschriebenen Ausführungsformen und werden mit Bezug auf Beispiele von Ausführungsformen erläutert, auf die die Erfindung jedoch nicht beschränkt ist.
  • Figurenliste
  • Bevorzugte Ausführungsformen der Erfindung werden nun lediglich beispielhaft mit Bezug auf die folgenden Zeichnungen beschrieben:
    • 1 zeigt ein Blockschaltbild einer Ausführungsform des erfinderischen Verfahrens zum Verhindern einer Fehlerausbreitung.
    • 2 zeigt ein Blockschaltbild eines verteilten Server-Client-Netzwerks.
    • 3 zeigt eine grafische Darstellung einer Ausführungsform des erfinderischen Verfahrens zum Verhindern einer Fehlerausbreitung.
    • 4 zeigt ein Blockschaltbild einer Ausführungsform des Verhinderungsmoduls.
    • 5 veranschaulicht ein Computersystem, zu dem das erfinderische Verhinderungsmodul gehört.
  • AUSFÜHRLICHE BESCHREIBUNG VON BEISPIELHAFTEN
  • AUSFÜHRUNGSFORMEN
  • Im Folgenden wird eine ausführliche Beschreibung der Figuren bereitgestellt. Alle Illustrationen in den Figuren sind schematisch. Zuerst wird ein Blockschaltbild einer Ausführungsform des Verfahrens zum Verhindern einer Fehlerausbreitung beschrieben. Anschließend werden Ausführungsformen des Verfahrens und des Verhinderungsmoduls beschrieben.
  • 1 zeigt ein Blockschaltbild einer Ausführungsform des erfinderischen Verfahrens 100 zum Verhindern einer Fehlerausbreitung. Der Fehler kann durch eine Folge von Befehlen (Fixlets) verursacht werden. Das Verfahren kann auf eine verteilte Client-Server-Umgebung angewendet werden. Das Verfahren kann das Ausführen 102 der Befehlsfolge in einem ersten Client aufweisen. Die Befehle können von einem Verwaltungssteuerungsserver bereitgestellt werden und auf Wartungsmaßnahmen hinweisen. Ein Befehl kann Informationen über eine Wartungsmaßnahme aufweisen, die im ersten Client ausgeführt werden sollte. Das Verfahren kann weiterhin aufweisen, dass ein von der Befehlsfolge verursachter Fehler durch den ersten Client ermittelt wird 104 und eine Warnmeldung von dem ersten Client basierend auf dem ermittelten Fehler erzeugt wird 106. Die Warnmeldung kann einen Hinweis auf die Befehlsfolge aufweisen. Bei dem Hinweis kann es sich auch um die vollständige Befehlsfolge handeln. Das Verfahren kann des Weiteren aufweisen, dass die Warnmeldung gesendet wird 108, so dass der zweite Client über die den Fehler verursachende Befehlsfolge informiert wird, um eine Ausbreitung des Fehlers zu verhindern.
  • 2 zeigt ein Blockschaltbild 200 eines verteilten Server-Client-Netzwerks. Das Netzwerk kann einen Verwaltungssteuerungsserver 202 aufweisen. Der Verwaltungssteuerungsserver kann verschiedene Befehle, sogenannte Fixlets, wie oben beschrieben bereitstellen. Ein erster Client 204 kann eine Befehlsfolge 206 von dem Verwaltungssteuerungsserver empfangen 220.
  • Beim Ausführen der Befehlsfolge kann der erste Client einen Fehler ermitteln, der von der Befehlsfolge verursacht wird. Der Fehler kann eine beliebige Fehlfunktion im ersten Client sein. Auf der Grundlage des Fehlers kann der erste Client eine Warnmeldung 208 erzeugen. Die Warnmeldung kann einen Hinweis auf die Befehlsfolge aufweisen, beispielsweise die gesamte Folge oder eine Zahl für jeden Befehl der Befehlsfolge. Die Warnmeldung kann einen Hinweis auf die Befehlsfolge aufweisen, die einen Fehler verursacht. Der Hinweis auf die Befehlsfolge kann auf einer Befehlshistorie beruhen. Wie viele Befehle in der gemeldeten Folge enthalten sein können, kann durch eine Konfiguration des Client definiert werden oder kann auf der Grundlage von Protokolldaten berechnet werden oder alternativ speziell für den spezifischen Empfänger angepasst werden. Ein spezifischer Client kann zum Beispiel die letzten drei Befehle benötigen, während ein anderer Client gegebenenfalls die letzten fünf Befehle benötigt. Anschließend kann der erste Client 204 die Warnmeldung an den Verwaltungssteuerungsserver senden 222.
  • Der Verwaltungssteuerungsserver kann die Warnmeldung zu einem zweiten Client 210 senden 226, um den zweiten Client über die Befehlsfolge zu informieren, die den Fehler verursacht. Der zweite Client kann von dem Verwaltungssteuerungsserver bereits eine weitere Befehlsfolge 212 empfangen haben 224. Auf der Grundlage der weiteren Befehlsfolge 212 und der Warnmeldung 214 kann der zweite Client wie in 3 beschrieben über das weitere Vorgehen entscheiden.
  • Zusätzliche Clients können informiert werden. Die Liste mit den zu warnenden Clients kann auf der Grundlage mehrerer Faktoren wie Betriebssystem oder Software-Konfigurationen auf den Clients angelegt werden. In einem spezifischen Unternehmen zum Beispiel können alle Entwickler-Clients in einer Liste mit zu warnenden Clients enthalten sein, da sie ähnlich oder identisch in Bezug auf einen verwendeten Software-Stapel sind. Ein solcher Faktor kann auch andere nützliche Kriterien wie geografische oder topologische Kriterien beinhalten.
  • 3 zeigt eine grafische Darstellung 300 des Verfahrens zum Verhindern einer Fehlerausbreitung. Wenn ein Fehler im ersten Client auftreten sollte, kann eine Warnmeldung an den zweiten Client 302 gesendet werden. Der zweite Client und schließlich auch weitere Clients können prüfen, ob die vom ersten Client empfangene Folge mit einer auf dem lokalen System des zweiten oder der weiteren Clients 304, 308 installierten Befehlsfolge übereinstimmt. Falls die Liste unterschiedlich ist 304, können die Informationen, d.h. die Warnmeldung, gelöscht werden 306, da kein Fehler auf der Grundlage der vom ersten Client ausgeführten Befehlsfolge vorliegen dürfte.
  • Falls die Liste oder Folge übereinstimmt 308, kann ermittelt werden, ob diese Folge gegebenenfalls bereits vom zweiten Client 310, 322 ausgeführt wurde. Für den Fall, dass die Befehlsfolge vom zweiten Client erfolgreich ausgeführt wurde 322, d.h. ohne Fehler 324, kann dieser Client den Server benachrichtigen 326 und damit auch alle anderen Clients und mitteilen, die Informationen vom ersten Client zu löschen, da der Installationsfehler nicht von der Folge, sondern von einem anderen Ereignis verursacht wurde. Die benachrichtigten Clients können dann anschließend diese Befehlsfolge ausführen.
  • Für den Fall, dass die Befehlsfolge ausgeführt wurde 322 und ein Fehler aufgetreten ist 314, kann der zweite Client ermitteln, ob der Server gegebenenfalls bereits benachrichtigt wurde 316. Ist dies nicht der Fall, kann der zweite Client den Server benachrichtigen und bestätigen, dass ein Fehler aufgetreten sein kann 318. In diesem Fall kann der zweite Client die Warnmeldung 320 löschen.
  • Falls die Befehlsfolge bereits empfangen, jedoch noch nicht ausgeführt wurde 310, kann die Installation verhindert 312 und nur ausgeführt werden, sobald der Administrator den Befehl gegebenenfalls erneut aktiviert. Der Befehl oder das Fixlet können als „anwendbar mit Warnung“ gekennzeichnet sein. Diese Kennzeichnung kann entfernt werden, sobald gegebenenfalls festgestellt wird, dass kein Fehler vorliegt.
  • 4 zeigt ein Blockschaltbild 400 einer Ausführungsform des Verhinderungsmoduls zum Verhindern einer Ausbreitung eines Fehlers, der durch eine Befehlsfolge in einer verteilten Client-Server-Umgebung verursacht wird. Das Verhinderungsmodul 400 kann eine Ausführungseinheit 402 aufweisen. Die Ausführungseinheit kann geeignet sein, die Befehlsfolge in einem ersten Client auszuführen. Die Befehle können von einem Verwaltungssteuerungsserver empfangen werden und können auf Wartungsmaßnahmen hinweisen, die vom ersten Client durchgeführt werden sollen.
  • Das Verhinderungsmodul 400 kann des Weiteren eine Ermittlungseinheit 404 aufweisen. Die Ermittlungseinheit kann geeignet sein, einen Fehler zu ermitteln, der von der Befehlsfolge verursacht wird. Das Verhinderungsmodul kann ferner eine Erzeugungseinheit 406 aufweisen, die geeignet ist, eine Warnmeldung basierend auf dem ermittelten Fehler zu erzeugen. Die Warnmeldung kann einen Hinweis auf die Befehlsfolge aufweisen, die den Fehler verursacht.
  • Das Verhinderungsmodul kann des Weiteren eine Sendeeinheit 408 aufweisen, die geeignet ist, die Warnmeldung zu senden, so dass ein zweiter Client über die den Fehler verursachende Befehlsfolge informiert wird, um eine Ausbreitung des Fehlers zu verhindern. Indem der zweite Client oder mehr Clients über die Möglichkeit informiert werden, dass die Befehlsfolge einen Fehler verursacht, können die anderen Clients die Installation oder Ausführung der Befehlsfolge abbrechen. Die Ausbreitung des Fehlers unter einer Vielzahl von Clients in der verteilten Client-Server-Umgebung kann somit verhindert werden.
  • Ein solches Verhinderungsmodul kann auch in einem Computersystem enthalten sein. Auf diese Weise kann das Verhinderungsmodul des Computersystems mit einem Betriebssystem zusammenarbeiten, um das Verfahren zum Verhindern einer Fehlerausbreitung wie oben beschrieben durchzuführen.
  • Ausführungsformen der Erfindung können praktisch in jedem beliebigen Computer umgesetzt werden, unabhängig davon, ob die Plattform für das Speichern und/oder Ausführen von Programmcode geeignet ist. Wie zum Beispiel in 5 veranschaulicht wird, kann ein Computersystem 500 einen oder mehrere Prozessoren 502 mit einem oder mehreren Kernen pro Prozessor, dazugehörige Speicherelemente 504, eine interne Speichereinheit 506 (z.B. eine Festplatte, ein optisches Laufwerk wie beispielsweise ein Compact-Disk-Laufwerk oder digitales Video-Disk-Laufwerk (DVD), einen Flash-Speicher-Stick usw.) und zahlreiche andere Elemente und Funktionalitäten beinhalten, die bei heutigen Computern üblich sind (nicht dargestellt). Die Speicherelemente 504 können einen Hauptspeicher beinhalten, z.B. einen Schreib-Lese-Speicher (RAM), der während der tatsächlichen Ausführung des Programmcodes verwendet wird, sowie einen Cachespeicher, der eine vorübergehende Speicherung von mindestens einem Teil des Programmcodes und/oder Daten bereitstellt, um die Häufigkeit zu verringern, mit der Code und/oder Daten aus einem Langzeit-Speichermedium oder externen Massenspeicher 516 für eine Ausführung abgerufen werden muss bzw. müssen. Elemente im Computer 500 können über ein Bussystem 518 mit entsprechenden Adaptern miteinander verbunden sein. Das Verhinderungsmodul 400 kann darüber hinaus mit dem Bussystem 518 verbunden sein.
  • Das Computersystem 500 kann des Weiteren ein Eingabemittel, beispielsweise eine Tastatur 508, eine Zeigeeinheit wie beispielsweise eine Maus 510 oder ein Mikrofon (nicht dargestellt) beinhalten. Der Computer 500 kann ferner ein Ausgabemittel, beispielsweise einen Monitor oder einen Bildschirm 512 [z.B. eine Flüssigkristallanzeige (LCD), eine Plasmaanzeige, eine lichtemittierende Diodenanzeige (LED) oder einen Kathodenstrahlröhrenmonitor (CRT)], beinhalten. Das Computersystem 500 kann mit einem Netzwerk verbunden sein (z.B. einem lokalen Netz (LAN), einem Weitbereichsnetz (WAN)) wie beispielsweise dem Internet oder einem ähnlichen Netzwerktyp, einschließlich drahtlose Netzwerke über eine Netzwerkschnittstellenverbindung 514. Dies ermöglicht eine Verbindung mit anderen Computersystemen oder einem Speichernetzwerk oder einem Bandlaufwerk. Fachleuten ist ersichtlich, dass es viele verschiedene Arten von Computersystemen gibt und dass die oben genannten Eingabe- und Ausgabemittel andere Formen haben können. Das Computersystem 500 kann allgemein mindestens die Mindestverarbeitungs-, Eingabe- und/oder Ausgabemittel enthalten, die notwendig sind, um die Ausführungsformen der Erfindung umzusetzen.
  • Fachleuten ist des Weiteren ersichtlich, dass sich ein oder mehrere Elemente des oben genannten Computersystems 500 an einem rechnerfernen Standort befinden und mit den anderen Elementen über ein Netzwerk verbunden sein können. Ausführungsformen der Erfindung können weiterhin in einem verteilten System mit einer Vielzahl von Knoten umgesetzt werden, wobei jeder Teil der Erfindung sich in einem anderen Knoten in dem verteilten System befinden kann. Bei einer Ausführungsform der Erfindung entspricht der Knoten einem Computersystem. Alternativ kann der Knoten einem Prozessor mit einem dazugehörigen physischen Speicher entsprechen. Der Knoten kann alternativ einem Prozessor mit einem gemeinsam genutzten Speicher und/oder Ressourcen oder einem Smartphone entsprechen.
  • Software-Befehle zum Umsetzen von Ausführungsformen der Erfindung können in einem computerlesbaren Medium wie beispielsweise einer Compact-Disk (CD), einer Diskette, einem Band oder einer beliebigen anderen computerlesbaren Speichereinheit gespeichert werden.

Claims (8)

  1. Verfahren (100) zum Verhindern einer Ausbreitung eines Fehlers, der von einer Befehlsfolge in einer verteilten Client-Server-Umgebung verursacht wird, wobei das Verfahren aufweist - Ausführen (102) der Befehlsfolge in einem ersten Client, wobei die Befehle von einem Verwaltungssteuerungsserver bereitgestellt werden und auf Wartungsmaßnahmen hinweisen, - Ermitteln (104) eines von der Befehlsfolge verursachten Fehlers durch den ersten Client, - Erzeugen (106) einer Warnmeldung von dem ersten Client basierend auf dem ermittelten Fehler, wobei die Warnmeldung einen Hinweis auf die Befehlsfolge aufweist, und - Senden (108) der Warnmeldung, so dass ein zweiter Client über die Befehlsfolge informiert wird, die den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern. - Empfangen der Warnmeldung durch den zweiten Client, und - Durchführen einer Maßnahme auf der Grundlage der Warnmeldung, wobei das Durchführen einer Maßnahme aufweist - Ermitteln durch den zweiten Client, ob der zweite Client dieselbe Befehlsfolge empfangen hat, und - wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch ist mit der Befehlsfolge, die den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge ausgeführt hat, Ermitteln, ob ein Fehler durch die weitere Befehlsfolge verursacht wurde, und - wenn ein Fehler ermittelt wird, Erzeugen einer weiteren Warnmeldung basierend auf dem ermittelten Fehler und Senden der Warnmeldung, so dass ein weiterer Client über die Befehlsfolge informiert wird, welche den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern, - wenn kein Fehler ermittelt wird, Erzeugen einer Meldung mit Informationen über die weitere Befehlsfolge und Senden der Meldung, um einen weiteren Client zu informieren, die Warnmeldung zu löschen und die Befehlsfolge auszuführen, und - wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch ist mit der Befehlsfolge, die den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge nicht ausgeführt hat, Löschen der weiteren Befehlsfolge.
  2. Verfahren (100) nach Anspruch 1, wobei das Senden (108) der Warnmeldung aufweist, dass die Warnmeldung zu dem Verwaltungssteuerungsserver gesendet wird und die Warnmeldung von dem Verwaltungssteuerungsserver zu mindestens dem zweiten Client weitergeleitet wird.
  3. Verfahren (100) nach Anspruch 1, wobei das Verfahren weiterhin aufweist, - wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die sich von der Befehlsfolge unterscheidet, welche den Fehler verursacht, Löschen der Warnmeldung.
  4. Fehlerverhinderungssystem aufweisend ein Verhinderungsmodul (400) zum Verhindern einer Ausbreitung eines Fehlers, der von einer Befehlsfolge in einer verteilten Client-Server-Umgebung verursacht wird, wobei das Verhinderungsmodul aufweist - eine Ausführungseinheit (402), die geeignet ist, die Befehlsfolge in einem ersten Client auszuführen, wobei die Befehle von einem Verwaltungssteuerungsserver bereitgestellt werden und auf Wartungsmaßnahmen hinweisen, - eine Ermittlungseinheit (404), die geeignet ist, einen von der Befehlsfolge verursachten Fehler durch den ersten Client zu ermitteln, - eine Erzeugungseinheit (406), die geeignet ist, eine Warnmeldung basierend auf dem ermittelten Fehler zu erzeugen, wobei die Warnmeldung einen Hinweis auf die Befehlsfolge aufweist, und - eine Sendeeinheit (408), die geeignet ist, die Warnmeldung zu senden, so dass ein zweiter Client über die Befehlsfolge informiert wird, die den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern. - eine Empfangseinheit in einem zweiten Client, die angepasst ist zum: - Empfangen der Warnmeldung durch den zweiten Client, - Durchführen einer Maßnahme auf der Grundlage der Warnmeldung, - Ermitteln durch den zweiten Client, ob der zweite Client dieselbe Befehlsfolge empfangen hat, - ein Ermittlungsmodul in einem zweiten Client, das angepasst ist zum: - wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch ist mit der Befehlsfolge, die den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge ausgeführt hat, Ermitteln, ob ein Fehler durch die weitere Befehlsfolge verursacht wurde, - wobei das Ermittlungsmodul auch angepasst ist zum: - wenn ein Fehler ermittelt wird, Erzeugen einer weiteren Warnmeldung basierend auf dem ermittelten Fehler und Senden der Warnmeldung, so dass ein weiterer Client über die Befehlsfolge informiert wird, welche den Fehler verursacht, um eine Ausbreitung des Fehlers zu verhindern, - wenn kein Fehler ermittelt wird, Erzeugen einer Meldung mit Informationen über die weitere Befehlsfolge und Senden der Meldung, um einen weiteren Client zu informieren, die Warnmeldung zu löschen und die Befehlsfolge auszuführen, und - wenn der zweite Client eine weitere Befehlsfolge empfangen hat, die identisch ist mit der Befehlsfolge, die den Fehler verursacht, und wenn der zweite Client die weitere Befehlsfolge nicht ausgeführt hat, Löschen der weiteren Befehlsfolge.
  5. Betriebssystem, das so konfiguriert ist, dass es das Verfahren nach einem der Ansprüche 1 bis 3 ausführt.
  6. Computersystem (500), das das Verhinderungsmodul (400) nach Anspruch 4 aufweist.
  7. Datenverarbeitungsprogramm zum Ausführen in einem Datenverarbeitungssystem (500), das Teile von Software-Code zum Durchführen des Verfahrens (100) nach einem der vorherigen Ansprüche 1 bis 3 aufweist, wenn das Programm in einem Datenverarbeitungssystem (500) ausgeführt wird.
  8. Computerprogrammprodukt, das in einem computerverwendbaren Medium gespeichert wird, das computerlesbare Programmmittel aufweist, um einen Computer (500) zu veranlassen, das Verfahren (100) nach einem der Ansprüche 1 bis 3 durchzuführen, wenn das Programm auf dem Computer (500) ausgeführt wird.
DE102012223123.4A 2011-12-14 2012-12-13 Verhindern einer Fehlerausbreitung Active DE102012223123B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP11193443 2011-12-14
EP11193443.6 2011-12-14

Publications (2)

Publication Number Publication Date
DE102012223123A1 DE102012223123A1 (de) 2013-06-20
DE102012223123B4 true DE102012223123B4 (de) 2021-08-19

Family

ID=48522331

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012223123.4A Active DE102012223123B4 (de) 2011-12-14 2012-12-13 Verhindern einer Fehlerausbreitung

Country Status (3)

Country Link
US (1) US9015531B2 (de)
DE (1) DE102012223123B4 (de)
GB (1) GB2499486B (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108737132B (zh) * 2017-04-14 2021-11-23 阿里巴巴(中国)有限公司 一种告警信息处理方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040019835A1 (en) 1999-12-30 2004-01-29 Intel Corporation System abstraction layer, processor abstraction layer, and operating system error handling
US20070180490A1 (en) 2004-05-20 2007-08-02 Renzi Silvio J System and method for policy management

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030065942A1 (en) 2001-09-28 2003-04-03 Lineman David J. Method and apparatus for actively managing security policies for users and computers in a network
US7398272B2 (en) * 2003-03-24 2008-07-08 Bigfix, Inc. Enterprise console
US20080222296A1 (en) 2007-03-07 2008-09-11 Lisa Ellen Lippincott Distributed server architecture
US8966110B2 (en) 2009-09-14 2015-02-24 International Business Machines Corporation Dynamic bandwidth throttling
US8667340B2 (en) 2011-03-29 2014-03-04 Hewlett-Packard Development Company, L.P. Method and system for distributed processing of alerts
JP6019995B2 (ja) * 2012-09-24 2016-11-02 日本電気株式会社 分散システム、サーバ計算機、及び障害発生防止方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040019835A1 (en) 1999-12-30 2004-01-29 Intel Corporation System abstraction layer, processor abstraction layer, and operating system error handling
US20070180490A1 (en) 2004-05-20 2007-08-02 Renzi Silvio J System and method for policy management

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
„Staged Deployment in Mirage, an Integrated Software Upgrade Testing and Distribution System‟ von Oliver Crameri et al, veröffentlicht in ACM SIGOPS Operating Systems Review. ACM, 2007. S. 221-236
ANTMAN, Jason: Patch Management: An overview. 2008. URL: http://rutgerswork.jasonantman.com/stor1-school/2008/Fall08/547_470/project/antman-patchManagementAPA.pdf [abgerufen am 4.11.2014]
CRAMERI, Olivier [et al.]: Staged deployment in mirage, an integrated software upgrade testing and distribution system. In: ACM SIGOPS Operating Systems Review. ACM, 2007. S. 221-236. URL: http://dl.acm.org/citation.cfm?id=1294283 [abgerufen am 4.11.2014]
ITO Security Blog. 27.6.2010. URL: http://itosecurity.com/blog/ [abgerufen am 4.11.2014]

Also Published As

Publication number Publication date
DE102012223123A1 (de) 2013-06-20
US9015531B2 (en) 2015-04-21
US20130159793A1 (en) 2013-06-20
GB2499486A (en) 2013-08-21
GB2499486B (en) 2014-03-12

Similar Documents

Publication Publication Date Title
DE112018003006T5 (de) Erkennung und entschärfung von angriffen von aussen bei der datenverarbeitung
DE112018004349T5 (de) Dynamische auswahl von bereitstellungskonfigurationen von softwareanwendungen
DE102012219363B4 (de) Ereignisvorhersage und Ermittlung von vorbeugenden Maßnahmen in einer vernetzten Datenverarbeitungsumgebung
DE112020004623T5 (de) Ml-basierte ereignishandhabung
US9720999B2 (en) Meta-directory control and evaluation of events
US20170068963A1 (en) System and a method for lean methodology implementation in information technology
DE102017217968A1 (de) Generieren eines Verschiebungsprotokolls für virtuelle Maschinen
DE102021130957A1 (de) Empfehlungen zur stabilität von software-aktualisierungen
DE10393571T5 (de) Verfahren und System zum Validieren logischer End-to-End-Zugriffspfade in Storage Area Netzwerken
DE112020002987T5 (de) Bereitstellen von mikrodiensten über eine dienstinfrastruktur hinweg
DE112010004238T5 (de) Intelligente rollierende Aufrüstung für Datenspeichersysteme
US20100281473A1 (en) Automated software deployment triggered by state differences in distributed systems
DE102021109767A1 (de) Systeme und methoden zur vorausschauenden sicherheit
DE102014114005A1 (de) Risikobeurteilung von Interaktionen von Anwendungen für mobile Einheiten aufgrund von Reputation
DE112019005729T5 (de) Erkennen von sicherheitsrisiken in zusammenhang mit einer software-komponente
DE102016100895A1 (de) Peer-to-Peer-Speicher in Unternehmen und Verfahren zum Verwalten eines Peer-Netzwerkspeichers
DE112018001524T5 (de) Gesundheitsdaten-analysesystem-verwaltung
DE112019001433T5 (de) Datenanonymisierung
DE112020004967T5 (de) Änderungsverwaltung und analytik für microservices
DE112021005636T5 (de) Migrieren von komplexen legacy-anwendungen
US9195535B2 (en) Hotspot identification
DE102021131913A1 (de) Optimieren eines planens einer einheitenaktualisierung
US10719375B2 (en) Systems and method for event parsing
DE112022001326T5 (de) Erzeugen und ausführen von prozessabläufen zum korrigieren von datenqualitätsproblemen in datenbeständen
DE112021003402T5 (de) Blockchain-verwaltung von bereitstellungsfehlern

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0011070000

Ipc: G06F0015163000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0011070000

Ipc: G06F0015163000

Effective date: 20141030

R016 Response to examination communication
R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

R082 Change of representative

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence
R020 Patent grant now final