2011，DevOps 扎根的一年

在 IT 这个行业内，每时每刻都会有新的理论和实践涌现出来，致力于解决在这个领域内可能存在已久的问题。如果说要给在 2011 年内出现的新技术趋势投票，DevOps无疑是位居前列者。下面这段是引用主编熊节在 2011 年4 月《架构师》DevOps 专题中的篇首语：

经过几年的酝酿，敏捷和运维这两个领域终于各自受到了足够的重视，并顺理成章地有了交集。从 2009 年起，一阵被称为"DevOps"的风潮从欧洲 发端，迅速席卷了北美和澳洲──现在以 Flickr、Twitter 为代表的一干互联网公司竞相以快速发布、频繁发布为荣：这厢 Flickr 做个 PPT 叫"每天 10 次部署"，那边 Twitter 就在演讲里有意无意地说"每天部署几十次"。一说起做互联网，你要是还在走俩月一个版本的发布周期呀，你都不好意思跟人打招呼──等你做出新版本，用户都跑竞争对手那儿去啦。

作为国内致力于促进软件开发领域知识与创新的传播的先锋媒体 InfoQ，对于新理念和新事物的推介从来不遗余力。如果我们现在回顾 2001 年 DevOps 专题的内容，会发现来自一线专家关于 DevOps 的精彩内容和分享俯拾皆是，琳琅满目。

第一篇是来自百度乔梁《DevOps，不是一个传说》，作者从让数据说话、流程建模、发现浪费、应对措施四个方面，来指导团队的各个角色如何破除部门之间的壁垒，让合作方式发生巨大变化，从“碉堡防御”走向“战线统一”。

原来，各角色仅关注于自己本身的工作，虽然大家都同处于一个项目中，但各自划分了"领地"，产品经理就应该将 MRD 写得清清楚楚，如果开发人员认为 不清楚，那就回去再改。开发人员只管按照 MRD 上的内容进行开发，很少考虑可测性和易测性问题。测试人员只管按照 MRD 中内容来测试，有问题通过内部工作 流平台提交问题单。运维人员只管根据开发人员提交的上线操作单进行操作。似乎各角色之间的沟通介质只有各自的"交付物"。

现在，各角色都能够共同合作，以项目的最终交付为目标，积极讨论需求，优化实现。因为角色之间的这种紧密合作让所有人对不同角色都有了深入的了解。 开发人员耐心为产品经理解释技术实现，说明计划安排，测试人员与开发人员共同讨论验收条件，避免遗漏需求。开发人员让运维人员了解架构设计， 细心听取运维人员的建议，进行技术改造，使部署工作更快捷有效。

对于 DevOps，不同的专家视角为读者呈现出 DevOps 不同的特质。James Turnbull 的《我眼中的 DevOps》中谈到：

DevOps 就是想方设法的避免这种“终极失败”，同时让大家用更聪明更有效的方式去工作。它是一种框架，包含了很多优秀想法和原则，它鼓励开发部门和运维部门通力合 作。在 DevOps 环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。

DevOps 也不仅仅是一种软件的部署方法。它通过一种全新的方式，来思考如何让软件的作者（开发部门）和运营者（运营部门）进行合作与协同。使用了 DevOps 模型 之后，会使两个部门更好的交互，使两者的关系得到改善，从而让很多领域从中受益，例如：自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提 供（provisioning）等等。

而 Damon Edwards 认为《DevOps 不是个技术问题，而是个业务问题》：

但是如果抛开这一业务流程的上下文，看看我们还剩下什么？是的，我们有一伙人，还有一些部门，它们各自做着它们自己的分内事。但是我们失去了真正做事的动力，到处是效率低下的工作、浪费、冲突和部门间的孤立。从表面上看，每个人都在仅仅为自己工作。

如果没有业务流程这一上下文，还会发生什么事呢？我们的工作将失去意义并最终消失。实现业务目标是我们得到薪水和花时间做事的原因。如果没有业务目 标或者我们所做的事情根本对实现业务目标都没有助益又会怎样呢？糟糕，我们所做的一切都变成了一种爱好。想想吧，有谁会傻到给爱好付薪水呢。

而我们本土的技术专家在对 DevOps 的理解和运用上，丝毫落后于国外的专家。事实上，在 DevOps 所涉及的工作，先进的互联网企业已经在多多少少在尝试自己的实践，来印证 DevOps 的可能。

李小红的《不同技术团队的配合问题及 DevOps》一文，广受读者好评，被认为实用、干货很多。文章从团队和部门领导者的角度，对 DevOps 涉及到的消除团队部门隔阂，给出了具体的操作办法，值得参考。

ThoughtWorks 的首席咨询师熊节对于如何采纳 DevOps 指明了方向：《建设 DevOps 能力，实现业务敏捷》。他阐述了 DevOps 试图解决的问题以及对策，并以 Flickr 案例说明可行性。同时，对于 DevOps 能力建设面面临的挑战也予以点明：

• 跨部门协作。很多大型软件组织都将开发与运营划分为不同的部门，而 DevOps 需要开发人员与运营人员无缝融合、紧密协作，这必然涉及部门之间的协调。如果处理不当，部门墙有可能严重损害软件组织交付业务价值的能力。
• 高层领导投入。相比传统的瀑布式发布，DevOps 是工作方式的变革，涉及到技术、流程乃至团队文化的改变。如果缺乏高层领导的关注，或者如果高层领导只把 DevOps 看作小范围、技术性的改善，DevOps 建设将很难收到预期的效果。
• 团队稳定性。传统意义上的“运维”是技术含量较低的岗位，人员流动率也相对较高。DevOps 要求开发团队和运营团队（尤其是运营团队）掌握更全面的技能，尤其是项目自动化技能。如果不能保证团队相对稳定，学习投资就会被浪费。