现在只要搞开发的人，都在谈微服务，只要搞运维的人，都在谈DevOps，但对于大部小伙伴来说几乎没什么经验，对于大部分企业来说也只处于尝试阶段，虽说如此，可感觉大家在制定目标时，都不太喜欢给自己留余地，把规划写得很大，功能很全，甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起，我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

挑战一：敏捷文化

1、切换敏捷之前的过渡区

对于许多草根程序员来说，提到敏捷所能带来的收益，条件反射地会说 “能快呀”、“不用写文档啦” 。

不能说这种说法有问题，只是不够专业，在实际的工作中，我们是否经常会听到这样的对话？

行，就按照你说的做，我写个需求规格说明书给你

好的，写完别忘记给领导审批，然后我按照需求做个设计给你看下……

开发结束啦，已经提测了，你问问测试吧……

问问测试吧，什么时候可以发布仿真环境……

又改需求了？别忘记先改需求规格说明书，要不然代码和文档对不上了，改完我再开发……

对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说，直接切换至敏捷模式，无论对业务、技术及架构都是非常具有挑战的，这种挑战多半来自于业务场景与公司文化的限制，甚至是组织结构的局限性，不但不能快起来，甚至会带来一些意想不到的灾难。

（图：职能化筒仓式组织结构）

先用迭代让业务快起来，敏不敏捷不着急

对于金融类企业来说，多半是业务驱动模式，业务关心的是 “快上线” 、 “别出事”，至于技术是用什么实现，敏捷也好，糊上墙也罢，他们其实并不关心。

为了快速让业务获得收益，在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值：要计划制造一辆汽车，它最核心的功能是可以在路上跑，所以我们可以先制造一个踏板车，依次迭代为滑板车、自行车、摩托车、汽车。

（图：正确理解迭代的方式）

瀑布 - 迭代 - 敏捷，三者的差异是啥呢？

（图：瀑布与迭代的区别）

（图：瀑布的特点）

（图：迭代的特点）

（图：迭代与敏捷之间的区别）

2、大家都缺乏敏捷文化

从某种角度来讲，目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的，开发和运维部门经常会坐在一起探讨，就运维流程如何改变、自动化能力如何建设等，然而自始至终无法突破的终极问题就是：无论我们如何改变，如果万一生产环境出了问题，谁承担责任？因为DevOps能力的建设需要一个过程，开发团队不敢承诺完全承担责任；而运维因为弱化审批和控制力，也认为不该为其承担责任。最终不了了之。

其实，使用迭代过度也只是权宜之计，真正的问题出在文化上，旧有的组织治理模式产生了各扫门前雪的官僚文化，没有责任共担，以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维，可能源自组织的绩效考评和激励制度。

（图文：跨职能产品化的组织结构）

　现代关于“系统论”的研究已经在很多著作中强调，一个组织就是一个由人构成的复杂系统，组织中每一个人所能获得的信息是有限的（包括最高管理者也是），每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

如果系统发生失败，例如生产环境出现问题，这必然是由于系统各个部分相互作用（从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用）产生的结果，对其中任何局部进行惩罚无非是寻找替罪羊，有害而无益。这时候组织真正应该做的，是相信每一个人都已经做出了最大努力，将相关干系人拉到一起对问题的根因进行分析，找到能够有效避免类似问题再次出现的解决方案，并确保该方案得到实施，对其效果进行验证。

这是ThoughtWorks在一篇DevOps文章中所提到的，我觉得一针见血，不过对于大部分企业，尤其是金融类企业，实践落地所付出的周期与成本可能会更大一些。

再举个例子，在「讲个‘理论型’高可用架构的故事给你听」我曾经说过，我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”，英文名叫“ChaosDevil”，这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭，以此来测试生产环境的快速恢复能力，促使各团队提升系统的稳定性；

（图：网络游戏 - 混世魔王形象照）

有趣的是被指定优先使用的团队口头全力支持，但实践起来却迟迟延误，当然大家都比较忙，这也是可以理解的。不过我们可以设想下，如果没有这个“魔王”，大家可以给领导讲自己的系统很稳定（只要没出问题）；

然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定，会降低自己在上级心目中的“有能力”印象，随之而来的可能就是问责、惩罚；

这样的文化下，大家真正关心的是如何给领导“表现”，而不是在真正的系统稳定性上追求卓越。

所谓敏捷文化是个啥？抄袭一张图吧，简单点：

（图：敏捷，乃至DevOps所需要的文化）

挑战二：配置文件的困惑

1、没有DevOps之前，配置文件是怎么玩的呢？

在「群雄割据」的时代里，通常一个Jar或一个War就可以打天下，以Spring+properties为例，对配置文件的适用场景基本可分为两种类型：

配置文件位于classpath下

使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件，通过源码可以知道，默认加载的是classpath下的文件，配置如下：

如果有多个配置文件加载，则：

配置文件位于外部目录

但是对于外部目录的配置文件，使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的，不过要修改他的路径配置方式，如下：

这样就可以成功加载外部目录的配置文件了，${user.dir}是系统变量，指用户当前目录所在。

当我们从「群雄割据」来到「天下一统」的时期后，虽然DevOps提升了交付效率，越来越满足快速试错的原则，可随之而来的「技术污染」却与日体现：

• …………
  
  

• 配置文件的版本如何与程序版本对应？
  
  

• 配置文件的管理如何更加简便？
  
  

• 配置文件的修改该有谁来操作？
  
  

• 配置文件的更新是否可以不影响正常服务？
  
  

• …………
  
  

无论哪一项污染，只会与DevOps扯上关系，都是让人头痛不已。

撸起袖子，不要怂，咱们搞个配置中心吧。

2、有了DevOps之后，配置文件又是怎么玩的呢？

其实想通过DevOps获得业务收益，无论从哪个环节启动，都将是一场持久战。

随着系统产品化的改造，通过DevOps流水线的快速交付通道，任何一个交付版本都可以通过CI与CD环节后，利用自动化部署工具轻松地完成升级或发布；

这段看似美妙的诱惑，首先挡住去路的，就是配置文件的使用与加载方式。

如果不将配置信息外移至配置中心，在DevOps中会出现哪些问题呢？

1.维护成本：系统拆分了更细了，增添CI与CD环境后，每个应用在每个节点下，都需要在本地维护一套完整的配置文件；

2.操作风险：配置修改随意，无操作痕迹，易出错；

3.版本需求：一切皆产品，一切皆版本，配置文件如何解决版本化控制问题？

图：配置中心在DevOps快速交付通道中

你不是常说你们的场景都是持续污染的吗？谈谈如何在污染环境下接入吧。

的确，在整个接入过程中可以说是一波三折，原因很简单，之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案，现在你说统一就统一？

无法满足我要求的，我不接。

这话表面看起来有些生硬，不过想想挺有道理的，所以在配置中心的方案中，我们提出了“三种适配器，两种推进器”的理念。

三种适配器

图：适配器Trade，满足原有使用Properites的诸侯们

图3：适配器Native，满足已使用过自研独立配置服务的诸侯们

图4：适配器Ccms，满足使用Key/Value的诸侯们

两种推进器

图：希望采用 “文件被动加载” 的诸侯们

图：希望采用 “Key/Value实时推送” 的诸侯们

从某种角度来说，就算没有配置中心的存在，我相信DevOps的推进也会顺理成章，只不过相对不会如此平滑，或多或少给未来造成风险。

有了配置中心，诸侯们的确享受到了福利：

1、配置统一在服务端维护，同一环境下所有应用节点共享同一份配置；

2、配置控制台提供鉴权、操作日志等服务；


3、配置控制台实现了版本控制，修改的配置需要发布后生效，减少误操作；


4、配置发布后，实时通知应用端，无须重启即可使用；


5、配置版本支持一键回滚；


6、配置控制台实现了整体复制、导出、批量修改等功能；

3、小结

本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事，所以对配置系统自身的原理与技术实现并未做详细的描述，如对这块有兴趣，欢迎大家在留言区中提出，我将通过独立的整篇文章加以叙述。

王晔倞，现任职好买财富平台架构部技术总监，负责好买中间件及平台化的研发及运营，团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设，辗转过不同的业务团队，对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

  现在只要搞开发的人，都在谈微服务，只要搞运维的人，都在谈DevOps，但对于大部小伙伴来说几乎没什么经验，对于大部分企业来说也只处于尝试阶段，虽说如此，可感觉大家在制定目标时，都不太喜欢给自己留余地，把规划写得很大，功能很全，甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起，我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

挑战一：敏捷文化

1、切换敏捷之前的过渡区

对于许多草根程序员来说，提到敏捷所能带来的收益，条件反射地会说 “能快呀”、“不用写文档啦” 。

不能说这种说法有问题，只是不够专业，在实际的工作中，我们是否经常会听到这样的对话？

行，就按照你说的做，我写个需求规格说明书给你

好的，写完别忘记给领导审批，然后我按照需求做个设计给你看下……

开发结束啦，已经提测了，你问问测试吧……

问问测试吧，什么时候可以发布仿真环境……

又改需求了？别忘记先改需求规格说明书，要不然代码和文档对不上了，改完我再开发……

对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说，直接切换至敏捷模式，无论对业务、技术及架构都是非常具有挑战的，这种挑战多半来自于业务场景与公司文化的限制，甚至是组织结构的局限性，不但不能快起来，甚至会带来一些意想不到的灾难。

（图：职能化筒仓式组织结构）

先用迭代让业务快起来，敏不敏捷不着急

对于金融类企业来说，多半是业务驱动模式，业务关心的是 “快上线” 、 “别出事”，至于技术是用什么实现，敏捷也好，糊上墙也罢，他们其实并不关心。

为了快速让业务获得收益，在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值：要计划制造一辆汽车，它最核心的功能是可以在路上跑，所以我们可以先制造一个踏板车，依次迭代为滑板车、自行车、摩托车、汽车。

（图：正确理解迭代的方式）

瀑布 - 迭代 - 敏捷，三者的差异是啥呢？

（图：瀑布与迭代的区别）

（图：瀑布的特点）

（图：迭代的特点）

（图：迭代与敏捷之间的区别）

2、大家都缺乏敏捷文化

从某种角度来讲，目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的，开发和运维部门经常会坐在一起探讨，就运维流程如何改变、自动化能力如何建设等，然而自始至终无法突破的终极问题就是：无论我们如何改变，如果万一生产环境出了问题，谁承担责任？因为DevOps能力的建设需要一个过程，开发团队不敢承诺完全承担责任；而运维因为弱化审批和控制力，也认为不该为其承担责任。最终不了了之。

其实，使用迭代过度也只是权宜之计，真正的问题出在文化上，旧有的组织治理模式产生了各扫门前雪的官僚文化，没有责任共担，以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维，可能源自组织的绩效考评和激励制度。

（图文：跨职能产品化的组织结构）

　现代关于“系统论”的研究已经在很多著作中强调，一个组织就是一个由人构成的复杂系统，组织中每一个人所能获得的信息是有限的（包括最高管理者也是），每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

如果系统发生失败，例如生产环境出现问题，这必然是由于系统各个部分相互作用（从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用）产生的结果，对其中任何局部进行惩罚无非是寻找替罪羊，有害而无益。这时候组织真正应该做的，是相信每一个人都已经做出了最大努力，将相关干系人拉到一起对问题的根因进行分析，找到能够有效避免类似问题再次出现的解决方案，并确保该方案得到实施，对其效果进行验证。

这是ThoughtWorks在一篇DevOps文章中所提到的，我觉得一针见血，不过对于大部分企业，尤其是金融类企业，实践落地所付出的周期与成本可能会更大一些。

再举个例子，在「讲个‘理论型’高可用架构的故事给你听」我曾经说过，我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”，英文名叫“ChaosDevil”，这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭，以此来测试生产环境的快速恢复能力，促使各团队提升系统的稳定性；

（图：网络游戏 - 混世魔王形象照）

有趣的是被指定优先使用的团队口头全力支持，但实践起来却迟迟延误，当然大家都比较忙，这也是可以理解的。不过我们可以设想下，如果没有这个“魔王”，大家可以给领导讲自己的系统很稳定（只要没出问题）；

然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定，会降低自己在上级心目中的“有能力”印象，随之而来的可能就是问责、惩罚；

这样的文化下，大家真正关心的是如何给领导“表现”，而不是在真正的系统稳定性上追求卓越。

所谓敏捷文化是个啥？抄袭一张图吧，简单点：

（图：敏捷，乃至DevOps所需要的文化）

挑战二：配置文件的困惑

1、没有DevOps之前，配置文件是怎么玩的呢？

在「群雄割据」的时代里，通常一个Jar或一个War就可以打天下，以Spring+properties为例，对配置文件的适用场景基本可分为两种类型：

配置文件位于classpath下

使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件，通过源码可以知道，默认加载的是classpath下的文件，配置如下：

如果有多个配置文件加载，则：

配置文件位于外部目录

但是对于外部目录的配置文件，使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的，不过要修改他的路径配置方式，如下：

这样就可以成功加载外部目录的配置文件了，${user.dir}是系统变量，指用户当前目录所在。

当我们从「群雄割据」来到「天下一统」的时期后，虽然DevOps提升了交付效率，越来越满足快速试错的原则，可随之而来的「技术污染」却与日体现：

• …………
  
  

• 配置文件的版本如何与程序版本对应？
  
  

• 配置文件的管理如何更加简便？
  
  

• 配置文件的修改该有谁来操作？
  
  

• 配置文件的更新是否可以不影响正常服务？
  
  

• …………
  
  

无论哪一项污染，只会与DevOps扯上关系，都是让人头痛不已。

撸起袖子，不要怂，咱们搞个配置中心吧。

2、有了DevOps之后，配置文件又是怎么玩的呢？

其实想通过DevOps获得业务收益，无论从哪个环节启动，都将是一场持久战。

随着系统产品化的改造，通过DevOps流水线的快速交付通道，任何一个交付版本都可以通过CI与CD环节后，利用自动化部署工具轻松地完成升级或发布；

这段看似美妙的诱惑，首先挡住去路的，就是配置文件的使用与加载方式。

如果不将配置信息外移至配置中心，在DevOps中会出现哪些问题呢？

1.维护成本：系统拆分了更细了，增添CI与CD环境后，每个应用在每个节点下，都需要在本地维护一套完整的配置文件；

2.操作风险：配置修改随意，无操作痕迹，易出错；

3.版本需求：一切皆产品，一切皆版本，配置文件如何解决版本化控制问题？

图：配置中心在DevOps快速交付通道中

你不是常说你们的场景都是持续污染的吗？谈谈如何在污染环境下接入吧。

的确，在整个接入过程中可以说是一波三折，原因很简单，之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案，现在你说统一就统一？

无法满足我要求的，我不接。

这话表面看起来有些生硬，不过想想挺有道理的，所以在配置中心的方案中，我们提出了“三种适配器，两种推进器”的理念。

三种适配器

图：适配器Trade，满足原有使用Properites的诸侯们

图3：适配器Native，满足已使用过自研独立配置服务的诸侯们

图4：适配器Ccms，满足使用Key/Value的诸侯们

两种推进器

图：希望采用 “文件被动加载” 的诸侯们

图：希望采用 “Key/Value实时推送” 的诸侯们

从某种角度来说，就算没有配置中心的存在，我相信DevOps的推进也会顺理成章，只不过相对不会如此平滑，或多或少给未来造成风险。

有了配置中心，诸侯们的确享受到了福利：

1、配置统一在服务端维护，同一环境下所有应用节点共享同一份配置；

2、配置控制台提供鉴权、操作日志等服务；


3、配置控制台实现了版本控制，修改的配置需要发布后生效，减少误操作；


4、配置发布后，实时通知应用端，无须重启即可使用；


5、配置版本支持一键回滚；


6、配置控制台实现了整体复制、导出、批量修改等功能；

3、小结

本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事，所以对配置系统自身的原理与技术实现并未做详细的描述，如对这块有兴趣，欢迎大家在留言区中提出，我将通过独立的整篇文章加以叙述。

王晔倞，现任职好买财富平台架构部技术总监，负责好买中间件及平台化的研发及运营，团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设，辗转过不同的业务团队，对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者