谁会在故障发生前买下它？

2025 年 11 月 18 日，Cloudflare 的网络开始呈现一种反复波动的状态：服务中断，恢复，又再次中断，几乎每五分钟一次。团队最初以为网络正遭受大规模网络攻击。根据该公司之后发布的报告，原因更离奇，却远没有那么戏剧化：一次数据库权限变更，使机器人管理系统（Bot Management）使用的特征文件内容翻倍。文件传播至网络设备后，超过了软件能够处理的上限。一次合法更新由此引发大范围故障 S01。

这个文件并非每天早晨随公告发布一次，而是通过 ClickHouse 数据库查询，每五分钟自动更新。部分节点已经收到权限更新，另一些尚未收到，因此系统有时生成正常文件，有时生成翻倍文件。服务一度恢复，使观察者误以为故障或许来自起伏不定的恶意流量。等到大多数服务器开始生成错误版本，故障状态反而稳定下来。根据同一份报告，到协调世界时（Coordinated Universal Time; UTC）14:30，主要流量大体恢复；直到 17:06，公司才宣布所有系统回到正常状态 S01。

五个月前，即 2025 年 6 月 12 日，Google Cloud 服务经历全球性中断。这次问题同样不是由攻击或入侵开始。一次配额策略更新写入了含空字段的数据，并把它传播到全球，随后触发一条无法处理空指针（Null Pointer）的代码路径。即使根因已经确定，重启浪潮仍拖慢了部分地区的恢复，因为复原请求给所依赖的数据库带来压力 S02。

两家公司不同，软件也不同，但两起事故之间存在值得研究的工程关联：系统并非无法应对罕见灾难；它把意外输入当成不可能出现的输入，再以机器的速度与确信传播了这一假设的后果。

事故会留下长篇报告。工程师阅读报告，在会议中讨论，最后把它收入人类经验的档案。几个月后，同一类错误可能出现在另一家机构，而那里的工程师或许早已读过第一份报告。战略问题也由此开始：如果我们能把一宗有记录的事故转化为可执行失效合约（Executable Failure Contract），明确触发故障的条件、不应出现的行为、发现它的实验，以及证明测试结果的证据，会怎样？

这样一来，出口商品便不只是监测故障的工具，也不是只写一次的咨询报告。它会成为一种测试：利雅得的工程师可以开发，新加坡的运营方可以运行，法兰克福的买方可以自行核验结果，不必只相信卖方的承诺。真正值得做科学与商业研究的，不是这个想法是否漂亮，而是故障逻辑能否在不同系统之间转移而不失真，以及外国客户是否愿意为这种转移再次付费。

如果我们认为软件业只出售“一切顺利时发生的事情”，这个想法确实显得古怪。成功的应用提供服务，芯片执行计算，网络传递消息。但这些产品周围还有一套沉默的经济：那些本不该发生的事情。企业可以按月为一项什么问题也没有发现的测试付费，前提是它有充分的工程理由相信，实验能够区分正常运行与可检测的故障。

这个市场并非想象。亚马逊云科技（Amazon Web Services; AWS）提供受控故障注入服务（AWS Fault Injection Service; FIS）。该服务自 2023 年起提供预设场景库，AWS 在 2024 年发布的指南中对此作了说明。这些实验可以模拟可用区（Availability Zone）故障或连接中断的影响，并能在越过特定边界时停止 S06S08。2025 年 5 月，AWS 又发布示例，展示如何借助 Amazon Bedrock 与大语言模型（Large Language Models; LLMs），从自然语言描述生成实验模板 S07。

因此，任何沙特项目都不能宣称自己发明了混沌工程（Chaos Engineering），也不能说第一次发现了把事故描述转成实验的可能。竞争者已经存在，其中一些还拥有客户正在测试的平台。拟议产品的窗口更窄，也更难：把失效的语义机制译成可跨环境迁移的测试，并附上对观测行为经过审查的证据，而不是把测试锁在单一云引擎中，或只会随机关停服务器。

这种差异未必能在市场上成立。云服务商可能把它作为订阅附加功能免费提供，买方也可能认为每个平台各自采用专门方案更有效。因此，工程上引人入胜的缺口不能直接等同于已经得到证明的投资机会。真正的项目始于找到愿意付钱弥合缺口的人，而不是先给缺口发明一个响亮的英文名称。

事故报告使用适合向人解释经过的语言：时间线、决策、假设、传播细节、根本原因（Root Cause）与补救建议。计算机却不能只凭一句“团队将改进错误处理”就安全开展实验。它需要明确的条件、初始状态、允许执行的动作、可观测结果，以及停止与回滚方式。

报告应被视为原料，而不是可直接运行的程序。它需要经历五次转换：

1. 区分观测与解释。 系统所有者公布了哪些事实？哪些内容仍是推论？哪些部分缺乏足以迁移的规范？
2. 提取因果模式。 例如，数据存储的读取权限变化生成重复行，使共享配置结构膨胀，读取器随后无法处理其大小。这是在描述一类行为，而不是复制某家公司的设计。
3. 编写功能不变量（Invariant）。 例如：“语义上重复的特征记录不得导致核心服务路径崩溃。”但不变量本身也需要限定：对目标产品而言，去重是否安全？记录顺序或重复次数可能本来就是语义的一部分。
4. 组装受控实验。 编译器（Compiler）在隔离环境中生成合成测试输入，要求特定结果，并设置停止条件（Stop Conditions）与回滚（Rollback）方法。
5. 输出证据记录。 使用了哪个软件版本？随机种子是什么（如有）？有哪些测试用例？通过分布式追踪（Distributed Traces）、日志和指标观测到了什么？

生成的单元可以表示为结构清晰的 IncidentSpec 文件，包含 evidence, preconditions, stimulus, oracle, stop, rollback, environment 与 limitations。这些字段是研究与开发建议，不是已获认可的标准，也不是现有沙特产品名称。oracle 指区分成功与失败的判定规则。智能测试最糟糕的地方，不是无法触发故障，而是触发故障后还庆祝实验成功，因为它根本不知道正确结果是什么。

常见的云端故障注入会切断网络、增加延迟（Latency）、停止容器或耗尽处理器。这些方法确实有用，却不足以对应前述两起事故中摧毁业务路径的事件。真正的触发因素是过大的文件，以及全球传播策略中的缺失字段。一个系统可以通过数千次服务器关停测试，却在数据库多导入一行时崩溃。

计算机科学区分资源故障（Resource Fault）与语义故障（Semantic Fault）。前者问：服务器消失会怎样？后者问：如果服务器运行得很快，却读到语法合法、但违反软件隐含假设的信息，会怎样？后一类测试可能处理数据损坏（Data Corruption）、模式漂移（Schema Drift）、版本偏差（Version Skew）、幂等性失效（Idempotency Failure），或重试风暴（Retry Storm）。

并非所有坏输入都应按同一方式处理。金融服务不能把所有权限错误改成“放行，以免服务停止”。面向公众的只读服务，则可能更适合在条件允许时保持开放（Fail Open），而不是阻断所有人。功能不变量来自服务的功能与边界，不能从新闻报道中直接复制。 产品最有价值的专业服务也在这里：把业务意义转化成可测条件，而不只是把文字翻译成配置文件。

软件测试还有其他工具。基于属性的测试（Property-Based Testing）生成多种输入，寻找不变量的反例；变形测试（Metamorphic Testing）在难以逐例确定正确答案时，比较修改输入前后的系统结果；差分测试（Differential Testing）比较两个声称遵守同一规则的实现。并发事务使问题更难：每个单独响应看起来都可能正确，整个事件历史却可能违反一致性保证（Consistency Guarantee）。多年来，Jepsen 项目一直把在故障下运行真实分布式系统并检查操作历史，做成公开、系统化的方法 S09。

因此，这不是一家创意机构替公司想象最坏的一天，再让语言模型画出场景。它需要程序语言语义（Programming Language Semantics）研究者、分布式协议（Distributed Protocols）研究者，以及明白“不要崩溃”远弱于“正确完成任务，既不重复也不丢失”的运维工程师。

文件翻倍、索引与分布式副本，听起来可能只是程序员边喝咖啡边读事故报告时的消遣。把目光转向 2024 年 2 月 22 日美国 AT&T Mobility 的事故，含义就不同了。美国联邦通信委员会（Federal Communications Commission; FCC）公共安全与国土安全局的报告称，一个网络组件配置错误后，全国范围的移动通信中断至少持续了 12 小时。根据监管机构从运营商处获得的数据，事故阻断了超过 9200 万通语音电话，以及超过 2.5 万次拨打 911 紧急呼叫中心的尝试 S03。

我们不会虚构某位无法呼叫救护车的患者，也不会推测每一通被阻断电话的后果。数字与服务类型已经足以说明其社会影响。一次技术组件变更，影响了数百万人的通信能力。可以迁移的教训不是把通话数字套到某一张沙特网络上，而是在发布变更前，测试单点变更如何传播，以及系统其余部分如何响应恢复。损害并未在发现错误时终止；大量设备同时尝试重新接入网络，可能在修复后继续加剧拥塞。

这三份事故档案各不相同：翻倍的特征文件、包含空字段的配额，以及配置错误的网络组件。它们却共同指向一个问题：一条局部控制信息，何时会迅速变成难以撤回的集体决定？ 把三个案例放在一起，不能证明一个平台能够发现全部故障。它们能构成一组比“我们用人工智能预测攻击和故障”更诚实的科学假设。

如果要做第一个沙特产品，我不会从庞大平台或挂着世界地图与警戒口号的仪表盘开始。我会从事故到测试编译器（Incident-to-Test Compiler）开始，让它处理公开事故档案，以及团队真正理解的三类软件。编译器不直接连接客户系统；它先要求客户提供服务接口的抽象模型、客户视为关键的属性，以及获准操作的环境边界。

人工智能（Artificial Intelligence; AI）阶段负责提取候选假设：“故障可能来自文件大小”“读取器可能无法处理空字段”“重试可能加重负载”。但每句话都必须附上报告中的证据，并标明状态：来源已证实、可能成立，或不可迁移。语言模型在这里是假设提取（Hypothesis Extraction）助手，不是签发运行许可的裁判。它可能弄错字段名，也可能编造因果关系，因此其输出不能直接变成影响真实服务的命令。

假设随后转为中间表示（Intermediate Representation; IR）。系统可以由此生成 Kubernetes 实验适配器（Adapter）、应用程序编程接口（Application Programming Interface; API）测试适配器，以及无需基础设施、只测试独立库的适配器。如果这些表示之间不能保持意义，商业订阅便没有价值：在第一个环境里停止一组容器，表面上可能与第二个环境中的故障相似，却缺少使原事故扩大化的共享状态。

结果来自服务指标、操作日志与跨接口执行追踪。OpenTelemetry 是可用的数据路径之一；云原生计算基金会（Cloud Native Computing Foundation; CNCF）介绍了其指标（Metrics）、日志（Logs）与追踪（Traces）的通用接口 S11。打造沙特产品无须再发明一套沙特监控协议。原创知识可能在于实验设计及其解释边界，证据传输则采用开放标准。

最后，拟议的“执行证据通行证”（Execution Evidence Passport）记录软件包版本、环境版本、注入的变更、测试判定器输出、停止原因与结论适用范围。它只是研究名称，不是独立认证印章。数字签名（Digital Signature）可以保护记录不被篡改；如果判定规则薄弱，签名并不能让结论变得真实。一项实验完全可能记录完备，却完整地回答了错误的问题。

图 2. 拟议产品架构，并非已经发布或部署的沙特系统。箭头表示需要人工审查的知识转换阶段，不能证明这些步骤在所有行业都能安全实现自动化 S06S07S09S11。

为了不让论点停留在会议节目单上，我们实施了一个边界明确的小型计算模型。我们为四类问题手工编写了 16 份合成测试合约：字段缺失的策略、因重复特征而超过容量限制的特征包、过期或未经认证的配置版本，以及永不停止的连接重试。随后在四个合成软件实现上运行这些合约：脆弱实现、只检查输入有效性的实现、只控制资源边界的实现，以及组合四类必要防护的实现。

程序实际执行了 64 个测试用例，并为每个用例输出日志、预期结果和观测结果。脆弱实现与 16 个用例中的 7 个一致；输入检查实现为 12 个；资源边界实现为 11 个；组合实现为 16 个 S13。这些数字都来自我们为展示示例而编写的代码，不是真实企业中的故障检出率。我们也没有用真正的人工智能从事故报告中提取用例；合约由人工设计，只为检验表示与执行思路。

图 1. 每个实现的输出与公开测试判定器一致的用例数；每类各四个用例。比例不代表商业故障检出能力，也不表示事故发生概率。代码、用例与结果文件见独立附件 S13。

实验最重要的结果，不是“防护越多，韧性必然越强”。那会构成循环论证，因为第四个实现本来就是为了通过我们编写的合约而设计。实验说明的是一件更克制、更有用的事：功能描述可以转化为输入、判定规则与可复现的结果记录，同时仍能清楚区分系统失效与测试未能理解系统。 从这套有限的练习走向生产数据库、支付平台或通信网络，还需要不同的实验、合约与成功定义。

外国客户不会向初创公司购买“互联网史”，因为它可以免费阅读；也不会购买对原作者已经写得更好的报告进行改写。只有当软件包替客户缩短了一项困难工作，客户才可能付费：把事故转化为可在其架构中安全表达的模式，并把执行结果连接到自身服务义务上。这项服务会产生集成成本（Integration Cost）；如果每位客户都需要两个月定制，成本足以吞掉许可费。

我设想三种不同的早期产品，销售时必须分开说明：

这些是拟议类别，并非已经创办的公司或售出的服务。业务可以先从第一类合约包开始；如果客户证明自己确实需要跨环境迁移，再发展第二类产品。若直接跳到一个“理解一切”的综合产品，更可能得到披着软件平台外衣、成本高昂的咨询业务。

2025 年 4 月，沙特出口发展局（Saudi Export Development Authority; Saudi Exports）参加摩洛哥马拉喀什（Marrakech）举行的 GITEX AFRICA 展会。“沙特制造”展区汇集了 28 家本国科技与通信企业，信息来自沙特通讯社（Saudi Press Agency; SPA）S04。2026 年 7 月，香港（Hong Kong）举办 LEAP East，沙特机构参与其中，多家科技公司建立联系；例如 Elm 宣布与 Huawei 签署人工智能与数字基础设施合作谅解备忘录 S05。

这些都是国际接触与推广渠道存在的具体信号，却不是沙特韧性产品的采购记录，也不能证明外国客户带来了持续收入。展会可以帮助企业见到买方；只有独立买方因为不愿失去第一个产品而签下第二份合同，出口产业才真正出现。

沙特无须先生产全球软件业的一切基础用品，才有资格专注这个缺口。它拥有规模可观的运营市场，计算、通信、服务、支付和物流领域也有潜在运营方，研究与工程能力还可以继续发展。但把这种环境称作“理想实验室”仍是需要检验的假设：本地客户可能善于组织大型项目，却暂时不愿让服务承受假设性测试；产品也可能困在难以复制的定制需求中。付费意愿、工程团队是否允许测试、事故数据的使用权，以及增加一个新客户的边际成本，都不能用笼统的国家优势代替回答。

海湾地区应对复合压力的经验，或许还能为数字供应链、网络时序、计算热负载与连接来源变化设计有用测试。这种把复杂现实转化为通用知识的工作是合理的，但模式必须来自公开数据或获准环境，不能来自敏感设施地图，也不能使用足以为攻击者提供目标清单的访问细节。

一家本地机构可以建出漂亮的平台，运行一百份合约，随后才发现售后维护成本高于许可收入。可出口软件需要清楚的单位经济效益（Unit Economics），不能把经常性收入与一次性开发项目混在一起。单项实验可能要求团队重新理解客户的事务、接口与安全规则，接受法律审查，使用客户的语言编写文档并提供运行支持；系统一升级，测试又要随之变化。

这里不假设市场规模，也不估计全球平均订阅价格。创始人应在真实试点客户中测量四个比例：每位客户所需的定制工时、无需专家介入即可运行的合约占比、每个新版本的维护成本，以及沙特境外的付费续约率。 “我们有一位国际客户”并不是充分标准。在国外执行的咨询项目属于专业服务出口，却未必是可以用可观经济倍数复制的深科技软件产品。

买方也可以为测试的预期年度价值设一个近似上限：把测试能够在影响用户前阻止的故障家族数，乘以真实发生概率与可避免损失，再减去实验成本、对开发造成的影响以及支付价格。但罕见故障的概率与反事实损失不容易知道。这个表达式适合帮助思考采购，不能用虚构数字填满，再宣布保证获得投资回报（Return on Investment; ROI）。

产品还有一处深层激励问题。如果公司出售“测试成功”，它就有动机编写容易通过的测试；如果出售“发现的故障数量”，它又有动机让用例越来越奇怪、越来越脱离现实。因此，产品需要更难操纵的指标：不在服务开发期间编写的盲测、不应被拒绝的反例、与现有工具的比较，以及完整运行成本。这些并非业务之外的治理要求，而是商品质量本身。

语言模型可以快速阅读数千份事故报告，生成初步假设家族。代码生成模型（Code Generation Models）可以编写适配器或用例生成器，再在封闭计算实验室中运行。但事故报告不是发生故障的系统的完整规范。报告可能省略内部接口，移除敏感数据，或使用无法确定事件顺序的概括性表述。文本中看似“原因”的内容，也可能只是时间上的巧合，或对最后一次处置决定的简写。

因此，编译器应在三个互相独立的层次上接受评估：从报告中检索证据的准确性（Evidence Grounding）、可执行形式的有效性（Executable Validity），以及在新环境中判断系统行为是否真实的跨系统迁移有效性（Cross-System Transfer Validity）。第一层不能证明第二层，代码正确也不能保证第三层。测试完全可以无错运行，却对正确行为作出错误判断。

这里显出人工智能的一处耐人寻味的矛盾：让机器提出“什么应该被破坏”相对容易；让它理解环境变化后什么必须继续保持正确，要难得多。这属于更深层的计算机科学，包括语义、一致性、时序逻辑（Temporal Logic）与状态建模（State Modeling）。代码越容易生成，人和机器共同提出可证伪问题的能力就越有价值。

对这个想法最有力的反对意见，不是说它毫无价值，而是说它可能只是现有工具中的一项功能，并不足以支撑一家独立公司。如果云服务能够在客户平台内部生成实验、执行实验并展示结果，客户为什么还要购买外部编译器？如果 Jepsen 这样的专业项目多年来一直为分布式系统提供独立一致性测试，新缺口究竟在哪里？如果事故记录缺少造成故障的私有规范，每位客户重新发现这些规范又要花多少钱？

答案不能靠宣称自己更强。我们需要商业实验来区分三种可能：带有限支持的专业软件包可以胜出；高质量服务可以成为高价值工程咨询，却无法像软件一样规模复制；二者都可能输给免费工具或大型平台的服务。第三种结果不是国家层面的失败，而是省下本可投向其他问题的资金与时间。

真正的市场进入测试可以这样设计：一个小型沙特团队，为公开事故家族制作两到三个软件包；两位本地客户同意进行安全实验；随后再找没有理由迁就这个国家或创始人的其他国家客户。对每位客户，都记录安装时间、修改了多少行代码、测试是否发现了现有测试集未发现的缺陷、两个版本后是否仍有用，以及客户是否再次付费。反例测试应当先行：一个客户或许已经能通过全部测试，根本不需要这项产品。

2026 至 2035 年间，这个想法可能出现三种有条件的结局。第一，它被云服务商的产品吸收；此时，与其竞争通用平台，不如向它们出售专业适配器或高级测试服务。第二，需要跨多个供应商取得独立证据的行业形成市场，能说明测试边界并完成迁移的独立产品由此成功。第三，业务一直是零散咨询：工程知识有用，却不足以形成拥有经常性软件收入的产业。

这些不是经过估计的概率。每个未来都有可观察信号：买方依赖内置工具、多供应商合约增长，或每个项目的定制工时居高不下。不能先写好结论，再从新闻中挑选让它看起来像命运的材料。

这里最重要的国家机会，比成立一家使用人工智能的公司更深。它在于形成一项可执行的知识资产：把世界已经遇到过的问题重新表达为可以迁移、运行与检查的测试，再从实验结果与现实结果之间的差异中学习。沙特团队会在文字难以替代证明的地方积累研究能力，客户也会得到一种无须相信卖方隐喻的商品。

传统工厂把原料投入生产线，产出可以称重的部件。拟议工厂可以投入事故报告，产出可被证伪的条件。如果这个条件能被反复卖给独立买方，它或许会成为新产业的种子。如果不能，我们至少会回答一个响亮名称无法解决的有用问题：失效经验中的哪一部分，能够在跨越国界时不丢失意义？

1. Cloudflare (Matthew Prince), Cloudflare outage on November 18, 2025, 18 November 2025. https://blog.cloudflare.com/18-november-2025-outage/
2. Google Cloud, Incident details: June 12, 2025 Google Cloud service outage, original post-incident timeline and root-cause updates, 2025. https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW
3. Federal Communications Commission, Public Safety and Homeland Security Bureau, February 22, 2024 AT&T Mobility Network Outage, July 22, 2024. https://docs.fcc.gov/public/attachments/DOC-404150A1.pdf
4. Saudi Press Agency, ‘Made in Saudi’ Pavilion at GITEX AFRICA Showcases 28 Leading Tech Companies, 14 April 2025. https://www.spa.gov.sa/en/N2297562
5. Saudi Press Agency, Elm Signs MoU with Huawei to Advance Cooperation in AI and Digital Infrastructure, 9 July 2026. https://www.spa.gov.sa/en/N2630981
6. AWS, Bootstrap your chaos engineering journey with AWS Fault Injection Service Scenarios Library, 1 October 2024. https://aws.amazon.com/blogs/mt/bootstrap-your-chaos-engineering-journey-with-aws-fault-injection-service-scenarios-library/
7. AWS, Chaos engineering made clear: Generate AWS FIS experiments using natural language through Amazon Bedrock, 13 May 2025. https://aws.amazon.com/blogs/publicsector/chaos-engineering-made-clear-generate-aws-fis-experiments-using-natural-language-through-amazon-bedrock/
8. AWS, Stop conditions for AWS FIS, official documentation. https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html
9. Jepsen, Analyses and Research Ethics, author-operated research and testing documentation. https://jepsen.io/analyses and https://jepsen.io/analyses/ethics
10. Principles of Chaos Engineering, Principles of Chaos Engineering. https://principlesofchaos.org/
11. Cloud Native Computing Foundation, OpenTelemetry has graduated… Now what?, 24 July 2026. https://www.cncf.io/blog/2026/07/24/opentelemetry-has-graduated-now-what/
12. AWS, REL12-BP04 Test resiliency using chaos engineering, AWS Well-Architected Reliability Pillar. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html
13. Author-supplied materials, Executable incident contract toy demonstration. See analysis/reproduce.py, data/contract_cases.json, data/contract_test_results.csv, data/contract_summary.csv, and data/execution_meta.json in the article package. These are explicitly artificial inputs and outputs, not observed Saudi or other operators' incidents.

可执行失效合约（Executable Failure Contract）；事故到测试编译器（Incident-to-Test Compiler）；功能不变量（Invariant）；测试判定器（Test Oracle）；基于属性的测试（Property-Based Testing）；差分测试（Differential Testing）；变形测试（Metamorphic Testing）；重试风暴（Retry Storm）；分布式追踪（Distributed Traces）；拟议执行证据通行证（Execution Evidence Passport）；单位经济效益（Unit Economics）；可迁移价值（Transferable Value）。

披露：本文在人工智能辅助下完成编辑与分析，并查阅了公开来源。没有进行访谈或生产系统实验，本文与随附研究论文也未经过独立同行评审。带有拟议名称的概念不是已发布产品或标准。编辑日期：2026 年 10 月 22 日。