让可观测性变得有趣：我们如何通过游戏提高工程师对事件管理的信心
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
在 Skyscanner，和许多组织一样，团队倾向于为单个故障模式遵循特定的运行手册。随着现代复杂分布式系统的发展，这带来了大多数错误都是未知的缺点，这使得运行手册只能部分适用。
在 Skyscanner 将我们的遥测数据迁移到 OpenTelemetry 标准后，我们现在拥有更丰富的仪器，并且可以直接依赖可观测性。因此，我们已准备好采用一种新的 可观测性思维模式，这需要培训我们的工程师有效地使用新生态系统。这使他们能够对任何已知或未知的问题做出高效响应，即使在压力下。
为了实现这一点，我们认为获得知识的最佳方式不是通过一次性观看文档或视频。相反，而是通过实践练习，包括从未见过（或至少很少见过）的问题场景。这有助于公司减少解决问题的时间（TTM），TTM 从第一响应者确认事件开始，一直到用户停止遭受事件影响为止。
环境
首先，我们需要设置一个环境，该环境演示了使用 OpenTelemetry 仪器和可观测性进行监控和调试的最佳实践。为此，我们建议使用官方的 OpenTelemetry Demo，这是一个名为 Astronomy Shop 的分布式系统的真实示例。借助 OpenTelemetry Protocol (OTLP)，我们可以简单地将 Collector 中的标准 OTLP 导出器指向 New Relic，这是我们在 Skyscanner 选择的可观测性平台，与其他平台一样，它完全拥抱开放标准来接收遥测数据。
该系统包含可注入平台的回归，并帮助我们展示服务水平目标（SLO）、跟踪、日志、指标等的重要性。例如，我们可以观察通过各个组件的流量，如下图所示。由于 OpenTelemetry 生态系统的一部分是开源的，我们可以轻松地引入任何新功能，这些功能将由 OpenTelemetry 贡献者进行审查。
可观测性游戏日
一旦环境设置好，我们就可以引入可观测性游戏日，这是一个基于 Google 在 Site Reliability Engineering book 中使用的“命运之轮”实践的倡议。
这个游戏模拟了一个生产事件，其中一位被称为游戏大师（GM）的主持人主持会议，观众中的某个人旋转命运之轮并解释一个事件或故障。然后，参与者被分成团队，并负责尽快识别和解决问题。如果解决方案不是最优的，GM 可以通过引入新工具或视图来提供帮助，这提供了不同的解决事件的视角（知识共享）。此练习可以针对不同的事件重复多次。
结果
多个 Skyscanner 团队已经完成了可观测性游戏日，每个团队的可观测性专家（大使）都会主持会议。参与者给出了非常积极的反馈，90% 的受访者表示在游戏日之后，他们对调试生产系统更有信心，并希望有更多的会议。
- 针对真实服务进行测试，并比较和对比不同的调试方法，这非常有价值。我确信每个人，无论技能水平如何，都能从会议中获得一些东西——我知道我做到了！感谢您花时间设置并为我们推广它—— Dominic Fraser（高级软件工程师）
- 这是一项非常棒的（公司范围内的）倡议，可以帮助人们提升在可观测性以及 OpenTelemetry/New Relic 方面的技能，我个人觉得它非常有益，而且很有趣！:D - Polly Yankova（软件工程师）
此外，我们还学到了
- OTLP 使标准应用程序与可观测性供应商的集成变得非常简单。只需将其指向正确的端点即可完成工作。
- 我们的获胜团队主要依靠跟踪数据来分析回归，这有助于他们更快地理解根本原因。跟踪万岁！
- 前端工程师认为游戏日缺乏对客户端可观测性的关注，因此我们决定向上游贡献（请参阅下面的后续步骤）。这是我第一次为该项目做出贡献，这是一次很棒的经历！维护者们非常友好，并帮助我进行了测试和发布。谢谢！
下一步
接下来的行动是为公司所有工程团队运行会议，并将它们转化为 Skyscanner 学习课程。这样，内容就可以在新加入者入职期间使用，或者供在公司工作时间较长的员工随时回顾。此外，在观察到普遍反馈后，我们认为扩展当前事件以包含更多特定于前端的事件会很有益，例如由浏览器流量触发的事件。为了实现这一点，我们向 OpenTelemetry Demo 贡献了功能，并为其他感兴趣的各方启用了这些功能。有关更多信息，请查看 已提交的 PR。