在过去的一年里，来自欧美的一群系统管理员和开发者一直在谈论一个新的概念：DevOps。DevOps是开发和运维这两个领域的结合。（DevOps还包括产品管理、QA、*winces*甚至销售等领域，如果我没记错的话） TheBroken 那么……为什么这两个领域会合并？原因有很多，但第一个原因是：我们当前的工作流程是脱节的。绝对脱节。很多公司的开发部门和运维部门之间的深层矛盾其实就是这种“脱节”造成的。（意译，请指正） 下面是一个大家基本都熟悉的例子：部署软件产品。 开发部想开发一款新产品。该产品需要使用最新最炫的技术来保证客户的所有花里胡哨，从而为公司带来数百万美元的利润。此产品要求使用最新的技术和操作平台，并且必须立即交付。于是开发部门没日没夜地加班加点，发疯似的砍代码，终于如期完成了任务。然后他们将自己的“杰作”倾倒给了运维部门。后者还没能完全接手，前者则迫不及待地要开始庆功宴了。 收到产品后，运维部的每个人都充满了恐惧。 这里是运维部的恐惧来源：（{A.B.C}表示A或B或C之一） 这个优秀的产品无法在当前的底层平台上运行，因为这个平台太旧了，空间不足，不支持某个版本} 该产品的架构与我们的{存储、网络、部署、安全}模型不匹配。 我们不了解这个产品的{reporting,security,monitoring,backup,servicedelivery}，所以我们不能把它变成一个实际可用的产品。 尽管有无数的抱怨和咒骂，运维部最终还是安装了这款产品。遗憾的是，由于大量的拙劣修改和不合理的强行操作，这款产品的性能只能归结为：***失败（EpicFail）。 于是心灰意冷的运维部开始记录各种问题，不断向开发部提出问题。而开发部门的回应基本上是： 这不是我们的错——我们的代码很糟糕——但部署（由运维部门）很糟糕。 运维部门很蠢，不懂新技术——为什么不能把最新的技术落地？为什么它们如此过时？ 在我的机器上运行的很好... 两个部门的沟通很快就变成了风暴。客户（以及股东、投资者和管理层）是遭受损失的输家。最后公司赔了无数的钱，大家都丢了饭碗。***的失败。 DevOps有什么不同？它有什么好处？ DevOps就是想办法避免这种“***失败”，同时让大家以更聪明、更有效的方式工作。它是一个包含很多好的思想和原则的框架，它鼓励开发部门和运维部门之间的合作。在DevOps环境中，开发人员和系统管理员建立关系、流程和工具以更好地与客户互动并最终提供更好的服务。 DevOps不仅仅是一种软件部署方法。它用一种全新的方式来思考如何让软件作者（开发部门）和运营者（运营部门）进行合作和协作。使用DevOps模型后，两个部门将更好地互动，改善两者之间的关系，这将有利于许多领域，例如：自动化、监控、容量规划和性能、备份和恢复、安全、网络和服务供应,等等 “什么是DevOps？”DevOps社区中的每个人都以不同的方式回答这个问题。因为我们的工作经历不同，关注的问题也不同。个人认为DevOps分为四个部分： simple KISS（KeepitSimpleandStupid，简单就是美）原则是最重要的。所以这段文字也很简单。我们尝试提供简单、可重复使用的解决方案。“简单”可节省文档、培训和支持方面的时间。“简单”增加了沟通的速度，避免了混乱，降低了开发运维出错的风险。“易”让发布产品更容易更快。 跨部门关系 早参与，多参与。对于开发者来说，运维人员应该驻扎在开发部门，参与开发的全过程。邀请运维人员参加你的Scrum或开发会议，与他们分享项目计划，分享新技术的想法和经验。在收集功能需求（指开发者使用的需求）的同时，还要收集运维需求。将“发布、备份、监控、安全、配置管理、系统功能”的测试视为一个独立的项目过程。软件产品在开发时解决的问题越多，在使用时暴露给用户的问题就越少。培训运维人员，让他们了解项目的架构和核心代码。如果运维人员在报告bug时提供的信息越多，你花在故障排除（trouble-shooting）上的时间越少，bug解决的速度就越快。 对于运维人员来说，遇到问题需要加开发人员，大家一起解决问题。邀请开发者参加你们的会议，分享项目进展（路线图），共同修改工作计划。运维人员必须了解开发部门下一步的工作方向，以保证产品运行的底层平台能够很好的支持最新的技术。开发人员也会带来相关的技术、知识和工作，帮助您改善产品的运行环境，使其更易于维护、简洁和有效。 开发领域有一些概念，例如：“基于API而不是封闭接口构建工具”、分布式版本控制、驱动测试开发，以及敏捷开发、看板管理（Kanban）和Scrum等方法论。如果将这些理念应用到运维领域，也会产生革命性的变化。 不要害怕新想法和新技术。我们可以随时随地向别人学习，哪怕是一句“我们再也不要那样做！”虽然我们在不同的部门，但是我们要一起学习，一起成长，这样我们才能更好的合作！ 按照从高到低的顺序，有效的沟通方式应该是：面对面沟通、视频会议、电话、即时通讯软件、Email。 Processinwork 有自己的过程工程（processengineering）——从原来的成绩单到ISO9001。但它们都有一个关键缺陷：它们过于理想化，要求每一步都必须成功执行。例如：为了组装一台新主机，会有如下一组简单的流程： 第一步：安装机器（将各种硬件组装在一起）。 第二步：接线并上电。 第三步：安装操作系统。 有步骤4、5、6。 如果一切顺利，步骤N将以一个功能完备且正常运行的新主机结束。但是万一有进程跑不通呢？比如在某一步断了不能继续，或者在这一步输出异常。是否还有其他步骤来处理此异常？ 所以，这个过程从头到尾都不会一帆风顺，所以我们要认真对待这个过程的每一步，找出所有潜在的问题和障碍。和软件产品一样，在流程管理上一定要有异常处理。我们不必能够准确预见每一个问题，但一定要保证即使流程出了问题，它仍然可以走下去。 将不同领域的所有过程串起来。这些领域包括：部署、监控、容量规划等。从逻辑上讲，“部署”是软件开发周期中的最后一个环节，因此应该属于“开发过程”而不是“运维过程”。另一个例子是指标和监控。在发展领域，如果不了解底线标准和估计，就无法进行任何评估。将开发部门和运维部门的流程打通，也会让两个部门更好的合作，相互理解，承担共同的责任。***还有一个好处：只需要一份文档，而不是两份（开发一份，运维一份），省钱。 自动化，自动化，还是自动化。构建或使用简单、可扩展的工具（确保提供API、机器可读的输入、输出——请参阅JamesWhite的文章：InfrastructureManifesto）。使用Puppet等工具进行配置管理。需要对这些自动化工具进行扩展，使其能够支持多域（开发域和运维域），使用同一个工具（也叫端到端）。这不仅会在产品支持和管理方面带来经济效益，而且允许在编写新代码的同时发布和管理产品。 ***，在构建流程和自动化时，请牢记KISS原则。越复杂越容易出错。只有简单的流程和工具才易于实施、易于管理、易于维护。 持续改进 不要停止创新和学习。当今的技术发展迅速，客户的需求往往也是如此。在你的工具和流程中加入“持续改进和持续集成”也是运维人员向（优秀的）开发人员学习的好方法，你可以学习测试驱动开发等最佳实践。例如：单元测试可以添加到您的部署过程中。在做监控的时候，还要加入一些行为测试，以提高交付质量。尝试用开发领域的工具（比如Hudson）做一些运维领域的工作（比如探索数据（explore），衡量性能（measure）等）。 要不断总结教训。积极主动，在不同领域寻找错误的根源。一旦收到bug报告，果断打电话给开发团队和运维团队一起解决问题。有时开发者可以简单的重构几次代码，避免改变底层运行环境，减轻运维人员的负担。总之，遇到问题，开发部门和运维部门应该密切配合，共同解决，而不是互相推卸责任，踢皮球。 对我来说... ***，对我来说，DevOps的主要内容是：跟谁一起工作，怎么一起工作。最吸引我的是，它致力于把不同部门、不同分工的人聚集在一起，共同解决问题。这样的工作环境才是我向往的天堂。
