软件系统稳定性建设思路总结

一、相关背景及概念

系统稳定性是指系统在受到内部或外部因素的扰动后，能够恢复到原有平衡状态的能力。这一概念主要涉及到系统对外部干扰的响应以及系统内部动态行为的控制能力。具体来说，系统稳定性包含以下几个方面的含义：

1. 抗干扰能力：系统在外界流量、网络波动等其他各种变化的影响下，能够保持其状态不发生显著变化。
2. 恢复能力：当系统受到某种干扰而偏离正常状态时，如果干扰消除后，系统能够恢复其正常状态，则系统是稳定的。相反，如果系统一旦偏离其正常状态，再也不能恢复到正常状态，且偏离越来越大，则系统是不稳定的。
3. 自动趋向性：如果一个系统能自动地趋向某一状态，且这一状态比原来的状态更稳定，那么可以说这个系统在这一方面具有良好的稳定性。

在控制理论中，系统稳定性是一个核心概念，它直接关系到控制系统的性能、安全性和有效性。一个不稳定的控制系统可能会产生不可预测的结果，导致系统输出无限制的增长、振荡过大或出现物理不可接受的行为，这在许多工程应用中都是灾难性的。

在软件系统中，如何评估一个系统的稳定性：

1.系统全年可用性：指系统在一年内能否正常运行，即无故障时间的百分比。系统可靠性越高，系统的稳定性也越高。服务器的可用性一般都是以几个9来表示，比如99.9%、99.99%、99.999%，9越多就代表可用性越强。

不同行业对系统高可用的要求是不一样的，金融电信级别的高可用，是需要99.99%及以上，一般互联网公司根据自己的业务场景及稳定性建设成熟度，目标定位99.95%-99.99%之间都可以接受的。

2.系统的恢复时间：指系统从出现故障到恢复的时间，一般业内有1-5-10的目标，指1分钟需要监测到系统故障，并且发出预警给相应开发及运维，5分钟内要响应，10分钟内要止损。

故障随时会发生，但是在业务高峰期概率特别大，对业务造成的损失和故障时间是正相关的，这个对开发同学的压力是很大的，基本上要求核心业务链路的值班同学，电脑不离身，做到随时响应。重大节点要求全员值班，这个都是可以理解的，程序员白头发、秃头等，除了研发压力大外，还有就是操心稳定性，这个也会和年度绩效目标挂钩。

每个公司对故障级别都有自己的定义，一般会根据故障造成的舆论影响，业务订单量影响，用户数影响，资损等进行综合定义。做稳定性建设的目标不是不零故障，因为有太多不可控因素，我们的核心目标是减少高级别故障，控制在可接受水平。

二、系统为什么会有稳定性问题

导致稳定性的问题有很多，大致可以分为以下几类：

1. 系统架构设计

• 设计缺陷：系统架构设计不合理，缺乏前瞻性和扩展性，导致在业务增长或需求变化时，系统难以应对，出现性能瓶颈或崩溃现象（特别是存储层的不合理设计及使用）。
• 模块耦合度高：系统中各模块之间的耦合度过高，一旦某个模块出现问题，很容易影响到其他模块，甚至导致整个系统崩溃。
• 历史债务：历史债务的积累，导致系统功能模块出现多个版本，每一波同学都会来重构，结果都是干一半的半吊子工程，在上面修改代码，非常容易出现问题。

2. 编程细节和代码质量

• 代码错误：程序员在编码过程中可能出现的各种错误，如逻辑错误、语法错误、资源泄露等，都可能导致软件系统出现稳定性问题。
• 代码风格和质量：代码的可读性、可维护性差，缺乏统一的编码规范和标准，增加了系统出错的概率。
• 同步和并发问题：在并发环境下，如果同步处理不当，如同步锁使用不当、线程死锁等，都可能导致系统性能下降或崩溃。
• 糟糕的系统性能：糟糕的系统性能，是稳定性常见问题，类似慢SQL，高耗时同步接口，事务范围过大等，都可能导致性能低下，从而拖垮系统，如果系统未做良好的故障隔离处理，还可能导致全系统的雪崩。

3. 外部因素

• 硬件故障：服务器、存储设备、网络设备等硬件设施的故障，都可能对软件系统的稳定性造成影响。
• 外部攻击：黑客攻击、病毒入侵等外部安全威胁，也可能导致软件系统出现稳定性问题。

4. 开发和测试过程

• 开发周期短：在快速迭代和交付的压力下，开发人员可能忽视了对代码质量的严格把控，导致软件系统中存在大量的潜在问题。
• 测试不充分：测试人员对软件系统的测试不够全面和深入，未能及时发现和修复系统中的缺陷和漏洞。

5. 用户需求和业务变化

• 需求变更频繁：用户需求的不断变化和增加，可能导致软件系统频繁变更和调整，增加了系统出错的风险。
• 业务流程复杂：业务流程的复杂性和多样性，要求软件系统具备高度的灵活性和可扩展性，这也增加了系统设计和实现的难度。

6. 维护和更新

• 维护不及时：对于已经发现的系统问题或漏洞，如果未能及时进行修复和更新，可能导致问题进一步扩大和恶化。
• 版本兼容性：在软件系统的更新和升级过程中，如果新版本与旧版本之间存在兼容性问题，也可能导致系统出现稳定性问题。

7. 其他人为错误

• 业务人员配置错误：错误配置导致的系统故障或者资损，包括配置值范围过大，导致的数据加载过多，导致系统崩溃，优惠过多导致的营销活动资损等。开发人员也需要反思对输入的约束及流程审核方面是否完善，让人容易犯错误的系统，始终不是好的设计。
• 运维或者开发误删除：比较场景的是 rm -rf xxx命令，或者delete数据的时候没有加where条件，而且恢复困难，导致各种问题。

三、稳定性治理

稳定性治理是一个综合性的工程，也是一个全民运动，任何对系统可以施加变化的人、环境、设备等因素，都可能导致问题。系统稳定性建设是确保系统在各种情况下都能稳定运行的关键工作。以下是一些做好系统稳定性建设工作的建议：

1、明确稳定性建设目标

• 设定具体目标：根据业务需求和技术现状，设定具体的稳定性建设目标，如降低故障率、缩短故障恢复时间等。
• 制定计划：围绕目标制定详细的实施计划，包括时间节点、责任分配和预期成果等。

2、构建稳定性团队

• 组建跨部门团队：稳定性建设需要开发、测试、运维、安全等多个部门的协同合作，因此应组建跨部门的稳定性团队。
• 明确职责：明确团队成员的职责和角色，确保每个人都知道自己在稳定性建设中的位置和任务。并且需要把稳定性相关的OKR可以贯彻到相关人身上。

3、制定规范与流程

• 开发流程规范：制定详细的开发流程规范，包括需求评审、技术方案设计、代码编写、测试等环节，确保每个环节都符合稳定性要求。
• 发布流程规范：控制发布权限和频率，制定严格的发布流程规范，包括发布前的检查、发布过程中的监控和发布后的验证等。
• 高可用设计：在系统设计时考虑高可用性，包括服务治理（限流、降级、熔断等）和容灾设计（如主备切换、多数据中心部署等）。

4、强化监控与告警

• 构建监控体系：围绕日志、指标、链路三大可观测性支柱，构建系统、应用、业务等多维度监控体系。
• 设置告警阈值：根据系统特点和业务需求设置合理的告警阈值，确保在发生异常时能够及时收到告警信息。
• 自动化处理：通过配置自动化脚本或工具，实现故障的自动识别和初步处理，减少人工干预。

5、提升应急响应能力

• 制定应急预案：针对可能发生的故障场景制定详细的应急预案，包括应急响应流程、应急处理措施和恢复方案等。
• 开展应急演练：定期组织应急演练活动，检验应急预案的有效性和团队的应急响应能力。
• 建立应急专家库：根据团队成员的专业技能和经验建立应急专家库，以便在发生复杂故障时能够迅速调动资源进行处理。

6、持续改进与优化

• 收集反馈：通过用户反馈、系统日志和监控数据等多种渠道收集系统稳定性和性能方面的反馈信息。
• 分析原因：对收集到的反馈信息进行深入分析，找出导致系统不稳定或性能下降的根本原因。
• 优化改进：根据分析结果制定优化改进方案并实施落地，不断提升系统的稳定性和性能水平。

7、引入先进技术和工具

• 关注行业动态：密切关注行业内的先进技术和工具动态，了解其在系统稳定性建设方面的应用情况。
• 引入新技术：在充分评估风险和收益的基础上引入新技术和工具，如混沌工程、智能巡检中心等，以提升系统稳定性和运维效率。

除了上述内容，高可用系统的设计，需要有一套比较科学的工程管理套路，要从产品、开发、运维、基建等全方位去考量和设计，高可用系统的设计思想包括但不限于：

• 做好研发规范，控制变更风险，系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准，类似设计评审、代码评审、发布计划评审，是规范的重点。
• 做好容量规划和评估，主要是让开发人员对系统要扛住的量级有一个基本认知，方便进行合理的架构设计和演进。容量规划一定要做到数据驱动，一般有线上全链路压测等进行验证，找出系统瓶颈，并且不断去优化，没有经过验证的评估，是不可靠的。
• 做好服务层面的高可用，主要是负载均衡、弹性扩缩容（系统设计为无状态）、异步解耦、故障容错、过载保护等。其中过载保护，需要基于系统的容量评估。负载均衡器可以抗多大的量， 有多少机器，都需要有了解。
• 做好存储层面的高可用，主要是冗余备份（热备、冷备，一主多从承压等）、失效转移（确认，转移，恢复）等。对存储层的TPS，QPS的承载量，要有清晰的认知，及时进行数据归档治理等，即使是性能还OK的索引，随着数据的增加，性能也可能会下降，时间是非常重要的一个维度。
• 做好运维层面的高可用，主要是发布测试、监控告警、容灾（同城双活、异地多活等）、弹性扩容能力、流量调拨、故障演练等。容灾方面，要根据公司的预算及团队技术水平而定，这方面的技术实施会增加研发及运维的复杂度，成本也可能大幅度上升，如果量级不大，不建议过早实施。
• 做好产品层面的高可用，主要是兜底策略，产品层面要基于故障时的B方案。
• 做好应急预案，主要是在出现问题后怎么快速恢复，不至于让我们的异常事态扩大，应急预案应该和业务和产品提前沟通，一旦条件符合，就触发预案执行，否则临时决策，效率反而很低。

这里的很多内容还可以做到非常深的，类似监控，如何做到从主机的CPU / IO/ 网络监控，到JVM层面的监控，中间件层面的监控，存储层的监控，应用层的调用量、耗时等，告警设置多少合适？这些都非常细节，但是对稳定性又极为重要，之前碰到CPU到95%才做告警，基本上一告警，就等于宣判死刑，日常根本没有时间去做治理，如果设置75%的告警，可能这个问题会被提早发现。

应用、存储、运维层面的高可用能力实施，涉及到的专业知识非常精深，需要专业技术人员，或者借助云厂商的相关产品能力。

四、如何长治久安

1、保持敬畏，责任落实：保持对线上系统的敬畏之心，每个和系统相关的人，主动/被动扛起肩上的责任（OKR落实），而且这方面的工作落实要说到做到。

2、苦练技术内功：加强专业人员的培训和人才梯队建设，构建良好的技术氛围。包括加强研发、设计规范的学习和落实，线上故障排查方法及工具沉淀等。人才的流动也是系统稳定性的核心要素，好不容易培养的人才，结果流失了，新同学来了，还需要继续踩坑，才可以获得治理经验，实在让人头疼不已，所以需要各团队加强知识库的沉淀，包括流程及故障案例等，让新同学可以快速成长为组织需要的人才。

五、结束语

稳定性建设工作是一项高度集成的系统工程，其核心在于技术领导者的远见卓识与精准施策。技术一号位作为引领者，需深刻把握稳定性的核心关切，不仅要在战略层面高屋建瓴，更要细致入微地部署实施策略。在此过程中，赋予架构师充分的决策权与自主权至关重要，这能够激发团队的创造力与应变能力，使技术架构在面对复杂多变的业务场景时保持坚韧不拔。

为确保稳定性工作的有效推进，组建并维持一支专业化的专职团队势在必行。这些团队成员应具备深厚的技术功底与丰富的实战经验，致力于通过精细化的运维管理、高效的故障排查与预防机制，以及创新的组件故障转移（FT）策略，全方位、多角度地加固系统防线。

祝愿在系统稳定性奋斗的同学，都有一头乌黑亮丽的秀发。

如果以上的稳定性建设对你有用，记得点赞收藏。