标签

工程效能

Kiwi TCMS 16.0:开源测试管理系统的大版本升级,有哪些值得关注的变动

来源: oschina.net 77
测试管理这件事,很多团队的做法是:自动化脚本跑完看一眼日志,手动测试靠 Excel 或 Wiki 记录,Bug 跟踪扔给 Jira。工具之间割裂,测试计划、执行记录和缺陷数据散落在不同系统里,回溯时全靠人肉拼凑。Kiwi TCMS 试图把这些环节收拢到一个系统中——手动测试用例管理、自动化测试结果汇总、Bug 跟踪器联动、权限控制和可视化报告,全部在一...

开源项目 CI/CD 安全:谁能在你的流水线里跑代码?

来源: cncf.io 78
过去一年,开源供应链几乎成了攻击者的游乐场。Axios 在 npm 上被劫持,正常版本里混进了远程访问木马;LiteLLM 的 PyPI 包同样遭篡改——这些都不是理论风险,而是已经发生的事。攻击路径往往指向同一个薄弱环节:CI/CD 流水线的执行权限。谁能触发 workflow?谁能往流水线里注入步骤?谁能拿到签名密钥?这些问题如果没想清楚,项目再火...

花 1500 美元让 LLM 黑自己的应用:一场真实漏洞挖掘实验

来源: oschina.net 43
安全研究员 Kasra 做了一件多数人只会想想的事——他掏出约 1500 美元,让多款主流大模型去攻击自己亲手写的应用,看它们能不能找到真正的安全漏洞。结果既让人意外,又让人清醒。 大多数 LLM 安全评测用的是人造题目:给模型一段有明显漏洞的代码,问它"这里有什么问题?"这就像把答案写在考卷旁边再问考生能不能看见。 Kasra 的做法完全不同。他构建...

Kimi Work 公测:把 Agent 落到本地,从写代码到做研究

来源: oschina.net 41
月之暗面把自家全员在用的本地 Coding Agent——Kimi Code——做成了更通用的底座,往上叠加金融、科研、办公等场景的 Skill,打包成 Kimi Work Beta 推向公测。这意味着"本地 Agent"不再只是程序员专属的工具,而是任何知识工作者装上客户端就能跑起来的生产力入口。 Kimi Code 是整个系统的内核。它每天服务几十...

Inspektor Gadget 首次安全审计:eBPF 可观测性工具的信任基石

来源: cncf.io 31
eBPF 正在重塑 Kubernetes 可观测性的底层逻辑——内核级钩子、零侵入采集、近乎无开销的运行时洞察。Inspektor Gadget 正是这一浪潮中的代表项目:它把数十种 eBPF 小工具打包成 Kubernetes 原生资源,一条命令就能追踪网络包、监控文件访问、抓取进程执行事件。但 eBPF 工具本身跑在内核态,权限极高,如果实现有漏洞...

数据中心断电零预警:Meta 的"瞬时断电风暴"验证体系

来源: engineering.fb.com 34
数据中心最怕的不是慢故障,而是"灯突然全灭了"——电网跳闸、UPS 失效、整排机柜瞬间掉电,零预警、零缓冲。传统灾备演练往往假设"有几分钟优雅关机时间",但现实中的断电不会给你这个窗口。Meta 近期公开了他们应对这类极端场景的测试范式 Instantaneous PowerLoss Storm,以及围绕它构建的纵深防御体系和验证方法。这篇文章拆解其核...

写代码不再是瓶颈:Spotify 如何把开发者体验扩展到团队与 AI Agent

来源: engineering.atspotify.com 53
Spotify 首席架构师在 Code with Claude 大会上抛出一个判断:写代码本身已经不再是约束了。真正卡住交付速度的,是团队协作摩擦、重复的基建搭建、以及工具链对 AI Agent 的不友好。他们的应对方式是——用平台工程把开发者体验(DevEx)从"个人写代码"的维度,拉升到"团队+Agent 高效运转"的维度。 这个判断值得认真对待。...

Google 全球服务舰队上的大规模 A/B 实验系统:如何让分布式实验不再打架

来源: infoq.com 41
Google 每天同时跑着成千上万个 A/B 实验——搜索、YouTube、Maps、Ads,每个产品都有自己的服务集群,每个集群又拆成几十个微服务。实验多了,问题就来了:用户在搜索页被分到实验 A,跳到结果页却被分到实验 B;曝光日志漏记了一条,结论就偏了;两个实验同时改同一个按钮的颜色,数据谁也说不清。 最近 Google 公开了它跨舰队的大规模 ...

Goa v3.28.0:大型设计生成时间从 46 秒降到 11 秒

来源: oschina.net 45
Goa 是 Go 语言生态中"设计优先"的 API 框架——你用 DSL 描述服务,框架帮你生成 transport 层、OpenAPI 文档、客户端代码。这个思路本身很清晰,但当设计文件膨胀到几十个 service、上百个 method 时,代码生成就会变成一件痛苦的事:跑一次 要等将近一分钟。v3.28.0 直接把这个问题砍到了 11 秒,同时还修...

pg_stat_statements 的沉默盲区:那些它看不到、记不住、悄悄丢掉的东西

来源: postgr.es 44
每个用 PostgreSQL 的人都会开 。它便宜、即时、不用装额外组件——查一下就知道哪个查询最慢、哪个调用最多。但用久了你会发现一些诡异的事:昨天还在列表里的关键查询今天消失了;p99 突然飙升但平均值纹丝不动;一个跑了 30 秒然后超时崩溃的查询,在视图里根本找不到踪迹。 这些不是 bug,而是 作为"一堆聚合计数器"的固有边界。上一篇文章讲了它...