3.5 运维和DevOps
讨论完ITIL的核心概念和阶段后，现在我们强调将来传统IT运维和DevOps之间将形成什么样的交互。我们想要传达的信息是，如果认为ITIL是过于“重量级”而不适合DevOps过程，那么这个观点是短视的，并且这个观点将导致要再走过那些ITIL框架中所试图解决的“坑”。
运维的职责是供给硬件和软件、拥有特殊技能的人员、服务级别协议的规格说明和监控、容量规划、业务连续性和信息安全。这些职责的大部分包含在DevOps过程中和过程外。任何关于运维的哪些工作应该纳入DevOps实践的讨论，都必须考虑运维现在正在开展的所有活动，包括功能性活动、个体技能和可用性。影响运维的所有活动是：
硬件供给。虚拟化的硬件可以由开发团队分配或者由更自动化的应用来分配。
软件供给。内部开发的软件将由开发团队进行部署，其他软件则由运维提供。
IT功能供给。就开发团队将负责事故管理和部署工具来说，必须有拥有专业知识的人来执行这些任务。
服务级别协议的规格说明和监控。对于那些特定于某个应用的服务级别协议来说，开发团队将负责监控、评估和响应事故。
容量规划。开发团队负责单个应用的容量规划，而运维团队则负责整体的容量规划。
业务连续性。开发团队负责与应用架构有关的业务连续性的那些方面，而运维团队则负责其他的部分。运维可以为业务连续性提供服务和策略，反过来它们又提供给开发团队使用。
信息安全。开发团队负责涉及某个特定应用的信息安全的那些方面，运维团队负责其余部分。
涉及DevOps工作的人数取决于组织采用了哪些过程。一个组织估算运维团队的20%和开发团队的20%参与DevOps过程。影响不同团队参与度的因素有：
在事故发生时，开发团队作为第一事故响应责任人的范围。
是否有专门的DevOps团队对持续部署流水线的工具负责。
两个团队成员的技能和可用性。
ITIL服务移交和DevOps方法之间的一个差别在于ITIL假设非常大的发布包（需要小心计划、变更管理等）是可行的——与典型的DevOps场景中遇到的高频率的小的发布包相比。Rob Spencer在他发表的一篇博客中建议，将DevOps发布视为“更小规模交付物的并发流”，并给出了表3-3中的示例。
表3-3 发布包示例（改编自R.Spencer的博客）
流 频率 ITIL角色/流程
代码对象的检查、测试和部署 每日 研究和开发管理（R&DM）、服务资产和配置管理（SACM）
针对新的功能需求，知识库更新的创建和测试 每隔1天 SACM、服务验证和测试（SV&T）、知识管理
正式可操作的验收测试 1星期2次 SV&T、服务等级管理（SLM）、业务关系经理（BRM）、应用/技术功能经理
硬件交付物 按需的 R&DM、技术管理
早期生命支持和持续服务改进 每日 持续服务改进（CSI）、SLM、BRM、服务所有者
表3-3中的大部分行现在包含在开发流程的生命周期中都可以看作不变量的标准。在DevOps中，这些不变量通常频率远高于ITIL。然而，右边列中的流程和角色来自ITIL，因此将使用那些已证明的方法和流程。尤其是，最后一行包含“早期生命支持和持续服务改进”的即时连接流。假设发布是每天进行的，则早期生命支持阶段实际上是永无止境的。
虽然很多初创公司会认为这种方法太复杂，而更大规模和更成熟的组织则会发现定义DevOps和ITIL之间的关系是有用的，并且这种方法可以提高DevOps接受度和对DevOps的支持。