两个线上变更的小故事

最近讨论生产环境的变更动作要标准化和流程化，并逐步收归平台的问题，遇到一个有意思的有意思或者可能比较常见的小挑战：

脚本和命令行方式不是很灵活，遇到什么问题，随时可以命令行解决。

暂时不说观点，先分享我在华为的时候碰到的两个小故事吧，两种对待生产环境不同处理方式的的案例：

第一个，我亲身经历的，2013年左右，我们服务的运营商采购了HP的小机跑Oracle。

经常会碰到一些问题需要联合排查，我们为了保证灵活，及时响应，说改配置就改配置，说重启就重启，利索的很。

但是，HP国内的工程师在小机上执行的每一行变更命令（查询不算）前，都是要得到总部确认和授权才可以执行的，说破天，也绝不允许随随便便执行变更。

当时我们就认为，几个命令行的事，搞这么复杂，真是不开窍。

第二个，是华为同事亲口给我说的，当时他在南美交付一个SMS项目，做验收时（准生产环境），有个用例没通过，定位发现有一个配置开关没开，习惯性登陆数据库就执行了一条update，把0变成了1。

从登陆数据库，到执行update语句，再到用例执行通过，还不忘给客户炫耀下操作多么熟练，让客户目瞪口呆。

结果，该项目直接被客户叫停，拒绝验收，现场和总部高层到现场赔礼道歉，承诺整改，全组现场接受变更培训，好像过了大半个月，经过一个专业考试后，再次上门道歉，才重启验收。

这种行为，国内没有问题，不出事，没人挑毛病，但是在海外，这就是不守规矩，没有专业性。

再往后，华为内部一直强调，交付给客户的生产环境，是客户的，不是华为的，任何动作都得经过主人同意，华为是服务方，不是你想动就能动的。

对于这种情况，华为也一直是高压线处理。

前两天在QCon，几个讲师聊到线上故障原因，变更引起的故障基本都要超过70%，，说变更是万恶之源真的是毫不为过。

所以，基本上，控制好变更引入的问题和风险，线上的故障就可以减少大半，而这里，我觉得首要的解决的问题，就是要规避人为操作引入的风险。

所以，我的观点，无它，生产环境，不要需要那么多灵活，越严谨越标准越好，越灵活，反而挂的越快。

大家也分享下看法吧。