通过 Charles T. Betz 和 Christoph Goldenstern
你必须生活在岩石下，才会错过最近敏捷和DevOps对所有IT事物的影响。从初创企业到地球上最大的企业，敏捷和相关技术正在改变IT的规划、构建、交付和运营方式。
这种转变对IT服务管理专业人士和他们的首选框架--ITIL意味着什么？ 很多。DevOps已经以意想不到的方式改变了对话。例如，长期以来，人们认为变化是稳定的敌人，因此，企业选择了不频繁的、"精心策划 "的发布--这似乎从来没有那么好的效果。
然后，DevOps出现了。在2009年期间，"Flickr一天10次部署 "是第一声集结号。当然，它的系统一定在不断崩溃？不，他们没有。当持续交付被很好地理解并正确执行时，系统的稳定性就会提高。 只有硅谷的初创公司才会这样做，对吗？2016年9月期间，巴克莱银行表示，其800个敏捷应用团队部署的频率越高，其服务就越稳定。在所有的规模中，很明显，对复杂系统的较小的、更多的增量变化是较低的风险，并促进稳定性。 此外，这些小的、渐进的变化的快速反馈，使得基于测试假设的新的学习文化通过将（用精益创业术语）最小可行产品快速带给客户。
发生了什么，这对成熟的企业与初创的组织来说意味着什么？理解敏捷和DevOps的影响的一种方法是通过扩展或 "出现 "模型。 诸如ITIL和COBIT等框架的问题在于，它们是在企业范围内提出的。该框架可能指出，它应该适应特定企业的需求；但具体如何做到这一点，往往是留给顾问的。对大型企业有用的东西，对初创企业可能没有意义。Verne Harnish在《扩大规模》一书中指出，在某些规模的公司中存在着自然的集群。
- 1-3名员工
- 8-12名员工
- 40-70名员工
- 350-500名员工
- 2,500-3,500名员工
缩放过程可以帮助我们理解目前业界的辩论，比如 "DevOps与ITIL"。从这些方面来考虑IT流程。你会为一个10人的公司推荐一个全面的变革管理流程吗？你能在没有流程的情况下经营一家3000人的公司吗？在什么时候你会引入一个，为什么？你还会在什么时候引入其他什么流程？
敏捷在小范围内运作良好。它是以团队为导向的，各种规模的公司都越来越意识到，合作的团队是产生价值的地方。完善的研究表明，协作型文化优于所有其他文化（包括竞争型文化）。一个10人的公司是一个团队，但一个50人的公司必须把自己看作是一个 "团队的团队"。问题是我们如何为所有这些团队提供 "胶水"，使我们不至于失去一致性。我们越是 "松散耦合"（用Spotify的工程文化术语来说），我们就越需要用共同的方法来 "紧密结合"，以促进合作和解决问题。
这似乎是显而易见的，但随着公司规模的扩大，模式一直是根据功能来进行专业化。
- 市场营销
- 研究与开发
- 销售
- 业务和服务
- 后台办公室（财务、人力资源、IT）
此外，每个职能部门都有分专业（例如，IT部门进一步专业为应用和基础设施团队；基础设施团队专业为服务器、存储、网络、24 x 7 NOC，等等）。
无论是在与企业的关系上，还是在内部，IT部门都将自己组织成一个 "接单者"。例如，应用团队向基础设施团队提交所需资源的 "票据"。这种模式可以产生相当稳定的IT系统和服务，但它们往往交付缓慢，变化缓慢。功能上的孤岛与端到端的流程思维是常态，这有点讽刺，因为这不是ITIL等框架所倡导的。
今天，数字化转型正在挑战和颠覆孤岛。随着面向市场的产品包含越来越多的信息技术，"后台 "IT与研发、一般运营和服务相融合。现在，IT对公司的生存至关重要，它被要求对市场需求有更多的反应。稳定性仍然是需要的，但不能满足快速变化的市场需求的稳定系统是没有价值的。
功能性筒仓需要交接。交接会导致延迟和反应迟缓。职能部门往往会对他们所服务的团队形成一种 "我们对他们 "的态度，并向他们要求提供服务。这就是为什么敏捷方法提倡多技能的团队：正如Marty Cagan在他那本有影响力的书中所说。 受到启发。如何创造顾客喜爱的产品。 团队至少需要能够推动产品实现三个必要的品质。
- 它有价值吗？
- 它是可用的吗？
- 这是否可行？
一个能够推动与这三个维度一致的结果的团队可以被称为 "全栈"。Scrum和其他敏捷方法反复强调，团队必须能够在总体上独立运作，尽量减少外部的依赖和阻碍。
目前的另一种做法是 "你建立它，你运行它"。这是一个很好的做法，与过去 "把它扔到墙上就跑 "的做法相比，是一个很大的变化，当时开发人员对编写真正能在生产中运行的软件几乎没有责任。从本质上讲，重点从垂直的IT "工厂模式 "转移到更多的 "水平管理 "方法。在这种情况下，团队有端到端的责任，包括一些更传统的ITIL学科的事件和问题管理。
正如亚马逊首席技术官维尔纳-沃格尔斯（Werner Vogels）的名言："无论从客户还是从技术的角度来看，赋予开发人员操作职责都极大地提高了服务的质量"。现在，开发人员越来越多地 "戴上传呼机"，并被激励编写稳定、可扩展和运行良好的软件，此外，还要满足用户对功能的期望。
ITIL何去何从？
这些基于团队的方法已被证明非常有效，这就是为什么世界各地的组织，无论大小，都在急于采用敏捷和DevOps。
然而，在 "团队中的团队"，大型组织层面，沟通和协作必须跨越团队。我们可以尽量减少这种沟通的需要，但在某些时候，你怎么知道两个变化不会发生碰撞？协调和同步活动的跨团队过程，需要迅速集中在对操作至关重要的关键信息上，这些信息提供了一个最小的，但必不可少的质量检查（例如，事件或问题声明）。
一个跨团队的共同问题解决方法，消除了事件、问题和变化管理之间的一些障碍。当每个人都 "使用相同的问题解决和执行语言 "时，它可以最大限度地减少无效或重复活动的 "死时间"，并改善数据的使用和共享方式。
变化管理t
由于ITIL长期以来一直倡导严格的变更流程，它已经成为许多敏捷和DevOps倡导者的一个障碍。然而，减缓变化的吞吐量（ITIL变化管理倾向于这样做）并没有与系统的稳定性相关联。
现在，对ITIL来说是公平的，对一个应用或服务的持续更新，其平台总体上是稳定的，被看作是不需要讨论或批准的 "标准 "变化。在ITIL中没有任何东西阻止这一点。然而，在很多组织中，现实情况是通过使用一到两周的变更控制周期来 "让开发者等待"。
当运营工程师负责对生产进行所需的变更时，变更延迟可能是由于过程中的工作太多，而不是由于缺乏跨团队的同步（例如使用双周变更审批委员会会议来评估风险）。然而，随着越来越多的团队在 "你制造，你运行 "的基础上运作，让运营部门实施生产变更被认为是不增值的。即使是经常被引用的 "职责分离 "问题也已经消失了。(见DevOps审计防御工具包，由DevOps传教士Gene Kim和IT审计师James DeLuccia共同编写）。
超越变革管理
除了变革管理，敏捷和DevOps团队如何体验ITIL？管理运营的团队，包括服务台功能和24x7中心（这是两种不同的服务），倾向于采用ITIL培训和术语，并让服务团队作为功能孤岛运作。
人们用这样的评论来为这些孤岛辩护："我们没有足够的人手给每个开发团队配备自己的运营人员或基础设施工程师！"但这错过了现代基于云的DevOps实践的重点，也忽略了IT服务管理的重要方面。ITIL提倡建立服务目录，这通常被用来 "前端 "基础设施服务。从历史上看，服务请求管理流程支持这些服务，通常是手工作业（例如，工程师分析一些新服务器的请求）。
云和微服务方法正在改变服务请求管理的面貌，它具有一致的、基于目录的前端和完全自动化的服务。除了具有高度自动化的服务目录，亚马逊或Azure云门户是什么？自助服务和自动化增强了功能团队的能力，并将基础设施团队从大多数按需咨询和工程服务中解放出来，这样他们就可以专注于建立和维持一个共享的自助服务基础设施。
向企业规模迈进
当敏捷思维被带入真正的企业规模时会发生什么？除了需要 "团队中的团队 "的协调，还有风险管理、治理等方面的问题。业务连续性、问题管理和重大事件响应成为关键问题。Kepner-Tregoe认为，特别是重大事件管理，需要专门的技能，帮助确保企业免受灾难性的破坏和损失。当重大故障发生时，这种 "止血能力 "要求专家既要有出色的解决问题的能力，又要有促进和沟通的能力，因为自然的高压环境和大量的利益相关者需要满足。
此外，在这个快速发展的环境中，企业不能再继续解决同样的老问题。将敏捷和DevOps原则引入到一个有着无法解决的积压问题（因此，事件量不断增加）的组织中是一种冒险的尝试。为了使敏捷和DevOps取得成功，企业需要开始认真对待问题管理，并投入资源来寻找问题的根源。将问题管理反馈到团队积压中，与新的用户 "故事 "一样，是一种新兴的最佳实践。
反过来说，扩大规模的一个风险是当组织实施了如此多的流程，以至于所有重要的团队经验被破坏了。多个流程更多的是由管理/文件的需求驱动，而不是其产出的价值，这可能会阻碍团队的交付，他们的凝聚力和交付客户价值的能力会下降。这种性能下降也是一个企业风险，可能是扩大规模的最大风险。
综上所述
ITSM实践为新的Agile/DevOps世界提供了很多东西。它们提供了一种围绕语言和成熟实践的一致性。服务目录、变更、事件和问题管理都是相关的。然而，企业应该防止将ITSM作为强调结构和流程而非服务结果的理由，从而失去ITIL等框架的一些原意。长期以来，以服务为中心的用户结果的方法一直是ITSM理念的一部分，而保持这种关注并有能力应用 "快速质量思维 "的服务经理将继续做得很好。在一天结束的时候，所有的事情都是关于客户体验的，以及他们每天遇到你的数字系统时在质量和稳定性方面的真实时刻。
关于Kepner-Tregoe
Kepner-Tregoe是问题解决的领导者。六十多年来，Kepner-Tregoe通过更有效的根本原因分析和决策技能，帮助全球数以千计的组织解决了数百万个问题。Kepner-Tregoe与各组织合作，通过以下方式大大降低了成本并提高了运营绩效
解决问题的培训、技术和咨询服务。