ITIL-服务运营（SO）

Posted 2021-01-22

一、服务运营（SO）的概述

1、从某种意义上，我们平时的工作、个人商铺的生存、企业的生存等等，都是提供某种服务，只是这个服务范围、服务的质量等等有差异

 而服务运营就是ITIL，对企业中IT部门对外提供服务的一个指导方针。具体的包括两大部分，一、职能（服务台、一线、二线、三线）二、流程（事件流程、事故流程、问题流程、请求实现流程、访问控制流程）

2、那服务运营要实现怎么样的目标或者说要达到怎么样的目的呢

就是按照与客户约定的SLA（服务级别协议）的标准，来完成服务的交付和服务的管理

3、什么是服务，以及怎么样的服务算好服务

我们平时听服务两个字听的最多的就是酒店，那为什么酒店会有三星级酒店、四星级酒店、五星级酒店，这个评价酒店星级的衡量标准是什么
是不同星级的酒店提供的服务多少么，当然是一个衡量指标，但是不是根本的，如果一个酒店提供了很多服务，但是都是一些让人感觉很糟糕的服务，这样我们会说这个酒店的服务水平好么

那什么是服务，服务的本质是什么呢。

服务本质上是对用户负责，是对事情的结果负责，就像五星级酒店提供的不同的服务，但同时提供的服务的质量也是有保障的，这样我们就觉得很贴心

而这个服务质量就是SLA,而这在IT于业务部门之间就是一种承诺，也是靠这个一种承诺，来体现IT的价值，从而证明了提供的是一种好的服务

二、SO中平衡的艺术

虽然我们提供的是一种服务，但是我们要对所有服务都有求必应，满足所有的服务请求么

结合我们自己实际的工作，如果我们真的这样做了，这样的服务肯定不会是一种好的服务，同样的道理，找女朋友，如果她提的什么要求，你都满足她，只能说明你们两个的地位太不平等，不可能很幸福的生活在一起

那应该怎么办的，一方面要我们提供一种好的服务，另一方面又要有所保留

这个就要求学会一种平衡之道

具体来说就是要学会在做加法与减法的过程中，保持一种平衡，最好的这是一种动态平衡，就像两个人在一起，不要天天腻在一起，也不要长期分开

而这种平衡在ITIL的SO阶段，要学会的是

a、IT也业务的平衡（我自己现在的工作是，我是属于外包组，加入蚂蚁金服的，然后做的工作是提供给客户阿里云和蚂蚁金融云的产品的售后问题支持，那这个平衡就是，在尽量满足用户的前提下，也要学会拒绝有些IT没有实现的需求，这个就是一种灰度思维）
b、稳定和响应的平衡（不要过分追求稳定也不要过于积极的响应）
c、质量和成本的平衡（既要提供质量好的产品，也要综合成本的考量）
d、主动和被动的平衡（提供服务要主动，但不能过于主动，还是举个追女孩子的例子，要主动去追，但不要在一开始暴露太多）

三、SO的原则

1、最核心的原则就是一个“提供好的服务”

那怎么样算好的服务呢？

以我自己现在售后一线的工作来说，主要就是

a、应答及时（回复）
b、回答专业（专业精神）
c、不断学习（谦虚精神，敬畏，空杯心态，接纳，学习，兼容并包）

而这全部概况起来就是两点，一、沟通能力 二、技术能力

那怎么样的沟通能力，是一种好的沟通能力

我们平时经常说有效沟通，而这有效沟通，指的就是用双方可以理解的语言进行沟通，这样的沟通才可算一种有效的沟通

又怎么样的技术能力，是一种好的技术能力

技术不是用来炫耀的，技术最大的价值，就是用技术解决现实中实际的问题，而如果你能用你的技术能力，解决大部分人解决不了的问题，那证明了你的稀缺性和你的价值，从而也体现了你有优先的技术能力

2、而另外两个支撑核心原则的原则就是“沟通原则”和“文档积累（技术沉淀）”

---

其实从更大的角度来考虑，我们个人的成长就是要具备这两个核心能力，一是沟通能力，二是个人的核心竞争力。而这就是吴军老师说的两条腿，而也只有有了两条腿，我们才能跑的更快，更远

四、SO职能

上面讲了ITIL中SO服务运营的作用是提供服务的一个过程和一些原则

那具体在提供服务过程中，由哪些人来提供服务呢，以及怎么样完成在服务提供的过程中完成人员的变换

具体的人主要分为这样四大类：
1、服务台（IT部门和用户的之间的一个接口）
2、一线（IT运营管理）：主要是负责一些相对技术要求不那么高的问题
3、二线（技术管理）：要求技术实力比较深入
4、三线（应用管理）：厂商变更了啊，要做应用的支持

那具体这样四大类人其对应的职能是什么呢，负责怎么样的事物管理

服务台（前端业务的一个接口）：用户与企业的一个接口
一线（IT运营管理）:日常的巡检、更新、文档、预定义的事故的处理，而这核心要给可以的一种体验就是，他是享受到了我的服务的，他是被服务的
二线（技术管理）：这类人一般都是T字型人才，可以处理复杂的事故，提供相应的技术方案
三线：（应用管理）：有些涉及到原厂的，问二线也解决不了的问题，就需要问三线

五、服务台

之前讲了服务提供过程中，处于不同环节的人，现在我们就讲讲第一环节，服务提供者与服务获得者之间的一道桥梁--服务台

1、大家想过没有什么会有服务台这样一个存在

举个简单的例子，我们去医院看病，是不是会有导诊台，那如果没有导诊台，我们要挂什么科，挂了号要到哪里去看病，等等问题，我们是不是会感觉很无助；再举个例子，现在公司一般都有行政前台，而前台的作用，基本就是服务台的作用，像我们平时要去公司面试，那她一般就会带我们去相应的面试地址参加面试等等，生活中有很多这样的例子

现在我们可以总结为什么要有服务台的存在了

a、方便用户和内部的联系
b、可以过滤一些无效信息（在提供服务的SO阶段，就是过滤不是服务请求的请求）
c、处理与用户之间的沟通

2、那有了服务台，服务台到底可以提供哪些服务呢

a、既然服务台是用户跟IT部门的一个接口，那IT部门提供的服务好不好，用户满不满意，服务台一般都是最先知道的，并把消息及时反馈给后端同学，而这用相对术语一些的话来说，就是监控服务级别协议SLA的执行情况
b、及时把用户反馈的问题，提交后端，以及后端处理完成后，对工单的关闭
c、提供系统管理报告（就是记录用户系统的情况，以及后端同学对系统管理的执行情况）
d、接受、记录、分级和追踪客户的服务情况（过滤）
e、有时服务台还承担一线的工作
f、解决不了的问题或者是需要二线支持的问题，及时协调二线和三线支持
g、及时通知客户其请求的当前状态和最新进展（提供问题的最新进展和最新情况）

---

（乍一看服务台的工作压力不小）

3、那服务台的是怎么演变的呢

一般一开始服务台就是一个电话受理中心（call center）主要接受用户的请求
慢慢的问题见的多了，也知道相应的处理办法了，服务台由原来的（call center）成长为（help desk），主要一方面接受用户的请求，另一方面处理一些日常的一般性的问题，而再成长就是成长为（service desk）变成服务中心，可以接受服务情况，处理一般性问题和处理复杂性问题

4、服务台的信息路由，看不同的问题，去协调对应的人去解决

5、刚才也说了，服务台要做很多事，那怎么衡量这个事情做的好不好，有没有什么价值呢，这就涉及到服务台的度量指标

度量指标必须切合实际（可以量化），也像我们制定自己的工作计划、学习计划，等等要可以落地，而不是只能在天上飘

那具体有哪些可以切合实际的度量指标来考核我们服务台的呢

a、一线问题解决率（用的比较多）
b、解决事故的平均时间
c、升级事故的平均时间
d、处理事故平均成本
e、平均回顾和关闭解决的时间
f、客户的满意度（用的比较多）

6、刚才也说了服务台要处理一大堆杂事，那这个可不可以请外包团队呢

 答案是肯定的，但是要注意几点事项

     a、对服务台提供的活动和服务的责任不能外购（就是对结果负责）
     b、外购要考虑的，是不是涉及到跨很多部门
     c、维护端到端的服务管理控制（还是对结果负责）
           通用的工具和流程
                 SLA的目标
                 沟通
                 数据的所有权

7、服务台内部的人员组成 一般分为两种，一种是服务台经理（一线经理）另外一种服务台的处理人员

8、既然服务台那么重要，服务台是企业与用户沟通的一个桥梁、接口
那么服务台关键的成功因素有哪些

        主要有以下几点：

        a、理解业务需求
        b、理解客户需求
        -----------------------------
        这两点综合一下就是理解客户的意思![](http://i2.51cto.com/images/blog/201811/25/6758cd09d8aebb929e71173cce74c328.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
        c、对服务台团队人员的培训
        d、服务级别是实际有效、协商一致和有规律的
        e、其提供的服务可以被老板和业务部门所接受，所认可

六、IT运营管理（一线）

刚才讲了服务台及其作用，以及考核和度量还是关键的成功因素
现在我们来讲讲服务台后面的一环，IT运营管理，俗称一线

1、那一线要做哪些事呢

a、执行组织的日常运营活动（一般都是预定义的）
b、主要工作包括：
i、运营的控制：监控和控制IT基础设施中的事件和运营活动（控制台的管理、工作的调度、备份的恢复、性能的维护活动等）
ii、设备的维护：管理物理的IT环境（数据中心、恢复中心、供电系统、空调系统啊，等等）

2、那一线人员是外采还是内建呢

主要从以下几个方面去考量：

a、外采和内建的成本
b、灵活性的考量
c、业务的角度，跟业务联系的紧不紧密

七、技术管理（二线）

刚才讲了服务台和一线，现在我们讲讲二线

1、二线在我们工作的过程中主要做哪些事情呢

 提供技术专家意见，负责IT基础设施的技术管理
 这一块主要包括两部分：
     i、复杂事故的处理
     ii、解决方案的设计和架构的编写

2、那二线平时在我们工作过程中一般是怎么样的角色的人呢

 技术牛人

3、为什么要有二线的存在呢，或者说二线存在的意义和目标是什么

 1、赋能一线
     2、处理复杂的事故
     3、解决方案的设计
     4、技术架构的设计

八、应用管理（三线）

九、SO流程

上面讲了提供服务过程的涉及到哪些人，那这些人之间怎么协同工作呢

这就涉及到了流程管理，而ITIL中SO运营管理主要包括五大流程：事件管理流程、事故管理流程、问题管理流程、请求实现流程和访问管理流程

下面我们就来详细聊聊ITIL中关于SO服务运营过程中有关流程

十、事件管理流程

1、要谈事件管理流程，那我们先谈一谈什么是事件

事件主要指两点 一、可被检测或者辨别 二、对IT基础架构级IT服务交付产生了影响，满足这两点就可被称为事件

2、那聊完了事件，那我们事件管理的要达到的目标是什么呢

a、检测和感知事件，并确定对应的控制行动
b、自动启动其他流程，作为服务运营流程的切入点

说白了，就是要让已发生的、未发生的事件，可控，可被管理

3、那事件管理所管理的范围是如何定义的呢

 一般包括如下几项：配置项、环境条件、软件许可监控、安全、正常活动

4、那如何进行事件管理呢

 一般平时我们工作中，主要通过监视工具来帮助我们进行事件的管理
     当然这一般从主动和被动两个方面来进行管理，主动一般是人，被动一般是工作支撑

5、那事件管理到底有什么价值呢

a、事故的早期检测，就是把事故扼杀在摇篮里

b、实时和自动异常报告

c、主动恢复（发现问题，自动处理，进行恢复）

d、集成到服务管理

6、那事件管理的流程到底长什么样子呢

具体可参看附件图片

简单的说，事件管理主要是对“信息”、“告警”、“异常”进行处理

7、那事件管理在具体的执行过程中，有哪些挑战呢

a、监控平台的部署和使用

b、合理、正确的过滤级别的设定

c、对工具使用人员的培训，成本比较高

d、在没有设置运维流程的情况下，部署事件管理工具

十一、事故管理流程

1、刚才我们讲了事件管理流程，现在我们来聊聊事故管理流程，这个流程在ITIL服务运营流程管理中是个重要的流程

那我们先来聊聊-事故管理流程的概述

2、什么是事故，事故是怎么定义的

  IT服务的无计划中断或者IT服务质量的降低，都可以被称为事故

3、那什么是事故管理

 事故管理流程，就是管理所有事故生命周期的流程

4、事故管理的目标和目的是什么

   而事故管理的目标和目的是，尽快的恢复正常服务的运营（as soon as possible）

5、事故的范围是什么

    来自服务台或通过事件管理接口的、中断或者可能中断服务的任何事件，来自技术员工的

6、事故管理的价值是什么

     那事故管理了创造的价值是什么
     a、检测和解决事故的能力，减少业务停机时间，支持服务的高可用性
     b、事故管理包括确定业务的优先级和按需分配资源，可以将IT活动与实时业务优先级对齐
     c、确定服务可能的改进
     d、服务台可以在处理事故的过程中，确定额外的服务或者培训需求

7、刚才介绍了事故、事故管理、事故管理的目标和目的、事故管理的范围、事故管理的价值，现在我们来聊聊事故管理中的原则和一些基本概念

 原则主要从以下几个方面去考虑：
     a、时间范围（SLA服务水平（企业对用户的承诺）、OLA（IT部门和IT部门的协议）、UC（和供应商之间的协议）） 
          而具体的时间范围主要包括两部分：响应时间和解决时间
     b、事故的处理模型
           处理事故的步骤
                 步骤的先后顺序
                 负责人
                 时间限制
                 升级流程
                 所有保留证据的活动（截图和备份）
        c、重大事故
             单独的流程，优先级高，时间范围短
                 需要映射到整体事故优先级系统中
        d、临时措施（临时的解决办法）
        e、变更请求（就是临时办法解决不了事故了，必须要请求变更解决了，采取的变更措施）

8、事故管理流程

 简单的讲主要是如下几步：
 输入--》记录（事故的鉴定、日志的记录、问题的分类）--》确定优先级--》诊断--》升级--》关闭

     而对应我自己的工作中就是

     输入--》1、判断是不是我们的工单 2、是不是特殊流程工单  --》确定优先级 --》诊断、处理 --》处理不了、升级 --》工单的关闭

9、那事故的记录和分类要记录那些事情和如何做分类呢

a、事故的记录：详细的、包含事故状态的、使用工具的支持
b、事故的分类：分类的编码规则、按级别分类

10、那事故的优先级要怎么确定呢

主要从以下两个方面去考量：事故的紧急程度和事故的影响程度

对于事情优先级的考虑
影响度
高 中 低
紧 高 1 2 3
急 中 2 3 4
度 低 3 4 5

优先级 描述 解决时间
1 critical 1h
2 high 8h
3 medium 24h
4 low 48h
5 planning planned

对于紧急程度的考虑
紧急度 重要程度
核心 一般
时间 业务 1 2
非业务 2 3

对影响程度的考虑
影响度 事故程度
中断 下降
范围 全局 1 2
局部 2 3

11、事故的升级

a、升级
如果某个事故在规定的时间内不能由一线支持小组解决，需要更多有经验的和更高权限的人员参与进来
可能发生在事故解决过程的任何时间和任何支持级别
b、升级的方式
职能型升级（functional escalation）--》技术
结构型升级（hierarchical escalation）--》管理
c、职能型升级的流程 一线—》二线—》三线（技术的排查）
d、结构型升级（时间的考虑）（站在公司的角度）

12、事故的关闭

a、事故关闭由服务台负责
b、检查内容
核实分类并修正
用户满意度调查
事故文档
是否记录问题
正式关闭

13、事故管理流程与其他流程的关系

a、跟问题管理流程的关系（问题的根本原因）
b、跟配置管理流程的关系（IT基础架构的逻辑关系配置图）
c、跟变更管理流程的关系（调整）
d、跟能力（容量）管理流程的关系（性能）
e、可用性管理（正常提供服务的时间占总时间的比值、减少宕机）
f、服务级别管理关系（承诺）

14、事故管理的挑战

a、 挑战一：如何尽早的发现事故
解决办法：事件管理一定要做好（做好预防和通知）
b、 挑战二：要求技术人员同用户一样记录所有事故，并鼓励用户使用web平台来完成，解决办法：知识库（技术人员）、引导（用户）
c、 挑战三：问题与已知错误信息的有效性 解决办法：文档管理
d、 挑战四：与配置管理系统的集成 解决办法：及时更新配置管理
e、 挑战五：与服务级别管理流程的集成（提升事故处理的满意度，对业务部门的承诺）
解决办法：SLA（IT和业务之间正式的承诺）
UC（跟供应商的关系）
OLA（IT部门跟IT部门）

15、事故经理与考核

a、事故经理角色的职责
i、 推动事故管理流程的有效性和高效性
ii、 管理事故支持团队
iii、 监控事故管理的效果，并提供改进建议
iv、 开发和维护事故管理系统及流程
vi、 管理重大事故
b、 关键度量指标
i、 事故总数
ii、 事故不同状态的明细（open，closed。。。）
iii、 当前未完成事故总数
iv、 重大事故数目和比例
vi、 平均解决时间，按优先级排序
vii、 按SLA解决事故的百分比
viii、 每个事故的成本
viiii、 重开的事故数目
viiiii一线事故的解决率

十二、问题管理流程

1、 什么是问题

         一个或多个事故的原因

2、什么是问题管理

 负责管理所有问题生命周期的流程

3、 问题管理的目标

   消除引起事件的深层根源以防止事故再次发生

4、 业务价值

   a、   与事故管理、变更管理流程一起，保证IT服务的可用性和质量提高
   b、   额外价值
    IT服务的高可用性
   业务与IT团队的高生产力
   减少因为临时解决方案的开支
   减少救火和重复解决事故的成本

5、 问题管理

   a、   被动问题管理（reactive）
    找出导致以前的事故发生的根本原因
    提出解决措施或纠正意见
   b、   主动问题管理（proactive）
    通过找到基础设施中的薄弱环节来阻止事故的再次发生
    提出消除这些薄弱环节的建议

6、 事故管理和问题管理

   a、   突发事件管理
     恢复服务到协商级别之上
     使用规避措施
   b、   问题管理 
      诊断突发事件的根本原因
      识别最终解决方案 
      可能花费更长的时间
   c、   incident--》problem--》known error--》change

7、问题管理流程

问题检测、日志的记录--》问题的分类和优先级--》问题调查诊断--》临时举措--》已知错误--》最大问题回顾--》问题关闭

8、问题调查诊断工具

a、 按时间顺序
b、 头脑风暴/鱼骨图（专家讨论）
c、 帕累托（优先解决更有价值的问题）
d、 5whys（深层次分析）

9、问题管理经理和度量指标

A、问题管理经理角色（IT运维经理）
a、协调所有问题管理活动
b、职责包括：
i、联络所有问题解决小组（由技术组支持），保证在SLA目标前提下迅速解决问题
ii、已知错误数据库的属主和保护者，负责已知错误的管理和搜索算法
正式的关闭所有问题记录
iii、联络厂商、承包商等确保三方完成解决问题相关合同
iv、安排、运行、记录问题、跟踪重大问题回顾相关活动
B、 度量指标
某个阶段内记录问题的总数（月会）
在SLA范围内，解决问题的百分比
超出约定解决时间的问题数目和百分比
尚未解决的问题和发展趋势（性能）
解决问题的平均成本（量化）
重大问题的数目及重大问题回顾执行的百分比
增加到KEDB的已知错误数目
KEDB的准确度

10、问题管理挑战

a、 挑战一：问题管理流程中重大的挑战是确保问题管理和事件管理有着正式的接口和协同工作的习惯 解决办法：（频繁发生（TOPn）、重大）
b、 挑战二：问题解决人员的技术和能力来识别事故的真实根本原因，有时候这也是一项挑战 解决办法：找高手
c、 挑战三：确保问题管理能够使用所有的知识和服务资产，而且配置管理资源对于调查和解决问题能力也是可用的 解决办法：建立知识库
d、 挑战四：确保不断对即使人员进行培训，内容涵盖对其工作的技术内容，以及他们支持的服务和使用的流程的业务培训 解决办法：培训
e、 挑战五：确保业务影响被所有解决问题的人员理解 解决办法：让业务跟IT的人多沟通
f、 挑战六：如果用于记录事故和问题的工具不同，将事故与问题关联的能力将成为一项挑战 解决办法：控制台

十三、请求实现流程管理

1、 服务请求（service request）与请求实现

     服务请求：来自用户的，对信息、建议、标准变更的请求，或者访问IT服务的请求（低成本、低风险、低技术、频繁发生）
     请求实现：负责管理所有服务请求生命周期的流程

2、 目的目标

            提供用户请求和接受标准服务的渠道
    为客户提供信息或者软件介质，许可证等标准服务

3、 价值

             标准服务的快速、有效访问、提升服务质量
     标准服务的集中提供，便于管理和提升，节约成本

4、 服务请求的困难

             用户视角和IT视角的矛盾

5、请求实现挑战及应对

  a、    定义的范围不当，用户不清楚具体有哪些请求流程能够处理
        （服务目录）
  b、    用户接口设计或实施不当，使得用户很难提出请求（改进，补单）
  c、    后端履行流程的设计或者操作很差，不能处理大的请求量，或某些特性的请求（增强服务台的实力，培养种子用户）
 d、 监视功能不足，使得无法收集准确的指标
 e、 增加自助服务的门户

十四、访问管理流程

1、 访问管理（access management）--》信息安全

   允许授权用户使用对应的服务，拒绝非授权用户
   也被称作身份或者权利管理

2、 范围

            所有技术和应用管理，通常在一个点控制，如服务台

3、 业务价值

            保证信息的私密性
    有效地管理员工的工作，减少信息的误用
    服务使用情况的审计，可用于满足标准，如SOX

4、 原则和基本概念

         访问（access）
   身份（identity）（密码/多因子验证）
   权限（rights）（RBAC）
   服务或服务组
   目录服务

5、访问管理的挑战及应对

    a、挑战一：缺少合适的用于管理和控制访问服务的支持技术，可能导致手工任务管理访问控制出错（堡垒机）
    b、挑战二：控制通过“后门”来访问，例如应用接口和防火墙特殊需求的规则变更
    c、挑战三：缺少对访问管理活动和控制的管理支持(“制定”、“执行”、“审计”)
    d、挑战四：由外部供应商管理和控制服务的访问
    e、挑战五：确保必要的服务访问级别和必要的管理控制，避免采用影响用户业务的方式进行控制