网站宕机了,负责该服务的工程师却看着仪表盘说"我这儿一切正常"。这不是段子,是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年的同一家公司深耕——这些数字背后是真实的试错成本。他们的结论并不新奇:上下文比数据更重要,产品思维比技术堆砌更有效。但知道和做到之间,往往隔着一次真实的生产事故。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.