在上一篇文章《传统企业DevOps基础设施架构规划之道》里面简单提到，区别于互联网企业，传统企业在实施DevOps时，一般只能实现DevOps to Pre-Production，甚至只是DevOps to UAT，极少能做到DevOps to Production的。当时并没有深入地展开讨论。本文尝试接着对这个问题做进一步的分析讨论，寻找导致这个问题背后的深层次原因。
在前面那篇文章里面也提到过，现在的传统企业大多遵循ITIL。这意味着在软件开发过程中存在变更管理(Change Management) 环节。简单来说，就是对生产环境的部署必须通过人工审批。一般来说，在操作层面，开发人员提前通过一个变更管理系统提交变更单，必须详细列明变更涵盖的改动、测试的结果、变更实施的具体时间、具体的部署与验证步骤、回滚的策略等，巨细无遗。变更提交后，必须经过相关人员的层层审批，然后才能部署。在这个过程中，只要其中有一层拒绝审批，整个变更单就得重新修改提交，然后从头开始审批。整个过程相当的费时费力。笔者曾经就职于一间大型跨国外资银行，曾无数次参与这种变更的审批流程，深感其中的繁琐。由于存在这样一个人工审批的环节，导致自动化的持续交付流水线不能打通生产环境的部署。DevOps就此与生产环境脱节。但是，这会是传统企业不能实现DevOps to Production的根本原因吗？
我认为不是。我认为变更管理只是表面的原因。要探讨深层的原因，或许我们需要回过头来审视一下为什么传统企业需要变更管理这一环节。很多传统企业，尤其是上市的大型企业，或者是金融类的企业，它们往往受到相关管理机构非常严厉的监管。对它们来说，保持业务连续性，以及IT系统的稳定性是非常关键的事情。生产变更导致业务出现问题可能会使企业陷入巨大的风险之中，所带来的财务和声誉的损失可能会相当严重。所以，它们必须引入ITIL和变更管理来保证对生产环境的变更都是经过审批的 。从某种程度上来说，可以认为它们是害怕与拒绝变化的。变化意味着有可能犯错，意味着危险。为了不犯错，宁可少变化或不变化，对变化的恐惧，才是其不能实现DevOps to Production的根本原因。但是，DevOps意味着拥抱变化。如何克服这种恐惧感，或许我们可以从互联网企业那里找到答案。
敏捷有句老话，如果你越害怕做一件事情，你就应该越频繁地去做它。对于部署，同样适用。互联网企业每天的部署次数非常多，如此频繁的部署往往意味着他们其实是在利用快速的上线来快速试错。允许犯错是互联网企业一个区别于传统企业的明显的基因。是人，就会犯错误。允许犯错是对人性的尊重。犯错并不可怕，犯错后只顾追责与逃责才可怕。与此形成对比的是，互联网企业并不会过多的追责，而是通过完善的容错机制让错误以尽可能低的成本尽早得到修复。犯错是安全的。犯错与纠错的成本是非常低的。这得益于频繁的部署造就的每次部署的细粒度。每次部署的改动都是很细微的，可能只是改一个图片的样式，或者是隐藏一个按钮，又或者是打开某个特性开关。部署的版本不正常工作？没问题，反正几分钟后的下一次部署就可以纠正。对用户更喜欢哪一个页面没有把握？没问题，同时部署两个页面做比较，看用户喜欢哪一个，掌握了第一手数据后立刻把受欢迎的那个页面部署到所有环境。有时候，互联网企业还会主动犯错，引入一些意外情况，以考察生产环境应对突发事件的能力。这方面最广为人知的就是Netflix的Chaos Monkey。互联网企业就是通过频繁的细粒度的部署以及完善的容错机制来消弭部署带来的风险。
对于互联网企业来说，生产环境部署是很轻量级的，是很稀松平常的事。当然，表面上看来很简单，实则非常不简单。不简单的背后离不开我在上一篇文章里面提到的非常强大的DevOps基础设施的支撑。例如，快速试错离不开A/B测试，蓝绿部署，金丝雀发布等部署策略的使用，这需要高度灵活的环境编排与基础设施即代码的能力；高频部署需要非常高效的持续交付流水线保障效率与非常完善的自动化测试保障质量；高效的纠错离不开完善的生产数据监控。除此之外，软件架构也需要考量。特性开关是实现高频部署的很重要的一环，软件架构必须具备足够的适应性与响应力，满足对特性开关的灵活设置。
罗马并非一日建成的。我相信入AWS，Netflix这些互联网企业也是经过很长时间的摸索与实践才走到了今天。我们只看到它们风光的一面，却很少去想，它们沿途走来也必定经历了许多炮火与血泪。DevOps之路并非可以一蹴而就，需要经历，沉淀与积累。对于传统企业来说，表面上只差最后一步，实则差距巨大。这种差距来自于基础设施建设与自身能力的薄弱，更来自于与生俱来的对变化的恐惧。越害怕变化，越急于求成，对基础设施的建设与能力的沉淀就做得越差，越没有信心，反过来就越害怕，形成恶性循环。正如笔者曾经参与的一个项目，领导强行要求把变更审批流程嵌入持续交付流水线中，然而实际的工作并没有发生任何变化，对外就声称实现了生产环境的自动部署。这其实是在自欺欺人，没有意义，团队根本就还没达到那个水平。其实最应该做的是，沉下心来，踏踏实实地构建底层的基础设施，不断尝试与总结，锻就自己的能力，积累自已的经验，一步一个脚印，逐渐建立信心 。纵使最后可能还是不能完全摆脱固有流程，也很难达到互联网企业的水平，但至少我们能够做到真正的拥抱变化，而不是惧怕它。
