KR20130123007A - Method for controlling trouble and server thereof - Google Patents

Abstract

The present invention relates to technology to issue a trouble ticket and to manage server or service trouble based on the issued trouble ticket. A server manages trouble as follows. The server: generates virtual role groups and stores processing staff information of each role that each virtual role group is matched to at least one piece of processing staff information; obtains information about a trouble occurrence from a subject being monitored and selects a virtual role group to process the trouble occurrence information among the virtual role groups; identifies processing staff information which is matched to the virtual role group among the processing staff information of each role and generates trouble ticket information including part of or all the trouble occurrence information; processes the issue of the trouble ticket using the trouble ticket information and the identified processing staff information; and completes the trouble ticket processing. According to the present invention, trouble occurrence information is accurately conveyed to a person in charge and a trouble ticket is correctly delivered although a person in charge is changed. Also, trouble recovery time from a managerial point of view can be accurately calculated. [Reference numerals] (110) Server;(120) Terminal;(130) Network

Description

METHOOD FOR CONTROLLING TROUBLE AND SERVER THEREOF}

The present invention relates to a technique for issuing a trouble ticket and managing the failure of a system or service based on this.

If a failure occurs, the failure details are checked, and the trouble management officer issues a trouble ticket. The basic cycle of fault management is created by handling a fault by a designated person to handle the fault, and closing or closing the fault ticket. Fault management methods based on these basic cycles are commonly applied and used in various fields. However, if you look at the current fault management methods, you can see that there are some problems as follows.

First, a trouble ticket is issued, but it is difficult to check whether it is correctly delivered to a designated person, and thus, an administrator who issues a trouble ticket frequently delivers a message through a landline. This results in inaccuracies in business processes and waste of human resources.

Another problem is that if a contact is changed for reasons such as leaving the company, leaving a job, transferring, etc., the disability ticket assigned to that contact is not correctly taken over by the new contact. Current trouble management methods are directly linked with the trouble ticket number generated by issuance of trouble ticket, so if the contact person changes, the trouble ticket associated with the contact person must be searched and changed to a new contact person. Is generating.

Another problem is that it does not include an accurate way of estimating failure recovery time after a failure has been recovered. Disaster handling is being finalized in order to fix the failure, and there are no methods and devices to calculate the indicators of the actual service being used on the normal track, so only low-level management services are provided at the management and management level. There is a problem.

Against this background, an object of the present invention is to transmit a failure-related alarm message through various passages of a representative information medium such as SMS, SNS, messenger, e-mail, etc., in order to accurately transmit the relevant information to a representative when the failure occurrence information is obtained. A role group that plays a specific role of failure information by forming a role group as an intermediary between failure information and contact information so that trouble ticket information associated with the contact person can be automatically carried over to the new contact even if the contact person changes. Linking to a group and applying real contact information to this role group again is applied. Also, even if the failure processing is completed to accurately calculate the failure recovery time, the time when the service utilization rate returns to the normal state, not the time taken to solve the system or hardware problem by monitoring whether the managed service afterwards is normally used. We want to calculate this as the time to recover from a failure.

In order to achieve the above object, in one aspect, the present invention, in a method for managing a failure in a server, role-specific processing that maps one or more processing personnel information for each virtual role group belonging to the virtual role group list Storing contact information in a database; Obtaining failure occurrence information from the failure monitoring apparatus; And selecting a virtual role group for processing the failure occurrence information from the virtual role group list, and issuing a failure ticket including some or all of the failure occurrence information in association with the selected virtual role group. Provides a way to manage failures.

In another aspect, the present invention, the role-specific contact information storage unit for storing the role-specific processing contact information for mapping the at least one processing contact information for each virtual role group belonging to the virtual role group list in the database; Failure occurrence information acquisition unit for obtaining failure occurrence information from the failure monitoring device; And a trouble ticket issuing unit for selecting a virtual role group for processing the failure occurrence information from the virtual role group list and issuing a trouble ticket including some or all of the failure occurrence information. to provide.

In another aspect, the present invention provides a method for managing a failure in a server, the method comprising: obtaining failure occurrence information from a failure monitoring device; Issuing a trouble ticket including some or all of the failure occurrence information; Terminating the fault ticket according to a predetermined method; Obtaining service operation information on the application service provided by the monitoring target or the application service provided by using the monitoring target after the termination processing, and comparing the estimated operation information when the service is calculated in advance to determine whether to recover the service. step; And in the determining of whether the service is recovered, determining a time from the end processing time to a time when the service recovery state is determined as the service recovery state, when the service recovery state is determined. Provide a method.

In another aspect, the present invention, the failure occurrence information acquisition unit for obtaining failure occurrence information from the failure monitoring device; A trouble ticket issuing unit for issuing a trouble ticket including some or all of the trouble occurrence information; A trouble ticket termination processor configured to terminate the trouble ticket according to a predetermined method; Obtaining service operation information on the application service provided by the monitoring target or the application service provided by using the monitoring target after the termination processing, and comparing the estimated operation information when the service is calculated in advance to determine whether to recover the service. Service recovery determination unit; And in the determining of whether the service is recovered, a failure recovery time calculation unit configured to determine, as the service recovery state, a time from the termination processing time point to the time when the service recovery state is determined as the service recovery state as the failure recovery time. Provides a server to manage.

As described above, according to the present invention, it is possible to accurately transmit the failure occurrence information to the person in charge first, and even if the person in charge is changed, the trouble ticket is carried forward correctly, and from the management point of view, it is possible to accurately calculate the required recovery time of the failure. It works.

1 is a diagram illustrating a network including a server and a terminal according to an embodiment of the present invention.
2 is a configuration diagram of a failure management system according to an exemplary embodiment of the present invention, which includes peripheral devices connected to a network with a server and a terminal to manage a monitoring object.
3 is an internal block diagram of a server according to an embodiment of the present invention.
FIG. 4 is an exemplary diagram showing processing person information for each role in which processing person information is mapped to a virtual role group as a table.
5 is an internal block diagram of a monitoring object.
6 is a flowchart of a method for managing a failure according to an embodiment of the present invention.
7 is an internal block diagram of a server according to another embodiment of the present invention.
8 is a graphic diagram displaying a service operation status pattern and a service operation expected pattern at the time of service recovery on one screen.
9 is a flowchart of a method for managing a failure according to another embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected to or connected to the other component, It should be understood that an element may be "connected," "coupled," or "connected."

1 is a diagram illustrating a network including a server 110 and a terminal 120 according to an embodiment of the present invention.

The server 110 and the terminal 120 are connected through the network 130, the failure management service provided through the server 110 may be displayed through the screen of the terminal 120, and the administrator 120 may display the terminal 120. By operating on, specific inputs to the server 110 may be generated. Hereinafter, some characteristics that may correspond to the server 110 and the terminal 120 will be described.

The terminal 120 may include a general PC such as a general desktop or a notebook computer and may include a mobile terminal such as a smart phone, a tablet PC, a PDA (Personal Digital Assistants), and a mobile communication terminal. But should be broadly interpreted as any electronic device capable of communicating with the server 110. [

The server 110 may be configured in the same manner as a conventional Web server or a web application server or a WAP server. However, in software, as described in detail below with reference to FIG. 3, a program module implemented through various languages such as C, C ++, Java, PHP, .Net, Python, Ruby, and performing various functions. (Module) may be included.

In addition, the server 110 may be connected to an unspecified number of clients (including the terminal 120) and / or other servers via the network 130 so that the server 110 can perform operations of the client or other server A computer system for receiving a request and deriving a result of the operation, or computer software (server program) installed for such a computer system.

In addition to the above-described server program, the server 110 may also include a wide range of application programs (application programs) operating on the server 110 and, in some cases, various databases built in or outside the server 110 It should be understood.

In addition, the server 110 can store and manage content, various information, and data in a database. Here, the database may be implemented inside or outside the server 110.

The server 110 may use a server program that is variously provided according to an operating system such as DOS, Windows, Linux, UNIX, or Macintosh to general server hardware Typical examples include a Web site used in a Windows environment, an Internet Information Server (IIS), Apache, Nginx, and Light HTTP used in a UNIX environment.

The network 130 is a network connecting the server 110 and the terminal 120 and may be a closed network such as a LAN (Local Area Network) or a WAN (Wide Area Network) ). ≪ / RTI > Here, the Internet includes various services existing in the TCP / IP protocol and its upper layers such as HTTP (HyperText Transfer Protocol), Telnet, File Transfer Protocol (FTP), Domain Name System (DNS), Simple Mail Transfer Protocol (SMTP), The global open computer network architecture that provides Simple Network Management Protocol (SNMP), Network File Service (NFS), and Network Information Service (NIS).

In addition, when the terminal 120 includes a mobile terminal such as a smart phone, a tablet PC, a PDA (personal digital assistant), and a mobile communication terminal, the network 130 may be a wireless access network such as a mobile communication network or a WiFi As shown in FIG.

2 is a configuration diagram of a failure management system according to an exemplary embodiment of the present invention, which includes peripheral devices connected to a network with a server and a terminal to manage a monitoring object.

Referring to FIG. 2, a failure management system according to an embodiment of the present invention may be connected to a server 110 that provides a failure management service and connected to a network to receive failure management information or output failure management information on a screen. In addition to the terminal 120, the monitoring object 140, the daemon server 150, the service monitoring terminal 160, and the system monitoring terminal 170 may be included. The server 110 is described in detail below with reference to FIG. 3, and other devices will be described first.

The monitoring object 140 refers to a monitoring object such as a device or an application that is a target of the failure management service. Representatively, a hardware system such as a network system or a DB may be one of the above-described monitoring objects, and a service (for example, a specific function of software, etc.) provided through another server may also be included in the above-described monitoring object 140. Can be a component. For example, when a game service is a target of a disability management service, one component of the above-described monitoring object 140 stores a game server providing a game service, a user account information linked with a game server, and the like. Database system, network devices connecting the game server to the user's terminal, service contents of the game (for example, a game execution screen, a software block), and the like. Eventually, the monitoring object 140 should be interpreted as including all components that can be monitored through the failure management service and reported to the server 110 as a failing device or service.

The daemon server 150 refers to a device on which software for monitoring the monitoring object 140 is running. A particular component of the monitoring object 140 can determine whether there is a failure by monitoring the properties of this particular component, e.g. if the network configuration does not respond to the ping service, there is a failure in the network function. You can judge. In addition to these examples, the daemon server 150 is applying various recently developed fault diagnosis techniques, and collects information on whether a specific component has failed while monitoring the monitoring object 140 in real time. The failure information collected as described above is transmitted to the server 110 connected through the network. As soon as the daemon server 150 confirms the failure, the failure information may be automatically and electronically transmitted to the server 110. The identified failure information may be stored in a database shared with the server 110 to exchange information with each other. Alternatively, the daemon server 150 may be adapted to the case where the server 110 periodically requests failure information. ) May also transmit failure information collected. In the present invention has been described that the server 110 can obtain the failure occurrence information through the daemon server 150, etc., it is not limited to the information transmission path of the above-described manner.

Since the daemon server 150 may be a device on which real-time monitoring software is run, this is not limited to an independent device or a configuration as a server. When the above-described monitoring software is installed in the server 110, the daemon may be configured in hardware. The server 150 may have the same configuration as the server 110.

The service monitoring terminal 160 is a device that functions to transmit failure occurrence information to the server 110 when an administrator who monitors a service that is a component of the monitoring object 140 detects a failure in a service that is monitored. . Typically, the service monitoring manager determines whether a failure occurs in a service as a component of a monitoring object while monitoring a failure report received through a customer center or a screen output of a service to a terminal. When the failure occurrence information is generated through this determination, it is transmitted to the server 110. To this end, if the server 110 may include functions for controlling the display of the screen by the service monitoring terminal 160, the administrators input the failure occurrence information by inputting the failure occurrence information on the screen displayed by the service monitoring terminal 160. And transmit to 110.

When the system monitoring terminal 170 detects a failure in a system to be monitored by an administrator who monitors a system (for example, a network, a DB, a public server, etc., referred to as an infrastructure) that is one component of the monitoring object 140. It is a device functioning to transmit failure occurrence information to the server (110). The administrator who monitors the system monitors the system's properties, usage status, etc., and if there are any abnormalities, it generates a failure information and sends it to the server 110, or if it is confirmed that the actual failure has occurred after detailed inspection, the failure occurs. The information is transmitted to the server 110. To this end, if the server 110 may include functions of controlling the display of the screen to the system monitoring terminal 170, the administrator inputs the failure occurrence information by inputting the failure occurrence information on the screen displayed by the system monitoring terminal 170 And transmit to 110.

The daemon server 150, the service monitoring terminal 160, the system monitoring terminal 170, and the like may be referred to as a failure monitoring device, and the server 110 may obtain failure occurrence information from the failure monitoring device. .

Hereinafter, the server 110 that performs the main contents according to an embodiment of the present invention while interworking with these peripheral devices will be described in detail.

3 is an internal block diagram of the server 110 according to an embodiment of the present invention.

Referring to FIG. 3, the server 110 may perform a role-specific contact information storage unit 310, a failure occurrence information acquisition unit 320, a contact information identifying unit 330, a trouble ticket information generation unit 340, and a trouble ticket issuance. The unit 350 may include a trouble ticket issue notification unit 360 and a trouble ticket interworking unit 370.

The role-specific contact information storage unit 310 stores process-specific contact information for each of the virtual role groups included in the virtual role group list in the database. In order to clarify the concept, the virtual role group will be described in detail with reference to FIG. 4.

FIG. 4 is an exemplary diagram showing processing person information for each role in which processing person information is mapped to a virtual role group as a table. Referring to Figure 4, the virtual role group is divided into a group responsible for the board failure in the service, a group responsible for the login failure in the service, a group in charge of the network failure in common, a group in charge of the email failure in common Lost These groups, as their name suggests, are groups that are responsible for handling faults. Looking at common techniques, once the failure information is obtained, the failure manager can directly assign a person to identify and handle. The person to handle may be an individual or may be a specific department. For example, assuming that a bulletin board installed in a community for users of a specific game is causing a malfunction, in a typical technology, the person who developed the bulletin board is designated as the processing person, or the development department of the specific game is the person in charge of processing. It is specified as. In this case, the problem arises when the designated person changes due to reasons such as leaving the company. Assuming that the person in charge of the aforementioned bulletin board problem is Kim Samdam, and Kim Samdam manages not only the aforementioned bulletin board but also an e-mail related to the specific game, when Kim Samdam retires and Kim Saddam becomes the substitute person, the server 110 The manager who manages the system must handle the change of the person in charge for all the trouble occurrence information that Kim Samdam was in charge of or the trouble ticket issued through this failure occurrence information. In this process, a work error or a work delay may occur, thereby delaying the prompt handling of the failure.

In contrast, one embodiment of the present invention uses a virtual role group, which serves as a kind of intermediate mapping code. In other words, in the failure information or the trouble ticket issued through the failure information, the above-mentioned virtual role group is designated as the person in charge as a kind of intermediate mapping code, and the failure is generated by linking the actual person in charge to the virtual role group again. The intermediate code is inserted between the fault ticket issued through the information or the fault occurrence information and the actual person in charge of the process so that the two are not directly connected. In this case, changing the contact person for the virtual role groups to which Kim Sam-dam is mapped in the above example eliminates the need to change the fault information or the trouble ticket issued through the fault information, and automatically changes to the changed contact person. The effect to be processed is generated.

In the above example, there is one or two disability tickets designated by Kim Sam-Dam as the person in charge, but there is no significant difference in terms of effectiveness, but in practice, tens to hundreds of disability tickets can be issued to the same person. In this case, one embodiment of the present invention As described above, if a virtual role group is provided as an intermediate mapping code, only the information mapped to the virtual role group can be modified to obtain an effect of changing the person in charge of all trouble tickets.

The failure occurrence information acquisition unit 320 obtains failure occurrence information from a failure monitoring apparatus. The process of acquiring the failure occurrence information may be described with reference to the aforementioned various methods (methods using the daemon server 150, the service monitoring terminal 160, the system monitoring terminal 170, etc.).

The contact information identifying unit 330 may identify the processing contact information mapped to the virtual role group from the processing contact information for each role.

The trouble ticket information generation unit 340 generates trouble ticket information including some or all of the trouble occurrence information. Since the acquired failure information may include raw data and raw data, there is also information that is difficult to include in the trouble ticket information that is generated as a trouble ticket and iterates the processing staff and the settlement staff. Therefore, the trouble ticket information may include only a part of the acquired failure occurrence information or may include information processed therein.

The above-mentioned trouble ticket information may further include information on the virtual role group selected in association with this. Thus, the virtual role group information as the intermediate mapping code for the processing representative information can be linked instead of directly linking the processing representative information to the trouble ticket information. Of course, the trouble ticket information may directly include the processor representative information mapped to the aforementioned virtual role group.

The trouble ticket issuing unit 350 selects a virtual role group for processing failure occurrence information from the virtual role group list, and links a failure ticket including some or all of the failure occurrence information to the selected virtual role group. Issue. Generally, disability ticket issuance, designated by the person in charge to handle the problem, and generating a management number for it is called disability ticket issue. The detailed process includes the function of confirming the occurrence, storing the trouble ticket issuance in the account of the processing person, and notifying the issue of the trouble ticket to the person in charge of the processing person.

The above-described selection may be made based on selection information according to the terminal's operation of the manager received from the terminal 120. Typically, the administrator checks the failure occurrence information displayed on the terminal 120, and distributes it to the appropriate role group.

After the trouble ticket is issued, the trouble ticket issuing notification unit 360 may transmit a part of the contents included in the trouble ticket information to the person in charge information medium included in the determined person in charge information. Such personal information carriers may include a portable personal communication terminal (SMS), an online messenger, an SNS, and an e-mail. SMS transmission may be used as a method that can be quickly confirmed by the processing personnel. For this purpose, the server 110 may further include an SMS transmission unit (not shown) which may automatically communicate with the SMS server to transmit information in an SMS manner. .

If information on the virtual role group included in the trouble ticket, that is, the processing person information mapped to the virtual role group is changed after the trouble ticket is issued, the contact person information medium included according to the changed processing person information Can retransmit the contents of the trouble ticket. In the past, the administrator modified the trouble ticket information and resent the information to the changed person in charge. However, because the virtual role group was set up with the concept of intermediate mapping code, the trouble ticket was changed in the block that manages the virtual role group information. If the issuing unit 350 or the disability ticket issuing notification unit 360 is notified, or the disability ticket issuing unit 350 or the disability ticket issuing notification unit 360 confirms the change of the virtual role group information periodically, Disability tickets can be reissued or the contents contained in the changed contact information carrier without any change in content.

The trouble ticket termination processing unit (not shown) performs termination processing on the issued trouble ticket. Shutdown processing can usually be done manually by the administrator. When the administrator determines that the failure has been restored and there is no longer the role of the person in charge of processing, the shutdown process button or menu can be selected to allow the server 110 to delete the trouble ticket. The failure ticket further includes termination processing information to distinguish it from other ongoing trouble tickets. Alternatively, the termination process may be automatically performed by the server 110. If you have a means to monitor the fault information, you can use this information to determine whether the fault is continuing or normal operation, and use this information to terminate the fault ticket or to leave it for a long time so that it is no longer meaningful. Disability tickets may be terminated according to predetermined criteria.

The trouble ticket interlocking unit 370 links the generated trouble ticket with a specific trouble ticket that has already been generated. The linking of the ticket may be performed by including a linkage-related information in the corresponding disability ticket or inputting a number or ID of a specific disability ticket linked to the interworking information area provided in the basic format of the disability ticket. When a trouble ticket is interlocked with another trouble ticket, an administrator or the like can monitor the information of the other trouble tickets associated with the trouble ticket on a single screen, and also terminate several trouble tickets through one termination process. You may.

Referring to the description of the process of acquiring fault occurrence information, the paths through which the fault occurrence information is obtained vary. It may be through the daemon server 150, may be through the service monitoring terminal 160, may be through the system monitoring terminal 170. In addition, the above-described daemon server 150 may not be one but several. In this case, several failure occurrence information may be generated and transmitted to the server 110 in several places for one failure. This structure creates the risk of having to do work over and over for a single failure and can create inefficiencies. Therefore, it is necessary to link trouble tickets issued repeatedly for the same failure to clean up the trouble tickets or to utilize the interworking information so that failure processing can be efficiently performed. The trouble ticket interworking unit 370 performs the trouble ticket interworking function.

5 to describe the function of the trouble ticket interlocking unit 370. 5 is an internal block diagram of the monitoring object 140. Referring to FIG. 5, the monitoring object 140 may be represented by hierarchically analyzing each component constituting the network object, the network system 550 corresponding to the infrastructure of the system, the DB system 540, and the same. The application server 530 that provides the server function, the common server 520, and finally can be divided into the application service 510 is presented directly to the user based on the above-described components. In order to provide one top-level application service, various lower layer components may be required. Here, each component indicated by the internal block of the monitoring object 140 may be recognized as one monitoring target by the failure monitoring apparatus. Therefore, in the above description or described below, the component may be understood as one monitoring object.

Let us assume a situation in which a failure occurs in a part of the monitoring object 140 having a hierarchical structure. First, when the lowermost network system 550 fails, the upper DB system 540, the application server 530, the common server 520, and the application service 510 may not all perform their normal functions. In this case, the terminal or device monitoring each component has a failure in the component monitored by the respective component (for example, including the application server 530, public server 520, etc.) Failure information will be sent to the server (110). In this case, in fact, there is a possibility that the same trouble or multiple trouble tickets which originate from one cause may be issued. As this trouble ticket is issued in duplicate, it creates inefficiency of work.

Some specific embodiments of linking fault tickets that are best handled the same or together are introduced.

First, the server 110 obtains failure correlation information between components in which failure correlation between elements constituting the monitoring object 140 is analyzed. An example of failure correlation information between components may be hierarchical structure information of components constituting the aforementioned monitoring object 140. Hierarchical information shows how each component affects other components. The server 110 assigns a failure-related component included in the trouble ticket information among the components constituting the monitoring object 140 to failure correlation information between the components, and causes another component or failure that may be a failure. Identify other components. In the above example, assuming failure ticket information including the network system 550 which is the cause of the failure as a component of the failure among several failure ticket information, the network that is the failure component included in the failure ticket information Substituting a component called system 550 into the above-described failure correlation information (for example, hierarchical structure information) between the components, DB system 540, application server 530, The common server 520 and the application service 510 are identified. In this case, the fault-related components included in the fault ticket information derived during the monitoring of the other possible components and the actual faults that are identified in this case may coincide with each other.

The failure-related component included in one trouble ticket and another specific trouble ticket information are substituted for the failure correlation information between the above-mentioned components, and the other components that may cause the failure or another component that causes the failure If there is a match, both disability tickets can be linked. Service monitoring teams that monitor the appearance of a service usually look at the failure from the service point of view and issue a trouble ticket, while teams managing the system's infrastructure often look at the failure from the infrastructure point of view and issue a trouble ticket. . In this case, substituting the fault ticket from the point of view of the service into the above-described fault correlation information between the components, it is possible to identify the fault component of the infrastructure point of view that causes the infrastructure, and similarly the fault ticket from the point of view of the infrastructure. By substituting the above-described failure correlation information between the components, it is possible to grasp the failure component of the possible service failure point of the superstructure. The components identified in this way can be compared with each other to determine whether both disability tickets are linked.

As another method of interworking the issued trouble tickets, when the virtual role group information included in the trouble ticket information of the two trouble tickets coincides with each other, the two trouble tickets may be interworked. In some cases, it may be difficult to assume that two disability tickets originated from the same disability, but virtual role groups are grouped by role, which can be more efficient.

In the above, the server 110 for managing a failure according to an embodiment of the present invention has been described. Hereinafter, a method for managing a failure by the server 110 according to an embodiment of the present invention will be described. The method for managing a failure according to an embodiment of the present invention, which will be described later, may be performed by the server 110 according to an embodiment of the present invention shown in FIG. 3.

6 is a flowchart of a method for managing a failure according to an embodiment of the present invention.

The server 110 first generates virtual role groups that are in charge of failure processing, and stores processing person information for each role in which at least one processing person information is mapped to each of the virtual role groups in a database (S600). Next, the server 110 obtains the failure occurrence information in the monitoring object (S602), and selects a virtual role group for processing the failure occurrence information from the virtual role groups (S604). The server 110 grasps processing person information mapped to the virtual role group from the processing person information for each role (S606), and generates trouble ticket information including some or all of the failure occurrence information (S608). ). By using the trouble ticket information and the identified processing person information, the server 110 issues a trouble ticket (S610), and then performs a termination process on the trouble ticket (S612).

In the above description, the method for managing a failure according to an embodiment of the present invention has been described as being performed by the same procedure as in FIG. 6, but this is only for convenience of description and within the scope not departing from the essential concept of the present invention. Depending on the implementation method, the execution procedure of each step may be changed, two or more steps may be integrated, or one step may be performed in two or more steps.

Hereinafter, a server 700 and a method for managing a failure according to another embodiment of the present invention will be described.

7 is an internal block diagram of a server 700 according to another embodiment of the present invention. Referring to FIG. 7, a server 700 for managing a failure according to another embodiment of the present invention includes a failure occurrence information acquisition unit 710, a trouble ticket issuing unit 720, a trouble ticket termination processing unit 730, and service recovery. The determination unit 740 may include a failure recovery time calculation unit 750.

The server 700 of FIG. 7 may be interpreted as including a function of the server 110 of FIG. 3, and in addition, further including a series of functional blocks for calculating a failure recovery time. However, the server 700 according to another embodiment of the present invention shown in FIG. 7 is not limited to this interpretation. Therefore, hereinafter, the server 700 of FIG. 7 will be described independently of the server 110 of FIG. 3.

The failure occurrence information acquisition unit 710 obtains failure occurrence information from a failure monitoring apparatus. The trouble ticket issuing unit 720 issues a trouble ticket including some or all of the acquired trouble occurrence information. The trouble ticket termination processing unit 730 terminates the issued trouble ticket according to a predetermined method. Detailed functions of the above-mentioned trouble ticket information acquisition unit 710, the trouble ticket issuing unit 720, and the trouble ticket termination processing unit 730 may refer to the functions of the server 110 in one embodiment of the present invention. It is omitted here to avoid duplication of content.

The service recovery determination unit 740 obtains service operation information on the application service provided by the monitoring target or the application service provided by using the monitoring target after the issued trouble ticket is terminated, and the service calculated in advance When recovering, it is compared with the expected operation information to determine whether the service recovers. Detailed functions will be described with reference to FIG. 8.

8 is a graphic diagram displaying a service operation status pattern and a service operation expected pattern at the time of service recovery on one screen. The graphic of FIG. 8 shows the number of simultaneous users for the service provided on the Y axis, and the time on the X axis. In addition, the solid line represents the operation information of the actual service, and the dotted line displayed at the top of the solid line represents the expected operation information at the time of service recovery.

Referring to FIG. 8, service failure occurred at time (A). As a result, the number of concurrent users for the service is rapidly decreasing. After (B), the failure of the service was recovered, and the number of concurrent users for the service was restored. Generally speaking, the failure recovery time means a time between (A) and (B). In other words, it is defined as a failure recovery time by calculating the time from when a service fails to when the service is restored. This is a concept that was applied to a fairly classic system. It was mainly used to create an indicator of how to quickly recover from a failure of a physical system such as hardware. However, in terms of management, the important information is not the time from (A) to (B), but from (A) to (C). (C) means the time when the level of service reaches the normal level without failure after the failure is recovered. It is important to minimize the time from (A) to (C) from a management point of view because the time from (A) to (C) is the time that caused the loss from failure. However, in order to calculate the time from (A) to (C), a method of calculating the time from (B) to (C) was required. Only time to B) is measured. Calculating the time from (A) to (B) is simple. First, a time when a failure is received, that is, a time when the failure occurrence information is acquired in the above-mentioned example becomes (A). Thereafter, the time for recovering the fault and terminating the issued trouble ticket becomes (B). Therefore, what is necessary is just to calculate the time difference of (A) and (B). The problem is to calculate the time from (B) to (C). The time from (B) to (C) is the time from the failure recovery to the normal operation of the service, which is defined here as the failure recovery time.

Let's take a look at how to calculate the time from (B) to (C) in question. The easiest way to calculate this is to take the input of the administrator and confirm the time in (C). The method may further include the step of receiving (C) time from the manager terminal according to the manager's experience or a guideline in a certain management process, and the failure recovery time defined above may be calculated as a difference time between (B) and (C). Manager intervention is required and can lead to data inaccuracies or loss of work. The method of automatically calculating the failure recovery time is to use the estimated operation information when the service is calculated in advance. If the service availability can be estimated in advance, for example, the expected utilization information, for example, the service utilization rate, then observe the service utilization trend from the time (B) to complete the recovery process for the failure, and then the value When approaching, it is determined that the service has recovered, and the time can be determined as (C).

The method of precomputing operation information upon service recovery will be described in more detail. In general, the service and the operation amount are often formed in a certain pattern. For example, in the case of a game service, the number of concurrent users may be different depending on the time of day or day of the week, and the time from service opening may be different. The rate at which the number of concurrent users increases as the number of times also forms a certain pattern. This is for the case that the service recovery time is long, and when the service recovery time is short, for example, within 10 minutes to 1 hour, the above-mentioned expected operation information during service recovery is said to be maintained just before failure occurs. You may see it. The pattern for the service operation information can be easily calculated and derived using the service history at the previous normal service time or the previous service operation information. For example, the pattern of hourly operation information may use the previous day information, and the pattern of the day of the week may use information of last week.

As described above, the service recovery determination unit 750 determines whether the service is recovered by using the expected operation information when the service is expected to recover, and at this time, the value derived from the service expected operation information is tracked and If the value of the current operation information is the same or within a certain range within a certain time interval, it can be determined that the service has recovered.

When it is determined that the service is recovered by this method, the failure recovery time calculation unit 760 determines the time from the termination processing point for the trouble ticket to the time when the service recovery state is determined as the failure recovery time.

In the above, the server 700 for managing a failure according to another embodiment of the present invention has been described. Hereinafter, a method for managing a failure by the server 700 according to another embodiment of the present invention will be described. The method for managing a failure according to another embodiment of the present invention to be described later may be performed by the server 700 according to another embodiment of the present invention shown in FIG. 7.

9 is a flowchart of a method for managing a failure according to another embodiment of the present invention.

The server 700 obtains failure occurrence information from the monitoring object (S900), and generates failure ticket information including some or all of the failure occurrence information (S902). Thereafter, the server 700 issues and processes a trouble ticket using the trouble ticket information and the person in charge of processing the trouble occurrence information (S904), and performs a termination process according to a predetermined method for the trouble ticket ( S906). After the termination process, the server 700 obtains service operation information on the application service provided by the monitoring target or the application service provided by using the monitoring target as a part, and compares it with the expected operation information when the service is calculated in advance. In step S908, the service recovery state is determined. When the service recovery state is determined, the time from the termination processing time point to the service recovery state is determined as the failure recovery time (S910).

In the above description, the method for managing a failure according to another embodiment of the present invention has been described as being performed by the same procedure as in FIG. 9, but this is only for convenience of description and within the scope not departing from the essential concept of the present invention. Depending on the implementation method, the execution procedure of each step may be changed, two or more steps may be integrated, or one step may be performed in two or more steps.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. That is, within the scope of the present invention, all of the components may be selectively coupled to one or more of them. In addition, although all of the components may be implemented as one independent hardware, some or all of the components may be selectively combined to perform a part or all of the functions in one or a plurality of hardware. As shown in FIG. Codes and code segments constituting the computer program may be easily inferred by those skilled in the art. Such a computer program may be stored in a computer readable storage medium and read and executed by a computer, thereby implementing embodiments of the present invention. As a storage medium of the computer program, a magnetic recording medium, an optical recording medium, or the like can be included.

It is also to be understood that the terms such as " comprises, "" comprising," or "having ", as used herein, mean that a component can be implanted unless specifically stated to the contrary. But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used terms, such as predefined terms, should be interpreted to be consistent with the contextual meanings of the related art, and are not to be construed as ideal or overly formal, unless expressly defined to the contrary.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

Claims (15)

In the way the server manages failures,
Storing processing representative information for each role in which at least one processing representative information is mapped for each virtual role group belonging to the virtual role group list in a database;
Obtaining failure occurrence information from the failure monitoring apparatus; And
Selecting a virtual role group for processing the failure occurrence information from the virtual role group list, and issuing a failure ticket including some or all of the failure occurrence information in association with the selected virtual role group; How to manage it. The method of claim 1,
Determining the processing person information mapped to the selected virtual role group from the processing person information for each role;
And after the issuing of the trouble ticket, transmitting some or all of the contents included in the trouble ticket to a person in charge information medium included in the determined person in charge information. 3. The method of claim 2,
The contact information carrier is at least one or more of a portable personal communication terminal, an online messenger, an SNS, and an e-mail, and manages a failure of the contact information carrier by automatically transmitting some or all of the contents included in the trouble ticket to the contact information carrier. How to. The method of claim 1,
After the issuance of the trouble ticket, if the process representative information mapped to the selected virtual role group is changed, a part or all of the contents included in the trouble ticket to the contact information medium included in the changed process representative information. Method for managing a failure, characterized in that for transmitting. The method of claim 1,
And a trouble ticket interworking step of integrating the trouble ticket with a specific trouble ticket that has already been generated. The method of claim 5,
Obtaining disability correlation information analyzing the disability correlation between the monitoring targets; And
From the failure correlation information, the cause monitoring target identified as the cause of the failure corresponding to the trouble ticket and the failure prediction monitoring target predicted to cause the failure in series according to the failure corresponding to the trouble ticket are identified, and in the same manner. Identifying a cause monitoring target and a predicted failure monitoring target in response to the specific trouble ticket,
In the trouble ticket interworking step, information on at least one monitoring target among a monitoring target, a cause monitoring target, or a predicted failure monitoring target corresponding to the trouble ticket, and a monitoring target, a cause monitoring target, or a failure prediction corresponding to the specific trouble ticket; And comparing the information on at least one monitoring target among the monitoring targets to link the trouble ticket with the specific trouble ticket. The method according to claim 6,
In the trouble ticket linking step,
The monitoring target or cause monitoring target corresponding to the trouble ticket and the monitoring target or failure prediction monitoring target corresponding to the specific trouble ticket match or correspond to the monitoring target or failure prediction monitoring target corresponding to the trouble ticket and the specific failure ticket. And when the monitoring target or the cause monitoring coincides, the trouble ticket and the specific trouble ticket are interlocked. The method of claim 5,
The monitoring target corresponding to the trouble ticket is for an application service, and the monitoring target corresponding to the specific trouble ticket is an infrastructure that is partially used to provide the application service or to provide the application service. How to manage. The method of claim 5,
And when the virtual role group selected in response to the trouble ticket and the virtual role group selected in response to the specific trouble ticket are the same, linking the trouble ticket and the specific ticket. A role-specific contact information storage unit for storing role-specific contact information for each of the virtual role groups belonging to the virtual role group list in a database;
Failure occurrence information acquisition unit for obtaining failure occurrence information from the failure monitoring device; And
And a trouble ticket issuing unit for selecting a virtual role group for processing the failure occurrence information from the virtual role group list and issuing a trouble ticket including some or all of the failure occurrence information. In the way the server manages failures,
Obtaining failure occurrence information from the failure monitoring apparatus;
Issuing a trouble ticket including some or all of the failure occurrence information;
Terminating the fault ticket according to a predetermined method;
Obtaining service operation information on the application service provided by the monitoring target or the application service provided by using the monitoring target after the termination processing, and comparing the estimated operation information when the service is calculated in advance to determine whether to recover the service. step; And
In the determining of whether the service is recovered, if it is determined that the service is in a recovery state, determining a time from the termination processing time to the time determined as the service recovery state as a failure recovery time comprising: . 12. The method of claim 11,
In determining whether to recover the service,
The service operation information is an hourly service operation status pattern derived by tracking a service operation amount, which is a value that quantifies the operation degree of the service hourly, and the expected operation information when the service is restored is an hourly service expected when the service is normally operated. It is an operation expected pattern, and the service operation status pattern and the service operation expected pattern is compared to determine the service recovery state when the pattern value of the predetermined time interval included in the two pattern information is within a predetermined criterion How to manage it. The method of claim 12,
And the service operation amount is the number of simultaneous access users for the service. 12. The method of claim 11,
The expected start-up information at the time of service recovery is calculated from the service start-up information at a normal service time stored in advance. Failure occurrence information acquisition unit for obtaining failure occurrence information from the failure monitoring device;
A trouble ticket issuing unit for issuing a trouble ticket including some or all of the trouble occurrence information;
A trouble ticket termination processor configured to terminate the trouble ticket according to a predetermined method;
Obtaining service operation information on the application service provided by the monitoring target or the application service provided by using the monitoring target after the termination processing, and comparing the estimated operation information when the service is calculated in advance to determine whether to recover the service. Service recovery determination unit; And
In the determining of whether the service is recovered, if it is determined that the service is in a recovery state, a failure including a failure recovery time calculation unit determining a time from the termination processing time point to the service recovery state is determined as the failure recovery time. Managed server.

Images