JP6926646B2 - Inter-operator batch service management device and inter-operator batch service management method - Google Patents

Description

The present invention relates to an inter-business batch service management device and an inter-business batch service management method that enable a linked service that combines services provided by a partner business operator.

Currently, wholesale service providers that provide various services such as network services, computer infrastructure services, and application services are emerging. Along with this, some service providers that provide services to end users do not own their own assets, but provide unique services by combining services provided by wholesale service providers (partner providers). Is also appearing. Network services are services such as wide area Ethernet service (Ethernet is a registered trademark), IP-VPN (Internet Protocol Virtual Private Network) service, and mobile communication provided by MVNO (Mobile Virtual Network Operator). The computer infrastructure service is a service that can be used by a virtual computer called Infrastructure as a Service (IAAS). The application service is a service that can be used by various applications such as mail, net storage, and a Web server. In addition, gateway services such as firewalls and storage services such as database servers are provided.

A website rental service is an example of a collaborative service that combines services provided by a partner company. The website rental service provider links the computer infrastructure service on which the web server operates, the database server service used by the web server, and the firewall service that protects the web server from network attacks to end users. Provide linked services.

Each partner company provides services via API (Application Programming Interface). For example, a service provider that provides a rental service for the above website calls an API and starts the service according to the following procedure. (1) The service provider specifies the specifications of the CPU (Central Processing Unit), the memory size, etc., calls the API for starting the virtual computer, and starts the Web server. (2) The service provider starts the firewall or database server by calling the API. (3) The service provider calls an API set to connect with a network so that the Web server, the firewall, and the database server can communicate with each other. (4) The service provider calls the API of the setting for connecting the firewall and the Internet. In this way, the service that is a component of the rental service of the Web server is called, and then the service of the component is set to cooperate, so that the cooperation service is generated (started) and provided to the end user. Will be done.

An example of another linked service is a cloud environment rental service. As a specific example, there is a file sharing service, and a case where a company uses it will be described as an example. This service includes a net storage service that provides the file sharing service itself, an IP-VPN service that connects the net storage to the corporate network of the user, and a firewall service that protects the net storage from network attacks. Included as a component. The service provider calls and starts the service of the net storage and the firewall using the API, and then the API that connects the net storage and the IP-VPN, the API that connects the net storage and the firewall, and the firewall. Call the API that connects to the Internet. Similar to the website rental service, the component services are called, set to cooperate, and provided to the end user as one service.

On the other hand, the business operator that provides the cooperative service (cooperative service provider) as well as the partner business operator also complies with the performance and quality described in the SLA (Service Level Agreement) included in the service contract. You need to monitor that. In addition, the linked service provider needs to detect a failure (failure) of the linked service and identify the range of influence (failure range) of the failure. Further, when a failure of the cooperation service is detected, the cooperation service provider needs to perform primary isolation to identify which service of the component has the failure.

Regarding monitoring of the operating status of the linked service, there is a technique described in Non-Patent Document 1. By using this technology, it is possible to generate a new monitoring section (monitoring area) by combining the service monitoring items of each component constituting the cooperation service.

Aiko Oi, Hiroyuki Onishi, Hideaki Kimura, "Automatic linking of monitoring items and monitoring sections," 2016 IEICE Communication Society Conference, B-14-11.

By using the technique of Non-Patent Document 1, it is possible to grasp the relevance between the monitoring items of the service, which is a component, and the monitoring target associated with the relevance. However, Non-Patent Document 1 does not describe the primary isolation of a failure, the identification of the range of influence of the failure, and the narrowing down of the failure location when a failure occurs in the linked service. For this reason, when a failure occurs in the linked service, failure analysis (failure judgment) such as primary isolation of the failure, identification of the range of influence of the failure, and narrowing down of the failure location cannot be performed, and the response to the failure is delayed. There is a problem. As a result, there arises a problem that the quality and reliability of the linked service deteriorate.

The present invention has been made in view of such a background, and it is an object of the present invention to provide an inter-business batch service management device and an inter-business batch service management method that monitor linked services and enable failure analysis. And.

To solve the problems described above, a first aspect of the present invention, structure and service provided by a server, a plurality of the services configured as elements by linking service, a service which has a plurality of said linkage It is an inter-operator collective service management device that provides the linked service by connecting the linked service that is included as an element service and linked , and the computer of the service provider that uses the linked service and the server via a network. A storage unit that stores a usage status database in which information associated with the cooperation service and a plurality of the component services constituting the cooperation service is stored, and the component service or the component associated with the cooperation service. According to the service level compliance determination rule indicating the rule for determining whether the service or the cooperation service complies with or violates the predetermined service level, each of the component service and the cooperation service has the predetermined service level. The component service is extracted from the cooperation service by referring to the service level compliance determination unit that executes the service level compliance determination of whether the service is in compliance with or in violation of the above and the usage status database, and the extracted service is described. If the component service is the linked service, the component service is further extracted, and the service level compliance determination unit is instructed in order from the extracted lower component service to determine the service level compliance. The service management device is a collective service management device between business operators, which is characterized by having a service status management unit that executes a service status determination that determines the operating status of the linked service.

Further, the invention according to claim 8, a service provided by a server, a service that links with the structure elements of the plurality of the services, including the service that has a plurality of the collaboration as a component service linkage It is a method of managing the inter-operator batch service of the inter-operator batch service management device that provides the linked service by connecting the linked service, the computer of the service provider that uses the linked service, and the server together via a network. The inter-operator collective service management device includes a usage status database in which information relating the cooperation service and a plurality of the component services constituting the cooperation service is stored, and the component service or the component service or The component service and the cooperation service are associated with the cooperation service and according to a service level compliance determination rule indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. Each of the above-mentioned configuration from the said cooperation service with reference to the service level compliance determination step for executing the service level compliance determination as to whether or not the predetermined service level is being observed or violated, and the usage status database. The element service is extracted, and if the extracted component service is the cooperation service, the component service is further extracted, and the service level compliance determination step is executed in order from the extracted lower component service. Then, the service status management step for executing the service status determination for determining the operating status of the linked service is executed, and the service management method is a batch service between business operators.

With the above configuration, the inter-operator batch service management device determines whether the service complies with the service level according to the service level agreement judgment rule (SLA judgment rule) from the subordinate component service of the linked service. The judgment (SLA judgment) is executed. By determining the SLA from the lower component services, the inter-operator batch service management device can identify which component service that constitutes the linked service has a failure, and the primary isolation of the failure of the linked service can be performed. It will be possible.

The invention according to claim 2 follows the service level compliance determination rule associated with the component service when the service level compliance determination unit executes the service level compliance determination for the component service. The inter-operator collective service management according to claim 1, wherein the service level compliance determination is executed with reference to the performance information of the component service acquired from the server that provides the component service. It was a device.

With the above configuration, the inter-operator batch service management device collects the performance information of the component service from the server that provides the component service and executes the SLA determination of the component service. By doing so, it is not necessary to develop a function to acquire performance information for each component service, and it is possible to execute SLA judgment using the function of the existing component service, which is a collective service management device between operators. Will be able to provide linked services using new component services at lower cost and in a shorter period of time than when developing a function to acquire performance information.

The invention according to claim 3 is described in accordance with the service level compliance determination rule associated with the cooperation service when the service level compliance determination unit executes the service level compliance determination for the cooperation service. The batch between business operators according to claim 1, wherein the service level compliance determination is executed with reference to the performance information of the component service acquired from the server that provides the component service of the linked service. It was used as a service management device.

With the above configuration, the inter-operator batch service management device collects the performance information of the component service from the server that provides the component service and executes the SLA determination of the cooperation service. By doing so, the inter-operator collective service management device can execute the SLA judgment for the linked service by combining the performance information of the component services, and can execute the SLA judgment according to the characteristics of the linked service. Become.

The invention according to claim 4 is described in accordance with the service level compliance determination rule associated with the cooperation service when the service level compliance determination unit executes the service level compliance determination for the cooperation service. The inter-operator collective service management device according to claim 1, wherein the service level compliance determination for the linked service is executed using the result of the service level compliance determination for the component service.

With the above configuration, the inter-operator batch service management device executes the SLA determination for the linked service based on the SLA determination result of the component service. By doing so, the inter-company batch service management device can execute the SLA judgment of the linked service by combining the SLA judgment of the component service, and can easily develop the SLA judgment rule of the linked service. ..

In the invention according to claim 5, the server that provides the service and the computer of the service provider that uses the linked service in which the plurality of the services are linked as component services are both connected via a network, and the linked. A storage unit that is a collective service management device between business operators that provides services, and stores a usage status database that stores information relating the cooperation service and a plurality of the component services constituting the cooperation service. According to a service level compliance determination rule associated with the component service or the cooperation service and indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. With reference to the service level compliance determination unit that executes the service level compliance determination as to whether each of the service and the linked service complies with or violates the predetermined service level, and the usage status database, the said The component service is extracted from the cooperation service, and if the extracted component service is the cooperation service, the component service is further extracted repeatedly, and the service level is in order from the extracted lower component service. It is provided with a service status management unit that instructs the compliance determination unit to determine the service level compliance and executes the service status determination to determine the operating status of the linked service, and the information in the usage status database is the type of the linked service. And the information including the type of the component service and the state including any one of normal, failure, and suspected failure as the state of the cooperation service, from the server that provides the component service. When a failure notification of the component service is received, the usage status database is referred to, and the component service of the same type as the component service for which the failure notification is notified is set as the component service. Regarding the linked service, the status of the usage status database corresponding to the linked service is regarded as a failure suspicion, and the service status determination for the linked service is instructed to the service status management unit to the linked service or its component service. When the service level compliance determination is violated, the status of the usage status database corresponding to the linked service is changed from failure suspected to failed, and the linked service and its component service are changed. When a compliance with the service level adherence determination for the bulk between the usage the state that you, further comprising a scenario management unit which changes normally from suspected fault the supplier database corresponding to the cooperative service It was used as a service management device.

With the above configuration, the inter-operator batch service management device receives a failure notification from the server that provides the component service, and determines the SLA of the service of the same type as this service or the linked service whose component service is the same type of service. To execute. By doing so, the inter-operator collective service management device can detect the failure of the service of the same type as the service notified of the failure, and the component service and the component service even if there is no notification of the failure of the same type but different service. It is possible to detect a failure of a linked service whose component service is a component service.

In the invention according to claim 6, the server that provides the service and the computer of the service provider that uses the linked service in which the plurality of said services are linked as component services are both connected via a network, and the linked. A storage unit that is a collective service management device between business operators that provides services, and stores a usage status database that stores information relating the cooperation service and a plurality of the component services constituting the cooperation service. According to a service level compliance determination rule associated with the component service or the cooperation service and indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. With reference to the service level compliance determination unit that executes the service level compliance determination as to whether each of the service and the linked service complies with or violates the predetermined service level, and the usage status database, the said The component service is extracted from the cooperation service, and if the extracted component service is the cooperation service, the component service is further extracted repeatedly, and the service level is in order from the extracted lower component service. It is provided with a service status management unit that instructs the compliance determination unit to determine the service level compliance and executes the service status determination to determine the operating status of the linked service, and the information in the usage status database is the type of the linked service. And the information including the state including any one of normal, failure, and suspected failure as the state of the cooperation service, and when the computer of the service provider notifies the failure of the cooperation service. In addition, with reference to the usage status database, regarding the cooperation service of the same type as the cooperation service for which the failure notification was given, the state of the usage status database corresponding to the cooperation service is regarded as a failure suspicion. When the service status determination for the linked service is instructed to the service status management unit and the service level compliance determination for the linked service or its component service violates, the usage status database corresponding to the linked service is used. When the state is changed from suspected failure to failure and the service level compliance determination for the linked service and its component service is met, the usage status corresponding to the linked service is met. And a database of the inter skill that you characterized in that state from suspected fault further comprising a scenario management unit to change properly collectively service management device.

With the above configuration, the inter-operator batch service management device receives a failure notification from the service provider who is a user of the linked service, and executes an SLA determination for the same type of service. By doing so, the inter-operator collective service management device can detect the failure of the service of the same type as the service for which the failure was notified, and the notification from the service provider different from the service provider that notified the failure can be sent. It is possible to detect a failure of the linked service without it.

In the invention according to claim 7, the information in the usage status database is information that further associates the service provider of the linked service, and the scenario management unit has a failure in the state for each service provider. The cooperation service is counted, the cooperation service whose state is suspected of failure is counted for each service provider, the cooperation service whose state is failure is counted for each type of cooperation service, and the cooperation is said. The inter-operator collective service management device according to claim 5 or 6, characterized in that any of the counting of linked services whose state is suspected to be a failure is executed for each type of service.

With the above configuration, the inter-operator collective service management device counts failed services, suspected failures, failed services for each service provider, and suspected failures for each service provider. By doing so, the inter-business batch service management device can provide the administrator of the inter-business batch service management device in an easy-to-understand manner in the operating status of the linked service.

According to the present invention, it is possible to provide an inter-business batch service management device and an inter-business batch service management method that can monitor a linked service and enable failure analysis.

It is a figure which shows the whole structure of the cooperation service system including the inter-operator collective service management device which concerns on this embodiment. It is a figure for demonstrating the definition and generation of the cooperation service provided by the inter-operator collective service management apparatus which concerns on this Embodiment. It is a figure for demonstrating the failure analysis by SLA determination of the cooperation service provided by the inter-operator collective service management apparatus which concerns on this embodiment. It is a functional block diagram which shows the configuration example of the inter-operator collective service management apparatus which concerns on this embodiment. It is a figure which shows the data structure example of the usage state DB (DataBase) which concerns on this embodiment. It is a figure which shows the data structure example of the performance information DB which concerns on this embodiment. It is a figure which shows the data structure example of the product resource DB which concerns on this embodiment. It is a figure which shows the data structure example of the performance management item DB which concerns on this embodiment. FIG. 5 is a sequence diagram showing an SLA determination process triggered by periodic monitoring, which is executed by the inter-operator batch service management device according to the present embodiment. It is a figure for demonstrating the SLA determination process which is executed by the inter-operator collective service management apparatus which concerns on this Embodiment, which is triggered by the receipt of a trouble ticket from a service provider. It is a figure for demonstrating the SLA determination process which is executed by the inter-operator collective service management apparatus which concerns on this Embodiment, which is triggered by the SLA violation notification from a partner business operator.

≪Overall composition≫
Hereinafter, embodiments of the present invention will be described with reference to the drawings. Before explaining the configuration and processing contents of the inter-business batch service management device of the present invention, the outline of the cooperation service provided by the inter-business batch service management device and the failure analysis (fault determination) of the cooperation service will be described.

FIG. 1 is a diagram showing an overall configuration of a cooperative service system 101 including an inter-operator batch service management device 100 according to the present embodiment. The linked service system 101 includes an application server 220 that is owned by a partner carrier and provides a component service, in addition to the inter-operator batch service management device 100 and the computer 211 of the service provider 210 that uses the linked service. , The computer base server 230 and the network server 240 are included.

The inter-operator batch service management device 100 and the computer 211 of the service provider 210 are connected by a network 291. The application server 220, the computer base server 230, and the network server 240 are connected to the inter-operator collective service management device 100 via the network 292. Further, the application server 220 and the computer base server 230 are connected via the network 293, the computer base server 230 and the network server 240 are connected via the network 294, and the application server 220 and the network server 240 are connected via a network (non-network). Connected via (shown). The network described above may be one network, and this one network includes the inter-operator collective service management device 100, the computer 211 of the service provider 210, the application server 220, the computer infrastructure server 230, and the like. Network servers 240 may be connected to each other.

The inter-operator collective service management device 100 links the services provided by the application server 220, the computer infrastructure server 230, and the network server 240 to generate one service (cooperation service), and provides this cooperation service as a service business. Provide to person 210. Hereinafter, the computer 211 is equated with the service provider 210, and is also simply referred to as the service provider 210.

≪Definition of linked services and service generation≫
FIG. 2 is a diagram for explaining the definition and generation of the cooperation service provided by the inter-operator collective service management device 100 according to the present embodiment. The process of defining and generating (starting) the linked service will be described with reference to steps S111 to S115 described in FIG. In the following, the linked service and the service that is a component thereof are also simply referred to as a service. In addition, the defined cooperation service is also referred to as a service product.

(1) Definition of service product: In step S111, the cooperation service provided by the inter-operator collective service management device 100 is defined as the service product 179. The service product 179 is defined by the service provider 210 who uses the service or the administrator of the inter-operator collective service management device 100. When the service product 179 is defined, in addition to the name, a service that is a component (component service) and a setting method necessary for linking the component services are defined. Examples of settings required for cooperation include network connection between servers that provide component services and database schema. The component service is not limited to the service provided by the server of the partner company (reference numerals 220, 230, 240 in FIG. 1), and may be a service product 179 defined separately. The product name of the service product # 4 shown in FIG. 2 is defined as "website rental service", and the constituent products that are the constituent services thereof are "service product # 12", "service product # 3", and "service product # 3". Service product # 8 ".

(2) Request for linked service: In step S112, the service provider 210 designates the defined service product # 4 in the inter-operator batch service management device 100, and requests the linked service as an instance thereof.
(3) Generation of component service: In step S113, the inter-operator collective service management device 100 that has received the request for the linked service generates an API to generate (start) each of the component services of the requested service product. Invoke to start the component service. If the component service is a service provided by a partner operator, the API of the server (reference numerals 220, 230, 240 in FIG. 1) is called via the network. If the component service is a linked service that includes another component service, the steps after step S112 that request the linked service are recursively executed. When the service product # 4 shown in FIG. 2 is requested, the service # 12 of the service product # 12, the service # 3 of the service product # 3, and the service # 8 of the service product # 8 are requested as the component services. And are generated.

(4) Coordination of component services: In step S114, the inter-company batch service management device 100 links the component services generated in step S113. The contents of the cooperation include connecting the servers that provide the component services via a network and defining the database schema. Service # 12, service # 3, and service # 8 shown in FIG. 2 are linked to generate (start) service # 4 of service product # 4.

(5) Provision of Linked Service: In step S115, the inter-operator batch service management device 100 provides service # 4, which is the linked service generated in step S114, to the requesting service provider 210.
By the above processing, the service provider 210 can use the cooperation service including the plurality of component services. After the service product is defined in step S111, the service provider 210 determines what kind of component service the linked service is composed of, and which partner company (server (reference numeral 220 in FIG. 1)) is the component service. , 230, 240)), you can request and use the linked service without being aware of whether it is provided.

≪Failure judgment of cooperation service≫
FIG. 3 is a diagram for explaining failure analysis by SLA determination (service level agreement determination) of the cooperative service provided by the inter-operator collective service management device 100 according to the present embodiment. The failure analysis process for the linked service will be described with reference to FIG.
The inter-company batch service management device 100 includes a monitoring scenario unit 121, a service status management unit 131, a performance management unit 133, a performance information DB 160, an SLA management unit 132, and a product resource DB 170, which will be described later (described later). See FIG. 4). Hereinafter, the outline of the failure analysis process of the linked service will be described along with steps S121 to S129.

(1) Instruction to execute SLA determination: In step S121, the monitoring scenario unit 121 instructs the service status management unit 131 to execute the SLA determination by designating a service at a predetermined timing, for example, periodically. ..
(2) Extraction of component service: In step S122, the service status management unit 131 decomposes the designated service and extracts the component service. The service 271 shown in FIG. 3 is the service of the service product # 4, and is decomposed into three component services of the service 272 of the service product # 12, the service 273 of the service product # 3, and the service 274 of the service product # 8. , Is extracted. A service identifier (service ID) is assigned to each service (271 to 274). For example, the service identifier of service 271 is SV43823.

(3) Performance information collection instruction: In step S123, the service status management unit 131 instructs the performance management unit 133 to collect the performance information of the service (271 to 274).
(4) Collection of performance information: In step S124, the performance management unit 133 collects the performance information of the designated service and stores it in the performance information DB 160 (see FIG. 6 described later).
(5) Instructing SLA determination: In step S125, the service status management unit 131 instructs the SLA management unit 132 to determine the SLA. When instructing, the service status management unit 131 instructs the SLA determination in order from the lowest service among the services that are the component elements. Here, since there are services (272 to 274) in the lower services of the service 271 and there are no services lower than these services, the service status management unit 131 can be selected from any of the services (272 to 274). Instruct SLA judgment. Further, for example, when the service 273 has a lower-level service, the service status management unit 131 instructs the SLA determination from the lower-level service.

(6) Acquisition of SLA Judgment Rule: In step S126, the SLA management unit (service level compliance judgment unit) 132 sets the SLA judgment rule (service level compliance judgment rule) required for SLA judgment of the specified service into the product resource DB 170. (See FIG. 7 described later).
(7) Acquisition of performance information: In step S127, the SLA management unit 132 acquires the performance information of the performance management items included in the SLA determination rule acquired in step S126 and referred to at the time of SLA determination from the performance information DB 160.
(8) SLA determination: In step S128, the SLA management unit 132 refers to the performance information acquired in step S127, and violates whether or not the specified service complies with the SLA according to the SLA determination rule acquired in step S126. Determine if it is.

(9) Result notification: In step S129, the SLA management unit 132 notifies the monitoring scenario unit 121 of the result of the SLA determination determined in step S128.
Based on the above SLA determination, the inter-operator collective service management device 100 can identify a service that does not comply with the SLA, and is a failed (failed) linked service or a linked service. It is possible to identify the defective component service inside. Further, when the service is out of order, the inter-operator collective service management device 100 can specify the cooperation service having the service as a component, and can specify the range of influence (affected range) of the failure. can. Further, the inter-operator collective service management device 100 includes a service within the fault range, a server that provides the service (reference numerals 220, 230, 240 in FIG. 1), and a network device (not shown) in the communication path with the server. It is possible to grasp the equipment and the number of suspected failures. In this way, the inter-operator batch service management device 100 can execute failure analysis (fault determination). In this way, the collaborative service provider can identify the faulty part (failed service or failed equipment), recover the service in a shorter time than before, and improve the quality and reliability of the collaborative service. Can be done.
Hereinafter, the configuration and processing contents of the inter-company batch service management device 100 will be described.

≪Configuration of integrated service management device between business operators≫
FIG. 4 is a functional block diagram showing a configuration example of the inter-operator batch service management device 100 according to the present embodiment. The inter-company batch service management device 100 includes an input / output unit 191, a storage unit 192, and a control unit 193.
The input / output unit 191 is composed of a NIC (Network Interface Card) and others, and is connected to the computer 211 (see FIG. 1) of the service provider 210, the application server 220 owned by the partner operator, the computer infrastructure server 230, and the network server 240. Send and receive communication data.

The storage unit 192 is composed of an HDD (Hard Disk Drive), an SSD (Solid State Drive), a RAM (Random Access Memory), and the like, and is necessary for a program and processing for realizing the functions of the inter-operator collective service management device 100. Store temporary data. The storage unit 192 stores the usage status DB 150, the performance information DB 160, the product resource DB 170, and the performance management item DB 180, which will be described later.

The control unit 193 is composed of a CPU, and executes a program stored in the storage unit 192 to make the inter-operator batch service management device 100 function. The control unit 193 includes a business API unit 110, which will be described later, a scenario management unit 120, a business resource management unit 130, and a partner company API adapter unit 140.

The business API unit 110 receives service requests from the service provider 210 and related systems (not shown) via the API. As a main service request, there is a service request (service order execution request) by designating a service product from the service provider 210 (see step S112 in FIG. 2). In addition, there are a service request for defining a service product (see step S111 in FIG. 2), a service request for a trouble ticket for notifying a service failure, and the like. The API that accepts the trouble ticket service request is the trouble ticket corresponding API 112 (not shown in FIG. 4, see FIG. 10 described later).

The scenario management unit 120 manages the execution of the business scenario according to the service received by the business API unit 110. As shown in FIG. 2, the scenario management unit 120 includes a monitoring scenario unit 121 that executes SLA determination at a predetermined timing, a trouble ticket handling scenario unit 122 that processes a trouble ticket issued when a failure is detected, and FIG. It is provided with a batch construction scenario unit 123 that generates (starts) a service by designating a service product.
The monitoring scenario unit 121 accesses the usage status DB 150 (see FIG. 5 described later), selects a service to be SLA-determined, specifies the service identifier (also referred to as a service identifier or service ID), and makes an SLA determination. Is instructed to the service status management unit 131, which will be described later.

FIG. 5 is a diagram showing a data configuration example of the usage status DB 150 according to the present embodiment. The usage status DB 150 is, for example, tabular data, and one record (row) contains information about the service being executed. The record of the usage status DB 150 includes the service ID 151, the product ID 152, the parent service ID 153, the user ID 154, the configuration service ID 155, the start date and time 156, and the attributes (columns) of the state 157.

The service ID 151 is an identifier (service identifier) of the service.
The product ID 152 is an identifier of the service product specified when the service provider 210 requests the service, and indicates what kind of service (service type, service type) the service is. The product ID 152 is the same as the product ID 171 of the product resource DB 170 (see FIG. 7 described later).

The parent service ID 153 is a parent (upper level service) when the service is a component service of the cooperation service, and is a service identifier of the cooperation service having the service as a component. If the service is a linked service that the service provider 210 directly requested to generate (start) and the parent service does not exist, the parent service ID 153 becomes an invalid value (described as "-" in FIG. 5). ..

The user ID 154 is an identifier of the service provider 210 using the service.
The configuration service ID 155 is a service identifier of the component service of the service. If the service is a service provided by a partner company, the component service does not exist, and the component service ID 155 is an invalid value (described as "-" in FIG. 5). When the service is a linked service, the configuration service ID 155 includes a service identifier for one or more component services.

Record 276 indicates a service with a service identifier of SV47583 and includes a service with a service identifier of SV41532 as a component service. In record 277, the service identifier indicates the service of SV41532, and the service of record 276 is the parent service. That is, the service of record 276 and the service of record 277 have a hierarchical (parent-child) relationship, the service of record 276 is the service of the upper level (parent), and the service of record 277 is the service of the lower level (child). .. In addition, service product # 37 includes service product # 32 as a component service.
The start date and time 156 is the date and time when the service started. The service start date and time of Record 276 is 3:24:53 on March 20, 2017.

State 157 indicates the state of the service. The statuses are "normal" that is operating normally, "failure" that is failing, "sub-failure" that is a component service failure, and "sub-failure" that the same type of service (same service product) is failing or sub-failing. There is a "suspicion". If the linked service has two component services, one is "normal" and the other is "failed", the linked service is "subordinate failure". Even if all component services are "normal", the parent linked service itself may be "failed".

When a failed service is detected, it is determined that another service with the same service product (of the same type) may also be failed, and the state 157 becomes "suspected". For a service that has become "suspected", an SLA determination is executed for failure analysis, and depending on the result, it is either "normal", "failure", or "subordinate failure". The SLA determination for failure analysis will be described later in step S136 of FIG. 10 and step S146 of FIG.

Returning to FIG. 4, the monitoring scenario unit 121 executes the SLA determination at a predetermined timing, for example, periodically (at intervals according to the service product). For example, assume that the SLA determination interval of service product # 37 is 15 minutes. In this case, the monitoring scenario unit 121 searches the usage status DB 150 for a record in which the product ID 152 is the service product # 37 every 15 minutes, specifies the service ID 151 included in the search result record, and makes an SLA determination. Instruct the service status management unit 131. The outline of the SLA determination process is as described with reference to FIG. 3, and the details will be described later with reference to FIG.

The trouble ticket handling scenario unit 122 is issued by the trouble ticket management unit 134, which will be described later, and instructs the service status management unit 131, which will be described later, to determine the SLA of the service for the trouble ticket including the service failure information, and analyzes the trouble. I do. The outline of the SLA determination process is almost the same as the SLA determination instructed by the monitoring scenario unit 121, and the details will be described later with reference to FIGS. 10 and 11.
As described with reference to FIG. 2, the batch construction scenario unit 123 generates the component service of the service product requested (step S112) from the service provider 210 (step S113) and links them (step S114). The requested cooperation service is started, and a series of processes to be provided to the service provider 210 (step S115) are executed.

The business resource management unit 130 has a function to be called from a business scenario provided in the scenario management unit 120 and a service request received by the business API unit 110, and includes a service status management unit 131, an SLA management unit 132, and a performance management unit 133. , The trouble ticket management unit 134 is included.

The service status management unit 131 executes the SLA determination of the service instructed by the monitoring scenario unit 121 and the trouble ticket handling scenario unit 122. Specifically, the service status management unit 131 disassembles the specified service, extracts the component services, and instructs the performance management unit 133, which will be described later, to collect performance information between each component service and the designated service. .. Subsequently, the service status management unit 131 receives a notification of the completion of collection from the performance management unit 133, and instructs the SLA management unit 132, which will be described later, to make an SLA determination in order from the lower service. The performance information is stored in the performance information DB 160 (see FIG. 6 described later) by the performance management unit 133.

The service status management unit 131 refers to the usage status DB 150 when decomposing the instructed cooperation service into component services. Specifically, the service status management unit 131 searches for a record having the service identifier specified by the monitoring scenario unit 121 and the trouble ticket response scenario unit 122 in the service ID 151, and refers to the configuration service ID 155 of the search result record. Get the component service and extract the component service. The service status management unit 131 specifies the service identifier of each extracted component service and instructs the performance management unit 133 to collect the performance information.

FIG. 6 is a diagram showing a data configuration example of the performance information DB 160 according to the present embodiment. The performance information DB 160 is, for example, tabular data, and one record (row) contains information related to performance information related to the service being executed. The record of the performance information DB 160 includes the service ID 161 and the product ID 162, the collection date and time 163, and the attributes (columns) of the collection data 164. The performance information is not limited to information indicating the performance itself such as the response time of the service, but is information including information related to quality or reliability such as the frequency of occurrence of errors and the down time of the service, and is necessary for SLA judgment. It is the information that becomes.

The service ID 161 is an identifier of the service, and is the same as the service ID 151 of the usage status DB 150.
The product ID 162 indicates the service type of the service, and is the same as the product ID 152 of the usage status DB 150.

The collection date and time 163 is the date and time when the performance information was collected. The collection date and time 163 of the record shown in FIG. 6 is 13:43:23 on March 30, 2017.
The collected data 164 is the collected performance information. The collected data 164 is not a single data, but includes a measurement period of performance information and numerical values of various performances. For example, in the case of the computer platform server 230 (see FIG. 1), the collected data 164 is the measurement period of the performance information of the virtual computer, the average CPU utilization rate of the measurement period, the number of bytes of data received during the measurement period, and the measurement period. Includes data such as the number of bytes of data written to the virtual volume and the number of write errors that occurred during the measurement period.

Returning to FIG. 4, the SLA management unit (service level compliance determination unit) 132 executes the SLA determination of the service instructed by the service status management unit 131. The SLA management unit 132 acquires the SLA determination rule from the product resource DB 170 (see FIG. 7 described later), acquires the performance information (collected data 164) from the performance information DB 160, and executes the SLA determination.

FIG. 7 is a diagram showing a data configuration example of the product resource DB 170 according to the present embodiment. The product resource DB 170 includes a plurality of records 278 indicating service products 179 (see FIG. 2). The record 278 of the product resource DB 170 includes the attributes of the product name 172, the product description 173, the constituent product 174, the contract 175, the SLA determination rule 176, and the adapter ID 177 in association with the product ID 171.

The product ID 171 is an identifier of the service product, and is the same as the product ID 152 of the usage status DB 150 and the product ID 162 of the performance information DB 160.
The product name 172 is the name of the service product. In the service product 179 (see FIG. 2), the product name 172 of the service product whose product ID 171 is the service product # 4 is "Web site rental service".
Product description 173 is a description of the service product.

The constituent product 174 is a service product that is a constituent element of the service product. In the service product 179 (see FIG. 2), the constituent product 174 of the service product whose product ID 171 is the service product # 4 is the service product # 12, the service product # 3, and the service product # 8.
The contract 175 is the content of the contract with the service provider 210 when using the service product, and includes the SLA.

The SLA determination rule (service level compliance determination rule) 176 is a rule for determining whether or not the SLA of the service product is satisfied. The SLA determination rule 176 refers to the data of the performance management items included in the collected data 164 of the performance information DB 160, and determines whether or not the SLA is being observed. The SLA determination rule 176 does not always refer to the data of a single performance management item, but may determine the SLA by referring to the data of a plurality of performance management items. As an example of the SLA determination rule, there is a rule that accumulates the number of write error occurrences at 15-minute intervals for one hour and determines whether the number of occurrences is less than or equal to a predetermined number. If it is a service provided by the network server 240 (see FIG. 1), there is an SLA determination rule 176 such as a communication delay occurrence rate, and if it is a firewall service (not shown), there is a communication throughput.

The adapter ID 177 is an identifier of an individual adapter 141 included in the partner company API adapter unit 140 (see FIG. 4) that serves as an interface to which the service is provided when the service product is a service provided by the partner company. .. The partner company API adapter unit 140 will be described later.

Returning to FIG. 4, when the service status management unit 131 instructs the SLA management unit 132 to perform the SLA determination, the SLA management unit 132 is instructed with the identifier of the service to be determined. The SLA management unit 132 obtains the product ID 152 from the record having the same service ID 151 as the service identifier by referring to the usage status DB 150, and further refers to the product resource DB 170 to obtain the SLA from the record having the same product ID 171 as the product ID 152. Acquire the determination rule 176. Subsequently, the SLA management unit 132 acquires the data of the performance management items included in the SLA determination rule 176 from the collected data 164 of the performance information DB 160, executes the SLA determination according to the SLA determination rule 176, and monitors the result in the monitoring scenario unit. Notify 121.

The performance management unit 133 collects the performance information of the service instructed by the service status management unit 131 and stores it in the performance information DB 160. When the service to be collected is a service provided by the partner company, the performance management unit 133 collects the performance information via the adapter 141 included in the partner company API adapter unit 140, which will be described later. The performance management unit 133 acquires the product ID 152 of the service from the usage status DB 150 (see FIG. 5), searches for the performance management item DB 180 (see FIG. 8 described later), and searches for the adapter 141 to be called and the performance management items to be collected. decide.

FIG. 8 is a diagram showing a data configuration example of the performance management item DB 180 according to the present embodiment. The performance management item DB 180 is, for example, tabular data, and one record (row) contains information regarding the performance management item of the service. The performance management items of the services (servers (reference numerals 220, 230, 240 in FIG. 1)) provided by the partner business operator are provided by the server, and the performance information of the performance management items is acquired via the adapter 141. The record of the performance management item DB 180 includes the adapter ID 181 and the product ID 182, the performance management item (metric name) 183, and the attributes (columns) of the SLA necessity 184.

The adapter ID 181 is an identifier of the adapter 141 that acquires the performance management item, and is the same as the adapter ID 177 of the product resource DB 170 (see FIG. 7). Performance information is acquired by calling the adapter 141 identified by the adapter ID 181.
The product ID 182 indicates the service type of the service, and is the same as the product ID 152 of the usage status DB 150 and the product ID 171 of the product resource DB 170.
The performance management item 183 is a name (metric name) of the performance management item of the service.
SLA necessity 184 indicates whether or not the performance management item is referred to in the SLA determination, and if it is referred to, it is Y, and if it is not referred to, it is N.

Returning to FIG. 4, the performance management unit 133 searches for a record in the performance management item DB 180 that has the same product ID 182 as the product ID 152 acquired from the usage status DB 150 and the SLA necessity 184 is Y, and obtains an adapter. Acquire ID181 and performance management item 183. Next, the performance management unit 133 specifies the service identifier via the adapter 141 identified by the adapter ID 181 to acquire the performance information of the performance management item 183, stores it in the performance information DB 160, and manages the service status. Notify the unit 131 that the acquisition of the performance information is completed.
The trouble ticket management unit 134 issues a trouble ticket when a service failure is found or there is an SLA violation. The trouble ticket includes the identifier of the service with the failure, the date and time when it was issued, the status of the failure response, and the like. The issued trouble ticket is processed by the trouble ticket handling scenario unit 122.

The partner operator API adapter unit 140 provides an interface function for calling the API of the service provided by the partner operator. The partner company API adapter unit 140 includes an adapter 141 that provides an interface function for each service product. When the service of the partner company is generated or the performance information is acquired, the adapter 141 corresponding to the service is called. The adapter 141 calls the API of the service (servers (reference numerals 220, 230, 240 in FIG. 1)) provided by the partner company, so that the service is generated and the performance information is acquired.

<< SLA judgment processing in regular monitoring >>
FIG. 9 is a sequence diagram showing an SLA determination process triggered by periodic monitoring, which is executed by the inter-operator batch service management device 100 according to the present embodiment. With reference to FIG. 9, the SLA determination process executed by the monitoring scenario unit 121, the service status management unit 131, the SLA management unit 132, and the performance management unit 133, which has been outlined in FIG. 3, will be described. The SLA determination process is not limited to a regular period, but is executed at a predetermined timing, for example, when the load of the inter-operator batch service management device 100 exceeds a predetermined value.

In step S11, the monitoring scenario unit 121 identifies the service to be determined by the SLA, outputs the identifier of the service to the service status management unit 131, and instructs the SLA determination. Specifically, the monitoring scenario unit 121 searches for a record of the usage status DB 150 (see FIG. 5) at a predetermined interval according to the service product, and the product ID 152 is an identifier of the service product. Next, the monitoring scenario unit 121 specifies the service ID 151 included in the search result record, and instructs the service state management unit 131 to make an SLA determination. When there are a plurality of records of the search result, the monitoring scenario unit 121 sequentially instructs the SLA determination.

In step S12, the service status management unit 131 decomposes the designated service, extracts the component services, and instructs the performance management unit 133 to collect performance information between each component service and the designated service. .. Specifically, the service status management unit 131 searches for a record of the usage status DB 150 (see FIG. 5), which is a service identifier whose service ID 151 is included in the instruction, and configures the search result record. Service ID 155. Get the service identifier of the component service from. Subsequently, the service status management unit 131 searches for the record of the usage status DB 150 in which the service identifier of the acquired component service is the service ID 151, and acquires the identifier of the component service of the component service. By repeating the process of searching for the component service, the service state management unit 131 decomposes the service instructed from the monitoring scenario unit 121 and extracts the component service. The service status management unit 131 outputs the service identifier of the designated cooperation service and the extracted component service to the performance management unit 133 to instruct the collection of performance information.

In step S13, the performance management unit 133 collects the performance information of the service instructed by the service status management unit 131 and stores it in the performance information DB 160 (see FIG. 6). Specifically, the performance management unit 133 searches for a record of the usage status DB 150, which is a service identifier in which the service ID 151 is instructed, and acquires the product ID 152 of the service. Next, the performance management unit 133 searches for a record of the performance management item DB 180 (see FIG. 8) in which the product ID 182 is the above product ID 152 and the SLA necessity 184 is Y, and the service is concerned. Acquire the product adapter ID 181 and the performance management item 183.

Subsequently, the performance management unit 133 acquires the collection of the performance information of the performance management item 183 via the adapter 141 identified by the adapter ID 181. The adapter 141 calls the API of the server (reference numerals 220, 230, 240 in FIG. 1) that provides the service, acquires the performance information of the specified performance management item of the specified service, and causes the performance management unit 133 to acquire the performance information. Output. The performance management unit 133 stores the output performance information in the performance information DB 160 (see FIG. 6), and notifies the service status management unit 131 that the acquisition of the performance information is completed. When the performance information is stored in the performance information DB 160, the performance management unit 133 newly adds a record. Subsequently, the performance management unit 133 stores the instructed service identifier, the above product ID 152, the current date and time, and the collected performance information in the service ID 161, the product ID 162, the collection date and time 163, and the collection data 164 of the added record. ..

In step S14, the service status management unit 131 and the SLA management unit 132, including the service specified by the monitoring scenario unit 121, move the service status management unit 131 and the SLA management unit 132 in order from the lower-level services of the component services extracted by the service status management unit 131 in step S12. Steps S15 to S22 are executed.
In step S15, the service status management unit 131 specifies the service identifier and instructs the SLA management unit 132 to make an SLA determination.

In step S16, the SLA management unit 132 acquires the SLA determination rule 176. Specifically, the SLA management unit 132 searches for a record of the usage status DB 150, which is the service identifier instructed by the service ID 151, and acquires the product ID 152 of the service. Next, the SLA management unit 132 searches for a record of the product resource DB 170 (see FIG. 7) whose product ID 171 is the product ID 152, and acquires the SLA determination rule 176 of the service product.

In step S17, the SLA management unit 132 acquires the performance information. Specifically, the SLA management unit 132 searches for a record of the performance information DB 160 (see FIG. 6), which is the service identifier instructed by the service ID 161, and acquires the collected data 164 of the search result record. do. Next, the SLA management unit 132 acquires the data of the performance management items included in the SLA determination rule 176 acquired in step S16 from the above-mentioned collected data 164. According to the SLA determination rule 176, the SLA management unit 132 may acquire the latest one collected data 164 or may acquire the latest plurality of collected data 164.

In step S18, the SLA management unit 132 executes the SLA determination. Specifically, the SLA management unit 132 refers to the performance management item data acquired in step S17, and determines whether or not there is an SLA violation in the service based on the SLA determination rule 176.
In step S19, the SLA management unit 132 proceeds to step S20 if there is an SLA violation in step S18, and proceeds to step S22 if there is no violation.
In step S20, the SLA management unit 132 notifies the monitoring scenario unit 121 that there was an SLA violation. The notification includes the identifier of the service that violated and the content of the violation (content of SLA determination rule 176).

In step S21, the SLA management unit 132 updates the usage status DB 150 (see FIG. 5). Specifically, the SLA management unit 132 searches the record of the usage status DB 150 for a record in which the service ID 151 is the service identifier to be determined by the SLA, and updates the state 157 of the record to "failure". Further, the SLA management unit 132 updates the state 157 of the service whose component is the service to "subordinate failure". Specifically, the SLA management unit 132 searches the record of the usage status DB 150 for a record in which the service identifier to be determined by the SLA is included in the configuration service ID 155, and updates the state 157 of the record to "subordinate failure". Further, the SLA management unit 132 repeatedly searches for a record of the service whose component is the service of the search result, and updates the state 157 of the record of the search result to "subordinate failure".

Regarding the linked service in which the component service is out of order, the state of the linked service 157 is updated to "subordinate failure" by the SLA determination of the component service. If the SLA determination of the linked service itself is a violation, the SLA management unit 132 updates the linked service itself as "failure". If the SLA determination of the linked service itself is not a violation, the SLA management unit 132 does not update the state 157 and remains a "subordinate failure".

In step S22, the SLA management unit 132 notifies the service status management unit 131 that the SLA determination of the service has been completed.
In step S23, it is determined whether the service status management unit 131 has executed steps S15 to S22 for all of the component services extracted in step S12. If the monitoring scenario unit 121 executes for all services including the service specified, the service status management unit 131 proceeds to step S24, and if there is an unprocessed service, from the lower service to step S15 or later. Repeat the process of.
In step S24, the service status management unit 131 notifies the monitoring scenario unit 121 that the SLA determination of the service instructed has been completed.

In the above processing, the service status management unit 131 decomposes the instructed service and extracts the component service (step S12), and the SLA management unit 132 lowers the extracted component services. Determine if the SLA is being followed in order from the service. When some kind of failure occurs in the service, the inter-operator collective service management device 100 determines the SLA retroactively to the components of the service, so that the cause service is in violation of the SLA determination result. It can be identified and the number of services that are failing can be ascertained. In addition, the inter-operator batch service management device 100 can grasp the equipment suspected of being out of order and the number thereof, such as the server providing the service and the network device in the communication path with the server. As described above, the inter-operator batch service management device 100 can execute the failure analysis (fault determination).

Further, even if the cooperation service has no failure detected, the inter-operator collective service management device 100 can identify the component service in which the failure has occurred by the above-mentioned failure analysis. The inter-operator batch service management device 100 responds before the service provider 210 using the linked service is affected by replacing the component service in which the failure has occurred with a normal service. be able to.

≪SLA judgment triggered by trouble ticket from service provider≫
With reference to FIG. 9, the SLA determination process executed by the inter-operator batch service management device 100 itself at a predetermined timing has been described. Subsequently, a failure analysis using the SLA determination process for the service failure detected by the service provider 210 will be described. FIG. 10 is a diagram for explaining the SLA determination process triggered by the receipt of a trouble ticket from the service provider, which is executed by the inter-operator batch service management device 100 according to the present embodiment. The SLA determination process will be described with reference to steps S131 to S136 described in FIG.

In step S131, the service provider 210 detects a failure of the service being used and notifies the inter-operator batch service management device 100. Specifically, the service provider 210 notifies the failure through the trouble ticket handling API 112 provided in the business API unit 110. The notification includes the service identifier of the service in which the failure occurred.
In step S132, the trouble ticket handling API 112 calls the trouble ticket management unit 134 and requests the issuance of the trouble ticket.

In step S133, the trouble ticket management unit 134 issues the trouble ticket 281. The trouble ticket 281 includes the issue date and time, the user identifier of the service provider 210 (user of the trouble ticket 281) who notified the failure that triggered the issuance of the trouble ticket, and the identifier of the service with the failure (related service of the trouble ticket 281). , Correspondence state (not shown), etc. are included. The response status includes the status of not responding, responding, discontinuing response, responding, etc., and indicates the progress status of troubleshooting (fault analysis). The issued trouble ticket 281 is sent to the trouble ticket handling scenario unit 122 included in the scenario management unit 120.

In step S134, the trouble ticket handling scenario unit 122 executes the SLA determination of the service. Specifically, the trouble ticket handling scenario unit 122 outputs the identifier of the service in which the failure occurred included in the trouble ticket 281 to the service status management unit 131, and instructs the SLA determination. The service status management unit 131, the SLA management unit 132, and the performance management unit 133 execute the processes after step S12 described in FIG. However, the notification destination of the SLA violation in step S20 and the notification destination of the completion of the SLA determination in step S24 are the trouble ticket handling scenario unit 122.

In step S135, the trouble ticket handling scenario unit 122 identifies the related service. The related service is a service of the same type (same service product) as the service in which the failure occurred, which is included in the trouble ticket 281. The trouble ticket handling scenario unit 122 searches the record of the usage status DB 150 (see FIG. 5) for the same record as the identifier of the service in which the failure occurred, in which the service ID 151 is included in the trouble ticket 281 and acquires the product ID 152. do. This product ID 152 is an identifier indicating a service product of the service.
Next, the trouble ticket handling scenario unit 122 searches for a record in which the product ID 152 is the same as the product ID 152 in the above search result in the records of the usage status DB 150, and acquires the service ID 151. This service ID 151 is an identifier of the same type of service as the service in which the failure occurred.

In step S136, the trouble ticket handling scenario unit 122 sequentially executes the SLA determination of the related service. Specifically, the trouble ticket handling scenario unit 122 executes the SLA determination of the related service and its component service. First, the trouble ticket handling scenario unit 122 updates the state 157 of the record corresponding to the service to be determined by SLA and the component service thereof, which is a record of the usage status DB 150 (see FIG. 5), to "suspect".

Next, the trouble ticket handling scenario unit 122 outputs the acquired service identifier to the service status management unit 131 to instruct the SLA determination. The service status management unit 131, the SLA management unit 132, and the performance management unit 133 execute the SLA determination process in the same manner as in step S134. Subsequently, the trouble ticket handling scenario unit 122 is a record of the usage status DB 150 if there is no failure including the component service as a result of the SLA determination, and is a record corresponding to the service to be determined by the SLA and the component service thereof. State 157 is updated to "normal".

By executing the SLA determination process triggered by the receipt of the trouble ticket from the service provider 210 shown in FIG. 10 (step S134), the inter-operator batch service management device 100 causes the notified service to fail. Identify the component service that is. Further, the inter-operator collective service management device 100 identifies a service of the same service product as the service notified as a related service (step S135), performs an SLA determination of the service (step S136), and fails. It is possible to perform failure analysis to diagnose whether it has occurred. The inter-operator batch service management device 100 determines whether or not a failure has occurred in advance without waiting for a notification (issue of a trouble ticket) from another service provider 210 using the same service product, and causes a failure. Perform the analysis. In addition, the inter-operator batch service management device 100 can grasp the equipment suspected of being out of order and the number thereof, such as the server providing the service and the network device in the communication path with the server.

≪SLA judgment triggered by SLA violation from partner company≫
Next, a failure determination using the SLA determination process for a service failure triggered by an SLA violation detected by a partner business operator will be described. FIG. 11 is a diagram for explaining an SLA determination process triggered by an SLA violation notification from a partner business operator, which is executed by the business operator collective service management device 100 according to the present embodiment. The SLA determination process will be described with reference to steps S141 to S146 described in FIG. In FIG. 11, the partner company is the computer base server 230, but the same processing is performed even if the application server 220 (see FIG. 1) or the network server 240.

In step S141, the computer-based server 230 detects an SLA violation (failure) of the provided service and notifies the inter-operator collective service management device 100. Specifically, the computer-based server 230 notifies through the adapter 141, which is an interface to the computer-based server 230 inside the inter-operator collective service management device 100. The notification includes the identifier of the service in which the failure occurred and the content of the violation.
In step S142, the adapter 141 generates an SLA violation notification (SLA violation notification) 283 and notifies the trouble ticket management unit 134. The SLA violation notification 283 includes the date and time of notification, the identifier of the service in which the SLA violation occurred, the content of the violation, and the like.

In step S143, the trouble ticket management unit 134 issues the trouble ticket 284. The trouble ticket 284 includes the issue date and time, the identifier of the SLA violation notification 283 as a related object (SLAV84792 shown in FIG. 11), and the like. In addition, related services and support status are included, but not shown. The issued trouble ticket 284 and SLA violation notification 283 are output to the trouble ticket handling scenario unit 122 provided in the scenario management unit 120.

In step S144, the trouble ticket handling scenario unit 122 executes the SLA determination of the service whose component is the service. Specifically, the trouble ticket handling scenario unit 122 searches the usage status DB 150 (see FIG. 5) for a record in which the service ID 151 is the identifier of the service included in the trouble ticket 284, and acquires the parent service ID 153. .. Next, the trouble ticket handling scenario unit 122 searches for a record in which the service ID 151 is the parent service ID 153 in the usage status DB 150, and acquires the parent service ID 153 of the search result record. The trouble ticket handling scenario unit 122 repeats the search for the parent service ID 153 until the parent service ID 153 becomes an invalid value.

Subsequently, the trouble ticket handling scenario unit 122 outputs the service ID 151 of the service whose parent service ID 153 is an invalid value and has no parent to the service status management unit 131, and instructs the SLA determination. The service status management unit 131, the SLA management unit 132, and the performance management unit 133 execute the processes after step S12 described in FIG. However, the notification destination of the SLA violation in step S20 and the notification destination of the completion of the SLA determination in step S24 are the trouble ticket handling scenario unit 122.

In step S145, the trouble ticket handling scenario unit 122 identifies the related service. The related service is a service whose component is a service that is the same service product as the service included in the SLA violation notification 283. The trouble ticket handling scenario unit 122 searches the record of the usage status DB 150 for a record in which the service ID 151 is an identifier in the related service of the SLA violation notification 283, and acquires the product ID 152. This product ID 152 is an identifier indicating a service product of the service. Next, the trouble ticket handling scenario unit 122 searches the product resource DB 170 for a record including the above product ID 152 in the constituent product 174, and acquires the product ID 171. This product ID 171 is an identifier of a service product whose component is the service in which the failure has occurred.

Subsequently, the trouble ticket handling scenario unit 122 searches the product resource DB 170 for a record including the above product ID 171 in the constituent product 174, and acquires the product ID 171 of the search result record. By repeating this search, the trouble ticket handling scenario unit 122 can acquire the identifier of the service product whose component is the service that violates the SLA. The identifier of the service product is not limited to one, and may be multiple. Next, the trouble ticket handling scenario unit 122 searches for a record in which the product ID 152 is the identifier of the above service product in the usage status DB 150, and acquires the service ID 151.
This service ID 151 is a related service, and is a service whose component is the service of the same service product as the service included in the SLA violation notification 283.

In step S146, the trouble ticket handling scenario unit 122 sequentially executes the SLA determination of the related service. Specifically, the trouble ticket handling scenario unit 122 executes the SLA determination of the related service and its component service. First, the trouble ticket handling scenario unit 122 updates the state 157 of the record corresponding to the service to be determined by SLA and the component service thereof, which is a record of the usage status DB 150 (see FIG. 5), to "suspect". Next, the trouble ticket handling scenario unit 122 outputs the acquired service identifier to the service status management unit 131 to instruct the SLA determination. The service status management unit 131, the SLA management unit 132, and the performance management unit 133 execute the SLA determination process in the same manner as in step S144. Subsequently, the trouble ticket handling scenario unit 122 is a record of the usage status DB 150 if there is no failure including the component service as a result of the SLA determination, and is a record corresponding to the service to be determined by the SLA and the component service thereof. State 157 is updated to "normal".

By executing the SLA determination process triggered by the SLA violation notification from the partner operator shown in FIG. 11, the inter-operator collective service management device 100 performs a failure diagnosis of the service whose component is the notified service. (Step S144). Further, the inter-company batch service management device 100 identifies the service of the service product whose component is the service product that violates the SLA (step S145), determines the SLA of the service (step S146), and fails. Diagnose if this has occurred and perform a failure analysis. For a service product that may have a failure, the inter-operator batch service management device 100 determines in advance whether or not a failure has occurred without waiting for a notification from the service provider 210. Can be executed. In addition, the inter-operator batch service management device 100 can grasp the equipment suspected of being out of order and the number thereof, such as the server providing the service and the network device in the communication path with the server. Further, the inter-operator collective service management device 100 can identify the services (range of influence, range of affliction) affected by the SLA violation.

≪Modification example≫
The SLA determination rule 176 (see FIG. 7) is not limited to one rule. There may be a plurality of SLA determination rules such as SLA determination rules for each of the write delay time, read delay time, write error occurrence frequency, and read error occurrence frequency for the virtual volume. Further, the triggers of the SLA determination executed by the SLA management unit 132 are periodic monitoring (monitoring at a predetermined timing) (see FIGS. 3 and 9), failure notification from the service provider 210 (see FIG. 10), and It was an SLA violation notification from a partner company (see Fig. 11). Depending on the occasion, the SLA management unit 132 may change the SLA determination rule 176 to be applied.

In the SLA determination of a service having a component, the SLA determination may be executed by referring to the performance information of a plurality of component services or using the result of the SLA determination of the component service. In the example of the website rental service, by adding up the response times of the firewall, the web server, and the database server, there is a rule to judge whether the response time from the viewpoint of the website user complies with the SLA. It may be included in the SLA determination rule 176. Further, in the cooperation service having a plurality of the same services as components, the SLA management unit 132 may comply with the SLA determination result of the cooperation service as long as the SLA determination result for the component service of a predetermined ratio is compliant. Further, the SLA management unit 132 may perform the SLA determination of the cooperative service by weighting the SLA determination result of the component service according to the processing capacity (throughput) of each component service.

Further, the judgment result of the SLA judgment rule 176 may be three or more judgment levels instead of two of compliance or violation. The SLA management unit 132 may make an SLA determination of the linked service by combining the determination levels of the component services. For example, there are four judgment levels: compliance level 3 (highest compliance level), compliance level 2, compliance level 1 (lowest compliance level), and violation level. If there is no violation level in the component service and the average of the compliance levels is equal to or higher than a predetermined value, the SLA management unit 132 may make the SLA determination result of the linked service compliant.

In the SLA determination triggered by the periodic monitoring, instead of the SLA determination rule that immediately determines the failure, the failure occurrence may be predicted by referring to the performance information of the periodic monitoring a plurality of times and the SLA violation may be determined. For example, if the memory size that can be used continuously decreases after a predetermined number of periodic monitoring, the rule that predicts that a memory shortage failure will occur and determines that the SLA is violated is determined by the SLA. It may be included in rule 176. In addition, the SLA judgment rule 176 includes a rule for predicting a failure and judging as an SLA violation by referring to the performance management items of a plurality of component services and the performance information of a plurality of periodic monitorings using machine learning technology. May be good. Furthermore, not only performance information, but also partner companies that provide service products and component services, servers that provide services, network devices on the communication path to those servers, types of network devices, etc. The SLA determination rule 176 may include a rule for predicting a failure and determining the failure.

In the failure analysis triggered by the failure notification from the service provider 210 and the SLA violation notification from the partner provider, the inter-operator collective service management device 100 sets the interval of periodic monitoring of the service product in which the failure is found. It may be shortened. Specifically, the inter-company batch service management device 100 may shorten the interval of periodic monitoring executed by the monitoring scenario unit 121 for the service of the service product. By shortening the interval of periodic monitoring, the inter-operator batch service management device 100 can focus on services with a high probability of failure, and can detect a failure in a short time. ..

In the above embodiment, after the performance information is collected and stored in the performance information DB 160, the SLA management unit 132 executes the SLA determination from the lower component service. The SLA management unit 132 may collect necessary performance information each time the SLA determination is executed.

The performance information stored in the performance information DB 160 is collected before the SLA determination and is referred to when the SLA determination is made. Regardless of the SLA determination, the performance management unit 133 may periodically acquire all the performance information in the performance management item DB 180. In this case, the service status management unit 131 executes the SLA determination in step S14 and subsequent steps after extracting the component services from the designated service without instructing the collection of the performance information in step S12 shown in FIG. ..

When a failure occurs, a plurality of SLA determinations may be executed at the same time triggered by periodic monitoring, a trouble ticket, and an SLA violation notification, and the same performance information may be collected multiple times. However, if the performance management unit 133 periodically acquires the performance information and the SLA determination refers to the performance information, it is possible to avoid collecting duplicate performance information, and the inter-operator batch service management device 100 or the like. It is possible to reduce the load of services provided by partner companies.

The performance management unit 133 may refer to the performance information acquired periodically and give a warning about the service when the numerical value of the performance management item specified in advance exceeds a predetermined threshold value. If a warning occurs a predetermined number of times or more within a predetermined time, it may be determined that the service may be out of order, and an SLA determination for the service may be executed. In addition, the performance management unit 133 may predict an SLA violation (failure) by referring to the performance management items of a plurality of component services using machine learning technology.

Regarding the record of the usage status DB 150 (see FIG. 5), the component service included only the service identifier (configuration service ID 155). The component product may include the service product identifier of the component service. When there is an SLA violation notification, the trouble ticket response scenario unit 122 accesses both the usage status DB 150 (see FIG. 5) and the product resource DB 170 (see FIG. 7) to configure the service product for which the SLA violation notification has been received. I was searching for a service product as an element. By adding the service product identifier of the component service to the attribute of the usage status DB 150, access to the product resource DB 170 becomes unnecessary.

In S136 described in FIG. 10, the trouble ticket response scenario unit 122 sets the record status 157 of the usage status DB 150 (see FIG. 5) corresponding to the service and its component service to “suspect” for each related service. It was updated, the SLA judgment was executed, and if there was no failure, it was set to "normal". The trouble ticket response scenario unit 122 first updates the status 157 of all records corresponding to the related service to "suspect", then executes an SLA determination for each related service, and if there is no failure, " It may be "normal". By doing so, the inter-operator collective service management device 100 can identify the suspected service at an early stage. The same applies to step S146 shown in FIG.

In the SLA determination process shown in FIG. 9, the SLA management unit 132 updated the state 157 of the usage status DB 150 (see FIG. 5) to “failure” or “subordinate failure” (step S21 shown in FIG. 9). The monitoring scenario unit 121 may be updated upon receiving the notification of the SLA violation. Further, in the SLA determination process shown in FIGS. 10 and 11, the trouble ticket handling scenario unit 122 may be updated.
The record state 157 of the usage status DB 150 distinguishes between a "failure" and a "subordinate failure", but the "subordinate failure" may be included as a "failure".

The usage status DB is configured to include an identifier of the service provider (user ID 154 shown in FIG. 5), and the inter-operator batch service management device 100 includes a failed service, a service suspected of being failed, and each service provider 210. It is possible to count any of the failed services, the services suspected of failing for each service provider 210, the failed services for each service product, and the services suspected of failing for each service product. By doing so, the inter-business batch service management device 100 can provide the administrator of the inter-business batch service management device 100 in an easy-to-understand manner in the operating status of the linked service.

≪Effect≫
When there is a failure in the linked service, the inter-operator batch service management device 100 can trace back to the component service, perform an SLA determination, and analyze the cause of the failure. Therefore, the failure can be easily isolated, the failure analysis time can be reduced, and the recovery time from the failure can be reduced. As a result, the inter-operator batch service management device 100 can improve the reliability of the linked service and reduce the cost of troubleshooting.

The inter-company batch service management device 100 performs the SLA determination at a predetermined timing, and when there is a failure in the service, it is possible to identify which component service is out of order.
In the wake of a failure notification from the service provider 210, which is a user of the linked service, and a notification of an SLA violation from a partner provider that provides the component service, the inter-operator collective service management device 100 uses the service product. Perform SLA determination. The inter-operator batch service management device 100 executes the SLA determination not only for the notified service but also for the service of the same service product. At the time of SLA determination, the inter-operator collective service management device 100 temporarily sets the service as a suspected failure service, and if it is found that there is no failure, it is normal.

As a result, the service suspected of failure can be identified and then narrowed down to the service that has failed. It is possible to accurately grasp the number of services in the failure range). Further, even if the cooperation service has no failure detected, if the component service has a failure, the inter-operator collective service management device 100 can detect the failure. By replacing the component service in which the failure has occurred with a normal service, the inter-operator collective service management device 100 can deal with the failure before the failure occurs in the linked service.

Since the inter-operator batch service management device 100 executes the SLA determination retroactively to the component service and detects the failure, the service causing the failure can be identified, and the range of influence of the failure (affected). Obstacle range) can be specified. Further, in the usage status DB 150 (see FIG. 5), the service and the service provider 210 using the service are managed in association with each other, and the inter-operator collective service management device 100 fails for each service provider 210. You can know the services you are doing and the number of them. The inter-operator collective service management device 100 grasps the equipment suspected of failure and the number of facilities such as services included in the affected area, servers that provide the services, and network devices in the communication path with the servers. Can be done.

When determining the SLA, the inter-operator batch service management device 100 determines by combining the performance information in the performance management items provided by the partner operator. For this reason, it is not necessary to newly develop a function for acquiring performance information necessary for SLA determination, and it is possible to realize SLA determination of a linked service at a lower cost than in the case of development. In addition, even when a new collaborative service is provided with a service provided by a new partner operator as a component, SLA judgment can be made using the performance information provided by the partner operator, and collective service management between operators is possible. The device 100 can provide a new cooperation service to a service provider in a short period of time as compared with the case of developing a function for acquiring performance information.

The inter-company batch service management device 100 can count the services provided, the services used by each service provider 210, and the services of each service product, which are out of order or suspected of being out of order. By doing so, the inter-business batch service management device 100 can provide the administrator of the inter-business batch service management device 100 in an easy-to-understand manner in the operating status of the linked service.

101 Cooperative service system 100 Collective service management device between operators 110 Business API department 120 Scenario management department 121 Monitoring scenario department 122 Trouble ticket handling scenario department 130 Business resource management department 131 Service status management department (service level compliance judgment department)
132 SLA Management Department 133 Performance Management Department 134 Trouble Ticket Management Department 140 Partner Business API Adapter Department 141 Adapter 150 Usage Status DB
160 Performance information DB
170 Product Resource DB
176 SLA Judgment Rule (Service Level Compliance Judgment Rule)
180 Performance management item DB
210 Service provider 211 Computer

Claims (8)

Service server and the service provided, utilizing a plurality of the services configured as elements by linking service, and cooperative service that links include service obtained by a plurality of the collaboration as a component service, the It is a collective service management device between business operators that provides the cooperation service by connecting both the computer and the server of the person via a network.
A storage unit that stores a usage status database that stores information relating the cooperation service and a plurality of the component services constituting the cooperation service, and a storage unit.
According to a service level compliance determination rule associated with the component service or the cooperation service and indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. A service level compliance determination unit that executes a service level compliance determination as to whether each of the service and the linked service complies with or violates the predetermined service level.
With reference to the usage status database, the component service is extracted from the cooperation service, and if the extracted component service is the cooperation service, the component service is further extracted, and the extracted lower level It is characterized by having a service status management unit that instructs the service level compliance determination unit in order from the component service of the above and executes the service status determination to determine the operating status of the linked service. Collective service management device between business operators. When the service level compliance determination unit executes the service level compliance determination for the component service, the service level compliance determination unit provides the component service according to the service level compliance determination rule associated with the component service. The inter-operator collective service management device according to claim 1, wherein the service level compliance determination is executed with reference to the performance information of the component service acquired from the server. When executing the service level compliance determination for the linked service, the service level compliance determination unit provides the component service of the linked service according to the service level compliance determination rule associated with the linked service. The inter-operator collective service management device according to claim 1, wherein the service level compliance determination is executed with reference to the performance information of the component service acquired from the server. When the service level compliance determination unit executes the service level compliance determination for the linked service, the service level compliance determination for the component service is determined according to the service level compliance determination rule associated with the linked service. The inter-operator collective service management device according to claim 1, wherein the service level compliance determination for the linked service is executed using the result of the above. A server that provides a service and a computer of a service provider that uses a linked service in which a plurality of the services are linked as component services are both connected via a network, and a collective service between the providers that provides the linked service. It ’s a management device,
A storage unit that stores a usage status database that stores information relating the cooperation service and a plurality of the component services constituting the cooperation service, and a storage unit.
According to a service level compliance determination rule associated with the component service or the cooperation service and indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. A service level compliance determination unit that executes a service level compliance determination as to whether each of the service and the linked service complies with or violates the predetermined service level.
With reference to the usage status database, the component service is extracted from the cooperation service, and if the extracted component service is the cooperation service, the component service is further extracted, and the extracted lower level It is provided with a service status management unit that instructs the service level compliance determination unit to determine the service level compliance in order from the component service of the above and executes the service status determination to determine the operating status of the linked service.
The information in the usage status database is information in which the type of the cooperation service, the type of the component service, and the state including any one of normal, failure, and suspected failure as the state of the cooperation service are further associated with each other. And
When the server that provides the component service notifies the failure of the component service, the usage status database is referred to, and the type of the component service that has been notified of the failure is the same type. Regarding the cooperation service whose component service is a component service, the state of the usage status database corresponding to the cooperation service is regarded as a failure suspicion.
Instruct the service status management unit to determine the service status for the linked service,
When the service level compliance determination for the linked service or its component service violates, the status of the usage status database corresponding to the linked service is changed from failure suspect to failure.
When the service level compliance determination for the linked service and its component service is met, a scenario management unit that normally changes the status of the usage status database corresponding to the linked service from the suspected failure is further provided. inter-dealer bulk service management system that shall be the feature. A server that provides a service and a computer of a service provider that uses a linked service in which a plurality of the services are linked as component services are both connected via a network, and a collective service between the providers that provides the linked service. It ’s a management device,
A storage unit that stores a usage status database that stores information relating the cooperation service and a plurality of the component services constituting the cooperation service, and a storage unit.
According to a service level compliance determination rule associated with the component service or the cooperation service and indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. A service level compliance determination unit that executes a service level compliance determination as to whether each of the service and the linked service complies with or violates the predetermined service level.
With reference to the usage status database, the component service is extracted from the cooperation service, and if the extracted component service is the cooperation service, the component service is further extracted, and the extracted lower level It is provided with a service status management unit that instructs the service level compliance determination unit to determine the service level compliance in order from the component service of the above and executes the service status determination to determine the operating status of the linked service.
The information in the usage status database is information in which the type of the linked service is further associated with the status of the linked service including any one of normal, faulty, and suspected faults.
When the computer of the service provider notifies the failure of the cooperation service, the usage status database is referred to, and the cooperation service of the same type as the type of the cooperation service for which the failure notification is given is provided. The state of the usage status database corresponding to the linked service is regarded as a failure suspicion.
Instruct the service status management unit to determine the service status for the linked service,
When the service level compliance determination for the linked service or its component service violates, the status of the usage status database corresponding to the linked service is changed from failure suspect to failure.
When the service level compliance determination for the linked service and its component service is met, a scenario management unit that normally changes the status of the usage status database corresponding to the linked service from the suspected failure is further provided. inter-dealer bulk service management system that shall be the feature. The information in the usage status database is information further associated with the service provider of the linked service.
The scenario management department
For each service provider, the linked service whose status is a failure is counted.
For each service provider, the linked services whose status is suspected to be out of order are counted.
For each type of the linked service, the linked service whose status is a failure is counted.
The inter-operator collective service management device according to claim 5 or 6, wherein for each type of the linked service, any of the counting of the linked services whose state is suspected of failure is executed. Service server and the service provided, utilizing a plurality of the services configured as elements by linking service, and cooperative service that links include service obtained by a plurality of the collaboration as a component service, the This is an inter-operator batch service management method for an inter-operator batch service management device that provides the linked service by connecting both the computer and the server via a network.
Before article inter-dealer bulk service management device,
Includes a usage database information associating a plurality of said component services constituting the front Symbol linkage service and the linkage service is stored,
According to a service level compliance determination rule associated with the component service or the cooperation service and indicating a rule for determining whether the component service or the cooperation service complies with or violates a predetermined service level. A service level compliance determination step for executing a service level compliance determination as to whether each of the service and the linked service complies with or violates the predetermined service level, and
With reference to the usage status database, the component service is extracted from the cooperation service, and if the extracted component service is the cooperation service, the component service is further extracted, and the extracted lower level The service level compliance determination step is executed in order from the component service of the above, and the service status management step for executing the service status determination for determining the operating status of the linked service is executed. Service management method.

Images