企业出海多云架构治理与容量保障实战：ADR 决策记录 + 技术债务台账 + 全链路压测与容量规划（2026 最新版）

📅 2026-09-24 · ChengziCloud - 一站式云端服务

Meta Description: 出海企业多云架构治理完整指南：用 ADR 记录架构决策、用技术债务台账管理欠债、用容量规划与全链路压测保障大促，含三云原生工具对比、落地命令与 90 天路线，一篇讲透。

> 关键词： 架构治理、ADR 架构决策记录、技术债务、容量规划、全链路压测

先说结论：多云架构最大的风险不是"某一朵云挂了"，而是"没人说得清这套架构为什么长这样"。 大多数出海团队在半年内完成了别人两年的上云进度：阿里云扛国内流量、AWS 接欧美业务、腾讯云放东南亚，跨云专线拉了三根，IaC 代码进了 Git。系统是跑起来了，但随之而来的是四个没人回答的问题——这套双活为什么是主备而不是双主？那个"临时"的 NAT 网关为什么挂了两年还没撤？下个月大促要买多少台机器？压测能压到多少 QPS？这四个问题的共同名字，叫架构治理。

本文只讲架构治理这条链路本身：决策怎么留痕、欠债怎么记账、容量怎么算、压测怎么打。它不重复网络怎么互通、成本怎么省、监控怎么接——那些属于相邻篇章，边界见第一节。

一、先划界：本文与相邻篇章的边界

site7 的多云系列已经比较密集，写"架构治理"最容易被误读成"又一个 CMP 篇"或"又一个 FinOps 篇"。所以先把边界钉死：本文处理的是架构的"元问题"——设计决策、欠债、容量与承载能力，不处理资源怎么纳管、钱怎么省、指标怎么看。

| 主题 | 本文是否覆盖 | 相邻篇章与边界 | |---|---|---| | ADR 架构决策记录 / 技术债务台账 / 容量规划 / 全链路压测 | 是，本文主体 | — | | 多云管理平台、资源纳管、自助服务目录 | 不覆盖 | 《多云管理平台（CMP）建设实战》管的是"资源怎么被申请和交付"；本文管"这笔资源当初为什么这么设计、还欠多少债、能扛多少量" | | FinOps 预算、分账、单位成本 | 不覆盖 | 《企业 FinOps 成本管理体系建设》讲"钱花得对不对"；本文讲"容量买得够不够、压测能不能撑住"，是成本的前置输入 | | 可观测性、告警治理 | 仅做衔接 | 《多云可观测性架构实战》管"线上出了事怎么看"；本文管"上线前怎么证明它撑得住"，压测数据是观测看板的重要输入 | | 混沌工程与韧性测试 | 仅做衔接 | 《多云混沌工程与韧性测试》管"故障注入下系统怎么表现"；本文管"正常负载下系统能扛到多少"，两者一正一逆 | | 灾备编排、RTO/RPO | 不覆盖 | 《多云灾备编排与自动化切换》管"挂了怎么恢复"；本文管"没挂之前买多少才不浪费" |

一句话：CMP 解决"有资源可用"，FinOps 解决"资源花得值"，可观测解决"出问题看得见"，而本文解决"架构可控"——决策有痕迹、欠债有台账、容量有依据、压测有数据。

二、为什么"能跑"不等于"可控"：多云架构的四个失控信号

出海多云环境有一个反直觉特性：它退化得非常慢，慢到你发现时已经积重难返。 单云团队架构腐化的第一个受害者是性能，你能立刻感知；多云团队的架构腐化第一个受害者是"共识"，而共识崩掉时通常没有任何指标报警。

四个典型的失控信号：

1. 决策失忆——问"为什么跨云用 VPN 而不是专线"，答案是"当时那位同事定的，人已经走了"。于是没人敢动，也没人敢改。 2. 隐性欠债——三个"临时方案"（临时 NAT、临时脚本、临时白名单）挂了两年，成了事实上不可动摇的生产依赖，谁碰谁背锅。 3. 容量玄学——大促前靠"上次买了多少、这次多加 30%"拍脑袋，买少了被打爆，买多了白烧钱，两个方向都无法归因。 4. 压测缺位——"我们做过压测"指的是某位同学用 ab 在测试环境压了 200 并发。生产跨云链路的真实瓶颈（专线带宽、跨云延迟、下游限流）从来没被验证过。

这四个信号共享一条治理主线，也就是本文的四层模型：

`mermaid graph TD A[业务与合规目标] --> B[L1 决策层 ADR: 为什么这么设计] B --> C[L2 债务层: 还欠多少债、何时还] C --> D[L3 容量层: 需要多少资源、怎么算] D --> E[L4 验证层: 全链路压测证明能扛住] E --> F[反馈: 压测暴露的瓶颈回到 L2 记债、回到 L1 改决策] F --> B `

对应的物理全景图如下，核心是一条"治理闭环"：决策留痕 → 欠债记账 → 容量有据 → 压测验证 → 结果回流。缺任何一环，治理都会退化成"写文档"。

`text ┌──────────────────────────────────────────────┐ │ 企业出海多云架构治理闭环 │ └──────────────────────────────────────────────┘ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ L1 决策层 │────▶│ L2 债务层 │────▶│ L3 容量层 │ │ ADR 记录 │ │ 台账+偿债 │ │ 模型+换算 │ │ /docs/adr │ │ /debt.yaml │ │ capacity.yml│ └──────────────┘ └──────────────┘ └──────────────┘ ▲ ▲ │ │ │ ▼ │ ┌──────────────┐ ┌──────────────┐ └────────────│ L4 验证层 │◀────│ 压测平台 │ │ 全链路压测 │ │ PTS/k6/LT │ └──────────────┘ └──────────────┘ │ 压测瓶颈 → 记一条技术债 → 需要时改一条 ADR（回流） `

四条纪律先立住：① 任何影响面超过一个团队、或不可逆的架构决策，必须有一条 ADR；② 任何"临时"方案必须进债务台账并带到期日；③ 任何容量决策必须能追溯到一条换算公式；④ 任何大促前必须有全链路压测报告，而不是"感觉没问题"。

三、L1 决策层：用 ADR 把"为什么这么设计"钉在 Git 里

ADR（Architecture Decision Record，架构决策记录）解决的是架构治理里最贵的一种成本：决策失忆。它不是设计文档——设计文档描述"系统长什么样"，而 ADR 只记录一件事：在某个时间点，面对某组约束，我们为什么选 A 而不是 B，以及这个选择带来了什么后果。

三者最容易混淆，先做个对比：

| 维度 | ADR（架构决策记录） | 设计文档（Design Doc） | 群聊 / 邮件结论 | |---|---|---|---| | 回答的问题 | 为什么这么选 | 系统怎么建 | 当时谁说了什么 | | 生命周期 | 永久，只追加不改写 | 随系统演进反复更新 | 三天后没人找得到 | | 粒度 | 一条决策一个文件 | 一个系统一个文档 | 一段对话 | | 是否进 Git | 必须 | 建议 | 从不 | | 关键价值 | 可追溯、可复盘、可推翻 | 指导实现 | 无 |

结论：设计文档回答"是什么"，ADR 回答"为什么"；只写设计文档的团队，半年后就只剩"是什么"，再也解释不了"为什么"。

3.1 ADR 的组织与命名

按 site7 的工程习惯，ADR 目录放在基础设施代码仓库根部，与 IaC 同仓（决策与实现同仓，评审时才看得见）：

`text infra/ ├── docs/adr/ │ ├── README.md // 索引（自动生成） │ ├── 0001-多云主备而非双主.md │ ├── 0007-跨云互联选型-ipsec-vpn.md │ └── 0012-新加坡区数据库选型.md ├── modules/ └── live/ `

一条 ADR 的内部结构（刻意只用纯文本，不写 Markdown 标题符号，避免模板本身污染渲染）：

`text ADR-0007 跨云互联选型：IPsec VPN 还是云专线日期 2026-08-12 | 状态已接受 | 责任人架构组 ──────────────────────────────────────────── 背景 Context 新加坡(阿里云)与法兰克福(AWS)双区需低延迟互联，当前日均跨境流量 180GB，峰值带宽需求 200Mbps，预算上限见 FinOps 季度表。决策 Decision 一期采用 IPsec VPN over 公网互联，专线作为二期备选；路由收敛时间要求 < 30s，MTU 统一降到 1380。后果 Consequences 正面：上线周期 3 天，月成本约为专线的 1/6。负面：公网抖动影响一致性，双向同步需重试补偿。风险：跨境流量增长至 1TB/日后，VPN 带宽成为瓶颈，需触发二期评审。替代方案 Alternatives A. 云专线直连：成本高但稳定，周期 4~6 周； B. 第三方 SD-WAN：托管省心，绑定供应商。 `

关键在"后果"与"替代方案"两段：绝大多数团队只写"决策"，不写"后果"，于是半年后没人知道这个选择埋了什么坑。一条不写后果的 ADR，等于没写。

3.2 实操：用 adr-tools / Log4brains 管理 ADR

手写 ADR 也能跑，但有工具后维护成本会低一个量级。两条主流路线（版本号一律以官方发布为准，不要照抄）：

`bash // 路线 A：adr-tools（轻量，纯 shell） adr init docs/adr adr new 跨云互联选型-ipsec-vpn // 生成 docs/adr/0007-跨云互联选型-ipsec-vpn.md adr new -s 0007 二期切换到云专线 // supersede：新决策推翻旧决策，保留链路 adr list // 打印全部决策索引 adr generate toc > docs/adr/README.md // 生成索引表

// 路线 B：Log4brains（带站点，可视化+时间轴） log4brains adr new log4brains preview log4brains build `

adr new -s（supersede）是这个机制最值钱的地方：架构不是不改，而是每次改都留一条链。 打开索引就能看到 0007 被 0031 取代了，而不是"文档里说的和现状对不上"。

3.3 一份可执行的 ADR 触发清单

不是所有决策都值得写 ADR，写了会淹没重点。建议只在命中以下任一条时写：

1. 跨团队影响 —— 决策影响超过一个团队的接口或节奏； 2. 不可逆或回滚昂贵 —— 例如上专线、定分片键、选中间件； 3. 跨云 / 跨地域 —— 涉及数据出境、延迟、专线带宽； 4. 被否决的方案值得记住 —— 为了避免下一个人把同样的坑再踩一遍； 5. 合规相关 —— 涉及 GDPR / 等保 / SOC2 的架构选择。

四、L2 债务层：技术债务要"记账"，不能靠"感觉"

技术债务这个比喻用滥了，但它真正有用的一点是：债务和金融债一样，关键在利息和到期日，而不是本金。 多云环境里的债务利息格外高，因为它跨了组织和云的边界——一个单云里"下个迭代就还"的临时脚本，在多云里可能变成三个团队都在依赖的隐形接口。

先给技术债务分类，不同类别的度量与偿债手段完全不同：

| 债务类别 | 典型表现 | 利息（不还的代价） | 度量口径 | 偿债手段 | |---|---|---|---|---| | 架构债 | 临时 VPN 替代专线、单点 NAT、硬编码 IP | 抖动放大、无法水平扩展 | 单点数 / 硬编码引用数 | 排期重构 + ADR supersede | | 配置债 | 手改控制台未回写 IaC、白名单长期放行 0.0.0.0/0 | 漂移难复现、安全面扩大 | IaC 漂移检查告警数 | 漂移自动收敛 + CSPM 门禁 | | 代码债 | 重复的连接池、绕过网关的直连、缺幂等 | 故障率上升、排障变慢 | 重复代码率 / 覆盖缺口 | 抽取公共模块 + 单测补齐 | | 文档债 | ADR 缺失、Runbook 过期、架构图与现状不符 | 新人上手慢、事故时无人敢动 | 关键系统 ADR 覆盖率 | 随变更强制更新 |

4.1 债务台账：一份 YAML 就是全部

不要用 Jira 的十级标签管债，用一份版本化的台账，让债务和代码一起评审：

`yaml debt: - id: DEBT-0031 title: 新加坡区出口仍使用临时单 AZ NAT 网关 category: 架构债 origin_adr: ADR-0007 detected: 2026-08-20 interest: 高 # 高/中/低 —— 利息决定优先级，不是本金 due: 2026-11-30 # 到期日：逾期即升级为季度 OKR 阻塞项 owner: 网络组 paydown: 改为双 AZ NAT + 关闭临时网关 - id: DEBT-0032 title: 法兰克福 3 台 ECS 手工扩容未回写 IaC category: 配置债 origin_adr: null detected: 2026-09-05 interest: 中 due: 2026-10-15 owner: 平台组 paydown: terraform import 回写 + 打标签 `

两条硬规则：① 用"利息"排序，不是用"本金"——一个改动量小但每季度都引发事故的债务，优先级高于一个改动量大但只影响内部工具的债务；② 每笔债必须有 due，没有到期日的债务台账三个月后就会腐烂成一堆僵尸条目。

4.2 技术债务的度量与可视化

债务管理最怕"看不见"。三个可直接落地的量化指标：

- ADR 覆盖率 = 关键系统中有 ADR 的比例（目标：核心系统 100%）； - IaC 漂移率 = 漂移检查告警数 / 受管资源数（目标：持续下降，新增即归零）； - 偿债吞吐 = 每迭代关闭的债务条目数（目标：≥ 新增条目数，即债务不涨）。

验证闭环：每季度做一次债务盘点，把台账里 interest: 高 的条目拿出来重新评估——要么排期还掉，要么用一条新 ADR 明确"我们决定永久接受这笔债"。"明确接受"也是一种治理，比装作看不见安全得多。

五、L3 容量层：从业务指标到资源规格的可追溯换算

容量规划的本质不是"猜需要多少机器"，而是把业务指标（DAU、订单数、峰值倍数）一步步换算成资源规格，并且每一步都能被复核。拍脑袋的问题不在于猜错，而在于错了以后无法定位是哪一步算错了。

5.1 四步换算链

一条通用换算链（所有系数都写进 capacity.yml，不要留在某个人的脑子里）：

1. 业务指标 → 峰值 QPS：峰值 QPS = 日均请求数 / 有效窗口秒数 × 峰值倍数。例如日均 2000 万请求集中在 8 小时，峰值倍数取 3，则 峰值 QPS ≈ 2000万 / 28800 × 3 ≈ 2083 QPS。 2. 峰值 QPS → 并发数（Little's Law）：并发数 = 峰值 QPS × 平均响应时间(秒)。响应时间 120ms，则当 QPS 2083 时并发 ≈ 2083 × 0.12 ≈ 250。这条公式是容量规划里最容易算错的一步——很多人直接拿 QPS 当并发数，结果要么过度采购，要么被打爆。 3. 并发数 → 实例数：实例数 = 并发数 / 单实例承载并发 × 冗余系数。单实例承载 40 并发、冗余系数 1.5，则 实例数 ≈ 250 / 40 × 1.5 ≈ 10 台。冗余系数不是懒惰，是给跨云抖动、可用区失效留的余量。 4. 实例数 → 配套资源：带宽 = 峰值 QPS × 平均响应体 × 8；数据库连接数校验 实例数 × 连接池大小 ≤ 数据库 max_connections × 0.8。

第 4 步是最容易漏的：应用层扩容了 3 倍，数据库连接池却顶住了上限，于是大促当天瓶颈不在应用而在数据库——这类问题只能靠全链路压测提前发现，所以 L3 与 L4 必须成对出现。

5.2 三云容量与压测原生工具对比

| 能力 | 阿里云 | AWS | 腾讯云 | |---|---|---|---| | 弹性伸缩 | 弹性伸缩 ESS（多伸缩配置支持 Spot 优先） | EC2 Auto Scaling + EC2 Fleet / ASG 混合实例策略 | 弹性伸缩 AS | | 规格/容量建议 | ECS 资源管家、成本管家 | Compute Optimizer（基于历史利用率的规格推荐）+ Trusted Advisor | 云顾问 Cloud Advisor | | 压测服务 | PTS 性能测试（支持 JMeter 脚本、全球发起） | 官方提供 Distributed Load Testing 解决方案（自建 k6/Locust） | PTS 性能测试 | | 监控与指标 | 云监控 CloudMonitor | CloudWatch（+ 详细监控 1 分钟粒度） | 云监控 | | 弹性触发指标 | 云监控报警 + 定时/动态规则 | CloudWatch 告警 + 目标跟踪策略（Target Tracking） | 云监控 + AS 策略 |

选型结论：容量建议优先用云原生工具（AWS Compute Optimizer / 阿里云成本管家 / 腾讯云云顾问）打底，它们免费且直接基于真实利用率；压测则统一用一套跨云可复用的开源方案（k6 优先），避免被单一云的压测产品绑定——压测脚本要能指向任何一朵云，否则双活架构的压测就是残缺的。

5.3 实操：容量建议与伸缩配置

先用云原生工具拿到"现状建议"（命令与参数以各云官方文档为准）：

`bash // AWS：看规格优化建议（哪些实例买大了/买小了） aws compute-optimizer get-ec2-instance-recommendations \ --region ap-southeast-1

// AWS：看闲置资源建议（哪些能降配或关掉） aws compute-optimizer get-idle-recommendations --resource-type Ec2Instance

// 阿里云：查看弹性伸缩组当前的伸缩配置与实例数 aliyun ess DescribeScalingGroups --RegionId ap-southeast-1 aliyun ess DescribeScalingConfigurations --ScalingGroupId asg-xxxx

// 腾讯云：查看伸缩组 tccli as DescribeAutoScalingGroups --region ap-southeast-1 `

再把换算结果落成"容量即代码"，随 IaC 一起评审：

`yaml capacity: service: order-api region: ap-southeast-1 business: daily_requests: 20000000 active_hours: 8 peak_multiplier: 3 derived: peak_qps: 2083 avg_rt_ms: 120 concurrency: 250 per_instance_concurrency: 40 redundancy_factor: 1.5 instances: 10 # ceil(250/40*1.5) bandwidth_mbps: 170 # 2083 10KB 8 / 1000 review: owner: 平台组 next_review: 2026-12-01 `

六、L4 验证层：全链路压测怎么打才算数

"做过压测"和"压测有效"是两件事。有效的全链路压测必须满足三个条件：链路完整（跨云全走一遍）、数据隔离（不能污染生产）、结论可落地（找到具体瓶颈并归因到人）。

6.1 压测方案设计：阶梯 + 稳态 + 尖峰

| 阶段 | 目的 | 加压方式 | 关键观测 | |---|---|---|---| | 基线 | 建立性能基线 | 单实例固定并发 | 单实例 TPS / P99 / 资源水位 | | 阶梯加压 | 找拐点 | 每 2 分钟 +20% 并发 | TPS 是否线性、P99 是否陡升 | | 稳态 | 验证持续承载 | 峰值的 80% 持续 30 分钟 | 长尾错误率、内存是否泄漏 | | 尖峰 | 验证弹性 | 3 秒内冲峰值 ×1.5 | 扩容是否跟上、是否触发限流 | | 破坏 | 找极限 | 压到错误率 > 5% | 第一个崩的组件是谁 |

最有价值的是"破坏"阶段：它不是看系统能扛多少，而是看系统先从哪里崩。第一个崩的组件，就是你要写进债务台账、也是下次大促前必须加固的地方。

6.2 跨云压测的三个硬约束

1. 流量来源要真实：压测机不能全部部署在同区，否则测不出跨云延迟。建议在新加坡、法兰克福两地各放一组压测节点，按真实流量比例发压。 2. 数据必须隔离：影子库 + 染色标记，压测写操作落到影子表或带 stress_ 前缀的记录，绝不污染生产数据。跨境场景下，这同时是合规要求（压测数据出境同样受 GDPR 约束）。 3. 下游要能被绕过或配合：真实压测里最容易被压垮的往往不是被测服务，而是它调用的第三方接口。对第三方要打桩或单独告知，否则你不是在测自己，是在攻击别人。

6.3 实操：k6 跨云压测脚本

k6 的优势是脚本即代码、可进 Git、可同时指向任意一朵云（JS 注释用 //，不要用 #）：

`javascript // stress-order-api.js —— 阶梯加压 + 阈值断言 import http from 'k6/http'; import { check, sleep } from 'k6';

export const options = { stages: [ { duration: '2m', target: 50 }, // 热身 { duration: '5m', target: 500 }, // 阶梯加压 { duration: '30m', target: 500 }, // 稳态 { duration: '1m', target: 0 }, // 收尾 ], thresholds: { http_req_duration: ['p(99)<500'], // P99 < 500ms http_req_failed: ['rate<0.01'], // 错误率 < 1% }, };

const BASE = __ENV.BASE_URL; // 传入目标云地址，跨云复用同一脚本

export default function () { const res = http.get(${BASE}/api/v1/orders?page=1); check(res, { 'status is 200': (r) => r.status === 200 }); sleep(1); } `

执行时切换 BASE_URL 即可指向不同云（同一份脚本，三朵云各压一遍）：

`bash // 压阿里云新加坡 k6 run -e BASE_URL=https://api-sg.example.com stress-order-api.js

// 压 AWS 法兰克福 k6 run -e BASE_URL=https://api-fra.example.com stress-order-api.js

// 输出到 Prometheus 远程写，和可观测看板打通 k6 run --out experimental-prometheus-rw \ -e BASE_URL=https://api-sg.example.com stress-order-api.js `

压测报告必含四张图：TPS—并发曲线、P99 延迟曲线、错误率曲线、资源饱和度曲线。四张图叠在一起，拐点在哪里、谁先崩，一目了然。一份没有拐点分析的压测报告，等于没报告。

七、把四层串起来：一次大促前的完整治理动作

治理不是四份文档，而是一条按时间推进的动作链。以一次大促为例：

`text T-45 天 L1 评审并更新所有涉及大促链路的 ADR（扩容决策、限流决策、降级决策） T-30 天 L2 债务盘点，把"高利息 + 到期日临近"的债务排进大促前迭代 T-21 天 L3 按四步换算链算出容量，用云原生工具交叉验证，形成采购/伸缩配置 T-14 天 L4 全链路压测第一轮，定位瓶颈 → 瓶颈回写债务台账 T-7 天 L4 修复后第二轮压测，确认拐点上移、无新增瓶颈 T-1 天 L1 冻结变更，确认 ADR 中的降级/限流预案可一键触发 T+1 天 L2 复盘，把本次暴露的新债务全部记入台账 `

这条链的价值在于：每个动作都产出可复核的证据——ADR 是决策证据，台账是欠债证据，容量表是采购依据，压测报告是承载能力证据。大促出问题时，你能精准回答"是算错了、没还债、还是超出已验证能力"，而不是"大家都以为没问题"。

八、参考价格表（新加坡，2026 年参考）

治理与容量工具本身大多免费或按量计费，真正花钱的是容量本身。下表为常见规格参考价，实际以各云官网实时报价为准：

| 配置项 | 阿里云国际版（新加坡） | AWS（新加坡） | 腾讯云国际版（新加坡） | |---|---|---|---| | 计算 2 核 4G 按量 | 约 $0.05~0.07/小时 | 约 $0.06~0.09/小时（视实例族） | 约 $0.05~0.07/小时 | | 计算 4 核 8G 按量 | 约 $0.10~0.14/小时 | 约 $0.12~0.18/小时 | 约 $0.10~0.14/小时 | | 1 年包年折扣 | 约按量 4.5~5.5 折 | Savings Plans 约 5~6 折 | 约按量 4.5~5.5 折 | | Spot / 抢占式折扣 | 约按量 2~3 折（回收率视规格） | Spot 约 2~4 折 | 约按量 2~3 折 | | 容量建议工具 | ECS 资源管家 / 成本管家（免费） | Compute Optimizer（免费） | 云顾问 Cloud Advisor（基础免费） | | 压测服务 | PTS 按压测资源用量计费 | 官方方案为自建，成本 = 压测机 EC2 + 流量 | PTS 按量计费 | | 跨云专线 / VPN | VPN 网关按实例 + 流量 | VPN / Direct Connect 按端口 + 流量 | VPN 网关按实例 + 流量 |

成本提醒：压测本身会产生带宽与流量费用，跨境压测的出网流量费往往比压测机本身更贵——做压测预算时把跨云流量单独列一行，别被压测机的小账单骗了。

九、90 天落地路线

| 阶段 | 时间 | 交付物 | 验收口径 | |---|---|---|---| | 一、立规 | 第 1~2 周 | ADR 目录 + 模板 + 触发清单；债务台账字段定义 | 任取一个核心系统，能说出 3 条关键决策及其后果 | | 二、铺底 | 第 3~6 周 | 核心系统 ADR 补齐；IaC 漂移检查上线；债务台账首次盘点 | ADR 覆盖率 ≥ 80%，台账条目全部有 owner 与 due | | 三、建模 | 第 7~10 周 | capacity.yml 换算链落地；接入云原生容量建议工具 | 任一服务可展示"业务指标 → 实例数"的完整换算 | | 四、验证 | 第 11~13 周 | 首轮全链路压测报告；瓶颈回写台账 | 报告含四张图与拐点归因；高压瓶颈全部有债务条目 |

验收用一句话概括：随便挑一个服务，你能在 15 分钟内回答它"为什么这么设计、还欠多少债、能扛多少量、上次压测的拐点在哪"——四问全答得上，治理就成立了。

十、常见问题 FAQ

Q1: 小团队（10 人以内）也要做架构治理吗？会不会太重？ 要，但要做减法。小团队只做两件事：ADR 只记"不可逆决策"（选型、分片键、数据出境方案），债务台账只记"高利息债务"。容量与压测可以先用云原生工具替代自建，等业务起来再补。治理的成本随团队规模增长，但收益是节省了无数次会议上的"这个当初为什么这么定"。

Q2: ADR 会不会又变成一种形式主义文档？ 会，如果只写"决策"不写"后果"和"替代方案"。防止形式主义的关键是ADR 进代码评审流程：新架构 PR 必须附带或引用一条 ADR，评审时第一句问"替代方案是什么"。没有替代方案的 ADR 一律打回——能写出替代方案，才证明你真的权衡过。

Q3: 技术债务台账和 Jira 里的任务重复吗？ 不重复，是不同层次。Jira 管"要做的事"，台账管"欠下的债"。一笔债可能对应多个 Jira 任务，也可能暂时不排期（明确接受）。台账的价值是全局视角与利息排序——Jira 里你看到的是任务列表，台账里你看到的是"哪些债在持续伤害我们"。两者可以有映射字段，但不要合并。

Q4: 容量规划算出来的数准吗？拍脑袋和经验判断真的不行吗？ 公式算出来的数也不需要"准"，它需要的是可追溯、可迭代。第一版大概率偏，但一旦有了压测数据，你就能反过来校准每一个系数（并发换算、冗余系数、单实例承载）。拍脑袋的问题从来不是错，而是错了以后无法定位是哪一步错了，于是下次还错。

Q5: 全链路压测会不会影响生产？ 只要满足三个隔离就不影响：流量隔离（压测流量带染色标记，网关按标记路由到影子链路）、数据隔离（影子库 / stress_ 前缀记录，写操作不落生产表）、依赖隔离（第三方接口打桩或提前沟通）。三项缺一不可，尤其是数据隔离——跨云压测写进生产库，是既违规又危险的组合。

Q6: 跨境压测的数据出境怎么合规？ 压测数据同样受 GDPR / 数据出境规则约束。三条做法：① 压测数据用合成数据，不搬真实用户数据出境；② 必须用真实数据时做脱敏 / 假名化，且记录跨境传输台账；③ 压测写操作落影子库并设定 TTL，定期清理。合规细节见《GDPR 数据跨境传输技术落地指南》，本文不重复。

Q7: 架构治理和混沌工程、可观测、FinOps 是什么关系？ 四条不同的链路，合起来才完整：可观测回答"现在发生了什么"，混沌工程回答"故障时会发生什么"，架构治理（本文）回答"这套架构为什么长这样、能扛多少、欠多少债"，FinOps回答"花的钱值不值"。治理产出的容量模型，是 FinOps 预算的输入；治理产出的债务台账，是混沌工程演练的靶子；压测数据，是观测看板里性能指标的基线。

Q8: 做架构治理最难的卡点是什么？ 不是工具，是"留痕"的习惯。工具（adr-tools、k6、Compute Optimizer）半小时就能装好，难的是团队愿意在赶进度时仍为一条决策写 10 行 ADR、在发现临时方案时仍花 1 分钟记一笔债。能扛过这个习惯养成期的团队，半年后架构的可维护性会甩开同规模团队一个身位——因为他们的架构有记忆，而别人的只有现状。

十一、总结

架构治理的本质，是把"架构"从一堆资源，变成一套有记忆、有台账、有依据、有证明的系统：

1. 决策有痕迹——ADR 与代码同仓，只追加不改写，用 supersede 记录演进，每条必写后果与替代方案。 2. 欠债有台账——用利息而非本金排序，每笔债带到期日，定期盘点，允许"明确接受"。 3. 容量有依据——四步换算链从业务指标推到资源规格，每一步系数可复核、可校准。 4. 压测有证明——阶梯 + 稳态 + 尖峰 + 破坏四阶段，四张图 + 拐点归因，瓶颈回写台账闭环。

做到这四点，出海多云架构最贵的成本——"没人说得清为什么"——就被消掉了。那时候，大促不再是赌博，架构演进不再是冒险，而是在一套自己看得懂、接得住的规则里稳定向前。

> 🚀 企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。我们提供多云架构治理体系设计、ADR 与债务台账落地、容量模型评审与全链路压测方案，帮助出海团队把架构从"能跑"做到"可控"。