小南伴你学-応用情報-第3期：令和5年春期問10（サービスマネジメント）

type

Post

status

Published

date

Jan 9, 2026

slug

summary

category

国家資格勉強

icon

password

先阅读第一段

考的是云服务的可用性管理。

L公司的主营业务是汽车部件制造与销售，公司发布在全国各地，白天晚上不间断的制造产品。

背后的有2个IT系统提供支撑，基幹係系统部署在本地，新的会計系系统部署在云上，是SAAS。

继续往下读

系统部门负责服务可用性和服务可持续性

这里给的表二a的地方，要填服务可用性的3个特性中的服务不间断的特性，叫什么

先看第一个问题

第一个小问，说法正确的是以下的哪个？

只要知道什么是MTRS和MTBF就可以回答出来

MTBF是系统正常运行的时间，MTRS是系统故障的时间

所以选什么？

正常运行的时间越久越越好，系统故障的时间越少越好

所以选

ア

第2个小问，说a里面要填5个字，我能想到的就是

信頼性

继续阅读

基幹業務需要高可用性，所以总部放的是2重系统，日常用其他的一个，维修的时候切换成备用系统，修好了再切换回来。

また？

数据怎么办？

数据使用全备份，备份2个，1个放公司里面，一个放公司外面。分开放

继续读下一个部分

这里出现了新公司，M公司。之前说了L公司的基幹業務系统是自己管理，那么新系统也自己管理就很麻烦，所以找了M公司，把会計系统给M公司来管理。

M公司提供了3个指标サービス時間也就是MTBF，サービス稼働率也就是可用性,計画停止時間,这个計画停止時間可不是BTTR，要注意

继续读

出现了b，是根据表4，系统故障数据多少属于合格？

先看可用性是多少

是99.5%

请注意，不要看表3计算，因为表3是サービスカタログ，表示M公司能够提供的服务菜单的一种。

而表4是双方决定的服务品质SLA。

1天20h提供服务，提供30天，承诺的可用性是99.5%

也就是100h，系统故障时间不可以超过0.5h。

其实也就是求MTTR

我们先得算系统运行了多久？然后就可用计算MTTR了

20*30=600

0.5*6=3h

3h=180min

继续读

3月的SLA达标了，但是しかし说光是达标不行，最好是不要给公司的支付业务带来影响

X说恢复时间也十分只要，就是要修的快，想给SLA加一个指标

看问题，找 ①サービスレベル項目问什么？

这里已经有3个指标了

分别是

MTBF，可用性，

缺一个什么？表示修的快的指标？

我觉得是サービス復旧時間　MTTR　或者MTRS，也就是一次不能坏太久。但是MTTR有一个M也就是平均下来不能坏太久，这里X的意思是，我们单次不能坏太久，所以是サービス復旧最大時間

继续读

说经理部门勤務時間变了，所以最好是信頼性再高点！

我们去看看，针对②経理部との調整，题目要问什么？

继续读

目前的MTBF（サービス時間）是1天20h

信頼性再高点应该调整说明指标呢？

我觉得是

経理部の勤務時間変更に合わせて、サービス時間を調整すべき，

但是答案是計画停止時間を考慮して経理部の勤務時間を定めること

为什么呢？

因为这道题要的是計画停止時間你觉得能不能改

如果能改的话，我一开始是觉得能改，所以直接把在上夜班的时候不停止系统，等没有人用系统的时候再停止

但是其实不能改

因为“计划停止时间”是云服务方在服务目录里事先规定好的前提条件，不是用户单方面能改的。

云服务必须定期做：

系统更新

安全补丁

数据维护

这些事不可能不停机完成，

所以云服务商会提前约好一个固定时间停机，对所有客户一起做。

不会因为你一个客户的需求，改固定停机时间，所以答案是，客户要根据画停止時間改上班时间

继续读下一个模块

太长了，我不读，我们先去看一下问题问什么

第1小问

问的是基幹業務系统M公司负责什么？

我们再反回去读文章，知道M公司提供的是Iaas

所以基础知识，Iaas的话，云供应商要管理什么？

我觉得是

硬件和虚拟化

也就是イエ

第2小问

上司说X说的不对，请问哪里不对？

文章说X想了3件事情

我读完之后，

觉得

第3个想法可能有问题，继续读发现，M公司提供的只有ユーザーデータファイル的同期、并不提供バックアップ，所以第3个想法是错的

第3小问

有基础知识的话，很容易，可用性的KPI就几个，一个是关于保守性的MTTR，一个是信赖性的MTBF

修的快不快，和运行的久不久

管理领域	代表性 KPI（考试必背）
可用性管理	服务稼动率、服务故障数、MTBF、MTBSI、MTRS、MTTR
イベント管理	事件件数、平均解决时间、首次解决率
问题管理	根本原因分析数、重复事件数
incident管理	变更成功率、失败变更数
ITSCM	灾害演练次数、RTO 达成率
サービスデスク	咨询件数、平均响应时间、一次解决率
キャパシティ管理	资源使用率、容量不足件数

所以选

ア、因为“服务故障数”直接表示“服务有多少次不能用”，而“能不能用”就是可用性本身。

第4大问

判断基准

文章说，公司没钱，所以发生灾难的时候，就不全部継続、就機能ごとに継続一部分就行、

这个老难了

機能ごとに事業に影響する度合い

跳过