导读
风险量化是运维数据化的一个方面，在稳定性建设大盘中处于预防环节。风险量化是指：按照事先约定的打分规则，对各运维场景的人工操作结果进行分析，得出改进项、形成改进闭环。打分规则是否正确、普适、全面，决定了运维风险量化工作的结果质量。
背景
随着运维领域的演进，各项运维工作逐步精细化，普适的知识、经验、流程、规范等最佳实践逐步沉淀到了工具平台。一般可以认为，工具平台强制实施的最佳实践，最终都可以被完全信任。
由于业务差异、历史沿袭等原因，工具平台很难将所有的最佳实践强制实施，而是留下了很多人为控制的入口。如，部署工具通常会实现高峰期封线，但会留下一个紧急变更的操作入口、来做应急修复。人的决策、操作会受到了个人成长历史的影响，因此人为控制带来了结果的不确定性，风险量化主要针对人为控制的部分、不针对工具平台已经固化的部分。
要素
这里先给出运维风险量化的定义：按照事先约定的打分规则，对各运维场景的人工操作结果进行分析，得出改进项、形成改进闭环。有三个要素：运维场景，打分规则，改进闭环。
运维场景，一般要覆盖留下了人为控制入口的工具平台，如测试、部署、监控、预案等。
打分规则，一般要覆盖由人决策的配置、操作等，如监控采集配置、部署灰度操作。
改机闭环，一般可以包括提升人员认知、扩展平台能力两个方向。提升人员认知重在从流程、规范、经验等维度加强人对服务等运维对象的统一认知，扩展平台能力则是消灭人为控制的入口。
实施
风险量化要借助平台记录的结果数据，由工具完成数据分析，产出改进报表。人再根据报表内容实施改进，或是提升人员统一认知，或是进一步收缩运维工具平台的人为操作入口。
打分规则的最小单位一般是服务，会根据服务等级给与不同权重。打分规则是否正确、普适、全面，决定了运维风险量化工作的结果质量。打分规则的形成是整个风险量化工作的重点和难点。
应用举例
这里只是对打分规则的维度做了简单举例，具体实施过程还需要细化!
PS：实际制定打分规则时，可能会涉及到服务等级等信息，上述为了简化没有体现