用质量属性场景描述系统要求

“响应要快”“系统要稳定”“以后容易扩展”都表达了合理愿望，却不足以指导架构。它们没有说明谁在什么条件下做什么，也没有说明系统做到什么程度才算合格。质量属性场景把这种模糊愿望改写成可分析的行为约束，使设计、测试和运营能够讨论同一件事。

质量属性描述系统怎样完成职责。性能关注请求在负载下的时间与吞吐，可用性关注故障发生后的服务连续性和恢复，安全性关注对攻击与误用的抵抗，可修改性关注变化的范围、代价和风险。属性之间并不独立：加密会消耗资源，强一致复制可能增加延迟，过度拆分会扩大运维和测试负担。

一个场景需要六个部分

常用的质量属性场景包含刺激来源、刺激、环境、受影响对象、系统响应和响应度量。词语不必机械套用，但信息不能缺失。

例如“接口应快速响应”可以改写为：工作日上午业务高峰期间，已认证用户向地图要素查询接口发起符合配额的请求；API 服务在数据库正常、缓存部分失效的条件下完成查询；95% 请求在 800 毫秒内返回，99% 请求在 2 秒内返回，错误率不超过约定阈值。这个场景把负载、系统状态和测量口径放进了要求。

可用性场景可以写成：主数据库实例在正常流量下不可达，平台检测故障并切换到可用副本；写服务恢复时间不超过既定目标，已确认事务的数据丢失不超过恢复点目标，操作人员能从告警中辨认故障范围。它仍需结合实际能力验证，不能仅因架构图中画了副本就判定满足。

可修改性场景则关注变化：法规要求新增一种内容保留规则时，由平台团队完成配置、迁移和验证；现有内容 API 保持兼容，改动限制在内容与审计模块，能够在一个发布窗口内上线并回退。这里的度量可以是受影响模块、工作量、停机时间或缺陷风险，不一定都是运行时数字。

场景从真实业务事件中来

质量属性不能只由架构师独自填写。产品、开发、测试、运维、安全和数据人员掌握不同的失败经验和约束。SEI 的 Quality Attribute Workshop Collection 描述了一类由利益相关方参与、提出并整理质量属性场景的方法。它的价值在于暴露各方真正重视的事件，而不是追求一份通用清单。

收集场景时可以从历史故障、业务峰值、外部依赖中断、审计要求、计划中的产品变化和无法接受的用户体验入手。参与者先提出具体事件，再消除重复、补足条件并排序。优先级不只看发生概率，还要看失败后果、恢复难度和架构决定是否难以逆转。

通用场景可以帮助团队不遗漏常见因素，但最终必须落到系统语境。同样是“拒绝未授权访问”，内容管理后台、公开检索接口和内部批处理使用的主体、资源与响应完全不同。照抄别的系统的阈值，得到的只是看起来精确的数字。

场景怎样影响架构

场景用于比较候选结构，而不是直接指定技术。性能场景可能引出缓存、索引、异步处理或预计算；可用性场景可能需要冗余、健康检查、故障隔离和恢复流程；可修改性场景可能推动稳定接口、模块边界和自动化测试。每种手段都有成本和副作用。

Reasoning About Software Quality Attributes 汇集了 SEI 关于质量属性推理的资料。分析时应找出架构敏感点和权衡点：哪些决定一改变就明显影响某个属性，哪些决定同时改善一个属性并损害另一个属性。数据库同步复制就是典型例子，它可能改善数据持久性，却增加写入路径延迟和故障处理复杂度。

方案评审不应只问“是否支持高可用”，而要沿场景检查刺激到达后经过哪些组件、在哪里检测、系统如何响应、度量由什么证据证明。证据可以来自原型、负载测试、故障演练、静态分析或已经运行的监控数据。没有证据的判断应明确标记为假设。

度量要能重复

“平均响应时间”容易掩盖长尾；“全年可用性”可能忽略关键业务时段；“恢复成功”如果没有恢复时间和数据损失口径，也无法比较。度量应说明统计范围、时间窗口、百分位、样本排除规则和观测点。服务端 500 毫秒并不等于用户端 500 毫秒。

可测试并不意味着所有场景都能在实验室完整复制。大规模区域故障、长期数据漂移和组织变化可能只能通过演练、模型或分阶段验证评估。此时应记录验证强度和剩余风险，不把部分测试写成全面保证。

场景也需要随系统演进。流量、用户群体、合规环境或部署方式变化后，旧阈值可能过松，也可能已经不现实。把场景与架构决定、测试和监控关联起来，才能在条件变化时找到应重新评估的内容。

参考资料

Reasoning About Software Quality Attributes，Carnegie Mellon Software Engineering Institute。
Quality Attribute Workshop Collection，用于利益相关方研讨与场景形成方法。
Software Architecture，用于架构、质量属性和分析实践的整体关系。