导读：
由于数字化转型，技术已经嵌入到公司所依赖的每一个业务流程和实践中。是时候接受DevOps的建议，重新思考业务与IT的划分了。
每一年都会有人预言“某某已死”。SaaS风火热炒的那几年，有人说，SaaS已死，但似乎并没有。那么，在如今数字化转型盛行的当下，又会有什么被认为“已死”的呢？
近期，国外一家大型全球IT服务公司的高级管理和IT顾问 Bob Lewis 就认为在当下IT即业务的做法已死，取而代之的则是能帮助企业更好、更高效运作的 BusOps。为什么这样说？BusOps 是什么？它又能带来哪些好处？带着这些问题，我们一起来学习一下。
要在数字时代取得成功，必须重新定义IT项目，以交付业务更改，而不仅仅是交付信息技术。但在这背后隐藏着一个更根本的转变：IT操作应该嵌入到业务操作中，就像IT应用程序应该嵌入到实现业务的更改中一样。
在许多组织中，IT的运行方式就好像它是一个独立的业务（为内部客户提供服务）一样。不幸的是，这样做会给IT部门的应用程序和操作方面带来障碍。
部分原因是IT即业务（IT-as-a-business）的比喻导致了一种奇怪的实践：IT操作与其内部客户之间的协商服务水平协议(SLA)。
在实际的IT外包术语中，SLA是一个由两部分组成的度量标准。第一部分是最低可接受的服务标准。第二部分列举了外包商达到这种服务水平的频率。
定义度量的第一部分通常很简单。然而，第二部分则更有趣。例如，SLA可能将一次停机的最大可接受标准定义为恢复服务之前的一个小时或更少。度量的后半部分可能指定外包商必须达到99%的服务水平。
如果外包商未能满足其SLA，那么，合同将指定补救措施，这也是一个需要协商的问题。如果内部IT应该表现得像一个独立的业务，那么还有什么比它与内部客户协商SLA更合乎逻辑的呢？
事实证明，答案是：许多替代方案更符合逻辑。
创新性的挑战
鉴于很多原因，内部SLA从来都不是一个好主意。首先，它们强化了错误的IT/业务关系模型——将IT即业务的观念销售给内部客户。
第二是差异的后果：如果IT未能达成协商的SLA，它的“客户”会怎么做？没有非性能惩罚的SLA是无效的，而带有非性能惩罚的SLA则导致组织间的不信任。
第三，你得到了你所衡量的东西。在大多数情况下，这意味着IT衡量的是服务水平，但缺乏任何衡量创新的标准。
运行良好的IT操作不断地在可靠性和创新之间取得平衡。但创新需要风险。因为SLA回顾过去，它们只报告创新的负面后果，而不是创新的好处。
我们以固态硬盘的初始转换为例。它们的短期可靠性和长期耐用性，对于早期用户来说，还没有得到证实。然而，他们为那些尝试使用它们的组织带来了丰厚的回报，使它们在分析和大数据方面获得了性能优势。
所以，保持领先需要一些冒险和前瞻性思维，而SLA天生就不鼓励这样做。
反对SLA的案例
IT通常承担两种类型的职责：技术服务和支持服务。
技术服务的SLA涉及系统可用性和性能等事项。问题是，以前，高可用性架构是一种选择。而现在他们则不是。
既然如此，IT是否应该继续追踪技术服务的服务水平呢？答案是肯定的，因为如果它做得不是很好，但只是作为一种工追踪工具，那么，这将是浪费时间。
因为虽然某个设备可能会出现故障，但这已不再是系统不能正常工作的原因。这就是高可用性架构的本质。如果一个系统曾经不可用，那应该是一个非常罕见的事件，因此，保持统计跟踪是浪费时间。
不会浪费时间是根本原因分析，因为每次停机都意味着您的高可用性架构有一个需要修复的设计缺陷。同样不浪费时间的是分析已报告的事件，以便在新出现的问题对整个业务造成影响之前及早发现并解决它们。
从另一方面来看，支持服务是IT人员帮助业务操作人员的工作。支持服务SLA涉及的问题包括：在帮助台响应他们的请求之前，某人应该预期等待多长时间，以及在问题解决之前，他们应该预期等待多长时间。
在任何一天，对于任何给定的呼叫，帮助台的响应要么比服务级别指定的更快要么更慢。当帮助台人员的容量超过呼叫量时，它的响应速度更快。相应的，当呼叫量超过服务台人员的能力时，它的响应速度会变慢。
因此，SLA与性能无关。它只是一根棍子，对敲打帮助台经理很有用，除此之外别无它用。
唯一真正重要的是预算季节，此时帮助台的服务水平可以用来证明雇佣更多员工的合理性。
公平地说，这不是一件小事。但是它证明了跟踪服务性能而不是协商SLA的做法是正确的。
唯一重要的IT操作度量
对于大多数管理人员来说，成功会提高他们的知名度，从而获得晋升、荣誉和更好的薪酬。而IT操作惟一可见的时候是出现问题的时候。
所有好的度量标准都是定性目标的数值表示。因此，最能反映其目标的IT操作度量是对其不可见性的度量。这个“不可见性指数”应该是一个复合度量，它包含应用程序可用性和性能、对帮助台的调用数量(更少的调用意味着更多的不可见性)以及反映IT操作性能在其他领域的业务流程和实践中成为瓶颈的频率。
典型的IT组织被划分为应用和操作、应用程序和运维，这些组织通常由于两个主要原因而互不信任。首先，应用程序通过应用的更改获得成功，但是每个应用更改都会增加运维可见性的风险。其次，应用程序需要运维来创建和维护开发和测试环境。所以，对于应用程序而言，这意味着运维是一个瓶颈。对于运维来说，这意味着要进行额外的工作，而且常常是计划外的工作。
而此时DevOps便登场了。与大多数敏捷变体不同，在DevOps中，开发团队包括一个或多个IT运维人员，他们在项目的时间表上协作处理IT运维职责，而不是通过运维请求队列。
所有这一切都是在说，当两个必须一起工作的团队之间出现摩擦或不信任时，在每个团队的起源下创建人员和流程的协作混合是一个有价值的解决方案。
数字化转型和BusOps的到来
如今，对于大多数组织来说，数字化转型是管理的主旋律。但又有哪一种管理潮流比数字化转型更令人困惑和模糊呢？
在所有这些含糊不清的背后，是创造新功能的特定数字技术。企业可以利用它们来创造竞争优势。或者，他们可以忽略它们，让竞争对手获得优势。
在这些细节背后是核心的数字现实：信息技术不再是可选的。它深深地嵌入到每一个业务流程和实践中，您的公司依靠它来进行日常业务。因此，从概念上讲，IT操作只是整个业务操作中许多活动部分的一个集合，这使得IT操作与CIO一样都是COO的职责范围。
在此之前，作为一个实际的问题，我们应该考虑到，无论在哪里，IT操作都应该保持完整。它的有效性(以及随之而来的不可见性)取决于许多技术熟练的专家——成熟和发展良好的学科的实践者——的持续合作。
而管理他们负责的过程和实践反过来又依赖于了解他们内部的负责人。领导他们取决于管理者在处理他们的职责时能够理解这些实践者。
同样值得注意的是，重组很少会修复任何东西。多数情况下，他们通过将以前不能很好地协同工作的团队置于共同管理之下来消除障碍，这也意味着大多数重组会在曾经有共同管理但现在不再有共同管理的团队之间制造障碍。
将IT操作移到组织结构图中，以便IT部门能够向COO报告，这与让IT保持原样的逻辑差不多。至于重组IT业务，将其拆分并在业务中分配职责则是行不通的。因为，毕竟技术人员一起解决共同的问题仍然有价值。
那么，需要改变什么呢？DevOps指出了方向。DevOps协作文化必须扩展到IT操作和其他业务操作之间的关系，就像希望更好地运行业务的业务经理和IT应用程序之间的关系一样。
所以解放你的服务台员工。由于没有SLA将他们束缚在椅子上，您可以鼓励他们起身去拜访有问题的人，了解他们面临的挑战是什么，并为他们如何利用现有技术提供见解。
同时，在IT部门的运维方面，敏捷性需要修正，这也是因为没有所谓的IT项目：目前实践的敏捷仍然关注于交付产品，而不是协作交付有策划的业务变更。当您在修复敏捷时，可以通过添加DevOps维度(在业务更改项目团队中包含系统和安全管理员)来进一步修复敏捷。如此一来，您的项目将有更好的结果，并且对业务领域中重要内容的额外了解将使IT操作在日常决策中更加有效。
最后，让我们引入一个新术语使它更为正式吧。正如DevOps是IT应用程序和IT运维的融合和协作一样，BusOps是IT操作和业务操作的融合和协作。
根据孙子兵法的说法，战争永远都是为了人心。而新事物占取人心的方式通常从创造新词汇开始。通过添加新的词汇，其结果可能会达到意料之外的效果。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
