我第一次出差给用户交付 HAMi 企业版，Helm 安装到一半就撞上了五六个漏打包的镜像，只能 Ctrl+C 停下来排障。

这在普通环境里也许只是补一次下载，在有些传统 HPC 或 IDC 环境里却完全不是一回事：文件要先刻录到光盘，经过可信设备，再从内网传到集群主节点。偏偏那天 MacBook Pro 还认不出 USB 光驱，一下午就这么没了。

当时我们交付的是一份 10 GB 左右的压缩包和一本安装手册。后来我才意识到：我交付的不是代码，也不是 Helm Chart，而是一整套要在没有公网的集群里跑起来、升级和排障的环境。

那也是我第一次负责 air-gap 环境交付。这篇文章最初写于 Zarf v0.76.0。2026 年 8 月，项目升级到了 v0.82.0，旧文里一些绝对判断也被实践推翻了。这一版保留当时的事故和选择过程，再补上后来踩到的 values、CRD、镜像架构和制品校验问题。

2026 年的今天：hermes agent、OpenClaw、各种各样的 CLI、skills、MCP，你方唱罢我登场。潮起潮落，最后剩下些什么？服务端的 API 一定仍然是企业内最重要的“资产”。

在此背景下，我们该如何产出 API 文档？特别地限定一下讨论范围，我们如何在 企业内部 产出 API 文档供其他 技术人员 使用？

本文所说的“文档”不限于形式，Markdown、YAML、JSON，人和 agent 有一方能读就行。 后文的重点将会是 O pen A PI S pecification YAML/JSON 文档（legacy named as Swagger specification）。

抛出这个问题之后，可能会有以下质疑：

• “AI Native” 时代了，还有这种需求吗？
• 这难道不是很成熟的技术吗？
• 人工编写文档怎么了？

接 上文，我想开发一个 CLI 工具，一行命令生成 Gin 等 HTTP/gRPC 框架的 API 文档。

Q4 断更至今，今天来输出一些碎碎念。我们抛弃繁文缛节，也不用大模型助力，直接上观点。由于单个 topic 的内容都不长，我就合在一起了。

ChaosBlade 和 kubectl exec 有什么关系？先说结论，ChaosBlade 里所有在 Kubernetes 中的故障注入本质上都在使用 kubectl exec 做 IPC（Inter-Process Communication）。ChaosBlade 简直是“云原生殉道者”，业务逻辑直接依赖 kube-apiserver。

如果您了解 kubectl exec 的工作原理，您就会知道这是一个非常“危险”的行为。什么？你觉得这是“站在巨人的肩膀上”？本文将反驳您这样朴素的想法。

如果您对这些话题的认知仅仅停留在 kubectl exec -it $podName -- bash，读完全篇，了解其背后的复杂链路与容器技术栈，跟你的运维/SRE 朋友炫耀一番吧！

真是 不看不知道，一看吓一跳，kubectl exec 完整串联了从 Kubernetes，containerd，runc 到操作系统的知识！ 读完本文，您将对 Kubernetes 内的长连接，CRI，OCI 都会有所了解。没在相关领域团队待过，如有疏漏还请在推特相关评论区/提 issue 狠狠批评我。

很多研发同学日常需要登录机器（物理机或虚拟机），读完本文你一定会有收获。 本文开头先抛出 3 个问题，足以总结全文内容，也能引起你的兴趣：

1. SSH 会话可以分成哪些种类？
2. ssh your-name@your-host，登上目标机器后执行 env 命令输出的环境变量是从哪些文件加载的？
3. ssh your-name@your-host -- env，env 命令输出的环境变量是从哪些文件加载的？

全文经过 GPT-5 的润色，与 strace 结果分析有关内容由 Claude Sonnet 4（沉思）参与完成。

设想一下，你的 Go 服务端程序的 main 函数里存在一些初始化逻辑，比如依赖注入框架 Wire 的 App 初始化，或者是自己手写的初始化逻辑。 阅码无数的你肯定见过在这期间使用 panic 来处理程序初始化错误的场景。请思考以下问题：

1. 所有的依赖组件初始化失败了都需要 panic 吗？
2. 如果某些依赖组件初始化失败了不需要 panic，那程序应该如何处理？
3. 组件初始化失败后能自愈吗？如何自愈？

每个团队，每家公司的答案都可能不太一样，本文不去深究这些问题的答案。作为“混沌工程领域”从业者， 我更关心如何验证这些答案的正确性，即如何制造故障来验证这些程序启动期间的表现是否符合预期呢？

我在 25 年 H1 完成了启动依赖演练的能力建设和功能推广。本文将分享该实验的背景、需求、方案、实践和成果。

这篇文章原本定稿于 2024 年 7 月 16 日，本以为老板要投稿到“哔哩哔哩技术”公众号上，后来却没有下文了。我认为这篇文章总结了我在 B 站很大一部分工作精华内容，包含了许多我的思考和有意思的技术细节。对“混沌工程”没有背景知识的读者不用担心读不懂，这篇文章主要讨论一些实际的系统实现问题。

这篇文章经过翻新打磨和新增内容后，字数来到了 16000 多字，读者反馈读起来非常费劲。为了让读者更轻松地阅读，我决定把这篇文章拆分成四章，并删去一些没什么营养的内容。目录如下，读者可以根据需要直接跳转到自己感兴趣的部分：

• 为什么 B 站还选择 ChaosBlade ？
• 如何改造 ChaosBlade ？
• 修复 ChaosBlade 遗留多年的 Bug
• 展望

以下是原文的最后总结，4 个章节仍以这个顺序编排：

BCM 团队在 ChaosBlade，Chaos Mesh 和 ChaosMeta 中选择了资历最老的 ChaosBlade 作为混沌实验工具，并以此为底座搭建了上层平台。本文介绍了上述 3 个项目的情况，阐述了选择 ChaosBlade 与放弃其余 2 个项目的理由；详细解释了对 ChaosBlade fork 版本 bcm-engine 的改造，修复与升级方案；并在最后说明了整个项目仍然存在的问题与可能的解决方案。

最后说一些扫兴的话，无论我做多大的努力，都改变不了一个事实：ChaosBlade 就是个典型的大厂“缝缝补补又三年，三年又三年”的屎山项目。 除非把它当做 “忒修斯之船”，整个用现代化 K8s operator pattern 改造一通才行，那这样一来它还能叫 ChaosBlade 吗？ 相信读完全部文章的你会明白我的意思。

这篇博文摘录于《bcm-engine —— 我们如何给 ChaosBlade 第二春》。原文原本定稿于 2024 年 7 月 16 日，本以为老板要投稿到“哔哩哔哩技术”公众号上，后来却没有下文了。我认为这篇文章总结了我在 B 站很大一部分工作精华内容，包含了许多我的思考和有意思的技术细节。 对“混沌工程”没有背景知识的读者不用担心读不懂，这篇文章主要讨论一些实际的系统实现问题。

摘录部分是原文的第一部分。本文主要介绍了当时国内混沌工程项目的现状，以及我们在选型时的考虑。 标题《为什么 B 站还选择 ChaosBlade？》是写个人博客时后取的。

TL; DR​

选择 ChaosBlade 作为公司新混沌工程平台的原因有以下几点：

• ChaosBlade 是国内最早开源的混沌工程项目，用户基础和企业用户数量最多。云原生程度 较低，适合团队技术栈。
• 其他项目（如 Chaos Mesh 和 ChaosMeta）都需要较高的 Kubernetes 技术能力，团队技术储备不足，且有较大的适配难度。
• 公司和部门对 ChaosBlade 有接入经验，存在较强的“路径依赖”心理。

这篇博文摘录于《bcm-engine —— 我们如何给 ChaosBlade 第二春》。原文原本定稿于 2024 年 7 月 16 日，本以为老板要投稿到“哔哩哔哩技术”公众号上，后来却没有下文了。我认为这篇文章总结了我在 B 站很大一部分工作精华内容，包含了许多我的思考和有意思的技术细节。 对“混沌工程”没有背景知识的读者不用担心读不懂，这篇文章主要讨论一些实际的系统实现问题。

摘录部分是原文的第二部分，并做出了一定的删减和结构调整。本文主要介绍了我们如何改造 ChaosBlade 以适应公司和产品需求。 标题《如何改造 ChaosBlade？》是写个人博客时后取的。

2024 年 H1，团队决定正式开启对 ChaosBlade 的改造和二次开发，新项目命名为 bcm-engine。

TL; DR​

改造内容：

1. 架构改造：移除不适合的 K8s 集群组件，在物理机上引入新的命令转发组件以更好地适应公司网络环境。
2. 仓库改造：分散仓库 => mono repo。
3. 本地化：绕开一些我们难以解决的设计/实现缺陷。

第一个改造项目并不需要改动 ChaosBlade 任何源码。第三点是二次开发的原始动机。改动源码的基础是第二点。