Cloud service support device, cloud service support method, and computer program

JPWO2024202898A5Active Publication Date: 2025-11-27NEC CORP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025510052
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-02-29
Filing Date
2024-02-29
Publication Date
2025-11-27
Estimated Expiration
2044-02-29

AI Technical Summary

Technical Problem

SaaS systems cannot directly monitor the operating status of cooperative systems (SaaS, PaaS, or IaaS provided by another provider), leading to delayed recognition of failures, causing unnecessary investigation and potential service disruptions.

Method used

A cloud service support device that acquires operational status information from multiple SaaS systems, estimates failure occurrence in linked systems, and outputs fault occurrence estimation information, enabling early detection of failures before user notification.

Benefits of technology

Enables prompt detection and notification of failures in cooperative systems, reducing unnecessary work and improving service reliability by identifying issues before they impact SaaS operations.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader

Abstract

An acquisition unit of this support device acquires operation status information representing an operation status from each of a plurality of SaaSes in order to detect a failure that has occurred in a cooperation system with which SaaS is cooperating, before the cooperation system reports the occurrence of the failure. Upon detecting an occurrence of a failure in SaaS, an estimation unit uses the operation status information acquired from each of the plurality of SaaSes to estimate whether or not a failure has occurred in a cooperation system that is cooperating with the failed SaaS. If it is estimated that a failure has occurred in the cooperation system, an output unit outputs failure occurrence estimation information indicating the estimation that a failure has occurred in the cooperation system.
Need to check novelty before this filing date? Find Prior Art

Description

Cloud service support device, cloud service support method, and program storage medium

[0001] The present disclosure relates to technology related to cloud services.

[0002] One system that provides cloud services is called SaaS (Software as a Service). SaaS provides software via an information and communication network (the Internet). SaaS providers that operate such SaaS services may use SaaS, PaaS (Platform as a Service), or IaaS (Infrastructure as a Service) provided by other providers to run the software. Both PaaS and IaaS are systems that provide cloud services, but PaaS provides a platform for running software (application programs) via an information and communication network (the Internet). IaaS provides hardware such as computers and storage devices that run software, as well as infrastructure such as communication lines, via the information and communication network (the Internet). IaaS is also sometimes called HaaS (Hardware as a Service).

[0003] Patent Document 1 (JP 2012-89080 A) relates to a fault analysis device, and discloses a technique for acquiring server logs and, if an error occurs in the server, using the acquired logs to analyze the cause of the error. Patent Document 2 (JP 2011-90622 A) relates to an operation status notification system, and discloses a technique for receiving operation status data from a server and detecting that a server failure has occurred using the received operation status data.

[0004] JP 2012-89080 A JP 2011-90622 A

[0005] However, SaaS cannot directly monitor the operation status of SaaS, PaaS, or IaaS provided by other providers (in the following description, such SaaS, PaaS, and IaaS provided by other providers will be collectively referred to as an interconnected system). In other words, SaaS cannot directly obtain log information or the like indicating the operation status of the interconnected system from the interconnected system and use the obtained information to monitor the operation status of the interconnected system. For this reason, SaaS cannot recognize the occurrence of a failure in the interconnected system unless the interconnected system notifies it of the occurrence.

[0006] However, when a failure occurs in a linked system, the linked system must check the situation before reporting the failure, so it takes time for the linked system to report the failure after the failure occurs. In other words, it takes time for SaaS to recognize the failure in the linked system it is using after a failure occurs in the linked system.

[0007] In this way, the SaaS cannot immediately know that a failure has occurred in the linked system. Therefore, when the SaaS enters a state of failure where it is unable to operate normally due to a failure in the linked system, it will first check whether there is a failure in itself, since it is not aware of the failure in the linked system. In other words, even if there is no problem with the SaaS, the work of searching for the cause of the failure in the SaaS must be carried out, resulting in unnecessary work.

[0008] The present disclosure has been devised to solve the above-mentioned problems. That is, a main objective of the present disclosure is to provide a technology for detecting a failure in an interconnected system (SaaS, PaaS, or IaaS provided by another provider) before the interconnected system notifies the user of the failure when the failure occurs in the interconnected system, when SaaS uses the interconnected system (SaaS, PaaS, or IaaS provided by another provider).

[0009] In order to achieve the above object, one aspect of the cloud service support device disclosed herein comprises: an acquisition unit that acquires operational status information indicating the operational status from each of a plurality of SaaS (Software as a Service); an estimation unit that, when a failure in a SaaS is detected, estimates whether or not a failure has occurred in a linked system that is linked to the SaaS in which the failure has occurred, using the operational status information acquired from each of the plurality of SaaS; and an output unit that, when it is estimated that a failure has occurred in the linked system, outputs failure occurrence estimation information indicating that a failure has been estimated in the linked system.

[0010] Furthermore, one aspect of the cloud service support method according to the present disclosure involves using a computer to acquire operational status information representing the operational status from each of a plurality of SaaS (Software as a Service), and when a SaaS failure is detected, using the operational status information acquired from each of the plurality of SaaS to estimate whether a failure has occurred in a linked system linked to the SaaS in which the failure has occurred, and when it is estimated that a failure has occurred in the linked system, outputting failure occurrence estimation information representing that a failure has been estimated in the linked system.

[0011] Furthermore, in one aspect, the computer program according to the present disclosure causes a computer to perform the following processes: acquiring operational status information indicating the operational status from each of a plurality of SaaS (Software as a Service); when a SaaS failure is detected, using the operational status information acquired from each of the plurality of SaaS to estimate whether or not a failure has occurred in a linked system linked to the SaaS in which the failure has occurred; and when it is estimated that a failure has occurred in the linked system, outputting failure occurrence estimation information indicating that a failure has been estimated in the linked system.

[0012] According to the present disclosure, when SaaS uses an interconnected system, if a failure occurs in the interconnected system, the failure can be detected before the interconnected system notifies the occurrence of the failure.

[0013] FIG. 1 is a diagram illustrating an embodiment of a cloud service support device (support device) according to the present disclosure. FIG. 2 is a diagram illustrating an example of a connection relationship between a support device and a SaaS to be supported. FIG. 3 is a diagram illustrating an example of an output mode in which the support device outputs failure occurrence estimation information. FIG. 4 is a flowchart illustrating an example of operation in the support device. FIG. 5 is a diagram illustrating another embodiment of a cloud service support device (support device) according to the present disclosure. FIG. 6 is a diagram illustrating the configuration of a cloud service support device (support device) of another embodiment. FIG. 7 is a flowchart illustrating an example of operation in the support device of another embodiment.

[0014] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0015] First Embodiment A cloud service support device (hereinafter also referred to as a support device for short) according to a first embodiment of the present disclosure is a device that provides support services for Software as a Service (SaaS). SaaS is a system that provides software as a cloud service via an information and communication network (the Internet). Herein, individuals and companies using SaaS are collectively referred to as SaaS users.

[0016] That is, the support device in the first embodiment has a configuration as shown in Fig. 1. The support device 1 is connected to a support target SaaS 3 that provides a support service. In the example of Fig. 1, for convenience, the number of SaaS 3 connected to the support device 1 is one, but in reality, the number of support target SaaS 3 connected to the support device 1 is multiple, as shown in Fig. 2. These support target SaaS 3 use cloud services provided by linked systems (SaaS, IaaS, or PaaS provided by other operators).

[0017] The support service provided by the support device 1 to SaaS3 is a service that notifies SaaS3 of a failure in the linked system 5 used by SaaS3 before the linked system 5 reports the failure.

[0018] The support device 1 has a configuration (function) for providing a failure notification service of such a linked system 5 to the SaaS 3 to be supported. The support device 1 is a computer device, and as shown in FIG. 1 , includes a control device 10 and a storage device 20. The storage device 20 includes a storage medium for storing data and a computer program (hereinafter also referred to as a program) 21. There are multiple types of storage devices, such as magnetic disk devices and semiconductor memory devices. Furthermore, there are many types of semiconductor memory devices, such as multiple types of RAM (Random Access Memory) and ROM (Read Only Memory). The types and number of storage devices 20 included in the support device 1 are not limited, and a description thereof will be omitted. Furthermore, if the support device 1 is equipped with multiple types of storage devices 20, they will be collectively referred to as storage devices 20.

[0019] The control device 10 is configured with a processor such as a CPU (Central Processing Unit). The control device 10 can have various functions based on a program 21 stored in a storage device 20 by reading and executing the program 21. Here, the control device 10 has an acquisition unit 11, an estimation unit 12, a generation unit 13, and an output unit 14 as functional units that provide a failure occurrence notification service for the linked system 5.

[0020] The acquisition unit 11 acquires operation status information from each of the multiple SaaS 3 to be supported. The operation status information is information that indicates the operation status of the SaaS 3 and includes at least information on whether processing using the linkage system 5 is running normally. The storage device 20 stores an operation status history information file for each SaaS 3 to be supported, and the acquisition unit 11 adds the acquired operation status information to the operation status history information file for each SaaS 3 to be supported. The timing at which the acquisition unit 11 acquires operation status information from each of the multiple SaaS 3 to be supported may be set appropriately by the operator of the support device 1, but it may be assumed, for example, that the information is acquired at predetermined time intervals. In such a case, if, for some reason, there is a SaaS 3 for which operation status information could not be acquired at the acquisition timing, the acquisition unit 11 adds information indicating a failure to the operation status history information file in the storage device 20 as operation status information related to that SaaS 3.

[0021] The estimation unit 12 uses the acquired operation status information to determine whether a failure has occurred in the SaaS 3. Furthermore, when the estimation unit 12 detects a SaaS 3 in which a failure has occurred, the estimation unit 12 uses the operation status information acquired from each of the multiple SaaS 3 to estimate whether a failure has occurred in the linked system 5 linked to the SaaS 3 in which the failure has been detected. The following method can be considered as an example of a method for estimating the occurrence of a failure in the linked system 5.

[0022] For example, user information regarding the SaaS 3 to be supported is pre-registered in the storage device 20 of the support device 1. The user information includes basic user information such as a user name, location, and contact information for identifying the SaaS to be supported, as well as related system information that indicates the linked system 5 with which the SaaS 3 is linked.

[0023] The estimation unit 12 references the user information registered in the storage device 20 and searches for items common to multiple SaaS 3 where a failure has occurred. As a result, it is assumed that the use of the same linked system 5 is detected as a common item among a predetermined percentage or more of the SaaS 3 where a failure has occurred. In this case, the estimation unit 12 estimates that the failure has occurred in the linked system 5 common to those SaaS 3 where a failure has occurred. Using this estimation result, for each SaaS 3 where a failure has occurred, the estimation unit 12 estimates whether or not a failure has occurred in the linked system 5 with which it is linked.

[0024] The estimation unit 12 further detects that a predetermined percentage or a predetermined number of the SaaS 3 where the failures have occurred have a common feature, for example, that the locations of the SaaS 3 are close to each other. In this case, the estimation unit 12 estimates that a communication failure has occurred in the area where the SaaS 3 where the failures have occurred are located.

[0025] The estimation unit 12 can further estimate the following items about the linked system 5 in which a failure is estimated to have occurred. In this case, the operation status information acquired from the SaaS 3 further includes application processing status information. The application processing status information is information representing the processing status of an application program (application) that is providing a service to the SaaS user 7. The estimation unit 12 extracts multiple pieces of application processing status information related to the linked system 5 in which a failure is estimated to have occurred from the application processing status information of the operation status information acquired from multiple SaaSs 3 by the acquisition unit 11. The estimation unit 12 then analyzes the extracted application processing status information to estimate the availability of each of multiple functions in the linked system 5. Specifically, for example, assume that the linked system 5 provides a database usage service as a cloud service. One of the functions related to the use of this database is an authentication function that determines access permission to the database. Another function related to the database is a data write function. Another function related to the database is a data read function. In such a case, the estimation unit 12 can estimate that, for the linked system 5 where a failure is suspected, the authentication function and data writing function related to the database are working, but there is an abnormality in the data reading function.

[0026] When the estimation unit 12 estimates that a failure has occurred in the linked system 5, the generation unit 13 generates information to notify the SaaS 3 and the SaaS user 7 of the estimation result (i.e., information indicating that a failure has been estimated in the linked system 5) as failure occurrence estimation information. The form of the failure occurrence estimation information generated by the generation unit 13 corresponds to a predetermined notification form for notifying the estimation result by the estimation unit 12. For example, when email is used as the notification form, the generation unit 13 generates an email body indicating the content of the estimation result by the estimation unit 12 as the failure occurrence estimation information. When a website is used as the notification form, the generation unit 13 generates failure occurrence estimation information to be posted on the website to change the content posted on the website according to the estimation result by the estimation unit 12. When a website is used, the support device 1 may notify the SaaS 3 and the SaaS user 7 by email informing them that new information regarding the operation of the linked system 5 has been posted on the website. In such a case, the generating unit 13 also generates the mail body of such an email.

[0027] The output unit 14 outputs the failure estimation information generated by the generation unit 13 using an output method corresponding to the predetermined notification mode as described above. For example, the output unit 14 notifies (transmits) the failure estimation information to the SaaS 3 by email. The output unit 14 may also transmit the failure estimation information to the SaaS user 7 by email. In this case, the SaaS 3 provides the contact information (email address information) of the SaaS user 7 to the output unit 14. Alternatively, the email sent from the output unit 14 to the SaaS 3 is configured to be forwarded by the SaaS 3 to the SaaS user 7. Note that the output destination to which the output unit 14 outputs the failure estimation information may be limited to the SaaS 3 and its SaaS user 7 using the linked system 5 in which the failure is estimated to have occurred, or may be all SaaS 3s and their SaaS users 7 that are support targets. The output destination of the failure estimation information by the output unit 14 may be appropriately set by the operator of the support device 1.

[0028] As another method for outputting the failure occurrence estimation information by the output unit 14, the use of a website, as described above, is conceivable. For example, a website may be created by the operator of the support device 1, and web pages corresponding to each SaaS 3 may be created within the website. These web pages are viewable by at least the operators of the corresponding SaaS 3 and their SaaS users 7. For each SaaS 3, the output unit 14 outputs the failure occurrence estimation information, as shown in FIG. 3 . In the example of FIG. 3 , web page 8 displays the name of the corresponding SaaS 3 and the operational status of the linked system 5 linked to the SaaS 3. Furthermore, the web page 8 displays information on the availability of each of the multiple functions of the linked system 5, as well as reference information. The reference information is information that is likely to be useful to the SaaS 3 and SaaS user 7 in which a failure has occurred in the linked system 5, and is not limited to information informing the SaaS 3 of other linked systems 5 operating normally, as shown in the example of FIG. 3 .

[0029] The support device 1 of the first embodiment is configured as described above. Next, an example of the operation related to the fault occurrence notification service in the support device 1 will be described with reference to Fig. 4. Fig. 4 is a flowchart illustrating an example of the operation related to the fault occurrence notification service in the support device 1.

[0030] For example, the acquisition unit 11 acquires operation status information from each of the multiple SaaSs 3 to be supported (step 101 in FIG. 3 ). Then, using the operation status information acquired from each of the multiple SaaSs 3 to be supported, the estimation unit 12 determines whether or not a failed SaaS 3 exists. When a failed SaaS 3 is detected, the estimation unit 12 uses the acquired operation status information to estimate whether or not a failure has occurred in the linked system 5 linked to the failed SaaS 3 (step 102). Thus, when it is estimated that a failure has occurred in the linked system 5, for example, the estimation unit 12 further estimates the availability of each of the functions of the linked system 5 estimated to have the failure.

[0031] Then, the generation unit 13 generates failure occurrence estimation information indicating that a failure has been estimated in the linked system 5 (step 103). After that, the output unit 14 outputs the failure occurrence estimation information using a predetermined output method (in other words, a notification mode) (step 104). For example, the output unit 14 may send an email containing the failure occurrence estimation information to the SaaS 3 or SaaS user 7 that is the support target, or may post on a website managed by the support device 1 that a failure has been estimated in the linked system 5.

[0032] As described above, the support device 1 of the first embodiment estimates the occurrence of a failure in the linked system 5 using the operation status information of the multiple SaaS 3 to be supported. In other words, if the linked system 5 is unable to provide services normally due to the occurrence of a failure, the SaaS 3 linked to the linked system 5 will also be unable to provide services (cloud services) normally due to the occurrence of the failure. It is considered that the time from when a failure occurs in the linked system 5 until the multiple SaaS 3 using the linked system 5 are similarly unable to provide services is shorter than the time until the linked system 5 reports the occurrence of the failure. Since the support device 1 estimates the occurrence of a failure in the linked system 5 using such operation status information of the multiple SaaS 3, it can detect (estimate) the occurrence of a failure in the linked system 5 before the linked system 5 reports the occurrence of the failure. Since the support device 1 can report the estimated occurrence of the failure in the linked system 5 to the supported SaaS 3, it is possible to prevent the SaaS 3 from having to perform the work of searching for the cause of the failure even when there is no problem with the SaaS 3, thereby preventing unnecessary work from occurring.

[0033] Furthermore, if SaaS3 is unable to provide services due to a failure in the linked system 5, the support device 1 can quickly inform the SaaS user 7 of the cause, thereby preventing a decline in the SaaS user 7's satisfaction with the service used by SaaS3.

[0034] Second Embodiment A second embodiment according to the present disclosure will be described below. In the description of the second embodiment, components having the same names as those of the cloud service support device (support device) of the first embodiment will be assigned the same reference numerals, and duplicate descriptions of the common components will be omitted.

[0035] 5, the cloud service support device (support device) 1 of the second embodiment includes, in addition to the configuration of the first embodiment, a proxy response unit 17. When the SaaS 3 to be supported becomes unable to provide service, the proxy response unit 17 accepts an inquiry sent to the SaaS 3 and responds to the inquiry on behalf of the SaaS 3.

[0036] That is, when a SaaS 3 in which a failure has occurred is detected using the operation status information of the SaaS 3 acquired by the acquisition unit 11, the proxy reply unit 17 recognizes the SaaS 3 as a target for the proxy reply service. Then, the proxy reply unit 17 accepts an inquiry from the SaaS user 7 to the SaaS 3 that is the target for the proxy reply service via the SaaS 3. Furthermore, the proxy reply unit 17 generates an answer to the inquiry and returns the answer to the SaaS user 7 that made the inquiry. The answer to the inquiry is generated using, for example, chatpot technology (in other words, AI (Artificial Intelligence) technology).

[0037] The support device 1 of the second embodiment has the same configuration as the support device 1 of the first embodiment, and therefore can achieve the same effects as the support device 1 of the first embodiment. Furthermore, the support device 1 of the second embodiment includes a proxy response unit 17. Therefore, the support device 1 of the second embodiment can achieve the following effects. When a failure occurs in SaaS 3 that prevents the provision of service, SaaS 3 wants to allocate human resources to investigating the cause of the failure and performing recovery processing in order to quickly restore the service. Meanwhile, when SaaS 3 is unable to provide service, inquiries from SaaS users 7 due to the inability to provide the service tend to increase. Taking into consideration a decline in service satisfaction, SaaS 3 responds to inquiries from SaaS users 7 in addition to responding to the failure. In other words, even though SaaS 3 wants to allocate limited human resources to failure response and achieve rapid recovery, it must also allocate human resources to responding to inquiries. This reduces the human resources available for failure response, resulting in a slowdown in the progress of recovery work.

[0038] In contrast, the support device 1 of the second embodiment is configured to provide a proxy response service that responds to inquiries to the SaaS 3 on behalf of the failed SaaS 3. Therefore, the SaaS 3 receiving the proxy response service does not have to respond to inquiries that are expected to increase due to the failure, and can allocate human resources to responding to the failure without having to worry about responding to inquiries. This allows the SaaS 3 to focus on investigating the cause of the failure and performing recovery processing, thereby achieving rapid recovery. In other words, the support device 1 of the second embodiment can achieve the effect of allowing the SaaS 3 to focus on recovery work while suppressing a decrease in the service satisfaction of the SaaS user 7 due to the response to inquiries to the failed SaaS 3 through the proxy response unit 17.

[0039] (Variation of the Second Embodiment) In addition to the proxy reply unit 17, the support device 1 may further include an analysis unit 18 as indicated by the dashed line in FIG. 5 . The analysis unit 18 analyzes the content of the inquiry received by the proxy reply unit 17 and uses the analysis results to generate a list of frequently asked questions (FAQs) that summarizes frequently asked questions and their answers. The FAQ information generated by the analysis unit 18 is output to the SaaS 3 to be supported. The SaaS 3 that receives the FAQ information publishes the FAQ on a website managed by the SaaS 3, for example. This can reduce the number of inquiries from SaaS users 7 to the SaaS 3.

[0040] The analysis unit 18 may also generate information other than FAQs using information that can be acquired from inquiries received by the proxy answering unit 17. For example, the analysis unit 18 may tally up words included in inquiries received by the proxy answering unit 17 and generate information ranking the words included in inquiries in descending order of increasing trend in the most recent predetermined period (e.g., one hour). The information generated by the analysis unit 18 in this manner is provided to the SaaS 3 that is the support target.

[0041] Furthermore, it is conceivable that the operator of the support device 1 imposes a usage fee for the proxy response service on the SaaS 3. In this case, the usage fee plan may be a pay-as-you-go plan in which a fee is charged according to the number of inquiries answered by proxy (in other words, the number of transactions). In such a case, the support device 1 is provided with a calculation unit 19 as indicated by the dashed line in FIG. 5 . The calculation unit 19 calculates the usage fee for the proxy response service in the SaaS 3 that uses the proxy response service. That is, fee schedule information for the proxy response service relating to the usage fee for the proxy response service is pre-registered in the storage device 20. Furthermore, if multiple fee plans for the proxy response service are set, fee schedule information corresponding to each fee plan is pre-registered in the storage device 20. Each of the multiple fee schedule information is associated with fee schedule identification information. Furthermore, proxy response service user information, which summarizes the SaaS 3 that use the proxy response service, is pre-registered in the storage device 20. This proxy response service user information includes system identification information of the SaaS3 that uses the proxy response service, and this system identification information is associated with the rate table identification information of the rate plan corresponding to the SaaS3 of the system identification information.

[0042] When the proxy response unit 17 functions (operates), the calculation unit 19 counts the number of inquiries processed in a predetermined fee calculation unit period (e.g., monthly) for each SaaS 3 that provided the proxy response service. Then, at a predetermined timing (e.g., on the first day of each month), the calculation unit 19 reads from the storage device 20 fee schedule information associated with the system identification information of the SaaS 3 for which the fee is to be calculated. Furthermore, the calculation unit 19 calculates the usage fee for the proxy response service for the SaaS 3 for which the fee is to be calculated, using the number of inquiries processed in the fee calculation unit period for the SaaS 3 for which the fee is to be calculated and the read fee schedule information. Furthermore, the calculation unit 19 outputs the calculated usage fee for the proxy response service to the SaaS 3.

[0043] It should be noted that an inquiry reception unit (not shown) may be provided in the support device 1 instead of the proxy reply unit 17. The inquiry reception unit receives an inquiry sent to the SaaS 3 in which a failure has occurred, and displays the content of the received inquiry on, for example, a display device (not shown) connected to the support device 1. In this case, a proxy replyer responds to the inquiry displayed on the display device to the SaaS user 7 on behalf of the SaaS 3. Even when an inquiry reception unit is provided instead of the proxy reply unit 17, the usage fee for the proxy reply service may be calculated by the calculation unit 19.

[0044] <Other Embodiments> The present disclosure is not limited to the first embodiment or the second embodiment, and various embodiments may be employed. For example, FIG. 6 shows the configuration of a cloud service support device (support device) according to another embodiment of the present disclosure. The cloud service support device (support device) 30 is, for example, a computer device, and includes an acquisition unit 31, an estimation unit 32, and an output unit 33 as functional units realized by the computer executing a pre-assigned computer program. The support device 30 is connected to each of multiple SaaS (Software as a Service) 35 that are support targets. The SaaS 35 is a system that provides cloud services. The linkage system 36 is a system that links with the SaaS 35 that are support targets.

[0045] The acquisition unit 31 of the support device 30 acquires operation status information indicating an operation status from each of the plurality of SaaSs 35. When the estimation unit 32 detects a failure in the SaaS 35, it estimates whether a failure has occurred in a linked system linked to the failed SaaS 35, using the operation status information acquired from each of the plurality of SaaSs 35. When it is estimated that a failure has occurred in the linked system, the output unit 33 outputs failure occurrence estimation information indicating that a failure has been estimated in the linked system.

[0046] 7 is a flowchart illustrating an example of the operation of the support device 30. An example of the operation of the support device 30 will be described with reference to this flowchart. For example, the acquisition unit 31 acquires operation status information from each of the multiple SaaSs 35 (step 201). Thereafter, when the estimation unit 32 detects a failure in the SaaS 35, it uses the operation status information acquired from each of the multiple SaaSs 35 to estimate whether a failure has occurred in the linked system linked to the failed SaaS 35 (step 202). Furthermore, when it is estimated that a failure has occurred in the linked system, it outputs failure occurrence estimation information indicating that a failure has been estimated in the linked system (step 203).

[0047] The support device 30 having such a configuration and operation can achieve the effect of being able to detect (estimate) the occurrence of a failure in the linked system to which the SaaS 35 being supported is linked before the linked system reports the occurrence of the failure.

[0048] The present invention has been described above using the above-described embodiments as exemplary examples. However, the present invention is not limited to the above-described embodiments. In other words, the present invention can be applied in various aspects that can be understood by a person skilled in the art within the scope of the present invention.

[0049] This application claims priority based on Japanese Patent Application No. 2023-053223, filed on March 29, 2023, the disclosure of which is incorporated herein in its entirety.

[0050] 1, 30 Support device 3, 35 SaaS 5 Linkage system 7 SaaS user 11, 31 Acquisition unit 12, 32 Estimation unit 14, 33 Output unit 17 Proxy response unit 18 Analysis unit

Claims

1. an acquisition means for acquiring operational status information representing an operational status from each of a plurality of SaaS (Software as a Service); an estimation means for, when detecting a failure in a SaaS, estimating whether a failure has occurred in a linked system linked to the SaaS in which the failure has occurred, using operation status information acquired from each of the plurality of SaaS; an output means for outputting failure occurrence estimation information indicating that a failure has occurred in the linked system when it is estimated that a failure has occurred in the linked system; A cloud service support device comprising:

2. The output means notifies the SaaS in which the failure has occurred of failure occurrence estimation information related to the linked system. The cloud service support device according to claim 1 .

3. The output means notifies the operator of the SaaS in which the failure has occurred of information about the estimated failure of the linked system on a web page that can be viewed by the operator of the SaaS in which the failure has occurred. The cloud service support device according to claim 1 .

4. The estimation means further estimates availability of each of a plurality of functions in the linked system in which a failure is estimated to have occurred, using the operational status information; The output means further outputs information indicating an estimation result of availability of each of a plurality of functions in the linked system in which the occurrence of a failure is estimated. The cloud service support device according to claim 1 .

5. The cloud service support device according to claim 1 , further comprising a proxy response unit that receives an inquiry to the SaaS from a SaaS user who is using the SaaS in which the failure has occurred and responds to the inquiry on behalf of the SaaS in which the failure has occurred.

6. The cloud service support device according to claim 5, further comprising an analysis unit that generates FAQs (Frequently Asked Questions) using an analysis result obtained by analyzing the content of an inquiry from a SaaS user to the SaaS regarding the occurrence of a failure.

7. By computer, Acquires operational status information representing an operational status from each of a plurality of SaaS (Software as a Service); When a failure of a SaaS is detected, operation status information acquired from each of the plurality of SaaS is used to estimate whether a failure has occurred in a linked system linked to the SaaS in which the failure has occurred; If it is estimated that a failure has occurred in the linked system, it outputs failure occurrence estimation information indicating that a failure has occurred in the linked system. Cloud service support method.

8. A process of acquiring operational status information representing an operational status from each of a plurality of SaaS (Software as a Service); When a failure of a SaaS is detected, a process of estimating whether a failure has occurred in a linked system linked to the SaaS in which the failure has occurred, using operation status information acquired from each of the plurality of SaaS; When it is estimated that a failure has occurred in the linked system, a process of outputting failure occurrence estimation information indicating that a failure has occurred in the linked system is estimated. A computer program that causes a computer to execute the following.