软件系统稳定的策略

记录一些最近发生的系统问题，以及制定的解决策略。

场景1

关键同事请假，开发工作和运维工作无法正常运行。

问题：项目和人的耦合度太高。

策略：从业务入手，加强团队培训，设立A/B角色。

场景2

慢SQL堆积，点击一个页面查询，直接把系统拖垮。

问题：缺少SQL审查环节，系统没有进行隔离。

策略：增加SQL审核机制，主业务系统和数控报表系统进行隔离，报表系统的查询，不影响正常的业务调度。

场景3

A工程师觉得a中间件好，引入到项目，B工程师也引入他觉得好的中间件。

问题：中间件混乱，实现同样功能的类似中间件重复引入，增加了维护的“黑匣子”。

策略：中间件标准化，让指定部门（如基础架构部门）负责中间件的引入，同时也增加适用于所有人的中间件引入流程规范。

场景4

系统不扛压，稍微有些数据，服务器资源占用直线上升。

问题：程序员素养需要提升，提高时间复杂度和空间复杂度的技术培训。

策略：在上线环节中增加压测节点，边技术培训边通过压测结果驱动系统往一个指定的性能指标看齐。

场景5

系统不稳定，发版本总有会有些小问题。

问题：代码质量考虑不周全，而工业对软件的稳定要求极高。

策略：增加测试环节，把稳定的、公用的板块进行抽离（如与设备打交道的板块），增加代码review机制。

场景6

客户反馈挂了，我们才知道系统挂了。

问题：业务是否正常提供服务，监控不及时。

策略：增加系统的物理主备和应用服务报警监测。

结语

以上是最近遇到常见场景及策略总结，最重要的还是按照策略去执行。