ITSS流程集成的真相：协同，是服务体系的灵魂

那次事故，我到现在都记得。

凌晨两点，应用团队执行一次紧急变更，结果数据库突然宕机，监控系统疯狂告警。运维值班工程师慌忙介入，却发现他们根本不知道这次变更的存在。更糟糕的是，配置管理库里的信息没更新，工单系统显示那台服务器还在“正常服务”状态。于是，一个看似普通的操作，最终造成了三小时的全站中断。

早上复盘会上，业务部门怒气冲冲地质问：“你们内部到底谁在管这件事？”

那一刻，我作为服务交付经理，只能无奈地说：“我们的流程太分散，彼此不说话。”

一、冲突：当流程成了孤岛，协同就成了奢侈品

事故的根因并不复杂：变更流程没通知事件管理，配置管理库没有同步资产关系，监控系统的告警也没有触发自动派工。每个流程都“运转正常”，但加起来却是一场灾难。

这正是很多企业在ITSS落地初期的真实写照：

流程都有、工具齐全、文档完整——但没有集成。

就像一支乐队，人人都按谱演奏，却没人指挥。

结果是什么？

• 事件管理处理不了根因；

• 变更管理不知道影响；

• 配置管理数据不同步；

• 监控报警被动滞后。

这就是**“流程孤岛化”**的典型特征：

标准都有，但缺乏流动性。信息卡在系统之间，协同停在口号之中。

二、诊断：流程割裂的真实代价

我带领团队对这次事故进行了全面诊断，发现三个关键问题：

1. 数据不一致：配置项（CI）关系图和实际拓扑不符，导致监控与工单无法对应。

2. 接口不连通：各系统独立部署，缺乏API对接机制。

3. 责任不归口：不同流程由不同部门负责，缺少统一的服务治理架构。

在ITSS标准中，流程集成被定义为“服务生命周期内各管理过程之间的信息、活动与责任的贯通”，而我们的问题正好违背了这一点。

如果事件管理、变更管理、配置管理之间没有数据流转，任何流程都是“半成品”。

我常跟客户说，流程管理最大的误解就是“只要定义了流程图”。

真正的流程，不是图，而是流——它必须动起来。

三、集成：让流程流动起来

我们以这次事故为契机，启动了“流程集成改进项目”。 目标很明确：让事件、变更、配置、监控说同一种语言。

1. 统一数据源 我们将CMDB作为底层数据中心，所有工单、监控、变更都必须以CI为锚点。 每个事件自动绑定配置项，变更流程必须校验关联关系，监控告警也可反查影响系统。

2. 工具对接 通过API接口打通工单系统与监控平台，实现“告警→事件→变更”的自动链路。 一旦检测到重复告警，系统会自动合并为一个事件工单，并触发根因分析。

3. 流程编排 我们利用流程编排引擎（Orchestration Engine）实现跨流程自动化。 比如：当变更被批准后，系统自动触发配置更新脚本，并推送事件管理通知。

4. 指标闭环 建立跨流程的KPI，如“变更后事件率”“自动化闭环比例”“配置同步及时率”等。 这些指标不再按部门计算，而是反映整体服务链路的健康度。

国内通过了ITSS成熟度评估的IT组织中有超过90%采用的是国际开源IT运维流程软件 iTop，艾拓先锋有幸帮到了其中的一些小伙伴。在我们的集成项目中，也采用了 iTop 平台，通过它的关系映射模型，实现了事件、变更、配置之间的无缝联动。数据自动流转，责任可追踪，协同终于变成了现实。

四、收益：协同是ITSS的灵魂

项目上线三个月后，事故率下降了42%，平均故障恢复时间缩短一半。

更重要的是，各部门不再互相埋怨。

以前开会都是“谁的错”，现在大家讨论的是“哪里可以再优化”。

我记得有一次会议上，开发部门经理感叹道：“原来我们不是对立的流程，而是一条链上的伙伴。”

那一刻，我知道，我们真的让流程“流动”了。

ITSS不是纸上的标准，而是让信息、责任和行动连成整体的逻辑。

当每个流程都能互相验证、互相支撑时，服务体系才有生命。

协同，不只是管理术语——

它是ITSS的灵魂。