DevOps与ITIL 5融合，构建可扩展的企业运营体系
企业如何在快速发布数字产品的同时，不丧失对服务质量的掌控？
答案始于团队协作方式的改变。DevOps通过共享所有权、自动化和快速反馈，将开发与运维连接起来。ITIL 5则为管理数字产品及其全生命周期的服务提供了更广泛的架构。
ITIL 5更加聚焦于数字产品和服务的管理。它将产品开发、交付、运维、支持、治理和改进整合在一个系统中。DevOps则提供了使该系统运转所需的工作习惯和技术流程。
其结果是从一个想法到可靠用户体验的清晰路径。
交接问题
许多公司仍将工作划分为独立的阶段。产品团队定义需求。开发人员编写代码。运维团队维持系统运行。支持团队处理用户问题。
每个角色都有其存在的合理价值。问题开始于工作在没有共享指标或共享背景的情况下从一个组传递给另一个组时。
产品团队可能要求一个新功能。开发团队可能按规格交付该功能。随后，运维团队可能会发现该功能带来了负载或支持风险。用户将最终结果视为一项服务，但公司却将其作为几个互不相连的任务来管理。
这导致了延迟和返工。它也掩盖了技术工作与业务价值之间的联系。
DevOps通过将开发和运维带入同一个交付流程来缩小这一差距。ITIL 5为这一流程提供了管理结构。产品团队因此可以加入同一系统，而不是将工作移交到一个独立的技术队列中。
关键问题从“团队是否完成了任务？”转变为“服务是否为改善用户而提升？”
从想法到服务的单一价值流
价值流描述了工作如何从需求转化为有用的结果。在数字运营中，这条路径可能包括发现、设计、构建、测试、发布、支持和改进。
DevOps通过自动化将这些步骤连接起来。持续集成管道会在代码变更时进行检查。自动化测试尽早发现缺陷。安全检查在同一工作流内运行。交付工具将经过批准的变更通过受控环境进行传递。
这并没有消除治理。它只是将治理移到了流程之中。
一次发布可能需要基于风险、服务影响或测试证据的批准。低风险变更可以通过简单的自动化路径。高风险变更可能需要更深入的审查。规则是明确的，因为交付系统记录了决策。
ITIL 5有助于定义这一流程的目的。其指导原则使工作专注于价值。治理设定边界。价值链链接创建、交付和支持数字服务的活动。持续改进将运营反馈转化为下一组变更。
这种结构对于启用AI的产品至关重要。新的推荐模型、搜索功能或自动化规则可能会改变用户行为和系统需求。发布过程必须同时考虑性能、安全性、可靠性和用户体验。
可靠性成为产品开发的一部分
可靠性通常由运维负责。这造成了微弱的反馈循环。开发人员可能在报告撰写后才会看到故障事件。产品团队可能只能通过滞后的业务审查来了解服务问题。
站点可靠性工程（SRE）通过将可靠性量化来改变这种模式。服务可以使用可用性、搜索速度、播放成功率或推荐新鲜度的目标。这些目标被称为服务级别目标（SLO）。
SLO将广泛的担忧转化为可操作信号。团队可以询问服务是否满足了定义的用户需求。他们还可以将交付速度与服务风险进行比较。
错误预算支持这一决策。错误预算代表SLO所允许的不可靠程度。当服务表现符合目标时，团队有空间发布变更。当故障消耗掉该配额时，稳定性工作优先。
这为产品、工程和运维团队创造了共同的语言。产品决策包含服务影响。工程决策包含弹性。运维数据塑造未来的设计。
可观测性加强了这一循环。日志、指标、追踪和用户体验信号展示了发布后发生的情况。这些信号可以揭示缓慢的请求、失败的事务、糟糕的模型响应或仅限于特定客户组的问题。
自动化随后可以支持安全的行动。系统可以扩展资源、重定向流量、禁用功能标志或回滚发布。这些行动需要明确的规则和测试。没有边界的自动化可能会更快地传播故障。
目标是可控的学习。每次发布都提供有关服务在实际条件下行为表现的证据。这些证据反馈给下一个产品和工程决策。
一个小例子
考虑一个添加了新推荐模型的音乐服务。
产品团队希望改善发现功能。工程师构建模型并准备发布。运维团队确定了运行所需的计算资源和监控。
在互不关联的流程中，该模型可能会一次性向所有用户推出。随后会出现支持工单或突然的性能下降等问题。
在集成的流程中，该模型首先在类生产环境中运行。自动化检查会审查其代码、安全性、延迟和资源使用情况。功能标志将其释放给有限的群体。可观测性跟踪推荐的新鲜度、请求速度、错误率和服务可用性。
团队还定义了响应路径。如果模型导致请求变慢或服务信号不佳，标志将关闭或发布回滚。现有服务继续运行。
ITIL 5提供了管理框架。该变更支持产品目标。治理设定发布控制。运维支持在线服务。持续改进利用结果来塑造下一次变更。
DevOps提供了交付机制。管道、测试、功能标志、监控和回滚将工作连接起来。
没有一个团队单独拥有整个结果的所有权。是这个系统拥有。
这种模式带来的变化
DevOps与ITIL 5的融合并不意味着每个流程都变得自动化。它意味着团队将工作作为一个互联的价值流进行管理。
这改变了几个日常习惯：
- 产品团队在规划中包含可靠性和支持需求。
- 开发人员将生产信号视为设计输入。
- 运维团队更早介入，在发布决策确定之前。
- 治理使用风险和证据，而不是默认依赖缓慢的审批。
- 支持数据到达构建和管理服务的团队。
- 改进工作遵循实时系统行为。
这种模式也暴露了弱点。即使手动交接阻止了每次发布，管道也可能被称为“持续”。监控仪表板可能显示基础设施健康状况，但忽略用户体验。事故流程可能恢复服务，而未解决导致故障的设计选择。
一个有用的测试很简单：追溯一项变更从其原始需求到生产结果的整个过程。注意信息停止流动的地方。这一点通常显示出产品、DevOps和服务管理需要更好整合的位置。
实际的启示是选择一个交接点并用共享证据将其连接起来。产品需求可以包含SLO。发布管道可以包含支持检查。事故审查可以创建一个具有明确负责人的产品待办事项。
这种小连接使价值流可见。它还给了团队一个共同的学习场所。
EuroOp LLC将此视为核心的应用研发模式：可靠的数字产品是在构建、运营和改进发生在同一反馈系统中时涌现出来的。EuroOp Insights在每期内容中都承载着同样的承诺：一个应用研发模式和一个来自EuroOp产品背后管道的实用要点。