根因诊断(寻踪)
服务的基本模型
我们先从“服务”这个定义入手，根据分形 的思想，以自相似和递归的方式来构建整个模型。
在 ITIL 的视角内，"服务" 被定义为，“为客户提供价值的一种手段，使客户不用承担额外的成本和风险就可获得所期望的结果”。所以，我们认为服务应当满足这样的几个要素：
接受服务请求（request）
响应服务结果（response）
交付一系列能力（capability）
需要消耗一些资源（resource）
并且这几个要素之间存在这样的关系：
request 是外部给这个服务的输入
response、capability 是服务的输出和表现
resource 具有两面性，一是资源的供给（supplement），这也是服务的输入；另一面是资源的消耗（consumption）
服务的表现形式化给出，就是：
response, capability, resource_consumption = service(request, resource_supplement)这样的模型，无论是在微观上的一个进程，或是宏观上的一个产品，均是适用的：
搜索
关键字
结果页
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)于是，分形的感觉就显而易见了：
宏观个体和构成其的微观个体存在相似性
他们之间是递归的关系
这样一种从局部感知整体的思想，可以方便我们利用一些简单的、自相似的模型，不断递归来构建复杂系统模型
传送门
Last updated