Operational Support System

Abstract

We provide technology that makes it easy to develop and maintain systems that streamline and automate MSP operations. [Solution] An event notification is used as a trigger to select and execute a corresponding job. A job is composed of two or more actions selected from a number of types of actions prepared in advance and linked sequentially. The combination of actions that make up the job and their linking order are determined according to the needs of the operator of the target equipment, and by setting this in a database, it is possible to execute processing that meets the needs of the operator of the target equipment.

Description

[Technical Field]

[0001] The present invention relates to a technology for supporting the operation of infrastructure facilities. [Background technology]

[0002] There is a service called MSP (Managed Service Provider) that is commissioned by the operator of infrastructure equipment to monitor, operate, and maintain the equipment on behalf of the operator. MSPs monitor the status of the equipment, notify the operator when an abnormality is detected, provide initial response when an abnormality occurs, perform regular inspections, and respond to malfunctions. These tasks are generally performed by manned response on a 24-hour basis.

[0003] As a mechanism for supporting MSP operations, for example, Patent Document 1 proposes a method for dealing with system failures at night or on holidays through remote maintenance, while Patent Document 2 proposes a method for supporting recovery and communication when a line failure occurs. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-184233 [Patent Document 2] Japanese Patent Application Laid-Open No. 2012-185680 Summary of the Invention [Problem to be solved by the invention]

[0005] Demand for MSPs is increasing year by year as infrastructure facilities increase and expand. However, due to the recent labor shortage and rising labor costs, it is becoming difficult to achieve stable 24 / 7 operation at low cost. As a result, there is a strong demand for labor-saving and automation of MSP operations, but several technical and practical challenges exist.

[0006] The first issue is development. Because there is a wide range of equipment configurations and operator (client) requirements, building an automated system for MSP operations traditionally required coding and detailed customization of programs tailored to each individual case. This resulted in increased development man-hours, and there were cases where the time and cost involved were incompatible with the wishes and budget of the client.

[0007] The second issue is operational. Changes in equipment configuration, operator requests, and operational methods occur frequently. Even if a system is created to suit each individual project, system maintenance such as program modifications is required each time a change occurs in equipment or operations. In the industry of monitoring infrastructure equipment, it is desirable to keep the time required for system maintenance as short as possible, but since system creation and ease of maintenance are generally in conflict, it can be difficult to respond flexibly and quickly.

[0008] The present invention has been made in consideration of the above-mentioned circumstances, and aims to provide a technology that makes it possible to easily develop and maintain a system for labor-saving and automation of MSP operations. [Means for solving the problem]

[0009] In order to achieve the above object, the present invention employs the following configuration.

[0010] The present invention is an operation support system for supporting the operation of a target facility, in which a plurality of types of jobs are registered in advance, which define processes to be executed for the target facility or a monitoring device that monitors the target facility, and / or processes to be executed for an operator of the target facility. an event notification receiving unit that receives an event notification issued from the target equipment or the monitoring device when a specified event occurs in the target equipment; a job selection unit that selects a job to be executed from the multiple types of jobs registered in the database based on information extracted from the event notification; and a job control unit that executes the job selected by the job selection unit, wherein multiple types of actions that are programs executed by a processor of the operation support system are prepared in advance, and the job is constructed by sequentially linking two or more actions selected from the multiple types of actions prepared in advance, and the combination of actions that make up the job and the order of linking them are determined in accordance with the requests of the operator of the target equipment, and set in the database, thereby making it possible to execute processing that meets the requests of the operator of the target equipment.

[0011] With this configuration, there is no need for program coding or detailed programming for each individual case; processing can be built according to the operator's needs simply by arranging actions sequentially. This significantly reduces development man-hours compared to the past, and even people without specialized programming knowledge can create and maintain jobs. Furthermore, even if the operator's needs or the equipment configuration change, there is basically no need to modify the program itself; changes can be made simply by changing the combination of actions and their connection order, allowing for quick response to operational changes with little man-hours.

[0012] The job preferably has a job action table in which an action link definition linking a target action to a next action to be executed after the target action is described for each of two or more actions that make up the job, and the job control unit preferably executes the actions sequentially in accordance with the action link definition in the job action table. By adopting the action link definition and job action table format in this way, it is possible to define and manage action combinations and their linking order in a clear and easy-to-understand format. Furthermore, even if a job needs to be changed, this can be accommodated simply by modifying the action link definition in the table, achieving high maintainability.

[0013] The action link definition may be capable of linking a plurality of next execution actions, each of which is executed alternatively, to one of the execution target actions. Such a framework may be used for, for example, conditional branching.

[0014] The job control unit may alternatively select an action to be executed from the plurality of next-execution actions according to a return value of the action to be executed. This method can improve modularity (independence) between actions.

[0015] It is preferable that the multiple types of actions are all designed to return the same type of return value. By standardizing the specifications of the return values ​​of the actions, development efficiency and maintainability can be improved.

[0016] In the action link definition, if there is no action to be executed after the target action, NULL should be set as the next action to be executed. By explicitly specifying NULL, setting errors and malfunctions can be prevented as much as possible.

[0017] At the end of two or more actions that are linked sequentially, it is advisable to place a terminal action in which all of the multiple next execution actions are set to NULL. By explicitly describing the terminal action, it is possible to prevent setting errors and malfunctions as much as possible.

[0018] The database preferably stores parameters referenced by the actions, and by determining the combination of actions that make up the job and the parameter values ​​for each action according to the needs of the operator of the target equipment and setting them in the database, it is possible to execute processing that meets the needs of the operator of the target equipment. By defining common processing that is not dependent on the operator in the action program and isolating parts that vary for each operator (e.g., the call destination, notification destination, etc.) from the program as parameters, the versatility and reusability of the action can be improved. Furthermore, by appropriately setting and changing parameter values, it is possible to flexibly and immediately respond to the needs of the operator.

[0019] The parameters may include variable parameters that can be changed by the operator of the target equipment themselves, and fixed parameters that cannot be changed by the operator of the target equipment. With this configuration, the operator can make necessary setting changes themselves, reducing the time and effort required to request setting changes from the MSP company and enabling quick setting changes.

[0020] The present invention may be understood as an operation support system having at least some of the above means or functions, or as a method including at least some of the above processes, or as a program for realizing such a method, or a recording medium on which such a program is recorded. Note that the above means and processes can be combined with each other as much as possible to constitute the present invention. [Effects of the Invention]

[0021] According to the present invention, it is possible to provide a technology that makes it possible to easily develop and maintain a system for labor-saving and automation of MSP operations. [Brief explanation of the drawings]

[0022] [Figure 1] An example of the configuration of an operational support system. [Figure 2] Examples of failure notification and failure recovery notification. [Figure 3] Example job table and job definition. [Figure 4] A specific example of a job. [Figure 5] An example of the configuration and functions of the settings UI section. [Figure 6] An example of the authentication screen and setting item selection screen. [Figure 7] An example of the call destination setting screen. [Figure 8] An example of the command setting screen. [Figure 9] An example of the non-monitoring settings screen. [Figure 10] Example of a configuration change notification that changes a parameter value. [Figure 11] Example of a configuration change notification for adding / removing from the non-monitored list. [Figure 12] 10 is an example of the monitoring behavior of the operation support system. [Figure 13] Example of a job action table. [Figure 14] An example of a modified job action table. DETAILED DESCRIPTION OF THE INVENTION

[0023] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0024] [System Configuration] 1 is a diagram showing the overall configuration of an operations support system 1 according to one embodiment of the present invention. First, an outline of the configuration of the operations support system 1 will be described with reference to FIG.

[0025] The operation support system 1 is a system operated by an MSP company entrusted by an operator 300 of the target facility 100, and is intended to support the operation of the target facility 100. For example, when the operation support system 1 detects that a failure has occurred in the monitored target facility 100, it notifies the operator 300 by phone or message, and automatically takes measures such as performing primary maintenance on the target facility 100 as necessary.

[0026] The operation support system 1 of this embodiment mainly comprises an event notification receiving unit 10, an event notification analyzing unit 11, a wait-and-see determining unit 12, a job selecting unit 13, a job control unit 14, a database 15, a setting change notification receiving unit 16, and a setting UI unit 17. The operation support system 1 is connected to the Internet and can communicate with the target equipment 100, the monitoring device 200, and the terminal 310 of the operator 300 of the target equipment 100 via the Internet. Note that, for illustrative purposes, only one target equipment 100 and one terminal 310 of the operator 300 are shown in FIG. 1 , but multiple target equipment 100 can be monitored with one operation support system 1, and the operation support system 1 can be used from multiple terminals 310.

[0027] The target facility 100 is, for example, infrastructure equipment such as network devices, servers, storage, air conditioning equipment, and power supply equipment. A monitoring device 200 is connected to the target facility 100, and the monitoring device 200 constantly monitors the status of the target facility 100. If an abnormality or failure occurs in the target facility 100, or if the status of the target facility 100 meets (or deviates from) a predetermined condition, the monitoring device 200 generates an event notification and transmits it to the operation support system 1. Note that if the target facility 100 itself has the function of generating and transmitting an event notification, the monitoring device 200 is not necessary.

[0028] Events are broadly divided into two types: "failure occurrence" and "failure recovery." The event notifications issued in response to these events are called "failure occurrence notification" and "failure recovery notification." An event notification contains at least information for identifying the target equipment and its monitoring item, information indicating the type of event (failure occurrence / failure recovery), information for identifying the date and time of occurrence, and information for identifying the content of the event. Furthermore, in the case of a failure occurrence notification, information indicating whether or not waiting is required and for how long to wait may also be included. Event notification may be carried out using any means that allows for the sending and receiving of messages (message exchange means), such as email, SMS (Short Message Service), or business communication tools. Examples of business communication tools include Microsoft Teams, Slack, Backlog, and LINE WORKS. In the embodiment described below, email is used. An example will be explained.

[0029] The event notification receiver 10 has a function of receiving an event notification issued from the target facility 100 or the monitoring device 200. The received event notification is passed to the event notification analyzer 11.

[0030] The event notification analysis unit 11 has a function of analyzing the event notification and extracting necessary information. For example, the event notification analysis unit 11 acquires information from the event notification, such as the target equipment where the event occurred and its monitoring item, classification as a failure occurrence notification or a failure recovery notification, the content of the event (such as the type of failure), whether standby is required and the standby time.

[0031] The wait-and-see determination unit 12 is a function that refers to the non-monitored object list registered in the database 15 and determines whether or not the received event notification corresponds to a non-monitored object. The non-monitored object list is a list in which non-monitored objects for which monitoring by the operation support system 1 is temporarily stopped are registered. The non-monitored object list is used during planned maintenance work, planned equipment shutdowns, or when a temporary failure occurs. For example, when performing maintenance work, the equipment to be worked on is registered as a non-monitored object before the work begins, and is deleted from the non-monitored object list after the work is completed. If the event notification (the target equipment 100 identified by the event notification) corresponds to a non-monitored object, the event notification is discarded and no further processing is performed. If the equipment corresponds to a non-monitored object, If not, the information obtained from the event notification is passed to the job selection unit 13 .

[0032] The job selection unit 13 has a function of selecting a job to be executed from among the jobs registered in the database 15 based on information extracted from the event notification. A job is data defining "a process to be executed on the target equipment 100 or the monitoring device 200" and / or "a process to be executed on the operator 300 of the target equipment 100." A job is defined for each type of failure that may occur in each target equipment 100, and these jobs are registered in advance in the database 15. Examples of processes to be executed on the target equipment 100 include processes to operate the target equipment 100 (shutdown, restart, command execution, etc.) and processes to obtain information (logs, status, etc.) from the target equipment 100. Examples of processes to be executed on the monitoring device 200 include processes to operate the monitoring device 200 (command execution, etc.) and processes to obtain information (logs, status, etc.) of the target equipment 100 recorded in the monitoring device 200. Furthermore, the processing executed for the operator 300 corresponds to, for example, processing for notifying the operator 300 (such as making a call or sending a message) and processing for sending data to the terminal 310 of the operator 300.

[0033] The job control unit 14 has a function of executing the job selected by the job selection unit 13. At this time, the job control unit 14 executes the job while referring to various parameter values ​​registered in the database 15.

[0034] The database 15 stores a job table, job definition information, action definition information (including parameter values), a non-monitoring target list, and the like.

[0035] The setting change notification receiving unit 16 is a function that receives a setting change message (setting change notification) sent from the terminal 310 of the operator 300, and updates the information (parameter values, non-monitored list, etc.) registered in the database 15 according to the instructions contained in the setting change notification.

[0036] The setting UI unit 17 is a function that provides a user interface for various settings to the terminal 310 of the administrator 300. The administrator 300 can use a web browser or a dedicated application to operate the user interface provided by the setting UI unit 17 and check or change various settings. The setting UI unit 17 updates information (parameter values, non-monitored target list, etc.) registered in the database 15 in response to a setting change instruction from the administrator 300.

[0037] In consideration of reliability and availability, the operation support system 1 of this embodiment may employ a configuration in which major components are made redundant. For example, the operation support system 1 may be configured with an application server, a database server, a load balancer, and the like.

[0038] The application server is a server that executes each process of the operation support system 1 described above, and is provided redundantly with two server computers. Each computer has a CPU (processor), memory, storage, a communication interface, etc. Each function shown in Figure 1 is realized in software by loading a program non-temporarily stored in storage into memory and executing it with the CPU. The database server is a server that realizes the database 15 described above. The load balancer is a device that distributes access to the application server, and is provided redundantly with two units. All of these devices are connected to an uninterruptible power supply (UPS), allowing them to operate for a certain period of time even in the event of a commercial power outage. This configuration enables stable monitoring 24 hours a day, 365 days a year.

[0039] [Event Notifications] FIG. 2A is an example of a failure notification email.

[0040] The sending address written in the From field of the email header indicates the sender of the event notification (the monitoring device 200 or the target facility 100). In the example of Fig. 2A, it can be seen that the failure notification was issued from a device with the email address "abc@xxx.jp".

[0041] The Subject of the email header contains the "identifier of the target facility 100" where the failure occurred, the "monitoring item" and the "type of event". The identifier of the target facility 100 consists of the host name and IP address of the target facility 100. The monitoring item indicates which part of the functions, resources or services the target facility 100 has that has failed. The type of event indicates whether the event is a failure (CRITICAL) or a failure recovery (OK). In the example of Figure 2A, the host name of the target facility 100 is "WebSV-001", and the IP address is "IP address". The IP address is "210.100.27.111", the monitoring item is "Host Down", and the event It can be seen that the type is "CRITICAL (failure occurred)".

[0042] The operations support system 1 can monitor a wide variety of items. Examples include disk usage, CPU usage, GPU usage, memory usage, traffic, alive monitoring, port monitoring, database monitoring, and system log monitoring. For example, when monitoring resource usage such as disk, CPU, GPU, and memory, a "failure" is determined to have occurred when the usage exceeds a threshold. When monitoring traffic, a "failure" is determined to have occurred when the volume of network traffic exceeds a threshold. When monitoring alive monitoring or port monitoring, a "failure" is determined to have occurred when normal communication with the monitored device or port number cannot be performed. Note that the monitoring items and failure determination criteria listed here are merely examples, and any monitoring items and determination criteria can be set according to the configuration of the target facility 100 and the needs of the operator 300.

[0043] The email text contains information such as the date and time the failure occurred, the identifier of the target equipment 100, and the alarm content. In the example of Figure 2A, it is clear that the date and time the failure occurred was "2025 / 01 / 30 03:40", the host name of the target equipment 100 was "WebSV-001", the IP address was "210.100.27.111", and the alert content was "Host Down detected in WebSV-001. No response from WebSV-001."

[0044] The event notification analysis unit 11 extracts this information from the email header and email body. Then, the job selection unit 13 can identify the equipment where the failure has occurred and the details of the failure based on the "event notification sender," "target equipment identifier," and "monitoring item" extracted from the email header, and select the job to be executed.

[0045] Fig. 2B is an example of a failure recovery notification sent when the failure in Fig. 2A is recovered. An example of a failure recovery notification sent by email is shown.

[0046] The items described in the email header and email body are basically the same as those in the failure notification. Based on the information extracted from the email header, the equipment in question and the details of the failure can be identified, and because the event type is "OK (failure recovered)", it can be recognized that the event notification is an email notifying that a recent failure has been recovered.

[0047] Job and Action Details Next, a description will be given of "jobs" and "actions," which are characteristic architectures adopted by the operation support system 1 of this embodiment.

[0048] FIG. 3 is a diagram showing a schematic diagram of a job table, job definitions, and action definitions registered in the database 15. As shown in FIG.

[0049] The job table JT is a table that links a monitoring target identified by "the sender of the event notification, the identifier of the target equipment, and the monitoring item" with a "job." Each row in the job table JT represents one job. By referring to this job table JT, the job selection unit 13 can select job J001, for example, when it receives a failure occurrence notification such as that shown in FIG. 2A.

[0050] Each job is made up of an arbitrary combination of one or more actions, and defines the procedure and flow of processing. For example, job J001 is made up of three actions A1 to A3.

[0051] An action defines the processing to be executed by the operations support system 1. The processing unit (granularity) defined as an action can be designed arbitrarily. However, if the processing unit is divided too finely, numerous types of actions must be prepared. This increases the number of actions that make up a single job, making job definitions cumbersome and sophisticated, and potentially increasing development time. Conversely, assigning complex processing to individual actions reduces the versatility and reusability of the actions and increases the frequency of action modifications and maintenance. Therefore, the granularity of actions must be designed to strike an appropriate balance. For example, actions can be defined based on the human work units in traditional MSPs (such as making a phone call, sending a message, executing a command, and acquiring logs). Corresponding to the granularity of actions makes it easier to visualize the processing to be executed when creating a job definition. Furthermore, to increase the versatility and reusability of actions, it is best to design them assuming that processing is completed within a single action (each action is independent) without passing information between actions.

[0052] An action consists of a program and parameters. The program defines the processing procedure to be executed by the processor of the operation support system 1, and the parameters are setting values ​​that are referenced when the program is executed. By setting the parameter values ​​appropriately, it becomes possible to execute processing that meets the requests (required specifications) of the operator 300 of the target facility 100.

[0053] Parameters include two types: variable parameters and fixed parameters. Variable parameters are parameters that can be changed by the operator 300 of the target facility 100 himself, while fixed parameters are parameters that cannot be changed by the operator 300 (i.e., parameters that are changed by the administrator (MSP) of the operations support system 1). For example, items that may be changed frequently due to circumstances on the operator 300's side are assigned to variable parameters, and important items related to the basic operation of the operations support system 1 are assigned to fixed parameters. This configuration allows the operator 300 to make necessary setting changes himself, reducing the effort required to request setting changes from the MSP and enabling quick setting changes. On the other hand, parameters that may affect the stability and reliability of the operations support system 1 are protected as fixed parameters, thereby reducing the risk of system failure due to incorrect operation by the operator 300.

[0054] [Example of action] In this embodiment, the following actions are prepared in advance.

[0055] (1) Call action This is an action to make a phone call and notify the operator 300 by automated voice. The action has the following parameters: · Call list (variable): A list of phone numbers and contact names · Call order (variable): Order of calls to the destination Calling time period (fixed): Define the time period when the call handling method changes (weekday daytime / weekday nighttime / holidays, etc.) Loop count (fixed): Number of times to retry if no response is received - Call interval (fixed): Waiting time for re-call Escalation method (fixed): Escalation pattern when the person you are calling is unavailable ·Name when calling (fixed): Company name to be presented to the caller Call contents (fixed): Items to be notified by automated voice

[0056] (2) Email sending action An action to send an email to the administrator 300. The email sending action has the following parameters. - Recipient list (fixed): List of recipient addresses (including To / Cc / Bcc settings) · Email subject template (fixed): Standard subject line - Email body template (fixed): Standard text for the body of the email Attachment (fixed): Specify the file to attach to the email. · Email sender (fixed): The sender's company name to be included in the email body

[0057] (3) Command execution action An action to execute a command on the target facility 100. The command execution action has the following parameters. Network address (fixed) of the target device: IP address or URL Login ID of the target device (fixed): Login ID Password for the device (fixed): Password required for login · Use of a relay server (fixed): Whether to use a relay server to log in to the target device · Network address of the base server (fixed): IP address or URL - Login ID of the springboard server (fixed): Login ID · Bastion server password (fixed): Password required for login Command (variable): Command to be executed on the target equipment Arguments (variable): Arguments given to the command Execution result (fixed): How the command execution result is returned

[0058] (4) Log acquisition action An action to obtain log data of the target equipment 100 from a log server. The log server is a device that records and manages log data of the target equipment 100, and the monitoring device 200 may play the role of the log server, or the target equipment 100 itself may have the log server function. The log obtainment action has the following parameters. Log server network address (fixed): IP address or URL Log server login ID (fixed): Login ID Log server password (fixed): Password required for login · Use of a jump server (fixed): Whether to use a relay server to log in to the log server · Network address of the base server (fixed): IP address or URL - Login ID of the springboard server (fixed): Login ID · Bastion server password (fixed): Password required for login Log file path (fixed): Destination for storing log files Format (fixed): Log file data format

[0059] (5) Standby Action An action to wait for the arrival of a fault recovery notification. The wait action has the following parameters: Wait time (variable): Wait time for notification of failure recovery - Behavior upon reception (fixed): Processing when a failure recovery notification is received within the waiting time - Timeout behavior (fixed): What to do if no failure recovery notification is received within the waiting time

[0060] [Example of a job] 4A to 4D show specific examples of jobs.

[0061] 4A is a job for processing to immediately notify a user by telephone when a failure notification is received. Job J1 is defined by only one call action A10.

[0062] 4B is a job that performs processing such that, after receiving a failure notification, if a failure recovery notification is received within a predetermined time, it does nothing, but if a failure recovery notification is not received within the predetermined time, it notifies the user by phone and email. Job J2 is defined by a combination of three actions: a wait action A20, a phone call action A21, and an email send action A22.

[0063] 4C is a job that, when a failure notification is received, first sends an email, then starts waiting, and if a failure recovery notification is received within a specified time, sends an email notifying the user that the failure has been recovered, and if a failure recovery notification is not received within the specified time, notifies the user by phone. Job J3 is defined by a combination of four actions: email sending action A30, standby action A31, email sending action A32, and phone call action A33.

[0064] 4D is a processing job in which, when a failure notification is received, the job first sends an email, then acquires log data from the target facility 100, logs in to the target facility 100, executes a predetermined command, and reports the log data and the command execution results by attaching them to an email. Job J4 is defined by a combination of four actions: an email sending action A40, a log acquisition action A41, a command execution action A42, and an email sending action A43.

[0065] [Job and action implementation example] In the operation support system 1 of this embodiment, the following implementation techniques are employed for jobs and actions in order to simplify the creation and maintenance of jobs.

[0066] (Action specifications) An action is implemented as a program (or function) that can be executed independently. Here, "independently" means that it does not depend on data generated by other actions and can complete its processing on its own.

[0067] There are multiple types of actions, and each has a different program content (processing content), but the specifications of the action arguments (input) and return values ​​(output) are unified. It is recommended that all actions are designed to take no arguments and return the same type of return value. The return value should be a binary or multi-valued type, and in that case, the meaning of the return value should be consistent. For example, a Boolean return value with two values, True / False, may be used, with "True" if the action was successful and "False" if the action failed. Alternatively, a multi-valued (integer) return value with three values, 0 / 1 / 2, may be used, with "0" if the action was successful, "1" if the action failed, and "2" if an exception occurred during the action.

[0068] (Job Action Table) Figure 13 shows a job action table. The job action table is an example of a job definition implementation, and defines the combination of actions that make up a job and the order in which they are linked. As an example, Figure 13 shows a description example of a job action table when defining job J3 in Figure 4C. The return value of an action takes three values: 0, 1, and 2.

[0069] Each row in the job action table indicates the action link definition for each of the multiple actions that make up a job. The action link definition is information that links a target action with a next action to be executed. It includes definitions for the target action's action ID, the target action's type, the action ID for the next action (0), the action ID for the next action (1), and the action ID for the next action (2). The action ID is an identifier that references an action definition and is uniquely assigned to each action definition registered in the database 15. The next action (0) is the action that is executed when the target action's return value is 0, the next action (1) is the action that is executed when the target action's return value is 1, and the next action (2) is the action that is executed when the target action's return value is 2. In other words, multiple next actions that are executed selectively depending on the return value can be linked to a single target action. This framework enables simple conditional branching. If there is no next action to be executed, NULL is set instead of the action ID. At the end of the job, a terminal action is placed in which all next actions are set to NULL.

[0070] When a job is started according to the job action table shown in FIG. 13, the email sending action A30 is executed first. If the email sending action A30 is successful (completion is normal) and a return value of 0 is returned, the wait action A31 is executed. If the wait action A31 is successful (a failure recovery notification is received within the specified time) and a return value of 0 is returned, the email sending action A32 is executed. If the wait action A31 fails (a failure recovery notification cannot be received within the specified time) and a return value of 1 is returned, the phone call action A33 is executed. After the email sending action A32 or the phone call action A33 is executed, the terminal action Z is executed and the job ends. Note that the terminal action Z may be an action that does not include any processing substance (performs no processing), or may perform processing such as recording a log, releasing memory, or restoring to the initial state.

[0071] By defining and managing jobs using the action link definitions and job action table described above, both people (those responsible for developing and maintaining jobs) and machines (job control unit 14 of the operation support system 1) can accurately understand the action combinations and linking order.

[0072] Furthermore, by managing the connections between actions in a table format, job changes can be realized simply by modifying the action link definition in the table. Specifically, adding an action is accomplished by inserting a new action link definition and updating the next action to be executed in the previous stage, while deleting or changing the order of actions is accomplished by simply modifying the related action link definition. For example, Figure 1 Job 3 has a content of "if a failure recovery notice is not received within a specified time, only a phone call will be made," but if you want to change this to "if a failure recovery notice is not received within a specified time, both a phone call and an email will be made," you can do this by adding an action link definition for the email sending action A34 and modifying the next action to be executed (0) for the phone call action A33, as shown in Figure 14 (only the hatched part in Figure 14 needs to be modified). In this way, management using action link definitions and a job action table greatly improves the maintainability and expandability of jobs.

[0073] Furthermore, this embodiment employs a method of selecting the next action to be executed according to the return value after the target action has finished. This type of implementation enhances the modularity (independence) of actions compared to when the target action calls the next action to be executed, or when the next action to be executed is selected based on an internal conditional decision or internal variable of the target action. Furthermore, standardizing the return value specifications eliminates restrictions on combining actions (e.g., action Y cannot be combined after action X), allowing for greater freedom in combinations and linking orders, resulting in benefits such as improved development efficiency, prevention of configuration errors, and improved maintainability.

[0074] Furthermore, by explicitly writing NULL in the job action table where there is no next action to be executed, and explicitly writing a termination action at the end of the job, both people (those responsible for job development and maintenance) and machines (the job control unit 14 of the operation support system 1) can immediately and without error understand that there is no next action to be executed and that the job has ended. This is effective in preventing setting errors and malfunctions.

[0075] [How to change settings using the UI] FIG. 5 is a diagram for explaining the configuration and functions of the setting UI unit 17. As shown in FIG.

[0076] The setting UI unit 17 has a web server function 170 that accepts access from a user (operator 300) and a data access function 171 that sends and receives data to and from the database 15. When a user accesses the URL of a setting page provided by the web server function 170 using a web browser on the terminal 310, an authentication screen 60 shown in the upper part of Figure 6 is first displayed. The user logs in by entering their user ID and password on the authentication screen 60. If authentication is successful, a setting menu screen 61 shown in the lower part of Figure 6 is displayed. From the setting menu screen 61, it is possible to transition to three setting functions: "Call Destination Settings," "Command Settings," and "Non-Monitored Target Settings." In addition, the setting UI unit 17 uses the data access function 171 to read the job table JT linked to the user ID from the database 15.

[0077] The call destination setting function allows users to confirm and change the variable parameters of the call action: the "call destination list (list of phone numbers and contact names)" and "call order (order of calls to contacts)." When a user clicks "call destination setting" on the settings menu screen 61, the call destination setting screen 70, as shown in Figure 7A, appears. The "Project" button at the top of the call destination setting screen 70 displays the project for which the settings are to be changed. A project refers to a unit of monitoring work that the user (operator 300) has outsourced to the MPS provider of the operations support system 1. If the user has outsourced multiple monitoring work, clicking the "Project" button displays a drop-down list, allowing the user to select the project for which the settings are to be changed. The "Registered Person List" on the left side of the call destination setting screen 70 displays a list of contact names and phone numbers registered in the operations support system 1. Registered users can be added, their registration details changed, or deleted using the "New," "Edit," and "Delete" buttons below the registered user list. The "List of Call Destinations" on the right side of the call destination setting screen 70 shows the call destinations and the order of calls referenced in the call action. The example in FIG. 7A shows the list of call destinations: Oda Tomoko → Eyama Osamu → Kitajima Daiki This shows a setting where calls will be made in the order of Mr. Abe → Taro Abe. By selecting a row in the list of registered users and clicking the "Add →" button, you can add the person in the selected row to the list of call recipients. Conversely, by selecting a row in the list of call recipients and clicking the "Delete ←" button, you can delete the person in the selected row from the list of call recipients. You can also change the call order by dragging rows in the list of call recipients. For example, in Figure 7A, Ukawa Hanako is selected. Pressing the "Edit" button in this state will edit her name and phone number, and pressing the "Delete" button will delete her record from the list of registered users. Pressing the "Add →" button will add Ukawa Hanako to the bottom (5th) of the list of call recipients.

[0078] FIG. 7B shows another example of the call destination setting screen 71. In this call destination setting screen 71, the checkbox on the left side of the list can be used to switch between including a call destination (active) and not including a call destination (inactive). FIG. 7B shows an example in which four people, Abe Taro, Eyama Osamu, Oda Tomoko, and Kitajima Daiki, have been set as call destinations. In addition, the pull-down button on the right side of the list can be used to set the priority (order of calls to the call destinations). Note that FIGS. 7A and 7B are merely examples of setting screens, and any UI may be used as long as it allows for changing the call destination and call order settings.

[0079] The command setting function allows the user to check and change the "command" and "arguments," which are variable parameters of the command execution action. When the user clicks on "Command Settings" on the settings menu screen 61, a command list screen 80 such as that shown in Figure 8A is displayed. The command list screen 80 displays a "Case" button and a list of commands set for that case. When the "New" button is clicked, a command setting screen 81 such as that shown in Figure 8B is displayed. On this command setting screen 81, the user can set the desired command by entering the command to be executed on the target equipment 100 and the arguments for that command, and pressing the OK button. Validation checks are performed on values ​​entered on the input forms of the call destination setting screens 70 and 71 and the command setting screen 81 at the time of entry, and an error message is displayed if an invalid value is entered.

[0080] The non-monitoring target setting function allows users to check and update the non-monitoring target list. FIG. 9 shows an example of a non-monitoring target setting screen 90. A list of currently registered non-monitoring targets is displayed at the top of the screen, and a form for new registration is located at the bottom. The list display area allows users to check the host name and IP address of each non-monitoring target. Users can also click the Delete button for a non-monitoring target to remove it from the non-monitoring target list (i.e., resume monitoring). In the new registration form, users can register a new non-monitoring target by entering the host name or IP address of the equipment and clicking the Register button. Note that this embodiment performs simple control: if a device is listed in the non-monitoring target list, it is not monitored; if not, it is monitored. However, it is also possible to specify the start and end dates and times of non-monitoring in the non-monitoring target list in advance, so that monitoring is switched to non-monitoring when the start date and time arrives and monitoring is resumed when the end date and time arrives.

[0081] When the settings are changed using the call destination setting function, command setting function, or non-monitored target setting function, the setting UI unit 17 uses the data access function 171 to update the variable parameter values ​​and non-monitored target list registered in the database 15. At this time, important setting changes may be recorded as an operation log so that the change history can be tracked later. Furthermore, when the settings in the database 15 are updated, an update completion notification may be sent to the MSP and the operator 300.

[0082] [How to change settings using setting change notification] In addition to using the UI provided by the setting UI unit 17, the user (administrator 300) can also It is also possible to change the parameter values ​​and non-monitoring list settings using email, etc.

[0083] Figure 10 is an example of a setting change notification email for changing a parameter value. The email's destination (To) is specified as "param@yyy.jp," an address dedicated to receiving setting changes, and the Subject contains the keyword "CHANGE_CALL_INFO," which indicates the parameter to be changed. This keyword is an example of changing the call destination and call order. The changed parameter value is then written in the email body in a specified format.

[0084] Figure 11A is an example of a setting change notification email for adding a new non-monitoring target to the non-monitoring target list. The email's destination (To) is specified as "param@yyy.jp," an address dedicated to receiving setting changes, and the keyword "ADD_PAUSE_RULE" is entered in the Subject field to indicate that a non-monitoring target is being added. The body of the email then contains the host name or IP address of the target equipment in a specified format. Note that if the start and end dates and times for non-monitoring can be reserved, the start and end dates and times may also be specified in the body of the email.

[0085] Figure 11B is an example of a setting change notification email for deleting a non-monitoring target from the non-monitoring target list. The email address (To) is specified as "param@yyy.jp," a dedicated address for receiving setting changes, and the subject is "DELETE_PAUSE_RULE," which indicates that the non-monitoring target is being deleted. The host name or IP address of the target facility is written in the body of the email in a predetermined format.

[0086] When the setting change notification receiver 16 receives a setting change notification such as that shown in FIGS. 10, 11A, and 11B, it updates the information (such as parameter values ​​and the non-monitored target list) registered in the database 15 in accordance with the instructions included in the setting change notification. When the settings in the database 15 are updated, an update completion notification may be sent to the administrator 300. The method of using a setting change notification is particularly useful when monitoring needs to be stopped immediately due to an unexpected task, when automatic registration is desired in conjunction with an in-house system, or when registration is desired from a device such as a smartphone where it is difficult to access a web screen. Note that although an example of email is shown here, the setting change notification may be sent using a means other than email, such as a message exchange means such as SMS or a business communication tool.

[0087] [Monitoring operation example] Fig. 12 shows an example of the monitoring operation of the operation support system 1. Here, an example will be described in which the execution of job J3 shown in Fig. 4C is triggered by the receipt of the failure occurrence notification shown in Fig. 2A.

[0088] When a host down of the target facility 100 is detected, a failure occurrence notification (FIG. 2A) is issued from the monitoring device 200. The event notification receiving unit 10 of the operation support system 1 receives the failure occurrence notification and passes the email to the event notification analyzing unit 11 (step S100). The event notification analyzing unit 11 acquires information such as the identifier of the target facility 100, the monitoring item, and the type of event from the failure occurrence notification (step S101).

[0089] Next, the wait-and-see determination unit 12 checks whether the target equipment 100 is registered in the non-monitoring list (step S102). If registered in the non-monitoring list, the wait-and-see determination unit 12 determines that this failure occurrence notification can be monitored (ignored), discards the failure occurrence notification, and terminates the process (YES in step S103). If the target equipment 100 is not registered in the non-monitoring list (NO in step S103), the process proceeds to step S104.

[0090] In step S104, the job selection unit 13 selects a corresponding job from the job table JT in the database 15 based on the information (identifier and monitoring item of the target equipment 100) acquired from the email. Here, it is assumed that job J3 is selected.

[0091] The job control unit 14 first executes the email sending action A30, which is the first action in job J3 (step S105). Specifically, the job control unit 14 reads the program and parameter values ​​of the email sending action A30 from the database 15, and executes the program according to the parameter values ​​to send an email to a pre-registered destination notifying the occurrence of a failure.

[0092] Next, the job control unit 14 executes a wait action A31, which is the second action in job J3. Specifically, the job control unit 14 waits for the arrival of a failure recovery notification while timing the specified wait time using a timer (step S106). The wait time may be specified by a parameter or may be specified in the failure occurrence notification. For example, the wait time can be specified by embedding a wait specification command such as "WAIT5m" (wait 5 minutes) in the subject or email body of the failure occurrence notification. By allowing the wait time to be specified in the event notification in this way, a highly versatile and convenient system can be realized. Note that if the operator 300 specifies the wait time as 0, the wait action A31 is skipped.

[0093] If a failure recovery notification is received within the standby time (YES in step S107), standby action A31 returns a recovery flag and terminates, and if a failure recovery notification is not received within the standby time (NO in step S107), standby action A31 returns a non-recovery flag and terminates. The job control unit 14 changes the next action to be called depending on the flag returned by standby action A31.

[0094] If the recovery flag is set, the job control unit 14 executes the email sending action A32, which is the third action in job J3 (step S108). Specifically, the job control unit 14 reads the program and parameter values ​​of the email sending action A32 from the database 15, and executes the program according to the parameter values ​​to send an email to a pre-registered destination notifying that the failure has been recovered.

[0095] If the non-recovery flag is set, the job control unit 14 executes the fourth action in job J3, which is call action A33 (step S109). Specifically, the job control unit 14 reads the program and parameter values ​​of call action A33 from the database 15, and executes the program according to the parameter values ​​to place a call to a pre-registered phone number and notify the user of the occurrence of a failure by automated voice. If the call to the person in charge cannot be connected, call control such as switching to the next call destination or escalation is executed according to the parameter settings. This completes the series of processes for notifying the occurrence of a failure.

[0096] [Features of the operation support system] In the operation support system 1 of this embodiment, processing for the target equipment 100 and the operator 300 is defined as a "job," and the job can be configured as a combination of pre-prepared "actions." Each action is composed of a program and parameters, and individual requirements can be met by setting the combination of actions and parameter values ​​according to the operator 300's requests. This configuration eliminates the need for program coding for each individual case or detailed program development, significantly reducing the number of development steps. Furthermore, even if the operator 300's requests or the equipment configuration change, there is basically no need to modify the program itself; it can be handled simply by changing the job configuration and parameter values ​​registered in the database 15. This allows for quick response to operational changes with little effort. We can respond to this.

[0097] Furthermore, the operation support system 1 employs an architecture in which a job is started when an event notification is received, thereby achieving loose coupling between the target equipment 100 (or the monitoring device 200) and the operation support system 1. This architecture makes it possible to support a variety of equipment 100 via a highly versatile interface, such as a message exchange means like email, regardless of the type or configuration of the target equipment 100 (or the monitoring device 200). This also contributes to reducing the development man-hours for the operation support system 1 and improving maintainability.

[0098] Furthermore, the operations support system 1 employs an architecture in which the processes to be executed are modularized as "actions" and jobs are defined by arbitrarily combining multiple components (actions). This makes it possible to add functionality to the operations support system 1 by adding new actions, resulting in a highly scalable system. Furthermore, even if a program malfunction occurs, the problem can be isolated at the action level, making it easy to deal with the malfunction. This also contributes to reducing the development man-hours for the operations support system 1 and improving maintainability.

[0099] The operations support system 1 also employs a method for sequentially linking actions. This allows jobs to be created intuitively by arranging actions in order, enabling even those without specialized programming knowledge to easily build processes that meet the operator's 300 needs. The sequential structure also ensures a one-way processing flow and clearly identifies the connections between each action, making it easy to understand the job's operation. This feature prevents configuration errors during job creation and improves the reliability and usability of the system. Furthermore, in the unlikely event of a malfunction, the sequential processing flow makes debugging and problem identification easy. Job modifications can be made with simple operations such as inserting new actions, replacing existing actions, and changing the order, achieving high maintainability.

[0100] Furthermore, the operation support system 1 provides a mechanism that allows the operator 300 to change the parameters referenced by actions, enabling the operator 300 to make necessary setting changes himself, reducing the time and effort required to request setting changes from the MSP and enabling quick setting changes. On the other hand, parameters that may affect the stability and reliability of the system are protected as fixed parameters, reducing the risk of system failure due to operator error.

[0101] Furthermore, by providing a UI for changing parameter settings, the operator 300 can make necessary setting changes while checking the current parameter values ​​on the screen, even if he or she does not have special knowledge. This improves the convenience of the operation support system 1. Furthermore, since it is possible to immediately check the format and validate the input values ​​at the UI level, it is also possible to prevent incorrect input of parameter values.

[0102] Also, by making it possible to change parameter settings by sending a setting change notification via email or the like, there is an advantage that the setting can be changed from any type of terminal that can send emails, without the need to install special software on the terminal 310 of the operator 300 or go through an authentication process such as logging in to the operation support system 1. Also, it is easy for the operator to automate setting changes by creating a script that automatically generates and sends emails or the like in cooperation with an in-house system.

[0103] In many cases, the telephone number of the call recipient changes every time there is a change in the system or personnel transfer of the operator 300. In the call action provided in the operation support system 1, the telephone number of the call recipient and the call order are changed. As described above, items that may change frequently due to circumstances on the part of the operator 300 are made variable parameters so that the operator 300 can change them himself. This reduces the workload of both the operator 300 and the MSP, and improves convenience for the operator 300.

[0104] While construction work (such as setting changes, equipment replacement, and inspection) is being performed on the target facility 100, the target facility 100 and its monitoring device 200 frequently issue event notifications. However, taking action in response to these event notifications, such as notifying the operator 300, is simply a hassle for the operator 300 and is inappropriate. Furthermore, if such notifications that do not require action are received by the operator 300, there is a risk that notifications that truly require action will be buried and overlooked. Therefore, if construction work or planned shutdowns of the target facility 100 are known in advance, they can be registered on a non-monitored list. This allows event notifications corresponding to non-monitored events to be ignored and prevents unnecessary processing from being performed on the facility 100 and its operator 300. This reduces the hassle for the operator 300 and allows them to focus on events that truly require action.

[0105] In addition, by providing a UI for checking and changing the settings of the non-monitored list, the operator 300 can check, add, and delete non-monitored targets on the screen himself, thereby improving the convenience of the operation support system 1.

[0106] Also, by making it possible to change the settings of the non-monitored targets list using a setting change notification via email or the like, there is an advantage that it is possible to issue an instruction to add or delete non-monitored targets from any type of terminal that can send email, without the need to install special software on the terminal 310 of the operator 300 or go through an authentication process such as logging in to the operation support system 1. Also, by creating a script on the operator 300 side that automatically generates and sends emails in cooperation with an internal system, it is easy to automate the addition or deletion of non-monitored targets.

[0107] In addition, in this embodiment, a standby action specialized only for standby processing is prepared, and this standby action is combined with a phone call action, etc. as needed, which has the advantage of facilitating the development and maintenance of the operation support system 1.

[0108] [others] The above-described embodiment merely exemplifies a configuration example of the present invention. The present invention is not limited to the specific embodiment described above, and various modifications are possible within the scope of the technical concept. For example, the event notification, job, action, and UI configurations described in the above-described embodiment are merely examples, and may be appropriately designed depending on the type of target equipment and the monitoring process to be performed. Furthermore, while the above-described embodiment uses standard format messages to notify setting changes to parameter values ​​and non-monitored lists, free-format messages may also be used. In the case of free-format messages, the setting change instructions may be interpreted using natural language analysis, or the instructions may be extracted from the message using a generation AI. Furthermore, the above-described embodiment illustrates an email sending action that notifies the user via email, but the user may also be notified via message exchange means other than email (e.g., SMS, business communication tools, etc.). Furthermore, the above-described embodiment illustrates a setting UI using a web browser. However, a dedicated app for accessing the operations support system 1 may be installed on the terminal 310 of the operator 300, and various setting changes may be made using the UI provided by the dedicated app. [Explanation of symbols]

[0109] 1: Operational support system 100: Target equipment 200: Monitoring device 300: Operator 310: Operator's terminal

Claims

1. An operation support system for supporting the operation of target equipment, a database in which a plurality of types of jobs defining processes to be executed on the target equipment or a monitoring device that monitors the target equipment, and / or processes to be executed on an operator of the target equipment are registered in advance; an event notification receiving unit that receives an event notification issued from the target facility or the monitoring device when a predetermined event occurs in the target facility; a job selection unit that selects a job to be executed from among the plurality of types of jobs registered in the database based on information extracted from the event notification; a job control unit that executes the job selected by the job selection unit, a plurality of types of actions, which are programs executed by a processor of the operation support system, are prepared in advance; the job is configured by sequentially connecting two or more actions selected from the plurality of types of actions prepared in advance, A combination of actions constituting the job and their connection order are determined in accordance with the request of the operator of the target equipment, and the combination and order are set in the database, thereby enabling the execution of processing that meets the request of the operator of the target equipment; the event notification includes a failure occurrence notification that notifies that a failure has occurred in the target equipment, and a failure recovery notification that notifies that the failure in the target equipment has been recovered from, The plurality of types of actions include a standby action for waiting for a predetermined standby time until a failure recovery notification is received when the failure occurrence notification is received. An operational support system characterized by the above.

2. the job has a job action table in which an action link definition linking an action to be executed with a next action to be executed after the action to be executed is described for each of two or more actions constituting the job; The job control unit executes actions sequentially in accordance with the action link definition in the job action table. The operation support system according to claim 1 .

3. The action link definition can link a plurality of next execution actions that are executed alternatively to one of the execution target actions. The operation support system according to claim 2 .

4. The job control unit selects an action to be executed from among the plurality of next execution actions in accordance with a return value of the action to be executed. The operation support system according to claim 3 .

5. All of the above types of actions are designed to return the same type of return value. The operation support system according to claim 4.

6. In the action link definition, if there is no action to be executed after the action to be executed, NULL is set as the next action to be executed. The operation support system according to claim 5 .

7. At the end of two or more actions that are linked sequentially, a terminal action is placed in which all of the next execution actions are set to NULL. The operation support system according to claim 6.

8. The database stores parameters referenced by the action, By determining the combination of actions constituting the job and the parameter values ​​of each action in accordance with the request of the operator of the target equipment and setting them in the database, it is possible to execute processing that meets the request of the operator of the target equipment.

8. An operation support system according to claim 1.

9. The parameters include variable parameters that can be changed by the operator of the target equipment himself, and fixed parameters that cannot be changed by the operator of the target equipment. The operation support system according to claim 8.

10. A command specifying the waiting time is embedded in the subject or email body of the failure notification. The operation support system according to claim 1 .

11. If the wait time specified by the command is 0, the wait action is skipped. The operation support system according to claim 10.

Images