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 任何源码。第三点是二次开发的原始动机。改动源码的基础是第二点。

这一部分的内容是 2025 年 5 月加入的，初稿完成时候我还没有修复这些 Bug。没有公司的条条框框，行文会更加奔放和随意。

ChaosBlade 是一个“缝缝补补”的项目，它一开始肯定是不支持在容器上进行故障注入的！在容器环境执行故障注入时出现了很多真正的 BUG，且多年来社区都没有修复（足以可见 ChaosBlade 广大的用户群体到底是怎么用这个产品的。那么多人都没有能力完成修复并提出 PR？）。maintainer 对这些问题的态度是“你们要用就自己修复吧”，所以我决定把这些问题都修复掉。但由于我对 cgroupv2 并不了解，也没有生产环境去验证，所以我以下很多内容都还仅停留在 cgroupv1 版本。cgroup 这个问题可以说是 ChaosBlade 社区里的“经典话题”，maintainer 一直在 画饼说某年某月（时间都改过几次）就能完成，结果每次都过去半年没有动静。大概阿里云内部也和 B 站一样永远留在了 cgroupv1 吧。

题外话：修复以下 3 个 bug 才是捣鼓 ChaosBlade 项目过程中最有意义和收获的经历。

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

摘录部分是原文的最后一部分。本文主要介绍了 bcm-engine 的未来。 标题《展望》是写个人博客时后取的。