如何保证系统“稳定性”
系统稳定性
软件系统开发过程一般过程是：需求调研-系统开发-质量测试-发布部署-业务运营/系统运维。我们谈到稳定性，从软件系统的角度来讲需要做到需求理解正确，功能实现得当，功能测试完备，发布计划执行完整，运营和运维监控及时几个方面
需求调研
如何保证需求理解正确，以我的经验来看：
1.学会聆听
要理解真正的业务目标，不要被一些花哨的描述混淆视线，我理解的业务目标一般分为上下游协作需求，数据统计分析需求，效率提升需求等，我曾经听过一个笑话：现代互联网软件系统就是excel的导入导出+一个工作群，初听觉得很可笑，细想一下大部分的需求不就是为解决这两个问题吗？因为大量企业软件本质：
- 数据采集
- 数据流转
- 数据展示
- 协作沟通
2.及时反馈
我们听取了业务方的需求介绍，厘清了需求目标，需要通过PRD，Demo页面，表格等协作工具及时跟业务方确认需求理解是否正确，实现手段是否满足业务需求，产出结果是否符合业务目标
正确的理解需求是提升系统稳定性的基石
系统开发
软件开发在“古法编程”阶段分为前端工程师和服务端工程师（AI时代vibecoding已经要求人人都是全栈工程师了），我的经验告诉我这两类人的通病是：前端工程师“不看”PRD，服务端工程师“不看”UI设计稿，这里的不看不是说软件工程师们完全不看，而是指不爱看，或者说看不懂，前端工程师习惯了对着高保真进行还原，服务端工程师习惯对着PRD coding，大家往往忽略了业务目标，认为业务是产品的事情，跟工程师没啥关系，只管实现需求，而不在意需求对应的业务目标。
很多团队会要求工程师们在开发之前写技术文档，来进行软件系统架构设计、交互设计，最终设计出的系统满足了“高并发，高可用，低耦合”等技术指标，但面对业务的快速变化时，却显得有些力不从心。
我认为保证系统稳定性的前提是工程师能够真正理解业务目标，具体的手段除了常规的PRD评审来了解需求，也需要接受业务方的业务培训，真正理解开发出来的系统在业务上的价值，面对的用户群体，市场规模，行业前景。
我认为这也是一个软件工程师的竞争力。
在系统开发过程中提供系统稳定性的保证，我认为可以从：
架构设计和技术选型
在理解业务目标和需求分解之后，进行适当的技术架构和技术选型，是保证系统开发的第一步，理解了业务的前景和市场规模，可以帮助我们在系统扩展性做好预留空间，业务起步阶段到业务高速扩张阶段，是否做好了幂等、分布式、事务控制等设计，能够通过简单的水平扩展或增加中间件来满足业务增长的性能需求，技术选型是否支持团队扩充后带来的协作问题。
群体决策总是好过单打独斗。
开发过程
不论是TDD还是BDD，还是“只写代码不写测试”，开发的目标总是快速、稳定的交付，最重要的还是需要认真阅读PRD文档真正理解业务需求，不要遗漏需求项。
开发过程中“先想清楚再动手”总是不会错的，在AI时代，提示词中写明需求目标，交互的出入参，总是好过让AI自由发挥，所以技术方案不仅仅是一个任务，而应该是一个动手实现前的行动纲领，我认为好的技术方案必须：明确实现的需求，定义交互的上下游以及出入参，明确异常情况处理。
开发过程中及时和leader、产品、测试同学进行沟通：需求的疑惑、实现手段的处理、延期风险等等问题，不要等到“问题出现我再告诉大家”。
开发交付
- 必须完成自测
- 必须完成冒烟用例测试
- 必须有代码审查工具进行代码审查
质量测试
我们往往高估了质量测试的能力同时也限制的质量测试权限。
很多公司制定了明确的规章制度要求测试不通过不准上线，往往又在排期面前妥协，带着bug上线“业务先跑起来”已经绑架了一切。
对于系统稳定性，在测试方面我的理解是：
提前介入
在需求评审阶段和技术方案阶段，测试同学就需要介入：理解需求、了解技术实现手段、明确测试目标、准备测试用例和测试工具。
提前沟通清楚业务目标，了解软件工程师们准备怎么干，提前和产品沟通测试覆盖的业务场景是否有遗漏，向工程师提供测试用例会极大的提高交付质量
发布部署
编写发布计划提前审查，制定发布流程规范并严格执行。
发布过程中容易出现的问题：
- 遗漏关键配置，导致请求错误，风控异常，业务错误造成资损。
- 遗漏数据库变更，上线就报错，业务崩溃。
- 开发和线上版本兼容问题：底层依赖问题，中间件版本问题，基础设施问题等等，导致上线一切正常，特定业务执行报错，用户兼容性问题导致流量损失。
- 监控没有覆盖，新的服务、中间件基础设施没有上监控，异常不被感知。
业务运营/系统运维
业务数据监控
业务上线后，需要关注业务数据，保持数据的敏感性，判断业务数据和预期结果的偏差值是否合理。要有明确的统计口径和统计手段，不论是查数据库，还是通过三方的统计工具，自研的数据报表系统等，总之要能看到准确的数据，并对数据的合理性有正确的判断。
系统运行稳定性
系统运维需要有完整的监控手段和预警机制，以及异常处理和回滚措施，保证系统能用比新业务/功能是否上线更重要。