DEVOPS 运维开发系列一：ITIL服务目录管理流程的设计与信息化管理系统功能的开发

ITIL是世界范围内公认的运维服务管理的最佳实践。ITIL的理论落地，不需要什么信息系统的支持，使用word文件、Excel表格一样可以对ITIL的十几个关键管理流程做到很好的落地。虽然是这么讲，但现在用人成本这么贵，任哪个公司也不会愿意为这些服务流程的落地设计出一大堆的角色和职位的吧，再说的手动维护这些工作流程，效率那么低，谁都不能把标准和规范坚持到底。时间一长，全部荒废。

因此，ITIL服务流程的实现上面，一定要结合使用DEVOPS技术，用信息化的方法提高运维服务流程的运转效率，用信息化、自动化的方法监控、发现和报警运维服务管理中存在的问题，结合使用信息化系统和运维自动化、批量化运维方面的技术，实现运维工作的平台化操作和服务流程的规范化。减少运维工程师手动维护各种管理表格的痛点，因为手动的方式也维护不准确，在服务器和应用数量快速增长的背景下，也会失控。

本文先以ITIL的服务目录管理流程进行展开，提供了该流程的ITIL流程设计、信息化系统建模以及DEVOPS运维开发功能的展示。

1、服务目录管理的目标

• 就所有约定的服务提供一个一致的信息源；
• 确保具有访问权限的人都可以使用这些信息；
• 确保服务目录已生成并得到维护；
• 已包含所有在运营的服务以及准备投入运营的服务的准确信息。

2、服务目录管理的范围

共包括6个活动：

• 定义服务
• 生成并维护一个准确的服务目录
• 服务目录与服务组合之间的接口、依赖性、一致性
• 服务目录与CMS中所有服务与支持性服务之间的接口和依赖性
• 服务目录与CMS中所有服务、支持性组件和配置项CI之间的接口和依赖性
• 结合业务关系管理和服务级别管理来确保信息与业务和业务流程保持一致

3、对业务的价值

• 提供了一个关于IT服务的中心信息源。
• 确保业务的各个方面都可以查看IT服务其详细信息和状态的准确、一致描述。
• 包含一个面向客户的视图，内含有关正在使用的IT服务适用的使用方式、支持的业务流程以及客户可以预期的每一项服务的级别和质量。

4、服务目录设计原则

• 通常需要一个服务层次结构（业务服务目录->技术服务目录）；
• 其中每一项服务都具有确定和约定的服务级别以及受影响客户的联系方式；
• 将每一项服务都定义为一个配置项CI，并适时将这些服务相关联以形成一个服务层次结构。

5、服务目录设计维度

（1）业务服务目录（客户视角）

• 交付给客户的所有IT服务
  
• 这些服务与业务部门和依赖于这些IT服务的业务流程之间的关系

（2）技术服务目录

• 交付给客户的所有IT服务
• 这些服务与支持性服务、共享服务、组件和CI之间的关系
• 为业务服务目录提供支持，但要注意避免成为客户视图的一部分

6、服务目录过程管理中的风险

• 目录中的数据不准确，也没有严格的变更控制
• 服务目录的接受度低，接入管理的应用少
• 缺少适用的信息维护工具或资源
• 信息太过详细难以准确维护，或太笼统而没有价值

7、服务目录管理信息系统的设计与开发

7.1 数据库的库表结构设计

（1）“服务”有哪些属性

• 服务名称【列表页属性】
• 关联应用程序（在本业务服务内共包含多少应用程序的实例）【列表页属性】
• 产品线【列表页属性】
• 机房（单机房、暂不考虑跨机房定义服务）【列表页属性】
• 使用方式【详情页属性】
• 服务范围【详情页属性】
• 关联业务部门【详情页属性】
• 关联业务流程【详情页属性】
• 投诉反馈【详情页属性】
• 备注【详情页属性】
• 服务级别协议（SLA）【详情页属性】
• 运营级别协议（OLA）【详情页属性】

注：列表页属性，表示该属性字段会出现在服务目录列表页面，同时这个属性也会在服务详情页面上展示。标注为详情页属性的，表示仅会展示在服务的详情页面中。

（2）需要通过元数据进行定义和维护的信息

• 关联的应用程序
  
• 机房
  
• 产品线
  
• SLA与OLA级别协议

（3）SLA与OLA级别协议需要有哪些属性

• 协议名称
• 关联服务
• 协议类别（SLA、OLA）
• 优先级
• 客户
• 服务等级描述
• 维护人
• 更新时间
• 生效时间
• 失效时间
• 是否需要故障通知
• 是否需要故障报告
• 是否需要服务报告
• 是否会索赔
• 备注

7.2 服务管理的完整设计与成品展示

一个完整的运维服务管理，需要至少包含以下5个管理功能：

• 产品管理
• 服务目录
• 服务级别管理
• 应用列表
• 作业管理

7.3 产品管理

产品管理功能的实现效果如下图所示。

大部分公司，包括产品设计、研发、测试、运维、运营等工作内容，都是基于产品线来对业务进行管理的。所以我们在这需将“产品”作为一种元数据信息进行维护，提供该信息项的增、删、改管理功能。

在这里定义和维护的“产品”信息，将作为下面的服务管理、服务级别协议管理的一项关键属性数据。

7.4 服务目录

这里谈到的“服务目录”专指从业务角度定义和理解的一个重要概念，而不是等同于应用程序级别的技术服务目录，如下图所示。

（1）查看服务目录

从上图的列表信息中，可以看到一个“服务”，属于哪个产品线，该“服务”中包含了多少个应用程序实例，“服务”部署于哪个机房。如果点击服务名称，则会进入查看服务详情页面。

点击应用数量列的数字，会打开一个应用程序的列表页，展示该服务所包含的是具体哪些应用程序。如下图所示：

注：这里在设计和实现应用程序的管理功能时，针对应用程序的发布上线做了很多设计和实现。

（2）添加新服务

（3）编辑服务的管理信息

（4）查看服务的详细信息

从上图中红色标出来的部分，可以看到，在查看一个服务的详情时，在页面上会动态展示出该服务相关的服务级别协议条款，分为面向客户的SLA和面向内部服务团队管理的OLA。

点击某一个服务级别协议的名称，会进入该协议的详情页面，如下图所示：

7.5 服务级别管理

（1）查看服务级别协议的列表

（2）同样为服务级别协议提供了增、删、改的功能

其中下图红色标出的属性是采取的与已有、已定义的管理信息建立的关联关系。这样处理后，更有利于运维服务管理的规范化和标准化，也方便在上图中按这几个关键属性对服务级别协议进行过滤展示。

7.6 应用列表

这里谈到的“应用列表”，实际上就是服务目录中的技术服务目录的概念，是业务服务目录在技术实现与系统部署上的落地结果。

我们所有的产品或服务，从技术角度去理解，都需要对应到一些具体的应用程序上去。这些程序会有机房、主机、服务、产品、部署路径、IP地址等众多的管理属性信息，还需要对应用程序做版本控制、发布、回退管理。

在为本文所谈的是“服务目录”管理流程，所以这里不对应用程序的版本控制、发布、回退做进一步的展开讨论。

下图为应用发布管理的管理页面展示：