云计算DevOps下，IT和业务应如何转变思维

云计算开发运营要求企业的IT部门和业务部门在协作方式和思维方式上都做出一些变化。请仔细阅读本文并了解他们应当作出哪些改变。

在云计算技术问世之前，应用程序的部署是由开发人员与数据中心内系统运营管理人员共同协调完成的。这正是开发运营（DevOps）一词的由来。而云计算的出现改变了这一切。目前，应用程序正越来越多地是被组装出来的——而非传统意义上的“开发”，而最终用户在应用程序的部署与生命周期管理中也越来越多地发挥着作用。云计算开发运营的成功源于从一开始就让其利益相关者涉足其中，同时协调团队积极专注于功能方面的组装（而不是开发），并克服了IT专业人员和运营人员之间的文化差异。

从一个组织和业务流程的角度来看，由云计算创造的最大变化就是对直线集权型组织进行了直接的授权，而在之前一直都是以IT为中心的流程。选择一个基础设施即服务供应商是一个技术难题，而选择一个软件即服务（SaaS）供应商则是一个商业问题。目前，无论企业用户采用了哪一种形式的云计算服务，利润和市场份额的压力都迫使他们更多地选择SaaS这类的模式，在这类模式中最终用户可在选择上发挥更大的作用。同样不可避免地，他们将在部署和应用程序生命周期中发挥更大的作用。

以一个强大企业架构为出发点将是有价值的，因为目前在云计算开发运营未来中的主要利益相关者都是间接从业务流程切换至IT实现的，而在未来这样一个转变将越来越多地以云计算服务为目标。此前，在这一层次上的流程定义都已能够拒绝用户对应用程序变更输入的速度，或者新功能必须被部署的速度。而现在，这一输入则已成为了制定云计算开发运营需求框架的关键，所以必须予以征求和考虑。

当然，从企业直属部门获得更多的输入并不意味着要忽视IT部门。由纯粹的用户群运行的云计算项目都是不可能成功的。直线集权型企业用户都必须做好准备，而IT团队亦是如此，后者将帮助实现不同云计算组件之间以及与内部部署应用程序和工具的集成。同样是这样一批专业人士也将把开发运营目标变成为现实。

当建立起一支云计算应用程序部署团队时，其首要任务之一就是建立一个功能性任务，以便于克服IT专业人员根深蒂固从下而上的开发习惯。从推行如何处理业务的指导入手来关注团队，将控制应用程序的部署与集成需求。由此可见，与其他应用程序和数据库进行集成的需求都是由IT团队成员进行开发和支持的。

即便对象集成这样一个第二层次也无法忽视来自于业务的影响。由企业直属部门直接推动的云计算应用程序将随对IT部门外部刺激的变化而变化。请记住，开发运营就是经典的对开发与运营的集成，IT部门能够对此有规划是因为他们正在启动类似项目。早期SaaS的实施经验表明，基于企业直属部门倡议而实施云计算服务的企业都很可能会相当快地把他们的云计算承诺扩展至相邻区域，并期望相邻内部应用程序的处理变得更为灵敏。把所有与新的云计算应用程序接触的应用程序审视一遍并重新检查他们的开发运营流程，这是非常明智的做法。

检查开发运营流程的内容可能是最大的变化。云计算开发运营中的“开发”就是业务流程与IT之间不断发展变化的联系。应用程序的部署实践则更多地依赖于业务流程和目标，所以首要考虑的一点就是部署的功能性影响，例如功能的可用性和与应用程序的集成，它们是业务层面而非技术层面的问题。

后者导致了云计算开发运营项目团队动态中最显著的亮点。在IT用户和IT专业人士之间几乎总是存在着观点上的差异。这种差异归结于“我做什么与它做什么”的独立意识。以往的经验表明，当IT目标过早接管而用户输入丢失时，云计算开发运营项目往往因先天问题而出师不利。

IT关注度太低也是一个问题。尽管直线集权型企业是云计算开发运营这个游戏中的新玩家，但是不要走太多弯路也是很重要的。有趣的是，直线集权型企业似乎在与开发运营相关的活动（包括ALM）中所犯的错误要比他们推动开发或应用程序选择时更多。云计算中的部署和集成是极具高技术性特点的，而直线集权型企业不应在缺乏专业指导的情况下自行实施。

那些已经完成云计算开发运营项目的用户给出了一个小贴士，应加强团队协作。直属部门和IT部门的负责人应当定期召开例会。当出现问题时，还应召开范围更广的团队会议，但是总体而言，IT部门和直属业务部门的成员都应在领导层设定的特定任务框架内进行互动。企业报告说，他们所付出的努力往往由于成员之间的个性冲突而付之流水，而其主要原因就是缺乏有组织的小组会议。在领导层会议中形成小组，设定议程，并确保所有小组会议都有一个明确的议程，同时领导层应承诺坚持按议程召开会议。