IT就像沙拉酱，有时你需要把它拌匀

原文作者：美国惠普知名博主Paul Muller

制作沙拉酱的一个简单要领是需要厨师忽略化学规律，让几乎是风马牛不相及的两种物质油和醋充分融合。而让两种原料充分融合的唯一方法就是用力搅拌，哪怕是在没有外部能量的情况下这两种原料彼此分离时也要继续搅拌。

CIO的角色跟那样一位大厨师没什么不同。将最新的Web2.0应用系统快速地、有效地和可靠地投入到市场需要在资深专业技能人员之中做一个很好的平衡。这个说起来容易做起来难，特别是当他们的行为更多地关注在满足团队的即时需求时，而不是最终结果时。真正的挑战是在没有一个能把这些东西调和到最和谐状态的“大厨师”和让他们保持这样的系统，功能性上的与团队保持一致反而更容易让他们分裂成各自的“部落”- 就像油和醋一样 – 搞得一塌糊涂。

一个针对IT的系统上的方法

我们不能容许这个情况继续下去。根据业内专家评估，所有的资本项目中有超过95%是依赖于IT的，大部分跟我聊过的IT领导者发现他们碰到了一个创新瓶颈，这阻止了他们按时交付新项目。将还在计划炉中的项目推上线成产品，这种压力往往是无法承受的。

通过系统迫使项目加快，这些项目中三个里面会有两个因为与预期的结果不符而提交失败。本质原因常常是因为很差的需求文档记录、对安全和质量（QA）流程的忽略，和一个被豁免考虑其他组织机构而独立运行所有项目需求的运营小组。

我们需要表现得更好，并且我相信这可以从打破管理、研发、QA和运营职能之间的silo开始。

我想一些人可能会想，“哈！亚当·斯密（经济学家）不是教我们给劳动者分工来生产一桶针比给一组多面手自己生产全部产品更加有效吗？”是的，我不是建议你们的研发小组应该自己规划、建立和支持每个应用系统，那我还不如建议一个丰田工作者自己组装一部车。

我的意思是，就像丰田的生产系统一样，意识到IT交付是个系统是很重要的。系统的上游活动和下游活动对产品有非常大的影响，所以我们需要一个与目标、工具和KPI紧密相关的方法来把我们的团队调动整合到一起，而不是分开。

DevOps动向

这不是一个新问题，但却变得愈加困难。过去二十年里我花了很多时间帮助企业机构转型，主要是通过把所有IT利益相关者组织到一起来寻找一个一致的流程、工具和测量系统。从服务管理和itSMF（IT服务管理论坛）开始，随后是管理、安全和应用交付，我发现每个小组都有自己专门的系统来处理自己的问题，并且在很大程度上和其他小组的需求是断开的。

好消息是一些基础运动工作正在把IT中的各“部落”聚合在一起，并且带来低成本、高质量和更好的一致性的机会来清除项目中的积压工作。通过务实的标准和技术创新，比如基于模型的动画、丰富的平台和云服务，我相信IT领导者有一个职业定义的机会，通过改变他们思考应用和服务生命周期的方式来为21世纪的IT交付做一个转型。

迄今为止声音最大的小组要数DevOps动向。首先，由Patrick Debois创造的DevOps动向和理论旨在认可和撰写研发者、QA与运营团队的做法和工作流程，用来促进为高质量的应用更快地建立和自动化部署。

出生于网络运营世界的比如像Flickr, Kaching (现在叫Wealthfront), Netflix和比他们大的表兄弟们，DevOps采取了一个针对IT交付的系统思维方法，包括一个服务的全部生命周期。最给力的是DevOps承认大多数的IT项目永远不会“完成”，而是一直在连续变化的状态，这也是您常常听到连续交付的原因之一，敏捷性和DevOps也常常被相提并论。在丰田生产系统的提示里和在Eric Reis的书《精益创业》（The Lean Startup）中，您甚至可以听到精益IT可以增添良好的措施这个措辞。

打破现实世界中的Silo

一个很好的打破silo的成功案例是一位客户同时也是朋友向我展示的，这个朋友是一家一流医疗保险供应商系统管理部的领导。在他从事IT的20年中，他曾经担任研发和运营的领导。可以很公平地说，他不知道的关于建立和监测关键任务、综合应用程序方面的事情是很少的。

最近他分享了他是如何能够使生产事故的发生数量减少90%。更妙的是，当问题发生时，跟过去相比他现在只需一半数量的员工和五分之一的时间来隔离和解决问题。

他分享了三个我认为对他来说可操作的理论：

• 运营在需求里是有发言权的 – 应用程序的支持性很重要的一点是它是非功能性需求的一部分。运营团队位于形成这些需求的最佳位置。
• 应用研发和QA应该是运营扩大的一部分 – 这有助于针对故障隔离和诊断建立一个真实世界中使用案例的共同认知。
• 在这两者之间建立共同的工具 – 在他的案例中，他主要关注常见的综合交易和负载生成器、诊断和配置管理工具。这不仅阻碍了他的研发和运营团队在工具上增加了一倍，并且基本上做的是同样的事情，而且可以促进一个研发和运营之间的共同的纽带来填补之前的间隙和隔阂。

您得到了您所审查的

是什么让DevOps成为这么强大的理念，是因为它为运营进入研发和需求的流程带来了声音。它承认并且正规化了研发者作为一个运营客户的需求。并且最重要的是，它预测了高速度和高变化的企业，我相信会那会是IT界新标准。然而，通过艰辛的道路我学到了“您得到您所审查的，而不是您所期望的”- 把两个通过差异来定义他们自己的团队混在一起需要比新工具和流程更多的东西。IT领导者需要建立KPI来推动跨部门和功能性IT团队内部的正确行为，比如，查找那些管理已经失效的未经授权的更改。

如果您还没有查看DevOps，我建议您现在就开始。然而，作为一个基层动向值得注意的是，DevOps社区要警惕厂商错误使用这个术语，如何讲起DevOps这个话题本身就是一个非常激烈的讨论，来自Gartner公司的Cameron Haight为我们提供了一个非常棒的客观总结。每个人都认同的是建立一个DevOps模型不是一个问题，可以通过工具单独解决， 这是个让我全心全意认可的理念。

如果您有这方面的经验，无论是正面的还是负面的，把研发、QA和运营聚集在一起，我肯定每个人都希望听到更多。如果没有其他的，这是令人深思的！

原文链接：http://www.enterprisecioforum.com/en/blogs/paulm/it-salad-dressing-sometimes-you-need-shake-it