虚机镜像预构建节省一半初始化时间，但云厂商的启动脚本仍会强制二次修正

为了提升基础资源扩缩容的效率，微博团队构建了虚机镜像服务，思路是通过描述文件预先定义虚机的完整配置（支持继承关系和简单的初始化指令），实例扩容时直接用这个预先构建好的镜像启动，而不是每次扩容都从一个基础镜像开始现场装配置、装软件——这个预构建策略把扩容时的初始化时间节省了大约50%，效果非常直接。但这个方案在实践中暴露出一个不那么直观的坑：一些云服务商会在虚机启动后自动修改部分配置（比如router、dns、ntp、yum这类系统级配置），这意味着即使镜像里已经把这些配置预先设定好了，云厂商自己的启动脚本仍然会在运行时把它们覆盖或修改掉——单纯依靠”镜像里配好了就一劳永逸”这个假设并不成立，必须在实例真正运行起来之后，再额外补上一道针对这类会被云厂商自动修改的配置项的二次修正逻辑。这个案例给出了一条使用云服务时容易被忽视的经验：云平台本身也有自己的初始化流程和默认行为，这些行为未必会和用户自己预先准备的镜像配置兼容，尤其是网络、DNS这类云平台出于自身管理需要而倾向于统一接管的配置项——在设计任何依赖云平台虚机镜像的自动化方案时，不能假设”我在镜像里写好的配置就是最终生效的配置”，而要主动去验证云平台自己的启动流程会不会在事后覆盖这些设置，并为这类”会被覆盖的配置”专门设计运行后的补救步骤。