下载掌阅APP，畅读海量书库
立即打开
量化分析体系是基于数据对系统进行量化、定位和分析，然后产生相应的治理措施，指导接下来的线上治理和线下治理，接下来从度量、定位和风险分析这几个维度对量化分析体系进行展开讨论。
稳定性工作包含的内容很多，在稳定性建设过程中，经常会遇到这样一个问题——服务当前的稳定性现状，不太好衡量和判断。比如，服务变更一直以来是影响服务稳定性的重要因素，由于没有明确的衡量标准和规范，很难说清楚服务变更做到什么程度才算是符合稳定性要求的变更，这样会导致执行服务变更的同学很难发现自己平常工作的不足，同时团队的管理者层面看不到自己团队变更风险的全貌和严重程度。服务变更只是稳定性建设的一个缩影，稳定性建设的很多维度和服务变更类似。
为了掌握稳定性建设的真实情况，同时引导和规范业务同学在稳定性建设时的做法，针对稳定性的一些重要环节，需要制订一定的度量标准，对业务同学日常的稳定性建设进行度量，明确告诉大家当前的稳定性工作处于什么水准，具体哪些地方需要改进。
以服务变更为例，流程规范规定高峰期不能上线，平台可以强制规定不能在这个时间上线，但一定会有紧急的需求需要在高峰期操作，所以平台还必须放开这个口子。这类操作带来的风险也是确确实实存在的，它不应该被经常执行；比如灰度检查通常暂停的时间越长越有可能发现问题，但平台只能约束至少有暂停或暂停一个固定时间，更长的暂停时间则由执行者把握。诸如这些问题，可以结合变更规范制定一个量化标准——更信用分标准。比如 变更信用分 标准可以规定，暂停时间越长分数越高，高峰期如有操作则需要扣分，同时不同优先级的模块采用不同的标准，最高优先级的模块有强制双重校验的要求，需要两个人校验后才能在平台上线，如果没有在平台执行这个要求也需要扣分。按照变更信用分标准，对每周的上线单进行系统分析，并按团队汇总、量化和排名，让大家能从全局的角度看到问题的总体情况和各自的严重程度，并能够从上往下索引到各个团队具体的变更单、变更人和变更参数，甚至直到具体的变更模块配置界面，以此促进各个团队有针对性地发现变更风险并清晰地知道如何进行完善。定期将每个团队本周的变更评分情况，以及存在变更风险的变更操作单，发送到对应团队的负责人与变更风险单的实际操作者，方便业务人员了解当前的变更风险，并及时针对性地进行改进。
针对稳定性建设的其他方面，我们也可以按照上述变更信用分的思路，建立相应的度量标准。比如 监控告警 ，针对基础监控是否有遗漏配置、上下游依赖健康是否完备、告警策略是否符合要求等情况，可以推出监控健康分，量化服务监控告警的完备情况，引导用户进行监控告警的完善工作。比如预案建设方面，可以推出预案健康分，量化一个服务的预案建设情况，涉及降级限流等预案是否完备，预案执行是否符合灰度要求，预案是否可以回滚等。
对于稳定性度量来说，主要是确定具体的度量指标，以及每个度量指标的标准评分。其实具体评分并不是那么重要，关键是大家对度量标准能够达成一致，能够对稳定性日常工作有实际的量化指导效果。
线上服务出现问题时，当有足够多的监控信息时，才能直观地定位问题。但随着业务规模变大，微服务的个数越来越多，链路、拓扑、网络越来越复杂，相应的监控事件越来越多。当出现故障，可能瞬间出现大量的报警信息，从众多告警中快速找到故障原因，确定相应的止损预案，是一个非常重要且有挑战性的事情。
出现故障时，首先需要确定故障的影响面，可以基于场景和分布式跟踪拓扑将业务组织成一个全局的“灭火图”，灭火图中包括所有核心服务的可用性指标，比如错误率、QPS、耗时等，出现故障时，先从灭火图中看出故障影响的业务和服务，接下来确定故障定位的范围。
为了从纷繁复杂的众多事件中定位具体的原因，可以将各维度的监控报警、各种变更事件以事件的方式，按照时间轴整合成一个时间线，有了事件时间线，我们就可以将关注焦点放到故障时间前一段时间内的监控告警事件以及变更事件上，从而根据具体的事件类型确定相应的预案和止损措施。
基于线上实时的可观测数据，以及研发全流程的变更和操作数据，我们可以得出很多维度的报表和趋势数据。这些维度可以涵盖服务治理的各个环节，比如链路SLA、超时重试、容量管理、强弱依赖关系等，这些数据可以作为接下来分析的基础。
同时，根据之前的风险分析以及一些静态的服务元数据信息，会形成一个和当前实时治理数据对应的历史基准库，将当前数据和历史基准库进行比较，从中找到趋势和规律，进而发现潜在的风险。
实时治理数据分析后一些有价值的东西可以沉淀到历史基准库，作为后续风险分析的基础，进而形成一个风险分析的闭环机制。在基于风险分析的在线上治理和线下治理中，会结合具体的场景和实例进行全面的剖析。