本文选自4月电子杂志：《IT新架构》：翻开另一面

DevOps理念广受青睐。在现实中，DevOps同样遭受地盘之争，而传统IT也没有适合的工具提供支持。它同样给IT带来不少新挑战，包括来自同行的孤立与非结构化的部署途径。

“因为团队正在尝试新的流程与工具，没有什么完美的方案可循，”CommerceHub 的质量总监Vijaya Kokkili说，该公司为电子商务零售商提供技术支持。“我们无意间发现了一些问题，而且其中一些仍然没有答案。”

在公司采用DevOps的两年里，Kokkili看到了转型与新现实的两个挑战。

“我们本来希望将许多标准做到位，但事实却很难正常工作，”她说，“这不是关于如何使用这些工具的问题，”而是需要沟通与协作，并重新定义工作方式。

一种新的孤立

曲解原意，很容易让DevOps结构化的IT组织因坏习惯而失败。

像大多数IT组织，CommerceHub的职能团队分为开发、数据库、QA和运维，团队之间由办公室物理隔离。当他们引入DevOps后，从每个小组中抽调人员组建跨职能团队，虽然部门经理还保留了对应的监督职能。然而，跨职能团队内部却仍旧孤立。将开发人员、IT运维专家、数据库管理员质量保证（QA）测试人员，数据库管理员和项目经理放在一个房间里，并不能解决问题。

“QA工程师可能会被开发人员孤立，因为他们彼此并不理解，或者没法在同一个频道上交流，”Kokkili说，而且那里也没有其他的QA。最终通过培训缓解了这一问题，教育每个成员如何在别人的工作中共享。

一旦解决了沟通障碍，磨合尚浅的IT团队必须强化所有这些项目的宗旨：以客户为中心的文化。

俄亥俄州立大学的IT团队利用PMP（Project Management Professional）概念实施了ITIL。DevOps是下一个目标。如果ITIL是管理IT变更的最佳实践框架，“DevOps的目标在于改变文化，”服务运营总监Bob Gribben说。

同时，DevOps的IT团队仍然有着部门指标。例如IT运维有正常运行时间与利用率等指标。这些目标并不是跨职能DevOps团队产品所有者的目标。但以用户和产品为中心的文化并不意味着放弃IT指标。

我们分享一切——但那是我的

如果DevOps是关于分担某个应用程序的责任，是否仍然存在界限？举例来说，如果一个跨职能团队分担事件响应，你要如何才能限制代码开发人员访问生产环境以定位某个问题？你真的试过吗？

问题的复杂性在于，不同IT组织对DevOps的看法是不同的。某些组织中，IT运维团队依然保持着对生产环境100%的控制。其他情况下，开发者需要像对待代码一样对基础设施负责并确保每个版本的稳定性。

维护网络的安全与公司信息安全，意味着成为敏捷、灵活开发的障碍。因此，安全、数据与测试通常是DevOps文化所忽视的部分。

安全，基于角色的访问控制与加密是DevOps应用程序生命周期的重要组成部分，Column Technologies技术顾问公司的首席DevOps实践管理师Michael Grant指出。适合的工具能提供可视化的流量监控，这也能让安全团队同意开放DevOps环境所需的应用程序所有访问权限。能够可视化网络与应用程序调用的基础设施监控工具同样能够提高安全性，无论是数据中心还是多租户的云资源上。

数据是每个企业的支柱，因此它也应该是DevOps流程的一个主要部分。但数据库管理员在DevOps的持续反馈回路中并没有原生位置。数据即服务是DevOps的下一环节，Grant说。数据安全作为一种服务，能够让QA在代码部署到生产环境之前更精确的测试负载——不至于压坏数据库团队的基础设施。

测试更难被DevOps实践者接受，他们总是看不到质量保证与测试专业知识的价值。

“我们某个产品团队，没有QA——这样就需要假设开发能够做测试的活，” Kokkili说，“但没有专业知识，测试环节积累了不少技术债务并最终导致生产环境问题。”

相比之下，将测试与质量保证工程师加入DevOps团队可以防止和一次性修复代码问题，避免DevOps在线上进行首次修复的思维定势。

当你手里只有一把锤子时

工具是任何DevOps环境的重要组成部分，但对于如此重要的问题，工具选择却是DevOps的结症所在。

“某个团队使用SalesForce来跟踪问题，另外一个组使用Trello，还有的团队在使用Jira——但这些都是为了解决相同应用程序的问题，”Kokkili说，“高级别的可视性十分困难。”

开发人员习惯于采用顺手的工具，无论工具是否适合公司的合规性，报表或运维可视性要求，Fixate IO的DevOps分析师Chris Riley指出。DevOps团队的目标是在不限制团队成员创造力的情况下实现标准化，而且还处于寻找满足跨职能协作常用工具的挣扎中。

采用DevOps工具的企业IT部门往往会权衡开源软件与能提供全面支持的企业套件，结果通常会更偏向于企业套件，某专注DevOps的IT顾问指出。这是因为企业希望能获得专业的支持、稳定与可用功能，如图形用户界面，而很多开源工具通常都不具备这些。与此同时，传统基础设施管理与监控工具厂商如CA与BMC真在开发DevOps产品，但好坏参半。折衷的方案是采用类似Puppet，遵循Linux开源模式，并通过上游社区借鉴控制、产品支持的经验。

我们离成功还有多远？

成功需要不断改进和完善，而不是对特定变更发起一次推动，却没有整体规划。DevOps，很像之前的ITIL，一直在推广反馈回路，但更多时候，IT部门更喜欢直接到达终点，Tedder Consulting公司首席顾问Doug Tedder说。

 我们看到与ITIL IT服务管理（ITSM）实现相同的模式。人们引入了事件管理和基本的变更管理流程，但并不理解如何交互或达到目标，Tedder说。“有些人过度设计了ITSM流程，这就不是ITIL，而是如何建设流程了。”

“改变需要努力，”Ohio State University的Gribben说。例如“需要每周花上5小时来进行新工具的培训，目的是为了之后每周能节约25小时。”

他同时还指出人的本性是专注不同工具、或更多的工具，而不是注重流程。 

“高管们会说‘等一下，我们已经买了一款工具，为什么还需要一个又一个的新购？’，而且似乎什么产出都没有，”Tedder说。如果IT部门没有针对业务进行持续改善，没有工具或工作组能够将他们从影子IT和外包结局中拯救。 

CommerceHub的Kokkili倡导像他们那样进行DevOps实践，第一年只引入一个产品团队，并且通过培训、讲解和出席会议建立与接受这一文化。“快速失败”可能是应用程序更新的口头禅——没有那么多人参与。