US8438179B2 - Storage medium storing trouble handling program, and trouble handling apparatus - Google Patents

Storage medium storing trouble handling program, and trouble handling apparatus Download PDF

Info

Publication number
US8438179B2
US8438179B2 US12/491,998 US49199809A US8438179B2 US 8438179 B2 US8438179 B2 US 8438179B2 US 49199809 A US49199809 A US 49199809A US 8438179 B2 US8438179 B2 US 8438179B2
Authority
US
United States
Prior art keywords
handling
history
trouble
information
history information
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.)
Expired - Fee Related, expires
Application number
US12/491,998
Other languages
English (en)
Other versions
US20100070462A1 (en
Inventor
Yuji Wada
Yasuhide Matsumoto
Yukihiro Watanabe
Kuniaki Shimada
Masazumi Matsubara
Kenji Morimoto
Hiroshi Otsuka
Akira Katsuno
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Assigned to FUJITSU LIMITED reassignment FUJITSU LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: OTSUKA, HIROSHI, MORIMOTO, KENJI, KATSUNO, AKIRA, MATSUBARA, MASAZUMI, MATSUMOTO, YASUHIDE, SHIMADA, KUNIAKI, WADA, YUJI, WATANABE, YUKIHIRO
Publication of US20100070462A1 publication Critical patent/US20100070462A1/en
Application granted granted Critical
Publication of US8438179B2 publication Critical patent/US8438179B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/0706—Error 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/0709—Error 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/079—Root cause analysis, i.e. error or fault diagnosis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13163—Fault alarm
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1325—Priority service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13349—Network management

Definitions

  • the technique described in this specification relates to a technique for handling a cause of a trouble having a plurality of symptoms in an information system.
  • the trouble recovery in an information system is generally handled by obtaining a handling method according to a symptom of a trouble from a knowledge base that accumulates past trouble cases, and by actually attempting the method.
  • FIG. 20 is a schematic diagram illustrating a conventional trouble handling method.
  • past trouble cases 1001 are put into knowledge data, which is then registered to a knowledge base 2000 .
  • the knowledge base 2000 stores records each composed of a symptom and its corresponding handling methods.
  • a user 3000 such as a system administrator, etc. inputs a symptom 3003 from a terminal 3001 , etc.
  • the knowledge base 2000 is searched by using the symptom 3003 as a key.
  • a cause, handling methods, etc. are returned to the terminal 3001 of the user 3000 as search results 2003 , and displayed on the screen of the terminal 3001 .
  • a computer-readable portable storage medium on which is stored a trouble handling program for causing a computer to execute a process for putting trouble handling cases occurring in the past in an information system into knowledge data, and for recommending a handling method on the basis of a trouble handling knowledge obtained by putting the trouble handling cases into the knowledge data, and a symptom of a trouble when the trouble occurs, comprises: a searching process for obtaining candidates of a handling method for a trouble requested to be handled by searching the trouble handling knowledge; a recording process for recording to a storing unit a history of handling methods executed for each symptom as handling history information; a priority assigning process for assigning priorities to the candidates of the handling method (handling method candidates), which are obtained by the searching process, with reference to the handling history information; and a process for returning to a handling request source the handling method for the trouble requested to be handled after assigning a priority to the handling method on the basis of priority assignment information obtained by the priority assigning process.
  • a trouble handling apparatus for putting trouble handling cases occurring in the past in an information system into knowledge data, and for recommending a handling method on the basis of a trouble handling knowledge obtained by putting the trouble handling cases into the knowledge data, and a symptom of a trouble when the trouble occurs, comprises: a searching unit for obtaining candidates of a handling method for a trouble requested to be handled by searching the trouble handling knowledge; a recording unit for recording to a storing unit a history of handling methods executed for each symptom as handling history information; a priority assigning unit for assigning priorities to the candidates of the handling method (handling method candidates), which are obtained by the searching unit, with reference to the handling history information stored in the storing unit; and a recommending unit for returning to a handling request source the handling method for the trouble requested to be handled after assigning a priority to the handling method on the basis of priority assignment information obtained by the priority assigning unit.
  • a trouble handling apparatus for putting trouble handling cases occurring in the past in an information system into knowledge data, and for recommending a handling method on the basis of a trouble handling knowledge obtained by putting the trouble handling cases into the knowledge data, and a symptom of a trouble when the trouble occurs, comprises: a handling history management information storing unit for storing handling history management information including a pair of each handling ID and handling history information corresponding to each handling ID; a handling request processing unit for receiving a handling request including a handling ID and a symptom of a trouble from a terminal of a user, and for returning a handling ID and a handling method in response to the handling request; a handling method searching unit for obtaining candidates of a handling method (handling method candidates) corresponding to the symptom of the trouble included in the handling request by searching the trouble handling knowledge; a handling method recommending unit for assigning priorities to the handling method candidates, which are obtained by the handling method searching unit, with reference to the handling history management information recorded in the handling history management information storing unit, for adding a pair of
  • FIG. 1 illustrates a solution image of an aspect (1)
  • FIG. 2 illustrates a solution image of an aspect (2), in which (a) and (b) represent handling method candidates of symptoms 1 and 2 , respectively;
  • FIG. 3 is a schematic diagram (No. 1 ) illustrating the outline of a system according to an embodiment
  • FIG. 4 is a schematic diagram (No. 2 ) illustrating the outline of the system according to the embodiment
  • FIG. 5 is a block diagram illustrating a configuration of a trouble handling system
  • FIG. 6 illustrates a hardware configuration of a computer that implements the trouble handling system according to the embodiment illustrated in FIG. 5 by executing a program
  • FIG. 7 is an entire flow of the trouble handling system
  • FIG. 8 is a flowchart illustrating a process executed by a handling request processing unit of FIG. 5 ;
  • FIG. 9 is a flowchart illustrating a process executed by a handling method updating unit of FIG. 5 ;
  • FIG. 10( a ) illustrates handling history management information before being updated by the handling method updating unit
  • FIG. 10( b ) illustrates arguments received from the handling request processing unit
  • FIG. 10( c ) illustrates the handling history management information after being updated by the handling method updating unit
  • FIG. 11 is a flowchart illustrating a process (corresponding to step S 17 of FIG. 5 ) executed by a handling method recommending unit of FIG. 5 ;
  • FIG. 12 is an explanatory view of a method for recommending a handling method effective also to another symptom being handled with high priority
  • FIG. 13 is an explanatory view (No. 1 ) of a method for calculating a priority in consideration of one handling;
  • FIG. 14 is an explanatory view (No. 2 ) of a method for calculating a priority in consideration of one handling
  • FIG. 15 is an explanatory view (No. 3 ) of a method for calculating a priority in consideration of one handling
  • FIG. 16 is an explanatory view (No. 4 ) of a method for calculating a priority in consideration of one handling
  • FIG. 17 is a flowchart illustrating a process executed by a symptom integrating unit
  • FIG. 18 illustrates a specific example of the process represented by the flowchart of FIG. 17 ;
  • FIG. 19 illustrates an example of a determination method executed in step S 66 of the flowchart of FIG. 17 ;
  • FIG. 20 is a schematic diagram illustrating a conventional trouble handling method.
  • a trouble handling program is a trouble handling program for causing a computer to execute a process for putting trouble handling cases, which occur in the past in an information system, into knowledge data, and for recommending a handling method on the basis of a trouble handling knowledge obtained by putting the trouble handling cases into the knowledge data, and a symptom of a trouble when the trouble occurs.
  • each of the handling histories of the symptoms is organized as an image of a tree structure, and symptoms that pass through a lot of common paths are collected into the same symptom, as described below.
  • symptoms resulting from the same cause are naturally collected into one symptom while being handled. This produces effects such as reductions in manpower required for handling, avoidance of duplicate operations, reductions in time and labor required to collect symptoms, and the like.
  • FIG. 1 illustrates a solution image of the aspect (1).
  • FIG. 1( a ) is a tree structure that represents the handling history of a symptom 1
  • FIG. 1( b ) illustrates a tree structure that represents the handling history of a symptom 2 .
  • the symptom 1 is “late response of a server A”
  • the symptom 2 is “discontinuity of a communication with a server B”.
  • FIGS. 1( a ) and 1 ( b ) common handling methods are portions enclosed with thick-line rectangles. Namely, handling methods 11 , 12 and 13 in the handling history 10 of the symptom 1 , and handling methods 21 , 22 and 23 in the handling history 20 of the symptom 2 are common. Accordingly, in this case, the handling methods 11 ( 21 ), 12 ( 22 ) and 13 ( 23 ) are collected as “a symptom caused by a server C”.
  • FIG. 2 illustrates a solution image of the aspect (2).
  • FIG. 2( a ) illustrates handling method candidates of the symptom 1
  • FIG. 2( b ) illustrates handling method candidates of the symptom 2 .
  • Each of the handling method candidates (handling methods) within a handling method candidate group 30 illustrated in FIG. 2( a ) is extracted from the handling history 10 illustrated in FIG. 1( a ).
  • Each of the handling method candidates (handling methods) within a handling method candidate group 40 illustrated in FIG. 2( b ) is extracted from the handling history 20 illustrated in FIG. 1( b ).
  • FIGS. 2( a ) and 2 ( b ) common handling methods in the handling method candidate groups 30 and 40 are portions enclosed with thick-line rectangles. Namely, the handling methods 31 and 32 within the handling method candidate group 30 , and the handling methods 41 and 42 within the handling method candidate group 40 are common. Accordingly, in this case, the handling methods 31 ( 41 ) and 32 ( 42 ) are determined to be effective in the handlings of the symptoms 1 and 2 , and the priorities of these two handling methods (“line examination” and “server C examination”) are made higher.
  • a user 100 transmits a symptom 110 ( 110 - 1 ), which includes an initial symptom 111 ( 111 - 1 ) “late response of the server A” and a performed handling 112 , from a terminal 101 of the user 100 himself to the trouble handling system 200 according to this embodiment.
  • a handling ID 120 120 - 1
  • none unset
  • also performed handling 112 - 1 is set to “none”.
  • the trouble handling system 200 returns a plurality of handling methods (three handling methods in this example) assigned with priorities to the terminal 101 of the user 100 upon receipt of the handling request 110 - 1 .
  • a handling method 310 - 1 (examination of the number of processes of the server A), a handling method 310 - 2 (examination of the line of the server A), and a handling method 310 - 3 (transmission of ping to the server B) are returned to the terminal 101 of the user 100 .
  • priorities are assigned to the handling methods 310 - 1 , 310 - 2 and 310 - 3 in this order.
  • “ping” used by the handling method 310 - 3 is a command for examining whether or not the server B is properly working on a TCP/IP network.
  • the trouble handling system 200 assigns a handling ID 120 ( 120 - 2 ) having an identifier of ID 111 to the handling methods 310 - 1 to 310 - 3 at this time, and returns the handling ID 120 - 2 to the terminal 101 of the user 100 . Thereafter, the user 100 and the trouble handling system 200 make communications about the trouble at this time by using the handling ID 120 - 2 .
  • the user 100 attempts the above described handling methods 310 - 1 to 310 - 3 upon receipt of these methods from the trouble handling system 200 . Then, as illustrated in FIG. 4 , the user 100 transmits to the trouble handling system 200 a symptom 110 ( 110 - 2 ), which includes a symptom 111 ( 111 - 2 ) proved by the handling at this time (such as “the number of processes of the server A is large”) and handling 112 performed at this time (“examination of the number of processes of the server A”) in addition to the above described initial symptom 111 - 1 .
  • the trouble handling system 200 returns to the terminal 101 of the user 100 a handling method 310 - 4 (“examination of the number of I/Os of the server A”), the above described handling method 310 - 3 , and a handling method 310 - 5 (“transmission of ping to the server C”) along with the handling ID 120 - 2 (ID 111 ).
  • priorities are assigned to the handling methods 310 - 4 , 310 - 3 and 310 - 5 in this order.
  • the user 100 continues to transmit to the trouble handling system 200 the handling request including “the initial symptom”, “a symptom proved by handling”, and “performed handling” by using the handling ID 120 as an identifier as described above until the trouble is solved.
  • the trouble handling system 200 returns handling methods assigned with priorities to the user 100 along with the handling ID 120 each time it receives the handling request from the user 100 .
  • FIG. 5 is a block diagram illustrating a configuration of the trouble handling system 200 illustrated in FIGS. 3 and 4 .
  • the trouble handling system 200 includes a handling request processing unit 210 , a handling method updating unit 220 , a handling method recommending unit 230 , a symptom integrating unit 240 , handling history management information 250 , a handling method searching unit 260 , and a trouble handling knowledge 270 .
  • the handling request processing unit 210 exchanges a handling request and a handling method with the terminal 101 of the user 100 by using the above described method illustrated in FIGS. 3 and 4 .
  • the handling request includes the handling ID 120 and the symptom 110
  • the handling method includes the handling ID 120 and handling methods 310 .
  • the handling request processing unit 210 requests the handling method searching unit 260 to search handling method candidates corresponding to the received symptom upon receipt of the handling request from the terminal 101 of the user 100 .
  • the handling request processing unit 210 requests the handling method updating unit 220 to update a handling method actually executed by the user 100 .
  • the handling request processing unit 210 also requests the handling method updating unit 220 to assign priorities to search results returned from the handling method searching unit 260 .
  • the handling request processing unit 210 requests the symptom integrating unit 240 to integrate a symptom being handled (the symptom handled so far) with the symptom received from the terminal 101 of the user 100 at this time. Then, the handling request processing unit 210 returns the handling ID and the handling methods, which correspond to the integration results of the symptom integrating unit 240 , to the terminal 101 of the user 100 .
  • the handling history management information 250 is a table that manages handling history information about each symptom (history information about handling methods executed in the past) by making the handling history information correspond to a handling ID.
  • the trouble handling knowledge 270 is a database that stores handling methods corresponding to each symptom.
  • the handling method searching unit 260 Upon receipt of a search request from the handling request processing unit 210 , the handling method searching unit 260 searches for the trouble handling knowledge 270 . As a result, the handling method searching unit 260 obtains handling method candidates corresponding to the symptom received from the handling request processing unit 210 . Then, the handling method searching unit 260 returns the obtained candidates to the handling request processing unit 210 .
  • the handling method updating unit 220 Upon receipt of an update request from the handling request processing unit 210 , the handling method updating unit 220 updates the handling history information corresponding to the handling ID within the handling history management information 250 .
  • the handling method recommending unit 230 Upon receipt of a recommendation request from the handling request processing unit 210 , the handling method recommending unit 230 assigns priorities to the handling method candidates searched by the handling method searching unit 260 with reference to the handling history management information 250 . Then, the handling method recommending unit 230 returns the priorities of the respective handling method candidates to the handling request processing unit 210 .
  • the symptom integrating unit 240 receives an integration request from the handling request processing unit 210 . Then, the symptom integrating unit 240 examines whether or not another handling ID within the handling history management information 250 exists which has a handling history information having a lot of portions in handling methods, which are common to handling history management information related to the handling ID currently being processed, by referencing the handling history management information 250 . If such a handling ID exists, the symptom integrating unit 240 integrates the handling history information of this handling ID. Then, the symptom integrating unit 240 returns the integrated handling history information to the handling request processing unit 210 .
  • FIG. 6 illustrates a hardware configuration of a computer that implements the trouble handling system 200 according to this embodiment illustrated in FIG. 5 by executing a program.
  • the computer 500 illustrated in FIG. 6 includes a CPU 501 , a memory 502 , an input device 503 , a display device 504 , an external storage device 505 , a portable storage medium driving device 506 , a network connecting device 507 , and a bus 510 that interconnects the CPU 501 and each of the components 502 to 507 .
  • the CPU 501 is a central processing unit for controlling the operations of the entire system of the computer 500 .
  • the memory 502 is a main storage device having an area into which the program executed by the CPU 501 is loaded, and a working area that stores intermediate data when the program is executed.
  • the input device 503 has a pointing device such as a keyboard, a mouse, etc.
  • the display device 504 is a CRT display, a liquid crystal display, etc.
  • the external storage device 505 is an HDD (Hard Disk Drive), an SSD (Solid State Drive), etc.
  • the portable storage medium driving device 506 is a device that reads/writes the data of a portable storage medium such as a CD (Compact Disc) a DVD (Digital Versatile Disk), a USB (Universal Serial Bus) memory, etc.
  • the network connecting device 507 is a network card, etc. for connecting to a LAN (Local Area Network) built in a data center, an intra-company system, or the like.
  • the LAN is connected to a WAN (Wide Area Network) such as the Internet, a VPN (Virtual Private Network), etc. via a network equipment such as a router, etc.
  • the computer 500 communicates with the terminal 101 of the user 100 according to various types of communication protocols such as TCP/IP, etc. via the network connecting device 507 .
  • the program (trouble handling program) for causing the computer 500 to function as the trouble handling system 200 according to this embodiment is stored on and distributed by a portable storage medium, for example.
  • the program can be downloaded and installed in the external storage device 505 , or a portable storage medium mounted on the portable storage medium driving device 506 via a network such as the Internet, etc.
  • the above described trouble handling program installed in the external storage device 505 , etc. is executed by the CPU 501 with an input operation performed by a system administrator, etc. from the input device 503 via a user interface screen displayed on the display device 504 , for example.
  • the CPU 501 executes the program, whereby the computer 500 implements the respective functions of the handling request processing unit 210 , the handling method updating unit 220 , the handling method recommending unit 230 , the symptom integrating unit 240 and the handling method searching unit 260 , which are included in the trouble handling system 200 illustrated in FIG. 5 .
  • the handling history management information 250 and the trouble handling knowledge 270 are created, for example, within the external storage device 505 or a portable storage medium mounted on the portable storage medium driving device 506 .
  • FIG. 7 is the entire flow of the trouble handling system 200 .
  • the trouble handling system 200 receives a trouble handling request from the terminal 101 of the user 100 (step S 1 ). Then, the trouble handling system 200 returns recommended trouble handling methods to the terminal 101 of the user 100 (step S 2 ).
  • FIG. 8 is a flowchart illustrating the process executed by the handling request processing unit 210 of FIG. 5 .
  • the handling request processing unit 210 executes the process represented by the flowchart of FIG. 8 each time it receives the handling request from the terminal 101 of the user 100 .
  • the handling request processing unit 210 Upon receipt of the handling request from the terminal 101 of the user 100 , the handling request processing unit 210 starts the process of the flowchart represented by FIG. 8 .
  • the handling request includes parameters i and id.
  • i is a parameter indicating a “symptom”.
  • id is a parameter indicating a “handling ID”.
  • the handling ID is an identifier assigned to a trouble currently being handled by the user 100 , and unique in the system. Accordingly, the terminal 101 of the user 100 and the trouble handling system 200 can identify the trouble currently being handled by exchanging the handling ID.
  • the symptom includes “a symptom (initial symptom and symptom proved by handling)”, and “handling performed by the user 100 ”.
  • the handling request processing unit 210 initially determines whether or not id is empty (step S 11 ). If id is empty (“YES” in step S 11 ), the process goes to step S 12 . If id is not empty (“NO” in step S 11 ), the process goes to step S 13 .
  • the “actually executed handling method” in step S 14 is information included in the “symptom” received from the terminal 101 of the user 100 .
  • the handling request processing unit 210 requests the handling method searching unit 260 to search handling methods corresponding to the symptom i in step S 15 .
  • the handling method searching unit 260 searches for the trouble handling knowledge 270 by using the symptom i as a key.
  • the handling method searching unit 260 obtains the handling methods corresponding to the symptom i from the trouble handling knowledge 270 . Then, the obtained search results are returned to the handling request processing unit 210 .
  • the handling request processing unit 210 determines whether or not the search results are empty (step S 16 ). If the search results are not empty (“NO” in step S 16 ) the process goes to step S 17 . If the search results are empty (“YES” in step S 16 ), the process goes to step S 23 .
  • the handling request processing unit 210 requests the handling method recommending unit 230 to assign priorities to the search results in step S 17 .
  • the process of step S 17 will be described in detail later.
  • the handling request processing unit 210 returns “no handling methods” to the terminal 101 of the user 100 in step S 23 . Then, the process of this flowchart is terminated.
  • step S 18 the handling request processing unit 210 determines whether or not id is empty (step S 18 ). If id is not empty (“NO” in step S 18 ), the process goes to step S 19 . If id is empty (“YES” in step S 18 ), the process goes to step S 22 .
  • the process of this step S 18 is a process for determining whether or not the current process is the initial trouble handling process, similar to step S 11 .
  • the trouble handling system 200 according to this embodiment records the history of handling methods corresponding to each trouble to the handling history management information 250 for each trouble of the user 100 .
  • the process of step S 19 can be executed only in response to the second handling request or later made from the terminal 101 of the user 100 . Accordingly, by executing the process of step S 18 , the handling request processing unit 210 determines whether or not to branch the process to step S 19 .
  • the handling request processing unit 210 requests the symptom integrating unit 240 to integrate the symptom being handled (symptom handled so far) with the symptom i.
  • the process of step S 19 will be described in detail later.
  • the symptom integrating unit 240 returns integration results to the handling request processing unit 210 upon termination of the process of step S 19 .
  • the handling request processing unit 210 determines whether or not the symptom i is integrated in step S 19 (step S 20 ). If the symptom i is integrated (“YES” in step S 20 ), the process goes to step S 21 . If the symptom i is not integrated (“NO” in step S 20 ), the process goes to step S 22 .
  • the handling request processing unit 210 returns to the terminal 101 of the user 100 the handling ID of the “symptom being handled”, which is integrated by the symptom integrating unit 240 with the symptom i, and the handling methods of the handling history linked last in the handling history information corresponding to the handling ID. Then, the process of this flowchart is terminated.
  • the handling request processing unit 210 returns to the terminal 101 of the user 100 id′ (handling ID) and handling methods assigned with priorities, which are obtained from the handling method recommending unit 230 , in step S 22 . Then, the process of this flowchart is terminated.
  • the handling request processing unit 210 receives the handling request from the terminal 101 of the user 100 . Then, the handling request processing unit 210 returns to the terminal 101 handling methods for handling the symptom i received from the terminal 101 of the user 100 by assigning priorities to the handling methods while making the requests to the handling method searching unit 260 , the handling method updating unit 220 , the handling method recommending unit 230 and the symptom integrating unit 240 . Additionally, the handling request processing unit 210 records the history information of handling methods, which correspond to each handling ID, in the handling history management information 250 .
  • FIG. 9 is a flowchart illustrating the process executed by the handling method updating unit 220 (corresponding to the step S 14 of FIG. 5 ). The process of this flowchart corresponds to the process of step S 14 of the flowchart illustrated in FIG. 8 .
  • the handling method updating unit 220 receives the parameter i (symptom) and the parameter id (handling ID) from the handling request processing unit 210 as arguments, and starts the process of the flowchart illustrated in FIG. 8 .
  • the handling method updating unit 220 initially determines whether or not information e of “performed handling” is included in i (step S 31 ).
  • the information e corresponds to the “examination of the number of processes of the server A” in the symptom 110 - 2 in the above described FIG. 4 .
  • step S 31 If the handling method updating unit 220 determines that the information e is included (“YES” in step S 31 ), the process goes to step S 32 . If the handling method updating unit 220 determines that the information e is not included (“NO” in step S 31 ), the process of this flowchart is terminated.
  • the handling method updating unit 220 updates the handling method of the last handling history in the handling history information having the handling ID of id, which is recorded in the handling history management information 250 , with the information e (step S 32 ). Then, the process of this flowchart is terminated.
  • the handling method updating unit 220 registers the handling method of the last handling history in the handling history information having the handling ID of id within the handling history management information 250 .
  • FIG. 10 illustrates an example of the process represented by the flowchart of FIG. 9 .
  • (a) and (c) respectively represent handling history management information 250 before being updated, and the handling history management information 250 after being updated.
  • (b) represents the arguments id (handling ID) and i (symptom), which the handling method updating unit 220 receives from the handling request processing unit 210 .
  • the handling history management information 250 is a table for storing records each composed of a handling ID 251 and its corresponding handling history information 252 in each entry.
  • the handling history management information 250 stores records each composed of the pair of a handling ID 251 generated by the handling request processing unit 210 and its corresponding handling history information 252 in the order where handling IDs 251 are generated.
  • the handling history information 252 stores handling methods actually executed by the user 100 in time series.
  • Each handling history stored in the handling history information 252 has a data format of “handling method a, [handling candidate (handling method candidate) a 1 , handling candidate a 2 , . . . ]”.
  • the handling method a is handling (corresponding to the above described information e) actually performed by the user 100 .
  • the handling method a is one of the handling candidates within [ ].
  • handling candidates are arranged in the order of priority within [ ] in each handling history. Handling candidates are hereinafter referred to as handling method candidates in this specification.
  • FIG. 10 illustrates an update example of the handling history information 252 having the handling ID 251 of id 3 . Since handling performed by the user 100 has not been received yet from the terminal 101 of the user 100 , the handling method of the last handling history in the handling history management information 250 - 1 before being updated having the handling ID 251 of id 3 is set to “none” as illustrated in FIG. 10( a ). In this example, the handling request processing unit 210 returns to the terminal 101 of the user 100 “line examination” and “server C examination” as handling methods to be recommended. At this time, the priority of “line examination” is higher than that of “server C examination”.
  • FIG. 11 is a flowchart illustrating the process (corresponding to step S 17 of FIG. 8 ) executed by the handling method recommending unit 230 .
  • the handling method recommending unit 230 receives from the handling request processing unit 210 id′ (handling ID) and C (handling method candidate group) as arguments. Then, a register R is initially set to “empty” (step S 41 ). Here, the register R is a register for storing a handling history. Next, whether or not the argument C is “empty” is determined (step S 42 ). If the argument C is not empty (“NO” in step S 42 ), the process goes to step S 43 . If the argument C is empty (“YES” in step S 42 ), the process goes to step S 52 .
  • step S 43 one handling method candidate c is extracted from C.
  • the handling method candidates c are extracted, for example, in the order of priority.
  • a variable p is initialized to “O” (step S 44 ).
  • the variable p is a variable for storing the numerical value of a priority.
  • information H that is a set of all pieces of handling history information corresponding to handling IDs that are not the same as id′ is extracted from the handling history management information 250 (step S 45 ).
  • step S 46 whether or not the information H is “empty” is determined (step S 46 ). If the information H is not empty (“NO” in step S 46 ), the process goes to step S 47 . If the information H is empty, the process goes to step S 51 .
  • one piece of handling history information h starts to be sequentially extracted from the first row of the information H. Then, whether or not the same handling method candidate as the handling method candidate c exists in the handling history information h is determined (step S 48 ). If the same handling method candidate as the handling method candidate c does not exist in the handling history information h (“NO” in step S 48 ), the process goes back to step S 46 . If the same handling method candidate as the handling method candidate c exists in the handling history information h (“YES” in step S 48 ), the process goes to step S 49 .
  • the handling method recommending unit 230 extracts the next piece of handling history information h from the information H in step S 46 executed at the second time or later. Then, the processes of steps S 47 and S 48 are again executed.
  • the handling method recommending unit 230 examines whether or not the handling method candidate c exists in the handling history information h currently being processed. If the handling method candidate c exists (“YES” in step S 48 ), the process goes to step S 49 .
  • the handling method recommending unit 230 calculates a value p′ in step S 49 .
  • the value p′ is a value used to calculate the weight of the priority p, and set to a value that increases as the priority becomes higher. The calculation of the value p′ will be described in detail later.
  • step S 50 the process goes back to step S 46 .
  • the handling method recommending unit 230 repeats the processes of steps S 46 to S 50 until determining that the information H is empty in step S 46 (“YES” in step S 46 ). As a result, the priority p of each handling method candidate c in the handling method candidate group C is calculated.
  • step S 46 If the handling method recommending unit 230 determines that the information H is empty (“YES” in step S 46 ), the process goes to step S 51 .
  • step S 51 the handling method candidate c is added to R.
  • This addition process is a process for sorting handling method candidates c in descending order of the value of p within R.
  • step S 51 Upon termination of the process in step S 51 , the process goes back to step S 42 , in which the handling method recommending unit 230 determines whether or not the information C is empty. If the information C is not empty (“NO” in step S 42 ), the handling method recommending unit 230 again executes the processes in steps S 43 and later.
  • the handling method recommending unit 230 calculates the priorities p of all of handling method candidates in the handling method candidate group C by repeating the processes in steps S 42 to S 51 . Then, the handling method candidates are arranged in descending order of the priority p within R.
  • step S 42 If the handling method recommending unit 230 determines that C is empty, namely, all the handling method candidates c are extracted from C (“YES” in step S 42 ), the process goes to step S 52 .
  • step S 52 the handling method recommending unit 230 adds R to the handling history management information 250 as handling history information having the handling ID of id′. This addition is made, for example, by registering the above described R to the end of the handling history management information 250 . Then, R is returned to the handling request processing unit 210 (step S 53 ), and the process of this flowchart is terminated.
  • handling method candidates are arranged in the order of priority within R. Accordingly, the handling method candidates arranged in the order of priority are transmitted from the handling method recommending unit 230 to the handling request processing unit 210 .
  • H is empty if id is empty. Therefore, the loop process of steps S 42 through S 46 to S 51 to S 42 is executed by the number of times equal to the number of handling method candidates c. Accordingly, when the initial handling request is received from the terminal 101 of the user 100 , the priorities p of all handling method candidates c corresponding to the initial symptom 111 - 1 of the symptom i are set to 0. Therefore, the priorities p of all the handling method candidates (handling request) corresponding to the initial symptom 111 - 1 become equal. Therefore, search results of the handling method searching unit 260 are set unchanged in R.
  • FIG. 12 illustrates an example of the process executed by the handling method recommending unit 230 .
  • a handling method effective also to other symptoms being handled is recommended with high priority.
  • a handling candidate (handling method candidate) which is included in larger numbers in handling history information 252 corresponding to the other symptoms being handled within the handling history management information 250 , may be obtained by being assigned with a higher priority p.
  • FIG. 12( a ) illustrates contents of handling history management information 250 ( 250 - 5 ) before the handling request processing unit 210 invokes the handling method recommending unit 230 .
  • the handling history management information 250 - 5 indicates the contents of the handling history management information before being updated by the handling method recommending unit 230 .
  • three pieces of handling history information 252 (handling history information respectively having the handling ID 251 of id 1 to id 3 ) being handled are currently registered.
  • the above described information H extracted from the handling history information 252 in step S 45 of the above described flowchart illustrated in FIG. 11 is a set of the handling history information 252 having the handling ID of id 1 , and the handling history information 252 having the handling ID of id 2 .
  • the appearance frequency as a priority p within H is calculated for each of the handling method candidates (server A examination, server B examination and server C examination in this case) within the handling method candidate group C.
  • the process in step S 49 of FIG. 11 is a process for setting p′ to 1 if the handling method candidate c is included in the handling history information h. Therefore, p of “server A examination”, p of “server B examination” and p of “server C examination” respectively result in 1, 0 and 2 as illustrated in FIG. 12( b ). Accordingly, the server C examination, the server A examination and the server B examination are arranged in this order if “server A examination”, “server B examination” and “server C examination” are arranged in descending order of the priority p.
  • the handling history of (none, [server C examination, server A examination, server B examination]) is added in the handling history information 252 having the handling ID 251 of id 3 within the handling history information 252 as illustrated in FIG. 12( c ).
  • the handling method recommending unit 230 returns the above described R to the handling request processing unit 210 (corresponding to the process in step S 53 of FIG. 11) .
  • FIG. 13 illustrates this method.
  • p′ of a handling candidate included in a handling method executed later is set to a value that decreases in decrements of 0.2 if the same handling candidate is included in a plurality of handling methods.
  • handling history information 252 having the handling ID 251 of id 1 within handling history management information 250 - 11 as illustrated in FIG. 13( a ) is exemplified.
  • this handling history information 252 it is recorded that handlings are performed in the order of “server A examination”, “server B examination” and “server C examination”.
  • handling candidates of the server A examination are “server A examination”, “server B examination” and “server C examination”. Additionally, it is recorded that handling candidates of the server B examination are “server B examination” and “server C examination”. Furthermore, it is recorded that a handling candidate of the server C examination is “server C examination”.
  • the handling method candidate group C includes “server A examination”, “server B examination” and “server C examination” as illustrated in FIG. 13( b ).
  • the priority p is calculated for each of the handling methods such as the server A examination, the server B examination and the server C examination in the handling history information 252 having the handling ID 251 of id 1 .
  • the values p′ of “server A examination”, “server B examination” and “server C examination” in the respective handling methods such as the server A examination, the server B examination and the server C examination within the handling history information 252 having the handling ID 251 of id 1 are set to the values illustrated in FIG. 13( a ).
  • the above described three handling method candidates are assigned with priorities in the order of the server C examination, the server B examination and the server A examination.
  • the server C examination, the server B examination and the server A examination, which are assigned with the priorities in this way, are stored in the variable R illustrated in FIG. 11 , and the variable R is returned from the handling method recommending unit 230 to the handling request processing unit 210 .
  • FIG. 14 illustrates a method for calculating the priority p of each handling method candidate within the handling method candidate group C by setting p′ of a handling candidate, which is included in more recent handling candidates within the handling history information 252 , to a higher value.
  • FIG. 14( a ) illustrates handling history management information 250 ( 250 - 13 ) where handling history information 252 , for which the priority p of each handling method candidate in the handling method candidate group C illustrated in FIG. 14( b ) is to be calculated, is recorded.
  • the reference value of p′ is set to 1 and the weight of “1 ⁇ 3” is added to the reference value for a handling candidate of the first handling.
  • the weight of “2 ⁇ 3” is added to the reference value.
  • the weight of “ 3/3” is added to the reference value.
  • the priority p of the server A examination, the priority p of the server B examination, and the priority p of the server C examination in the handling method candidate group C respectively result in 1.3, 1.7 and 2 as illustrated in FIG. 14( c ).
  • the priority p is calculated by being rounded off to the first decimal place.
  • FIG. 15 is an explanatory view of a method for calculating the priority of a handling method candidate by setting p′ of a handling candidate, which is assigned with a higher priority within the handling history management information 250 , to a higher value.
  • handling history information 252 corresponding to the handling ID of id 1 in the handling history management information 250 ( 250 - 15 ) as illustrated in FIG. 15( a ).
  • the handling method candidate group C includes “server A examination”, “server B examination”, and “server C examination” as illustrated in FIG. 15( b ).
  • p′ of the server A examination, p′ of the server B examination, and p′ of the server C examination are respectively set to 1, 0.8 (1 ⁇ 0.2), and 0.6 (1 ⁇ 0.4) as the handling candidates within the handling history information 252 having the handling ID of id 1 in the handling history management information 250 (see FIG. 15( a )).
  • p′ of each handling method candidate is set to a value that decreases in decrements of 0.2 each time the priority becomes low.
  • FIG. 16 is an explanatory view of a method for setting p′ of a handling candidate, which is included in a handling having a lot of common portions to the handling in question within the handling history management information 250 , to a higher value.
  • id′ is “handling ID: 3 ”
  • the handling method candidate group C is ⁇ server A examination, server B examination, server C examination ⁇ as arguments passed from the handling request processing unit 210 to the handling method recommending unit 230 as illustrated in FIG. 16( b ).
  • handling history management information 250 - 17 are those illustrated in FIG. 16( a ).
  • “server 1 examination” and “server 2 examination” are recorded as handling methods in the handling history information 252 having the handling ID 251 of id 3 within the handling history management information 250 .
  • the handling history information 252 having the handling ID 251 of id 1 and the handling history information 252 having the handling ID 251 of id 2 in the handling history management information 250 - 17 are examined.
  • both of “server 1 examination” and “server 2 examination” are recorded as handling methods in the handling history information 252 having the handling ID 251 of id 1 .
  • only “server 2 examination” is recorded in the handling history information 252 having the handling ID 251 of id 2 .
  • the weight of p′ of a handling candidate within the handling history information 252 having the handling ID 251 of id 1 is set to a higher value than that of a handling candidate within the handling history information 252 having the handling ID 251 of id 2 .
  • the weight of each handling candidate corresponding to the handling ID 251 of id 1 , and the weight of each handling candidate corresponding to the handling ID 251 of id 2 are set to “2 ⁇ 5” and “1 ⁇ 5”, respectively.
  • p′ of “server A examination” and p′ of “server B examination”, which correspond to the handling ID 251 of id 1 are set to “1+2 ⁇ 5”.
  • p′ of “server A examination” and p′ of “server C examination”, which correspond to the handling ID 251 of id 2 are set to “1+1 ⁇ 5”.
  • FIG. 17 is a flowchart illustrating the process executed by the symptom integrating unit 240 . This process corresponds to the process of step S 19 illustrated in FIG. 8 .
  • the symptom integrating unit 240 receives the parameter id (handling ID) from the handling request processing unit 210 , and starts the process represented by the flowchart of FIG. 17 .
  • the symptom integrating unit 240 initially determines whether or not id is empty (step S 61 ). If id is not empty (“NO” in step S 61 ) the process goes to step S 62 . If id is empty (“YES” in step S 61 ) the process goes to step S 68 .
  • the determination made in step S 61 is similar to the process of step S 11 represented by the above described flowchart of FIG. 8 .
  • the symptom integrating unit 240 extracts information h having the handling ID 251 of id from the handling history management information 250 in step S 62 .
  • information H other than h is obtained from the handling history management information 250 (step S 63 ), and whether or not the information H is empty is determined (step S 64 ). If the information H is not empty (“NO” in step S 64 ), the process goes to step S 65 . If the information H is empty (“YES” in step S 64 ) the process goes to step S 68 .
  • the symptom integrating unit 240 extracts the first h′ from the information H in step S 65 .
  • This h′ is information composed of a pair of the handling ID 251 and its corresponding handling history information 252 , similar to the above described h. Then, a comparison is made between the handling history information 252 of h and the handling history information 252 of h′, and whether or not they have a lot of common portions is determined (step S 66 ). If they have a lot of common portions (“YES” in step S 66 ), the process goes to step S 67 . If they don't have a lot of common portions (“NO” in step S 66 ), the process goes back to step S 64 . The process of step S 66 will be described in detail later.
  • the symptom integrating unit 240 repeats the processes of steps S 64 to S 66 until determining that H is empty, namely, h′ to be extracted from H does not exist any more (“YES” in step S 64 ), or determining that the handling history information 252 of h and the handling history information 252 of h′ have a lot of common portions (“YES” in step S 66 ).
  • the symptom integrating unit 240 integrates h with h′ in step S 67 , and returns the status of “symptom to be integrated exists” and h′ to the handling request processing unit 210 . Then, the process of this flowchart is terminated.
  • the symptom integrating unit 240 returns the status of “no symptom to be integrated” to the handling request processing unit 210 in step S 68 . Then, the process of this flowchart is terminated.
  • FIG. 18 illustrates a specific example of the above described process of the flowchart illustrated in FIG. 17 .
  • FIG. 18( a ) illustrates handling history management information 250 ( 250 - 19 ) before being integrated by the symptom integrating unit 240 .
  • FIG. 18( b ) illustrates the argument id that the symptom integrating unit 240 receives from the handling request processing unit 210 .
  • FIG. 18( c ) illustrates the handling history management information 250 ( 250 - 21 ) after being integrated by the symptom integrating unit 240 .
  • the symptom integrating unit 240 receives the handling ID of id 3 as the argument id from the handling request processing unit 210 as illustrated in FIG. 18( b ). Accordingly, information h having the handling ID 251 of id 3 in the handling history management information 250 ( 250 - 19 ) illustrated in FIG. 18( a ) is to be integrated.
  • the information H other than h is composed of information having the handling ID 251 of id 1 and information having the handling ID 251 of id 2 in the handling history management information 250 - 19 . Accordingly, the information h′ having the handling ID 251 of id 1 , and the information h′ having the handling ID 251 of id 2 are sequentially extracted from the information H.
  • the handling history information 252 having a lot of common portions to the handling history information 252 of the information h is the handling history information 252 of the information h′ having the handling ID 251 of id 2 as illustrated in FIG. 18( a ).
  • “server D examination”, “examination of the number of processes of the server D”, “examination of the number of I/Os of the server D”, and “none” are common in the respective handling methods within the respective handling history information 252 .
  • the information h having the handling ID 251 of id 3 is integrated with the information h′ having the handling ID of id 2 as illustrated in FIG. 18( c ).
  • FIG. 19 illustrates an example of the determining method executed in step S 66 of the flowchart illustrated in FIG. 17 .
  • “history 1 ” and “history 2 ” respectively indicate the handling history information 252 of the information h, and the handling history information 252 of the information h′.
  • A, B, C, D and E indicate handling methods within the handling history information 252 .
  • a ⁇ B ⁇ C ⁇ D ⁇ E indicates that the handling methods are executed in the order of A, B, C, D and E.
  • FIG. 19( a ) illustrates an example where a lot of common portions are determined to exist if the ratio of common portions to the entire handling history information 252 is equal to or larger than a certain value.
  • the certain value is set to 50 percent.
  • FIG. 19( b ) illustrates an example where a lot of common portions are determined to exist if the handling history (handling method history) of one piece of handling history information 252 matches a forward portion of the handling history of another piece of handling history information 252 .
  • the handling history “A ⁇ B ⁇ C” of the history 2 matches the forward portion of the handling history “A ⁇ B ⁇ C ⁇ D ⁇ E” of the history 1 .
  • the ratio of the forward match portion is 60 percent. Since the reference value (certain value) of the forward match portion is set to 50 percent in this example, the handling histories of the history 1 and the history 2 are determined to have a lot of common portions.
  • FIG. 19( c ) illustrates an example where a lot of common portions are determined to exist if the handling history (handling method history) of one piece of handling history information 252 is included in another piece of handling history information 252 .
  • the handling history of the history 1 is “A ⁇ B ⁇ C ⁇ D ⁇ E”.
  • the handling history of the history 2 is “B ⁇ C ⁇ D”.
  • the handling history of the history 2 is included in the history 1 , and the ratio of the handling history of the history 2 to the entire handling history of the history 1 is 60 percent. Since the reference value (certain value) of the inclusion ratio is set to 50 percent in this example, a lot of common portions are determined to exist.
  • FIG. 19( d ) illustrates an example where a lot of common portions are determined to exist if the handling history of one piece of handling history information 252 matches a backward portion of the handling history of another piece of handling history information 252 .
  • the handling history of the history 1 is “A ⁇ B ⁇ C ⁇ D ⁇ E”.
  • the handling history of the history 2 is “C ⁇ D ⁇ E”.
  • the handling history of the history 2 matches the backward portion of the history 1
  • the ratio of the backward match portion of the history 2 to the entire handling history of the history 1 is 60 percent. Since the reference value (certain value) of the ratio of the backward match portion to the entire handling history is set to 50 percent in this example, a lot of common portions are determined to exist.
  • This embodiment automatically integrates symptoms resulting from the same cause during handling. This can reduce manpower required for the integration. Moreover, a handling method effective also to other symptoms is recommended with higher priority in consideration of the other symptoms simultaneously in progress. As a result, a total handling time required for a trouble that causes a plurality of symptoms can be reduced. Accordingly, the disclosed program and method can efficiently handle a trouble that causes a plurality of symptoms in an information system.
  • Embodiment according to the present invention is not limited to the above described embodiments, and can be modified and implemented in a variety of ways within the scope that does not depart from the spirit of the present invention.
  • the method for calculating the priority p is not limited to the above described embodiments.
  • the method for determining that a lot of common portions exist is not limited to the methods referred to in the above described embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Biomedical Technology (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
US12/491,998 2008-09-17 2009-06-25 Storage medium storing trouble handling program, and trouble handling apparatus Expired - Fee Related US8438179B2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-238221 2008-09-17
JP2008238221A JP5439775B2 (ja) 2008-09-17 2008-09-17 障害対応プログラム、障害対応装置、及び障害対応システム

Publications (2)

Publication Number Publication Date
US20100070462A1 US20100070462A1 (en) 2010-03-18
US8438179B2 true US8438179B2 (en) 2013-05-07

Family

ID=41008356

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/491,998 Expired - Fee Related US8438179B2 (en) 2008-09-17 2009-06-25 Storage medium storing trouble handling program, and trouble handling apparatus

Country Status (3)

Country Link
US (1) US8438179B2 (ja)
JP (1) JP5439775B2 (ja)
GB (1) GB2463546B (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150149822A1 (en) * 2013-11-26 2015-05-28 International Business Machines Corporation Event handling in storage area networks

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014103071A1 (ja) 2012-12-28 2014-07-03 富士通株式会社 対処方法作成プログラム、対処方法作成方法、及び情報処理装置
US10263836B2 (en) * 2014-03-24 2019-04-16 Microsoft Technology Licensing, Llc Identifying troubleshooting options for resolving network failures
US10067812B2 (en) * 2015-03-30 2018-09-04 Ca, Inc. Presenting diagnostic headlines using simple linguistic terms
US9979607B2 (en) * 2015-06-22 2018-05-22 Ca, Inc. Diagnosing anomalies based on deviation analysis
JP2020181505A (ja) * 2019-04-26 2020-11-05 富士通株式会社 インシデント対応支援プログラム、インシデント対応支援装置およびインシデント対応支援方法
US11775367B2 (en) 2019-07-08 2023-10-03 Nippon Telegraph And Telephone Corporation Automatic cooperation apparatus, automatic cooperation method and automatic cooperation program

Citations (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4633467A (en) * 1984-07-26 1986-12-30 At&T Bell Laboratories Computer system fault recovery based on historical analysis
US5214653A (en) * 1990-10-22 1993-05-25 Harris Corporation Fault finder expert system
US5253184A (en) * 1991-06-19 1993-10-12 Storage Technology Corporation Failure and performance tracking system
JPH08221295A (ja) 1995-02-13 1996-08-30 Mitsubishi Electric Corp 障害支援装置
US5799317A (en) * 1995-11-08 1998-08-25 Mci Communications Corporation Data management system for a telecommunications signaling system 7(SS#7)
US6012152A (en) * 1996-11-27 2000-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Software fault management system
US6324659B1 (en) * 1999-10-28 2001-11-27 General Electric Company Method and system for identifying critical faults in machines
US6343236B1 (en) 1999-04-02 2002-01-29 General Electric Company Method and system for analyzing fault log data for diagnostics
US6415395B1 (en) * 1999-04-02 2002-07-02 General Electric Company Method and system for processing repair data and fault log data to facilitate diagnostics
US6446224B1 (en) * 1995-03-03 2002-09-03 Fujitsu Limited Method and apparatus for prioritizing and handling errors in a computer system
US6631384B1 (en) * 2000-09-05 2003-10-07 Algoplus Consulting Limited Information system and method using analysis based on object-centric longitudinal data
US6651034B1 (en) * 1999-10-28 2003-11-18 General Electric Company Apparatus and method for performance and fault data analysis
US6895585B2 (en) * 2001-03-30 2005-05-17 Hewlett-Packard Development Company, L.P. Method of mixed workload high performance scheduling
US6912676B1 (en) * 1999-09-02 2005-06-28 International Business Machines Automated risk assessment tool for AIX-based computer systems
GB2412271A (en) 2004-03-18 2005-09-21 Fujitsu Ltd Estimating network troubles
US7143316B2 (en) * 2002-07-19 2006-11-28 Hewlett-Packard Development Company, L.P. Fault diagnosis in a network
US7237138B2 (en) * 2000-05-05 2007-06-26 Computer Associates Think, Inc. Systems and methods for diagnosing faults in computer networks
US20070276631A1 (en) 2006-05-23 2007-11-29 International Business Machines Corporation Causal ladder mechanism for proactive problem determination, avoidance and recovery
US20070294003A1 (en) * 2006-06-14 2007-12-20 Underdal Olav M Reverse failure analysis method and apparatus for diagnostic testing
US7409595B2 (en) * 2005-01-18 2008-08-05 International Business Machines Corporation History-based prioritizing of suspected components
US20090157678A1 (en) * 2007-12-18 2009-06-18 Mladen Turk Content Based Load Balancer
WO2009122525A1 (ja) 2008-03-31 2009-10-08 富士通株式会社 トラブル対処システム、方法およびそのためのプログラム
US8271402B2 (en) * 2006-12-30 2012-09-18 Troppus Software Corporation Technical support agent and technical support service delivery platform

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4237076B2 (ja) * 2004-02-17 2009-03-11 Ｎｅｃパーソナルプロダクツ株式会社 エラー処理システム、エラー対応情報処理装置、情報端末、エラー処理方法、プログラム
JP4239989B2 (ja) * 2005-03-07 2009-03-18 日本電気株式会社 障害復旧システム、障害復旧装置、ルール作成方法、および障害復旧プログラム

Patent Citations (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4633467A (en) * 1984-07-26 1986-12-30 At&T Bell Laboratories Computer system fault recovery based on historical analysis
US5214653A (en) * 1990-10-22 1993-05-25 Harris Corporation Fault finder expert system
US5253184A (en) * 1991-06-19 1993-10-12 Storage Technology Corporation Failure and performance tracking system
JPH08221295A (ja) 1995-02-13 1996-08-30 Mitsubishi Electric Corp 障害支援装置
US6446224B1 (en) * 1995-03-03 2002-09-03 Fujitsu Limited Method and apparatus for prioritizing and handling errors in a computer system
US5799317A (en) * 1995-11-08 1998-08-25 Mci Communications Corporation Data management system for a telecommunications signaling system 7(SS#7)
US6012152A (en) * 1996-11-27 2000-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Software fault management system
US6343236B1 (en) 1999-04-02 2002-01-29 General Electric Company Method and system for analyzing fault log data for diagnostics
US6415395B1 (en) * 1999-04-02 2002-07-02 General Electric Company Method and system for processing repair data and fault log data to facilitate diagnostics
US6912676B1 (en) * 1999-09-02 2005-06-28 International Business Machines Automated risk assessment tool for AIX-based computer systems
US6324659B1 (en) * 1999-10-28 2001-11-27 General Electric Company Method and system for identifying critical faults in machines
US6651034B1 (en) * 1999-10-28 2003-11-18 General Electric Company Apparatus and method for performance and fault data analysis
US7237138B2 (en) * 2000-05-05 2007-06-26 Computer Associates Think, Inc. Systems and methods for diagnosing faults in computer networks
US6631384B1 (en) * 2000-09-05 2003-10-07 Algoplus Consulting Limited Information system and method using analysis based on object-centric longitudinal data
US6895585B2 (en) * 2001-03-30 2005-05-17 Hewlett-Packard Development Company, L.P. Method of mixed workload high performance scheduling
US7143316B2 (en) * 2002-07-19 2006-11-28 Hewlett-Packard Development Company, L.P. Fault diagnosis in a network
GB2412271A (en) 2004-03-18 2005-09-21 Fujitsu Ltd Estimating network troubles
US7409595B2 (en) * 2005-01-18 2008-08-05 International Business Machines Corporation History-based prioritizing of suspected components
US20070276631A1 (en) 2006-05-23 2007-11-29 International Business Machines Corporation Causal ladder mechanism for proactive problem determination, avoidance and recovery
US20070294003A1 (en) * 2006-06-14 2007-12-20 Underdal Olav M Reverse failure analysis method and apparatus for diagnostic testing
US8271402B2 (en) * 2006-12-30 2012-09-18 Troppus Software Corporation Technical support agent and technical support service delivery platform
US20090157678A1 (en) * 2007-12-18 2009-06-18 Mladen Turk Content Based Load Balancer
WO2009122525A1 (ja) 2008-03-31 2009-10-08 富士通株式会社 トラブル対処システム、方法およびそのためのプログラム
US20110016355A1 (en) 2008-03-31 2011-01-20 Fujitsu Limited System, method and computer readable storage medium for troubleshooting

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Office Action issued from the UK Patent Office in corresponding UK Patent Application No. GB0911136.0, mailed Mar. 19, 2012.

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150149822A1 (en) * 2013-11-26 2015-05-28 International Business Machines Corporation Event handling in storage area networks
US9619311B2 (en) * 2013-11-26 2017-04-11 International Business Machines Corporation Error identification and handling in storage area networks

Also Published As

Publication number Publication date
GB2463546B (en) 2012-11-28
GB0911136D0 (en) 2009-08-12
JP2010072834A (ja) 2010-04-02
GB2463546A (en) 2010-03-24
US20100070462A1 (en) 2010-03-18
JP5439775B2 (ja) 2014-03-12

Similar Documents

Publication Publication Date Title
US8438179B2 (en) Storage medium storing trouble handling program, and trouble handling apparatus
US8645356B2 (en) Adaptive query execution plan enhancement
CN111897638B (zh) 分布式任务调度方法及系统
US20090006066A1 (en) Method and System for Automatic Selection of Test Cases
US20150222731A1 (en) Computer, guide information providing method and recording medium
US20160019265A1 (en) Database consolidation advisor
CN104572069A (zh) 对描述数据中心中的配置项之间的依赖关系的信息进行实时分布式管理的方法和系统
US20150178359A1 (en) Intelligently provisioning cloud information services
JP2014191604A5 (ja)
US20110113429A1 (en) Incident management method and operation management server
KR20150084892A (ko) 동적 그래프 퍼포먼스 모니터링
US20070050425A1 (en) Log management program of a computer, log management method thereof, and computer system
JP6692454B2 (ja) 継続的インテグレーションシステム及びリソース制御方法
KR20150087265A (ko) 동적 컴포넌트 퍼포먼스 모니터링
US20160006633A1 (en) Monitoring item selection method and device, and storage medium
CN110069406A (zh) 自动触发的tpc-ds测试方法以及系统
CN112860496A (zh) 故障修复操作推荐方法、装置及存储介质
JP5061671B2 (ja) 演算プログラム、分散処理プログラム、分散処理システムおよび演算処理方法
CN113495723B (zh) 一种调用功能组件的方法、装置及存储介质
US20200210307A1 (en) Method for automatically analyzing bottleneck in real time and an apparatus for performing the method
JP7068210B2 (ja) データベース管理システム、端末装置及び方法
US20220300509A1 (en) Database system, distributed processing apparatus, database apparatus, distributed processing method and distributed processing program
JP7102783B2 (ja) システム管理装置、システム管理方法、およびプログラム
US10664496B2 (en) Computer system
JP2010009288A (ja) マルチプロセッサシステム及びプログラム実行方法

Legal Events

Date Code Title Description
AS Assignment

Owner name: FUJITSU LIMITED,JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WADA, YUJI;MATSUMOTO, YASUHIDE;WATANABE, YUKIHIRO;AND OTHERS;SIGNING DATES FROM 20090602 TO 20090608;REEL/FRAME:022877/0551

Owner name: FUJITSU LIMITED, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WADA, YUJI;MATSUMOTO, YASUHIDE;WATANABE, YUKIHIRO;AND OTHERS;SIGNING DATES FROM 20090602 TO 20090608;REEL/FRAME:022877/0551

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20210507