四 软件风险在何方
前面介绍了控制风险的方法，回到软件系统这个领域，它的风险又在哪里？
以软件系统为对象，从内看包括：计算系统和存储系统；从外看包括：人员，硬件，上游系统，下游系统；以及（隐含的）时间。
由于每个对象都是由其他对象组成的，因此每个对象还可以继续往细分解（理论上可以无限分解下去），上面的分解方式主要是为了简化理解。
1 软件系统风险的来源
风险源于（有危害的）变化，一个对象的风险来源于所有跟它有关系的对象的（有危害的）变化。因此，软件系统风险的来源，分为以下7大类：
计算系统变化：运行变慢，运行错误
系统运行所依赖的服务器资源（如CPU，MEM，IO等），应用资源（RPC线程数，DB连接数等），业务资源（业务ID满了，余额不足，业务额度不够等）的负载等都会影响系统运行的风险期望。
存储系统变化：运行变慢，运行错误，数据错误
系统运行所依赖的服务器资源（如CPU，MEM，IO等），存储资源（并发数等），数据资源（单库容量，单表容量等）的负载和数据一致性等都会影响存储系统运行的风险期望。
人的变化：变更出错
变更人员的数量，安全生产意识，熟练程度，变更的数量，变更的方式等都会影响变更的风险期望。
由于变更的人多，变更的次数也多，导致变更成为蚂蚁所有故障来源里的TOP1，这也是为什么“变更三板斧”这么出名的原因。
“变更三板斧”正确的排序应该是“可灰度，可监控，可应急”；可灰度代表的是R，可监控和可应急代表的是T。
思考：如果变更三板斧让你再加一板斧，你觉得应该是什么？
硬件变化：损坏
硬件的数量，质量，使用年限，保养等都会影响硬件的风险期望，硬件损坏会影响上层软件系统不可用。
上游变化：请求变大
请求分为3个维度：（由无数API汇集而成的）网络流量，（由无数KEY请求组成的）API，KEY。
- 网络流量过大会造成网络堵塞，影响网络通道中的所有网络流量请求。
- API请求过大会造成对应服务集群过载，影响整个服务机器上的所有API请求，甚至往外传播。
- KEY请求过大（俗称“热点KEY”）会造成单机过载，影响单机上所有KEY请求，甚至往外传播。
所以大促保障的时候，不仅仅是关注核心API的容量保障，还需要考虑网络流量和热点KEY。
下游变化：响应变慢，响应错误
下游服务的数量，服务等级，服务可用率等影响下游服务的风险期望。下游响应变慢可能会拖慢上游，下游响应错误可能会影响上游运行结果。
时间变化：时间到期
时间到期往往被人忽视，但它往往具有突然性和全局破坏性，一旦时间到期触发故障会导致非常被动，所以要提前识别，尽早预警，如：秘钥到期，证书到期，费用到期，跨时区，跨年，跨月，跨日等。
- 例如：2019年日本运营商软银因证书到期引发3000w用户长达4小时通信中断。
以上每一大类风险都可以基于nPRT公式进行逐一分析处理。
2 风险的数量：一生三，三生万物
任何一个事物既是由其他事物组成的又是其他事物的组成部分，无限循环下去；一生三，三生万物，风险的数量是无穷无尽的。
向内看，内含内，可以无限小下去；当原子粒度的问题传播开时，也可能影响软件系统的可用性，就像100纳米的新冠病毒就可以影响人体的可用性一样。
向外看，外有外，可以无限大下去；当太阳系毁灭，软件系统的可用性自然就不复存在。
虽然风险无穷无尽，但是只要我们对风险多一些了解，根据控制风险的一些理念和原则，还是可以更好的降低风险期望。
谈一谈敬畏之心：
- 我们对世界的认知是有限的，这也让我们少了许多恐惧，同时也让我们少了一些敬畏之心。
- 我们真正要敬畏的不是处罚条例，而是我们不知道的，以及我们不知道我们不知道。
五 结束语
- 所有事物都是变化的。
- 所有事物都不是100%可靠的。
- 因此才有了风险，风险是不可见的，可见的是故障。
- 风险是不能消灭光的，但是可以远离，可以减少。
- 故障是不可避免的，但是可以推迟，可以缩小影响范围，缩短影响时间。
nPRT公式不仅仅适用于软件系统风险，也适用于其他风险领域，希望对大家有用。
