在满足需求、有良好的使用体验（基于真实的用户看法，不是开发者自己觉得）基础上，进一步提更高的要求：
- 接口响应超时
- CPU load 升高
- 内存
- GC 频繁
- 死锁
- 大数据量存储
一、三高（高可用 + 高性能 + 高并发）
1.1 高可用(可用性) Availability
可用性强调的是服务的总体持续时间，比如可用性级别为三个九（99.9%）意味着一年 365 天里总共停止服务 8.76 个小时。
可靠性 Reliability
- 功能如预期运行（宁可抛出异常，不要默默地给错误运行）
- 出现故障的频率
- 出现故障也应该不对系统造成太大的影响
- 可维修性：故障定位容易、修复步骤简单、修复成本低廉
和高可用的区别：
- 大部分时候，这两个指标都是密切相关的
- 如果我有一个电视机，每天都准时看儿童频道的《动漫世界》一个小时，然后过去三年也都用得挺好，没有送去修过（导致我看不了），那可以说高可用了（正常运行时间 / 预期运行时间），但是如果这个电视机每次看的时候可能隔一会儿需要拍一巴掌（中间出雪花的时间可以忽略），那这就不能说这个电视机是可靠了。
-
又比如说，我又买了另一个电视机，不需要拍巴掌了，我看的挺开心，不过才高兴两年，坏了，看不了了，楼下电器维修店的小哥搞不定，联系厂家售后维修，一下就是两周看不了电视。对于一个家用电器，两年坏一次可以说高可靠，但是可用性就有问题了（
(365 - 7) / 365 = 98%）。 -
MTBF Mean Time Between Failure 无故障时间，每隔多久遇到一次故障
- MTTR Mean Time To Repair 修复时间，每次遇到故障需要维修多久
-
MTTF Mean Time To Failure
-
根据当前的可用性级别，然后指定合理的可行性目标
- 操作规范/最佳实践
- 预防性维护 Preventive Maintenance
- 合理的 PM 计划：可实施，正确的时机
- 重点是影响最大的故障
- 不断的改进和优化
稳定性 Stability
- 系统运行平稳（不一定如预期执行）
连续性 Continuity
故障出现之后的处理能力：故障能否快速修复，能否不影响主要业务的运行。
比如我有两台电视机，坏了一台，我还有另一台可以看，虽然另一台是之前淘汰的一台黑白电视，效果差点，好歹能用啊。
这台电视就是我们常说的灾难备份，或者说容灾备份。
1.2 高性能 HP Performance
- 处理速度快
- 资源占用低
1.3 高并发 HC Concurrency
- 响应时间
- 吞吐量
- 并发用户数
二、安全性
- 基础设施安全：操作系统、网络、数据库
- 数据安全
- 脱敏：降低数据泄漏所产生的消极影响
三、易用性
四、其他
3.1 可测试性
3.2 可维护性
运维方便，运营方便，二次开发方便
- 代码注释与文档
- 合理的日志
- 监控与数据统计
- 误操作发生率低
- 可理解性：代码可读性，合理的技术框架/系统架构
- 可拓展性：新增功能不需要修改现有结构的能力。分层，合理的耦合度（尽可能的高内聚、低耦合），合理的功能抽象，数据结构可拓展
3.3 可伸缩性 Scalable/Scalability
在系统不需要修改（顶多改改配置）的前提下，通过增加或减少硬件资源来动态提升或降低系统各项能力。
- 通常采用服务器集群的方式。
- 集群一上来，就和高可用有很大关联。
3.4 可扩展性 Extensibility
通过合理的设计，使得新增功能时，不需要改动现有功能，或者只需要对现有系统进行少量调整就行。
总之，将新功能对现有业务逻辑的影响降到最低。
3.5 可观测性
能够方便快捷的了解到程序运行情况。
合理的日志，指标数据的暴露（Pull/Push）。
