流量翻倍，但成本降低86%！「芝麻街」制作方PBS的俭约架构实践

关注

原创 2025-03-31 15:30:21 1.1k 阅读 AI 写同款· GEO 优化 ›

K8s镜像拉取失败：5步定位与修复 K8s 镜像拉取失败时，反复删除 Pod 往往只会重新触发同一个错误。表示容器镜像未能拉取，kubelet 正在退避重试；这与应用启动后反复退出的不同。本文面向运行在 Linux 节点上的 Deployment，整理一条通用排查路径，不编造事故日志，也不把某个环境的结论当成所有集群的默认行为。检查命令默认只读；先确认集群、命名空间和 Pod。<...>表示读者需要替换的参数，不是真实资源名或凭证。标明“变更”的命令只能在获批后执行，不能把整篇文章当脚本一次运行。阅读详情

01/前言

1969 年，弗雷德·罗杰斯（Mr. Rogers）在美国参议院商务委员会作证，申请资金以支持公共广播的发展。他那番感人至深的发言被认为是美国电视史上的关键时刻，强调了教育类节目对公众福祉的重要性。

时至今日，这一使命仍在延续，美国公共广播公司 PBS 的 Mike 和他的团队也以自己的方式践行着这一承诺——将每一分公共资金都用到极致。

在资源有限但对高质量、易获取内容的需求不断增长的时代，这些工程师在幕后努力提高效率，利用创新性技术，确保每一分钱都物超所值。

在 PBS，我们的使命是教育、启发并娱乐观众。这一愿景始终指引着我们的每一个决策，甚至影响到我们的技术投资策略。我们并不追求成为下一个 Amazon Prime 或 Netflix，而是希望以最具成本效益的方式，为公众提供优质的内容和服务。

因此，解决方案并不总是“直接扩容更大的实例”或“增加几个只读副本”，有时，答案恰恰在于我们可以缩减或优化哪些内容，而不是简单地添加更多资源。

毕竟，我们使用的是公共资金—— PBS 的每一位成员都深知这一点，并将其融入到我们的思考与决策之中。

02/从被动救火到主动防患

我在 PBS 的旅程始于 2009 年，当时我以外包合同的形式加入公司，担任技术负责人，来负责支持团队维护和优化现有系统。一年后，我转向了其他项目。但到了 2014 年，曾经的上司联系到我，问我是否有兴趣担任技术运维总监一职。

由于要时刻关注系统运行状况，确保一切正常运转，让观众能够顺利观看最新节目，我个人其实很少有机会实时观看我们的节目。

经过几年这样的高压工作后，我在 2017 年做出了一个艰难的决定——离开 PBS。我想尝试一些新的挑战，也收到了来自一家盈利性公司的工作邀请，据说在那里我将拥有更大的团队，也能推动更多的变革。

然而，我很快意识到自己离开 PBS 是个错误的决定。

我怀念 PBS 以使命为导向的工作氛围，甚至怀念在非营利组织有限预算下工作的挑战。因此，我开始和前上司讨论回归的可能性，尽管当时我的职位已经有人接替。他给了我思考的选择，看看是否有我认为组织中缺失但又值得投入精力去改进的方向。

于是，我回到了 PBS，担任云架构师这一新角色，不再只是“救火”，而是专注于“防火”——让我们的系统更具弹性、可扩展性，并进一步优化成本。

关键的变化在于，我们不再只是被动应对突发问题，而是主动调整和优化基础设施，使其更加稳健和高效。这不仅是我个人思维模式的转变，也需要跨团队的紧密协作。

我们需要确保技术投资符合 PBS 的使命——在有限资源的约束下，为观众提供优质内容，同时确保资金的合理运用。

03/重新设计弹性架构

我们早期遇到的一个反复出现的挑战，就是如何应对重大事件带来的流量激增，比如新纪录片的首播，或者热门剧集的新一季开播。这些重磅节目总是会为我们流媒体平台带来巨大的流量激增，而我们最初基于 EC2 的架构年复一年地难以应对。

在许多情况下，我们会遇到“惊群效应”，比如当一封营销邮件发出，或观众在节目结束时看到屏幕上的“访问 pbs.org/masterpiece 了解更多”时，会有大量用户瞬间涌入网站。

同时，我们还要适应新内容发布模式的不断变化（比如首播当天上线、次日上线，或者一次性放出整季内容）。

为了应对这种情况，我们经常不得不紧急“救火”，迅速扩容服务器以应对流量激增，但等流量回落后，又会留下大量闲置容量。这种被动的扩缩容方式不仅成本高昂，还令人压力山大。

一个典型案例就是肯·伯恩斯（Ken Burns）执导的纪录片《越南战争》首播。当时，我们知道流量会上涨，但没有预料到峰值会如此之高。

当时，我们使用 Chef 和 OpsWorks 来配置和部署实例以支撑流量，但性能却十分不理想。我们花了很长时间才找到问题所在。

当时，我们的监控数据显示 CPU 使用率、内存、网络都处于正常水平，所以一开始并不明白系统为何会出现卡顿，唯一的应对方式就是不断增加服务器。

然而，最终我们发现问题并不在硬件资源，而是系统内部存在一些限制，比如打开的文件处理程序、进程和线程数量等。一旦我们发现并调整了这些限制，服务器的处理能力显著提升，能够在使用更少实例的情况下承载更大的流量，从而更高效地管理负载。

在这次纪录片首播过程中，我们经历了扩容方面的挑战，不得不熬夜处理各种问题。这让我们意识到，我们需要一个更具弹性和效率的架构方案。

于是，我们开始探索弹性容器技术。将平台容器化，并利用 Fargate 快速扩展和缩减基础设施，使我们能够在满足需求的同时，避免因服务器长期运行但未充分利用而导致的资源浪费。

举例来说，去年，即便计算资源的使用量和流媒体流量翻倍，我们仍然成功将计算成本削减了 86%。

从“救火”到“防火”：文化转变的挑战

虽然容器化和无服务器架构带来了显著优势，但转型过程却需要整个组织的文化变革。

我需要与产品团队密切合作，帮助他们理解 “性能和高可用性本身就是一项功能”，而不仅仅是交付某个看起来很酷的新功能按钮。

要实现从“救火”到“防火”的思维转变，我们必须保持持续的沟通和协作。

我不能简单地强制推行技术变革，而是要带领团队一起完成这次转型，向他们解释其中的好处，并帮助他们认识到这些变化将如何在长期内让工作变得更加轻松。

这需要一定的平衡，我既希望赋予团队足够的灵活性和创新空间，又要确保他们在做决策时能从整个系统的角度出发。

其中一个关键策略，就是设定一套清晰的边界，在界线范围的所有变更都被允许，而不是制定过于严格的规则。

我不希望成为“审批警察”，对每一次更改都要审核批准。因此，我建立了一个预生产环境（Pre-Prod environment），让工程师们可以在没有风险的情况下测试和试验新方案，同时创建了 Terraform 模块，用于展示符合 PBS 标准的基础设施管理方式。

我希望通过以身作则来推动变革，同时尽可能用自动化手段减少人为失误，让工程师们能够直观理解自己的决策带来的影响，并信任他们能做出负责任的选择。

投资可观测性，推动成本意识

要让这一切真正发挥作用，我们还需要加强可观测性（Observability），因为你无法监控看不见的东西。

我们构建了自定义的可视化面板和报告工具，使团队能够清晰地看到他们的云资源消耗情况、延迟指标和其他关键性能指标。

通过以易于访问的方式呈现这些信息，我们成功打造了一种关注成本、重视性能的文化。

最有效的优化，往往是渐进式的

在不断优化系统的过程中，我们认识到，仅仅关注技术是不够的，我们还需要考虑更广泛的环境影响。

这要求我们采取务实且迭代的优化方法。我们无法每隔几年就彻底更换整个基础设施，因此，我们必须精通渐进式优化。

无论是调整数据库实例规格，还是优化视频编码效率，又或是自动化数据清理流程，每一项改进最终都会累积成显著的成本节省和碳减排。

这不仅仅是为了节约开支——作为 PBS，我们要以负责任的方式管理资源，这样才能将节省下来的资金再投资于更优质的内容和服务，回馈观众。

优化《芝麻街》内容交付的案例

上述优化方法最具影响力的实践之一，是我们对《芝麻街》内容交付的优化工作。

早在 2009 年，当我们被邀请将《芝麻街》作为 Google Doodle 首页涂鸦展示时，我们就意识到，当时的本地部署基础设施根本无法承受预期的访问流量激增。

我们决定迅速将《芝麻街》网站迁移到 AWS，在这个过程中，我们不仅显著提升了内容交付系统的弹性和可扩展性，还积累了宝贵的云架构经验。

这次迁移成为 PBS 技术演进的一个关键转折点，证明了云架构能够让我们更加灵活地应对不断变化的需求。

04/打造俭约架构文化

这个故事并没有就此结束。

多年来，我们持续优化和完善内容交付系统，以支持日益增长的节目目录。其中，视频编码优化是我们重点关注的领域之一。

我们从传统的 AVC（H.264）切换到 HEVC（H.265）编解码格式，使得视频文件更小，从而减少存储占用、降低 CloudFront 的数据传输成本，同时也能够减少观众的流量消耗。

此外，我们启用了可变码率（Variable Bitrate Encoding，VBR），根据观众的网络状况来动态调整视频质量，在减少流量消耗的同时确保最佳观看体验。

对于不同类型的内容，我们采用了更具针对性的编码策略。

举个例子，对于占我们节目库很大一部分份额的儿童节目，我们通常选择较低的码率。许多孩子都是在低端设备或流量有限的网络上观看我们的内容，因此降低《芝麻街》等节目的流量消耗，能够直接帮助这些家庭减少月度流量费用。

我们认为，对于大多数儿童节目来说，观众几乎不会察觉 4K 和 720p 之间的显著差异，因此在这些场景下 720p 就足够了。

但对于画面质量要求更高的节目，我们仍然优先采用更高的码率和视频分辨率，以提供最佳观看体验。

部分优化由 AWS MediaConvert Automated ABR 提供支持，我们还借助 Mux Data 监测观众体验，确保我们的优化措施不会引发任何问题。

这些优化对我们的云成本产生了显著的影响。

在进行编解码切换和可变码率优化之前，我们需要人为地限制某个流媒体平台的最高画质为 720p 以降低成本。

然而，在 CloudFront 和 S3 账单大幅减少后，我们得以重新开放 1080p 高清流，让观众享受更高质量的视频体验。

通过主动优化和迭代的方法，我们在降低成本和减少环境影响的同时，依然能提供卓越的观众体验。

这些努力是我们在 PBS 培养俭约架构文化 的关键组成部分。

俭约架构文化的养成

培养俭约架构（Frugal Architecting）的文化并不容易，但它对我们的成功至关重要。我们必须打破团队壁垒、加强内部教育，并不断挑战各种可能性。

正是通过鼓励团队在成本和效率方面发挥创造性思维，我们才能在保持卓越观众体验的同时，始终践行 PBS 负责任管理的价值观。

为了达成这一目标，我们采取了一些关键措施：

定期分享成本与性能数据 —— 无论是某个新功能对云账单的影响，还是某项优化所带来的成本节约，我们都会公开展示这些成果，并以此强化团队的俭约意识。
打破工程师与产品团队的壁垒 —— 我们鼓励团队共同参与技术决策，而不是由工程师团队单方面制定架构策略。通过开放对话和相互理解，我们帮助产品团队认识到性能、安全性、可用性和成本优化也是产品特性的一部分，从而使我们的产品路线图更加一致，确保资源投入更有针对性。

当然，PBS 旅程仍在继续。

随着技术的演进和观众期望的变化，我们需要不断调整和优化系统。但我相信，俭约架构的理念将继续为我们提供坚实的基础，无论未来会遇到什么样的挑战，PBS 都能够始终专注于为观众创造有价值的内容。