当Jake Paul与Mike Tyson于2024年11月登上拳台时,这场比赛同时向大约6500万个并发流进行了直播。在普通的一天,Netflix的基础设施要处理超过20亿次请求,并且每秒处理多达3800万条实时日志事件。在这种规模下,整体情况已无法装进某个工程团队的脑海,也无法呈现在单一仪表板上,要足够快地理解系统以保持用户体验完好,变成了一项艰巨的搜索任务。
不妨看一个典型的性能回退:主页渲染时间大约增加了1.5秒,随即触发告警。原因可能出现在系统的任何位置:可能是客户端应用发布或A/B测试推出,可能是基础设施中的负载削减,也可能是由于六跳之外的某个服务发布而导致GraphQL查询返回错误数据。要回答“是什么导致了问题?”,需要细致地逐层梳理数据。
指标、事件、日志和追踪,合称MELT,是这项调查的合适原材料,而每一类大约只能回答问题的四分之一。Netflix将这四大支柱统一到单一的可观测性数据层中,使工程师能够实时观察用户体验、应用健康状况和后端行为。在该示例调查中,修复耗时四个小时,其中很少的时间用于高强度计算。大部分时间都花在重建系统早已知晓、却从未以人或机器易于读取的形式记录下来的关系上。
根本问题在于,Netflix的工具内部协调一致,但彼此对外隔离。Atlas了解应用程序和时间序列,Radar了解阈值和告警历史,incident.io了解严重级别和响应人员,PagerDuty了解轮值安排,Spinnaker了解何时发布了什么。Slack历史记录保存着上个季度哪位工程师解决过类似问题的知识,但任何查询引擎都无法触及。更多数据或更好的仪表板只能带来边际改善。在缺乏准确上下文的情况下,AI智能体同样力不从心,因为它们可能产生幻觉,并把值班工程师引向错误的方向。真正需要的是一个将这些系统连接起来的互联知识图谱。
来源: Hacker News · 由HeadlinesBriefing整理摘要