引言
中间件稳定性尤为重要，本文希望梳理从各个方面形成一个体系回答这个问题。推而广之，其他技术治理也类似。本文主要内容有：
  • 业界案例分析
  • 故障恢复演练
  • 每月攻防演练
  • 遵守变更规范
  • 完善监控告警
  • 事故案例复盘
  • 落实代码CR
一、业界案例分析
以业界一公司的故障举例，由于强依赖缺少降级方案造成比较大的故障。
在早上8点到10点、下午5点到8点为业务高峰，也就是上下班高峰期。
容器团队通过弹性调度在低峰区缩容、高峰期扩容。
容器pod的重建依赖一个摘流系统。
摘流负责发布前流量的拉出、发布后流量的拉入。
摘流系统依赖CMDB去检查应用的合法性。


故障发生在CMDB系统出现假死、整个CMDB无法访问。
‍摘流系统无法访问CMDB、流量的拉入拉出失效。
在高峰期容器弹性扩容后、无法引入流量、导致大量服务不可用。
反思改进，  容器弹性扩缩容强依赖摘流系统、缺少摘流系统异常的降级应对方案。
反思改进，  摘流系统强依赖CMDB系统、缺少CMBD异常后的降级措施。
反思改进，容器弹性扩缩容是后来新增能力，未对依赖的上下游方案通盘走查，是否存在强依赖以及应对措施。
二、故障恢复演练

当故障出现时，5分钟发现、5分钟定位、10分钟恢复，5-5-10。
架构设计上避免故障发生对业务的影响。
例如：RocketMQ主从跨可用区交叉部署。
例如：Kafka核心服务3个副本。
例如：注册中心/配置中心等本地磁盘/缓存容灾设计。
提供容灾迁移能力，当故障发生时迁移到灾备集群。
常备低水位容灾集群、一键/自动迁移到灾备集群。
完善SOP应急手册、人员互备实时Oncall。
应急恢复演练达到或不断逼近10分钟。
三、每月攻防演练
为什么需要重视故障演练？
提高容错性、可恢复性、验证高可用能力。
验证关键指标等告警的时效性。
应急操作恢复的时效演练。
场景：磁盘IO、CPU飙高、磁盘损坏、节点宕机、主从切换、网络分区等。
符合预期，心里有数。
不符预期，强化改进。
四、遵守变更规范
不同等级中间件需符合停留期要求。
变更范围由小到大验证。
变更从非核心服务到核心服务验证。
中间件变更需要整理文档，变更文档需要织评审。
满足可监控、可应急、可灰度基本要求。
变更单需要审批流程。
五、完善监控告警
每个组件梳理完善关键指标。
吞吐QPS、连接数、节点数量、响应时间、节点可用性、硬件指标水位。
确保指标监控告警畅通有效。
每周定期巡检确保水位正常。
六、事故案例复盘
定期复盘线上涉及中间件的案例。
业界的典型案例分析并沉淀文档。
举一反三其他组件和场景。
把别人的经验变成自己的。
反思自身组件需要提高的点。
七、落实代码CR
变更须组织CR并落实记录。
记录CR文档，例如：需求、分支、代办改进项。
强化代码评论，注意评论与代码对应。
使用CR工具，例如：GitLab Merge Requests
先讲解代码结构与主流程。
静默阅读对代码做出评论。
互备同学主评/其他人参评。
讲解人对评论解释和答疑。
总之，不断尝试更为有效的CR方式。
继续阅读
阅读原文
关键词
组件
能力
节点
容灾
方案