图16 技术链路示意图，其中每一个卡片标记放大倍数
根据前文流量预估模型计算终端接口QPS和技术链路后，也可得到链路上各层依赖的QPS。也因为平台上维护了技术链路元数据，让前文提到的从业务场景维度和活动全局维度关注流量成为一件可能实现的事情，否则以文档形式记载技术链路，很难做到这一点。
图17 Advisor上技术链路元数据模型
遗留的问题是，某个业务场景可能由于版本不同、用户身份不同导致技术链路不同，这里提供两种解决方案：
方式1：构造不同版本、不同用户身份多次抓包，Advisor支持将多次抓包合并作为最终结果；在此基础上，通过代码检查梳理结果是否全面。
方式2：Advisor根据线上真实请求汇总成完整的请求链路，再由技术同学从中择选S13涉及到的链路。
图18 基于完整链路择选
故障演练
S13中希望通过故障演练平台Fault（下文简称Fault）达到的目的是：正确识别到技术链路上的强弱依赖，强依赖应当确保有发现机制和预案手段，弱依赖应当确保可以自动降级，且降级后不影响该业务场景的核心功能。建议故障演练放在前置工作：
- 通过故障演练可识别S13的强依赖路径，便于更有针对性的进行压测、SOP。
- 故障演练发现的问题涉及代码改动，压测应当基于改动后的代码。
日常演练的做法是以接口维度将其中的故障点依次注入故障（可参考B站故障演练平台实践）。但S13的60 业务功能，逐一验证接口，时间成本太大。因此，将演练优化为两大步骤：
Step1：优先确定面向终端的接口的强弱。如果某个接口故障并不影响该业务场景的核心功能，则定义为弱依赖。例如进房场景，通过验证全屏/竖屏观看、唤起礼物面板送礼、在弹幕区发送弹幕互动等几个核心功能，从20 个接口最终确定4个强依赖接口（见表3的强弱依赖标注）。
Step2：针对Step1筛选出来的强依赖接口，联同质量工程效率团队建设了面向业务场景的故障演练，以业务场景维度整体验证。将Advisor的技术链路导入Fault，Fault自动将标注预期是弱依赖的依赖点组合排列，自动依次注入故障和调用自动化用例验证表现。
图19 Step2示意图
