Skyscanner可观测性重构：一个平台工程师的13年教训

网站宕机了，负责该服务的工程师却看着仪表盘说"我这儿一切正常"。这不是段子，是Skyscanner真实发生过的场景。

Wayne Bell和Dan Gomez Blanco在InfoQ慕尼黑峰会上还原了这一幕。两人曾在Skyscanner共事，现在分别领导平台战略和可观测性架构。他们用800多个微服务的实战经验，解释了一件事：为什么技术债会拖垮工程师效率，以及OpenTelemetry（开源遥测框架）如何成为解耦的关键。

从"我这儿正常"到全局可见

Dan Gomez Blanco现场演示了那个经典困境。当预订流程中断，他的仪表盘绿灯全亮，服务指标毫无异常。"我不知道我的服务怎么会导致旅客无法预订，"他说，"我这儿运行正常。"

Wayne Bell的角色是接起首席商务官的电话，然后意识到问题的根源——缺乏上下文（context）。没有上下文，工程师只能用直觉而非证据判断故障关联。

可观测性的三大支柱——指标（metrics）、追踪（traces）、日志（logs）——产生的是海量离散数据。Dan强调："上下文让我们能用证据回答这些问题。"没有它，三个支柱只是噪音。

平台即产品：把工程师当客户

Wayne Bell在Skyscanner待了11.5年，最后领导全球生产平台和开发者体验团队。他的核心方法论是：把内部平台当作产品来运营，工程师就是客户。

这个视角转变直接影响了技术选型。Skyscanner从供应商锁定的监控方案迁移到OpenTelemetry，实现了埋点代码与后端存储的解耦。"这让我们能自由切换供应商，而不需要重写所有埋点，"Dan解释道。

更深层的变化是组织文化。平台团队开始像产品经理一样思考：工程师的痛点是什么？上手成本有多高？当平台团队用客户思维替代"我提供什么你就用什么"的傲慢，采纳率自然上升。

技术债的隐性成本

800多个微服务的技术债不是抽象概念。Dan指出，老旧的可观测性实现方式让工程师在排查故障时浪费大量时间——写临时查询、上下文切换、猜测而非验证。

迁移到标准化方案后，Skyscanner的故障率下降，但两人没有给出具体数字。他们更强调结构性改善：当埋点规范统一，新服务自动继承可观测能力，不再需要每个团队重复造轮子。

Dan在平台工程领域工作了13年，履历包括CERN和Skyscanner。他的观察是：大多数公司的可观测性投资集中在工具采购，而非数据质量和上下文关联。结果是买了 Ferrari，却在开拖拉机。

为什么这件事值得现在关注

Wayne和Dan的分享发生在InfoQ慕尼黑开发者峰会，面向的是正在处理"关键软件挑战"的高级开发团队。他们的经验之所以具体，是因为经历了完整的周期——从单体到微服务，从供应商锁定到开放标准，从运维救火到平台工程。

Dan现任New Relic首席可观测性架构师，但他反复强调的却是减少对特定供应商的依赖。这种看似矛盾的姿态，恰恰说明了OpenTelemetry的成熟度：它不再是理想主义的开源项目，而是被商业厂商主动拥抱的事实标准。

对于管理数百个服务的团队，这个转变的ROI（投资回报率）计算很简单：每次故障排查节省的时间 × 故障频率 × 工程师时薪。当规模达到Skyscanner级别，这个数字会倒逼组织变革。

800个微服务，13年平台工程经验，11.5年的同一家公司深耕——这些数字背后是真实的试错成本。他们的结论并不新奇：上下文比数据更重要，产品思维比技术堆砌更有效。但知道和做到之间，往往隔着一次真实的生产事故。