配置化有哪些问题？

相信大家或多或少都听说过一些配置化解决方案，不管是在一些晋升PPT或是产品规划会上。我甚至还听到过产品因为一个功能，准备让研发提供一套低代码平台给他们操作，这种产品听起来就很不务实，缺少基本的收益思维。

配置化确实是一种很好的提升研发效率、提高业务交付效率的手段。其思想就是将原有通过代码组织编排的逻辑以流程配置、字典配置、特征配置等手段外显出来，提供给研发同学、产品、运营一个可视化的操作界面进行勾选，实现业务能力的可运营。

但大家有没有想过，一套配置化能力体系会存在哪些问题？需要具备哪些完备的能力？

之前和晋叔聊，他说他们做了一些配置化手段提供给运营同学做广告体系运营，我问他：“你们敢百分百把运营平台提供给运营同学操作吗？”

最近再和晋叔聊，我说我们做了一些配置化手段，提供给运营操作。晋叔同样问了我一句话：“你们敢百分百把运营平台提供给运营同学操作吗？”

我们回答的都是不敢。

我统计了一下过去发生的一些比较难搞的线上故障，往往都是配置化系统导致的。也就是说因为一些不成熟的配置化方案，导致了我们核心链路出现过难搞的稳定性故障。

而稳定性又是一个研发团队的基石，是研发团队技术能力的体现，是研发的基线，做不好稳定性就很难展现研发团队的价值。

我们可以把一套资源与能力在线上被使用的过程统一叫做“线上变更”，我们可以假想下研发操作线上变更与运营操作线上变更的不同心态。

研发会将其当做一套研发流程交付，做必要的cr、double check、灰度放量、监控报警观察等。

运营操作基本不会有这些动作，7*24小时想发就发，而且经常会有点多次、不关注状态机状态的情况（当然这些还是因为配置化平台非功能性功能不完备造成的）。

研发操作的线上变更实现大概有三类：代码上线实现、技术配置上线实现、数据库DDL操作实现。

这三类操作都是通过统一的技术基础设施实现的，不管是代码交付上线、配置变更上线、数据库操作都具备回滚的能力，而且这种回滚是完备的、是稳定可靠的。

而我们为运营提供的配置化系统往往是不完备的，比如缺少必要的状态机判断，缺少必要的回滚机制，多人操作同一套资源时缺少必要的隔离与并发控制，缺少完备的权限审批流程，缺少完备的灰度放量观察手段，缺少快速止损可用性降级手段等...我们还可以列出很多。

每次对于一个核心链路核心功能的配置化系统上线，我都可以提出一堆非功能性的要求，也可以看到很多非功能性的隐患点，而对这些非功能性能力的进一步完善，基本是没有时间做的，因为这部分投入产出比太低了，产品往往觉得那些看得见的功能有了就行。

直到有一天一个底层的bug被触发，导致了底层数据的不一致，运营进行了多次操作与点击，而底层缺少必要的隔离与并发控制，数据与流程进一步错乱。

当发现问题，引起线上故障时，希望操作回滚进行止损，但由于数据不一致，底层的一大坨json已经很难回到他应该有的状态，结果故障越拖越大，损失越来越不可控，只能上线代码将这部分功能下掉，用默认值兜底。

所以，在一个核心链路引入一个配置化解决方案风险多大，其需要极其完备的设计。有时你会发现一个信得过的配置化系统，其实是应该具备一些数据库基础能力的，而开发出这一套完备的基础能力，你需要在产品排期上增加几倍的时间才可以。

配置化很好，可以提效，但你敢将核心链路上配置化系统交给产品运营同学随意操作吗？