Operation management device, operation management method, and operation management program

Abstract

To appropriately estimate a user which can be affected.SOLUTION: In an operation management device 15 for managing operation of a system 11 providing service 12 requesting external service 14 to perform processing through an API (Application Programming Interface), a storage device stores test data making the external service execute processing through the API, the external service 14 used through the service 12 by a user, and correspondence between the external service 14 and the API used by the user, and the processor detects whether or not an obstacle occurs on the external service side, confirms whether or not the obstacle on the external service side is reproduced through the API used when the obstacle occurs using the test data, when detecting the obstacle, and specifies the external service and a user using the used API, when reproducing the obstacle on the external service side.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an operation management technique for a system that provides a service to multiple users, which requests processing from the service via an API (Application Programming Interface). [Background technology]

[0002] Cloud-native applications, which combine public clouds and small services known as microservices to enable rapid system updates and ongoing updates, are becoming more common. As a result, the trend is shifting from the traditional approach of continuing to use applications developed on stable IT (Internet Technology) infrastructure without updating them as long as they continue to operate stably, to one in which open source software (OSS) and commercial software as a service (SaaS) are actively incorporated, and systems are frequently and locally updated to address issues as well as to meet new customer requests.

[0003] Cloud-native applications provide mechanisms that can withstand failures such as abnormal service terminations and high loads, which are one of the causes, by using redundant configurations and automatic scaling for important microservices. However, if a service behaves abnormally due to faulty code, it is necessary to quickly identify the cause, and if the cause is something that the company can handle, it must take action. If the cause is commercial SaaS that the company cannot handle, it is necessary to understand that a failure has occurred that is not the company's fault and notify users.

[0004] Patent Document 1 discloses a technology that predicts the impact that services provided by other companies will have on a company's own system by learning the relationship between posts on SNS (Social Network Service) about failures in services provided by other companies and failures in the company's own system.

[0005] Furthermore, Patent Document 2 discloses a technology that stores information on the services used by each user, access history information, and failure history for each service, and suppresses unnecessary notifications by not notifying failure information to users who are unlikely to use the service until the estimated time of service recovery when a service failure occurs. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Patent Publication No. 2021-140308 [Patent Document 2] Japanese Patent Application Publication No. 2018-46422 Summary of the Invention [Problem to be solved by the invention]

[0007] However, Patent Document 1 applies to systems in which failure information is posted on SNS, but cannot be applied to systems in which this is not the case. Also, while it may be possible to detect a failure in a service provided by another company, it does not take into consideration whether the failure affects all users of the service or only some users who use a specific function within the service.

[0008] Furthermore, in Patent Document 2, the users to whom the fault information should be notified are narrowed down from the viewpoint of whether or not they will use the service in which the fault occurs by the estimated time of fault recovery, but no consideration is given to which users will be affected if a fault occurs in some of the services used by the service.

[0009] The present disclosure has been made in consideration of the above circumstances, and its purpose is to provide a technology that can appropriately estimate users who may be affected when a failure occurs in a service that is requested to be processed by a service provided to users. [Means for solving the problem]

[0010] In order to achieve the above-mentioned object, an operation management device according to one aspect is an operation management device that manages the operation of a system that provides a provided service to multiple users, which requests processing from one or more called services via an API (Application Programming Interface), and the operation management device has one or more processors and a memory device, and the memory device stores test data that causes the called service to execute processing via the API, the called service that the user is using through the provided service, and a correspondence between the called service and the API that the user uses, and the processor detects whether a failure has occurred on the called service side of the provided service for a specified user, and if a failure on the called service side is detected, uses the test data to execute a confirmation test to confirm whether the failure on the called service side can be reproduced via the API that was used when the failure occurred, and if the failure on the called service side is reproduced as a result of the confirmation test, identifies the user who is using the called service and the API that was used. [Effects of the Invention]

[0011] The present disclosure provides a technology that can appropriately estimate users who may be affected when a failure occurs in a service that is requested to be processed by a service provided to users. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram showing the overall configuration of a computer system according to one embodiment. [Figure 2] FIG. 2 is a hardware configuration diagram of an operation management apparatus according to an embodiment. [Figure 3] FIG. 3 is a diagram illustrating the configuration of a main memory and a storage device of an operation management apparatus according to an embodiment. [Figure 4A] FIG. 4A is a diagram illustrating an example of a user table according to an embodiment. [Figure 4B]FIG. 4B is a diagram illustrating an example of an external service table according to an embodiment. [Figure 4C] FIG. 4C is a diagram illustrating an example of a microservice table according to an embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of an external service API table according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of an API usage status table according to an embodiment. [Figure 7] FIG. 7 is a diagram illustrating an example of a confirmation test table according to an embodiment. [Figure 8] FIG. 8 is a diagram illustrating an example of an influence range estimation table according to an embodiment. [Figure 9] FIG. 9 is a flowchart of a log monitoring process according to an embodiment. [Figure 10] FIG. 10 is a flowchart of a verification test process according to one embodiment. [Figure 11] FIG. 11 is a flowchart of an influence range estimation process according to an embodiment. [Figure 12A] FIG. 12A is a diagram illustrating a first example of a service status check screen according to an embodiment. [Figure 12B] FIG. 12B is a diagram illustrating a second example of a service status check screen according to an embodiment. [Figure 12C] FIG. 12C is a diagram illustrating a configuration of a third example of a service status check screen according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] The following description of the embodiments will be given with reference to the drawings. Note that the embodiments described below do not limit the scope of the invention as claimed, and not all of the elements and combinations thereof described in the embodiments are necessarily essential to the solution of the invention.

[0014] In the following explanation, information may be described using the expression "AAA table", but the information may be expressed in any data structure. In other words, to show that the information does not depend on the data structure, the "AAA table" can be called "AAA information".

[0015] In the following description, processing may be described with a "program" as the operating entity. However, since a program is executed by a processor to perform a predetermined process using at least one of a storage device and an interface as appropriate, the processing entity may also be the processor (or a computer or computer system having a processor). A program may be installed on a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable recording medium. In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs. At least a portion of the processing realized by executing a program may be realized by a hardware circuit (for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array)).

[0016] FIG. 1 is a diagram showing the overall configuration of a computer system according to one embodiment.

[0017] The computer system 1 includes a plurality of user terminals 13, a system 11, a plurality of external services 14, and an operation management device 15. These components are connected to each other so as to be able to communicate with each other via a network (not shown), for example.

[0018] The system 11 is configured, for example, with a public cloud server. The system 11 provides a service 12 (provided service) to multiple users. The service 12 includes, for example, multiple microservices 12a. The microservices 12a communicate with other microservices 12a using HTTP (Hyper Text Transfer Protocol) or HTTPS (Hyper Text Transfer Protocol Secure). In the service 12, each user can realize the service they desire by, for example, combining the microservices 12a that each user requires.

[0019] The user terminal 13 is a terminal used by a user, and uses the service 12 provided by the system 11. Some users use the external service 14 by calling an API in the service 12 that uses the external service 14.

[0020] The external service 14 is an example of a called service, which executes a predetermined process in response to a request sent via an API and returns the process result to the service 12. In this embodiment, the external service 14 is provided by a third party different from the provider (management entity) that provides the service 12, and the provider of the service 12 is not able to know the details of the process of the external service 14, but the external service 14 may be a service provided by the provider of the service 12.

[0021] The operation management device 15 executes processing for managing the operation of the service 12 in the system 11 .

[0022] FIG. 2 is a hardware configuration diagram of an operation management apparatus according to an embodiment.

[0023] The operation management device 15 is configured by a computer such as a PC (Personal Computer) or a general-purpose server, and includes a processor 21, a main memory 22, a storage device 23, a communication device 24, an input device 25, and a display device 26. The units 21 to 26 are connected via a bus 27.

[0024] The processor 21 is, for example, a CPU (Central Processor Unit), and by executing a program read from the storage device 23 to the main memory 22, configures various functions that perform various processes necessary for the operation and management of the system 11 (service 12).

[0025] The main memory 22 is, for example, a RAM (RANDOM ACCESS MEMORY), and stores the programs executed by the processor 21 and necessary information.

[0026] The storage device 23 is, for example, a hard disk or a flash memory, and stores programs executed by the processor 21 and data used by the processor 21.

[0027] The communication device 24 is, for example, an interface such as a wired LAN card or a wireless LAN card, and communicates with the user terminal 13, the system 11, the external service 14, etc. via a network.

[0028] The input device 25 is, for example, a mouse, a keyboard, etc., and receives input of information from the operations manager. The input device 25 receives input of information to be set in a table stored in the storage device 23, for example.

[0029] The display device 26 is, for example, a display, and displays and outputs various screens including the results of the processing performed by the processor 21.

[0030] FIG. 3 is a diagram illustrating the configuration of a main memory and a storage device of an operation management apparatus according to an embodiment.

[0031] The main memory 22 stores a microservice identification program 301, an external service identification program 302, a log identification program 303, a log monitoring program 304, a confirmation test program 305, an impact scope estimation program 306, and a service status presentation program 307.

[0032] The microservice identification program 301, when executed by the processor 21, performs processing to identify the microservice 12a that calls the external service 14 from the service 12 that constitutes the system 11. The external service identification program 302, when executed by the processor 21, performs processing to identify the external service 14 that the system 11 calls.

[0033] The log identification program 303 is executed by the processor 21 to identify the log to be monitored by the operation management device 15. The log monitoring program 304 is executed by the processor 21 to perform processing to monitor the usage status of the external service 14 and whether or not a failure has occurred from the log to be monitored.

[0034] The confirmation test program 305 is executed by the processor 21 to perform processing to confirm the reproducibility of a failure of the external service 14. The impact scope estimation program 306 is executed by the processor 21 to perform processing to estimate users affected by the failure based on the failure status of the external service 14. The service status presentation program 307 is executed by the processor 21 to perform processing to present the status of the service 12 provided by the system 11.

[0035] The storage device 23 stores a user table 311, an external service table 312, a microservice table 313, an external service API table 315, an API usage status table 316, a confirmation test table 317, an impact scope estimation table 318, and a test data table 319.

[0036] The user table 311 stores information about users who use the services 12 provided by the system 11. The external service table 312 stores information about the external services 14 used by the system 11. The microservice table 313 stores information about the microservices 12a that call the external services 14 within the microservices 12a that constitute the system 11. The external service API table 315 stores the operation types of the APIs called within the external services 14. The API usage status table 31 stores the latest usage status of the APIs of the external services 14. The confirmation test table 317 stores information about confirmation tests that confirm the reproducibility of failure occurrences. The impact scope estimation table 318 stores information about failures in services provided by the system 11 and users affected by the failures. The test data table 319 stores test data used when calling the external services 14 via APIs. This test data is, for example, data used during the development of the microservice 12a to confirm that the external services 14 are operating normally, and is data (argument combinations, etc.) that was confirmed to be normal, i.e., data that passed the confirmation test.

[0037] Next, the various tables stored in the storage device 23 will be described in detail.

[0038] FIG. 4A is a diagram illustrating an example of a user table according to an embodiment.

[0039] The user table 311 stores a row (entry) for each user. A row of the user table 311 includes fields for a user ID 41, a user name 42, and a sender 43.

[0040] The user ID 41 stores a unique identifier (user ID) assigned to each user. The user name 42 stores the user name of the user corresponding to the row. The sender 43 stores transmission information such as an IP address and a host name that can identify the user terminal 13 when the user corresponding to the row uses the service 12. The various information in the user table 311 can be acquired from a table (not shown) that manages information on users who have signed a service contract for the service 12 provided by the system 11, for example, a table managed by an external device (not shown in FIG. 1).

[0041] FIG. 4B is a diagram illustrating an example of an external service table according to an embodiment.

[0042] The external service table 312 stores a row for each external service. Each row of the external service table 312 includes fields for an external service ID 44, an external service name 45, and a URL 46.

[0043] The external service ID 44 stores a unique identifier (external service ID) assigned to the external service corresponding to the row. The external service ID is, for example, written in a design document created when developing the system 11. The external service name 45 stores the name of the external service corresponding to the row (external service name). The URL 46 stores a URL that is accessed when using the external service corresponding to the row. The external service table 312 is created by the external service identification program 302. The external service identification program 302 obtains the external service ID, service name, and URL for the external service from, for example, a device not shown, and stores them in the external service table 312.

[0044] FIG. 4C is a diagram illustrating an example of a microservice table according to an embodiment.

[0045] The microservice table 313 stores a row for each microservice 12a that constitutes the service 12. The row of the microservice table 313 includes fields for a microservice ID 47, a microservice name 48, and an external service ID 49.

[0046] The microservice ID 47 stores an identifier (microservice ID) that uniquely identifies the microservice 12a corresponding to the row. The microservice name 48 stores the name (microservice name) of the microservice 12a corresponding to the row. The external service ID 49 stores the external service ID of the external service called by the microservice 12a corresponding to the row. If the microservice 12a corresponding to the row calls multiple external services, the external service ID 49 stores a string in which the external service IDs of the multiple external services to be called are separated by commas. If the microservice 12a corresponding to the row does not call an external service, the external service ID 49 stores a value that does not overlap with the external service ID, for example, "-1". The microservice table 313 is created by the microservice identification program 301 acquiring various information about the microservice, for example, from a device not shown in FIG. 1.

[0047] FIG. 5 shows an example of the configuration of the external service API table 315.

[0048] The external service API table 315 stores a row for each external service and API that calls the external service. A row of the external service API table 315 includes fields for an external service ID 53, an API 54, and a type 55.

[0049] The external service ID 53 stores the external service ID of the external service corresponding to the row. The API 54 stores information identifying the function of the API used to call the external service corresponding to the row (e.g., the name of the API). The API 54 stores, for example, "GetVersion," an API for obtaining version information provided by the external service, and "auth," an API for obtaining a dedicated token when authentication of a user using the external service is successful. In the example of FIG. 5, these are simply represented as API1, API2, ..., etc. The type 55 stores the type of operation when the API corresponding to the row calls the external service. For example, if the external service supports a method called a REST (REpresentational State Transfer) API, the type 55 stores "POST," indicating a new creation function, "GET," indicating a reference function, "PUT," indicating an update function, "DELETE," and the like. A method for creating the external service API table 315 will be described later.

[0050] FIG. 6 is a diagram illustrating an example of an API usage status table according to an embodiment.

[0051] The API usage table 316 stores a row for each API usage by a user. This API usage table 316 manages the correspondence between users, external services, and used APIs. A row of the API usage table 316 includes fields for a user ID 61, an external service ID 62, an API 63, a result 64, a latest usage time 65, and a current usage 66.

[0052] The user ID 61 stores an identifier (user ID) that uniquely identifies the user who used the API corresponding to the row. The external service ID 62 stores the external service ID of the external service 14 used by the user with the user ID corresponding to the row. The API 63 stores the function of the API called (used) when the user with the user ID corresponding to the row uses the external service. The result 64 stores the result (return value, status code) when the API corresponding to the row is called. The status code stored in the result 64 is, for example, "200" if normal, a number in the 500s if there is an error on the external service side, and a number in the 400s if there is an error on the API request side. The latest usage time 65 stores the latest time when the external service and API corresponding to the row were used. The currently used 66 stores information indicating whether the user with the user ID corresponding to the row is currently using the external service corresponding to the row. Current use 66 stores "TRUE" if the user is currently using the external service, and stores "FALSE" if the user is not currently using the external service, i.e., is using another external service.

[0053] FIG. 7 is a diagram illustrating an example of a confirmation test table according to an embodiment.

[0054] The confirmation test table 317 stores rows for pairs of external services and APIs that are the subject of confirmation tests. Each row of the confirmation test table 317 includes fields for an external service ID 81, an API 82, a user ID 83, a request time 84, a result 85, and a test time 86.

[0055] The external service ID 81 stores the external service ID of the external service corresponding to the row. The API 82 stores the function of the API corresponding to the row. The user ID 83 stores the user ID of the user who used the external service and API corresponding to the row. The request time 84 stores the time when a confirmation test request was made to the API corresponding to the row. The result 85 stores the result of a failure reproducibility test when a request is made to the external service corresponding to the row via the API. The test time 86 stores the time when the failure reproducibility test was made.

[0056] FIG. 8 is a diagram illustrating an example of an influence range estimation table according to an embodiment.

[0057] The impact scope estimation table 318 stores a row for each failure whose reproducibility has been confirmed. The row of the impact scope estimation table 318 includes fields for an external service ID 1001, an API 1002, a type 1003, a microservice 1004, an in-house error 1005, an affected user 1006, and an estimated impact scope 1007.

[0058] The external service ID 1001 stores the external service ID of the external service involved in the failure corresponding to the row. The API 1002 stores the function of the API involved in the failure corresponding to the row. The type 1003 stores the type of operation when the API called the external service in the failure corresponding to the row. The microservice 1004 stores the microservice ID of the microservice that called the external service involved in the failure corresponding to the row. The internal error 1005 stores information indicating whether the failure corresponding to the row is a failure caused within the service 12. If the failure is caused within the service 12, the internal error 1005 stores "TRUE", and if the failure is not caused within the service 12, the internal error 1005 stores "FALSE". The affected user 1006 stores the user ID of the user affected by the failure corresponding to the row. The estimated impact scope 1007 stores the impact scope estimated to be affected by the failure corresponding to the row, for example, the user ID or a set of user IDs of the users estimated to be affected.

[0059] Next, the processing operation of the operation management device 15 will be described.

[0060] FIG. 9 is a flowchart of a log monitoring process according to an embodiment.

[0061] The log monitoring process is executed periodically, for example. The log monitoring program 304 (strictly speaking, the processor 21 that executes the log monitoring program 304) acquires the difference between the logs identified as the monitoring targets by the log identification program 303, that is, the logs acquired since the last time they were acquired (S701).

[0062] Here, the microservice identification program 301 refers to the microservice table 313 to identify the microservice that is calling the external service, and the log identification program 303 sets the log file output by the identified microservice as the log to be monitored, and provides the log monitoring program 304 with a list of log files of this monitored log or extraction conditions for extracting the log of the identified microservice from an application or service that aggregates and stores the log files. The log monitoring program 304 obtains the difference between logs based on the list of log files or the extraction conditions.

[0063] Next, the log monitoring program 304 reads one line from the acquired log that calls the API of the external service 14 (S702). Here, the line that calls the API of the external service can be determined by the fact that it contains the URL of the external service 14.

[0064] Next, the log monitoring program 304 determines whether all the lines of the log acquired in step S701 have been read (S703), and if all the lines have been read (S703: Yes), ends the process.

[0065] On the other hand, if not all rows have been read (S703: No), that is, if there is a row that calls the API of external service 14, the time, user ID, external service ID, API, operation type, and results of calling the API of the external service are extracted based on that row (S704).

[0066] Here, the user ID can be extracted from a specified row by identifying a row in the log where the sender information calling the API of the external service, included in the row, matches the sender information of the sender 43 in the user table 311. The external service ID can be extracted from a specified row by identifying a row in the external service table 312 where the URL 46 contains a URL that prefix-matches the URL included in the row of the log. The API of the external service can be extracted by removing the URL of the external service from the URL included in the row of the log. Note that the result of calling an external service via an API in this embodiment is, for example, a status code (e.g., 200, 500, etc.) that is the return value when a REST API is called via HTTP.

[0067] Next, the log monitoring program 304 compares the combination of external service ID, external service API, and operation type extracted in step S704 with the combination of external service ID, API, and operation type in a row of the external service API table 315, and if no row with the same combination exists, it inserts a row containing the combination of external service ID, API, and operation type into the external service API table 315 (S705).

[0068] Next, the log monitoring program 304 compares the user ID, external service ID, external service API, and results extracted in step S704 with the contents of the API usage table 316, and performs processing to update the API usage table 316 (S706).

[0069] Specifically, the log monitoring program 304 obtains a microservice ID that matches the external service ID extracted in step S704 from the microservice table 313. Next, the log monitoring program 304 extracts rows in which the user ID and external service ID match from the API usage table 316. Next, the log monitoring program 304 extracts the external service ID corresponding to the microservice ID from the microservice table 313, and leaves the row that includes the extracted external service ID from the extracted rows in the API usage table 316. Next, if the external service ID in the external service ID 62 of the left row differs from the external service ID extracted from the log, the log monitoring program 304 determines that the user has changed the external service they are using, and stores a value indicating that this is a previously used external service in the current usage 66 of the corresponding row in the API usage table 316 (in this example, "FALSE"). On the other hand, if there is a row with the same external service ID and API among the rows extracted from API usage table 316, the result 64 and latest usage time 65 of this row are updated to the information extracted from the row of the log, and if there is no row with the same external service ID and API among the rows extracted from API usage table 316, the user ID extracted from the log is set to user ID 61, the external service ID is set to external service ID 62, the API is set to API 63, the result is set to result 64, the time obtained from the log is set to latest usage time 65, and a value indicating that the external service currently in use (to be changed) is set in current usage 66 (in this example, "TRUE") is set, and a row is inserted into API usage table 316.

[0070] Next, if a new result indicating an abnormality on the external service 14 side (in this example, a value in the 500s) is stored in result 64 in API usage table 316, the log monitoring program 304 adds a new row to confirmation test table 317, sets the values ​​extracted from the log to the external service ID 81, API 82, and user ID 83 of that row, sets the request time 84 to the time at that time (S707), and proceeds to step S702 to read the next row.

[0071] Next, the confirmation test process will be described. The confirmation test process is a process for executing a confirmation test to check whether the occurrence of a failure can be reproduced without relying on the user.

[0072] FIG. 10 is a flowchart of a verification test process according to one embodiment.

[0073] The confirmation test process is executed, for example, periodically (for example, at a cycle shorter than the cycle at which the log monitoring process is executed).

[0074] The confirmation test program 305 (strictly speaking, the processor 21 that executes the confirmation test program 305) extracts one row from the confirmation test table 317 for which the confirmation test for the reproducibility of the occurrence of a failure has not been processed, i.e., one row for which the result 85 is empty (S901), and determines whether or not there is an unprocessed row (S902).If there is no unprocessed row (S902: No), the processing ends.

[0075] On the other hand, if there are unprocessed rows (S902: Yes), the confirmation test program 305 obtains the external service ID of external service ID 81 and the API of API 82 from the extracted row (referred to as the target row in the explanation of this process), and searches the confirmation test table 317 to see if there is a row that has the same external service ID and API and in which a result is stored (S903).

[0076] As a result, if there is a corresponding row (S903: Yes), the confirmation test program 305 determines whether the difference between the test time 86 of the corresponding row and the current time is within a predetermined period (S904).

[0077] As a result, if the difference between the test time 86 of the corresponding row and the current time is within a specified period (S904: Yes), this means that the results of past confirmation tests can be used, so the confirmation test program 305 stores the result of the result 85 of the corresponding row and the time of the test time 86 in the result 85 and test time 86 of the target row, respectively (S905), and proceeds to step S901.

[0078] On the other hand, if there is no corresponding row (S903: No) or the difference between the test time 86 of the corresponding row and the current time is not within the specified period (S904: No), the confirmation test program 305 creates test data for a reproducibility confirmation test to determine whether the fault can be reproduced (S906).

[0079] Here, the URL that is the destination of the test data is created by linking the URL of URL 46 of a row in external service table 312 whose external service ID is the same as the external service ID of the target row with the API of the target row. Furthermore, the operation type when sending the test data is the operation type of row type 55 in external service API table 315 whose external service ID and API match the external service ID and API of the target row. The specific arguments in the test data are the arguments stored in test data table 319.

[0080] Next, the confirmation test program 305 executes a confirmation test to confirm whether the occurrence of the failure can be reproduced by sending test data to the target external service 14 (S907). Next, the confirmation test program 305 stores the test result and test time received from the external service 14 in the result 85 and test time 86 of the target row in the confirmation test table 317 (S908), and proceeds to step S901.

[0081] This confirmation test process makes it possible to appropriately check whether a failure that occurred in a process for a certain user can be reproduced using test data, thereby appropriately checking whether a failure is likely to occur in processes for other users.

[0082] Next, the impact range estimation process will be described. The impact range estimation process is a process for estimating the range of users that may be affected by a failure.

[0083] FIG. 11 is a flowchart of an influence range estimation process according to an embodiment.

[0084] The impact range estimation process is executed when a new test result is set in the confirmation test table 317, for example.

[0085] The impact extent estimation program 306 (strictly speaking, the processor 21 that executes the impact extent estimation program 306) locally copies the impact extent estimation table 318 (S1101). In the explanation of this process, the locally copied impact extent estimation table 318 will be referred to as the local impact extent estimation table 318, and the fields in the rows will be explained using the same reference numerals as the corresponding fields in the impact extent estimation table 318.

[0086] Next, the impact scope estimation program 306 reads one unprocessed row from the confirmation test table 317 (S1102), determines whether or not there is an unprocessed row (S1103), and if there is no unprocessed row (S1103: No), proceeds to step S1110.

[0087] On the other hand, if there are unprocessed rows (S1103: Yes), the impact extent estimation program 306 determines whether the result 85 of the row read in step S1102 (referred to as the read row in the explanation of this process) is an error (S1104). In this embodiment, if the result is in the 500s, indicating a problem on the external service 14 side, it is determined to be an error in the external service 14, if the result is in the 400s, it is determined to be an error inside the system 11, and if the result is anything other than that, it is determined to be no error.

[0088] As a result, if it is determined that the error is on the external service 14 side (S1104: Yes), the impact scope estimation program 306 acquires the user IDs of other users who are using this external service 14 and API. Specifically, the impact scope estimation program 306 acquires, from the API usage status table 316, the user ID of a row in which the external service ID matches the external service ID of the read row, the API matches the API of the read row, and current usage 66 is "TRUE" as the user ID of the other user who is using this external service and API. Next, the impact scope estimation program 306 references the microservice table 313 to identify a microservice ID corresponding to the external service ID of the read row, and references the external service API table 315 to identify an operation type corresponding to the external table ID and API of the read row. Next, the impact scope estimation program 306 identifies, from the local impact scope estimation table 318, a row that includes a combination of the external service ID and API of the read row, the identified microservice ID, and the identified operation type. If a corresponding row does not exist in the local impact scope estimation table 318, the impact scope estimation program 306 creates a new row including a combination of the external service ID and API of the read row, the identified microservice ID, and the identified operation type. Next, the impact scope estimation program 306 stores the acquired user ID of the other user in the estimated impact scope 1007 of the identified row or the newly created row (referred to as the target row in this processing) of the local impact scope estimation table 318. Here, if the user ID of the other user overlaps with a user ID already stored in the affected user 1006 and estimated impact scope 1007, that user ID is not stored. Here, if there are multiple user IDs of the other users, the user IDs are stored, for example, separated by commas. Furthermore, the impact scope estimation program 306 stores "FALSE" in the in-house error 1005 (S1105).

[0089] Furthermore, if it is determined that the error is internal to the system 11 (S1104: Yes), the impact scope estimation program 306 identifies the user IDs of all users who are using this external service 14 and API from the API usage status table 316, then references the microservice table 313 to identify the microservice ID corresponding to the external service ID of the read row, and references the external service API table 315 to identify the operation type corresponding to the external table ID and API of the read row. Next, the impact scope estimation program 306 identifies a row including a combination of the external service ID and API of the read row, the identified microservice ID, and the identified operation type from the local impact scope estimation table 318. Note that if a corresponding row does not exist in the local impact scope estimation table 318, the impact scope estimation program 306 creates a new row including a combination of the external service ID and API of the read row, the identified microservice ID, and the identified operation type. Next, the impact scope estimation program 306 stores the obtained user IDs of other users in the estimated impact scope 1007 of the identified row or the newly created row (this row is also the target row in this processing) of the local impact scope estimation table 318. Next, the impact scope estimation program 306 stores all identified user IDs in the affected users 1006 of the target row of the local impact scope estimation table 318, and stores "TRUE" in the in-house error 1005 (S1105).

[0090] On the other hand, if it is determined that there is no error (S1104: No), the influence extent estimation program 306 advances the process to step S1106.

[0091] In step S1106, the impact scope estimation program 306 determines whether the user ID of the read row exists in the estimated impact scope 1007 of the target row (S1106), and if it exists (S1106: Yes), it deletes this user ID from the estimated impact scope 1007 of the target row in the local impact scope estimation table 318 (S1107), and proceeds to step S1108. On the other hand, if the user ID of the read row does not exist in the estimated impact scope 1008 (S1106: No), the impact scope estimation program 306 proceeds to step S1108.

[0092] In step S1108, the impact scope estimation program 306 adds the user ID of the read row to the affected user 1006 of the target row (S1108). Next, the impact scope estimation program 306 deletes the old row corresponding to the target row from the impact scope estimation table 318 (S1109), and proceeds to step S1102.

[0093] On the other hand, if there are no unprocessed rows in step S1103 (S1103: No), the impact scope estimation program 306 determines that the rows in the local impact scope estimation table 318 are rows where the failure is still ongoing, inserts each row at the end of the impact scope estimation table 318 (step S1110), and terminates the processing.

[0094] This process makes it possible to appropriately estimate and manage the scope (users) of influence that is likely to be affected by the external service ID and API in which the error has occurred.

[0095] Next, a description will be given of the service status confirmation screen displayed by the service status presentation program 307. The service status confirmation screen may be displayed at all times, or may be displayed in response to an instruction from the administrator, for example.

[0096] Fig. 12A is a configuration diagram of a first example of a service status check screen according to an embodiment. The service status check screen in Fig. 12A is a screen that is displayed when there is no abnormality in the system 11, that is, when no rows are stored in the impact extent estimation table 318.

[0097] The service status confirmation screen 1201 includes a service name display area 1202 and a status display area 1203. The service name display area 1202 displays the name of the service 12 to be displayed.

[0098] The status of the service 12 to be displayed, i.e., normal or abnormal, is displayed in the status display area 1203. If there is no abnormality in the system 11, i.e., if no rows are stored in the impact extent estimation table 318, the service status presentation program 307 displays the service name in the service name display area 1202 and displays "normal" in the status display area 1203.

[0099] 12B is a configuration diagram of a second example of a service status check screen according to an embodiment. The service status check screen in FIG. 12B is a screen that is displayed when an abnormality exists within the company, i.e., on the microservice 12a side, with respect to the system 11, that is, when a row is stored in the impact extent estimation table 318 and the internal error 1005 of the row is TRUE.

[0100] The service status confirmation screen 1210 includes a service name display area 1202, a status display area 1203, a microservice name display area 1214, a faulty external service display area 1215, a displayed user type display area 1216, and a details display area 1217.

[0101] The microservice name display area 1214 displays the name of the microservice in which the abnormality was discovered. The faulty external service display area 1215 displays the name of the external service in which the failure occurred. The displayed user type display area 1216 displays the type of user displayed in the details display area 1217. The details display area 1217 displays information about users affected by the failure and / or who are suspected to have experienced a failure.

[0102] If there is an abnormality within the company of system 11, that is, if a row is stored in impact scope estimation table 318 and internal error 1005 of the row is TRUE, service status presentation program 307 displays the service name in service name display area 1202, displays "abnormal" in status display area 1203, displays the name of the microservice where the failure occurred in microservice name display area 1214, displays the name of the external service where the failure occurred in failed external service display area 1215, and since internal error is TRUE, that means there is a failure in the microservice that calls the same external service ID and all users who use this microservice are affected, displays "all users" in displayed user type display area 1216 and displays the user name corresponding to the user ID of affected user 1006 of the row in impact scope estimation table 318 in detail display area 1217.

[0103] This service status confirmation screen 1210 allows the administrator to easily grasp the external service in which the failure occurred and the affected users.

[0104] 12C is a block diagram of a third example of a service status confirmation screen according to an embodiment. The service status confirmation screen in FIG. 12C is an example of a screen that is displayed when there is an abnormality in the API or external service side of the system 11, that is, when a row is stored in the impact extent estimation table 318 and the internal error 1005 is FALSE.

[0105] The service status confirmation screen 1301 includes a service name display area 1202, a status display area 1203, a microservice name display area 1214, a faulty external service display area 1215, a displayed user type display area 1216, a user display area 1307, and an API display area 1308.

[0106] The user names affected by the failure and the names of users in the range estimated to be affected by the failure (estimated impact range) are displayed in the user display area 1307. The API display area 1308 displays APIs used by users affected by the failure or APIs used by users estimated to be affected by the failure.

[0107] Regarding system 11, if there is an abnormality on the API or external service side, that is, if a row is stored in the impact scope estimation table 318 and the in-house error 1005 of the row is FALSE, the service status presentation program 307 displays the service name in the service name display area 1202, displays "abnormal" in the status display area 1203, displays the name of the microservice in which the failure occurred in the microservice name display area 1214, and displays the name of the external service in which the failure occurred in the failed external service display area 1215.

[0108] Furthermore, the service status presentation program 307 displays in the displayed user type display area 1216 a character string ("affected user" in this embodiment) indicating that the affected users are not necessarily all users, and displays in the user display area 1307 a user name corresponding to the user ID of the affected user 1006 in the row of the impact scope estimation table 318 and a user name corresponding to the user ID of the estimated impact scope 1007. Furthermore, the service status presentation program 307 displays in the API display area 1308 the API used by the user whose user name is displayed in the user display area 1307, i.e., the API of the API 1002 in the row. Here, the service status presentation program 307 displays the API 1309 used by the affected user and the API 1310 used by users in the estimated impact scope in a display manner that allows them to be distinguished. Note that the display manner of the APIs in the API display area 1308 may differ depending on the operation type in the API (the operation type of the type 1003 in the row). For example, update operations ("POST" in this embodiment) and delete operations ("DELETE" in this embodiment) depend on the API call history up to that point in the processing of each user who uses the external service, so even if the result of the confirmation test in the operations management device 15 is successful, there is a higher possibility that an abnormality will occur in the processing of another user than with reference operations ("GET" in this embodiment) and creation operations ("POST" in this embodiment). Therefore, APIs that perform update operations and delete operations may be displayed in a more emphasized manner (for example, with a darker display color) than APIs that perform reference operations and creation operations.

[0109] This service status confirmation screen 1301 allows the administrator to easily understand the external service in which the failure occurred, the affected users and the APIs they are using, and the users and the APIs they are using that may be affected.

[0110] The present invention is not limited to the above-described embodiment, and can be modified appropriately without departing from the spirit of the present invention.

[0111] For example, in the above embodiment, the service status presentation program 307 may notify the user having the user ID of the affected user 1006 and / or the user ID of the estimated affected range 1007 in the impact range estimation table 318 that a failure has occurred or that a failure is estimated to occur, for example by sending a notification to the user terminal of this user. [Explanation of symbols]

[0112] 1...computer system, 11...process information management device, 12...service, 12a...microservice, 13...user terminal, 14...external service, 15...operation management device, 21...processor, 22...main memory, 23...storage device

Claims

1. An operation management device that manages the operation of a system that provides a service to a plurality of users, the service requesting processing from one or more call destination services via an API (Application Programming Interface), one or more processors and a storage device; the storage device stores test data for causing the called service to execute processing via the API, the called service used by the user through the provided service, and a correspondence relationship between the called service and the API used by the user; The processor: Detecting whether a failure has occurred on the called service side in the service provided to the predetermined user; When a failure on the called service side is detected, a confirmation test is performed using the test data to confirm whether or not the failure on the called service side can be reproduced via the API that was being used when the failure occurred; If the failure on the called service side is reproduced as a result of the confirmation test, the user who uses the called service and the API that was used is identified. Operation management device.

2. The called service is an external service provided by a third party different from the administrator of the system. The operation management device according to claim 1 .

3. The processor: Detecting that the user has changed the destination service being used by the provided service, and storing the detected changed destination service in the storage device as the destination service being used by the user. The operation management device according to claim 1 .

4. The processor: The specified user is displayed in an identifiable manner. The operation management device according to claim 1 .

5. The processor: Regarding the identified users, affected users who are users in whom the failure occurred on the called service side are displayed in a manner that allows them to be distinguished from other users. The operation management device according to claim 4 .

6. The storage device includes: storing the type of operation to be performed on the called service by the API; The processor: The type of operation by the API that was used is identified, and information that identifies the API that was used is displayed in a display mode corresponding to the identified type of operation in association with the user. The operation management device according to claim 1 .

7. The processor: Information specifying an API whose operation type to the called service is an update operation or a delete operation is displayed more emphatically than information specifying an API whose operation type is a reference operation or a creation operation. The operation management device according to claim 6.

8. The processor: Notifying the identified user of information regarding the occurrence of the failure The operation management device according to claim 1 .

9. The processor: If the confirmation test has been performed within a predetermined period for the call destination service where the failure occurred, the confirmation test is not performed and the result of the confirmation test within the predetermined period is used. The operation management device according to claim 1 .

10. 1. An operation management method using an operation management device that manages the operation of a system that provides a service to a plurality of users, the service requesting processing from one or more call destination services via an API (Application Programming Interface), comprising: The operation management device test data for causing the called service to execute processing via the API, the called service used by the user through the provided service, and a correspondence relationship between the called service and the API used by the user; Detecting whether a failure has occurred on the called service side in the service provided to the predetermined user; When a failure on the called service side is detected, a confirmation test is performed using the test data to confirm whether or not the failure on the called service side can be reproduced via the API that was being used when the failure occurred; If the failure on the called service side is reproduced as a result of the confirmation test, the user who uses the called service and the API that was used is identified. Operation management method.

11. An operation management program to be executed by a computer that manages the operation of a system that provides a service to a plurality of users, the service requesting processing from one or more call destination services via an API (Application Programming Interface), The computer test data for causing the called service to execute processing via the API, the called service used by the user through the provided service, and a correspondence relationship between the called service and the API used by the user; The computer, detecting whether a failure has occurred on the called service side in the service provided to the predetermined user; When a failure on the called service side is detected, a confirmation test is executed using the test data to confirm whether or not the failure on the called service side can be reproduced via the API that was being used when the failure occurred; If the failure on the called service side is reproduced as a result of the confirmation test, the user who uses the called service and the API that was used is identified. Operations Management Program.

Images