稳定性不是创可贴

Posted 2023-03-01 柳清风09

在一次内部的分享中，有位同事分享了稳定性的话题，有句话是这样说的”稳定性不是创可贴“，深有感触，从多年的工作经历分享我对稳定性的认识。

一、定义

稳定性简单来说就是不出故障，通常理解的稳定性就是几个9，就是一年的服务不可用时间占全年的占比多少。譬如

• 三个9（99.9%） 也就是（1-0.999）36524 =8.76 个小时
• 四个9（99.99%）52.6 分钟
• 五个9（99.999%）5.26 分钟
  9越多，稳定性越搞，无限趋近1.

二、相关因素

这个我想分享的重点，通常的观点是认为稳定性就是线上运维或者SRE之类，但我想说的是稳定性就是一个系统工程，贯穿整个软件生命周期。

软件架构

在软件架构的时候就需要考虑未来的稳定性，譬如系统依赖的第三方服务或者中间件选型等，是否采用异步处理，是否采用缓存设计，系统的容量评估，是否考虑多机房容灾部署、是否有限流和降级处理等，这些问题如果在系统架构的时候没有考虑进去，那么这个系统就是一个”天生缺陷的娃“。

开发过程

这部分是经常被一些小公司忽略的，认为功能测试跑通了，页面点点都ok，服务就可以发布上线了。这个一个很大的误区，稳定性的保障需要像一个紧箍咒一样带在研发同事的头上，不能把代码交给运维就算了事了。目前比较流行的Devops理念就是希望研发能够参与到线上服务运维中去，从而在研发过程中，注意稳定性的建设。这就需要开发中加强代码的评审、单元测试和集成测试等。并且打印一些运维日志，帮助快速在线上排查问题。针对外部系统调用增加失败情况下的退避重试等。

发布过程

这里通常是提供一些蓝绿发布或者金丝雀发布等，让服务能够稳定的切换，以及失败情况下的及时回滚（止血肯定是第一位的）。发布的过程需要做到：可灰度、可监控、可回滚。
当然，这里也需要注意一些小细节，譬如劈开高峰期发布，发布批次之间的间隔时间（因为有些问题需要等待一段时间才能发现）等。

运维

这部分内容大家可能都有比较直观的认识，运维需要保障服务稳定性。运维需要提供各种维度的监控，机器性能（CPU、内存、网卡、磁盘、线程数、连接数）、应用日志监控和性能监控（慢SQL、QPS、TPS、请求失败数、RT）、调用链以及相关告警。
运维还需要处理一些突发故障排查，只有快速的排查出故障，才能尽快修复故障，降低故障的影响时间。在面对一些大促或者活动适合，运维方面也要做好各种压测和针对可能故障的预案。

三、云原生

在云原生其中的一个目标就是打造一个稳定性的业务系统，可以看到原生的很多组件都与稳定性息息相关，譬如k8s的健康检查和容器副本数保障、promethues性能监控、Jaeger调用链、filebeat日志等。除了上面组件以为，云原生中提倡的Devops概念和最佳实践也是为了保障的服务的稳定性。