名称: 质量属性分类法 描述: 用于非功能性需求的“-ilities”框架。用于定义NFRs、评估架构权衡或在系统设计中确保质量属性得到处理。涵盖可扩展性、可靠性、可用性、性能、安全性、可维护性等。 允许工具: Read, Glob, Grep
质量属性分类法
本技能提供了一个全面的框架，用于理解和应用质量属性（非功能性需求）在系统设计中。
何时使用此技能
关键词: NFR, 非功能性需求, 质量属性, -ilities, 可扩展性, 可靠性, 可用性, 性能, 安全性, 可维护性, ISO 25010
在以下情况下使用此技能:
- 定义系统的非功能性需求
- 评估架构权衡
- 进行架构评审
- 准备系统设计面试
- 确保所有质量维度都得到考虑
- 将业务需求转换为技术需求
什么是质量属性？
质量属性（QAs）描述系统如何执行，而不是它做什么。它们通常被称为：
- 非功能性需求（NFRs）
- “-ilities”（可扩展性、可靠性等）
- 横切关注点
- 系统质量
关键见解: 功能性需求定义功能；质量属性定义这些功能的工作效果。
核心质量属性
主要属性（六大属性）
| 属性 | 定义 | 关键问题 |
|---|---|---|
| 可扩展性 | 处理增长的负载 | 我们能增长10倍？100倍？ |
| 可靠性 | 一致的正确操作 | 每次都能正常工作吗？ |
| 可用性 | 系统运行时间 | 需要时是否运行？ |
| 性能 | 速度和吞吐量 | 有多快？ |
| 安全性 | 保护免受威胁 | 安全免受攻击吗？ |
| 可维护性 | 易于更改 | 能轻松更新吗？ |
次要属性
| 属性 | 定义 | 关键问题 |
|---|---|---|
| 可测试性 | 易于验证 | 能有效测试吗？ |
| 可观察性 | 系统可见性 | 能看到发生了什么吗？ |
| 可操作性 | 易于操作 | 能在生产中运行吗？ |
| 可移植性 | 平台独立性 | 能移动它吗？ |
| 互操作性 | 系统集成 | 能与其他系统协同工作吗？ |
| 成本效率 | 资源优化 | 成本效益高吗？ |
详细质量属性定义
可扩展性
定义: 通过添加资源处理增加负载的能力。
| 类型 | 描述 | 示例 |
|---|---|---|
| 垂直扩展 | 向现有机器添加更多能力 | 升级到更大实例 |
| 水平扩展 | 添加更多机器 | 在负载均衡器后添加更多服务器 |
| 弹性扩展 | 基于负载自动扩展 | 自动扩展组 |
测量:
- 最大并发用户数
- 给定延迟下的每秒请求数
- 支持的数据量
- 规模化下的每笔交易成本
权衡:
- 可扩展性通常与一致性冲突（CAP定理）
- 更高可扩展性 = 更高复杂性
- 水平扩展需要无状态设计
可靠性
定义: 随时间正确操作的概率。
| 概念 | 定义 |
|---|---|
| MTBF | 平均无故障时间 |
| MTTR | 平均恢复时间 |
| 容错 | 在组件故障时继续运行 |
| 韧性 | 从故障中优雅恢复 |
测量:
- 错误率（错误 / 总请求数）
- 故障率（故障 / 时间段）
- 数据准确率百分比
- 成功交易率
权衡:
- 更高可靠性 = 更高成本（冗余）
- 可靠性 vs 性能（校验和、验证）
- 可靠性 vs 复杂性（更多故障模式处理）
可用性
定义: 系统运行时间的比例。
| 级别 | 运行时间 | 每年停机时间 | 每月停机时间 |
|---|---|---|---|
| 99% | 两个9 | 3.65天 | 7.31小时 |
| 99.9% | 三个9 | 8.76小时 | 43.8分钟 |
| 99.99% | 四个9 | 52.6分钟 | 4.38分钟 |
| 99.999% | 五个9 | 5.26分钟 | 26.3秒 |
测量:
可用性 = 运行时间 / (运行时间 + 停机时间)
= MTBF / (MTBF + MTTR)
权衡:
- 每个额外“9”成本指数级增加
- 可用性 vs 一致性（CAP定理）
- 计划维护影响可用性
性能
定义: 系统运行的速度和效率。
| 指标 | 定义 |
|---|---|
| 延迟 | 完成一个请求的时间 |
| 吞吐量 | 单位时间处理的请求数 |
| 响应时间 | 用户等待的总时间 |
| 利用率 | 资源使用百分比 |
常见目标:
- 网页加载: < 2秒
- API响应: < 100毫秒 (p99)
- 数据库查询: < 10毫秒
- 批处理作业: < 预定窗口
权衡:
- 性能 vs 成本（更快硬件成本更高）
- 延迟 vs 吞吐量（批处理提高吞吐量，损害延迟）
- 性能 vs 一致性（缓存提高速度，可能提供过时数据）
安全性
定义: 保护数据和系统免受未授权访问。
| 原则 | 描述 |
|---|---|
| 机密性 | 数据仅对授权访问 |
| 完整性 | 数据准确且未被篡改 |
| 可用性 | 需要时系统可访问 |
| 不可否认性 | 行动可归属 |
测量:
- 检测违规的时间
- 漏洞数量
- 合规审计结果
- 平均补丁时间
权衡:
- 安全性 vs 可用性（更多安全性 = 更多摩擦）
- 安全性 vs 性能（加密增加延迟）
- 安全性 vs 成本（安全工具和专业知识昂贵）
可维护性
定义: 随时间易于修改系统的能力。
| 方面 | 描述 |
|---|---|
| 模块化 | 组件可独立更改 |
| 可重用性 | 组件可重用 |
| 可分析性 | 易于理解系统 |
| 可修改性 | 易于进行更改 |
| 可测试性 | 易于验证更改 |
测量:
- 实现典型更改的时间
- 每次更改的缺陷注入率
- 代码复杂度指标
- 文档覆盖率
权衡:
- 可维护性 vs 性能（抽象增加开销）
- 可维护性 vs 上市时间（良好设计需要时间）
- 可维护性 vs 专门化（通用 = 较慢）
质量属性场景
如何指定质量属性
使用此模板使质量属性可测量：
来源: [谁或什么产生刺激？]
刺激: [发生什么事件？]
工件: [系统哪部分受影响？]
环境: [在什么条件下？]
响应: [系统应如何响应？]
测量: [如何知道成功？]
示例场景
可扩展性场景:
来源: 营销活动
刺激: 10倍流量峰值
工件: Web应用程序
环境: 正常操作
响应: 自动扩展以处理负载
测量: 延迟保持在200毫秒以下 (p99)
可用性场景:
来源: 硬件故障
刺激: 数据库服务器宕机
工件: 订单处理系统
环境: 业务高峰期
响应: 故障转移到副本
测量: 恢复时间 < 30秒，无数据丢失
安全性场景:
来源: 外部攻击者
刺激: SQL注入尝试
工件: 用户认证
环境: 生产环境
响应: 阻止攻击，警报安全团队
测量: 零成功注入，5分钟内警报
ISO 25010 质量模型
ISO 25010标准定义了8个质量特性：
| 特性 | 子特性 |
|---|---|
| 功能性适宜性 | 完整性、正确性、适当性 |
| 性能效率 | 时间行为、资源利用、容量 |
| 兼容性 | 共存性、互操作性 |
| 可用性 | 可学习性、可操作性、可访问性 |
| 可靠性 | 成熟度、可用性、容错、可恢复性 |
| 安全性 | 机密性、完整性、不可否认性、责任性 |
| 可维护性 | 模块化、可重用性、可分析性、可修改性、可测试性 |
| 可移植性 | 适应性、可安装性、可替换性 |
系统设计面试中的质量属性
如何解决质量属性
- 询问需求: “预期的延迟是多少？可用性目标是什么？”
- 陈述假设: “我假设我们需要99.9%的可用性”
- 证明决策: “我在这里添加缓存以提高性能”
- 承认权衡: “这提高了可扩展性但复杂了一致性”
面试中常见的质量属性权衡
| 决策 | 改进 | 损害 |
|---|---|---|
| 添加缓存 | 性能 | 一致性、复杂性 |
| 添加复制 | 可用性 | 一致性、成本 |
| 使用异步处理 | 吞吐量 | 延迟、复杂性 |
| 分片数据库 | 可扩展性 | 跨分片查询 |
| 添加加密 | 安全性 | 性能 |
| 使用微服务 | 可维护性、可扩展性 | 延迟、复杂性 |
设计评审的质量属性检查清单
最终确定设计前，验证：
- [ ] 可扩展性: 能处理10倍增长吗？
- [ ] 可靠性: 处理组件故障吗？
- [ ] 可用性: 满足运行时间目标吗？
- [ ] 性能: 满足延迟/吞吐量目标吗？
- [ ] 安全性: 保护数据和访问吗？
- [ ] 可维护性: 易于更新和调试吗？
- [ ] 成本: 规模化下在预算内吗？
- [ ] 可观察性: 能监控和故障排除吗？
按质量属性的架构战术
可扩展性战术
| 战术 | 描述 |
|---|---|
| 水平扩展 | 添加更多实例 |
| 负载均衡 | 分发流量 |
| 分片 | 分区数据 |
| 缓存 | 减少重复工作 |
| 异步处理 | 解耦组件 |
可用性战术
| 战术 | 描述 |
|---|---|
| 冗余 | 组件的多个实例 |
| 故障转移 | 自动切换到备份 |
| 健康检查 | 早期检测故障 |
| 优雅降级 | 减少功能而非完全故障 |
| 地理分布 | 生存数据中心故障 |
性能战术
| 战术 | 描述 |
|---|---|
| 缓存 | 减少计算/IO |
| CDN | 服务内容更接近用户 |
| 连接池 | 重用昂贵连接 |
| 压缩 | 减少数据传输 |
| 索引 | 加速查询 |
安全性战术
| 战术 | 描述 |
|---|---|
| 加密 | 保护静止和传输中的数据 |
| 认证 | 验证身份 |
| 授权 | 控制访问 |
| 审计日志 | 跟踪行动 |
| 输入验证 | 防止注入攻击 |
从业务需求到质量属性
转换指南
| 业务需求 | 质量属性 | 技术影响 |
|---|---|---|
| “必须处理黑色星期五流量” | 可扩展性 | 自动扩展、弹性容量 |
| “不能丢失订单” | 可靠性、持久性 | 复制、备份、事务 |
| “始终可用” | 可用性 | 冗余、故障转移、监控 |
| “快速结账” | 性能 | 缓存、优化、CDN |
| “保护客户数据” | 安全性 | 加密、访问控制、审计 |
| “易于添加功能” | 可维护性 | 模块化设计、清洁架构 |
| “法规合规” | 安全性、可审计性 | 日志、加密、访问控制 |
| “全球用户” | 性能、可用性 | CDN、地理分布 |
相关技能
design-interview-methodology- 总体面试框架estimation-techniques- 量化容量需求cap-theorem- 一致性/可用性权衡 (阶段 2)trade-off-analysis- ATAM和决策框架 (阶段 5)architectural-tactics- 按属性的详细战术 (阶段 5)
相关命令
/sd:analyze-nfrs [scope]- 分析代码中的质量属性 (阶段 5)/sd:explain <concept>- 解释任何质量属性
相关代理
trade-off-analyzer- 评估设计权衡 (阶段 2)sre-persona- 可靠性/可观察性视角 (阶段 5)security-architect- 安全性影响 (阶段 5)
版本历史
- v1.0.0 (2025-12-26): 初始发布
最后更新
日期: 2025-12-26 模型: claude-opus-4-5-20251101