4、可用性准则：高可用架构设计、灾备与业务连续性、性能监控与容量规划、SLA管理
可用性，说白了就是你的系统到底能不能用、好不好用。SOC2审计里，可用性准则关注的是系统在承诺的时间内能不能正常提供服务。我做了这么多年审计，见过太多系统平时跑得挺好，一到关键时刻就掉链子的情况。嗯，这里面的门道，咱们一个一个说。
4.1 高可用架构设计
高可用架构，不是说你买几台服务器堆在一起就完事了。我见过不少团队，觉得上了双机热备就万事大吉，结果主备切换时数据丢了半天的量。为什么会这样？因为架构设计没考虑清楚。
我个人习惯把高可用分成三个层次来看：
- 基础设施层：电源、网络、服务器硬件的冗余。别小看这个，我曾经有个客户，机房UPS坏了，结果整个业务停了4小时。你说冤不冤？
- 应用层：无状态设计、负载均衡、自动伸缩。说白了，你的应用不能依赖某台特定的机器。
- 数据层：数据库主从、分片、多活。这是最难的，也是坑最多的。
核心原则：单点故障（SPOF）必须消除。你想想看，如果某个组件挂了，整个系统就瘫了，那这个组件就是你的命门。
举个例子，一个典型的Web应用高可用架构：
用户 → DNS轮询 → 多台Nginx反向代理 → 应用服务器集群 → 数据库主从/读写分离这里每个环节都要考虑冗余。DNS层面可以做多机房，Nginx可以搞Keepalived，应用服务器用K8s管理，数据库至少一主一从。我在项目中遇到过，客户只做了应用层的高可用，结果数据库挂了，应用层再健康也没用。所以，全链路的高可用才是真高可用。
4.2 灾备与业务连续性
灾备和业务连续性，很多人混为一谈。其实不一样。灾备是技术层面的，比如数据备份、异地容灾。业务连续性（BCP）是管理层面的，包括人员、流程、沟通机制。
我记得有一次审计，客户说他们有灾备方案。我问：「备份数据恢复过吗？」对方沉默了。嗯，这里要注意：没验证过的灾备方案，等于没有。
灾备的几个关键指标：
| 指标 | 说明 | 常见目标 |
|---|---|---|
| RTO（恢复时间目标） | 从故障发生到业务恢复，最长能接受多久 | 金融行业通常4小时内 |
| RPO（恢复点目标） | 最多能丢失多长时间的数据 | 核心业务通常15分钟内 |
我曾经帮一个客户做灾备演练，他们的RTO目标是2小时，结果实际恢复用了6小时。为什么？因为文档没更新，新加的几台服务器根本没在灾备清单里。所以，灾备方案要定期演练，至少一年一次。
避坑指南：我曾经见过一个团队，备份数据存在同一台存储上。结果存储坏了，备份和源数据一起丢。记住：备份要遵循3-2-1原则——3份副本，2种介质，1份异地。
4.3 性能监控与容量规划
性能监控，不是装个Prometheus就完事了。你得知道监控什么、怎么报警、谁来响应。我个人的习惯是，先定义关键指标（KPI），再搭监控。
常见的性能指标：
- 响应时间：用户请求到返回结果的时间。超过2秒用户就开始不耐烦了。
- 吞吐量：单位时间内能处理多少请求。QPS、TPS都是这个范畴。
- 错误率：5xx错误、超时、连接失败的比例。一般要求低于1%。
- 资源使用率：CPU、内存、磁盘、网络。别等到100%了才报警，那已经晚了。
容量规划，说白了就是预测未来需要多少资源。你想想看，双十一、618这种大促，如果没提前扩容，系统分分钟被打趴。我有个客户，平时QPS只有1000，结果搞了个活动，流量瞬间冲到5000，服务器直接挂了。后来他们学乖了，每次活动前都做压测和扩容。
注意：容量规划不是一次性工作。业务在增长，用户行为在变化，你的容量规划也要动态调整。我建议每季度做一次容量评估，至少提前一个月准备大促资源。
4.4 SLA管理
SLA（服务等级协议），是可用性准则的最终体现。你跟客户承诺了99.9%的可用性，那就得做到。做不到怎么办？赔钱呗。所以SLA管理，本质上是一种风险管理。
SLA的几个关键点：
- 定义清楚：什么算可用？什么算不可用？维护窗口算不算？这些都要白纸黑字写清楚。
- 可测量：可用性怎么算？通常用这个公式：
可用性 = (总时间 - 不可用时间) / 总时间 × 100% - 有惩罚机制：达不到SLA，客户能获得什么补偿？这既是约束，也是信任的体现。
举个例子，99.9%的可用性，一年最多允许宕机8.76小时。99.99%呢？只有52.56分钟。你想想看，你的系统能扛住吗？
我的经验：SLA不是越高越好。99.999%的可用性，成本是指数级上升的。你要根据业务价值来定。核心交易系统可以定高一些，非核心系统适当放宽。别为了面子，给自己挖坑。
最后说一句，可用性准则不是技术部门的事。它需要运维、开发、产品、甚至法务一起参与。我见过最好的团队，他们把可用性指标写进了KPI，每个人都知道自己该做什么。嗯，这才是真正把可用性落地的样子。