故障信息提供服务器、故障信息提供方法

摘要

一种故障信息提供服务器，与由多个服务器构成的处理服务器群连接，对由处理服务器群提供的服务的利用者提供与在处理服务器群中发生的故障有关的信息，具备：故障发生及修复管理部，管理处理服务器群的故障发生状况；日志管理部，管理与处理服务器群的各服务器的服务提供状况的履历有关的日志信息；规则管理部，管理与表示故障对服务的影响度的服务影响度有关的规则；服务影响度计算部，基于日志信息及规则，计算服务影响度；以及服务影响度通知部，向利用者通知由服务影响度计算部计算出的服务影响度。

说明书

技术领域

本发明涉及对系统利用者提供故障信息的故障信息提供服务器及故障信息提供方法。

背景技术

已知有使用经由无线通信网络连接的车载装置等的终端对系统利用者提供各种服务的系统。在这样的系统中发生了某种故障的情况下，优选的是将故障发生时的状况向利用者通知。在专利文献1中，公开了一种中继装置，当检测到不处于工作状态的内容服务器装置时，制作能够识别该内容服务器装置处于怎样的状态的服务菜单，向便携终端推送分发。

现有技术文献

专利文献

专利文献1：日本特许第3642004号

发明内容

发明要解决的问题

在使用上述专利文献1所公开的中继装置的情况下，系统利用者虽然在系统故障的发生时能够知道非工作状态的内容服务器装置的存在，但不能知道对所提供的服务的影响度。

解决问题所采用的手段

本发明的故障信息提供服务器，与由多个服务器构成的处理服务器群连接，对由上述处理服务器群提供的服务的利用者提供与在上述处理服务器群中发生的故障有关的信息，具备：故障发生及修复管理部，管理上述处理服务器群的故障发生状况；日志管理部，管理与上述处理服务器群的各服务器的服务提供状况的履历有关的日志信息；规则管理部，管理与表示上述故障对上述服务的影响度的服务影响度有关的规则；服务影响度计算部，基于上述日志信息及上述规则，计算上述服务影响度；以及服务影响度通知部，向上述利用者通知由上述服务影响度计算部计算出的服务影响度。

本发明的故障信息提供方法，使用与由多个服务器构成的处理服务器群连接的故障信息提供服务器，对由上述处理服务器群提供的服务的利用者提供与在上述处理服务器群中发生的故障有关的信息，由上述故障信息提供服务器，管理上述处理服务器群的故障发生状况；管理与上述处理服务器群的各服务器的服务提供状况的履历有关的日志信息；管理与表示上述故障对上述服务的影响度的服务影响度有关的规则；基于上述日志信息及上述规则，计算上述服务影响度；向上述利用者通知上述计算出的服务影响度。

发明效果

根据本发明，服务利用者在系统故障的发生时能够知道对所提供的服务的影响度。

附图说明

图1是表示本发明的一实施方式的故障信息提供服务器的结构的图。

图2是表示保存在车载终端管理部中的数据的表结构例的图。

图3是表示保存在通知信息管理部中的数据的表结构例的图。

图4是表示保存在服务结构管理部中的数据的表结构例的图。

图5是表示保存在计算规则管理部中的数据的表结构例的图。

图6是表示保存在预测规则管理部中的数据的表结构例的图。

图7是表示保存在日志统计值管理部中的数据的表结构例的图。

图8是表示保存在日志管理部中的数据的表结构例的图。

图9是表示服务影响度计算部执行的处理的流程图的图。

图10是表示故障发生及修复管理部执行的处理的流程图的图。

图11是表示在利用者终端上显示的通知画面例的图。

图12是表示在车载终端上显示的通知画面例的图。

具体实施方式

以下，使用附图对本发明的一实施方式进行详细的说明。

图1是表示本发明的一实施方式的故障信息提供服务器的结构的图。故障信息提供服务器101具备CPU(Central Processing Unit)112、输入部113、输出部114、通信部115、存储部111。

存储部111使用半导体存储器或HDD(Hard Disk Drive)等构成，保存各种程序及数据。例如，通过将保存在计算机可读取的存储介质中的程序及数据向故障信息提供服务器101安装，能够将这些程序及数据保存到存储部111中。存储部111在功能上具有车载终端管理部131、通知信息管理部132、服务结构管理部133、计算规则管理部134、预测规则管理部135、日志统计值管理部136、日志管理部137。

CPU112基于存储在存储部111中的程序及数据，执行用于使故障信息提供服务器101动作的各种运算处理。CPU112在功能上具有服务影响度通知部121、服务影响度计算部122、故障发生及修复管理部123、日志统计处理部124。

输入部113检测来自操作者的操作输入，向CPU112输出。输入部113例如由鼠标或键盘等构成。

输出部114按照来自CPU112的指示进行画面显示或声音输出。输出部114例如由显示器或扬声器等构成。

通信部115按照来自CPU112的指示，在与连接在故障信息提供服务器101上的处理服务器群141、利用者终端151及车载终端152之间进行通信。故障信息提供服务器101及处理服务器群141经由因特网150而与利用者终端151及车载终端152连接。因特网150既可以是有线连接，也可以是无线连接。

处理服务器群141由多台服务器构成，对利用者终端151及车载终端152提供各种服务。车载终端152是作为系统利用者的最终用户持有的终端。例如，可以将装备在车辆中的车载导航系统或由最终用户带入到车辆中的智能电话等作为车载终端152来使用。利用者终端151例如是向最终用户销售车辆的厂商的管理者等、最终用户以外的系统利用者拥有的终端。另外，在图1中为了简略化，将利用者终端151及车载终端152分别仅表示了各1个。但实际上，对应于系统利用者的数量，许多利用者终端151及车载终端152经由因特网150连接在处理服务器群141及故障信息提供服务器101上。

接着，对存储部111和CPU112的详细情况进行说明。在处理服务器群141中发生了系统故障的情况下，故障信息提供服务器101向利用者通知该系统故障发生对提供服务的影响度。存储部111和CPU112分别具有的上述各部被用于该服务影响度的通知。

服务影响度通知部121取得由服务影响度计算部122计算并从故障发生及修复管理部123输出的服务影响度。基于所取得的服务影响度，服务影响度通知部121生成表示处理服务器群141中的故障发生对服务的影响度的服务影响度信息，向通信部115输出。从服务影响度通知部121输出到通信部115的服务影响度信息由通信部115经由因特网150向利用者终端151及车载终端152发送。由此，服务影响度通知部121进行向利用者的服务影响度的通知。

在向车载终端152通知服务影响度的情况下，服务影响度通知部121向车载终端管理部131询问，确定作为通知对象的车载终端的组，对该组通知计算出的服务影响度。例如，在作为通知对象的车载终端152是“车载终端ID＝A12345”的情况下，以该“A12345”的车载终端ID为关键字检索车载终端管理部131，确定车载终端组。具体而言，在以图2所示的数据构造保存在车载终端管理部131中的信息中，检索在车载终端ID203一栏中包含“A12345”的信息，从与其对应的车载终端组202一栏的内容中确定“组1”。并且，在从故障发生及修复管理部123接收到的服务影响度中，将“车载终端组＝组1”的服务影响度向车载终端152通知。此时，既可以通知“车载终端组＝组1”的服务影响度的全部项目，也可以仅通知其中的一部分。当向车载终端152通知服务影响度时，将故障发生时刻等信息也一起通知。

从服务影响度通知部121向利用者终端151及车载终端152通知服务影响度的定时可以为任意的定时。例如，也可以是，如果有从利用者终端151或车载终端152向故障信息提供服务器101的访问，则对应于该访问而从服务影响度通知部121进行服务影响度的通知。此外，也可以在处理服务器群141中发生故障时通知，也可以在故障发生中定期地通知。进而，也可以仅在故障发生时和修复时等的特定的定时通知。

服务影响度计算部122基于来自故障发生及修复管理部123的请求，计算与处理服务器群141的工作状态对应的服务影响度。由服务影响度计算部122得到的服务影响度的计算结果经由故障发生及修复管理部123被向服务影响度通知部121输出。另外，关于服务影响度计算部122的处理内容，在后面参照图9的流程图详细地说明。

故障发生及修复管理部123经由通信部115接收从处理服务器群141发送的与系统故障的发生状况及修复状况有关的信息。基于该信息，故障发生及修复管理部123判断在处理服务器群141中是否发生了系统故障。在判断为发生了系统故障的情况下，故障发生及修复管理部123对服务影响度计算部122请求由该故障带来的服务影响度的计算。并且，从服务影响度计算部122取得服务影响度的计算结果，向服务影响度通知部121输出。此时，也可以将与该故障有关的其他信息、例如故障的发生时刻等也一起通知。另外，关于故障发生及修复管理部123的处理内容，在后面参照图10的流程图详细地说明。

日志统计处理部124从日志管理部137定期地取得保存在日志管理部137中的与处理服务器群141的各服务器的服务提供状况有关的日志信息。并且，将所取得的日志信息进行统计处理，将其结果向日志统计值管理部136保存。

在车载终端管理部131中，保存有用于将车载终端152以组单位进行管理的数据。基于保存在车载终端管理部131中的数据，服务影响度通知部121能够在处理服务器群141中的故障发生时确定作为服务影响度的通知对象的车载终端152，使用通信部115向该车载终端152发送服务影响度信息。

图2表示保存在车载终端管理部131中的数据的表结构例。车载终端管理部131例如使用图2所示的表结构的数据，根据搭载车种、发售年、种类等，将多个车载终端152分组管理。图2的数据表由厂商名201、车载终端组202、车载终端ID203的各项目构成。

厂商名201表示安装有属于各车载终端组的车载终端152的车辆的制造销售厂商的名称。车载终端组202表示对各车载终端组分配的组名。车载终端ID203表示用于唯一地识别属于各车载终端组的车载终端152的识别码。

在图2的数据表中，在第一行，在厂商名201一栏中记载有“厂商A”，在车载终端组202一栏中记载有“组1”，在车载终端ID203一栏中记载有“A12345”、“B56789”。这表示，由A12345、B56789的ID号分别确定的车载终端152属于组1的车载终端组，安装有这些车载终端152的车辆是由厂商A制造、销售的。

此外，在第二行，在厂商名201一栏中记载有“厂商A”，在车载终端组202一栏中记载有“组2”，在车载终端ID203一栏中记载有“C98765”。这表示，由C98765的ID号确定的车载终端152属于组2的车载终端组，安装有该车载终端152的车辆是由厂商A制造、销售的。

在通知信息管理部132中，保存有用于管理与从处理服务器群141向车载终端152的提供服务及在处理服务器群141的故障发生时从故障信息提供服务器101通知的服务影响度的项目有关的通知信息的数据。基于保存在通知信息管理部132中的数据，服务影响度通知部121在处理服务器群141中的故障发生时能够确定向利用者终端151及车载终端152通知的服务影响度的项目。

图3表示保存在通知信息管理部132中的数据的表结构例。通知信息管理部132例如使用图3所示的表结构的数据，按每个车载终端组管理从处理服务器群141的提供服务、和在处理服务器群141的故障发生时通知的服务影响度。图3的数据表由车载终端组301、提供服务302、服务影响度303的各项目构成。

车载终端组301表示对各车载终端组分配的组名，与图2所示的车载终端管理部131的车载终端组202对应。提供服务302表示处理服务器群141向各车载终端组提供的服务的种类。服务影响度303表示在处理服务器群141的故障发生时从故障信息提供服务器101向利用者终端151及车载终端152提供的服务影响度的项目。

在图3的数据表中，在第一行，在车载终端组301一栏中记载有“组1”，在提供服务302一栏中记载有“服务1”、“服务2”，在服务影响度303一栏中记载有“服务工作率”、“响应时间”、“连接终端数”。这表示，属于组1的车载终端152被从处理服务器群141提供与服务1及服务2对应的服务，当在处理服务器群141中发生了故障时，对于组1的车载终端152及对应的利用者终端151，通知服务工作率、响应时间、连接终端数的信息作为服务影响度。这里，与组1的车载终端152对应的利用者终端151是厂商A的利用者终端151，其能够基于图2所示的车载终端管理部131的保存数据来确定。

此外，在第二行，在车载终端组301一栏中记载有“组2”，在提供服务302一栏中记载有“服务2”，在服务影响度303一栏中记载有“故障修复计划时刻”、“不可利用终端数”。这表示，属于组2的车载终端152被从处理服务器群141提供服务2的服务，当在处理服务器群141中发生了故障时，对组2的车载终端152及对应的利用者终端151通知故障修复计划时刻、不可利用终端数的信息作为服务影响度。

在服务结构管理部133中，保存有用于管理处理服务器群141的服务结构的数据。基于保存在服务结构管理部133中的数据，服务影响度计算部122在处理服务器群141中的故障发生时能够确定作为在服务影响度的计算中使用的日志信息的取得对象的服务器。

图4表示保存在服务结构管理部133中的数据的表结构例。服务结构管理部133使用例如图4所示的表结构的数据，按每个服务来管理构成处理服务器群141的各服务器。图4的数据表由服务ID401、服务器种类402、服务器ID403的各项目构成。

服务ID401表示用于唯一地识别处理服务器群141的各服务器的提供服务的识别码，与图3所示的通知信息管理部132的提供服务302对应。服务器种类402表示各服务器的作用。服务器ID403表示用于唯一地识别具体地实施各服务器的作用的服务器的识别码。

在图4的数据表中，在第一行，在服务ID401一栏中记载有“服务1”，在服务器种类402一栏中记载有“Web服务器”，在服务器ID403一栏中记载有“服务器1”、“服务器2”。此外，在第二行，在服务ID401一栏中记载有“服务1”，在服务器种类402一栏中记载有“AP服务器”，在服务器ID403一栏中记载有“服务器3”、“服务器4”；在第三行，在服务ID401一栏中记载有“服务1”，服务器种类402一栏中记载有“DB服务器”，在服务器ID403一栏中记载有“服务器5”、“服务器6”。这表示，服务1由作为Web服务器的服务器1及服务器2、作为AP(应用)服务器的服务器3及服务器4和作为DB(数据库)服务器的服务器5及服务器6提供。

在计算规则管理部134中，保存有用于管理为了计算处理服务器群141的故障发生时的当前时间点的对服务的影响度而使用的计算规则的数据。基于保存在计算规则管理部134中的数据，服务影响度计算部122能够在处理服务器群141中的故障发生时计算服务影响度。

图5表示保存在计算规则管理部134中的数据的表结构例。计算规则管理部134使用例如图5所示的表结构的数据来管理计算规则，该计算规则定义了根据保存在日志管理部137中的日志信息计算当前时间点的服务影响度的方法。图5的数据表由服务影响度501、计算规则502的各项目构成。

服务影响度501表示在故障发生时从故障信息提供服务器101向利用者终端151及车载终端152提供的信息，与图3所示的通知信息管理部132的服务影响度303对应。另外，服务影响度501的各项目优选的是与预测规则管理部135的保存数据中的服务影响度(后述的图6所示的服务影响度601)不重复。即，使得在计算规则管理部134和预测规则管理部135这两者中不定义相同项目名的服务影响度。如果这样，则关于服务影响度的各项目，能够判别是使用由计算规则管理部134管理的计算规则计算、还是使用由预测规则管理部135管理的预测规则计算。计算规则502关于服务影响度501的各项目表示其具体的计算方法。

在图5的数据表中，在第一行，在服务影响度501一栏中记载有“服务工作率”，在计算规则502一栏中记载有“(全部时间－系统停止时间)/全部时间”。这表示，作为服务影响度之一的服务工作率可以通过将从“全部时间”减去“系统停止时间”后的值除以“全部时间”来计算。另外，“全部时间”表示在处理服务器群141中提供服务的全部服务器的工作时间的合计，“系统停止时间”表示因故障造成的服务器的停止时间。这些信息可以从保存在日志管理部137中的日志信息中取得。

此外，在第二行，在服务影响度501一栏中记载有“响应时间”，在计算规则502一栏中记载有“‘Web服务器中的回答时刻－Web服务器中的请求受理时刻’的平均值”。这表示，作为服务影响度之一的响应时间可以作为从处理服务器群141中的Web服务器中的请求受理时刻到回答时刻为止的时间的平均值计算。另外，Web服务器的具体的服务器ID可以基于图4所示的服务结构管理部133的保存信息来确定。这里，假设在保存于日志管理部137中的日志信息中，包含有能够将来自各车载终端152的请求受理与针对该请求的回答建立关联的信息(例：事务ID等)。通过基于该信息求出从各请求的受理到回答所花费的时间的平均值，能够计算响应时间。另外，这里设为从请求受理时刻到回答时刻为止的时间的平均值，但也可以为最大值或最小值。

此外，在第四行，在服务影响度501一栏中记载有“访问数”，在计算规则502一栏中记载有“由Web服务器受理的请求数”。这表示，作为服务影响度之一的访问数可以作为由处理服务器群141的Web服务器受理的请求数计算。请求数可以从保存在日志管理部137中的日志信息中取得。另外，在处理服务器群141中Web服务器有多台的情况下，只要计算各自的请求数的平均值或合计值作为访问数就可以。此外，在从同一个车载终端152有重试的情况下，只要将该重试也看作1次请求来计算访问数就可以。或者，也可以将重试省去而计算访问数，也可以仅将一定时间以内的重试省去。

如以上说明，在计算规则管理部134中，关于服务影响度的各项目保存有用于计算其值的计算规则。另外，图5所示的计算规则不过是一例，可以按服务影响度的每个项目设定各种各样的计算规则。

在预测规则管理部135中，保存有用于管理为了预测处理服务器群141的故障发生时的未来时间点的对服务的影响度而使用的预测规则的数据。基于保存在预测规则管理部135中的数据，服务影响度计算部122在处理服务器群141中的故障发生时能够计算服务影响度。

图6表示保存在预测规则管理部135中的数据的表结构例。预测规则管理部135使用例如图6所示的表结构的数据来管理预测规则，该预测规则定义了根据保存在日志管理部137中的日志信息及保存在日志统计值管理部136中的日志统计信息来预测未来时间点的服务影响度的方法。图6的数据表由服务影响度601、预测规则602的各项目构成。

服务影响度601表示在故障发生时从故障信息提供服务器101向利用者终端151及车载终端152提供的信息，与图3所示的通知信息管理部132的服务影响度303对应。另外，如上述那样，服务影响度601的各项目优选的是不与图5所示的计算规则管理部134的保存数据中的服务影响度501重复。预测规则602关于服务影响度601的各项目表示其具体的预测方法。

在图6的数据表中，在第一行，在服务影响度601一栏中记载有“故障修复计划时刻”，在与其对应的预测规则602一栏中，记载有对当前时刻加上“修复所需要的时间”的情况、和“修复所需要的时间”的确定方法。这表示，作为服务影响度之一的从故障起的修复计划时刻可以通过确定修复所需要的时间、将该值加到当前时刻中来预测。这里，修复所需要的时间可以使用保存在日志管理部137中的日志信息，按照由预测规则602定义的方法来求出。具体而言，例如在保存在日志管理部137中的日志信息中的Web服务器的最近日志中包含有“AA”这样的字符串的情况下，修复所需要的时间被要求为5分钟。此外，在AP服务器的最近日志中包含有“BB”这样的字符串的情况下，修复所需要的时间是7分钟，在AP服务器的最近日志中包含有“CC”这样的字符串的情况下，要求修复所需要的时间是8分钟。另外，最近日志的范围既可以用例如1分钟等时间来指定，也可以用10个等的数量来指定。结果，例如在当前时刻是19时22分、修复所需要的时间被要求5分钟的情况下，故障修复计划时刻可以预测为19时22分+5分＝19时27分。

此外，在第二行，在服务影响度601一栏中记载有“不可利用终端数”，在与其对应的预测规则602一栏中记载有根据“故障发生时刻”、“故障修复计划时刻”、“分时间段的平均连接终端数”进行预测。这表示，作为服务影响度之一的不可利用终端数、即因故障而被限制服务的利用的利用者的数量可以基于故障发生时刻、故障修复计划时刻及分时间段的平均连接终端数来预测。这里，故障修复计划时刻可以如上述那样求出。此外，故障发生时刻可以由故障发生及修复管理部123取得，分时间段的平均连接终端数可以根据保存在日志统计值管理部136中的日志信息的统计值取得。结果，例如假设故障发生时刻是19时17分、故障修复计划时刻是19时27分，作为分时间段的平均连接终端数，19时～20时的平均连接终端数是600(台/时间)。在此情况下，由于故障发生期间是从19时17分到19时27分的10分钟，所以可以预测出不可利用终端数为600(台/时间)×10(分)÷60(分)＝100台。

此外，在第三行，在服务影响度601一栏中记载有“连接错误数”，在与其对应的预测规则602一栏中记载有根据“故障发生时刻”、“故障修复计划时刻”、“分时间段的平均访问数”进行预测。这表示，作为服务影响度的之一的连接错误数、即因故障而向处理服务器群141的连接发生错误的来自利用者的访问数可以基于故障发生时刻、故障修复计划时刻及分时间段的平均访问数来预测。这里，故障发生时刻及故障修复计划时刻可以与预测上述不可利用终端数的情况同样地取得。此外，分时间段的平均访问数可以根据保存在日志统计值管理部136中的日志信息的统计值取得。结果，例如故障发生时刻是19时17分、故障修复计划时刻是19时27分，作为分时间段的平均访问数，19时～20时的平均访问数是1200(访问/时间)。在此情况下，由于故障发生期间是从19时17分到19时27分的10分钟，所以可以预测出连接错误数为1200(访问/时间)×10(分)÷60(分)＝200访问。

此外，在第四行，在服务影响度601一栏中记载有“响应延迟率”，在与其对应的预测规则602一栏中记载有根据“分时间段的平均响应时间”、“服务器减少率”进行预测。这表示，作为服务影响度之一的由故障造成的来自处理服务器群141的响应延迟率可以基于分时间段的平均响应时间及服务器减少率来预测。这里，服务器减少率如在预测规则602一栏中记载那样，通过将服务器工作台数除以服务器冗余构成台数来计算。此时，也可以按服务器的每个种类计算服务器减少率，采用其中的最低值作为处理服务器群141的服务器减少率。例如，在处理服务器群141由Web服务器、AP服务器、DB服务器这三种服务器构成、由两台服务器冗余构成的Web服务器中的1台因故障而宕机的情况下，Web服务器的减少率为0.5。同样，关于AP服务器、DB服务器也求出减少率，在其中选择最低值，由此能够求出处理服务器群141的服务器减少率。此外，分时间段的平均响应时间可以根据保存在日志统计值管理部136中的日志信息的统计值取得。结果，例如假设分时间段的平均响应时间是1.6秒，服务器减少率是0.5。在此情况下，可以预测出响应延迟时间为1.6(秒)÷0.5＝3.2(秒)。

如以上说明，在预测规则管理部135中，关于服务影响度的各项目保存有用于预测其值的预测规则。另外，图6所示的预测规则不过是一例，可以按服务影响度的每个项目设定各种各样的预测规则。

在日志统计值管理部136中，保存有用于管理与由日志统计处理部124制作的处理服务器群141的日志信息的统计值有关的日志统计信息的数据。基于保存在日志统计值管理部136中的数据，服务影响度计算部122在处理服务器群141中的故障发生时能够计算服务影响度。

图7表示保存在日志统计值管理部136中的数据的表结构例。日志统计值管理部136使用例如图7所示的表结构的数据，将由日志管理部137管理的日志信息的统计值按处理服务器群141的各服务器所提供的每个服务进行管理。图7的数据表由项目701、服务ID702、统计值703构成。

项目701表示各统计值的内容。服务ID702表示用于唯一地识别处理服务器群141的各服务器的提供服务的识别码，对应于图3所示的通知信息管理部132的提供服务302和图4所示的服务结构管理部133的服务ID401。统计值703表示每个项目的统计值。

在图7的数据表中，在第一行，在项目701一栏中记载有“分时间段的平均连接终端数”，在服务ID702一栏中记载有“服务1”，在与其对应的统计值703一栏中记载有每个时间段的数值。这表示作为日志信息的统计值之一的分时间段的平均连接终端数。该统计值例如可以在保存在日志管理部137中的Web服务器的日志信息中确定来自车载终端152的连接开始日志、将其按每个时间段进行总计来计算。这里，假设在保存在日志管理部137中的日志信息中，包含用于确定连接在Web服务器上的车载终端152的车载终端ID、用于确定车载终端152所利用的服务的服务ID。另外，在处理服务器群141中有多台Web服务器的情况下，也可以求出各Web服务器的分时间段的平均连接终端数，将其平均值作为处理服务器群141的分时间段的平均连接终端数。或者，也可以不是平均值，而是最大值或最小值。

关于在其他行中记载的“分时间段的平均访问数”、“分时间段的平均响应时间”，也能够通过与上述同样的方法计算。另外，响应时间的具体的计算方法与在图5中说明的方法同样。

在日志管理部137中，保存有用于管理处理服务器群141的日志信息的数据。基于保存在日志管理部137中的数据，服务影响度计算部122在处理服务器群141中的故障发生时能够计算服务影响度。

日志管理部137经由通信部115从处理服务器群141收集日志信息。此时，既可以从处理服务器群141向故障信息提供服务器101通知日志信息，也可以通过从故障信息提供服务器101对处理服务器141请求日志信息来取得日志信息。此外，既可以将日志信息实时地收集，也可以以一定周期收集。

图8表示保存在日志管理部137中的数据的表结构例。日志管理部137使用例如图8所示的表结构的数据，管理与处理服务器群141的各服务器的服务提供状况的履历有关的日志信息。图8的数据表由服务器ID801、时刻802、日志803构成。

服务器ID801表示用于唯一地确定各日志发生的服务器的识别码。时刻802表示各日志发生的时刻，日志803表示从处理服务器群141的各服务器输出的具体的日志信息的内容。

如图8的数据表所示，记录在日志803中的日志信息包括用于确定提供服务的服务ID、用于确定提供了服务的车载终端152的车载终端ID、用于确定事务的事务ID等信息。通过作为日志信息而记录事务ID，如在图5中说明那样，能够将来自各车载终端152的请求受理与针对该请求的回答建立关联。

在存储部111的各管理部中，记录有以上说明那样的数据。

如果在处理服务器群141中某个服务器发生系统故障，则服务影响度通知部121将用于通知对该服务器所提供的服务的影响度的服务影响度信息经由通信部115向利用者终端151及车载终端152发送。此时，服务影响度通知部121从故障发生及修复管理部123接收与服务影响度有关的信息。与服务影响度有关的信息具有与图3所示的保存在通知信息管理部132中的数据同样的数据构造。即，由表示作为对象的车载终端152的组的“车载终端组”、表示受到故障的影响的提供服务的内容的“服务ID”、和表示故障对提供服务的影响度的“服务影响度”的组合构成。例如，假设发送了“车载终端组＝组1”、“服务ID＝服务1”、“服务影响度＝故障修复计划时刻19时27分”这样的服务影响度信息。该服务影响度信息是指对属于组1的各车载终端152提供的服务1的故障修复计划时刻是19时27分。另外，在服务影响度通知部121中，对于从故障发生及修复管理部123接收到的信息，既可以仅管理最新的值，也可以管理接收到的信息的履历。在管理履历的情况下，也可以仅将特定的服务影响度的项目作为履历管理的对象。

服务影响度通知部121基于从故障发生及修复管理部123接收到的信息确定车载终端152的组，对与该组对应的利用者终端151、各车载终端152通知服务影响度。此时，在向利用者终端151通知服务影响度的情况下，优选的是基于以图2那样的数据构造保存在车载终端管理部131中的信息，确定所确定的车载终端152的组是哪个厂商的，将该厂商的利用者终端151作为通知对象。例如，在利用利用者终端151的是“厂商A”的管理者的情况下，以“厂商A”为关键字，提取图2的厂商名201的记载是“厂商A”的行，从该行中的车载终端组202的记载内容中确定“组1”、“组2”。并且，在从故障发生及修复管理部123接收到的服务影响度的信息中，提取“车载终端组＝组1”或“车载终端组＝组2”的与服务影响度有关的信息，向利用者终端151通知。此时，优选的是将故障发生时刻及属于车载终端组的车载终端的一览等的信息也一起通知。

图9是表示故障信息提供服务器101的服务影响度计算部122执行的处理的流程图的图。

首先，在步骤901中，服务影响度计算部122确定有故障的影响的服务。这里，服务影响度计算部122从故障发生及修复管理部123接收与故障发生时刻、故障发生服务器有关的信息。并且，以接收到的信息所示的故障发生服务器为关键字在服务结构管理部133中进行检索，确定受到故障的影响的服务的服务ID。具体而言，在以如图4所示的数据构造保存在服务结构管理部133中的信息中，检索在服务器ID403一栏中包含故障发生服务器的ID号的行，从该行的服务ID401一栏中记录的内容中确定服务ID。另外，由于有服务器被多个服务利用的情况，所以有虽然服务器ID是一个、但检索到多个服务ID的情况。

接着，在步骤902中，服务影响度计算部122确定通知的服务影响度的项目。这里，服务影响度计算部122以在步骤901中确定的服务ID为关键字在通知信息管理部132中进行检索，决定服务影响度的项目。具体而言，在以图3所示的数据构造保存在通知信息管理部132中的信息中，检索在提供服务302一栏中包含有在步骤901中确定的服务ID的行，从在该行的服务影响度303一栏中记录的内容中确定服务影响度的项目。此时，从相同行的车载终端组301一栏的记载内容中还确定通知的车载终端的组。

接着，在步骤903中，服务影响度计算部122判定在步骤902中确定的服务影响度的项目是否能够基于由计算规则管理部134管理的计算规则来计算。这里，服务影响度计算部122从在步骤901中确定的服务ID和在步骤902中确定的车载终端的组及服务影响度的项目的组合中选择一个。并且，以所选择的组合的服务影响度的项目为关键字在计算规则管理部134中进行检索，检索对应的服务影响度的有无。具体而言，在以图5所示的数据构造保存在计算规则管理部134中的信息中，在服务影响度501一栏中记录的内容中检索所选择的组合的服务影响度的项目。结果，在服务影响度501中存在该服务影响度的项目的情况下(是)，判定为能够基于计算规则计算，向步骤904前进，在不存在的情况下(否)，判定为不能基于计算规则计算，向步骤905前进。例如，在检索的服务影响度的项目是“服务工作率”的情况下，其在图5的表中存在于服务影响度501的第一行。因而，在此情况下判定为能够基于计算规则计算，向步骤904前进。另一方面，例如在检索的服务影响度的项目是“故障修复计划时刻”的情况下，其在图5的表中不存在。因而，在此情况下判定为不能基于计算规则计算，向步骤905前进。

在从步骤903前进到步骤904的情况下，在步骤904中，服务影响度计算部122基于日志信息及计算规则计算服务影响度。这里，服务影响度计算部122基于与在步骤903中检索到的服务影响度的项目对应的计算规则502的内容，取得用于计算该服务影响度的项目的计算规则。接着，在保存在日志管理部137中的故障发生时刻以后的日志信息中，收集在所取得的计算规则中需要的日志信息。并且，通过使用收集到的日志信息按照计算规则进行计算，计算服务影响度的值。

以下说明关于例如“故障发生时刻＝19时22分”、“服务ID＝服务1”、“服务影响度＝响应时间”的组合的具体的服务影响度的计算方法。在此情况下，服务影响度计算部122首先通过参照图5所示的计算规则管理部134的保存信息表的第二行，将响应时间的计算规则确定为“‘Web服务器中的回答时刻－Web服务器中的请求受理时刻’的平均值”。接着，通过向服务结构管理部133询问服务1的Web服务器，从图4所示的服务结构管理部133的保存信息表中，取得“Web服务器＝服务器1、服务器2”的信息。接着，从图8所示的日志管理部137的保存信息表中，取得服务器ID801是“服务器1”或“服务器2”、时刻802是“19时22分以后”的日志信息803。并且，基于使用所取得的日志信息的计算规则，计算“‘Web服务器中的回答时刻－Web服务器中的请求受理时刻’的平均值”。

在从步骤903前进到步骤905的情况下，在步骤905中，服务影响度计算部122基于日志信息、日志统计信息及预测规则，计算服务影响度。这里，服务影响度计算部122以在步骤902中确定的服务影响度的项目为关键字，在预测规则管理部135中进行检索，取得用于计算该服务影响度的项目的预测规则。接着，在分别保存在日志管理部137、日志统计值管理部136中的故障发生时刻以后的日志信息及日志统计信息中，收集在所取得的预测规则中需要的日志信息及日志统计信息。并且，通过使用收集到的日志信息及日志统计信息按照预测规则进行计算，计算服务影响度的值。

以下说明关于例如“当前时刻＝19时35分”、“故障发生时刻＝19时22分”、“服务ID＝服务1”、“服务影响度＝故障修复计划时刻”的组合的具体的服务影响度的计算方法。在此情况下，服务影响度计算部122首先通过参照图6所示的预测规则管理部135的保存信息表的第一行，确定故障修复计划时刻的预测规则。接着，通过向服务结构管理部133询问所确定的预测规则的服务1的Web服务器、AP服务器，从图4所示的服务结构管理部133的保存信息表中，取得“Web服务器＝服务器1、服务器2”、“AP服务器＝服务器3、服务器4”的信息。接着，从图8所示的日志管理部137的保存信息表中，取得服务器ID801为“服务器1”、“服务器2”、“服务器3”或“服务器4”、时刻802为“19时32分以后”的日志信息803。这里，设最近日志的范围为3分钟，取得当前时刻的3分钟前的19时32分以后的日志信息。并且，基于使用所取得的日志信息的预测规则，计算故障修复计划时刻。例如，在修复所需要的时间是5分钟的情况下，通过对当前时刻的19时35分加上修复所需要的时间的5分钟，预测故障修复计划时刻为19时40分。

此外，以下说明关于例如“故障发生时刻＝19时22分”、“故障修复计划时刻＝19时40分”、“服务ID＝服务1”、“服务影响度＝不可利用终端数”的组合的具体的服务影响度的计算方法。在此情况下，服务影响度计算部122首先通过参照图6所示的预测规则管理部135的保存信息表的第二行，确定不可利用终端数的预测规则。接着，从图7所示的日志统计值管理部136的保存信息表中，取得项目701对应于“分时间段的平均连接终端数”、服务ID702对应于“服务1”的统计值703。并且，基于使用所取得的日志统计信息的预测规则，计算不可利用终端数。例如，在19时～20时的平均连接终端数是100(台/时间)、故障发生时间是18分(19时22分～40分)的情况下，预测为不可利用终端数＝100(台/时间)×18(分)÷60(分)＝30台。

接着，在步骤906中，服务影响度计算部122关于在步骤901中确定的服务ID和在步骤902中确定的服务影响度的项目，确认是否计算了对于全部的组合的服务影响度。在已计算对于全部的组合的服务影响度的情况下(是)，向步骤907前进，在还有未计算的服务影响度的情况下(否)，向步骤903返回。

接着，在步骤907中，服务影响度计算部122确认是否关于在步骤902中确定的全部的车载终端的组计算了全部组的服务影响度。在已计算全部的组的服务影响度的情况下(是)，结束图9的处理，在还有未计算的服务影响度的情况下(否)，向步骤903返回。

通过以上说明那样的处理，服务影响度计算部122关于从处理服务器群141提供的服务中的有故障的影响的服务，能够决定应计算的服务影响度的项目。并且，能够基于由计算规则管理部134管理的计算规则或由预测规则管理部135管理的预测规则，按因故障发生而从处理服务器群141提供的服务受到影响的车载终端的每个组计算服务影响度。

图10是表示故障信息提供服务器101的故障发生及修复管理部123执行的处理的流程的图。

首先，在步骤1001中，故障发生及修复管理部123从处理服务器群141接收故障发生的通知。这里，作为故障发生通知，从处理服务器群141接收故障ID、故障发生时刻、故障发生服务器等信息。这里，故障ID是用于唯一地确定发生的故障的识别码。既可以由外部服务器监视处理服务器群141的资源而自动地向故障信息提供服务器101通知警报，也可以人工进行监视而通知警报。

接着，在步骤1002中，故障发生及修复管理部123使用服务影响度计算部122，计算由故障发生带来的服务影响度的计算。这里，故障发生及修复管理部123对于服务影响度计算部122，以在步骤1001中接收到的故障发生通知中的故障发生时刻、故障发生服务器为自变量，请求服务影响度的计算。对应于该请求，服务影响度计算部122在执行由图9的流程图说明的处理后，向故障发生及修复管理部123应答服务影响度的计算结果。从服务影响度计算部122向故障发生及修复管理部123传送的服务影响度的计算结果由车载终端组、服务ID、服务影响度等信息构成。例如，作为服务影响度的计算结果而传送“车载终端组＝组1”、“服务ID＝服务1”、“故障修复计划时刻＝19时27分”的信息。这表示，在处理服务器群141对组1的各车载终端152提供的服务1中发生了故障，其故障修复计划时刻是19时27分。

接着，在步骤1003中，故障发生及修复管理部123将在步骤1002中取得的服务影响度的计算结果向服务影响度通知部121传送。

接着，在步骤1004中，故障发生及修复管理部123判定在步骤1001中接收到的故障是否已修复。在故障已修复的情况下(是)，结束图10的处理，在故障没有修复的情况下(否)，向步骤1002返回。该判断例如与步骤1001同样，可以通过从处理服务器群141接收修复后的服务的故障ID、故障修复时刻的通知来进行。

另外，在上述说明中，通过步骤1001的处理，以处理服务器群141中的故障发生为触发事件来计算服务影响度，但也可以以来自利用者终端151或车载终端152的请求为触发事件来计算服务影响度。

此外，故障发生及修复管理部123优选的是，如果在步骤1001中从处理服务器群141接收到故障发生的通知，则定期地进行步骤1002～1004的处理。如果这样，则能够在从处理服务器群141中发生故障到修复的期间中，由服务影响度计算部122按每规定的周期再计算服务影响度的最新值。并且，能够由服务影响度通知部121将由服务影响度计算部122求出的每规定周期的服务影响度的最新值向服务利用者通知。但是，也可以不这样，而将服务影响度仅计算一定的次数，也可以通过来自利用者终端151或车载终端152的停止请求而停止服务影响度的计算。

接着，说明当从故障信息提供服务器101接收到由处理服务器群141中的故障发生带来的服务影响度的通知时、在利用者终端151及车载终端152中分别显示的通知画面的例子。

图11表示在利用者终端151中显示的通知画面例。在图11所示的画面上，显示有厂商名1101、故障发生时刻1102及属于厂商A的各车载终端组的服务影响度的信息。在每个该车载终端组的服务影响度的信息中，包含车载终端组1103、车载终端一览按钮1104、各服务的服务影响度1105、履历按钮1106。

在图11的画面中，如果利用者终端151的管理者将利用者终端151操作而按下车载终端一览按钮1104，则通过弹出画面来显示属于与该车载终端一览按钮1104对应的车载终端组1103所示的车载终端152的组(这里是组1)的车载终端152的一览。此外，如果按下履历按钮1106，则通过图表显示与该履历按钮1106对应的服务影响度的履历信息。例如，在将处于服务工作率的右侧的履历按钮1106按下的情况下，弹出显示服务工作率的履历图表。

另外，在图11的画面中，关于没有故障的影响的服务，显示“正常工作”这样的信息。由此，对利用者终端151进行操作的厂商的管理者能够掌握对由本公司销售的车辆的服务提供状态、因故障造成的服务影响度。

图12表示在车载终端152中显示的通知画面例。在图12所示的画面中，显示有故障发生时刻1201及各个服务的服务影响度1202。

在图12的画面中，也与图11同样，关于没有故障的影响的服务，显示“正常工作”这样的信息。由此，对车载终端152进行操作的最终用户能够知道自己利用的服务的工作状态。

根据以上说明的本发明的实施方式，起到以下的作用效果。

(1)故障信息提供服务器101与由多个服务器构成的处理服务器群141连接，对处理服务器群141的服务的利用者提供与在处理服务器群141中发生的故障有关的信息。故障信息提供服务器101具备对处理服务器群141的故障发生状况进行管理的故障发生及修复管理部123、管理与处理服务器群141的各服务器的服务提供状况的履历有关的日志信息的日志管理部137、管理与表示故障对服务的影响度的服务影响度有关的规则的作为规则管理部的计算规则管理部134及预测规则管理部135、基于由日志管理部137管理的日志信息及由规则管理部管理的规则而计算服务影响度的服务影响度计算部122、和将由服务影响度计算部122计算出的服务影响度向利用者通知的服务影响度通知部121。由此，服务利用者在系统故障的发生时能够知道对于提供的服务的影响度。

(2)上述规则管理部包括计算规则管理部134，该计算规则管理部134管理用于计算故障对服务的当前时间点的影响度的计算规则。服务影响度计算部122基于由日志管理部137管理的日志信息及由计算规则管理部134管理的计算规则，计算服务影响度。由此，能够可靠地计算故障对服务的当前时间点的影响度。

(3)此外，故障信息提供服务器101还具备日志统计值管理部136，该日志统计值管理部136管理与日志信息的统计值有关的日志统计信息，上述规则管理部包括管理用于预测故障对服务的未来时间点的影响度的预测规则的预测规则管理部135。服务影响度计算部122基于由日志管理部137管理的日志信息、由日志统计值管理部136管理的日志统计信息、以及由预测规则管理部135管理的预测规则来计算服务影响度。由此，能够可靠地计算故障对服务的未来时间点的影响度。

(4)预测规则管理部135管理例如包括用于预测从故障起的修复计划时刻的预测规则、用于预测因故障而被限制服务的利用的利用者的数量的预测规则、用于预测因故障而向处理服务器群141的连接发生错误的来自利用者的访问数的预测规则、用于预测因故障造成的来自处理服务器群141的响应延迟率的预测规则中的至少一个的预测规则。由此，能够适当地管理与各种各样的服务影响度的项目有关的预测规则，并用于服务影响度的计算。

(5)故障信息提供服务器101还具备将由利用者持有并分别接受服务的提供的多个车载终端152以组单位进行管理的车载终端管理部131。服务影响度计算部122按由车载终端管理部131管理的车载终端152的每个组计算服务影响度。由此，不论接受服务的提供的车载终端152的数量如何，都能够以组单位集中计算服务影响度。

(6)此外，故障信息提供服务器101还具备管理与按车载终端152的每个组设定的服务影响度的通知项目有关的通知信息的通知信息管理部132。服务影响度通知部121基于由通知信息管理部132管理的通知信息，按车载终端152的每个组向利用者通知不同的服务影响度。由此，关于从处理服务器群141提供的服务不同的各种各样的车载终端152的组，能够分别通知适当的服务影响度。

(7)优选的是，在故障发生及修复管理部123中，通过定期地进行图10的步骤1002～1004的处理，服务影响度计算部122按每规定的周期再计算服务影响度的最新值，服务影响度通知部121向利用者通知由服务影响度计算部122求出的每规定的周期的服务影响度的最新值。如果这样，则即使在从处理服务器群141中发生故障到修复的期间状况变化的情况下，也能够正确地通知服务影响度。

(8)服务影响度通知部121通过发送用于将图11、图12所例示的画面分别在利用者终端151、车载终端152上显示的信息，向利用者通知服务影响度。这些画面至少包括表示故障的发生时刻的故障发生时刻1102、1201、和表示与利用者的属性对应的各服务的服务影响度的服务影响度1105、1202。由此，能够以对于利用者而言容易理解的形态进行服务影响度的通知。

另外，以上说明的实施方式及各种变化例不过是一例，只要不损害发明的特征，则本发明并不限定于这些内容。本发明并不限定于上述实施方式及变形例，在不脱离本发明的主旨的范围内能够进行各种各样的变更。

以下的优先权基础申请的公开内容作为引用文写入到本申请中。

日本专利申请2014年第262091号(2014年12月25日提出)

标号说明

101：故障信息提供服务器；111：存储部；112：CPU；113：输入部；114：输出部；115：通信部；121：服务影响度通知部；122：服务影响度计算部；123：故障发生及修复管理部；124：日志统计处理部；131：车载终端管理部；132：通知信息管理部；133：服务结构管理部；134：计算规则管理部；135：预测规则管理部；136：日志统计值管理部；137：日志管理部；141：处理服务器群；150：因特网；151：利用者终端；152：车载终端。