一、个人认知迭代
自从2022年7月4日JD机房断电故障后，ITU持续投入了大量人力来加固PaaS组件的稳定性，希望验证和强化组件在机房级别故障下的容灾能力，降低故障RTO时间。我近半年个人的工作重心也转移到建设公司级别的容灾演练平台上了，在此过程中，在系统稳定性上也有了一些认知迭代，想和大家分享下。
1.1、墨菲定律
在互联网领域，高性能、高并发、高可用相关的讨论屡见不鲜，三高问题中高性能和高并发大家工作中接触较多，对于高可用，往往是纸上谈兵。前几年提到高可用，什么同城容灾架构、异地容灾架构、两地三中心方案层出不穷，坊间还充斥着支付宝CTO剪网线、饿了么CTO主动做IDC断网测试等各种段子，美团在2019年也组织过GQ、YF机房整体断网演练。前几年业界内没有发生大规模的机房级别故障，我也会怀疑是否有必要投入高昂的成本来建设机房容灾能力。然而最近两年，先后出现亚马逊机房故障、美团0704故障到最近的阿里云香港机房故障，这些故障也印证了墨菲定律：如果事情有变坏的可能，不管这种可能性有多小，那么它总会发生
1.2、AZ容灾的ROI
仅从单量损失看，美团0704故障订单损失约3%~5%，金额损失好像是700多万。而从AZ容灾的投入看，人力投入成本加上机房建设成本必然是远超过这个数字。但是除账面损失外，故障时候大量客诉显然让公司付出了更大的隐性损失，“#美团挂了”一度登上微博热搜，这也违背了“以客户为中心，长期有耐心”的美团价值观。巧合的是最近阿里云香港机房故障，张勇也提到“任何故障的发生，对阿里是万分之一、百万分之一的概率，一旦发生在每个客户身上就是百分之百。我们必须急客户所急，想客户所想，既主动解决客户看得到的问题，更要把客户尚未感知到的风险防患于未然”。所以建设AZ容灾能力短期收益可能不高，也不太可能一蹴而就，需要持续去提升，可以看做是一个长期价值投资。
1.3、顺势而为
JD 0704故障后，可以明显感受到公司自上而下都更重视AZ容灾能力建设了，每周都会组织各种稳定性会议进行吹风讨论。从ITU的各个中间件到业务部门，在建设和验证AZ容灾能力上基本能达成共识。这对于我们是一个绝佳的机会，我们应该抓住这个风口来建设并打磨演练工具。在平台建设上，我们要形成一套具备高实操性的服务容灾常态化演练机制，尽可能降低组件方接入成本，奉行“把困难留给自己，把简单交给用户”的策略来支持更多的组件进行各类容灾演练，以演练作为抓手来提升组件的容灾能力。
二、系统稳定性建设模型
根据公司和业内的一些经验，我们可以从以下几个方面作为抓手来建设系统的稳定性。具体到每个子模型，按照从低到高提出了L0、L1、L2和L3四个不同级别的能力模型。
2.1、流程规范
大公司一般对流程规范这项都很看重，只要是人都难免会犯错，公司希望通过一些规章制度来避免由于人为不规范操作导致的线上故障，例如我司的COE”六要两不要”生产规则，就是严格的高压线，一旦违反就可能会有严重的后果。
| 安全生产准则 | 是否违规 | 违规说明 | |
|---|---|---|---|
| 六要 | 要测试 | ||
| 要周知 | |||
| 要审核 | |||
| 要灰度 | |||
| 要观测 | |||
| 要可回滚 | |||
| 两不要 | 不要瞒报故障 | ||
| 不要违规变更数据 | |||
流程规范：团队内部应用的关于线上系统运维的流程、规章制度等。
- L0：没有流程机制，完全依赖RD的个人经验。
- L1：有完善的流程机制，如值班机制、故障复盘机制、故障处理流程等，但缺少落地保障机制。
- L2：将流程机制沉淀为经验库，形成SOP。并将部分流程机制线上化，通过系统进行辅助。
- L3：流程规范线上化，成为研发交付标准流程和卡点，基本上不再依赖人的经验。
2.2、变更管控
对所有线上变更操作的管控
- L0：变更随意，缺少对线上变更操作的评估和管控。
- L1：有流程和机制来约束线上变更操作，有对应的应急预案。是否落地执行依赖RD经验，无法有效管控。
- L2：评估影响范围且有对应的应急预案。完善的线上变更操作SOP，并有系统进行支撑。沉淀各类线上变更的评估项，形成经验库。
- L3：线上变更具备灰度、降级、快速回滚能力，具备自动发现系统异常能力，对业务零影响。
2.3、风险感知
发现和定位线上系统问题
- L0：系统缺少监控报警，线上问题完全依赖客服商服等人工反馈。
- L1：监控覆盖了部分核心业务场景，部分场景有遗漏。
- L2：监控覆盖全部核心业务场景，业务正确性监控覆盖部分业务场景。具备较完善的系统资源、应用、业务立体化的监控告警能力。
- L3：监控覆盖全部核心业务场景，业务正确性监控覆盖全部核心业务场景。具备风险预防能力，能提前发现系统潜在隐患并及时修复。部分场景具备秒级发现和定位问题的能力。
2.4、风险控制
控制线上已经出现的线上故障，确保系统具备服务能力
- L0：故障处理缺少预案、工具辅助，导致线上故障升级。系统缺少自我保护。
- L1：核心场景有预案，具备快速止血能力，但需要有经验的RD负责组织协调，依赖个人经验主义。
- L2：预案覆盖关键的核心和非核心场景，人工干预少。系统具有快速止损和恢复能力，平均恢复时长在30分钟以内。
- L3：达成1-5-10目标，1分钟发现，5分钟定位，10分钟恢复。预案操作初步实现自动化。
2.5、容量评估
评估业务流量与系统资源之间的关系、系统资源调度能力
- L0：缺少容量评估意识、动作，无弹性扩容能力。
- L1：具备全链路压测能力，核心资源具备弹性扩容能力。
- L2：具备分钟级的弹性调度能力，30分钟内完成扩容且系统恢复正常。
- L3：具备秒级弹性扩容能力，10分钟内完成扩容且系统恢复正常。
2.6、预防与演练
提前发现和预防潜在的风险
- L0：核心场景缺少巡检、演练。
- L1：日常有进行周期性巡检，对潜在风险提前优化。核心场景有预案但没有演练，RD对预案操作不熟悉。
- L2：巡检工具代替人工巡检。定期进行预案演练，RD对预案操作非常熟练。
- L3：具备在线破坏检测能力，真正落地混沌工程。
2.7、容灾架构
系统发生故障时,能够尽可能地保证业务的连续性
- L0：单AZ内多机部署，并支持单机故障自动迁移（依赖PasS侧），单AZ故障，服务一定不可用。
- L1：多AZ内多机部署（同城或异地），并支持单AZ故障自动迁移（依赖PaaS侧N+1容灾能力），非核心服务可通过降级进行容灾
- L2：核心服务（含依赖PaaS资源）做SET化部署，SET间两两互备，互备SET异地部署，数据双向实时同步且保障最终一致；数据无法分片且被SET服务频繁访问的服务做City部署，依赖数据做异地主从集群部署；其他服务做中心部署。 单AZ故障，SET服务（含依赖PaaS资源）及City服务通过人工切换到互备SET实现容灾，City服务依赖PaaS及中心服务依赖PaaS侧N+1容灾能力进行容灾，非核心服务可通过人工降级进行容灾。
- L3：核心服务（含依赖PaaS资源）做SET化部署，SET间两两互备，互备SET异地部署，数据双向实时同步且保障最终一致，SET自身数据与互备SET备份数据独立集群存储；数据无法分片且被SET服务频繁访问的服务做City部署，依赖数据在每个SET部署只读副本；其他服务做中心部署。 单AZ故障，SET服务（含依赖PaaS资源）及City服务通过人工切换到互备SET实现容灾，City服务依赖PaaS及中心服务依赖PaaS侧N+1容灾能力进行容灾，非核心服务可通过自动降级进行容灾。
2.8、服务治理
服务链路依赖、容量、架构、代码风险治理
- L0：服务具备基本的弹性和韧性(超时、限流、熔断、重试)配置，服务Owner及团队对服务的容量具备感性的认知，但缺乏服务治理的理论依据。 服务接入统一框架，具备基本的内部和外部请求链路图，服务Owner及团队在接新需求和重构过程中具备基本的统一框架认知。 建立统一代码规范，各团队感知并初步解决代码扫描暴露的风险。 涉及协议：MThrift Http。
- L1：服务的弹性和韧性配置相关的阈值在逐步形成的统一巡检标准范围内，服务Owner及团队理解统一巡检的各项规则。 服务利用统一框架对自身上下游链路形成画像，通过内外步链路图指导其开发迭代和容量风险评估。 各团队根据统一代码规范，完善代码，代码扫描保留出的风险逐步收敛。 涉及协议：MThrift Http Mafka Zebra Cache。
- L2：服务的弹性和韧性配置相关的阈值与统一服务治理理论相一致，服务Owner及团队具备服务治理的理论依据，并共同逐步完善理论。服务治理统一化、常态化、部分自动化。 服务链路依赖全面基于统一框架迭代，各类标签健全。 各团队根据统一代码规范迭代，常态的代码扫描暴露的风险数平稳。 涉及协议：全部。
- L3：服务的弹性和韧性全面自动化，并具备一定的预测能力。 通过服务画像自动识别迭代中存在的链路风险。 涉及协议：全部。
