实时报警和监控系统有助于我们实现全天候可靠性的目标。为了推进这一使命，优步工程公司建立了一个异常检测平台要在系统指标中查找和标记偏差，并通知呼叫工程师负责解决它们。
我们的平台建立了支持单一的预测模型，但我们的增长需要新的，每个都有自己的独特时间范围。我们选择使我们现有的平台模型无关，而不是从头开始划痕。此外，我们能够通过零停机和满载成功将此延伸整合到生产中向后兼容性。
在这里，我们讨论了我们如何为我们现有的异常检测平台推出模型无关主义，导致更强大，更可扩展的实时警报系统和整体更畅销的工程师的通话体验。
超级异常检测优步
2015年底，优步工程的观测团队建立了我们的异常检测平台的第一个迭代。从那时起，该平台已经发展到包含多个独立的部分，包括预测层和存储层。预测层(F3)生成周期预测，即与预测范数不同程度的偏差对应的有时间限制的浮点值集合。然后，该平台将预测传输到我们的存储层(Forecaststore)，用户可以检索历史和近期的预测，以获得更准确的预测。
我们的原始异常检测算法，时间表，间隔30分钟，并在我们现有的预测服务中实现为自包含的预测模型。最初部署在argos.， TimeTravel在预测其潜在的时间序列时假定了季节性。因此，对于更静态的度量(如监控CPU利用率或给定服务中打开线程的数量)中检测异常来说，这种方法是不够的。
2017年初，优步的可观察性应用和智能决策系统团队决定通过扩大平台的预测机制来解决这些限制，以包括更广泛的独特模型套件，从而扩展了对异常检测平台的有效用例的范围。
其中一个新模型是AutoStatic，它的设计适用于24小时预测;通过为长期指标铺平道路，AutoStatic允许用户依靠模型本身来确定最佳的“静态”阈值。
然而，当我们开始将AutoStatic集成到F3中时，我们很快发现了底层体系结构中的几个基本缺点。首先，F3的预测管道无法解释模型机制的变化。例如，一个产生未来30分钟有效预测的模型无法与预测未来5小时仍然有效的同行模型共存——f3的管道根本没有本地方法来解释这些变化。
另外，底层预测的数据模型在单个顶级映射中存储了所有阈值，该映射仅被阈值标识符键控。要存储由相同阈值对应的不同模型产生的值，我们必须创建和使用包含型号名称本身的专用阈值键，例如，ModelNameExtremelyHigh或者Someothermodelnameextremelylow，防止混乱和clobbering.其他模型的价值。AutoStatic模型的早期版本就是这样实现的，结果对于F3的开发人员和消费者来说都很麻烦，如下面的图2所示:
这些缺点进一步扩展了异常检测平台的模型舰队困难。我们知道进一步的发展只会加剧问题，所以我们采取了根本不同的方法。来自Timetravel的去耦F3使服务模型 - 不可忽视和可扩展。
为了完成这一重组，我们首先定义了更新的平台要求，下面概述。主要是，我们需要支持截然不同：
- 更新日程表。例如，Timetravel每半小时更新其预测;另一个模型可能每24小时这样做。我们的最终设计需要为更新不同时间表的模型提供支持。
- 预测阈值。所有模型都需要输出对应于相同严重性级别的阈值，例如，非常高兴或者略微，而不破坏其他模型的输出值。
考虑到这些规范，我们得出了一个设计，将现有的数据模型作为一个“集合”重新使用，并由各个模型确定范围。这个新的范式为我们提供了更大的可扩展性，从而使预测模型能够输出具有其自身有效期的阈值集。这为F3以及其生成的预测的任何消费者提供了消除模型及其相应输出之间歧化的原生能力。
通过模型明确地限定阈值范围还可以让消费者将模型选择逻辑与阈值选择逻辑解耦;毕竟，阈值语义在不同的模型中保持相同。最后，这个数据模型(如下所示)让F3在模型预测到期时更新模型预测，而保留其他预测不变。
实施和推出
但是，在我们执行之前，我们必须通过为顶级字段和向后兼容性提供支持，确保我们的新设计与我们的遗留平台互操作，这是一个功能，使平台开发人员继续迭代，独立于任何下游依赖项。
我们的新设计使这些需求略有意义。由于每个已弃用的顶级字段隐含地与一个模型 - 时间表 - 它们各自具有相对于新的模型特定字段的一个相应的访问器。结果，即使预测层完成填充遗留字段，存储层也可以使用其访问器施加属于这些字段的值，并将其注入查询时间的相应对象有效载荷。此策略允许根据自己的计划预测消费者在新的访问者字段上，同时也使F3团队能够继续在后端上生长平台。
这不仅是这种“赋予赋予和注入”模式确保了向后兼容性，但它还让我们改写较旧的预测结果（即，在引入这些新字段之前持续存储的那些）。换句话说，我们使用相同的策略来实施不仅仅是向后兼容性，还要使用向前兼容性。最终的结果是:平台扩展无缝地增加了生产者和消费者的灵活性。
关键的外卖
我们的项目说明了在数学建模和平台工程的交叉点上出现的独特挑战。此外，它还表明，无论应用于时间序列预测还是面向服务的体raybet手机app系结构开发，一般的工程最佳实践仍然广泛适用于各个领域。
具体而言，从平台角度来看，我们的研究表明：雷竞技是骗人的
- 不要把你的架构看作是一个静态的、不变的限制，而是一个有机的实体，它可以在面对变化的外部需求时适应和发展。
- 延伸看似无法可用于的系统，而不是从头开始重新设计它们，这可能是值得的，从而更容易支持历史使用模式。
从建模角度来看，该项目引起了注意孤立模型并将其集成到预先存在的生产系统中的挑战。特别地，假设必须分解为低级构造，此时必须重新加工以与现有架构集成，或者 - 如我们的异常检测平台所示 - 扩展到占新要求。
下一步
我们新发现的异常检测平台的可扩展性大大降低了预测模型集成的门槛，允许平台扩展以满足更复杂的用例。随着时间的推移，这种可扩展性将为优步的工程师提供更准确、智能和可操作的实时警报。
虽然我们的异常检测平台还有更多的工作要做，但上面概述的新扩展将为我们实时报警和监测系统的未来优化铺平道路。
如果您想授权Uber的工程师来监控其生产系统，请可观测性的应用程序团队很想和你说话。
