家乐福的 Jira Service Management 落地实践

家乐福（以下简称家乐福）作为传统零售业外企，从前端到后端、从基础架构到应用，服务于各个业务部门的系统大大小小超过 50 多个，涉及到前端销售链路、供应链链路再到后端的财务系统、人事管理系统等等。

我们为何选择 Jira Service Management？

和大多数首次使用 Jira 的用户一样，我们最早购买和使用的是 Jira Software，目的是通过 Jira 来构建统一的项目管理和任务管理平台。在具体使用上，我们主要是从项目维度出发，将不同的项目进行分类，然后再根据不同项目类型用类似瀑布式项目管理模式和敏捷 Scrum 的模式在 Jira 上开展项目任务的管理。

对于传统企业的 IT 部门而言，应用和项目只是其中的一部分工作。在 IT 服务管理方面，我们想根据 ITIL 的框架来搭建与 IT 服务相关的一系列流程、其中包括：IT Service Management、Incident Management、Problem Management 等等。由于我们之前已经有了自己的事件管理工具，而那个工具不太具备扩展性从而实现服务管理和其他若干模块的能力延伸，因此我们把视线放到了 Jira Service Management 上。Jira Software + Jira Service Desk 产品结合的好处显而易见，与运维和开发相关的一些内容可以自然而然地打通，处理运维问题的支持团队甚至能看到这个问题是由哪个版本的哪个开发任务造成的，以及是谁来解决和负责这个任务。

但理想总是比较美好的，我们碰到的实际问题是由于外部供应商开发居多，而真正的开发过程的任务管理和测试管理都是在他们各自的平台完成的。要强制要求供应商使用我们统一的平台固然是一个办法，但也需要大量人力配合和时间。因此，我们第一步还是采取分而治之的方式。

Service Request 的设计

通过初步的服务梳理，我们根据实际的工作组将 IT 服务分为以下几个大类：

• Infrastructure Request

• Application Request

• Security Event Report

• Data Request

这里，我们在 Jira ServiceDesk 中通常有两种处理办法。一是只创建一个整体的 service 项目把这些相关的 request type 通过分组进行统筹管理，然后为每一种类型的 request type 定义各自的工作流来满足相应的要求。二是针对每个大的工作组单独创建项目，项目内可以更加细致的定义各个子类的 request type 和不同的工作流。

在评估了当前各组的工作实际情况后，我们认为单是 Infrastructure 里就有很多不同的 request type，因此需要定义很多不同的 issue type，但过细的维度也会相应加大管理难度。因此，我们选择分别创建 4 个 service project 的形式。

虽然是 4 个不同的项目，但是 Jira Service Management 提供了一个统一的 portal 入口。如此一来，前台的用户看到的只是 4 个父级菜单，而后台人员则是登录各自的项目进行运维操作，后期的管理工作也就变得容易多了。

Jira Software 与 Jira Service Management

通过网上交流，我们还发现有些其他同行在没有 Service Desk 的情况下用 Jira Software 基于本身自定义的 issue type、customize field、screen 以及很灵活的 workflow 也能实现基本的表单提交和工作流程审批功能。

从实际使用者的角度，我想分享一下这两个组件在实现上的不同，或者更突出地讲讲 Jira Service Management 基于 Jira Software 之上有哪些非常棒的新特性：

1. Jira Service Management 提供默认的 IT service desk 模板 — 在选择创建一个 Service Desk 类型的项目时，我们能看到 Jira Service Management 提供了一个 IT Service Desk 项目类型。如果你不知道都有哪些 IT service 你应该提供服务的话，那从这里开始也是一个不错的选择：

2. 访问权限 — 我们知道 Jira 是按用户数来计算 license 的，因此开放 Service Desk 给用户应该至少覆盖整个企业的内部员工，而很多场景下我们不想他们占用 Jira 的用户数量，但同时又允许他们提交 request。

Jira Service Management 项目支持不同的客户权限类型。我们可以灵活的配置不同的项目，哪些是对于全网路开放的，哪些是对全企业开放的，还有哪些是需要特定 Jira 权限账号才能使用的。我们购买了 50 个 Jira Service Management Clients，但可以服务于 800 名左右的用户：

3. 通过接收邮件就能开单 — 很多用户如果连 Jira Software 的 portal 页面都访问不了，他们还能直接通过发邮件的形式开单，同时也能通过邮件接收到工单更新的回馈以及用户满意度调查的相关邮件。可以说，用户完全不需要登录 Jira Software 也能实现对工单的简单处理：

4. 节点审批 — 这是购买 Jira Service Management 之后对工作流引擎的一个加强。它可以针对节点进行更便捷的审批人或审批组的配置：

5. 自动处理 ticket — 我们知道，很多请求服务单是需要提出人来关闭的，但往往他们在事情得到解决后并不会主动再打开系统去关闭这些 ticket。那么我们就可以通过这个 Automation 的功能定义一些当触发了特定条件就会自动更新 ticket 的操作。

默认情况下，系统就已提供了这个标准的三个工作日已解决的工单自动关闭规则，你要做的就是启用它即可：

 心得和总结

•  总体来说，Jira Service Management 可以通过简单配置直接支持标准 ITIL 框架中的 Service Management 和 Incident Management。

•  关于 SLA 的部分，我们由于是内部运维，因此没有硬性要求，但是 Jira Service Management 提供的功能还是很完善的。

•  如果搭配 Confluence 一起使用的话，那就能在服务支持的同时增加 knowledge base 功能。也就是，将 knowledge 在 Confluence 中进行添加管理，并和 ticket 直接关联。

•  Jira 自带的开发 API 接口非常实用，和其他系统对接的需求能够非常方便地实现。拿我们自己的实例来说，通过 Splunk 收集日志安全事件，识别出来的安全事件随后就会自动在 Jira 中创建事件。这个工作只需要两边通过简单的接口调用就能完成。