Manjusaka 的碎碎念（以及摇曳露营 S4 2027 放送予定）

https://www.youtube.com/watch?v=N0QfgZsDBv8&t=4235s 推荐一下（

https://dl.acm.org/doi/10.1145/2517349.2522727 https://www.usenix.org/conference/osdi16/technical-sessions/presentation/xu 推荐两篇经典论文

突发恶疾，maimai 瘾犯了

有测试开发在找工作么（我们组目前有测试开发的 HC），简而言之，我们现在 AI 开发迭代速度太快了，我们需要专门的人来做测试基建，包括不仅限于 1. 去理解业务，帮助业务沉淀合理的 E2E 测试，删除冗余的测试 2. 梳理现在测试基建的情况，基于 Kubernetes/Managed Agent 梳理一套从端侧到API测得通用的测试基建复用不同的业务 3. 通过积累 Skill 等方式帮助同事的 CC 写出更好的测试 整体来说画像会偏通用的研发，但是希望能比较会找茬，以及愿意贴身参与业务迭代（有兴趣可以联系 me@manjusaka.me)

哎哎哎哎哎，想玩 NVL72

https://space.bilibili.com/3461562830424779/lists/8682435?type=season 推荐对 AI Infra 感兴趣的可以去看看北大超算俱乐部这系列的科普视频

前两天聊了一下关于 SRE/Infra Team 的一些 AI 时代的想法，今晚也在碎碎念一下 在我看来，SRE/Infra Team核心的存在的意义只有一个，即为业务服务，这是SRE/Infra Team唯一的一条 Tier0 规则，换句话说，SRE/Infra Team做事的规则和节奏都是基于这条规则来进行构建的 我们都是 Product Engineer ，只是我们的方向会更偏 Infra/稳定性 一点，如果大家从这个视角看那么很多问题会迎刃而解 在这个基础上，不要给自己设置很明确的 margin，限制自己去只能做什么，通常给自己预设的一些 Role 只是希望帮助自己可以在一个阶段内能找到自己的主线任务。如果发现什么事情做了对业务会有收益，那么不需要顾虑，去做。 在这个过程中，SRE/Infra Team会涉及到很多和外部合作的部分，包括部署应用在内的很多需求。在这个过程中，我会要求自己从 Day0 开始，就去了解你的业务方在做什么，我要维护的功能是什么，这里是否有我可以顺手帮助业务同学做了的最佳实践。还是请记住一句话，我们都是 Product Engineer 。很多时候有新项目进入到我们的迭代节奏的时候，这意味着我们是和业务同学同样的需要对这个项目结果负责的 pair programming 的角色。交付不是我们的目的，而只是让我们参与项目的一个契机。 所以在这个基础上，不需要对于 Deadline 有太多的顾虑，我们做好一件事比做完十件事重要的太多。 差不多就是这样，AI 时代对整个 SRE/Infra Team 的影响是巨大的，有更高的需求，也有更高的要求，但是本质上就还是要践行一个原则：为业务服务。

https://fixupx.com/plantegg/status/2088608730615287923 再多说两句，我觉得讨论上下云的优劣性无可厚非。但是搞出一个权力寻租的潜台词我觉得就挺无聊的了 有一说一，公有云反而是权力寻租空间最小的地方。目录价基本上是统一的，你各个消费额的用户折扣也大差不差，以阿里云为例，你GC6和GC7就泾渭分明。你要说有没有其余的商务考虑，比如作为融资的一部分啊，附加其余的商务合作啊，那肯定有，但是不在权力寻租的范围内。 但是你要搞私有云，那说法可就多了啊。你都是 D5 4800 的条，镁光，海力士都不一样，还有很多很细节的地方都能很细致的谈。还有比如啥搭一些老硬件啥的 你一个单子谈下来，彼此之间即便同样的硬件，价格差出50% 以上的也一堆。你心大一点的，你吃个10到20回扣也能舒服吃。真要打工人要多考虑点，确实应该鼓吹下云 各家搞 IT 采购的每年廉政通报上都见得不少吧？是高发区吧 那我是不是可以说，下云支持派的都是为了在采购这件事上多点话语权，给自己狠狠捞一笔？ 不能吧，很无聊的一件事。我觉得技术讨论就技术讨论，没必要扯太多场外因素。真要是扯起来，各种硬件大额采购绝对是 IT 圈子里最混沌的区域了

https://fixupx.com/RonVonng/status/2088581115145859547 一些观点认同，一些观点不认同 开宗明义，我认可成本收益曲线这个说法。如果不把业务性质考虑进来进行成本计算，那么这个成本衡量的有所偏颇。 比如我天天讲的合规的例子。举个例子对于很多初创 toB 服务的企业来说，SOC Type II 是个绕不过去的坎。某种意义上来说这是一个敲门砖。 比如其中的一部分审计 1. 对网络资源的物理和逻辑限制可防止未经授权的访问 2. 实施控制措施以防止未经授权的变更和管理任何 IT 系统变更 自建机房需要去准备的审计材料和合规治理的复杂度远高于云厂商（而且这不是一次性的投入 XDDD）。 同时部分业务形态也决定了天生的云是更亲和的。举个直接的例子，假如你是一个数据相关的 startup，你需要帮用户处理/存放各种海量数据。你的用户群大头都在 AWS，GCP，Azure 等公有云上。那这个时候，你只能选择和不同的云厂商进行深度绑定，依托很多基础设施，处理诸如 privatelink 这类的细节 就还是那句话，Basecamp 是个很好的例子，但是坦白说 Basecamp 不代表着上下云的金标准。 在现实发展中，Basecamp 这样下云的黄金场景太少了 1. 业务增速相对稳定，对于硬件的需求相对稳定，基本无潮汐流量场景 2. 无多区域合规部署需求 3. SRE 团队素质极高且人员配置足够（他们应该是接近1:5 的 SRE 比研发数量，可能会更高。而且他们 Per personal 薪资应该是不低于 18w USD/year) 关于 1 可以在举个例子，目前硬件的发展极为迅速，我们今年年初全部换到了第五代AMD EPYC，相较于之前，我们整体的成本下降了，原因很简单，单核性能提升非常大 而我们现在也有很多 GPU 服务在从年初开始的从 T4 比较老的实例因为业务关系在逐渐切到 L4 实例。还有很多硬件规格因为业务场景需要调整的场景。我估计这个换谁来搞3年/5年摊销都一头乱麻 就还是那句话，如果创业公司业务变化极快导致硬件需求变化极快，那么下云就是作死

有一说一，你别说，Service Mesh 在 AI 时代反而会更有用了

最近在「壹个村小」成都夏令营做了几周义工，跟创始人聊了很多。 他 06 年本科计算机毕业，做了三个月开发后发现并不是心之所向，去云南支教，后来和同行的小伙伴一起创立了这个公益助学组织，到现在做了接近 20 年。 组织的官网是他 2008 年用 Adobe Dreamweaver 做的，用的 ASP 和 Microsoft Access，到现在几乎不可维护，于是在义工期间我回归自己的本行，花了一周多使用 Next.js + Postgres 完全重构了整个网站页面、DB 数据结构和所有的后端逻辑，在这周一正式上线了。 创始人跟我说，他们的大量时间花在了捐助人和学生之间的信息传达和沟通上，现在每年新增学生大概七八百，同时在管理的学生两三千，有这样一个更好的系统省下的时间，或许能让他们跟更多的学校和学生去家访沟通，每年或许能有更多的容量帮助到更多的学生，哪怕只是几十个。 在 AI Coding 的时代，时常觉得代码已经毫无价值，但当这段代码真实地与现实生活产生了链接，给一些学生带来了帮助，这种意义感无可名状。 这或许不是我做过的最复杂的系统，但产生的成就感与价值感远超其他所有的工作或是项目，或许人总该去追求一些心之所向的东西，会觉得技术有时候也可以是美好和意义的载体。 于现阶段处在生活拐角的我来说，这也无异于一种救赎。 https://www.one-school.org/

只能说愿大家老而不登

jeff dean 跑路了 https://fixupx.com/jeffdean/status/2085034604172603724

FFmpeg 9.0版本刚发布了。这个版本的代号是“Lei” 按照惯例，“Lei” 应该是哪个计算机科学家/数学家，可想了好久也对不起来这是谁。 查了一下FFmpeg的开发邮件列表，才发现原来是纪念已故的@雷霄骅 [蜡烛]。 他在 2013–2016 年间撰写了大量 FFmpeg API、源码分析及音视频编解码、封装和传输协议方面的中文教程与示例，帮助许多中国开发者入门音视频和 FFmpeg。于 2016 年疑似因过劳突然离世。 今年是离世10周年，FFmpeg用了这个大版本号来纪念他。 ▎Source

https://fxtwitter.com/AikidoSecurity/status/2084584370556530882 Node.js 生态核心库之一 Keyv 被上游供应链攻击，请注意防范

测试

卧槽，我怎么把评论群组删了

推荐所有人看摇曳露营！

PyCon China 2026 报名正式启动啦！欢迎大家到现场玩！ ps：讲师，赞助商，合作社区，志愿者都在持续招募中，欢迎大家一起加入！！ 报名链接：https://www.huodongxing.com/event/6870624098800 官网：https://cn.pycon.org/2026/