DevOps是IT交付过程令人兴奋和具有深远意义的转变。承诺很诱人： 从根本上提高生产力，更低的成本和更可靠的系统。

那么，你应该跟随潮流，让你的IT部门去参与开发运营融合（DevOps），对吧？大家都开始干了，所以你也别落后。最大的问题不是干不干，而是怎样干，从哪里入手？

首先，走出去，招聘一些DevOps人才。等，等DevOps可不是一个岗位哦。
好吧，你应该创建一个DevOps工作组或者部门，对吗? 在一个DevOps主管的带领下，你可以训练出一个伟大的DevOps团队——再等等！！——DevOps既不是一个部门，也不是一种职能。

好吧，如果它不是一个岗位、 一个职能或一个部门，那DevOps到底是什么？

DevOps是文化、 流程、 技术和人。DevOps战略是将许多学科融合为一套有凝聚力的组织原则。DevOps是一种新的IT系统交付方法，承诺更快交付、更高质量、终结全球饥荒、获得永生！好吧，也许不包括最后两个……DevOps也意味着IT组织在时间、经历和资源各方面的庞大的投入。

DevOps也就是应用程序开发和系统运维的融合 可以改造和提升IT交付能力。DevOps概念同样也极易被滥用，所以我认为应该立一个警示牌。警告：DevOps滥用可能导致丢饭碗、 业务中断、和CEO郁闷地汇报。

DevOps为什么不容易

首先，让我们弄清楚DevOps“不是什么”。DevOps不是Chef、Puppet或者Salt Stack，或者任何其它工具、脚本环境或者技术。虽然自动化是DevOps的核心理念，但它不等于自动化。

DevOps也不会是你组织里深层次技术和专业技能的替代品。去专业化，并不意味着你要解雇你所有的Linux或者Oracle专家。

对于高度集中的科技公司例如Yahoo 、Facebook或Yammer，那里的所有DevOps主管想要取得DevOps成功非常艰难。对于传统企业，特别是大型分布式组织，在整体意义上的DevOps成功往往是不可能实现的。

为什么这么难？一个原因：文化。

DevOps要求深层次的文化和组织变革。需要改变行为习惯 ——要改变的太多太多。这意味着大家要扔掉奉行了几十年的显规则和潜规则。你不得不告诉老部下们，大部分他们知道的和每天做的事物都已经过时了。

IT组织结构调整很容易。我可以把开发人员和运维人员安排在同一个房间，安排他们完成工作，这也是一种显式的调整。但是，这两个不同的群体的人，带着多年不一样的培训经历和不同的技能，真能够融入DevOps组织吗？要知道，他们可能来自不同的星球！

怎样搞定DevOps

想要为DevOps和应用灵活性而重塑你的团队，需要领导层的勇气和无私奉献。当然，它也需要花费时间和金钱，并且需要在团队成员筛选上做出艰难的决定。

为了促进DevOps战略，调整考核和激励机制是必要的。如果你依然只根据敲出代码的生产力来奖励开发人员，或者根据基础设施的可靠性来奖励运维人员，那么，什么都不会改变。相反，应该奖励系统创建和运维的整体团队，并且根据团队工作的全部要素来确定奖励。

围绕业务系统而不是职责来组织工作，这就是DevOps打破IT分组壁垒的寓意。一个团队应该有开发人员创建代码，从用户界面到业务逻辑和数据结构，也应该有运维人员负责操作自动化和部署。

人们需要知道他们需要对什么样的系统负责，而并不仅仅是毫无责任地从一个系统换到另一个系统。唯一的例外是专家。

团队待在一起，共同为他们的应用和系统负责。

不要制造一个团队支持太多应用的局面。在这个预算缩减的年代很难考虑周全，但是经历这种融合转变之后，你的团队将更加富有成效，并且不需要额外人员就能应对需求的增长。

你需要充足的专家参与项目和为团队提供支持 ——这些人都是不同学科的大师和专家。他们为系统提供支持，但是不会长期指派给某一个系统。他们不需要对这些系统负责。

全面自动化 —— 部署、 升级、 扩展、 维护、 数据卫生、 测试、 监测、 安全和策略管理。在自动化方面投入巨资，目标是100%的自动化，不考虑低于90%的可能性。但是，全面自动化也可能会引起自动化泛滥。集中审查和调整可以控制Chef或Puppet脚本库的无序增长。

针对整个团队进行奖励和表彰。成功离不开大家共同的努力，同样，问题需要整个团队自我反省。系统团队应该承认专家们的贡献 ，对表现杰出的专家给予奖励。

围绕建设运营融合的原则制定新的企业体系结构标准。这将确保系统符合运维的需求。

DevOps战略必须获取本组织自顶向下的全面支持。整个行政领导团队 ——不只是首席信息官 ——应知道它为什么重要和怎样使它取得成功。

请记住，这是重大的文化和组织变革，多分配些时间开展培训和组织开发活动。如果你变革得太快而忘了和您的所有团队步调一致，你将整天陷入失误和冲突——最后满盘皆输。