配速记页 02-quality 使用。
一个残酷的事实：功能，随便哪个团队都能实现；区分系统高下的，是质量属性。淘宝和一个小商城，功能列表几乎一样，但一个是每秒百万订单、一个是每天三百单。
架构设计的本质：在有限资源下，为互相冲突的质量属性做分配。这就是「架构=一系列决策」的定义（Bass），每个决策都在给某些属性加分、给另一些减分。架构师的价值不是画框图，是让这些加减显性化、可辩护。
每个质量属性背后都有一门真实世界的学问，理解了它，战术就不用死记：
性能 = 排队论 请求到达是随机的（泊松到达），服务时间是随机的，系统本质是一个排队网络。利特尔法则 L = λW（系统内请求数 = 到达率 × 响应时间）解释了为什么并发涨一点、延迟涨一截。
可用性 = 故障经济学 硬件一定会坏、网络一定会断、人一定会犯错。可用性思维不是「消灭故障」，是管理 MTBF 和 MTTR 的比值。五个9不是靠零件可靠，是靠快速检测 + 快速恢复。
可修改性 = 变更成本曲线 软件 60%-80% 的成本花在维护。可修改性的全部秘密：把「变化的」和「不变的」分开（关注点分离）。
安全性 = 攻击面经济学 攻击者的决策模型：攻击成本 < 攻击收益才动手。防御不是打造不可破的墙，是把攻击成本抬到收益之上。限制暴露（最小攻击面）、纵深防御（突破一层还有一层）都在抬成本。
可测试性 = 可控 + 可观测 能控制输入、能观察输出，就能测试。这就是为什么 mock、日志、链路追踪是可测试性基础设施。
易用性 = 用户认知成本 常被工程师轻视，但案例题出现「新手培训时间」场景时要能识别出来。
战术是设计原语（如「引入缓存」），架构模式是打包好的战术组合（如「读写分离架构」=缓存+多副本+负载均衡）。这个层次关系解释了为什么学战术比背模式高效：模式千变万化，原语就那几十个。
因为所有属性都在竞争同一批资源：
权衡点是架构的常态而非意外。ATAM 的全部意义，就是把这些权衡从架构师的直觉里挖出来放到桌面上。
「系统要高可用」没法分析。「主库宕机后 30 秒内完成主备切换、数据丢失不超过 10 笔交易」可以分析、可以测试、可以争优先级。效用树的方法论价值：把质量属性从形容词降维成场景（刺激-环境-响应），并让干系人对 I（重要度）/M（实现难度）打分——这张表就是后续所有架构讨论的议程。