爱奇艺广告平台的架构设计与演进之路

自动运维系统架构

1. 问题发现和分析定位

业界通用的方式是全链路追踪系统（dapper & zipkip）和智能运维，我们也在正在进行这方面的工作；除此之外，我们还做了另外两件事情：异常检测和 Staging 环境建设；

异常检测：主要是从业务层面发现各种宏观指标的异常，对于广告投放系统、库存量、曝光量、点击率和计费率等都是非常受关注的业务指标；异常检测系统可以预测业务指标在当前时刻的合理范围值，然后跟实时数据作对比；如果实时数据超出预测范围就会发出报警并附带分析数据辅助进行问题分析；这部分工作由在线服务和数据团队共同完成，这个系统有效地提高了问题发现的效率。

爱奇艺广告平台的架构设计与演进之路

Staging 环境建设：系统变更（包括运维和新功能发布）是引起线上故障的主要原因，所以我们需要一个系统帮助我们以很小的代价快速发现变更异常。

在功能发布时大家都会采用梯度发布的方法，譬如先升级 5% 的服务，然后观察核心指标的变化，没有明显异常就继续推进直到全量；这个方法并不是总能有效发现问题，假如一个新功能中的 bug 会导致 1% 的订单曝光下降 50%，那么在全量发布之后系统的整体曝光量也只有 0.5% 的变化，也可能因为其他订单的填充使得整体曝光量没有变化，所以仅通过整体曝光量很难发现这个问题。只有对所有订单的曝光量进行对比分析才能准确地发现这个问题。

我们在实践中利用向量余弦相似度来发现系统变更引起异常，即把一段时间内（5min）曝光的广告数量转换成向量并计算余弦相似度。那么如何得到两个向量呢？可以按照梯度发布的时间进行分割前后各生成一个向量，这个方法不够健壮，不同时间的向量本身就有一定的差异。

我们是这样来解决的：部署一个独立的投放环境（我们称为 Staging 环境，相对的原本的投放环境称为 Base 环境）承载线上的小流量（譬如 3%），所有的系统变更都先在这里进行；然后用 Staging 环境的向量与 Base 环境的向量进行相似度计算。

因为对差异非常敏感，使用余弦相似度做监控会有误报发生；不过这个并不难解决，通过一些 bad case 的分析，我们定位并消除了两个环境之间的差异（非 bug）因素；在正常情况下两个环境的相似度会保持在 95% 左右，并在遇到真正的异常时会有明显的下降触发报警。Staging 环境及相似度检测功能在实践中多次帮助我们发现系统异常。