还需结合真实案例，确保DevOps带来的潜在回报能够发挥***价值。
DevOps在原则层面堪称技术领域的乌托邦，其强调软件开发者与其他IT员工及管理层间的协作与沟通，同时主张以自动化任务处理方式实现软件交付及基础设施更新。有了DevOps的帮助，软件的开发、测试与发布工作皆能够得到显著加速，可靠性亦将有所提升。
然而尽管成功案例不少，但事实证明DevOps也有可能因为种种原因而走入歧途。为了防止这类状况再次发生，我们将在今天的文章中通过实例进行分析。
缺少项目发展愿景
IBM公司早在2003年就开始进军DevOps——当时这一词汇甚至还没有正式出现。蓝色巨人希望借此实现一款新产品的敏捷软件开发。虽然投入了不少资源，但其努力显然并没有获得理想回报。根据IBM公司北美云与DevOps服务线负责人Mustafa Kapadia的说法，“开发方面的速度非常出色，但运维团队却无法及时跟上，这就使得客户仍然不能快速获得开发成果。”
作为DevOps举措的一部分，IBM公司随后决定以自动方式进行代码部署，同时继续秉承敏捷方法。然而这同样未能提升软件交付速度。IBM公司进行了“价值链分析”，并发现***的障碍并非源自敏捷或者自动化，而是整体开发与运行环境。尽管在手段上有所更新，但陈旧而迟缓的原有环境仍然令项目陷入滞后。
最终，IBM公司的DevOps尝试宣告失败。Kapadia表示，“如果我们不清楚要如何完成工作，也不知道哪些问题值得解决，那么无论如何变换敏捷方法都将无济于事。”
而这也证明，只要管理者们能够真正理解工作流程及其中影响速度的环节，那么DevOps就能够真正得到针对性调整并实现应有效果。
可访问性太高，相关培训太少
早在2006年，专业内容共享网站SlideShare（如今已经被领英所收购）还是一家员工不足20位的小型初创企业。但雄心勃勃的他们希望利用DevOps模式加快速度并领先于竞争对手。
DevOps的目标在于尽可能提升工程团队效率并传播技术知识，这样任何企业成员在休假或者离职时，其他人员都能顺利顶替而上。
另外，DevOps的一大设计原则要求员工拥有更强的工作责任感。“这意味着开发者可能需要接触基础设施当中那些以往并不需要了解的部分，”前SlideShare公司成员Kalache指出。在SlideShare公司，工程师们需要访问生产服务器与生产数据库。
有位软件工程师尝试了一款MySQL数据库的图形化操作工具。“他决定重组该工具以提升其实际效果，”Kalache指出。“但他没有想到的是，自己的修改对生产数据库的执行序列造成了影响，最终数据库锁定并导致SlideShare.net网站无法访问。”
而且在问题出现时，这位当事者甚至根本没想到是自己的修改引发了状况。“此次故障给我们带来两项警示。其一，虽然DevOps旨在失去大家参与到产品/服务周期的各个阶段，但事实上这种广泛的访问能力也可能极为危险。此次状况在当初的小型企业中可能影响不大，但对声誉良好的大型公司而言则很可能是致命的。”
其二，开发者需要接受更好的培训以了解生产基础设施的相关知识。Kalache指出，“DevOps是一种高度强调人与人间互动的工作方式，我们不能先入为主地认为参与者了解某方面技能。因此，培训必须以强制方式进行。”
DevOps覆盖范围不足
有时候，失败的结果可能源自DevOps的指向性过强。
某家车辆租赁公司在全美拥有大量合作伙伴。每位前往合作伙伴处希望租车的用户都将通过一款定制化应用获得相关信息与申请服务。不过由于其中涉及资金交易，所以应用内也包含有第三方服务负责验证。
“这款软件的DevOps方案主要围绕服务器指标，旨在确保应用性能始终稳定，”该公司软件顾问Nathaniel Rowe表示。“但在几周之前，我们曾经由于监控结果出现问题而被迫中断了整套系统，”Rowe表示。“某项必要的第三方验证服务出现了网络中断，这直接使得我们的基础设施也陷入瘫痪。”
出现这一问题的原因相当复杂，包括设计上的缺陷与开发中为了节约成本而狂砍外包价格。总之，最终原本并非必要的系统指标变成了运行的必要条件，这实在让该公司始料未及。
问题出现后，开发团队立即介入并分享了特定验证代码，从而在根本上杜绝了发生此类状况的可能性。“为了防止未来再次发生这种网络故障，我们设置了全局重新路由机制，并在服务出现问题时立即向合作伙伴发出提醒。”
事实证明，前期时间与资金的投入非常必要。执着于眼前的小利而忽略了DevOps的适用范围只会带来更大的损失。
忽视人员与流程
CloudBees公司现任DevOps布道者Brian Dawson曾就职于美国政府的一家合同供应商，当时他们正帮助政府开发一款Web应用。“我们当时的工作是构建工具及流程以覆盖全部定义与规则，构建、提交并发布代码，具体手段则采取协同型开源启发形式，”Dawson回忆道。
DevOps工具的部署与配置非常成功，然而遗憾的是DevOps不可能单纯通过工具来实现。他强调称，“人员、文化、流程与工具这几大要素在DevOps中同样重要。”
然而，政府方面只求快速完成平台构建，却忽略了人员与流程等环节。“这意味着虽然我们提供的是DevOps平台，但其实际使用方式却仍然相当陈旧，”Dawson指出。“整个敏捷流程根本没能得到有效落实，实际生产负荷测试也没有真正进行。”
最终，Web应用发布后立刻遭遇到大量故障。另外，由于涉及多个政府部门，因此解决问题的周期相当漫长。而在网站最终开始运作后，人们又发现其响应时间缓慢到令人难以忍受。
技术问题在几个月后彻底消失，但文化层面的冲突却始终不断。Dawson指出，“如果没有科学的人员、流程与工具相配合，DevOps根本无从谈起。”
毫无疑问，DevOps是一种相当有效的软件交付加速方案，但其同时也能够为我们的团队提供一种***凝聚力的文化氛围。如果失去了这一点，那么DevOps根本无法掀起这一股新的技术转型浪潮。
