根因诊断(寻踪)

服务的基本模型

我们先从“服务”这个定义入手，根据分形 的思想，以自相似和递归的方式来构建整个模型。

在 ITIL 的视角内，"服务" 被定义为，“为客户提供价值的一种手段，使客户不用承担额外的成本和风险就可获得所期望的结果”。所以，我们认为服务应当满足这样的几个要素：

• 接受服务请求（request）

• 响应服务结果（response）

• 交付一系列能力（capability）

• 需要消耗一些资源（resource）

并且这几个要素之间存在这样的关系：

• request 是外部给这个服务的输入

• response、capability 是服务的输出和表现

• resource 具有两面性，一是资源的供给（supplement），这也是服务的输入；另一面是资源的消耗（consumption）

服务的表现形式化给出，就是：

response, capability, resource_consumption = service(request, resource_supplement)

这样的模型，无论是在微观上的一个进程，或是宏观上的一个产品，均是适用的：

举例	request	response	capability	resource(supplement,consumption)
搜索	关键字	结果页	PV，相关性，速度，时效性，…	服务器、流量获取、人员、…
前端 UI 服务	GET /doc	HTML 结果	qps，时延，成功/错误率，size，…	带宽、cpu、内存、PS 后端计算、存储服务
后端存储服务	查询网页	网页内容	同上	硬盘，SSD
CPU	指令	运算结果	MIPS, CPI, CPU usage, …	电、槽位、机架位、制冷设备、…
硬盘	read/write	数据	rps, wps, svc time, wait time, io util, …	电、槽位、机架位、…

也即我们可以进一步将宏观上的某个服务，其所依赖的资源，抽象为另一个服务，后者同样需要接受 request、产生 response、表现出 capability，消耗了 resource resource 可以还是一个服务，…，形如：

response, capability, resource_consumption = service(request, resource_supplement, dependent_service)

于是，分形的感觉就显而易见了：

• 宏观个体和构成其的微观个体存在相似性

• 他们之间是递归的关系

这样一种从局部感知整体的思想，可以方便我们利用一些简单的、自相似的模型，不断递归来构建复杂系统模型

传送门

阿里云 DAS pyod