G行云原生那点事儿，怎么搞得更稳更抗摔一点的实践分享

根据G行技术团队在多次内部分享及部分对外技术文章中的核心观点整理）

我们行搞云原生也不是一天两天了,一开始大家觉得上了容器、用了Kubernetes，搞了微服务，就等于高枕无忧了，但现实很骨感，线上该出的问题一个没少，有时候因为服务拆得更散了，链路更复杂，问题反而更隐蔽、影响面更广，这几年我们核心的精力，不是追求更多花哨的新技术，而是扎扎实实地思考怎么让这套体系更稳、更抗摔，说白了，就是怎么让系统在出问题时，能自己“扛过去”，或者把影响降到最低，而不是动不动就需要深更半夜把兄弟们拉起来救火。

我们的实践,主要围绕几个方面来搞：

第一，在“防”字上下功夫，把故障扼杀在摇篮里。

光靠事后救火太被动了,我们觉得预防才是最好的稳定性策略。

• 代码质量卡得更严了。 以前可能单元测试覆盖率有个要求就差不多了，现在我们在流水线里加入了更多的自动化检查关卡，比如静态代码扫描重点看那些可能导致空指针、资源泄漏的“坏味道”；集成测试阶段，不仅仅测试正常流程，还必须要求开发同学编写异常场景和边缘情况的测试用例，比如模拟下游超时、返回异常码等，通不过这些测试，代码就别想上线。（来源：G行DevOps团队关于质量门禁的分享）
• 基础设施的“体检”常态化。 我们对Kubernetes集群本身也不是完全信任的，会定期用一些混沌工程工具，比如故意干掉一个工作节点，或者模拟网络延迟，来检验我们的应用是否真的能按照预设的策略实现高可用，这种“主动找茬”的方式，帮我们提前发现了不少配置上的漏洞，比如某个服务的副本数虽然设了3个，但都调度到了同一个物理节点上，这个节点一挂，服务照样全瘫。（来源：G行SRE团队混沌工程实践内部分享）

第二，在“控”字上做文章，让故障发生时能及时刹车。

万一没防住,问题真的发生了，最关键的是要能快速发现、快速隔离，避免雪球越滚越大。

• 监控告警不说“废话”。 我们吃过告警泛滥的亏，一大堆无关紧要的警告把真正重要的信息淹没了，现在我们强调告警的“精准性”和“可操作性”，指标告警一定要关联到具体的业务含义，比如不是简单报“CPU使用率高”，而是报“支付服务响应时间超过500ms的请求比例超过5%”，这样一看就知道是哪个业务出了问题，严重程度如何，告警信息里会直接附带初步的诊断链接或排查步骤，收到告警的人能立刻行动。（来源：G行监控平台优化专项总结）
• 限流降级成为“标配”。 这是保证系统不被冲垮的生命线，我们要求所有对外的核心服务，必须配置完善的限流和降级策略，当一个服务的响应时间明显变长时，网关层面就要自动触发限流，拒绝掉一部分非核心请求，保证核心交易还能通，服务自身也要有降级策略，比如查询积分服务挂了，能不能返回一个默认值，让主流程先走下去，而不是一直卡死等待，我们把这些策略的配置和演练，作为每个服务上线前的硬性验收标准。（来源：G行微服务治理框架应用指南）

第三，在“治”字上求长远，从根子上降低故障概率。

处理完一次故障不是结束,更重要的是防止同样的坑再踩一次。

• 故障复盘“对事不对人”。 我们强调复盘的目的不是为了追责，而是为了改进，每次线上问题之后，都会组织详细的复盘会，必须刨根问底找到根本原因，是代码逻辑缺陷？是配置错误？是基础设施不可靠？还是流程有漏洞？然后会生成明确的改进事项，落实到具体的人和完成时间，并且有跟踪闭环，曾经因为一个基础镜像的版本存在已知漏洞导致问题，之后我们就建立了全行的基础镜像安全扫描和强制升级流程。（来源：G行事件管理制度）
• 容量管理从“凭经验”到“看数据”。 以前扩容缩容多少有点拍脑袋，现在我们通过持续压测，建立每个业务模块的精准容量模型，比如我们知道在“双十一”期间，订单服务每秒钟处理1000笔交易需要多少CPU和内存资源，这样在做大促预案时，资源分配就非常清晰和自信，既不会资源浪费，也不会因为准备不足导致系统宕机。（来源：G行性能压测团队年度总结）

我们的体会是,云原生体系的稳定性和韧性，不是一个开关或者某个神奇工具就能解决的，它是一整套贯穿于研发、测试、部署、运维全生命周期的实践集合，是一种追求极致稳定性的工程师文化，核心思想就是从被动救火转向主动防御，通过自动化、标准化的手段，把不确定性尽可能变成可控的，让系统真正变得“皮实”起来，这条路没有终点，我们还在不断地踩坑和填坑中继续摸索。