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 can be configured by any combination of one or more actions selected from multiple types of actions prepared in advance, and each of the multiple types of actions is configured by a program executed by a processor in the operations support system and parameters referenced by the program. By determining the combination of actions that make up the job and the parameter values ​​of each action according to the needs of the operator of the target equipment and setting them 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] For example, call control requires detailed rules regarding the telephone number of the call recipient, how many calls to register, the order in which to make calls, what to do if the call doesn't connect, and whether to handle calls differently on weekdays, weekends, and holidays. Furthermore, with each internal organizational change or personnel transfer on the operator's side, the person in charge of calls, telephone numbers, and call rules often change. Building a system that can flexibly accommodate such individual requests and changes is no easy task.

[0009] 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]

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

[0011] The present invention provides an operations support system for supporting the operation of target equipment, the operations support system comprising: a database in which multiple types of jobs defining processing to be executed on the target equipment or a monitoring device monitoring the target equipment, and / or processing to be executed on an operator of the target equipment are pre-registered; an event notification receiving unit that receives an event notification issued from the target equipment or the monitoring device when a predetermined 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 the job can be configured by any combination of one or more actions selected from multiple types of actions prepared in advance, and each of the multiple types of actions is configured by a program executed by a processor of the operations support system and parameters referenced by the program, and the operations support system is characterized in that the combination of actions that constitute the job and the parameter values ​​of each action are determined in accordance with the requests of the operator of the target equipment, and the parameter values ​​of each action are set in the database, thereby making it possible to execute processing that meets the requests of the operator of the target equipment.

[0012] This configuration eliminates the need for program coding or detailed programming for each individual project, significantly reducing development man-hours. Furthermore, even if changes occur in operator requirements or equipment configuration, there is generally no need to modify the program itself; changes can be accommodated simply by changing the job configuration and parameter values ​​registered in the database. This allows for rapid response to operational changes with minimal man-hours.

[0013] 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.

[0014] The system may further include a setting UI unit that provides a user interface for checking and changing the setting values ​​of the variable parameters on a terminal of an operator of the target equipment, and the setting UI unit may update the value of the variable parameter registered in the database when the value of the variable parameter is changed in the user interface. By providing such a UI, the operator himself or herself can make necessary setting changes while checking the current parameter values ​​on the screen, even without special knowledge, thereby improving the convenience of the system.

[0015] The system may further include a setting change notification receiving unit that receives a setting change notification from an operator of the target equipment, and when the setting change notification includes an instruction to change the setting value of the variable parameter, the setting change notification receiving unit updates the value of the variable parameter registered in the database. This method has the advantage that the setting can be easily changed from a terminal on the operator side.

[0016] The plurality of types of actions may include a call action for calling the operator of the target equipment, and the variable parameters of the call action may include the telephone number of the call destination. In many cases, the telephone number of the call destination changes every time the operator changes its organization or personnel. Therefore, by allowing the operator to change the item themselves, it is possible to reduce the work of both the operator and the MSP company, and to improve the convenience of the operator. The action may include a command execution action that executes a command on the target equipment, and a variable parameter of the command execution action may include a command to be executed on the target equipment.

[0017] The database may include a list of non-monitored targets, which includes non-monitored targets for which monitoring is temporarily suspended. The database may further include a wait-and-see determination unit that references the list of non-monitored targets to determine whether the event notification received by the event notification receiving unit corresponds to the non-monitored target. If the event notification corresponds to the non-monitored target, the wait-and-see determination unit discards the event notification so that the job selection unit does not process the event notification. This configuration allows the system to ignore event notifications corresponding to non-monitored targets and prevent unnecessary processing for the equipment and its operator. This reduces operator hassle and allows the operator to focus on events that truly require attention.

[0018] The system may further include a setting UI unit that provides a user interface for checking and changing the settings of the non-monitoring target list on a terminal of an operator of the target equipment, and the setting UI unit may update the non-monitoring target list registered in the database when a non-monitoring target is added or deleted in the user interface. By providing such a UI, the operator can check, add, and delete non-monitoring targets on the screen himself, thereby improving the convenience of the system.

[0019] The system may further include a setting change notification receiving unit that receives a setting change notification from an operator of the target equipment, and the setting change notification receiving unit may update the non-monitored target list registered in the database when the setting change notification includes an instruction to add or delete a non-monitored target. This method has the advantage that an instruction to add or delete a non-monitored target can be easily given from an operator's terminal.

[0020] The event notification may include 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, and the multiple types of actions may include a standby action that waits for a predetermined standby time to receive a failure recovery notification when the failure occurrence notification is received. By preparing a standby action specialized only for standby processing and combining this standby action with a phone call action or the like as necessary, there is an advantage in that the development man-hours and maintenance of the system are simplified.

[0021] The wait action may determine the wait time based on information extracted from the event notification. For example, if the wait time can be specified in the subject or body of the event notification, a highly versatile and convenient system can be realized.

[0022] 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]

[0023] 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]

[0024] [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. DETAILED DESCRIPTION OF THE INVENTION

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

[0026] [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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] The wait-and-see determination unit 12 has a function of referring to the non-monitored object list registered in the database 15 and determining whether 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 event notification does not correspond to a non-monitored object, the information obtained from the event notification is passed to the job selection unit 13.

[0034] 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.

[0035] 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.

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

[0037] 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.

[0038] 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 operates the user interface provided by the setting UI unit 17 using a web browser or a dedicated application, and checks and changes various settings. The setting UI unit 17 updates the information (parameter values, non-monitoring target list, etc.) registered in the database 15 in response to a setting change instruction from the administrator 300.

[0039] 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.

[0040] 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.

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

[0042] 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".

[0043] 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)".

[0044] 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.

[0045] The email body contains the date and time of the failure, the identifier of the target equipment 100, the alarm content, etc. In the example of Figure 2A, the date and time of the failure is "2025 / 01 / 30 03:40", the host name of the target equipment 100 is "WebSV-001", the IP address is "210.100.27.111", and the alert content is "Host Down detected on WebSV-001. WebSV-0 You can see that there is no response from 01.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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 requirements (required specifications) of the operator 300 of the target facility 100.

[0055] 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.

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

[0057] (1) Call action This is an action to make a phone call and notify the operator 300 by automated voice. The call 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

[0058] (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

[0059] (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

[0060] (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

[0061] (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

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

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] [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.

[0068] 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 uses a web browser on the terminal 310 to access the URL of a setting page provided by the web server function 170, 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.

[0069] 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 "Call Destination List" on the right side of the call destination setting screen 70 shows the call destinations and the call order referenced in the call action. The example in Figure 7A shows a setting in which calls are made in the following order: Tomoko Oda → Osamu Eyama → Daiki Kitajima → Taro Abe. Selecting a row in the list of registered users and clicking the "Add →" button adds the selected row to the call destination list. Conversely, selecting a row in the list of registered users and clicking the "Delete ←" button removes the selected row from the list of registered users. Dragging rows in the list of registered users also allows you to change the call order. For example, in Figure 7A, Hanako Ukawa is selected. Pressing the "Edit" button edits her name and phone number, and pressing the "Delete" button removes her record from the list of registered users. Pressing the "Add →" button also adds Hanako Ukawa to the bottom (fifth) of the list of registered users.

[0070] 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 (active) and not including (inactive) as call destinations. 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 FIG. 7A and FIG. 7B are merely examples of setting screens, and the call destinations and call destinations can be set in a variety of ways. Any UI may be used as long as it allows the order settings to be changed.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] [How to change settings using setting change notifications] In addition to using the UI provided by the setting UI unit 17, the user (administrator 300) can also change the settings of the parameter values ​​and the non-monitoring list by using e-mail or the like.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] [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.

[0080] 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).

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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 with 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 for 5 minutes) in the subject or email body of the failure occurrence notification. In this way, the event By allowing the user to specify the waiting time in the event notification, a highly versatile and user-friendly system can be realized. If the operator 300 specifies the waiting time as 0, the waiting action A31 is skipped.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] [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's 300's requests. This configuration eliminates the need for program coding or detailed program development for each individual case, significantly reducing development man-hours. Furthermore, even if the operator's 300 requests or the equipment configuration change, there is basically no need to modify the program itself; changes can be made simply by changing the job configuration and parameter values ​​registered in the database 15. This allows for rapid response to operational changes with minimal man-hours.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] In many cases, the telephone number of the call recipient changes every time there is a change in the organization or personnel of the operator 300. In the call action provided in the operation support system 1, items that may change frequently due to circumstances on the operator 300 side, such as the telephone number of the call recipient and the call order, are set as variable parameters so that the operator 300 can change them himself. This reduces the workload of both the operator 300 and the MSP company, and improves convenience for the operator 300.

[0095] 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, the operator can register the facility 100 on a non-monitored list. This allows the operator 300 to ignore event notifications that are not monitored and prevent unnecessary processing from being performed on the facility 100 and its operator 300. This reduces the hassle for the operator 300 and allows the operator 300 to focus on events that truly require action.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] [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]

[0100] 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, The job can be configured by any combination of one or more actions selected from a plurality of types of actions prepared in advance, each of the plurality of types of actions is configured from a program executed by a processor of the operation support system and a parameter referenced by the program; A combination of actions constituting the job and the parameter values ​​of each action are determined in accordance with the request of the operator of the target equipment, and the combination and parameter values ​​of each action 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 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 1 .

3. The system further includes a setting UI unit that provides a user interface for checking and changing the setting values ​​of the variable parameters to a terminal of an operator of the target equipment, When the value of the variable parameter is changed in the user interface, the setting UI unit updates the value of the variable parameter registered in the database. The operation support system according to claim 2 .

4. The device further includes a setting change notification receiving unit that receives a setting change notification from an operator of the target equipment, The setting change notification receiving unit updates the value of the variable parameter registered in the database when the setting change notification includes an instruction to change the setting value of the variable parameter. The operation support system according to claim 2 .

5. The plurality of types of actions include a call action for making a call to an operator of the target equipment, The variable parameters of the call action include the telephone number of the call recipient.

5. The operation support system according to claim 3 or 4.

6. the plurality of types of actions include a command execution action that executes a command on the target equipment; The variable parameters of the command execution action include a command to be executed on the target equipment.

5. The operation support system according to claim 3 or 4.

7. a non-monitoring target list in which non-monitoring targets for which monitoring is to be temporarily suspended are registered in the database; The system further includes a wait-and-see determination unit that refers to the non-monitoring target list to determine whether the event notification received by the event notification receiving unit corresponds to the non-monitoring target, and, if the event notification corresponds to the non-monitoring target, discards the event notification so that the event notification is not processed by the job selecting unit. The operation support system according to claim 1 .

8. The device further includes a setting UI unit that provides a user interface for checking and changing the settings of the non-monitoring list to a terminal of an operator of the target equipment, The setting UI unit updates the non-monitoring target list registered in the database when a non-monitoring target is added or deleted in the user interface. The operation support system according to claim 7.

9. The device further includes a setting change notification receiving unit that receives a setting change notification from an operator of the target equipment, The setting change notification receiving unit updates the non-monitoring target list registered in the database when the setting change notification includes an instruction to add or delete a non-monitoring target. The operation support system according to claim 7.

10. The wait action determines the wait time based on information extracted from the event notification. The operation support system according to claim 1 .

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

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

Images