vault-para/200-area/Personal Development/System Architec/决策方法.md at main

Files

T

2025-12-29 13:38:39 +08:00

12 KiB

Raw Permalink Blame History

tags: [architecture, decision, ATAM, ADR, tradeoff, risk, wsjf]
created: "<% tp.file.creation_date('YYYY-MM-DD') %>"
updated: "<% tp.file.last_modified_date('YYYY-MM-DD HH:mm') %>"

目标：让架构决策 可解释 / 可量化 / 可追溯 / 可回滚。

1) 方法家族（知道用什么）

ATAM：以“质量属性场景”驱动的架构权衡；产出风险/敏感点/权衡点、Utility Tree。
ADR：单条架构决策记录；背景→选项→量化权衡→决策→回滚→验证。
Trade-off Matrix：把可用性/成本/复杂度/交付周期等维度量化对比。
Utility Tree：质量属性（可用/性能/安全…）→ 场景化 → 重要度×难度评分。
WSJF / CoD：对一篮子能力排序（价值/时效/风险降低 ÷ 规模）。
风险分析：风险登记（概率×影响）、敏感性（Tornado）、决策树（期望值）。
实验驱动：金丝雀/灰度/A-B；以 SLO & Error Budget 作为放量门禁。

2) 统一流程（Playbook）

对齐业务目标与 NFR/SLO
列出 ≥ 2 个候选（含“不做/延后”）
Utility Tree 场景化：重要度 (BI) × 难度 (TR)
Trade-off 量化：可用/性能/成本 (TCO)/复杂度/交付
风险登记：概率×影响 + 缓解/触发器/应对
做出决策并写 ADR（含回滚条件与验证指标）
金丝雀验证 → 复盘（按月/季度迭代）

3) 最小公式（随手可用）

Error Budget（同窗） = 1 - SLO；例：99.95%/月 ≈ 22 分钟
Burn Rate = 实际消耗 / 线性应消耗（> 1 表示过快）
串行可用性近似：A_total ≈ ∏ A_i；并联冗余：A = 1 - ∏(1 - A_i)
WSJF = (业务价值 + 时效性 + 风险降低) / 规模
风险评分 = 概率(1–5) × 影响(1–5)（> 12 需强缓解）
停机成本 ≈ 分钟 × 单位损失 × 影响用户占比
年度 TCO ≈ 计算+存储+网络+日志+监控 + 人力×系数 + 预留 10%

4) 权衡维度（打分建议）

可用性（预期 SLO / RTO / RPO）
性能（P95 / P99 目标可达性）
成本（一次性 vs 年度 TCO）
复杂度（开发/运维/组织）
交付周期（从 PoC 到可用上线）
风险（技术/合规/运营）

建议：评分用 1（优）~ 5（差）；或直接用定量值（SLO%、$TCO、周数）对比。

5) 模板速用

5.1 Trade-off Matrix（权衡矩阵）

方案	SLO/可用性	年 TCO	复杂度	交付周期	关键风险	结论
A	99.9%	$X	3	1	区域单点	过渡
B	99.95%	$X+30%	4	2	跨区复制/切换	✅
C	99.99%	$X+80%	5	4	一致性冲突	暂缓

5.2 Utility Tree（简版）

availability:
  - scenario: "Region 故障 30m 内恢复"
    BI: 5   # Business Importance
    TR: 4   # Technical Risk
performance:
  - scenario: "峰值 5k QPS P95≤250ms"
    BI: 5
    TR: 3
security:
  - scenario: "密钥自动轮换/静态加密"
    BI: 4
    TR: 2

5.3 ADR（Architecture Decision Record）

# ADR-XXXX: <标题>
## 背景
目标 / SLO / 约束（预算/期限/团队）
## 选项
A / B / C（含“不做”）
## 量化权衡
权衡矩阵 + TCO + 停机成本 + 风险表
## 决策
选择 X（理由与 SLO/成本对齐）
## 回滚计划
触发条件（p95>阈、burn_rate>2x…）与一键脚本
## 验证
金丝雀步骤、成功判据、观测指标（RED/USE）
## 后续
里程碑、技术债、风险缓解任务

5.4 风险登记（Risk Register）

ID	风险	概率	影响	分数	缓解	触发器	应对
R1	复制延迟超阈	3	4	12	增带宽/压测	lag>15s	降级读主库
R2	切流脚本失败	2	5	10	预演	回滚>5m	手动 Runbook

5.5 WSJF / CoD（优先级）

能力/改造	价值	时效	风险降	规模	WSJF
自动回滚	7	9	8	4	6.0
观测统一	6	8	7	5	4.2
跨区主备	8	7	6	8	2.6

6) 验证要点（决策“落地就绪”）

有 回滚条件与脚本（已演练）
金丝雀/灰度 与 SLO/预算 绑定（stop_if 明确）
成本/停机损失 有计算来源（表/链接可追溯）
风险登记 有触发器与应对动作
ADR 已归档，并在 PR / 变更单中引用

7) 常见反模式（避免）

只有口头结论、无 ADR / 无量化
只看一次性成本，不看年度 TCO 与 停机成本
无回滚/未演练；金丝雀只是“形式”
风险登记没有触发器，告警不连 Runbook
用平均延迟代替 P95/P99，掩盖体验尾部

8) 记忆卡（60 秒回顾）

工具箱：ATAM / ADR / Trade-off / Utility Tree / WSJF / 风险登记
关键四问：值不值？做得成？能按时？出事能回？
落地三件套：SLO & 预算门禁、回滚脚本、ADR 可追溯

下面给你一份“按实际操作最常用”的架构决策方法清单——偏工程落地，少理论。每条都写什么时候用、产出、优缺点，最后给一套“80/20 标配组合”。

现在最常用的决策方法（工程实践版）

1) RFC / 设计提案评审（Design Doc / RFC Review）

场景：中大型改造、跨团队影响、有外部依赖的变更。
怎么做：一页或多页设计文档（问题→方案A/B/C→权衡→风险→回滚），线上异步评审+同步评审会。
产出：评审结论、改动清单、遗留问题、后续指标。
优点：共识快、成本低、适配组织协作；易留档。
缺点：如果不强制“量化对比”，容易拍脑袋。
要点：文档内嵌Trade-off 表与回滚计划，引用 SLO&预算。

2) 权衡矩阵（Trade-off Matrix）

场景：在 2–3 个候选架构/云上拓扑/中间件里做选择。
怎么做：对可用性/性能/成本(TCO)/复杂度/交付周期/风险打分或填入实数（推荐实数）。
产出：1 张表 + 结论 + 假设与数据来源。
优点：直观、团队对齐快；适合管理沟通。
缺点：维度权重主观；需配真实数据支撑。
要点：把SLO、停机成本、年度 TCO放进表里，避免空话。

3) ADR（Architecture Decision Record）

场景：任何会影响系统边界/接口/成本的决定（无论大小）。
怎么做：每个决定 1 条 ADR（背景→选项→量化权衡→决策→回滚→验证）。
产出：可追溯的决策档案；PR/变更单引用。
优点：治理性强、可回溯；适合审计与人员更替。
缺点：只记录、不替代分析；若无模板易变成流水账。
要点：强制包含回滚触发条件与验证指标（如 burn rate、P95）。

4) 轻量 ATAM（场景化权衡）

场景：质量属性冲突明显（可用性↔成本、性能↔一致性）。
怎么做：把 NFR 拆成场景（如“Region 挂 30 分钟仍对外 99.95%”），对重要度×难度打分，找敏感点/风险点。
产出：简化版 Utility Tree、风险/敏感点列表。
优点：能把“质量属性”落到可验证场景。
缺点：完整 ATAM 成本高；建议做轻量版（半天内搞定）。
要点：每个场景都要有验证口径（数据源+SLO/阈值）。

5) 实验/金丝雀 + 守护指标（Experiment / Canary with SLO Gates）

场景：对性能、稳定性有不确定性的变更或新中间件上线。
怎么做：5%→25%→100% 放量，stop_if：P95>阈、错误率>阈、burn_rate>2x 自动回滚。
产出：放量对比截图/链接、是否推广的结论。
优点：用事实说话；能避免“大爆炸上线”。
缺点：需要可观测性底座与自动回滚脚本。
要点：把SLO & Error Budget作为发布门禁，而不是“建议”。

6) WSJF / RICE（优先级排序）

场景：多项能力/改造同时竞争资源（平台建设、韧性改造、性能优化）。
怎么做：WSJF =（价值+时效+风险降低）/ 规模；或 RICE = Reach × Impact × Confidence ÷ Effort。
产出：有理有据的 Roadmap 排期。
优点：跨团队对齐投资顺序很有效。
缺点：打分主观；需定期复盘更新分值。
要点：把停机成本/合规风险折算进“价值/时效”。

7) 风险登记+触发器（Risk Register with Triggers）

场景：跨区复制、数据一致性、迁移/割接、重大高风险变更。
怎么做：列出风险，概率×影响评分；为每条风险设触发器（如 lag>15s/10m）与应对动作。
产出：风险台账、演练计划、应对 Runbook。
优点：让风险可运营、可预案，不是“备忘录”。
缺点：没有触发器就会沦为形式。
要点：触发器必须对接告警并链接Runbook。

8) 成本模型 / TCO 评估（含停机成本）

场景：云上选型、多活/主备、日志与追踪留存策略、CDN 与边缘。
怎么做：测算年度 TCO + 停机成本（分钟损失×影响用户），放入权衡矩阵。
产出：成本对比表与单位经济性（Cost/Txn、Cost/1k req）。
优点：管理层买单的通用语言。
缺点：参数需持续校准；早期估算误差较大。
要点：与 SLO 联动：SLO 提升→停机成本下降可抵消一部分 TCO 增量。

80/20 标配组合（推荐你实际落地就用这套）

小团队/中型组织都适用，投入小、收益高。

RFC + Trade-off 表（所有非小改都走）
ADR（每个决定 1 条，PR 必须引用）
金丝雀 + SLO 门禁（stop_if 自动回滚）
轻量 ATAM（半天工作坊：列场景→标敏感点）
WSJF（季度 Roadmap 排序）
风险登记（带触发器）（迁移/跨区/数据一致性类必配）
成本模型（年度复盘，纳入权衡矩阵）

一页式对照表（可贴墙）

方法	典型时机	输入	产出	用时	负责人
RFC/设计提案	中大型变更	问题/约束/选项	评审结论 & TODO	0.5–2 天	方案 Owner
Trade-off	多选其一	SLO、TCO、性能/复杂度	权衡矩阵 & 选择	1–3 小时	架构师
ADR	任意决定	RFC/评审结论	可追溯记录	30–60 分钟	Owner
轻量 ATAM	质量冲突	NFR 场景	Utility Tree & 风险点	半天	架构+SRE
金丝雀+门禁	上线放量	SLO & Budget	对比证据/回滚与否	持续	Dev+SRE
WSJF/RICE	排期取舍	候选能力列表	排序表 & Roadmap	2–4 小时	PM/架构
风险登记	高风险变更	风险清单	触发器 & Runbook	1–2 小时	Owner
成本模型	选型/复盘	账单/流量/人力	年度 TCO & Unit Cost	1–3 天	FinOps

可复制的最小模板片段

Trade-off（行内版）
A: 99.9% / $X / 复杂度3 / 1周 | B: 99.95% / $X+30% / 复杂度4 / 2周 -> 选 B（停机成本年省≈$91k）

ADR 抬头
ADR-2025-10-XX 多Region主备：选 B；回滚触发=burn_rate>2x 或 P95>+20%；验证=金丝雀 5%→25%→100%

金丝雀 stop_if
["p95_ms>阈","error_rate>阈","burn_rate_any>2x"] 触发自动回滚 + 切流

风险登记一条
R1 跨区复制延迟：概率3 影响4=12；触发=lag>15s/10m；应对=降级读主库 + 补偿队列；季度演练

想让我把这套“标配组合”打成一份 Obsidian 模板（带 Front-matter 和 Templater 变量）吗？我可以直接给你可粘贴的文件结构和占位内容。

12 KiB Raw Permalink Blame History Unescape Escape