效率优先，还是稳定优先 － 推动产品迭代的一些思考

前些天，我们某款产销系统在某品牌使用过程中出现了P0级故障，大致情形：当消费者订单触发一些自动化场景时，将指令下达到执行器，而当执行器明确告知执行成功的情况下，调度器更新了执行成功的状态。然而实际情况是，执行器并没有真的完成。最终定位了一个底层诱因，云数据库服务器的sync_binlog参数默认值问题。业务代码提交了数据库请求，数据库并没有写入硬盘就告知业务系统数据库已经保存了。简单讲我提交了请求，你提交了请求，你回滚了，我也被动回滚了。可是我跟人说我已经搞定了，实际没搞定。????大家有没有找到熟悉的味道。针对此例，尽管底层数据库服务器没有保证事务性，但是产品自身没有做好预警和监控。

这也重新激发了过去一年我对效率和稳定的一些思考。熟悉我的人，对我有个评价，离开电脑桌，就像行走的机器人，做事情很实际特别接地气，但眼睛里心里有一些很高远很理想很不切实际的东西。所以，无论出于提高团队的能力，还是出于对客户的负责，都应该除了在技术层面做复盘外，还需要在工程文化理论上做一些深层次的复盘，以避免此类问题的再次发生，通过持续交付，重新挽回信任。言归正传。

我们知道，效率和稳定是衡量产品对业务支持能力的两个关键指标。从工程角度来看，效率提升一定程度会影响稳定性，而稳定性要求过高又会影响业务效率，同时兼顾效率和稳定，也就变成了一个巨大的挑战。从业务角度来看，成熟业务会更偏向于稳定性，而新业务更偏向于效率。

这里效率，是指产品迭代效率，影响产品迭代效率的因素可能有：业务开发复杂度、业务迭代流程、业务维护成本、稳定性要求。如何提高产品的可靠性、扩展性和可维护性，都是效率应该思考的点。具体关于提高效率有关的技术架构和软件工程的理论，这里不作赘述。

以下，重点探讨下稳定性。影响稳定性最重要的因素就是产品的鲁棒性。通俗点讲，稳定性就是少出线上问题，尽量别影响业务正常运营。用技术语言翻译下，就是在任何情况下都不会出现服务异常中断或资源泄露，同时在非正常输入和非正常压力情况下服务在可接受延迟范围内正确响应率不低于一定比例。影响系统不稳定的因素主要有：需求变更、用户行为变化、数据变化、硬件故障等。对应地，需要我们做好变更管控、扩容、性能优化和限流等。

如果要给稳定性保障一个比较通用的定义，那这个公式大概是成立的：稳定性 = 良好的架构设计实现 + 完善的软件研发交付流程 + 持续的线上应急机制和方法 + 专业的技术团队 + 优秀的项目管理和团队协作。

过去三年，我们通过MVP方案（小步快跑）、CICD流水线（快速交付）、容器化云原生（降低硬件和维护成本）等各种方法和工具，利用微服务技术构建了业务中台和数据中台，通过业务数据化、数据业务化，流程自动化等指导思想构建了大量的电商自动化场景。今后，我们需要在保障服务稳定性的底线基础上，进一步根据不同类型的客户，根据客户所在的不同阶段，定义好可量化的业务稳定性指标，做好软件研发交付流程和客户成功工作。

现正式推出K5计划：品牌公司10万元/年，代运营公司20万/年。享受驻场调研和企业数字化转型服务。有意者留言。