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

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.

Description

Technical Field

[0001] This disclosure relates to technologies related to cloud services.

Background Art

[0002] As one of the systems for providing cloud services, there is something called SaaS (Software as a Service). SaaS provides software via an information and communication network (the Internet). SaaS providers who operate such SaaS may use SaaS, PaaS (Platform as a Service), or IaaS (Infrastructure as a Service) provided by another provider in order to execute the software. Both PaaS and IaaS are systems for providing cloud services, but PaaS provides a platform for executing software (application programs) via an information and communication network (the Internet). IaaS provides hardware such as computers (computers) and storage devices for executing software via an information and communication network (the Internet), as well as infrastructure such as communication lines. IaaS is sometimes called HaaS (Hardware as a Service).

[0003] Note that Patent Document 1 (Japanese Unexamined Patent Application Publication No. 2012-89080) relates to a failure analysis device, and in this Patent Document 1, a technique for acquiring the logs of a server and analyzing the cause of an error using the acquired logs when an error occurs in the server is shown. Patent Document 2 (Japanese Unexamined Patent Application Publication No. 2011-90622) relates to an operation status notification system, and in this Patent Document 2, a technique for receiving operation status data from a server and detecting that a failure has occurred in the server using the received operation status data is shown.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

[0005] Incidentally, SaaS cannot directly monitor the operational status of other vendors' SaaS, PaaS, or IaaS (in the following explanation, such other vendors' SaaS, PaaS, and IaaS will also be collectively referred to as "integrated systems"). In other words, SaaS cannot directly obtain log information or other data representing the operational status of integrated systems from those systems and use that information to monitor their operational status. Therefore, SaaS cannot recognize a failure in an integrated system unless that system notifies it of the failure.

[0006] However, when a failure occurs in a linked system, it takes time to check the situation before notifying the system of the failure. In other words, with SaaS, there is a delay between when a failure occurs in a linked system being used and when the system recognizes that failure.

[0007] Thus, SaaS applications cannot immediately detect failures in integrated systems. Therefore, when a SaaS application becomes inoperable due to a failure in an integrated system, it first checks for its own failures because it is unaware of the failure in the integrated system. In other words, even if there is no problem with the SaaS application itself, it has to perform the necessary work to find the cause of the failure within the SaaS application, resulting in wasted effort.

[0008] This disclosure was devised to solve the above-mentioned problems. Specifically, the main purpose of this disclosure is to provide a technology that detects failures in linked systems (SaaS, PaaS, or IaaS from other providers) before those linked systems notify the system of the failure, when a SaaS is using such a system. [Means for solving the problem]

[0009] To achieve the above objective, the cloud service support device relating to this disclosure, in one aspect, An acquisition unit that acquires operational status information representing the operational status from each of multiple SaaS (Software as a Service), When a SaaS failure is detected, an estimation unit uses operational status information obtained from each of the multiple SaaS applications to estimate whether or not a failure has occurred in the linked system that is connected to the affected SaaS. If a failure is estimated to have occurred in the linked system, the output unit outputs failure estimation information indicating that a failure has been estimated in the linked system. It is equipped with.

[0010] Furthermore, the cloud service support method related to this disclosure is, as one aspect thereof, By computer, We obtain operational status information representing the operational status from each of the multiple SaaS (Software as a Service) applications. When a SaaS failure is detected, operational status information obtained from each of the multiple SaaS applications is used to estimate whether or not a failure has occurred in the linked system that is connected to the affected SaaS. If a failure is suspected in the linked system, failure estimation information indicating that a failure in the linked system has been suspected will be output.

[0011] Furthermore, the computer program relating to this disclosure, in one aspect, The process involves obtaining operational status information representing the operational status from each of multiple SaaS (Software as a Service) applications, When a SaaS failure is detected, the system uses operational status information obtained from multiple SaaS applications to estimate whether or not a failure has occurred in the linked system that is connected to the affected SaaS. If a failure is estimated to have occurred in the linked system, the system will output failure estimation information indicating that a failure has been estimated in the linked system. Have the computer execute it. [Effects of the Invention]

[0012] According to this disclosure, when a SaaS uses an integrated system, it can detect a failure in the integrated system before the integrated system notifies the system of the failure. [Brief explanation of the drawing]

[0013] [Figure 1] This figure illustrates one embodiment of the cloud service support device (support device) related to this disclosure. [Figure 2] This diagram illustrates an example of the connection relationship between a support device and the supported SaaS application. [Figure 3] This diagram illustrates an example of an output mode in which a support device outputs fault estimation information. [Figure 4] This is a flowchart illustrating an example of operation in an assistive device. [Figure 5] This figure illustrates another embodiment of the cloud service support device (support device) related to this disclosure. [Figure 6] This diagram illustrates the configuration of a cloud service support device (support device) in another embodiment. [Figure 7] This is a flowchart illustrating an example of operation in a support device of another embodiment. [Modes for carrying out the invention]

[0014] Embodiments according to the present disclosure will be described below with reference to the drawings.

[0015] <First Embodiment> The cloud service support device according to the first embodiment of the present disclosure (hereinafter also simply referred to as the support device) is a device that provides support services for SaaS (Software as a Service). SaaS is a system that provides software via an information communication network (Internet) as a cloud service. Here, people 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 the SaaS 3 to be supported that provides support services. In the example of FIG. 1, for convenience, the number of SaaS 3s connected to the support device 1 is one, but in reality, the number of SaaS 3s to be supported connected to the support device 1 is plural as shown in FIG. 2. Those SaaS 3s to be supported use cloud services provided by a cooperation system (SaaS, IaaS, or PaaS by another operator).

[0017] The support service provided by the support device 1 to the SaaS 3 is a service that notifies the occurrence of a failure in the cooperation system 5 before the cooperation system 5 notifies the occurrence of the failure when a failure occurs in the cooperation system 5 used by the SaaS 3.

[0018] Support device 1 has a configuration (function) that provides a fault notification service for such a linked system 5 to the supported SaaS3. Support device 1 is a computer device and, as shown in Figure 1, comprises a control device 10 and a storage device 20. The storage device 20 has a storage medium for storing data and computer programs (hereinafter also referred to as programs) 21. There are many types of storage devices, such as magnetic disk devices and semiconductor memory elements, and furthermore, there are many types of semiconductor memory elements, such as RAM (Random Access Memory) and ROM (Read Only Memory). The types and number of storage devices 20 provided by support device 1 are not limited and their explanation is omitted. Also, if support device 1 is equipped with multiple types of storage devices 20, they will be collectively referred to as storage device 20.

[0019] The control device 10 is composed of a processor such as a CPU (Central Processing Unit). The control device 10 can perform various functions based on the program 21 stored in the storage device 20 by reading and executing the program 21. In this case, the control device 10 has an acquisition unit 11, an estimation unit 12, a generation unit 13, and an output unit 14 as a functional unit that provides a fault notification service for the linked system 5.

[0020] The acquisition unit 11 acquires operational status information from each of the multiple SaaS3s being supported. The operational status information represents the operational status of the SaaS3 and includes at least information on whether processing using the linked system 5 is working correctly. The storage device 20 stores an operational status history information file for each SaaS3 being supported, and the acquisition unit 11 adds the acquired operational status information to the operational status history information file for each SaaS3 being supported. The timing at which the acquisition unit 11 acquires operational status information from each of the multiple SaaS3s being supported may be set as appropriate by the operator of the support device 1, but for example, it may be set to acquire at pre-set time intervals. In such a case, if there is a SaaS3 from which operational status information could not be acquired at the acquisition timing for some reason, the acquisition unit 11 adds information indicating a failure to the operational status information file in the storage device 20 as operational status information related to that SaaS3.

[0021] The estimation unit 12 uses the acquired operational status information to determine whether or not a failure has occurred in SaaS3. Furthermore, if the estimation unit 12 detects a SaaS3 that is experiencing a failure, it uses the operational status information acquired from each of the multiple SaaS3s to estimate whether or not a failure has occurred in the linked system 5 that is connected to the SaaS3 that has detected a failure. 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, the storage device 20 of the support device 1 has user information about the SaaS 3 to be supported pre-registered. The user information includes basic user information such as the username, address, and contact information to identify the SaaS to be supported, as well as related system information representing the linked system 5 with which SaaS 3 is connected.

[0023] The estimation unit 12 refers to user information registered in the storage device 20 and searches for commonalities among the multiple SaaS3 experiencing failures. If it detects that the use of the same integrated system 5 is common to a predetermined percentage or number of the SaaS3 experiencing failures, the estimation unit 12 estimates that the integrated system 5 common to those failing SaaS3s is experiencing a failure. Using this estimation result, the estimation unit 12 estimates whether or not a failure has occurred in the integrated system 5 connected to each of the failing SaaS3s.

[0024] The estimation unit 12 may further detect common characteristics among a predetermined percentage or number of SaaS3s experiencing failures, such as proximity in location. In this case, the estimation unit 12 estimates the occurrence of communication failures in the regions where those failing SaaS3s are located.

[0025] The estimation unit 12 can also estimate the following matters regarding the linked system 5, which is estimated to be experiencing a failure. In this case, the operational status information obtained from SaaS3 will further include application processing status information. Application processing status information is information that represents the processing status by the application program (app) that provides services to the SaaS user 7. The estimation unit 12 extracts multiple application processing status information related to the linked system 5, which is estimated to be experiencing a failure, from the application processing status information of the operational status information obtained from multiple SaaS3 by the acquisition unit 11. Then, the estimation unit 12 analyzes the extracted application processing status information to estimate the availability of each of the multiple functions in the linked system 5. Specifically, for example, suppose 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 the authentication function that determines permission to access the database. Another function related to the database is the data writing function. Furthermore, another function related to the database is the data reading function. In such cases, the estimation unit 12 can make estimations such as that, for the linked system 5 where a failure is estimated to have occurred, 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 inform SaaS3 and SaaS user 7 of the estimation result (i.e., information indicating that a failure has been estimated in the linked system 5) as failure estimation information. The form of the failure estimation information generated by the generation unit 13 corresponds to a predetermined notification form that informs the estimation result by the estimation unit 12. For example, if email is used as the notification form, the generation unit 13 generates an email body as failure estimation information that represents the content of the estimation result by the estimation unit 12. If a website is used as the notification form, the generation unit 13 generates failure estimation information to be posted on the website in order to change the posted content displayed on the website according to the estimation result by the estimation unit 12. When using a website, the support device 1 may also notify SaaS3 and SaaS user 7 of the new information regarding the operation of the linked system 5 by sending an email to them. In such cases, the generation unit 13 also generates the email body of that email.

[0027] The output unit 14 outputs the fault estimation information generated by the generation unit 13 using an output method corresponding to the predetermined notification method as described above. For example, the output unit 14 notifies (sends) the fault estimation information to SaaS3 via email. The output unit 14 may also send the fault estimation information to SaaS user 7 via email, in which case SaaS3 provides the output unit 14 with the contact information (email address information) of SaaS user 7. Alternatively, the email sent from the output unit 14 to SaaS3 is configured to be forwarded to SaaS user 7 by SaaS3. The output destinations for the fault estimation information output by the output unit 14 may be limited to SaaS3 and its SaaS user 7 that are using the linked system 5 where a fault is estimated to have occurred, or they may be all SaaS3 and their SaaS user 7 that are being supported. The output destinations for the fault estimation information output by the output unit 14 may be set as appropriate by the operator of the support device 1.

[0028] Furthermore, as another method for outputting fault estimation information by the output unit 14, it is conceivable to use a website, as described above. For example, a website is generated by the operator of the support device 1, and within this website, a web page corresponding to each SaaS3 is generated. This web page is accessible to the operator of at least one of the SaaS3 users 7 who is connected to the corresponding SaaS3. On such a web page for each SaaS3, the output unit 14 outputs fault estimation information, for example, as shown in Figure 3. In the example in Figure 3, web page 8 shows the name of the corresponding SaaS3 and the operating status of the linked system 5 with which the SaaS3 is connected. Furthermore, web page 8 shows 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 thought to be useful to the SaaS3 and SaaS user 7 experiencing a failure in the linked system 5, and is not limited to information that informs of other linked systems 5 that are operating normally, as shown in the example in Figure 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 notification service in the support device 1 will be explained using Figure 4. Figure 4 is a flowchart illustrating an example of the operation related to the fault notification service in the support device 1.

[0030] For example, the acquisition unit 11 acquires operational status information from each of the multiple SaaS3s to be supported (step 101 in Figure 3). Then, using the operational status information acquired from each of the multiple SaaS3s to be supported, the estimation unit 12 determines whether or not there is a SaaS3 that is experiencing a failure. If a SaaS3 that is experiencing a failure is detected, the estimation unit 12 uses the acquired operational status information to estimate whether or not there is a failure in the linked system 5 that the SaaS3 is connected to (step 102). If it is estimated that there is a failure in the linked system 5, the estimation unit 12 further estimates the availability of each of the functions of the linked system 5 that is estimated to be experiencing a failure.

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

[0032] As described above, the support device 1 of the first embodiment estimates the occurrence of a failure in the linked system 5 using operational status information of multiple SaaS3s that are being supported. In other words, if the linked system 5 becomes unable to provide services normally due to a failure, the SaaS3s that are linked to the linked system 5 will also be unable to provide services (cloud services) normally due to that failure. The time from when a failure occurs in the linked system 5 until multiple SaaS3s using the linked system 5 become unable to provide services is considered to be shorter than the time it takes for the linked system 5 to notify of the failure. Since the support device 1 estimates the occurrence of a failure in the linked system 5 using operational status information of multiple SaaS3s, it can detect (estimate) the occurrence of a failure in the linked system 5 before the linked system 5 notifies of the failure. Since the support device 1 can notify the supported SaaS3s of the failure in the linked system 5 that has been estimated in this way, it is possible to suppress the situation in which the SaaS3s have to perform work to find the cause of the failure even though there is no problem with the SaaS3, which would result in unnecessary work.

[0033] Furthermore, if SaaS3 is unable to provide its service 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 SaaS3.

[0034] <Second Embodiment> A second embodiment relating to this disclosure is described below. In the description of the second embodiment, the same reference numerals are used for components that have the same names as those of the cloud service support device (support device) of the first embodiment, and redundant explanations of these common parts are omitted.

[0035] The cloud service support device (support device) 1 of the second embodiment, as shown in Figure 5, is equipped with a proxy response unit 17 in addition to the configuration of the first embodiment. The proxy response unit 17 receives inquiries directed to the SaaS3 when the SaaS3 to be supported becomes unable to provide its service, and responds to those inquiries on behalf of the SaaS3.

[0036] In other words, when the operational status information of SaaS3 acquired by the acquisition unit 11 is detected to be causing a failure in SaaS3, the proxy response unit 17 recognizes that SaaS3 as a target for the proxy response service. The proxy response unit 17 then receives inquiries from SaaS users 7 to the SaaS3 targeted for the proxy response service via that SaaS3. Furthermore, the proxy response unit 17 generates an answer to that inquiry and sends that answer back to the SaaS user 7 who made the inquiry. The answer to that inquiry is generated using, for example, chatbot 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 is equipped with a proxy answering unit 17. For this reason, the support device 1 of the second embodiment can achieve the following effects. That is, when a failure occurs in SaaS3 that prevents the service from being provided, SaaS3 would like to allocate human resources to investigating the cause of the failure and the recovery process in order to recover quickly. On the other hand, when SaaS3 is unable to provide the service, there is a tendency for inquiries from SaaS users 7 due to the inability to use the service to increase. SaaS3 takes into consideration the decrease in service user satisfaction and responds not only to failure response but also to inquiries from SaaS users 7. In other words, even though SaaS3 wants to allocate limited human resources to failure response in order to recover quickly, it must also allocate human resources to responding to inquiries. This results in a situation where human resources for failure response are reduced, and the progress of work related to recovery is slowed down.

[0038] In contrast, the support device 1 of the second embodiment is configured to provide a proxy answering service that answers inquiries to the malfunctioning SaaS3 on behalf of the SaaS3. As a result, the SaaS3 receiving the proxy answering service does not have to deal with the inquiries that are expected to increase due to the malfunction, and can allocate human resources to troubleshooting without having to consider responding to inquiries. This allows the SaaS3 to concentrate on investigating the cause of the malfunction and the recovery process, enabling a rapid recovery. In other words, the support device 1 of the second embodiment, through the proxy answering unit 17, can suppress the decline in service satisfaction of SaaS users 7 caused by responding to inquiries to the malfunctioning SaaS3, while allowing the SaaS3 to concentrate on recovery work.

[0039] (Modified version of the second embodiment) In addition to the proxy answering unit 17, the support device 1 may also be equipped with an analysis unit 18, as shown by the dashed line in Figure 5. The analysis unit 18 analyzes the content of inquiries received by the proxy answering unit 17 and uses the results of this analysis to generate an FAQ (Frequently Asked Questions) that summarizes frequently asked questions and their answers. The FAQ information generated by the analysis unit 18 is output to the SaaS3 being supported. The SaaS3 that receives the FAQ information can, for example, publish the FAQ on a website managed by the SaaS3. This can reduce the number of inquiries from SaaS users 7 to the SaaS3.

[0040] Furthermore, the analysis unit 18 may generate information other than FAQs using information obtained from inquiries received by the proxy answering unit 17. For example, the analysis unit 18 may aggregate the words included in inquiries received by the proxy answering unit 17 and generate ranking information in descending order of the rate of increase of words included in inquiries over the most recent predetermined period (e.g., 1 hour). The information generated by the analysis unit 18 in this way is provided to the supported SaaS3.

[0041] Furthermore, it is conceivable that the operator of support device 1 may charge SaaS3 a fee for using the proxy answering service. In this case, the fee plan may be a pay-per-use plan where the fee is charged according to the number of inquiries answered (in other words, the number of processes). In such cases, support device 1 is equipped with a calculation unit 19 as shown by the dashed line in Figure 5. The calculation unit 19 calculates the usage fee for the proxy answering service in SaaS3 that uses the proxy answering service. That is, fee schedule information for the proxy answering service regarding the usage fee for the proxy answering service is pre-registered in the storage device 20. Also, if multiple fee plans are set for the proxy answering service, 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. In addition, proxy answering service user information, which summarizes the SaaS3s that use the proxy answering service, is pre-registered in the storage device 20. This proxy response service user information includes the system identification information of the SaaS3 that uses the proxy response service, and this system identification information is associated with the price list identification information of the corresponding pricing plan for that SaaS3.

[0042] When the proxy answering unit 17 is functioning (operating), the calculation unit 19 counts the number of queries processed for each SaaS3 that provided the proxy answering service during a predetermined billing period (e.g., monthly). Then, at a predetermined time (e.g., on the 1st of each month), the calculation unit 19 reads the pricing information associated with the system identification information of the SaaS3 subject to billing from the storage device 20. Furthermore, the calculation unit 19 uses the number of queries processed during the billing period in the SaaS3 subject to billing and the read pricing information to calculate the usage fee for the proxy answering service in the SaaS3 subject to billing during that billing period. Finally, the calculation unit 19 outputs the calculated usage fee for the proxy answering service to the SaaS3.

[0043] Alternatively, an inquiry reception unit (not shown) may be provided in the support device 1 instead of the proxy response unit 17. The inquiry reception unit receives inquiries directed to the SaaS 3 experiencing a failure and displays the content of the received inquiries on a display device (not shown) connected to the support device 1. In this case, the proxy responder answers the inquiries displayed on the display device on behalf of the SaaS 3 to the SaaS user 7. Even if an inquiry reception unit is provided instead of the proxy response unit 17, the usage fee for the proxy response service may be calculated by the calculation unit 19.

[0044] <Other Embodiments> This disclosure is not limited to the first or second embodiments, and various forms of implementation are possible. For example, Figure 6 shows the configuration of a cloud service support device (support device) of another embodiment related to this disclosure. This 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-provided computer program. The support device 30 is connected to each of the multiple SaaS (Software as a Service) 35 to be supported. The SaaS 35 is a system that provides cloud services. The collaboration system 36 is a system that collaborates with the SaaS 35 to be supported.

[0045] The acquisition unit 31 of the support device 30 acquires operational status information representing the operational status from each of the multiple SaaS 35. When the estimation unit 32 detects a failure in a SaaS 35, it uses the operational status information acquired from each of the multiple SaaS 35 to estimate whether or not a failure has occurred in the linked system that is linked to the failed SaaS 35. If the output unit 33 estimates that a failure has occurred in the linked system, it outputs failure estimation information indicating that a failure has been estimated in the linked system.

[0046] Figure 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 explained with reference to this flowchart. For example, the acquisition unit 31 acquires operational status information from each of the multiple SaaS 35 (step 201). Subsequently, if the estimation unit 32 detects a failure in SaaS 35, it uses the operational status information acquired from each of the multiple SaaS 35 to estimate whether or not a failure has occurred in the linked system that is linked to the failed SaaS 35 (step 202). Furthermore, if it is estimated that a failure has occurred in the linked system, it outputs failure estimation information indicating that a failure has been estimated in the linked system (step 203).

[0047] The support device 30, which performs this configuration and operation, has the effect of being able to detect (estimate) a failure in the linked system with which the supported SaaS 35 is linked, before the linked system notifies the occurrence of the failure.

[0048] The present invention has been described above using the embodiments described above as exemplary examples. However, the present invention is not limited to the embodiments described above. That is, the present invention can be applied in various forms that can be understood by those 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 29 March 2023, and incorporates all of its disclosures herein. [Explanation of symbols]

[0050] 1,30 Support equipment 3.35 SaaS 5. Integration System 7 SaaS users 11,31 Acquisition Department 12,32 Estimation part 14,33 Output section 17 Agency Answer Department 18 Analysis Department

Claims

1. A means for acquiring operational status information representing the operational status from each of multiple SaaS (Software as a Service) applications, When a SaaS failure is detected, an estimation means is used to estimate whether or not a failure has occurred in the linked system that is connected to the failed SaaS, using operational status information obtained from each of the multiple SaaS instances. If a failure is estimated to have occurred in the linked system, an output means outputs failure estimation information indicating that a failure has been estimated in the linked system. A cloud service support device equipped with the following features.

2. The output means notifies the SaaS experiencing the failure of estimated failure information regarding the linked system. The cloud service support device according to claim 1.

3. The output means notifies the operator of the SaaS experiencing the failure of the linked system of estimated failure information on a web page accessible to the operator of the SaaS experiencing the failure. The cloud service support device according to claim 1.

4. The estimation means further estimates the availability of each of the multiple functions in the linked system that is presumed to be experiencing a failure, using operational status information. The output means further outputs information representing the estimated availability of each of the multiple functions in the linked system where a failure is suspected. The cloud service support device according to claim 1.

5. The cloud service support device according to claim 1, further comprising a proxy response means that receives inquiries from SaaS users using the SaaS experiencing a failure and responds to those inquiries on behalf of the SaaS experiencing the failure.

6. The cloud service support device according to claim 5, further comprising an analysis means for generating FAQs (Frequently Asked Questions) using the analysis results obtained from analyzing the content of inquiries to the SaaS regarding failures from SaaS users.

7. By computer, We obtain operational status information representing the operational status from each of the multiple SaaS (Software as a Service) applications. When a SaaS failure is detected, operational status information obtained from each of the multiple SaaS instances is used to estimate whether or not a failure has occurred in the linked system that is connected to the failed SaaS. If a failure is suspected in the linked system, failure estimation information indicating that a failure in the linked system has been suspected will be output. Cloud service support methods.

8. The process involves obtaining operational status information representing the operational status from each of multiple SaaS (Software as a Service) applications, When a SaaS failure is detected, the system uses operational status information obtained from each of the multiple SaaS instances to estimate whether or not a failure has occurred in the linked systems that are connected to the failed SaaS. If a failure is estimated to have occurred in the linked system, the system will output failure estimation information indicating that a failure has been estimated in the linked system. A computer program that causes a computer to execute a command.

Images