1. PaaS高可用概述：什么是PaaS平台高可用、为什么需要高可用、核心指标解读
好，咱们直接进入正题。PaaS平台高可用，这个词你肯定听过。但到底什么是高可用？为什么非做不可？SLA、RTO、RPO这些指标又该怎么理解？
我做了这么多年SRE，见过太多因为高可用没做好而翻车的案例。今天就把这些经验掰开揉碎了讲给你听。
1.1 什么是PaaS平台高可用
说白了，PaaS平台高可用就是：当部分组件挂了，你的平台还能正常提供服务。
举个例子。你搭建了一个Kubernetes集群，上面跑着几十个微服务。突然，一台物理机宕机了。如果平台是高可用的，那这台机器上的Pod会自动调度到其他节点，用户几乎无感知。如果没做高可用，那这台机器上的服务就全挂了。
我个人习惯把高可用拆成两个层面：
- 基础设施层：网络、存储、计算资源要有冗余
- 应用层：服务本身要能扛住单点故障
我在项目中遇到过一种情况：客户说他们的PaaS平台做了高可用，结果一问，只是把数据库做了主从。网络交换机、负载均衡器全是单点。嗯，这种高可用，说白了就是自欺欺人。
核心观点：高可用不是某个组件的特性，而是整个系统的能力。任何一个单点，都可能成为整个平台的阿喀琉斯之踵。
1.2 为什么需要高可用
这个问题其实不用我多说。你想想看，现在的业务对PaaS平台的依赖有多深？
- 开发环境挂了，研发团队没法干活
- 测试环境挂了，版本发布要延期
- 生产环境挂了，直接就是事故
我记得有一次，某电商平台大促期间，PaaS平台的容器编排组件出了问题。结果呢？所有新部署的服务都起不来，扩容也扩不了。那场面，真是惨不忍睹。
为什么需要高可用？三个字：降风险。
具体来说：
- 业务连续性：平台挂了，业务就停了。停1分钟损失多少？你自己算算。
- 用户体验：用户可不管你是底层平台挂了还是应用挂了。他们只知道「这系统真难用」。
- 运维成本：没有高可用，每次故障都要人工介入。半夜爬起来处理故障，你受得了吗？
我的经验：做高可用，前期投入确实大。但比起故障后的损失，这点投入真不算什么。我曾经帮一个客户算过账：他们每年因平台故障造成的损失，是做高可用方案成本的5倍以上。
1.3 核心指标解读：SLA、RTO、RPO
聊高可用，这三个指标绕不开。我见过很多人在面试时背得滚瓜烂熟，但实际用起来就懵了。咱们一个一个说。
1.3.1 SLA：服务等级协议
SLA，全称Service Level Agreement。说白了，就是你和用户之间的一个承诺：我保证你的服务一年能正常用多久。
常见的SLA有：
| SLA | 年停机时间 | 月停机时间 |
|---|---|---|
| 99% | 87.6小时 | 7.3小时 |
| 99.9% | 8.76小时 | 43.8分钟 |
| 99.99% | 52.56分钟 | 4.38分钟 |
| 99.999% | 5.26分钟 | 26.3秒 |
你看，从99.9%到99.99%，看起来只多了0.09%，但年停机时间从8.76小时降到了52分钟。这背后的投入，可不是线性增长的。
我曾经帮一个金融客户做方案，他们要求99.999%的SLA。嗯，那套方案做下来，成本是普通方案的3倍。但金融行业嘛，停1分钟都是大事。
避坑指南：不要盲目追求高SLA。我曾经见过一个团队，为了达到99.999%的SLA，搞了极其复杂的架构。结果呢？复杂度太高，反而更容易出故障。合适的才是最好的。
1.3.2 RTO：恢复时间目标
RTO，Recovery Time Objective。意思是：出故障后，你需要在多长时间内恢复服务。
举个例子。你的PaaS平台挂了，RTO是1小时。那就意味着，从故障发生到服务恢复，不能超过1小时。
RTO决定了你的容灾方案：
- RTO < 5分钟：需要热备，自动切换
- RTO < 1小时：需要温备，手动切换
- RTO > 4小时：冷备就够了，慢慢恢复
我在项目中遇到过一种情况：客户定的RTO是15分钟，但他们的备份数据恢复需要30分钟。这明显不合理。所以，定RTO的时候，一定要考虑实际恢复能力。
1.3.3 RPO：恢复点目标
RPO，Recovery Point Objective。意思是：你能容忍丢失多少数据。
还是举个例子。你的数据库在10:00挂了，RPO是1小时。那就意味着，你最多能接受丢失10:00之前1小时的数据。也就是说，恢复时只能恢复到9:00的状态。
RPO决定了你的备份策略：
- RPO = 0：必须实时同步，不能丢任何数据
- RPO < 5分钟：需要近实时同步
- RPO > 1小时：定时备份就够了
关键点：RTO和RPO是相互关联的。RTO越短，RPO通常也越短。但实现成本会成倍增加。我建议你根据业务重要性，分级别设定不同的RTO和RPO。
1.4 三个指标的关系
这三个指标不是孤立的。它们共同决定了你的高可用方案：
- SLA：决定了你要投入多少资源
- RTO：决定了你的恢复策略
- RPO：决定了你的数据保护策略
我习惯这样思考：先定SLA，再拆解出RTO和RPO。然后根据RTO和RPO，设计具体的容灾方案。
举个例子：
- SLA = 99.99% → 年停机不超过52分钟
- RTO = 10分钟 → 故障后10分钟内恢复
- RPO = 5分钟 → 最多丢失5分钟数据
那你的方案就得是：热备 + 自动切换 + 实时数据同步。成本高，但能扛住。
我的建议：刚开始做高可用，别追求极致。先做到99.9%的SLA，RTO控制在1小时内，RPO控制在15分钟内。等团队成熟了，再逐步提升。一口吃不成胖子。
1.5 小结
这一章咱们聊了：
- 什么是PaaS平台高可用：说白了就是扛得住故障
- 为什么需要高可用：降风险、保业务、省成本
- 三个核心指标：SLA是承诺，RTO是恢复速度，RPO是数据丢失容忍度
下一章，咱们会深入聊PaaS平台的常见故障模式。嗯，那些让你半夜爬起来处理的故障，我都会一一拆解。
记住一句话：高可用不是锦上添花，而是雪中送炭。别等出了事故才后悔。