对SCM好些，携程事故影响能否被降低?

如果对SCM好些，携程事故影响能否被降低?

今天下午QQ群，朋友圈，微博突然间就爆炸了。我还以为挖支付宝光纤的铲子找到了呢。Oh,NO. 这次不是支付宝铲子的问题，是携程数据的问题。

我打开携程网站，发现一个特别友爱的提示：携程网站暂时无法提供服务，正在紧急修复中...你可以访问：艺龙旅行网。如果要是平时我还以为两家联姻了呢。实际上是因为携程已经好几个小时无法访问了。打开首页看到的飞机信息还都是3.25号的信息。随便再点一下，就直接挂了。

这时ScmRoad QQ群里各种小道消息，有的说携程数据库物理被删除了，有的说上线脚本出现问题把线上服务器 D 盘卸了，还有的开始报线上版本的源代码都被删除等等。各种消息满天飞。这时一小撮 SCM 开始插科打诨，有的开始卖硬盘，有的开始卖携程备份数据。。。。总之这是一起重大事故已经定性了。

有人微博说携程内部悬赏100万解决问题。现在是悬赏解决问题的时候么？现在是大家齐心协力，解决问题，共度难关的时候。你这样悬赏得伤了多少技术人的心啊。

事已至此，我在考虑如果平时 SCM 的工作做得更好些，这次事故带来的影响会不会小些。 首先从网上报料至少有以下几个方面和配置管理有关：

1）线上环境被破坏（线上服务器 D 盘被卸载）

2）线上版本丢失(无法找到线上的发布版本)

3）线上版本的源代码丢失（囧...）

4）找不到发布清单（居然到了要每个人查自己邮件记录归纳发布清单的地步）

再牛逼的技术也抵不过一次物理伤害，这是一个真理，但是我觉得不是那么简单，事情查清楚后再去分析吧。我们现在来看看上面提到的四个方面如何解决。

上面的问题结点分析来其实涉及三个方面

1）源代码管理

2）发布管理

3）线上管控

源代码管理是配置管理的基础，没有良好的源代码管理，是做不好配置管理的。源代码是公司的资产，如果公司的资产都能这么轻而易举的丢失，且很难恢复，那么我只能说我们的配置管理工作太需要改进了。很多人都在强调备份，其实恢复更重要。扪心自问，有多少人会定期的把备份的数据在其它服务器上恢复，看一下数据是否可用，校验一下数据是否正确？很少。不做恢复的备份就是个面子工程。当你需要恢复的时候，我们却发现数据是不可用的，或者可用但数据太旧的时候，也许才懂得备份恢复的价值。我再强调一遍：不做恢复的备份是没有任何意义的。同时要做好源代码的管控。源代码丢了，SCM 却无法及时恢复，只能说明 SCM 地位太低，其它人的权限太高了，过多插手 SCM 的事务。建议取消所有和 SCM 不相关人员的管理权限，同时限制对备份数据的读写。

这里涉及发布管理的问题很多。首先发布版本丢失。发布的版本是什么？是钱啊。按照今年携程一季度财报公布的数据，携程宕机的损失为平均每小时106.48万美元。试想谁会把这么多钱都能丢了呢？这些都是显性的损失，隐形的更大。品牌的价值，客户的信任。其次是线上发布清单。这个清单就如同小孩的出生证明一样，要和发布版本在一起。发布的版本和发布清单必须做好存档，备份，且限制访问。除了配置管理人员，其他人员限制访问。

线上管控不必多说。这次事故，运维要承担责任。要有线上事故的预案。和配置管理相关的部分就是要把配置管理和运维松耦合。同时管理分开。万一某具有配置管理系统和线上系统高权限的人出错了那影响的可是从源代码到线上环境，一整套系统。这太可怕了。有些人是权力控，我是总监我是VP，我就要有系统的管理权限。我还是给这些人降降温吧，从公司利益的角度出发你也不应该这么做。

这次事故中配置管理最大的问题是配置管理员对配置管理系统话语权的丧失。也就是文中提到的配置管理工程师

１）无法及时提供线上版本，发布清单

２）当线上版本，发布清单不可用，找不到的情况下，无法从源代码快速构建出线上版本

３）无法提供线上版本的源代码，甚至无法恢复。

这三条不都是配置管理最基本的职责么？

实话实说，我不是来补刀携程的，只是觉得公司在某些方面的确应该给专业人士话语权，让专业人才干专业的事。希望通过这次事件让大家把配置管理重视起来，同时让配置管理人员干好自己的活。

ps:最新消息是有个开发总监离职给系统留了后门造成的。不知真假。如果真是如此，这人的人品也真够差的。