服务体系设计与运营

服务目录与服务级管理是 ITSM 落地中最见功力、也最决定成败的部分。传统 ITIL 对服务设计过于宽松理论化，是 ITIL 难以落地的关键原因。本节给出经过实战验证的设计方法与运营要点。

一、服务包设计：先归大类

合理的服务层级设计，有助于服务组合管理和服务统计分析。按组织形态，服务包通常有两种设计范式：

集团信息中心：

• 员工 IT 服务
• 基础设施服务
• 网络与系统
• 软件与应用服务

IT 服务商：

• 标准服务
• 增值服务
• 战略大客户服务

先归个大类，适用于 IT 部门规模较大的场景。服务包的粒度以"一眼能说清该找谁"为度。

二、SLA 设计：每项服务至少要有一条 SLA

现代 ITSM 的设计趋势是强化服务、弱化（或对用户隐藏）服务类型。传统 ITIL 理论中的 OLA 部分在现代 ITSM 设计中已被废弃（运营商 OSS 领域则继续沿用）。

一般 IT 运维场景采取统一设计 SLA，不要求每个服务绑定到某个具体 SLA，但有一条强制底线：

每个服务至少要绑定一条 SLA，否则服务无法上线。

这规避了"名义上的服务要么无人执行、要么没有底线"的两大通病。每条 SLA 均应明确响应时限与解决时限，防止无限期拖延。即便设置"480 分钟响应、240 小时解决"，也比没有解决时限要好——因为随着时间变迁，IT 环境变化，可能该服务工单内容早已改变或失效，系统可自动关闭。SLA 同时需要设置默认优先级。

三、服务目录设计：老鸟与菜鸟的分水岭

服务目录设计成功合理，基本上 ITSM 实施项目就成功了三分之一。

3.1 服务类型

下面是一种典型设计（非严格统一标准，可按实际场景自定义，核心要求是各类服务有明确的界限）：

服务类型	描述	典型
请求	高频低风险的服务请求，包含投诉与建议	PC 故障、邮件申请、密码重置
故障	与业务系统故障相关的报障	OA 故障、ERP 报修
事件	对接监控告警，将需人工响应的告警转为事件	监控告警处理
问题	危害严重或高频的工单，尝试寻找根本解决方案	ERP 性能优化
变更	进入生产环境的变更活动（设备部件替换或软件配置修改）	服务器硬盘更换
发布	新 IT 资源由开发测试环境进入生产环境的活动（补丁、新版本、大型硬件上架）	新系统上线
任务	工单协同任务或个人任务	个人事务
安全	与安全应急事件相关的服务流程，更高优先级、更专业团队	网络安全响应、勒索病毒处理
需求	业务需求通道，由业务需求分析师或产品经理团队支持	CRM 新需求

3.2 服务属性

服务属性	设计描述	必填性
是否关联配置	是否允许根据配置项来提交工单	选填
是否关联应用系统	是否允许根据业务系统来提交工单	选填
交付方式	现场服务、远程服务、驻场服务、其他	必填
服务包	建议将服务纳入其中一个服务包	必填
默认紧急程度	根据服务内容及概率确定	必填
默认影响范围	根据服务内容及概率确定	必填
默认服务团队	每项服务必须有支撑团队	必填
默认 SLA	每项服务必须绑定 SLA	必填
服务图标	用于方便视觉区分服务	选填
服务描述	方便用户了解服务详细内容	选填

除上述强制策略外，还有两个关键设计：

• 服务负责人：该服务经理在服务出现 SLA 告警或超低评价时接收告警信息；
• 服务范围：公共服务一般用于组织全局范围；专属服务用于非全局用户的服务。

3.3 服务精细化设计

服务名称定义要清晰。 服务名称要通俗易懂、接地气、一目了然，且一般不建议与服务类型同名；服务描述是必要的，主动传递服务对象范围等信息，减少不必要的工作。

正面示例：

• 服务名称：PC 故障——主要面向个人电脑用户的一般故障，例如配件故障、网络中断等问题；
• 服务名称：Email 密码重置——本服务受理公司邮箱密码重置事项，需提供员工工号等必要信息。

反面示例：

• 服务名称：业务问题——服务描述：无。

服务范围设计： 不要涵盖超大范围的服务（例如"全部业务系统服务"——没有细分到系统，容易造成多个支持团队职责不明）；也无须细分到令人发指（例如"OA 导航栏报错修复"——会导致 IT 服务数量暴涨）。除公共服务外，其他服务均纳入服务合同管理，确保服务实际执行范围可控。

3.4 服务自动化

• 自动分发：系统根据服务合同设定，自动分发至支持团队工程师；
• 自动关闭：标记为已解决后，用户与服务台均未选择关闭工单，系统自动关闭并设置中等评价——通过合理的设计尽量避免服务台的非必要干预；
• 自动预警：对低评分工单自动通知服务台值班与服务经理。

3.5 多渠道接入与统一入口

多服务渠道接入：Web、呼叫中心、App、微信小程序、钉钉、监控告警。对互联网组织，侧重年轻人常见的提交方式；对传统用户群体，注重呼叫中心等提交方式。

统一入口：统一从服务目录作为工单发起。最终用户只看到服务目录提交；系统自主根据服务目录确定服务类型，自主根据服务流程确定工单后续处理逻辑。

入口设计好不好，采和科技运维团队归纳为"简、准、智、快、兼"五字原则：

• 简：从用户侧看，入口操作步骤少、界面直白，把学习成本降到最低；
• 准：用户在入口能准确找到自己要的服务，不靠猜、不靠问；
• 智：高频问题尽量由自助服务与自动化承接，AI 机器人先做一轮引导，常见故障自动派单甚至自动关闭，减少人工干预；
• 快：从 IT 侧看，入口要便于监控工单分布、处理效率与数据统计，不能只讨好用户、把麻烦全留给服务台；
• 兼：办公区内与区外、桌面端与移动端、工作日与节假日，入口都要稳定可达。

常见入口方式各有取舍，按用户结构与业务紧急度组合使用，而非押注单一渠道：

入口方式	优势	局限	适用场景
Web 自助服务目录	信息完整、可挂附件与知识条目、全程留痕、边际成本低	需主动登录，移动端体验偏弱	办公场景下的标准请求与报修
呼叫中心（电话）	最贴近传统用户习惯，紧急故障可直达，口头沟通效率高	人力成本高、通话不易留痕检索、高峰期占线	传统办公群体、重大紧急故障
移动 App / 企业 IM（微信、钉钉等）	贴近日常办公路径、推送直达、上手几乎零成本	消息易被淹没、工单格式不规范，需与工单系统双向打通	年轻化团队、移动办公与值班通知
邮件	异步提交、天然留痕、可抄送相关方	分类困难、易漏单、SLA 计时不直观	非紧急咨询、跨部门协同
监控告警自动接入	7×24 无人值守、告警及时转事件工单、处理结果可回写告警源	依赖告警过滤规则，误报会产生大量无效工单	基础设施与业务系统的监控联动

入口组合没有标准答案，按业务类型、用户年龄结构与办公环境确定主渠道与备选渠道；上线后依据各入口的使用量、处理效率与满意度反馈定期调整，而不是一次设定长期不变。

3.6 服务团队层级设计

每个服务支持层级的单个团队不要超过 10 人，建议 27 人。按"一线 + 二线 + 三线"层级设计，一个服务背后支撑团队工程师至少可容纳 2030 人，完全满足中小型服务团队不超过 10 人的要求：

服务名称	一线支持团队	二线支持团队	三线支持团队
PC 故障	L1TA	L2TA	L3TA

对集团型公共 IT 服务，可进一步扩展：

服务名称	一线支持团队	二线支持团队	三线支持团队
PC 故障	L1TA、L1TB、L1TC	L2TA、L2TB	L3TA

通过合理的多级服务团队设计，可支撑更多工程师，且保证每个小团队职责清晰。

3.7 目录的组织逻辑：按实际服务平铺，而非照本宣科

3.1 的九类服务划分是系统内部的语义底座，用于后台判定流程与 SLA，并不是给用户看的菜单。ITIL 原生分类（请求、故障、事件、问题……）本质是技术思维：用户分不清自己提的是"故障"还是"问题"，即便有经验的工程师也时常含糊。

实战中的服务目录应当按实际开展的运维服务来组织，用用户语言平铺展开：

• 前台目录面向用户，按"PC 故障""邮箱密码重置""新员工开机账号"这类真实服务项陈列，层级尽量扁平，不搞多级嵌套；
• 后台语义留给系统：用户提交后，由系统依据服务属性自动判定服务类型、分发团队、匹配 SLA（见 3.5 统一入口）；
• 命名与描述直白到技术人员与普通用户都能一眼看懂，每项服务落实默认团队与默认 SLA，审批与分发路径按服务风险等级设定，而不是全目录一刀切。

判断一份目录是否接地气，最简单的办法是让一线用户挑单：他能不查字典、不问服务台就找到自己要的那一项，目录就算设计对了。

3.8 开通前的预调配与预管控

服务目录不是列完名称就上线。一项服务正式开放提交之前，资源与管控参数必须先到位，否则工单量一上来必然失控：

• 预调配：按服务的专业方向与预估工作量先定好支撑团队；按预估用户规模提前规划人力与 SLA 资源比例，避免用户量波动时响应质量跳水；
• 预管控：把响应、预警、解决时间与次数限制一次设好；对搁置、转派、回退设定明确的次数上限；明确是否需要审批、审批层级与规范——这些参数在服务设计阶段一次性配好，比工单积压后再补规则有效得多。

反面案例并不少见：某在线教育企业设计课程播放系统的运维服务目录时，响应与解决时间未设、转派与搁置未做规范。上课高峰期学员集中反馈播放卡顿，工单随即失控——工程师随意搁置、无限转派，问题久拖不决，直接影响学员体验与续费。目录设计流于形式、管控参数近乎为零，事后再堆技术手段与业务规则，往往事倍功半。

四、服务实施：合同、配置与参数

服务合同是服务关系的承载体，是 ITIL v4 服务价值链生效的基础。 除公共服务外，服务均纳入服务合同管理；供应商合同管理供应商的服务承诺。服务配置包含全局配置、工单设置、邮件收发、呼叫中心等初始设定；通过对处理节点的必要告警设置，提升服务团队响应效率，确保 IT 服务水平。

参数设定（绝对加分项）：服务参数需支持无需编码的网页配置，方便快速适应运维环境变化，方便服务经理随时调整服务运营后台参数。

五、服务运营：工单、值班、巡检、告警、考核

5.1 工单管理

工单管理流程是 ITSM 的核心流程。常见的工单操作及设计要点：

操作	描述	频率
新建	用户新建或服务台工程师新建	高
审批	用户方审批 + 服务方审批（可选）	低
指派	手工指派	低
解决	工程师处理工单	高
评价	用户或服务台才有权评价工单	高
关闭	关闭工单	低
搁置	设为搁置，SLA 停止计时，通知团队负责人和服务经理	低
取消搁置	SLA 继续计时，通知团队负责人和服务经理	低
备注	随时添加备注，备注通知工程师	低
撤销	待审批/待指派中的工单可撤销，通知服务经理与用户部门管理员	低
转派	仅支持组内转派，转派次数有限制	低
回退	回退到服务台	低
编辑	后台编辑，通知用户和服务经理	低
转知识	成功的经验可以复制沉淀	低
升级	服务合同已设定可升级时支持升级	低

5.2 值班管理

选择团队、选择团队成员填入，即完成值班组配置。值班安排与节假日、SLA 统计联动，是服务连续性的基础。

5.3 巡检管理

巡检是信息中心的日常任务。常见巡检计划制定流程：选择巡检设备后要与巡检指标关联。如能通过监控工具自动采集部分巡检指标值，是加分项。

5.4 告警管理

大规模监控告警信息过滤，是 ITSM 集成监控工具非常有挑战性的一环。通过合理的过滤规则，将告警转到合适的事件工单，并将处理进度和结果同步给告警来源，形成监控-事件闭环。

5.5 考核管理

考核兼顾客观统计与主观评分，支持设置自定义评分指标，并可设定考核权重。主观反馈（满意度积分统计）与客观数据（SLA 响应/超时统计）结合，避免单一口径的片面性。

5.6 服务台大屏：当班视角的两类信息

服务台的工作视图（值班大屏）设计要同时回答两个问题：现在正在发生什么，以及近期趋势往哪走。

实时态势（及时性）：

• 最新工单流：实时获取最新提交的运维工单，不让新单在队列里沉底；
• 最新 SLA 告警：哪里即将超时、哪里已经超时，第一时间感知；
• 待关注工单：临近 SLA 边界、近期评价偏低的工单单列出来，防止个别低分拉低整体服务评价。

历史汇总（趋势判断）： 在实时视图之外，按四个维度回看服务统计，据此判断运维走向：

维度	看什么
服务类型	哪类服务工单在涨，是请求堆积还是故障增多
业务系统	哪个业务系统的工单集中暴露，是否需要立项治理
团队绩效	哪个团队响应慢、积压多，人力是否需要再平衡
SLA 数值	响应与超时的整体水位，SLA 设定是否脱离实际

实时视图管"当班不出事"，四维度趋势管"下周怎么调"；后者与第六章的定期报告分析互补——大屏解决当班调度，报告解决阶段改进。

六、服务优化：报告、分析与改进

6.1 重点服务统计对象

对象	分析角度
服务经理	从服务运营角度分析
业务经理	从业务系统角度分析
运维经理	从服务团队角度分析
客户用户	从服务发起部门角度分析
工程师	从技术管理角度分析

6.2 常见分析切入点

1. 用户主观反馈分析：满意度积分统计；
2. 系统客观统计数值分析：SLA 时间统计（响应 / 超时）。

典型分析视图包括：服务分析（色块面积代表工单数量，服务经理可钻取到子服务）、业务系统运维服务分析（从业务系统角度纵览运维工单概况）、工单深度分析（饼图比例代表各工单属性占比）、客户分析（基于服务方组织提供运维统计视图）。

6.3 服务改进

服务改进要回答两个问题：改进什么（数据暴露的高频、超时、低分、积压）与如何改进（流程调整、团队调整、自动化加深、知识沉淀）。改进的依据是运营数据，不是直觉。

七、售后服务：项目生命周期的延续

实施上线不是终点。典型的售后服务体系：

一般技术支持：

• 业务咨询（ITILDesk 产品相关、IT 运维相关）；支持方式：微信、电话、邮件；SLA：30 分钟内响应、24 小时内答复；
• 定期巡检（系统运行状态、数据库运行状态）；支持方式：上门；周期视服务合同（每月/每季/每年）；
• 故障排除（系统运行故障、数据库维护故障）；支持方式：网络或上门；SLA：15 分钟响应、5 个工作日内解决。

新需求二次开发： 新需求分析 → 确认设计方案（供应商和业主方均确认）→ 编码测试（技术编码、系统集成；开发环境测试、模拟上线测试）→ 上线部署（上线方案、模拟上线成功、上线部署）。

系统升级改造： 视具体项目而定，需要双方协商共同完成。

小结：服务体系设计的成败，集中在三件事——服务目录是否贴合用户语言、每项服务是否有团队与 SLA 兜底、流程是否足够简化。运营则靠数据说话：工单操作留痕、SLA 跟踪、巡检与告警联动、考核多口径并行，最终落到持续改进。