JP2018046422A - Fault notification device and fault notification system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To restrict a user with a low possibility to perform access till a fault is recovered from being notified compared with a case where all the users are notified of occurrence of a fault.SOLUTION: A fault notification system includes: a service information acquisition section for acquiring a history of access by a user; and an object user identification section for identifying a notification object user being a user to be an object to be notified of occurrence of a fault on the basis of a mode of access by a user included in the history when a fault occurs in a service to be provided to a user. The object user identification section identifies an object user by estimating a time till a fault is recovered.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a failure notification device and a failure notification system.

  In Patent Document 1, the error detection unit detects the possibility of an error from the activation time acquired by the information acquisition unit and the history of the activation time acquired in the past recorded in the history recording unit, and the detected state Accordingly, there is described a support information presenting device that can detect the possibility of occurrence of an error that could not be detected in the past by presenting it in the information presenting unit and provide support information.

JP 2008-250390 A

  By the way, when a failure occurs in the service provided to the user, the occurrence of the failure may be notified to the user by e-mail or the like, for example. On the other hand, depending on how the user uses the service, a notification that is less necessary for the user may be received.

  Therefore, in the present invention, compared to the case where all users are notified that a failure has occurred, the object is to suppress notification to users who are less likely to access before the failure is recovered. To do.

According to the first aspect of the present invention, when a failure occurs in a history acquisition unit that acquires a history of access by a user and a service provided to the user, the failure is determined based on a mode of access by the user included in the history. This is a failure notification device having a specifying unit that specifies a notification target user who is a user who is a target of notification of occurrence of the error.
The invention according to claim 2 includes an estimation unit that estimates a recovery required time that is a time required for recovery of the failure, and the specifying unit includes the recovery required time estimated by the estimation unit, and the user The failure notification device according to claim 1, wherein the notification target user is specified based on an access mode according to claim 1.
The invention according to claim 3 includes a failure information storage unit that stores a history of failures that have occurred in the service, and stores an elapsed time from the occurrence of each failure until recovery, and the estimation unit includes: The failure notification device according to claim 2, wherein the recovery time is estimated based on the elapsed time.
The invention according to claim 4, wherein the history acquisition unit stores an access time that is a time when access is received from a specific user, and the specific unit has generated the failure based on the access time. 4. The failure notification device according to claim 1, wherein it is determined whether to notify the specific user.
According to a fifth aspect of the present invention, when the information related to the service is notified to the user before the failure occurs, the specifying unit includes the user who is notified of the information as the notification target user. The fault notification device according to claim 1.
In the invention according to claim 6, the notification of the information includes information on an access destination related to the service, and the specifying unit is configured to respond to the notification of the information among the users who are notified of the information. 6. The failure notification device according to claim 5, wherein a user who has accessed the access destination is specified, and the specified user is included in the notification target user.
The invention according to claim 7 is a history acquisition unit that acquires a history of access by a user, and an access that acquires information related to an access mode by a user included in the history when a failure occurs in a service provided to the user. An aspect acquisition unit, an estimation unit for estimating a recovery time required for recovery of the failure, the access mode acquired by the access mode acquisition unit, and the recovery time estimated by the estimation unit Based on the identification unit for identifying the notification target user, which is a user to be notified of the occurrence of the failure, and when the information about the service has been notified to the user before the failure occurs, The user who notified the information is specified, and the notification target user specified by the specifying unit is updated based on the specified user A failure notification apparatus and a that updating unit.
The invention according to claim 8 is a history acquisition unit that acquires a history of access by a user, a provision unit that provides a predetermined service to the user, and a user included in the history when a failure occurs in the service It is a failure notification system having a specifying unit for specifying a notification target user, which is a user who is a target of notification that the failure has occurred, based on an access mode.

According to the first aspect of the present invention, it is possible to suppress notification to a user who is unlikely to access before the failure is restored, as compared to the case where all the users are notified that a failure has occurred. Can do.
According to the second aspect of the present invention, it is possible to more accurately identify a user who has a low possibility of accessing before the failure is recovered.
According to the third aspect of the present invention, it is possible to more accurately identify a user who has a low possibility of accessing before the failure is recovered.
According to the fourth aspect of the present invention, it is possible to more accurately identify a user who is less likely to access before the failure is recovered, based on the history of user access time.
According to the fifth aspect of the present invention, it is possible to more reliably include users who have a high possibility of receiving information notification and accessing them.
According to the sixth aspect of the present invention, it is possible to more reliably include users who have a high possibility of receiving an information notification and accessing them.
According to the seventh aspect of the present invention, it is possible to suppress notification to a user who is unlikely to be accessed before the failure is restored, compared to a case where all the users are notified that a failure has occurred. Can do.
According to the eighth aspect of the present invention, it is possible to suppress the notification to the user who is unlikely to access before the failure is restored, compared to the case where all the users are notified that the failure has occurred. Can do.

It is the figure which showed the example of whole structure of the failure notification system with which this Embodiment is applied. It is a figure for demonstrating the structural example of a server. It is the flowchart which showed the operation example of the server. (A) thru | or (f) is a figure for demonstrating the information regarding operation | movement of a server. It is the figure which showed the hardware structural example of the server.

Embodiments of the present invention will be described below with reference to the accompanying drawings.
<Failure notification system 1>
FIG. 1 is a diagram showing an example of the overall configuration of a failure notification system 1 to which the embodiment is applied.
The failure notification system (service system, failure notification device) 1 includes a client group 10 including a first client 11, a second client 12, and a third client 13, a server 20, and a help desk 30. The client group 10 and the server 20 are connected via a network 40. The help desk 30 is connected to the server 20.

  Each of the first client 11 to the third client 13 configuring the client group 10 is configured by a computer device such as a desktop computer, a notebook computer, a tablet computer, or a smartphone. The first client 11 to the third client 13 are not limited to so-called computer devices, but are image forming devices that form images on paper, reading devices that read images formed on paper, or image forming and image forming devices. It may be a multi-function machine having a plurality of functions such as reading and FAX. In the illustrated example, the client group 10 is composed of three clients, but the number of clients is not limited to this.

The server 20 is configured by a computer device. The server 20 according to the present embodiment has a function of detecting that a failure has occurred in a service (user service) for a user provided to the first client 11 to the third client 13 and notifying the user. .
The service here is not particularly limited as long as it is a service provided via the network 40. The entity (provider or provider) that provides this service may be the server 20 or a computer device other than the server 20 included in the network 40.

The help desk 30 supports users of the first client 11 to the third client 13. For example, the help desk 30 includes an information terminal device (not shown), responds to inquiries by e-mail or telephone from the user, and performs advertisements and reports to the user by e-mail or telephone.
The help desk 30 includes a computer device having various databases in which information necessary for supporting a user is stored. In addition, this help desk 30 may respond to the inquiry from a user, etc., while an operator (help desk person in charge) uses an information terminal device.
In the illustrated example, the help desk 30 is connected to the server 20, but may be connected to the network 40.

<Server 20>
<Configuration Example of Server 20>
FIG. 2 is a diagram for explaining a configuration example of the server 20.
Next, a configuration example of the server 20 will be described with reference to FIGS. 1 and 2.
The server 20 according to the present embodiment includes an input / output unit 201, a service monitoring unit 203, a service information acquisition unit 205, a failure detection unit 207, a help desk information acquisition unit 209, a user contact unit 211, a target user The identification unit 213, the access history storage unit 221, the user attribute storage unit 223, the failure information storage unit 225, and the help desk information storage unit 227 are included.

The input / output unit 201 inputs / outputs various data to / from the network 40.
The service monitoring unit 203 monitors services provided to the first client 11 to the third client 13 via the network 40. In the following description, a service to be monitored by the service monitoring unit 203 may be referred to as a monitoring target service.

  A service information acquisition unit 205, which is an example of a history acquisition unit, acquires information about the monitored service via the service monitoring unit 203. More specifically, the service information acquisition unit 205 acquires access history information and user attribute information. The service information acquisition unit 205 is an example of an access mode acquisition unit.

Here, the access history information is information relating to a history of a user (an example of a specific user) accessing a monitored service website (access destination) or the like.
Specifically, the access history information is information relating to the time when the user accesses the website of the monitored service, the frequency of access, the access route, the screen (display screen) confirmed by the user at the time of access, and the like. The access time may be not only the access time (hour and minute) itself, but also time classification such as time zone (for example, morning, afternoon, early morning, late night), in other words, information on time.

  The access history information is sent when a mail such as a promotion (promotion) is sent from the help desk 30 (details will be described later), and the user who receives the mail accesses or accesses the website. Contains information about how long it takes to access the website later. The information on the access route includes information on an access route (for example, a link destination URL) included in the transmitted mail.

The user attribute information is information related to the user attributes of the monitored service.
Specifically, the user attribute information requires a user name (name), a type of service to be monitored, a screen (operation screen) that can be referred to by the user, a notification method to the user when a failure occurs, and special handling. In the case of a user (premium user, exclusive dealer), information on the type and the like is included. As a method for notifying a user, for example, an alert (pop-up) is displayed on a service screen in addition to a telephone call or an email. These notification methods may be individually set according to the influence degree (service influence degree) of the failure that has occurred. In addition, the users who need special handling include users who need to be contacted regardless of the service impact level (failure impact level) when a failure occurs.

The failure detection unit 207 detects the occurrence of a failure in the monitored service via the service monitoring unit 203 and acquires failure information that is information about the failure that has occurred.
The failure information includes failure details, failure target screen, failure occurrence time (failure occurrence time), failure recovery time (recovery time), time taken from failure occurrence to recovery (failure recovery time, Elapsed time) etc. Note that the failure occurrence time and the failure recovery time may be not only the time itself but also a time division such as a time zone (for example, morning, afternoon, early morning, midnight).

Here, the failure content is information relating to the type of failure that has occurred, for example, information for distinguishing between failure and unarrival of a captured file, or other failure.
The failure target screen is a screen (operation screen) displayed on the client where the failure has occurred. In other words, it is a screen on which a problem has occurred in service provision.

As a failure in the monitored service, for example, when the first client 11 to the third client 13 are multifunction devices, there is an abnormality in the consumable data used in the multifunction device, and the data related to the consumables is displayed on the service screen. It may not be displayed.
In addition, failure detection or recovery (convergence) by the failure detection unit 207 is detected by re-execution of a batch or manual operation (for example, click) by a user.

  Further, if the server 20 can detect that a failure has occurred, the server 20 does not have to include the failure detection unit 207 (and the service monitoring unit 203), unlike the illustrated example. For example, a computer device (not shown) other than the server 20 included in the network 40 may have the function of the failure detection unit 207. And when this computer apparatus detects a failure, while outputting a signal, the server 20 may receive this output signal.

  The help desk information acquisition unit 209 acquires help desk information that is information related to support by the help desk 30. Specifically, the help desk information is mail information (mail issue information) that is information about mail sent from the help desk 30 to the user, or information about complaints (feedback) received by the help desk 30 from the user. Contains some complaint information. This mail information includes the date and time of mail transmission, the type (content) of the mail, the presence / absence of information on the access destination (for example, the URL of the link destination) in the mail text, and the access information (access information of the access destination included in the mail text) Presence, access time, access frequency (number of times)).

Note that the type of mail transmitted from the help desk 30 to the user is not particularly limited as long as the received user is an opportunity to use the service. For example, as this type, there are an advertisement mail of a service to be provided, a contact mail of a report (report) regarding a service to be provided such as data update and maintenance.
The complaint information includes information such as the date and time when the help desk 30 received the complaint or the content of the complaint.

  The user contact unit 211 performs contact with the user after a failure occurs via the input / output unit 201. The user contact unit 211 has service screen information that is information displayed on display means (screen, not shown) of the first client 11 to the third client 13. Further, the user contact unit 211 holds template information such as an email sent to the user when a failure occurs. And based on the information which the user contact part 211 hold | maintains, the user contact part 211 performs a contact (notification) to a user. In addition, the user contact unit 211 creates and stores a notification list that is a list of users who have made notifications. Note that the execution of contact to the user by the user contact unit 211 may be triggered by an operation by the operator of the server 20. Moreover, the aspect which assists the communication by an operator by the user contact part 211 may be sufficient. Alternatively, the user may be contacted by a computer device (not shown) other than the server 20.

  The target user specifying unit 213 which is an example of the specifying unit and the estimating unit collects part or all of the above information (monitoring target service, user attribute information, failure information, access history information, help desk information), etc. analyse. More specifically, the target user specifying unit 213 specifies a user (target user, notification target user) to be notified of the occurrence of a failure based on the above information (details will be described later).

The access history storage unit 221 stores the access history information acquired by the service information acquisition unit 205.
The user attribute storage unit 223 stores the user attribute information acquired by the service information acquisition unit 205.
The failure information storage unit 225 stores failure information related to the failure detected by the failure detection unit 207.
The help desk information storage unit 227 stores the help desk information acquired by the help desk information acquisition unit 209.

  Here, the failure information storage unit 225 accumulates (updates) the failure information every time a failure occurs. More specifically, the failure information storage unit 225 calculates and stores an average value (average recovery time) of failure recovery times for each failure content, for example, when failure information is updated. Further, the failure information storage unit 225 stores a reference recovery time for each failure content. This reference recovery time is a time used as an alternative to the average recovery time when the number of cases stored in the failure information storage unit 225 is small (for example, two or less), and a predetermined time is set. . Note that this reference recovery time is arbitrarily determined, and may be uniformly determined for all failure contents in addition to the aspect previously determined for each failure content. Here, the failure recovery time is an example of the time required for recovery.

  The failure detection unit 207 can be understood as a means for determining a service that is affected when a failure occurs. Further, the failure detection unit 207 and the user contact unit 211 can be regarded as means for detecting and notifying a failure. In addition, the target user identification unit 213 predicts the time until the failure is converged when a failure occurs in the service, or narrows down users who have access within the time predicted from the access history, or a failure occurs. It can be understood as a means for predicting the access rate and time after mail transmission from the access history.

  Further, the target user specifying unit 213 and the user contact unit 211 can be regarded as means for making an announcement (notification) to the user depending on the level of failure. The access history storage unit 221 can be regarded as a means for storing an access history of a user's service. Further, the failure information storage unit 225 can be regarded as a means for storing the time until the failure occurrence and convergence of the service. The help desk information storage unit 227 can be regarded as a means for storing a history of transmission of a mail related to support, a link destination, and the like.

<Operation Example of Server 20>
FIG. 3 is a flowchart illustrating an operation example of the server 20.
When a failure occurs in the service provided to the first client 11 to the third client 13, the user may be notified of the failure by e-mail or the like, for example. However, when the relevance between the user who has received the notification and the failure that has occurred is low, the user may feel annoying the notification. Here, the relationship between the failure and the failure is low means that the user does not use the service in which the failure has occurred (the usage frequency is low), and the user uses the service in which the failure has occurred next. In some cases, the timing is after the failure is recovered.

  Therefore, the server 20 in the present embodiment narrows down the users who are notified of the occurrence of the failure according to the time (time zone) when the failure occurred. More specifically, the failure recovery time is estimated (predicted), and the necessity of notifying the occurrence of the failure is determined for each user based on the failure recovery time. Note that by predicting the failure recovery time, the user who should be notified of the occurrence of the failure can be identified more accurately.

Hereinafter, an operation example of the server 20 will be described with reference to FIGS. 1 to 3.
Here, it is assumed that the monitoring target service is provided in the first client 11 to the third client 13. In addition, it is assumed that the failure detection unit 207 of the server 20 monitors whether there is a failure in the monitored service.

  First, when the failure detection unit 207 of the server 20 detects that a failure has occurred in the monitored service (YES in step 301), the failure detection unit 207 identifies (acquires) failure information of the failure that has occurred (step 302). ). More specifically, the failure detection unit 207 acquires the failure content specification and failure occurrence time, and stores them in the failure information storage unit 225.

  Next, the target user specifying unit 213 determines whether a failure that matches the specified failure content is stored in the failure information storage unit 225 (step 303). If a failure that matches the specified failure content is stored in the failure information storage unit 225 (YES in step 303), the target user specifying unit 213 indicates that the specified failure content is three or more in the history. It is determined whether it is included (step 304). If three or more cases are included in the history (YES in step 304), the target user specifying unit 213 acquires the average recovery time of the specified failure stored in the failure information storage unit 225 (step). 305). Then, the estimated recovery time is calculated based on the acquired average recovery time and the failure occurrence time acquired in step 302 (step 306).

  On the other hand, when the specified failure content is not stored in the failure information storage unit 225 (NO in step 303), or is not included in the history (NO in step 304), the target user specifying unit 213 Acquires the reference recovery time stored in the failure information storage unit 225 (step 307). Then, the estimated recovery time is calculated based on the acquired reference recovery time and the failure occurrence time acquired in step 302 (step 306).

  Next, the target user specifying unit 213 specifies the target user based on the calculated estimated recovery time (step 308). Although details will be described later, the target user specifying unit 213 can use the monitoring target service in which a failure has occurred by the estimated recovery time based on the information stored in the access history storage unit 221 and the user attribute storage unit 223. Narrow down the number of highly qualified users.

  Next, the target user identification unit 213 determines whether there is a help desk history within a predetermined period based on the help desk information stored in the help desk information storage unit 227 (step 309). For example, the target user specifying unit 213 determines whether an email is transmitted from the help desk 30 to the user in a predetermined period (eg, 24 hours) before the failure occurrence time.

  If there is a help desk history (YES in step 309), the target user identification unit 213 determines whether link destination information is included in the text of the transmitted mail (step 310). If the link destination information is included (YES in step 310), the target user specifying unit 213 updates the target user (step 311). That is, the user of the transmission destination in the mail including the link destination is added to the target user. Then, a target user list that is a list of the specified target users is created (step 312).

  On the other hand, when there is no help desk history (NO in step 309), or when link destination information is not included (NO in step 310), the target user specifying unit 213 is based on the target user specified in step 308. Then, a target user list is created (step 312).

  Next, based on the user attribute information stored in the user attribute storage unit 223, the user contact unit 211 determines, for each user included in the target user list, whether the notification method when a failure occurs is email ( Step 313). If the notification method is mail (YES in step 313), the user contact unit 211 transmits a mail notifying that a failure has occurred to the user (step 314).

On the other hand, when the notification method when a failure occurs is not mail (NO in step 313), the user contact unit 211 notifies the occurrence of the failure by a method other than mail (step 315). In the example shown in the drawing, a setting for performing pop-up display on the service screen is performed.
Then, the user contact unit 211 creates and stores a notification list that is a history (list) of notification methods of failure occurrence (step 316).

Next, the failure detection unit 207 determines whether the estimated recovery time has elapsed (step 317). When the estimated recovery time has elapsed (YES in step 317), the failure detection unit 207 determines whether the failure has ended, that is, whether the failure has been recovered (step 318). When the failure is recovered (YES in step 318), the process flow ends.
On the other hand, if the failure has not been recovered (NO in step 318), the process proceeds to step 302. In the failure identification in step 302 after the transition, each processing is performed by replacing the failure occurrence time with the estimated recovery time calculated in step 306 before the transition.

<Processing information of server 20>
4A to 4F are diagrams for explaining information related to the operation of the server 20.
Next, information processed in accordance with the operation of the server 20 will be described with reference to FIGS.
Here, as an example, it is assumed that a failure (hereinafter referred to as a screen failure) due to an interface screen delay occurs in a server (not shown) that provides a multifunction machine service at 4 am on December 25, 2015.

FIG. 4A shows an example of failure information stored in the failure information storage unit 225.
The failure information shown in FIG. 4A is failure history information. Specifically, the failure information includes reference number, failure alert (error code), failure content, occurrence date and time, service influence, and time information. The influence of the service includes a service screen type and a report type. Further, the time includes a failure occurrence time (failure occurrence time) and a failure end time (recovery time).

Here, as described in Step 301 and Step 302 of FIG. 3 above, when the failure detection unit 207 of the server 20 detects the occurrence of a failure, the failure information is acquired and stored in the failure information storage unit 225.
In this example, the screen failure is stored in “NO. 1” (reference number 1) in FIG. This screen failure alert is “A0001”. In the example shown in the figure, the screen failure is immediately after the occurrence of the screen failure, and since the screen failure has not ended yet, the end time is not recorded (see the arrow in the figure).

Here, the screen failure of the alert “A0001” has also occurred about 6 months ago (June 6, 2015) and about 11 months ago (January 20, 2015). In addition, this screen failure has occurred about twice a year, has occurred at 4 am in the past two times, and has been recovered by 10 am.
In addition, the average recovery time of the past two screen failures is “5 hours 48 minutes”. In this case, the estimated recovery time, which is the time when the average recovery time has elapsed from the failure occurrence time, is “5 hours 48 minutes” after “4 am on December 25, 2015”, that is, “December 25, 2015. Day 9:48 am "(see step 306).

FIG. 4B shows an example of user attribute information stored in the user attribute storage unit 223.
The user attribute information shown includes information on the name of the user, the type of service used, the type of screen that can be referred to by the user, and the conditions (premium user, exclusive dealer).
FIG. 4C shows an example of target user information specified by the target user specifying unit 213.

As described in step 308 of FIG. 3 above, the target user identification unit 213 determines the failure information stored in the failure information storage unit 225, the user attribute information stored in the user attribute storage unit 223, and the calculated estimation. The target user is specified based on the recovery time.
In the above example, a user who can access between the failure occurrence time “December 25, 2015 at 4 am” and the estimated recovery time “December 25, 2015 at 9:48 am” Is identified. For example, a user who has accessed the time zone within 30 days is assumed to be an accessible user. In this example, 100 target users are specified.

FIG. 4D shows an example of help desk information stored in the help desk information storage unit 227.
FIG. 4E shows an example of target user information updated by the target user specifying unit 213.

  The help desk information shown in FIG. 4D includes information on the name of the user, the type of mail transmitted to the user, the type of link screen, and the date and time when the link destination was accessed. Note that this help desk information (history) is information related to mail transmitted to the user during a predetermined period before the failure occurrence time, for example.

Here, as described in step 311 of FIG. 3, the target user specifying unit 213 updates the target user based on the help desk information.
In the example of FIG. 4D, the “data update” mail is transmitted to the user “abc” and the user “def”. Then, the user “abc” and the user “def” access the link destination included in the mail transmitted to the user within 3 hours from the mail transmission. Here, assuming that this “data update” mail is transmitted one hour before the failure occurrence time, the user “abc” and the user “def” are mail transmission dates and times, December 25, 2015. There is a possibility of access to “6 am on December 25, 2015” after “3 hours” from 3 am on the day (high possibility). This time is before the above-mentioned estimated recovery time “December 25, 2015, 9:48 am”.

Therefore, it is necessary to specify the user “abc” and the user “def” as target users. Here, in the target user information in FIG. 4C, the user “abc” is included, but the user “def” is not included.
Therefore, as shown in FIG. 4E, the user “def” is added to the target user information (see the arrow in the figure). Here, one target user is added to the 100 people specified in FIG. 4C, and 101 target users are specified.

FIG. 4F shows an example of a notification list created and stored by the user contact unit 211.
As described in step 316 of FIG. 3 above, the user contact unit 211 creates and stores a notification list.
The notification list shown in FIG. 4F includes types of alerts and failure report methods.
Further, in this example, the user contact unit 211 creates a notification list shown in FIG. 4 (f) and stores the information, so that an email with a screen link to be failed cannot be transmitted from the help desk information. Stop function.

  In the above example, by notifying the user of unnecessary information by notifying (developing) useless information by measuring the time and notifying the contents of the failure. That is, failure information is appropriately notified.

  In general, when a failure occurs, the number of contacts (email, telephone) from the user who intends to use the service to the help desk 30 may increase. In this embodiment, the burden on the help desk 30 is reduced by transmitting (notifying) information required by the user in advance to the user when a failure occurs as described above. In other words, the support rate of the help desk 30 can be increased by reducing the burden on the help desk 30.

  As a conventional technique different from the present embodiment, there may be a technique for detecting in advance the possibility of a failure or automatically providing appropriate information to a user. However, unlike these techniques, the present embodiment has a function of notifying only users who have a high possibility of accessing the service in which the failure has occurred in the notification after the failure has occurred.

In general, it is difficult to grasp a user who needs the notification, that is, an appropriate user when the failure information is notified. To explain further, although the failure effect of the service / screen differs depending on the failure level, there is no function to notify depending on the failure level.
On the other hand, in the present embodiment, the time from the occurrence of the failure to the time until the recovery is calculated, and from the average value of the time, users who are highly likely to access the service in which the failure has occurred are analyzed, and notification is made. Do. The user who has a high possibility of accessing is specified based on the access / operation history, support information, and the like as described above.

  In other words, in the present embodiment, the user who performs the notification is specified based on the mode of access executed by the user in the past. For example, when a time period (access time) when a certain user is likely to use the service overlaps with a failure recovery time estimated from the failure occurrence time, the user is notified. .

FIG. 5 is a diagram illustrating a hardware configuration example of the server 20.
The server 20 is realized by a computer device as described above.
As shown in FIG. 5, the server 20 includes a CPU (Central Processing Unit) 231 that is a calculation means, a main memory 233 and a HDD (Hard Disk Drive) 235 that are storage means. Here, the CPU 231 executes various programs such as an OS (Operating System) and application software. The main memory 233 is a storage area for storing various programs and data used for execution thereof. The HDD 235 is a storage area for storing input data for various programs, output data from the various programs, and the like.

  The server 20 also includes a communication interface (communication I / F) 237 for performing communication with the outside. Note that the program executed by the CPU 231 is stored in a storage medium such as a CD-ROM, for example, in addition to being stored in the main memory 233 in advance, or provided to the CPU 231 or the network 40 (see FIG. 1). It is also possible to provide it to the CPU 231.

<Others>
When there is an unexpected user access, notification may be executed when access from the user is detected. For example, if the access from the user who has not executed the failure notification can be confirmed from the access history after the notification to the other user is terminated after the failure occurs, the failure content may be immediately notified to the user. .

  In the above description, when the estimated recovery time has passed and the failure has not been recovered (NO in step 318), it is a preset time, which is the time from failure start to recovery (reference recovery time). ) May elapse to identify users who are likely to access and take action.

  Here, in the above description, it has been described that the update of the target user (step 311), in other words, the addition or deletion of the target user is executed based on the help desk history. The update of the target user is not particularly limited as long as it is executed based on the service usage mode of the user. For example, when a certain user does not access at all, it is not necessary to notify the user. Further, for example, when a user frequently uses a premium service, the user may be notified by telephone in addition to the notification by e-mail.

Now, the calculation method of the average recovery time is not particularly limited. For example, when there are three or more histories of the same failure content, the remaining average value may be calculated except for the longest recovery time and the shortest recovery time. In addition, the average value may be calculated by collecting similar failure contents without being limited to the same failure contents. In addition, an average value may be calculated for each element different from the failure content, for example, for each failure occurrence time zone.
Furthermore, other representative values may be used instead of the average value of the recovery time. For example, the longest recovery time or the shortest recovery time may be used.

In addition, information regarding the estimated recovery time may be included as the content of the email notifying that a failure has occurred. For example, in the above example, the text “Recovery scheduled” may be included at “9:48 am on December 25, 2015”. Alternatively, the estimated recovery time may be expressed with a wider range. For example, the text “Recovery scheduled” may be included in the “morning on December 25, 2015”.
Further, unlike the above configuration, the failure notification system 1 may be configured without the help desk 30.

Moreover, although the case where the failure has not ended after the estimated recovery time has elapsed (NO in step 318) has been described to proceed to step 302, the present invention is not limited to this. For example, the user included in the target user list created in step 312 may be notified again. Or, since there is a possibility that the failure recovery is further delayed and affects the entire system that provides the service, if the failure has not ended after the estimated recovery time has elapsed (NO in step 318), more users, For example, all users may be notified.
Further, the steps after the estimated recovery time (steps 317 and 318) may be omitted.

  Further, when the entire system that provides the service stops, all users may be notified. In other words, depending on the degree of the failure that occurred, a mode for performing notification to the user based on the failure occurrence time and the estimated recovery time as described above, and notification to the user regardless of the failure occurrence time and the estimated recovery time. The mode to be executed may be switched.

Although various embodiments and modifications have been described above, it is of course possible to combine these embodiments and modifications.
Further, the present disclosure is not limited to the above-described embodiment, and can be implemented in various forms without departing from the gist of the present disclosure.

DESCRIPTION OF SYMBOLS 1 ... Failure notification system, 10 ... Client group, 20 ... Server, 30 ... Help desk, 207 ... Failure detection part, 213 ... Target user specific part, 221 ... Access history storage part, 223 ... User attribute storage part, 225 ... Failure Information storage unit

Claims (8)

A history acquisition unit for acquiring a history of access by a user;
When a failure occurs in the service provided to the user, based on the access mode by the user included in the history, a specifying unit that identifies a notification target user that is a user to be notified that the failure has occurred, A failure notification device. Having an estimation unit for estimating the time required for recovery, which is the time required for recovery of the failure,
The failure notification device according to claim 1, wherein the specifying unit specifies the notification target user based on the recovery time estimated by the estimation unit and an access mode by the user. A failure information storage unit that stores a history of failures that occurred in the service and stores an elapsed time from the occurrence of each failure to recovery,
The failure notification apparatus according to claim 2, wherein the estimation unit estimates the time required for recovery based on the elapsed time. The history acquisition unit stores an access time that is a time of access from a specific user,
The failure notification device according to claim 1, wherein the specifying unit determines whether to notify the specific user that the failure has occurred based on the access time. The said specific | specification part includes the user who was notified of the said information in the said notification object user, when the information regarding the said service was notified to the user before the said failure | damage | failure occurred. Failure notification device. The notification of the information includes access destination information regarding the service,
The specifying unit specifies a user who has accessed the access destination according to the notification of the information among the users notified of the information, and includes the specified user in the notification target user. The failure notification device according to claim 5, wherein: A history acquisition unit for acquiring a history of access by a user;
When a failure occurs in the service provided to the user, an access mode acquisition unit that acquires information related to the mode of access by the user included in the history;
An estimation unit for estimating a time required for recovery, which is a time required for recovery from the failure;
Based on the access mode acquired by the access mode acquisition unit and the recovery time estimated by the estimation unit, a notification target user who is a user to be notified that the failure has occurred is identified. Specific part to do,
When information related to the service is notified to the user before the failure occurs, the user who notified the information is specified, and the notification specified by the specifying unit based on the specified user A failure notification device having an update unit for updating a target user. A history acquisition unit for acquiring a history of access by a user;
A providing unit for providing a predetermined service to the user;
When a failure occurs in the service, the failure notification includes a specifying unit that identifies a notification target user, which is a user to be notified that the failure has occurred, based on an access mode included in the history. system.

Images