CTO指南 -- 为什么说超过2台ECS就要考虑如何避免“配置飘移”问题

摘要 本文探讨了业务系统多台ECS多实例运行时，基于配置文件管理配置会遇到的著名的“配置漂移”问题，以及如何基于类似阿里云ACM的配置中心集中化管理方案来帮助解决这个问题

各位CTO/CIO，你为系统准备时光机了么？

“配置飘移”这个问题其实不是什么新鲜玩意，国外早在业界提了很多年了，业界每年因配置飘移而产生的故障和系统失效问题带来的经济损失那是相当的可观，但是国内业界关注和重视甚至“意识”到这个问题存在的人都相当的少。配置飘移，简单来说就是各位CTO逼自己回答下面2个问题

“设置” - 恢复出厂设置

上图操作大家应该不陌生，生产系统配置就好比我们手机上的“设置”，要知道我们的手机“专人”维护配置，VIP待遇，尚且随着随着时间的推移，安装的APP越来越多，某天可能不得不需要恢复出厂设置，更何况我们的生产系统？如果上一次做“配置”的那个哥们离职了，他曾经对系统做的那些“神”操作还如何恢复往日荣光？

创业艰难百战多，十万旌旗斩阎罗

所谓千里之行，始于足下，一个伟大的激动人心的创业项目可能是下面这个最典型的基本高可用(无单点)的技术架构开始的

我们后文就以这个典型的场景为例来阐释一下什么是配置飘移问题，其给生产可能带来的伤害。

配置飘移(Configuration Drift)

配置漂移指的是随时间做出的引起计算机或服务偏离所希望的配置的改变。

差不多一半的不定期系统停机时间可归因于配置问题。配置指的是标识和设置硬件和软件的属性的值的过程，使得系统按特定的行为匹配运行环境。当开发和运维一天一天的对发生的需求和问题做出响应时，服务器和系统可逐渐地变得以偏离于策略或标准的方式配置，该过程被称为配置漂移。

如果计算机和应用部署不是类似地被配置，则管理多个机器和应用运行实例可快速地变得复杂。即使对于最初被完全相同地配置的计算机和应用副本，配置改变也可能随时间发生。配置漂移越大，就变得越难以调试问题，使得对系统的有效管理和维护更困难。

上面的概念好枯燥，还可以更枯燥么？答案是可以, 参见 有效管理配置漂移!

理论是枯燥无味的，我们以上文中的典型架构场景具体看一下一些可能会导致配置飘移的案例帮助你更好的理解问题所在。

Web 服务器配置

随着业务的发展，应用服务器压力越来越大，在某个时间点，你可能发现其中一台机器的Heap被打爆了，修复很简单--临时增加最大堆大小。假设堆大小是运维人员登录到服务器时一次性更改，增加堆大小并重新启动Web服务器。然后在有些地方指出了Web服务器所在的机器正在进行维护。但不幸的是增加堆大小这个临时配置并没有被反馈到Web服务器配置基线里面，这样在未来新的Web服务器扩容进来并投产进来时，可能会面对因较低的堆设置，导致用尽内存从而带来的意外的故障。

计划的数据库密码变更

作为定期维护的一部分，生产数据库的密码可能需要被定期更新。这将导致应用服务器的数据源配置需要关联的更新。这可能可以通过手工或者自动化脚本以在生产上应用这些变更。

这个过程中脚本中的编程错误可能导致不正确的数据源配置从而导致某台应用服务器无法连上数据库，从而带来意外的系统宕机时间。或者，如果脚本需要手动运行每个服务器，管理员忘记将更改应用于其中一个服务器。

数据库URL变更

让我们考虑另外一个可能导致数据源变更的例子，随着业务的拓展，一个新的数据库投产，这样应用服务器上的数据源配置需要变更JDBC URL以便指向新的数据库。
为了让事情更有趣，让我们假设旧的数据库服务器保持运行，也许它会用于备份。假设再次的，组织通过手工或者自动化脚本以在生产上应用这些变更，这个过程中产生的错误带来的问题可能比上一个更难以发现，因为可能运行了一段时间后才发现，有些应用服务器居然连的还是老的数据库。

版本管理带来配置管理的焦油坑

一个好汉三个帮，现代软件开发，我们会在应用中引入各种组件依赖，而这些组件各有版本，在各条业务系统上，会根据自己的需求和问题，以不同的节奏升级自己的包，随着时间的流逝，俯瞰自己的所有系统，即使同一个组件也使用了各种不同的版本，这些不同的版本开放了不同的配置参数，这种版本配置焦油坑往往将我们拉入噩梦。一个好好的配置参数，在一个业务系统上表现良好，在另一个业务系统那里却是导致诡异问题的恶魔。

环境配置的复杂性

配置在环境间也有极大的可能产生飘移，在软件生产流水线上，一般标配是开发、测试、预发、生产四个环境，这些环境之间的配置并不完全相同，一些有助于调试类的配置只能在开发、测试环境打开。基于本地的开发和生产放在云上也常常会导致一些在本地调整的配置忘记了应用到云上的生产环境从而导致意外的生产服务停机。

铁打的团队流水的人

作为一个CTO，相信你经常需要面对这种时刻，关键时刻，痛失了一员大将，或者需要挥泪斩马谡，但是1个月的交接时间做个代码的“后事托付”都还不够呢，更何况是线上运行需要的额外的一些重要的配置变更？

你新招来的哥们投入迭代，开发新需求，然后在新的环境和机器上做部署，但不幸的事，系统跑不起来啦或者跑起来总是时不时出一些诡异的问题，因为曾经趟过的那些坑，曾经做的一些“黑配置”和紧急的fix已经随着那个兄弟一起带走啦。

配置快照

配置快照是指将系统中关键配置，例如SLB配置，nginx配置httpd.conf, 应用服务器配置，如tomcat.xml, 数据源配置，数据库配置RDS，缓存配置，应用配置如application.yml等定时（例如每天或者每小时）做一个快照存储到配置中心。

如下图所示:

让你的系统有恢复“出厂设置”的可能性

有了定期的配置快照之后，很容易通过在如下通用2个配置管理的流程中，在适当的点上使用配置中心提供的配置管理工具做到我们系统的一键恢复“出厂设置”或者一键恢复到上一个有效配置状态，

一般来说，配置中心提供的工具集应该包含但不限于以下能力:

• 统一分发配置到多台机器的能力
• 配置版本管理
• 从配置中心拉取配置并放到本地（可以使用类似confd这种工具）
• 配置分发/拉取状态追踪（例如推送轨迹）
• 配置变更审计能力

常用的配置中心产品介绍

• 阿里云 ACM: 阿里云应用配置管理，前身为Diamond，算是国内最早的配置中心产品。目前在Git上有不同开源版本，在阿里云上有商业版供使用。
• Spring Cloud Config: Spring Cloud官方用于做配置中心的工具，主要是在Java Spring领域使用。
• ZooKeeper: ZK其本身虽具备一部分配置中心能力，但是由于本身定位于分布式协调信息管理，因此仅比较适合在应用规模不大的情况下做配置中心。

总结

本文我们探讨了在云原生时代,云上开发和运维应用时（超过2台ECS）的配置飘移问题，以及探讨了如何通过引入集中管理配置的配置中心帮助消解配置飘移的问题，最后，想跟说的是 “用什么工具解决问题不重要，重要的是知道有这么个问题”。