凌晨了，暂时恢复技术博主。
看到腾讯关于最近这次故障的公告，简单来说是配置数据错误导致的服务崩溃。
系统演化的规律之一就是灵活性和可靠性之间会存在长期博弈，配置作为一个提升灵活性的重要功能，如果从稳定性的角度看，存在几个风险：
一，没有编译期检查
除了编译器相关的配置以外，几乎所有的配置都是启动时或者运行期加载，这就跳过了绝大部分编译或者链接问题（类型不兼容、引用不存在等），很多问题只能在启动时或者运行期才能显现出来。
二，缺少测试
绝大部分开发人员不会为配置写单元测试，虽然有集成测试可以验证配置的正确性（一般在金丝雀发布前的阶段），但是测试用例里也只是功能回归，而不是专门测配置相关的边界和异常情况。
三，缺少版本和流程管理
大部分公司对于代码发布都会建立严格的流程，但是对于配置发布，尤其是运行期动态加载的配置发布，却很少有同等级别的管理。
不少公司直接没有把配置纳入版本管理体系里，配置的变更后不能直接回滚，或者没有动态配置的金丝雀、蓝绿发布流程。
四，开发人员缺少配置管理的意识
绝大部分开发会把配置变更和代码变更分开，认为代码变更是“上线”，配置变更是“改配置”，因此很多配置相关的幺蛾子都游离于稳定性体系之外，出了问题之后可能绝大部分人都还不知道到底发生了什么。
就像我之前说过的观点，解决配置问题的第一步就是先明确一个问题：
配置是代码的一部分。
配置是代码的一部分。
配置是代码的一部分。
看到腾讯关于最近这次故障的公告，简单来说是配置数据错误导致的服务崩溃。
系统演化的规律之一就是灵活性和可靠性之间会存在长期博弈，配置作为一个提升灵活性的重要功能，如果从稳定性的角度看，存在几个风险：
一，没有编译期检查
除了编译器相关的配置以外，几乎所有的配置都是启动时或者运行期加载，这就跳过了绝大部分编译或者链接问题（类型不兼容、引用不存在等），很多问题只能在启动时或者运行期才能显现出来。
二，缺少测试
绝大部分开发人员不会为配置写单元测试，虽然有集成测试可以验证配置的正确性（一般在金丝雀发布前的阶段），但是测试用例里也只是功能回归，而不是专门测配置相关的边界和异常情况。
三，缺少版本和流程管理
大部分公司对于代码发布都会建立严格的流程，但是对于配置发布，尤其是运行期动态加载的配置发布，却很少有同等级别的管理。
不少公司直接没有把配置纳入版本管理体系里，配置的变更后不能直接回滚，或者没有动态配置的金丝雀、蓝绿发布流程。
四，开发人员缺少配置管理的意识
绝大部分开发会把配置变更和代码变更分开，认为代码变更是“上线”，配置变更是“改配置”，因此很多配置相关的幺蛾子都游离于稳定性体系之外，出了问题之后可能绝大部分人都还不知道到底发生了什么。
就像我之前说过的观点，解决配置问题的第一步就是先明确一个问题：
配置是代码的一部分。
配置是代码的一部分。
配置是代码的一部分。
