腾讯云线下交付项目事件单业务规范赋能—私有云ASP通道原创

大家好，那首先呢，感谢大家来参加今天的一个课程培训，呃，先给大家做个自我介绍，我是服务搞进二组的，徐真呢，由我呢这边来开始。我们今天的第一个培训课程呢，是针对于我们腾讯云线下交付项目，就是事件单的一个业务规范服务，是针对于我们这个私有云P通道的做了一些配的。那么现在我就进入我们第一个的这个培训的一个课程，那么首先我们来看一下，就是说我们这个赋能材料的一个一个整体的一个内容。第一个部分的话呢，就是我们会讲一下，就是事件单的一个术语定义，会从事件单的定义，以及它的一个目的呢，去去做一些相关的一个介绍。那第二个部分的话呢，就会对我。我这个私有化事件单的流程去做介绍，第三个部分呢，是会对我们私有化事件单关键角色及职责的一些相关介绍。第四个部分的话呢，是。

我们安装事件单状态的一些相关介绍，第五个部分的话呢，会放在就是我们事件单优先级及S相关的一些内容。第六个部分的话呢，是我们。单问题分类相关的内容，那么最后一个部分的话呢，也会就是给大家讲解一下，就是我们私有云SP通道建单，包括就是短暂的一些指引也会在测试。环境呢，给大家做一个演示。那现在我们就进入就是第一个部分的一个内容了，就是关于就是事件单处理定义这一块。首先呢，就是事件单的一个定义的话呢，指的就是说我们在交付或者是售后服务过程当中呢，呃，由我们的客户侧，或者是我们的一线工程师主动或者被动的去记。这个就是我们的一个问题咨询。或者是技术支持请求等等。那么我们事件单的一个目的的话呢，就是去帮助我们的客户去快速。

嗯。对，现在大家能够听得清楚声音吗？可能是那个网络网络信号不太好。啊，现在这个声音是清晰的吗？大家可以听到。嗯，好的，那那我就继续。啊，现在的声音是清楚的吗？大家可以听到吗？好，那我这边的话就接着继续讲一下，就是我们关于就是事件单的一个目的，那么我们事件单的一个目标的话呢，就是帮助。我们的客户去快速的去恢复，恢复恢复业务，那也就是我们事件单的一个特点，那么至于说这个就是，呃，这个就是解决就是就是问题的这个根本原因。

或者是根本原因，并且要解决的话呢，那个就放在我们就是第二个部分，就是关于问题的一些介绍上面，这个也是我们事件单的一个一个特点，都在快速恢复业务这一块。那么接下来我们就进入就是第二个部分的一个一个内容。就是关于私有化事件单的一个流程，嗯，首先大家可以看到就是。左左边的话，大家可以看到就是我们呃，私有云P通道事件单的来源的话呢，主要是来来自于就是项目现场的一个反馈，以及一些其他渠道的一些。反馈，那么最终的话呢，就是我们的私有化的一个事件单的话，都会在安登系统当中去流转，比我们的一线一线的这个客户代表去建单。并且呢，及时的去处理这个工单。如果在一线无法能处理的这个情况下呢，会转单给到我们的1.5线处理，那么在1.5线仍然没有办法这个解决。

觉得这个情况下呢，会依次的就是传递给各二线以及后端就是三线或者四线产研以及垂直产研的一个同学。那接下来我们就看一下。就是事件单的一个流程的一个一个详细的一个一个一个内容。呃，大家可以看到就是这张流程图上面就是首先这个事件单的一个。创建包括结单的话呢，都会放在就是就是这个操作呢，都会在一线这里，那么大家也可以看到就是一线就是作为客户代表在这里的一个一个角色。的这种就是就是接受，就是来自客户侧的一个反馈以及。针对于就是客户侧的一个沟通的一个工作。那么从这个流程上来看的话，大家可以看到就是一线的这个我们的公开表就是创建工单之后呢，呃，它会进行一个就是对于工单的话进行一个处理。

在他没有办法处理的一个情况下呢，他可以去转单给到我们的一个1.5线的一个同学。那么1.5线的同学的话呢，也收到就是就是一线的同学。就转过来的这个事情单呢，他可以去判断，就是说这个转班是否是合理的，那么如果说针对于就是不合理的一个情况的话呢，嗯。1.5线是可以进行一个拒单的，那么关于就是拒单的一个标准的话，我们会在在下一个就是下一个章节的内容，就是关键的一个角色及职责上面去。给大家做详细的一个介绍，那么针对于就是合理的一个情况的话呢，就是一点，我先会进行一个处理，那么针对于就是说这个事件当当中的一个信息，如果。说这个不够完整，那么需要去去补充这个信息的时候呢，这个时候是我们的业务，这个同学是可以去发起这个向客户代表发起，就是要申请补充的。

那么针对于就是1.5线的这个同学，能够就是处理完这个工单之后的话呢，能够就是闭环解决的话呢，他可以在处理完成之后呢去发起。这个申请结单。那么由我们一线的这个同学的话呢，在判断就是说这个处理结果，这个申请结单的话，是否合理，要站在客户的这个这。这个角度上去看，这个这个业务是否去恢复了，有没有解决客户的一个问题，去同意或者是拒绝他的这个申请。那么如果说拒绝的话呢，就会又返回到。在这个我们的这个这个上一级的一个处理队列，我们1.5线这里，那么针对于1.5线，如果说他不能够这个解决的这个问题的话，他也可以一直去。转班给到我们的这个二线或者三线的同学。

那么以此以此类推。的话呢，二线或者三线后，以及我们四线同学的话，在接到上一上一个岗位队列的上一个岗位部转过来的工单的话呢，也可以进行一个判断，就是说是否是。合理的。如果是合理的一个情况下的话，就可以去就是接受这工单平均处理，如果是这个不合理的一个情况下呢，就可以去做一个拒单的这。这样的一个一个动作。呃，刚刚有同学在反馈，就是听不到声音，嗯，现在可以听到声音吗？这边信号是什么。

嗯，现在可以听到声音吗？首先呢，大家可以看到就是这个。这个流程上面大家可以看到，就是在这里的话。那就是创建工单，包括就是工单结单的这个操作的话呢，都是在一线这里，也就是大家可以看到。呃，现在可以听得清了。嗯，现在在线的同学可以听得清吗？

嗯，那那我们就接着这个继续，我们刚刚讲。这个内容啊，这个PPT的话呢，到时候会在这个，呃，会会这个我们的培训材料的话都会发出来的，这个具体的这个渠道的话，一会请林文同学。补充一下。那好，那我们就接着就是这个，刚刚就是讲这个私有化事件单流程图。这个地方也就是说在一在这里的话呢，一线他是一个客户代表的角色呢，他要去就是呃去处理就是就是客户特的一个反馈，以及和客户侧的一个沟通。的工作，以及就是一线在这里的话，在创建工单的时候，对于优先级的一个判断啊，这这些的话都是在一线这里。那么就是在这个一线，在。创建完工单之后的话呢，会对这个工单进行处理，对于他无法处理的一个情况的话呢，会就是转给我们的1.5线去去处理我们的1.5线的话呢，就是。

就可以去判断，就是说这个一线转单的这个情况是否是合理的，针对于就是不合理的一个情况的话，是可以进行一个这个拒单的，那么针对于就是合理的一个情。情况的话呢，就是就会接着去处理，那么在过程当中，如果发现这个事件单的信息不完整的话呢，他也可以向一线客户代表那边去发起这个。这个补充的一个申请。那么再进行一个处理，那么针对于就是说他不能够闭环解决的这个这个事件单的话，他要及时的去转向到。啊，就是后端去处理，那么后端也可以就是按照这个我们的一个去单的一个标准去判断说这个转单是否是合理的，如果是合理的，那么我们的二线或者是三线。自信的同学的话呢，就继续去处理，如果不合理的一个情况的话，也是可以去拒绝这个事件单的，那么针对于就是事件单已经可以闭环解决的情况下呢，当前。

处理人在处理完这个事件单以后呢，可以向这个一线呢，发起这个申请结单的一个操作，由我们的一线呢再去判断，就是说这个申请这个结单。是否是合理的，如果说这个问题已经解决了，并且客户也认可了，那么就可以去同意这个接单的动作，如果说这个问题还没有解决的话，那我们一线一线的。这个客户代表是要把控好，就是这个这个这个同意申请结单这个这个这个权利的要保证，就是在客户的问题已经解决的情况下，才能够去同意。这个申请接单，如果在问题还没有解决的一个情况下，一定要去拒绝这个后端的一个申请。那接下来就给大家讲一下。那就第三个部分，就是关于事件单的一个关键角色及职责的一个一个内容。

那么首先大家可以看到，就是在就是一线这个。一线一线就客户代表这个这个角色，这里的职责的话呢，他要去做就是这个简单，并且要去确定这个事件单的一个优先级，明确工单。归档的必要的一个信息，呃，在这里的话呢，就是要重点要去提醒一下，就是我们一线的同学，一定要就是根据就是呃，就是特情的一个判断去确定好我们的一个。事件单的一个优先级，避免呢，就是说这个没有就是没有，就是确定好这个事件单的优先级，导致我们事件单的这个处理不及时，从而呢，引发就是。课目测的一个一个不满，这一点呢，就一线的同学一定要去注意，就在就是客情的这个反馈上，或者是这个影响范围上面，呃，有了变化之后的话呢，就是大家一定要。要及时去做这个调整。

那么同时呢，就是在一现在建完这个事件单之后呢，对于他这个无法就是处理的一个情况的话呢，他要去及时的去转点。他的下一层的一个队列去处理，那么就是基于实际的一个配置情况的话，他下一层级的这个岗位有可能是1.5线，有可能是二线，也有可能是产业或者是追。产业这个地方的话呢，大家就根据这个实际配置的这个情况去看就可以了。那我们接下来就是看到就是1.5建这个角色1.5。件的话呢，他会接收就是来自一线升级的这个事件单，他会去核实这个事件单的一个问题，及时的去响应，并且要处理这个事件单。那么首先的话呢，他就可以通过就是FQ啊，或者是端的这个手段呢，进行一个诊断分析，去尝试的去恢复业务，如果说在业务恢复以后的话呢。

但是如果就是说在对于就是一线找过来的这个事件单，他发现有这这样的一些就是条件的一个。情况下他是可以去拒单的。第一。第一个的话呢，就是没有按照我们的一个模板要求去转班的。第二个的话呢，就是我们的工单Q或者我们的。呢，就已经是已经有提供了解决方法的时候呢，我们的一线仍然转班的时候呢，这个在这种场景下，一种线是可以去拒单的。那么第三种情况下。就是在这个工单信息错误，比如说产品名称版本，或者是工单归档这些信息，如果有这种明显的一个错误的话，也是可以去做这个拒单的。第四种情况的话，就是这种表错了，这个队列的。也是可以进行一个一个拒单的一个操作的。那么这以上这四种情况的话呢，就是在发现。

就感恩。上一个上上一个岗位，就是上一个岗位转到转过来的这个事件单有如下的这几种。如下的这几种场景的时候呢，是可以进行。进行一个拒单的一个操作的。那么对于就是1.5线无法解决的一个事件单的话呢，他就要及时的去转单给他的下一层的一个队列去处理了。那么同样的就是对于二线三线或者四线的这个也是四线的这个岗位的话，都是一样的，那么这唯一的差距，呃，唯一的这个差，差别的话呢，就是在于。就是四线的同学的话，就是最后的这个事情当成一个一个兜底人了，他就没有办法再转给他的下一层级的一个队列了。那接下来我们就看就是第四个部分的一个内容，就是关于就是安事件单的一个状态的一个一个介绍，那么首先可以看到就是。

就说从一个事件单上面来看的话，我们会看到有三个角色，第一个的话呢，就是客户，第二个的话呢，就是我们的一线，就是我们的客户代理，以及我们的这个当前处理的是一点。线二线或者三线四线的一个同学。那么大家在这里的话，可以看到，就是一线的同学的话呢，他是去建这个建单之后就接受科目测的一个反馈之后。他会进行一个签单的一个操作，那么签单之后呢，他也可以去进行一个转单，给到当前处理人的一个。那么当前处理人的话呢，去做一些处理。或者是拒绝，就是一线的一个转班，如果说他不符合这个转班的这个要求的话。那么当前处理人的话。行，处理人的话呢，也可以就是向我们的一线呢发起，一线的客户代表呢，发起就是申请补充，那么在处理完这个事件单之后呢，也可以。

就像我们的这个一线的客户代表呢，发起这个申请结单的这个请求，那么一线的客户代表呢，就会根据这个实际的一个情况去判断，就是说能否同意他的这个申请。那么在这里的话呢，有一个比较特殊的状态呢，要跟大家提醒一下，就是对于就是就是代茶根音这个状态，代茶根这个状态的话呢，就是是当前是。有这么两种场景，第一种的话呢，就是有已经有临时的一个处理方案了，但需要通过出包去彻彻底修复的。还有一种呢，就是说当前。也没有一个解决方案是需要进一步去查根的，那么这个时候呢，就是统一的呢，都在这个事件当当中呢，去扭转到这个代查根的状态。然后呢，创建这个这个问题单，通过问题单来来跟进处理，那么跟进这个书包以及变更后续的变更就是就是问题能够被彻底的。

这个就是关于就是安灯事件单状态的一个。一个情况。那接下来就是给大家讲一下，就是第五个部分，就是事件优先级级S相关的一个内容。呃，我们优先事件单的一个优先级的话呢，会基于我们受影响业务的一个实际影响程度，以及事发的一个紧急程度去，并且去结合就是。不同的一个客户级的话，去判定这个事件单的一个优先级，那么在后面一个部分的内容的话，也会给大家讲到，就是这个优先级取证这一块的内容。那么我们也是根据就是工单优先级的一个不同呢，并且呢，是基于就是历史工单的一个处理能力，包括就是客户的一个预期呢，我们是有。

制定了取决时效。SLA承诺的。那么对于就是SVIP紧急的一个事件的话呢，我们的一个处理的话是八小时。对于非常。紧急的一个事件的处理，处理效的话，我们是12个小时要去去恢复。对于紧急的这个事件单的话，我们是在我们的处理。那么对于就是一般的一个事件单的话，我们的理是。那么在这里的话呢，其实这里的一个要点的话呢，还是大家要聚焦在就是每个岗位的一个处理时效。那么要通过就是每一个就是合理的。工作就是每个岗位的一个处理事项。从而能够保证就是我们。整体的这个这个事件单的一个一个处理时长。

接下来我们看一下，就是优先级的这个举证这一块的一个内容。那么大家可以看到，就是事件单优先级的一个判定矩阵的话呢，是影响程度为纵轴的，以紧急程度呢为横轴的，根据就是。根据我们的这个这个优先级举证的话呢，能够匹配出来我们当前试验单的一个优先级。呃，线上的同学现现在可以听到声音吗？嗯，好的，那我这边的话稍微就是移动一下，就是到一个网络比较好的一个地方。

现在。你就接着就是。呃，现在可以听到吗？好，那我们就就接着开始吧。这个大家刚刚就跟大家讲到，就是说这个事件单的一个优先级的一个判定指证的话，会根据我们的一个影响度，包括就是我们的一个紧急度呢，会去做判断。那么大家可以。

看到就是说在这里面的话呢，就会看到这个举证当中的话，影响的一个范围的话呢，就是会根据我们的一个业务的一个影响范围去做判断，紧急度的话呢，会根据就是。我们这个就是主要就是客户测的一个一个一个客情的一个反馈，包括就是呃，就是否是业务的一个特殊时期的话呢，去做一个一个。判断。那么大家可以看到，如果说就是在客户，如果就是明确问题，就是不紧急，或者没有就一般的一个咨询的话呢，你都可以就是。还有其他特殊情况的话，我们紧急都是可以放在一登这里的。一度是放在一根这里。如果客户已经出现了。呃，现在声音可以听到吗？啊好的，那那我就继续，那么就是关于如果说客户已经出现了这个催单，并且要催促问题解决。

之后那我们就要及时的调整，就是我们的这个紧急度到到两灯，那么就是客户已经出现了，就是急躁的情绪，并且就是有投诉的这种风险的时候，就要把紧急度放三灯。那么就是如果说这已经就是客户有要求索赔，或者是说在期的这个客户呢，出现问题的话，那个紧急程度是不是到四张。那么针对于就是有客户有明确就是说表达过，就是已经涉及到了这个舆情的风险，或者是涉政涉法的这种违规风险的话，那积极度就需要就调到我们最高的一个一个经级就是。要的。那么针对就是在看，就是这个纵筹这个部分，就是业务影响范围这一块。

呃，线上的同学现现在可以听到声音吗？啊，现在可以做，那那我们就接着继续。就是这个影响范围。这一。影响范围这一块的一个。的内容的话呢，就是这个首先就会针对于是一般的一个一个问题咨询的话呢，我们就会把它这个影响程度就会放在移动了，那么对于只是这个生产环境。它出现了一些不可用啊，但是没有造成受损的这种，或者是测试环境出现问题，那这个这这个影响度的话，就会放到到两灯。啊，现在可以听得清楚吗？

呃，线上的同学现现在可以听到，可以听到声音吗。那我这边还是还是还是先给大家再接着讲吧，然后。这个这个课后的话呢，会再把这个录屏给到给到大家。

那么针对于就是就是客户这个关键业务。关键一。业务出现中断的这个情况的话呢，但是没有造成这个大范围影响的话呢，还算就整体可控的话，那我们对这个影响的话呢，可以放在四，但是如果说是已经这个。受到最大范围的严重影响，并且对于客户造成比较大的一个损失的时候，就需要把这个影响度调到五了。呃，这个地方的话呢，需要特别关注的。就是线同学需要特别去关注的就是关于优先级降级的这个这个问题，目前的话呢，就是只有两种这个条件是允许这个优先级去降级的。其他的这个优先级降级的这个这个操作呢，都是不合规的，那么就是这两种情况，第一种的话呢，就已经是查明是客户的问题，需要客户去解决的。那么。

第二种的话呢，是跟客户协商了之后呢，客户认为优先级就是不高，并且呢，就已经是给到客户一个可以接受的一个预期时间了，那么只有在这两种情况下呢。是可以进行这个优先级降降级的一个操作的。那么就是就是一线的客户代表的话，一定要特别注意，就是不能够就是凭着这个感觉去判断。或者就是说呃，后端就是1.5线啊，或者是二线三线三线或者四线的这个同学的话呢，就判断这个问题，不仅仅就就要求说做这种降级的操作。那这种也是不允许的，一定一定是在就是和客户侧的这个沟通，并且客户侧是认可的一个情况下，我们才能进行一个降级的一个操作。那接下来我们就是在看到就是事件单的一个问题分类的一个一个情况了，那么就是事件单的这个问题分类。

的话呢，是我们在事件中创建的时候，它一个必填的一个一个选项，那么一会在这个测试环境给大家演示的时候也可以看到。那么我们看一下就是。交付这里面的话呢，就是针对于交付阶段事件单的一个问题分类的一个枚举值的一个说明了，那详细的内容的话，大家可以去，就是在在这个课后再去看。呃，这里面的话有几个就是要注意的一个枚举值的话呢，一个就是就是那个产品需求，包括产品咨询，还有资料文档的这个问题，这几个的话还是。呃，大家还是要区别清楚，就针对于产品需求的话呢，它指的就是客户针对于产品提出就是既定范围以内的新功能或新特性的一个需求。咨询的话呢，指的就是没有出现异常，只不过就是客户对于产品的使用操作或者是功能，就是提出了这一类咨询，那么资料文档问题的话，是就是他这。

这类的一个一个一个情况的话，是产品文档缺失，或者是透清晰，有这个歧义的一个一个情况。那么在这里的话，大家就是在录单的时候，就是。在建单的时候还是要注意一下，就是我。这几个就是这个分类的话，不要就是混淆了。那么就是在这里的话，大家。来看一下，就是运维阶段的一个事件，单问题分类的一个一个媒体值。一个一个明确值的一个说明。在这里的话呢，就是。大家要注意的就是使用方法咨询跟产品技术咨询这这一块的一个一个两个分类的一个枚举值的一个说明，呃，使用方法的一个咨询的话呢，指的是。对产品使用明确是对于产品的使用方法的一个一个咨询，那这种情况的话，是在于我们的一个产品文档当中，应该要有覆盖的技术上就是产品技术知识。

咨询的话呢，它是对于就是产品技术和原理的一个咨询，那那么这一类的这一类的一个问题分类的话，大家在验单的时候也要留意一下。那接着就是到我们这个最后一个部分了，就是私有云P通道，就是事件单建单或者是转单的一个一个。那这里的话，我在在这个测试环境给大家做个演示。

呃，大家可以看到就是这个测试环境的这个页面吗。看不到你，那你那个投屏投的是单独的那个屏。你现在大家可以看到这个这个页面吗。现在可以，现在可以。是针对于就是这个建单这一块的一个操作的话呢，就在测试环境给大家做一个演示，那么首先的话呢，就是在这个就是呃，就是。

在it服务管理这个工单这个模块，那么在我们的正式环境当中的话呢，这个是叫事件单，在测试环境这里是工单，这一会可以给大家做个演示。那在这里就是。就是创建工单，呃，这里大家要留意一下，就是在这个选择上面的话呢，这个工单来源的话，选择的是我们的这个私有云P。那么在这里的话，这个项目名称的话，它是支持就是模糊模糊的一个搜索的，大家可以输入关键字去去搜索。那么在这里的话，就是项目阶段这一块的话，大家要根据就是实际的一个一个情况的话去选择，就是对应的一个一个阶段去选择交付或者是。不会。那么就选择一个产品检测。

这里的话大家就选择这个，根据实际。这些情况去选择这个使用方法咨询。呃，这里的话，大家在可以看到就是优先级这个地方的话呢，这个安东当中的话呢，它是默认。一般的如果说对于这个这个优先级需要去去更改的话呢，大家可以就是点击这个修改的这个按钮的话呢，进行对于一个就是影响度或者是。还有紧急度，还有这些关键词去做一个修改。然后呢，在这里的话呢，大家去选择就是我们的一个工单归档。

问题标题，我这个是在测试环境，给大家做这个。合适。那么在实际的一个情况，大家。要根据实际的这个事件单的一个情况呢，去做这种就是。那么创建完了以后呢，就是在这个工单列表这里的话，我们会看到刚创建的这张这张事件单。拍这张。

打开这张事件单的话呢，就是在一线，就是客户代表这个角色，这里的话。呃，如果说针对于我们或者是一些客户代表同学能够处理的一个问题的话呢，就进行一个处理，或者说针对于他不能够处理的一个情况的话呢，就要去。进行一个就是转班的一个一个操作。那么转单的话呢，在这里的话有两种这个转单的一个选择，第一第一种的话呢。是按照我们的这个队队列去，去另外一种的话呢，是按照我们的一个指定库里面去的单会看到，就是按照这个队列去表单的话会有就是有。有两个推荐的队列，那么就根据实际的一个情况去选择，那么我们就转处理人的话呢，就需要在这里去输入入一个就是账号去实现转发。内部内。

那就是我们的一个就是比较简单的一个就是单，包括这个转单的一个一个一个指引。那么这里的话呢，大家要留意。就是一种情况呢，如果说是在我们当前的岗位没有配置队列的情况下呢，它就会弹出这个弹窗的一个一个提醒呢，就会提醒就是说申请这个。队列后呢，再进行一个转单，因为我们目前ASP通道下呢，它是在就是归档项目跟队列这三个去做绑定的，那么在这个时候如果弹出了这个。这个提醒之后的话呢，无线同学就是再去联系，就是预测的这个对接人的话呢，发起这个配置的一个流程申请，另外呢，也检查一下，就是说这个项目是否有。

对，因为在支持这个模糊搜索之后的话呢，这个项目比较多的时候，大家可能会会选错在这个地方的话，大家要多多留意一下。那么刚刚的话呢，就是只是给大家就是简单的做了一些，就是简单和转单的一些基础操作的一个演示，那么大家也可以就在安灯的这个这个安灯指引。这里面的话呢，就是有一个就是进进入到我们的一个拜年玩转安灯的这个课程当中去，去做一个详细的了解，这个里面的话呢，会有非常详细的一个建议。介绍关于安灯啊，包括这个工单处理的一个相关的一些一些具体的一个操作，就可去通过这个地方去了解。嗯。那以上呢，就是我们这个第一个部分的，就是一个课程培训的一个一个内容了，那接下来的话呢，就。

就由我就由就是其他老师。给大家就是培训第二个部分的一个课程。嗯，各位好，我是腾讯这边的QA Doris，然后我跟大家简单介绍一下，就是在我们腾讯云线下交付项目，就是跟质量呃要求相关的一些流程，嗯主要包含就是五部分，然后首先就是故障管理，然后接着就是问题，还有我们经常就是说在呃客户那里做一些售后服务过程中碰到的一些变更，看这变更是怎么管理的，然后另外两个部分是售后，就是经经常会碰到的一些转为，还有巡检，然后的一些呃流程上的一些基本要点，还有一些注注意的一些事项，然后做个简单的介绍，那首先看一下故障管理，那其实一提到故障，基本上大家都是呃要色变的，然后故障这一块，其实就是我们腾讯的这个故障的管理，跟大家经常听到的那个故障还会有一点差异的，那刚刚前面那个老师讲了事件，那其实。

那我们这里的故障，你可以把它简单的理解成比较严重的事件，那其实就是我们对这里呢，就是说呃，首先有个故障的一个基本的一个定义，就是会引起客户的服务发生异常，或者就是说客户的业务运行不稳定，发生错误或者中断等，引引起一些服务质量显显著下降的事件，那基于这样的一个概念，然后呢，我们又定义了一些标准，就是通过这些标准，然后看一下，就是说产生了一些就是客户的一些呃报账啊或怎么样的，就或者通过一些监控发现的问题，需不需要呃进入到故障管理的池子里面。

那一般就是说我们这几个标准其实也是参考的，我们也根据，就是说我们的客户的一些情况，或者一些管理的模式在不断的去优化标准，目前所定义的这些标准就是主要这五点，比如说客户业务受到大范围的严重影响，或者是整体中断，那这种情况那不用说了，肯定是第一时间赶紧升级成故障，就是简单的事件的流程也不能以满足，就是说这个标准了，就所有的事，所有的事情都要第一就是放下第一时间去响应故障，然后第二点呢，就是因平台的原因导致客户的一些关键服务中断，并且中断的时长，这里有一个判断的条件，大于60分钟以上，或者是客户已经就是非常的生气了，可能会投诉到相关的一些领导层，甚至有可能就是说有有些客户他可能比较特殊，会引起一些，嗯，社会上的一些舆情等这种情况的都要，就是说进入到故障的一个池子里面来，还有一些客户一些敏感数据的一些泄露，比如说一些客户的一些数据啊，支付记录啊。

这些泄露这些也要就是赶快的，就是说进进行进呃快速的响应，然后另外一点就是一些存在一些较高的一些法律风险，或者是一些运呃安全合规，或者是一些运营风险的这一类的，然后另外一种就是还有一些客户处于就是重点保证时期，发生的严重影响服务质量的问题，你比如说我们央视啊，央视然后正在呃晚会的直播，然后如果说在这个期间出了问题，那肯定就是马上也是响应的，那我们就是做这些事情的一个目的呢，就是通过故障的管理，呃，然后就是说引起相关的角色的，就是高度的一个警觉，然后能够引起就是说我们相关的资源啊，相关的人力能够尽快的配合，然后能够尽快的恢复客户的业务，减少影响，那同时呢，一般产生这类问题了，那肯定就是说是要严重，那我们会有相应的角色。

那在腾讯一般是我们会有QA的角色，QA的角色会组织相关的人员进行就是整个故障的一个复盘，对整个过程过程处理，然后进行一个就是比较细化的一个回顾看看，就是说中间过程中哪里有问题啊，而且还包括就是说我们再往前去看看看，就是说。我们的产品哪里有问题，或者说我们在运维服务过程中哪里有问题，就是目的就是找到我们产生问题的一个根本原因，然后针对这些问题，然后给出来一些改进措施，然后我们就是说在腾讯这边会有就是专门的QA去跟进这些改进措施的一个闭环情况，然后我们每一条改进措施会有明确的责任人，并且就是说这个责任人完成了之后，还会有相关的验证人去验证你的改进措施是不是真的有效，是不是真的落地了，那所以大家可以看到就是说整个的故障管理在流程上，包括管控上是非常严肃的一件事情，嗯，而且在我们内部，其实就是说一旦产生了故障，如果有明确的这种责任团队，尤其是比如说是产品研发团队的责任，那研发团队的相关的就是说责任人也会被通报会批评。

这个简单看一下，我们的就是故障的处理流程，那实际上就是故障的处理会比就是说你大家看到的这个流程会复杂，但是呢，我这里主要因为呃讲讲一些就是说在故障处理呃，流程中的一些要点，还有一些关键的角色要做的一些事情，呃，因为这里面的这个流程上展示上没有显示具体的角色，因为要做这样的事情，可能根据不同的企业啊，或者是不同的，就是说一个服务模式会对应到不同的岗位或者角色，那么希望就是说我们如果说要做故障管理这样的一个事情，那就是说会依照我们这样一个通用的流程去匹配，看什么样的角色去做，去做这样的事情。

那首先就是故障上报，那刚刚就是也讲到了一个故障的一个定义，还有故障的一个判断的一个标准，那在当前的情况下，我们可能没有办法做到那么智能啊，那通过一些监控告警，马上呢就能判断出来是不是故障，然后就告警给相关的人，那通常情况下，尤其是我们私有云，然后客户环境也比较复杂，也并不是说我们能第一时间就是说呃，会主动的去客户获取的，客户的一些情况，很多的情况，可能一些报证是客户报过来的，那我们根据客户报的一些情况，那就刚刚的就是说第一时间可能是第一反应是先录，我们刚刚那个就是事件单，那如果在事件单过程中发现这个影响的这个程度会越来越大，就就要有一个人，那我们可能就是说，你可以把它定义成故障经理的角色，具具体就是说在你的处理过程中有什么，就是说比如说售后的什么，嗯，运维工程师啊来承担啊，或者是我们的服务经理来承担都是可以的，就是有人要承担这样的事情，要尽快的进行故障的上。

号，然后上报之后，一般按我们的习惯就是快速的建立一个故障的处理群，就是把相关的干系人，然后尽快的然后卷入进来，尤其是是是要呃，涉及到运维啊，比如说研发，他们需要一起去排账，然后去看，就是说嗯，这个故障要怎么处理，那接着呢，就是说把相关的资源，相关的人卷入进来之后，就要进入一个故障处理的一个过程，那一般就是我们也会要求一个时间点，那关键的处理人一定要15分钟内就要上线。然后同时呢，因为我们的客户会比较着急，那我们的故障处理成当前是是一个什么样的情况，一定要就是说每20分钟内，我们会定义这样一个时间的要求，然后同步一下处理进展，由我们就是在跟客户的呃，沟通的一些，比如说我们的服务经理啊等，跟客户去做一些信息的同步，同时进行一些客户，客户安抚的工作。

那在处理过程中，有时候可能有一些故障，随着故障的处，就是处理过程中，或者是它的一些影响进一步扩大，那我们可能还需要按向上的这种方式，可能要向我内部的一些高层领导，然后去同步，然后有有可能是需要卷入，卷入一些更高级别的一些资源，然后进行这个协助的这个故障的处理。然后在故障处理过程中要注意，如果说故障处理遇到阻塞了，尤其是遇到一些技术的障碍，或者很长时间没有没有进展，也要注意要及时的就是进行升级，那整个的故障处理完了之后，我们要进行这个就是说刚刚也提到了我们故障的一个复盘和总结，我们就是会有对应的角色，一般就我们是就是QA来卷起一个，就是说故障的一个复盘，故故障复盘完了之后，就会输出一个比较正式的一个故障报告，那这个故障报告呢，其实我们也会分为对内的和对对外的，那对内的就是可能我们的就是点会复盘的非常细，我们的改进措施明确到人，明确到时间，明确到具体的时间，那给到客户的我们可能会就是说由相关的，比如说我们内部会有一些就是说架构师啊，或者是商务啊等一些角色，然后进行一些润色，然后润色之后再提供给这个客户。

嗯，如果我说的比较快，或者大家有什么疑问，也可以就是打断哈。刚刚那边网络不好，我不知道我这边网络怎么样，大家都能听到吗。好，那我继续哈。这里就是要讲一些，就是故障处理的一些注意事项，就是一旦有了故障，一定要以恢复线上的服务为第一优先级，就是有的时候就是说我们遇到了故障了，可能哎呀，这到底是什么原因呢？或者是有些人会呀，这是不是我的责任啊，可能会想的比较多，先一开始先不要想那么多，一定要先想办法怎么样，就是尽快的恢复客户的这个服务，采取一些就是说呃，一些紧急的一些处理措措施，那同时在处理过程中，就是刚刚也强调了，一定要及时透明这个处理进展，还有一些呃潜在的一些风险，然后不能自行解决的，一定要立刻就是寻求这个协助和升级，就不要在这个处理过程中就觉得啊，我一定就是说我要当英雄或怎么样的，就是有碰到了一些技术难点，相信很相信自己我能搞定，其实就是说我们的故障处理，呃，每延迟一分钟，那可能我们的外部客户，甚至我们客户的客户，那受到的影响可能是我们难以想象的。

那举个例子，就比如说我们的那个，呃，疫情小程序，那疫情小程序如果说在在在那个就是说高峰期的时候，那客户要进行扫扫码或怎么样，就是用户进行扫码，然后在机场如果说那个小程序出了故障，那不能登机，那这种就就很严重了，所以呢，就是说我们处理这些故障，可能跟我们的就是说实际的最终的用户是息息相关的，那我们肯定就是说要。整个的这个意识流程上的意识一定要加强的。另外就是一个最重要的一点，就是事后的总结，我们就是故障管理的一个重大的一个就是目的也是进行一个事后的一个总结，一定要妥善优化，然后保证就是说那我们不在同一个地方踩坑。这个就是我们目前呢，就是故障管理的一个流程，那同时呢，就是我这里不会讲一些具体工具的一些操作，那实际上就是根据这样的一个流程，安登里面它也有，就是配套的一些功能，到时候就说我们需要上的时候有，就是安登这边的，呃，产品运营或产品经理的同事再跟大家详细的介绍，就是安灯的一些流程。

这个是故障的，那接着就是看我们还有一个问题，管理问题，讲到这儿大家会对事件故障问题会有会很容易混哈，可能在平时我们的沟通中，这几个概念，这几个术语，基本上大家都是也会混着用的，但是真正的在我们就是说这种质量流程上，会相当于是有一个严格的就是这样的分层分级，以及就是说它的管控的目的，我们要达到什么样的一个效果啊，会有一个明确的这样的一个区分，那这里的问题的概念呢，其实这里问题是跟就是我们的第一部分，我们的事件管理是强相关的，那刚刚就是讲到的事件，我们可能想的就是说我们有了事事件之后要尽快的恢复那。恢复之后呢，然后呢，是吧，我们可能就是如果说需要去深层次的去挖掘一些，就是说这个事件的一些根源，然后还要再去看他是不是就是说会对其他方面的，就是就是同一个客户出现的问题，会不会影响到其他客户，那这个时候我们做一个深层次的根源的一个分析，并且防止这个事件再次发生，我们就会针对这种情况，然后进行一个就是把它当做问题管理，那这个问题管理又包括呃两种，一种是主动性的，一种是被动性的，那主动性的基本上就是说可能我们比如说我们的一些运维的技术专家呀，然后诶发现有些问题，然后就是说希望就是说通过问题管理找出一些就是比较薄弱的一些环节来，就是阻止我们事件的进一步的一个发生。

并且就是说把这些就是说它的一个影响进行消除，那被动性的问题管理呢，就是说通过我们找出一些导致历史事件发生的一些根本原因，然后我们提出一个解决措施，还有一些纠正的一些建议。

啊，这里的整体的我们的就是一个管控的范围，是首先就是说对就刚刚我们提到的各种各样的事件单的一个分析，然后发现一些共性的问题或者是隐患，然后还有一种就是说通过我们的监控告警发现的一些问题啊，然后我们也纳入我们的一个问题管理，那还有一些呢，就是说比如说我们有一些事件单已经有规避措施，但是需要转到问题单彻底解决的，并且这个情况我们就是说通过我们在我们的事件单里面会就是说直接创建一个问题单。还有一种情况就是对于我们事件当中没有规避措施，但是呢，我们事件其实已经解决了，但是这个时候我们需要继续去查它的规避措施，并且进行修复的，然后这种情况我们也会就是说通过就是说问题单的方式进行管理，那这里呢，就是说有跟事件单是一样的，那我们也会对就是问题单的优先级，呃呃，进行这个分级也是分成了四级，那这里有一个原则，就是对于单个问题单，呃，它关联的这个事件单的这个优先级呢，它就是问题单的这个优先级是跟事件单是保持一致的，对于关联多个事件单的问题单，那呃，我们会优先取这个事件单中的最高的优先级，作为这个问题单的一个优先级，就是作为就是这样的一个原则，那因为就是不同的优先级，我们也也是有不同的这种SL的要求的，所以才就是做出这样的一个。

呃，分级。下面是我们就是问题管理的一个流程。那首先那就是问题的一个确定和记录，那这里我们一般会有一个就是呃，问题经理的角色，那具体这个问题，同样的问题，具体的这个问题经理是由就是说我们实际中的什么岗位或什么角色来对应的，也是需要就是说我们去做匹配的，那在腾讯内部其实是有明确的去角色，呃，也也也其实也有明确的，也类似是一个岗位，然后去执行这个问题经理的这样的一个职责。

那根据就是刚刚讲到的满足这个问题单触发的场景，然后我们就创建一个问题单，并且跟根据刚刚讲到的这个问题的单的级别确定，就是问题单的这个，呃，四个级别的哪一种大家也可以看到，就是这边四个级别，每个级别都有定义它的这个处理的ss LA。那这些准备条件做好之后，然后呢，呃，就有相关的人员进行一个问题单的一个审核，就是确保这些基础的信息是齐备的，然后接着呢，再转给就是对应的这个问题处理人，那问题处理人在接到这个问题之后，就要进行一个调查和诊断，要分析这个就是问题的一些原因，并且识别一些改进措施，啊如果它是一确定，诶可能是一个已知的问题，可以选择跟已有的问题单的关联，那这里其实在我们实际，呃，就是说我们的项目的运营过程中，呃，我可以举个例子，比如说某一个客户他报了一个问题，那报了这个问题他可能就说，比如说发现一个，呃一个。

产品的一个bug，那这个bug呢，他就说我们第一时间会先建一个事件单，那建了这样的一个事件单之后，那可能这个只是单个客户的一个解决，就是这个时候我们会发现，诶这个bug可能是一个全网的，可能就是说我只要我有这个产品的客户，我都会有类似的问题产生，那这个这个情况我们就需要建一个呃问题单，然后呢，就是说建了问题单之后，然后就是由这个问题处理人给出来这个相应的这个原因以及改进措施，然后呢，这个改进措施呢，会关联到我们每一个客户啊，是可能会识别出来到底影响了哪一条，哪个客户，哪个客户他要，呃，具体怎么做才能把这这样的一个问题进行修复。

那接着呢，就是说识识别了改进措施之后，就是我们具体的这个问题的一个跟进和处理，然后以保证我们的问题呢，它的影响能够，呃做个就是根本的这个消除，那其实这个就是说下面我还会讲一个变更管理，就是说很多的时候我们问题的解决要通过变更的实施能解决，这个就是事件问题变更的关联，等一下我我会再跟大家详细的介绍，就是说具体是怎么解决的，怎么消除，就是跟变更相关的一些东西，那最后就是说我们解决完了，还有一个问题解决方案的一个归档，那这样这样呢就是说。也方便我们做一些就是说一些，呃，知识库的一些沉淀吧，然后共享，然后这个就是解决方案归档之后，我们这个问题单也就可以关闭了。这个是我们目前的一个问题，管理的一个流程。下面就是一个变更管理了，那其实就是大家可以看哈啊，我们在处理事件或者是处理故障，或者是处理就是刚刚所说的问题的过程中，那有可能都会对客户的这些环境，不管是就是说正式环境也好，或者是客户的测试环境也好，要实施一些变更啊，实施一些就是对客户的线网做出一些修改，那这种情况我们把它定义成就是说我们的技术变更，那就是这里也是为了跟客户，就是说我们在跟客户进行项目交付过程中的一些，呃，需求管理啊，或者方案变更进行一个区分，那其实也可以理解成这些，更多的是我们一些比较常规的一些，就是说运维所呃所做的一些变更，那为了更好让大家理解，这里对一些常规的一些变更做了一个呃分类吧，那比如说我们经常说的我们的软件八次修复。

那还有就是比较大的，我们大的大小版本的一个升级，那还有我们会碰到各种各样的一些安全漏洞，那对安全漏洞的一个修复，那还有我们就是满为了满足就是客户的不同场景的扩容操作，那还有有有可能还有一些客户的一些服务啊，或者设备下线，那我们会通常把它叫做缩容，那还有另外两种经常见到的各种各样的软硬件的配置变更，还有一些就是说对一些软对硬件啊，或者是一些第三方软件的一些，就是说这些基础设施的一些参数的一些调整啊，接口配置啊，重启等等这些呢，我们都会把它，呃纳入我们就是技术变更的一些管控里面，因为变更往往是就是说我们的故障啊，或者问题的一个出口，那如果说不对这个变更进行一些管控，而且我们出了一些问题，那究竟哪里就是说谁什么时间做了什么操作，我们都没有办法追溯啊，那所以呃，也并且在中间实施。

的过程中，有可能他的技术方案是否可行啊，我们相关的人员是否知道，我们就是说在就是说对我们的运营环境做了这样的变更，可能都会都会产生问题，那为了就是避免这些问题的产生，我们就梳理了我们的技术变更的管理的就是刚刚除了刚刚的类型，还有具体的一些流程，然后还有一些在过程中要遵循的一些要求。

那尤其是对于我们那个私有云的一些项目，那就是我们通常所说的线下交付项目，那我们的变更，我们现在就是严格的要求，我们任何的变更就是要就是跟我们的变更时间窗，我们的变更的方案就是要跟客户沟通好。经过客户授权之后，我们才能去做这样的一个变更。好，下面我们具体的来看一下这个技术变更流程，那首先呢，就是说变更啊，我刚刚也讲到了，就是说我们可能变更的来源有各种各样的，呃，客户的一些问题啊，甚至客户的需求，还有我们产品本身要呃做的一些就是说产品的一些bug的修复，或者一些产品升级，或者一些运维的一些常规的就是说通过巡检啊，发现了一些问题，然后主动进行修复，那这种各种各样的，然后来来了之后呢，变更来了之后，我们首先有一个变更请求，那么就是有个变更请求之后，那我们要有相关的人员组织我们的变更的评估，那在我们通用的I里面，或者业界里面，基本上会有变更经理的这样的一个角色，那就是说有可能这个变更经理是一个呃，实体的岗角色也有可能是呃，就是什么人员兼职的，甚至有变更委员会这样的啊，这个就是根据各个企业的情况，然后大家来定，那一就是，但是呢，一定要有人去做这样的事情，然后进行变更评估，那变更。

评估什么呢？那就要看这个变更的背景，还有就是说变更一些常见的变更的优先级，那我们也会把变更就是分成呃各种各样的不同的优先级，还有这个变更过程中，如果说我的变更操作过程中会不会有什么新的风险，还有我变更的成本，可能我需要的，我需要什么呃程度的技术专家，然后进行呃变更方案的制定，还有我需要什么样的人或者什么样的职级进行这个变更的，呃这个实施，或者是我这个变更过程中，我需要多长时间，这些都要通过这个变更评评估，然后去提前的去想这些事情，那把这些就是变更评估。

明确就是把这些事情做了之后，那接着才会到下一步我们变更方案的一个制定，那变更方案里面我们就会要求就是一些必须要求的一些内容，比如说我们的变更计划，我们大概会在什么时间进行这个变更，尤其是有些那个客户，我们要避开客户的一个高峰期，你比如说央视，那央视如果说我们在七点钟去变更，那肯定是不可能的，对吧，那我们要了解客户的一些高峰期，去尽量的去避开这样的一个时间。然后还有变更的影响，那如果说我。

不执行这个变更有可能对客户有什么影响，那我执行过程中，以及我执行后，或者我执行失败，对或对客户或什么会有什么影响，或者我在变更过程中对客户是不是呃有损的，这些都要，就是说在变更方案里面要要事先的，就是要想清楚，还有我们变更的内容，嗯。要做什么，呃，要做什么步骤都要写清楚，那接着呢，就是说变更完了，那并不是就完事了的，那在你的变更过程中，你还要写你你的一些验证的一些操作，那就是说我们可能有可能我们变更的人跟验证的人，呃是同一个，也可能是不同的，那如果是尤其是对于不同的，那验证的步骤一定要写清楚的，我们之前出现过好几个case，就是啊，我变更完成了，完了之后呢，验证步骤写的不清晰，然后呢，在另外一个人在执行。验证的过程中就不小心动了，客户的一些向往的一些数据结果影响了，就是导致了一个重大的一个故障，那所以呢，我们要求的这些内容也基本上是基于这种血的，呃，经验或者教训。

那另外一个就是说，在变更过程中，万一出了问题，一定要有一个紧急的预案，还有能够回滚的，一定要把回滚的步骤，回滚的这个措施写清楚。这个就是我们变更方案里的要求的一个一个内容，然后在腾讯呢，我们会把这些变更方案会以一个变更控制表的一个方式来呈现出来，就是会有一个模板啊，包括后面呃，我们安灯上也会把变更控制表这样一个东西做一个线上化，把这些所有的一些内容也每每一步都写的清清楚楚的，也相当于是有一个变更方案的一个模板一样的东西。好，那接着变更方案完成了之后，接着就是一个变更的授权了，刚刚也提到了，就是说我的变更方案是否是可执行的，是否是，就是说没有，没有瑕疵或纰漏的，一定要有，就是说技术专家的角色进行这个技术这个变更方案的一个审批，啊，我们内部经常叫技术授权，那至于就是说有哪些人，哪些就是专家可以来参与这个技术授权，这个可以我们自己自己来定，来匹配，那接着就是还有一个管理授权，就刚刚有提到了，比如说。

啊，我们的呃，实施变更人的人是否有资质啊或怎么样的，可能就是通过管理授权，一个就是有管理角色的一个人，然然后去承担啊在腾讯内部我们因为有Mo这样的角色，就是相当于是就是对标，呃，P Mo就是项目管理办公室，我们售后也有售后服务办管理办公室这样的角色，我们有这样的一个角色进行一个管理的授权。啊，接着还有客户授权，那我们的项目就是在客户现场的，或者是远程的，我们的客户服务经理要跟客户进行一个授权，就是要告诉客户啊，我们在什么时间点，要要对客户什么呃，进行一些什么操作，要跟客户说清楚，嗯。

那有些客户他本身如果说客户自己负责运维，他可能对我们的一些，呃，变更的一些方案，尤其是变更的操作内容可能把关的更细啊。那完了之后就是具体的一个变更实施了，那变更实施过程中就是要强调的，就是说一定要按照你事先的变更方案，然后执行操作，那不能说哦变更方案写的A，那我我我用B来操作，那如果说你发现变更方案有有问题的，那这个流程其实是倒回要撤回去的，你要就是再回到再重新制定变变更方案，后面的一些评审啊，授权啊，要重新重新做。那另外一点要注意的就是说在过程中，在实施过程中，如果呃有些异常，这个有了异常，尤其是会导致一些故障的，一定要及时采取措施啊。接着就是变更，呃，实施完成之后，就是要进行一个变更的一个验证啊，验证不通过，那肯定也是要及时的采取一些相应的补救措施，那这个验证不通过可能会有两种情况，一个是针对我本次的变更是失败的，但有可能对客户影响不大，那我就是再重新，再就看我变更方案是怎么样再重新做，那另外一种就是我变更的失败，而且会引起了客户。

一些问题，那就就是说会进入到我们的刚刚提到的我们的事件流程或者是故障流程里面去啊，要去处理一些问题。哦，这接着就是完了之后就是整个的变更，完了之后要通知到相关的人员啊。尤其是在有些比较复杂的，可能比如说一些客户的环境比较复杂，又涉及到交付，又涉及到售后服务的，那这个时候交付跟售后这两种大的角色，一定要做好这种变更的协同，做好变更的通知。那最后就是说我们所有的这些过程的变更的，就是说我们对这些变更的，呃，分一些分级啊，或者变更一些基本属性啊，时间啊，人员啊，变更的这些内容也都要做一个基本的记记录，以方便出现问题之后能够进行一个复盘，那有工具支持的，那比如说我们有我们安灯工具支持了，那我们的变更流程，技术变更流程，就是通过安灯来进行一系列的这样的记录和评审，那那如果说呃，条件不具备的，没有比较成熟的工具和还没有接入我们的安灯，那这个时候就是说线下这些事情也要也要，该做的也要做啊。

那还有一种场景，就刚刚讲到啊，这个流程好长好复杂，那可能有一种情况，比如说我们那个确实要处理客户的一些故障，那那按照处理客户的故障，那刚刚又说了又很紧急，那按照这样的一个流程，是不是黄花菜都凉了，那这种情况其实我们也提供了一个紧急的一个场景，对于紧急变更的一个指导吧，那对于紧急变更的我们，那肯定我们也要采取一些变通的方式，你比如说我们快速的，那本来就比如说引起了故障，故障本来也是要快速拉群的，对吧？那我们在快速的拉群的过程中，把我们的变更方案跟相关的人，然后确定清楚，同时就是说这些事情也可以并行，同时跟客户进行一个授权，然后然后确定了之后，然后我们就可以执行相关的操作，那操作完了之后，为了方便，我们就是有完整的变更记录，然后进行或者进行我们变更的一些审计或者追溯，那我们还要把相应的一些呃流程给补齐，嗯，就是要求做这样的一个要，就是有这样的一个要求。

我们这里会一般要求就是完成之后，最好在24小时能够完成，就是相关的一些呃，记录的补充。下面就是再来看一下，就是我们变更常见的一些分层分级来管管理，这里呢，就是变更，我们会把它呃进行一个变更的风险等级，那刚刚讲的可能有普通变更，紧急变更啊，这里还有个变更的风险等级，那目前在我们的内部呢，就是我们会根据一些产品业务特性去制定一些变更操作的风险等级表，那尤其是对于这种高风险的，那可能就是说我我一实施就直接会影响到设备的一些稳定性，或者是影响到客户的一些核心业务，那这个时候我们可能对于，尤其是我们技术授权的过程，我们会呃更加的加强，我们会可能会再上升到呃更高一层的角色，比如说我们会直接让我们的呃产研的专家来进行这个变更方案的，这样的一个，呃，技术评审这里就是讲一下，就是我们做这个变更风险等级的一个这样的一个目的吧，那其实。

变更风险等级怎么分，那这个肯定是基于就是说经验不断的在完善，也不是说啊一次性做好了，我就是啊一成不变的。那接着还有一个变更的优先级，那其实有时候会看到，就是说不管是主动啊被动啊，可能会收到很多很多的变更，那收到很多很多变更的时候，那我们要怎么做呢？尤其是可能哪哪个哪个级哪个先做哪个后做那个这个这个时候呢，我们会给一些就是变更优先级啊，然后以方便就是我们的一些人员或者运维，运维人员做一些就是说变更的时间窗，然后看怎么样，就是说评估会更合理。

这个这些优先级的这些说明，也其实也都是一些参考，然后呢，具体的就是怎么分，然后大家可以根据自己的一些经验，然后逐步的去完善，然后我们目前列的这些也是基于就是说现在的一些碰到的一些问题或者一些经验，然后给他梳理出来的，那以后以后如果有新的，我们也可能这些分层分级，这些管理方法也会不断的去进行优化。然后这里再跟大家介绍一下，就是目前我们内部对于我们的售后或者交付的，呃，这种这种技术工程师在进行客户现场操作的时候，制定了六大的严禁条例，嗯，这六大严禁条例呢，就是说也相当于是我们一个质量的强管控措施，如果违反了这些严禁条例，我们也会进行相应的处罚，那我们会有就是说呃，尤其是QA在一些问题或故障事件进行复盘的过程中或审计的过程中，然后会去看有没有违反这些严禁条例，这些严禁条例在这里也可以跟大家再来一条一条的看一下啊，这也真的是就是说不管是公有云也好，私有云也好，就是根据我们各种各样的经验，然后把它总结出来的，虽然这些东西全是意识层面的啊，甚至有些东西可能也没有办法通过啊，我比较嗯，自动化的工具啊去避免，但是有了这些意识真的会。

减少很多就是不必要的问题，我们通常就是说也不多嘛，六条嘛，打印出来，你可以就是实时的提醒一下，你自己那看一下都是什么哈，首先第一条就是对于这种就是我们的线下交付的项目，我们是严禁未经过客户授权执行变更啊。

可其实可以看到，就是说这些研究条例，刚刚我在讲流程的时候也都讲过，只是我们把最容易踩坑的，然后把它给列出来，另外一种就是严禁未经过技术或管理审批执行变更，这其实我们内部经常说我们的三授权，客户授权，技术授权，管理授权啊，你不能是说啊，我随意的哦，我觉得客户这里有问题，我自己就改了。另外一点就是严禁不按照审批通过的变更方案执行，变更这个就刚刚也其实也提到了啊，我们的方案是A，然后呢，你就说哎，这里有点问题，我自己私下就改了，我按B来执行，这这种情况也是严禁的，如果说你在执行过程中，你发现方案有问题，提出来，大家就是一起再来看一下，嗯，再进行评审，而不能说你自己直接就改了。

下面一个就是说变更执行后，不按验证方案进行验证啊，那那这个就是刚刚也提到了，也是有就是出过这种问题的啊。当然这里我们也会要求，就是说方案里面就要加上验证的，就是具体的步骤，那原来可能我们的变更方案里面都没有加这个东西，现在已经要求就把这些东西都写上，另外一点就是严禁没有经过客户允许或审审批，这条是单独又又又强调了一遍，相当于在生产环境进行测试，以及对生产环境数据进行分删改操作。这种其实出现故障也是也是出现过的，就是问题我觉得就是不可理解的，怎么会直接能敢拿，就是客户现网的一些真实数据，然后进行一些增增删感的操作，对吧，这也是一个最基本的一个意识。那接着另外一个就是说在变更过程中出现异常的时候啊，一定要在就是说你风险可控的情况下，就是嗯哦，这里是严禁，就是在风险可控的情况下，未采取相应的措施，那比如说你明明你变更在过程中你都出现问题了，而你跑出去，然后啊，跟同跟同事朋友聚个餐，出去吃个饭，然后回来之后黄花菜就凉了，对不对啊，那这个时候如果如果出现问题，一定就引起自己的高度的警觉，该拉人该拉人，该看怎么解决就怎么解决啊。

这个就是我们目前在变更管理的，就是说强调的，嗯，一些严禁措施。呃，变更这一块，然后就刚刚讲到呃，问题故障变更，然后这三大其实跟事件流程是都是强相关的，然后在安登里边也相当于是安灯产品家族一样，就是都是支持的，然后我另外再讲两点，就是跟嗯。跟我们的交付跟售后就是有个界限，包括我们的安登里边的一些就是说会，呃设置一些队列，可能跟当前你是属于这个，你这个项目是交付阶段还是运维阶段都有一些关系，所以呢，这里我就是顺带的讲一下，就是我们的转为流程是怎么做的，嗯，那转为不用说是，就是说是一个项目从交付阶段到维护阶段的一个标志，那转为通过后，那这个责任主题也就从交付团队转变成售后团队，那往往是就是说在交付团队跟售后团队这种就是说会就可能就是交，呃交接期最容易产生问题了，甚至有可能会产生就说哦，我还没有转转为呢，我还没有跟售后团队，就是，呃，就是进行一个交接完了之后，交付团队已经离场了，然后客户出了问题找不到人，就是以防止这种问题，所以呢，我这里再把转为再呃简单的介绍一下，那在我们内部目前会把它分为产品转为和项目转为，那可能。

大家会有点，诶为什么会这么分，这里也大家也可以看一下，我们在实际项目中，就是尤其是我们ASP各种呃，各种这样的合作商，那我们会不会也碰到这种情况，如果碰到这种情况也可以采取这种模式，那我们的产品转为呢，其实相当于是我们的一个内部的转为，就是说我们产品只要交付完成了，然后呢，符合就是说。

有相关的一些测试报告，或者是呢，有一些就是说比较成熟的一些巡检工具，也跑了一次巡检，有对应的一些巡检结果，那我们这时候就可以发起一个内部的一个转为，就是交付可以先离场，然后售后可以先入场，然后继续支持客户，那当然这个情况下有可能就是说我们客户层面我们还没有转为，因为一般我们大家也呃应该也都清楚，客户转为就是是你要跟客户就盖戳，客户要验收通过，要要签订正式的合同呢，那有的客户可能就是说你交付完成了之后，那我要试运行一段时间，那这个试运行有的时候真的是，那要看商务或者是说我们的售前跟客户谈的怎么样了，有可能一拖半年一年的，真的是有这种情况的，那这种情况呢，为了保证我们交付跟售后有很好的衔接，那我们就是说。

就根据这种项目的一些特殊情况，然后我们就制定了我们的呃产品转为，也就是内部转为，然后还有还有以及这个项目转为，那这个流程其实是还是比较简单的，呃流程本身就是说谁来发起转为谁来进行，就是说呃由什么人一起，然后进行这个转为评审，那如果说转为评审在会上我们达不到这个呃一致的意见，是不是就是说再有一个呃相关就是是高一层的这个领导进行一些转为决策，那因为毕竟这个嗯我尤其是我们内部的转为，像呃交付跟售后有时候会有有有一定的扯皮啊，交付是巴不得，哎我赶紧把这我交付完成，赶紧走，完了之后售后发现啊，你这里有有问题，那里有问题就不允许那个呃就是交付走，那其实这里是一个交付和售后，就是PK的一个过程，那这里呢，一般我们也会定义一些，就是说你是什么产品，会定义一些，就是一些转为的一些check的检查表，然后。

根据这个检查表，然后那个一项一项的来看啊，当前是否满足，然后满足了，呃，我就就能过，如果不满足，那也要在这个转为评审会上给出这个对应的一些解决的一些建议，你否则的话就是说你没有一些解决的建议，那后面有可能就是爆一个雷对吧。然后这个呃，根据这个就是转为的这个check检查表，这个就是看要看我们的交付的一些标准，或者是运维的一些标准，或者我们产品的一些特性，这个是因为是可以说是定制化的，嗯嗯，这个要根据就是说我们具体是什么产品啊，客户是什么样的一个产品，然后自己来进行这这样的一个自定义，就是希望就是说我们每一个项目它都有这样的东西啊，作为一个标准吧。这个是我们这个转为流程，而且就是说一旦在在我们内部就是说转为我们每个项目。

嗯，我们每一个项，嗯，这是要说有话说吗。我们每个项目，然后它的，嗯有多少个局点，这个局点它有什么产品，它的产品的这个这个局点呢，它的一个状态，我们都会做这样的记录，然后以方便就是说我们刚刚讲到的事件也好，然后问问问题也好，变更也好，就是能够转到对应的这个处理队列里面，嗯。下面是我们的一个巡检管理，这个巡检管理就是也简单的讲一下吧，这个就是是我们呃售后经常要做的一件事情吧，就是巡，巡检这概念应该大家也都不陌生，这个主要是就是说为了减少，就是我们主动的发现一些问题啊，或者是为了减少我们一些故障的发生，然后呢，我们内部就是说对我们内部的一个巡检，然后做了一个要求，然后尤其是就是说对于就是说什么样的项目，然后他的巡检频率是怎么样子的，如果你做不到要进行就是报备，我们提了这样的要求，那一般这个我们巡检一般会分为就是说主动巡检，被动巡检，那主动的一般就是我们运维，然后为客户提供的一些日常的巡检服务，那有可能就是说我们的巡检的平台如果说比较成熟了，那基本上我们能够实现这种自动化巡检的，如果说那工具巡检工具没没有这种自动化的，靠人拿着巡检手册一项一项的进行巡检，那也有这种情况。

放的，那这种的我们要怎么做，那还有一种情况就是说在我们跟客户会签订一些就是说呃专项服务，那有可能就是说客户要求你一年啊，或者是一年一次或两次的给我们做一次这种深度的一些巡检，那这种情况就是说我们要跟客户约定好时间啊，并且就是说把巡检的一些。结果或者报告就是要给客户进行确认，就是我们的另另外一种场景，那我们的流程其实也比较简单，首先就是要有一个巡检的准备嘛，那准备就是说刚刚也提到了，是不是有工具，没有工具，我有没有巡检手册，嗯，那没有的话，那那确实因为同学肯定就不知道怎么巡检了，要巡检什么对吧？那接着还有一个就是说，尤其是我们要部署巡检平台的，那肯定你要经过客户的一个授权，跟客户要明确，事先明确好我们的巡检方式，我们的一个巡检频率是怎么样子的，不是所有的客户都愿意让我们就是。

主动的进行巡检，或者每天就巡检的也要经过客户的同意，接着就是我们这具体执行巡检的过程了，那巡执行巡检完了之后，那要就是接着就是有巡检的报告，那对于呃被动的，那我们就是需要输出一个呃比较官方的一个巡检报告给客户，那平时我们自己的这种日常巡检，那我们有的有工具的，可能就是说会自动化的输出一些巡检报告，那输出完了之后，那我们要做的就是要去看巡检的这个结果有没有异常，那如果发现了异常，那接着就是说进行我们的。走我们的事件流程，就刚刚也讲到了。

这里我们目前对巡检的一个要求，我简单的介绍一下，那我们目前要求的是有驻场运维的项目，呃，就客户授权后每天巡检至少一次，没有驻场运维的，然后这种巡检的频率也至少一个月两次，这这样的最低要求，那接着就是要输出一些报告，然后如果发现异常，然后录入安灯事件单，那上面的巡检的这些频率做不到的，要进行一个报备啊，比如说明原因，比如说啊客户他可能有自己的团队，客户自己进行巡检啊，不要求腾讯进行呃巡检，这举个例子哈，还有一种情况就是说，呃产研支持的比较弱，产研没有给呃运运运维同学巡检的支持，也不知道巡检什么，那巡检或者巡检能力达不到，那这种情况也也也是会有的，所以我们就进行一个报备就OK，嗯。这个就是我们目前的巡检的一个流程，那其实呃，刚刚讲到的就是目前我们在线下交付项目，就是交付和售后，呃，整个过程中就是比较重要的几个的质量跟，而且跟质量强相关的几个流程啊。

其他的如果有需要的话，再慢慢完善，目前是主要推的是这些流程，大家看有没有什么问题。那没有的话，我这边就结束，嗯，然后就给到下一位同学。好，那我们回到课程当中来，大家辛苦了，那我们这这一个课程呢，我们要讲一下关于这个艾在腾讯云的一个最佳的实践，也就是我们整个安登平台，我们怎么用我们的安登平台，我们的客户。交付这个云服务。OK，那我先自我介绍一下，我是呃，安登平台的一个产品经理。

目前主要负责的是私有云这一块的事件啊，问题这一块的一些，呃，流程的产品经理。好，那我们先说一下，就是我们先把整个课程的大纲给大家去介绍一下，那我们通过这门课，其实大家需要掌握了以下几点，当然我们后面的话也会有考试的内容，就是在明天吧，有一个考试，那我我来讲的这一个部分呢，会涉及到两个部分的一个考试内容啊，第一个部分呢，会涉及到一些I的一些相关的知识啊，第二部分呢，是关于我们整个安登平台的整个功能层面的，包括流程层面的，那整个的考试的内容会相对来说啊，不会很难呢，因为艾在艾这个层面的话，因为是一个非常庞大的一个体系，非常呃里面的涵盖内容非常非常多，所以呢，我今天所讲解的基本上都是非常泛泛的一个层面，会基本上给大家介绍一些相对理论。理论。

呃，面面上的一些东西，比如说啊，我们为什么要用艾来做云服务啊啊，以及说艾，我们刚刚其实两位老师有讲过关于事件问题变更这一块的一些流程了，那我们也只会聚焦于这个啊，这几个流程到底要解决什么问题就可以了，那第三点就是我们能够啊清楚的区分什么是事件啊，什么是问题，什么是变更，其实就呃就就。就足够了，那这一块的比重呢，不会很高，那么第二块呢，是关于我们安灯这一块，安灯首先我们要了解，就是关于这个安灯，它到底解决了什么问题啊，就我们为什么呃要要来拿这个安灯的认证，为什么我们要用安灯啊，就是这是我们一个也是价值价价值层面的一些1111个呃问题。第二块就是也是刚刚讲到的安登的三大流程的一个定义，其实也就是跟刚刚结合的一个艾的几大流程结合起来的，安登的三大流程的定义，以及他们的关系，涉及到相关的角色啊有哪些，以及他们的职责是什么啊，第三块就是这三大流程当中有哪些操作规范。

会在会些，会有一些比较基础的操作规范，最后呢，会给大家再介绍一下几个必须要知道的功能和概念，比如说ola啊，优先级啊，以及一些讨论的功能啊，这些我们都会后面的课程讲到，简单来说呢，对于的整个解，大家只要了解面上就好，题目不会非常难。那对于安登的整个呃理解呢，大家只要了解说安登解决了什么问题，这三大流程之间的关系，以及我们怎么操作，规范是什么就可以了。那整个课程包含三个部分啊，第一部分我先讲一下关于I相关的一些面上的东西，第二块呢，就是安登介绍一下安在这个腾讯云当中，我们用安灯是如何存在这套东西的啊，第三块我们会了解一下啊，几个安灯必须要了解的术语和概念，为什么要了解术语和概念呢？主要就是为了帮助大家以后呢，在跟我们啊腾讯的产产品研发团队也好啊，或者是在我们内部的协作当中，我们能够呃很好的在整个术语概念上面保持一致啊，提高沟通的一个效率。

那么首先我会给大家介讲一下这个背景，就是说目前我们其实整个全国我们都在讲一个啥数字化的一个时代，那数字化的时代和数字化转型其实都成为了我们整个社会的一个非常大的一个热点，那么呃，为什么要提这个点呢？其实整个数字化的一个转型呢，会对我们整个it的啊，It的个运维会产生一个非常大的影响，那具体会表现在四个方面啊，第一个方面就是啊，其实整个的数字业务的其实本身是一个客户满意并流一个自动一直在讲的一个概念啊，实现这样的一个自动化的概念呢，那我们就需要一个新的一个业务模型啊，来来让整个流程走顺。第二块就是整个技术，技术生态，新技术也带来一些新的机遇和风险，当然不断增长的需求啊，It也必须要在降低风险。成本和风险而。

且遵守法规的同时啊，要更快的交付我们的云产品，并提高产品质量，尤其是在我们现在啊，包括腾讯云，阿里云这些云厂商快的发展的一个一个背景之下，那么如何保证这些呃更好的一些数字化的产品能够交付，并且快更快的交付，同时能够在交付过程当中保证产品和服务的质量啊，其实也是需要我们考虑的，在数字化的时代，这个要求更高了，那另外就是我们要目前有一些啊it交付的一些新的交付范式，比如啊敏捷这一块正在起给我们整个it带一种新的一个和挑战，因此呢，如果没有有效的一个it数字的模型，我们把这个it成简化动化，其实就会的成本以及的还有一些的损失，那其实我们的目的就是为了让我们的整个it的流程更加的呃，就低成本，同时呢，服务质量，交付质量更好，这也。

在就是大家，呃，目前也面临的一个目标。那因此呢，我们引入到一个的一个概念，其实数字化时代的这个概念引入到了是一个四的一个概念，那么我先介给大家介绍一下，就这一啊，什么是呢？其实就是英国国家计算机和电信局C。在这个20世纪80年代末开发出来的一套这个it服务管理的一个标准库，你可以理解为它是一套方法论，那么其实大家可能呃在有有这个印象啊，可能有些是在这个一上个世纪70年代，六七十年代的时候，其实这个计算机开始这个普及的时候，尤其是在欧美发达国家普及的时候，很多人就开始用一些用计算机来解决一些问题了，那这个时候呢，呃，一些一些公司的话呢，他可能就呃采用这个计算机来简单的记录啊，简单记录，然后来实现这个工作，能够在it上面来完成打字啊这种简单的一些记录，但是呢，随着企业规模越来越大，那整个人人员流动也变得越来越越越越复杂，同时呢，也涉及到多部门的，尤其是一些啊，非常大庞大的一个公司，这个体量非常大的情况之下，如何实现人员之间的协作啊，It的整个运运维it服务如何去保障啊，整个的整个it这一块怎么去那。

成为了整个呃这个大大时代背景下的一个一个难题，那么有没有一套呃，很好的一个把整个it服务管理起来的一个理论呢？那么就从就在这样一个背景下面诞生了，那呃做这个的一个主要解决的目的，其实就下面这个啊，提高it与业务的一致性，我们又让it更好的保障业务的流程的进行啊，从而提供服务，更好的满足客户的需求。第二块呢，就是我们要了解整个业务的一个可用性，安全性，容量，连续性能达到的水平，规划可以达到这种水平解决方案，那还是一点就是要提高整个it的服务质量，最后当然就是为了减少人力的浪费，通过协作呢，我们能够量化出来，集中精力的一蹴而就来降整个it的服务成本。

那的话大概会经历了四个整个服务的过程啊，大体上是四个，其实是呃五个啊，就大体是四个，第一个呢，就是在这个191986年的时候艾的啊V1.0的版本，当时呢，只是基于职能的实践，什么叫职能时，就是说it运维当中需要哪些角色，这些角色之间怎么去协作啊，是在一个职能的一个角度，那么在2.0的时候，是1989年的时候，提出了这个非常有名的啊PPT啊，流程啊，然后组织流程，还有整个的工具层面，就是在这个时候提出来的，提出以客户为中心，流程为导向，这一套也是为全的一个it服务管理最佳实践的框架，那么在零七年的时候呢，又提出了一个it服务生命管理周期的概念啊，有一个非常的理论，四批啊，People product partner啊，引入的一个应商的概念，那么这一套也也是目前企业里面应用最广的一个理论，就是V3.0，那在4.0也就是。

2019年的时候啊，就强调了一个价值流，他终于提出了一个从it产品的交付和运端的一个数字化运营模型，也就是我刚刚提到的，在数字化时代的背景之下，It怎么进行做交，怎么做运营，怎么去更合理的去从需求到部到整个的流程，最后实现优化的一个过程，他就强调这样一个价值流的一个方法，那成了一些精的理理理念，还有一些敏捷的理念，那这些大家基本上了解一下就好了。

那在三里面其实就涉及到很多模块，其实大家对这些可能比我更加的了解，做这些it运维的，那么里面会强调了几个环节，首先从整个it的服务战略这个环节啊，当收到客户需求开始，我们要投入多少人力，多少财力，怎么去组合我们的服务啊，就服务战略层面啊，对整个进行了一个设计。第二块就在服务设计层面，我们要给用户交付什么样的产品呢？我们有哪些服务目录呢？那我们要给用付什么样一个承诺呢？啊，以及说我们的产品的可用性容量如何呢？整个的服务连续性怎么保障呢？安全性怎么保障，还有一个供应商我们怎么去管理，这一块也是服务设计当中的一个内容，那服务设计好了，怎么去给服务，给用户交付我们更好的云产品呢？啊涉及到一个服务的转换的一个环节，包括一些啊资产啊变更，刚刚呃，Do瑞S也讲到变更，那还有发布部署，检查测试，同时呢，我们把这些问题沉淀下来的一个知识管理啊这一块其实是在服务转换相关的范畴，那服务运营就是说我们这个产品交付出去了，那我们怎么把这块。

玩转起来啊，把整个运营让用户呃满意度提升，那这里会涉及到一些监控的管理啊，服务请求管理，还有一些事件管理，问题管理，访问管理，那其实刚刚都是想到了一些什么巡检啊，这些其实也都属于在这个服务运营的一个范畴里面，它对整个的呃，目前整个系统的运作情况，产品运作情况进行一个监控，那么我们后面讲的一个事件管理啊，问题管理，其实都属于在服务运营，怎么去解决问题，怎么让这个问题呃从此规避避免，不要不让他再继续发生啊，就问题管理要解决的，那最后服务改进，服务改进呢，讲的就是说在呃怎么去度量我们这个服务啊，服务满意度怎么去衡量，最后呢，我们的服务报告是什么样的，如何对整个服务进行一些不断的优化和改进，那服务改进其实是贯穿始终的。

看一下这张图啊，非常小，但是大概有几个模块，就刚刚我讲的，首先服务战略，服务设计与转服务设计，服务转换，服务的运营，那我们发现这个持续的service啊，服务的整个改进是贯穿几个流程始终的，我们看到四个箭头。啊，所以我我之所以讲这个的一个目的，就在于说我们其实是基于一套方法论去做这些事情的，并不是说我们在整个的执行的运维过程当中是有是想到什么去做什么的，而是说他是需要有一套理论的框架，而大家上安来的一个目的，也就是我们认同这一套框架，认同有一套比较完整的一个方法论去指导我们的行为和规范，那这是我们讲头的一个目的。那么到去年的2019年，有一个四提出了一个价值的共同创造，那么以前我们讲的服务应商啊，合作伙伴就腾讯合作伙伴跟服务的消费者之间，其实是单向而遥远的。

就是说可能呃，真正面向客户的可能就是公司的主体啊，那服务的应商只是在后补充弹药啊，那这种这样的一种关系，但是我们会发现现在整个组织认识到整个价值其实通过服务供应商和消费之间积极合作，共同创造的，比如说在座的各位合作伙伴，他怎么去跟这个客户之间其实是一个保持一个非常密的关系的，他跟的消费者之间是共同创造的，共同去协作，不断去优化的，所以这样的一种关系，也就让我们需要，呃，包括我们的合作伙伴就需要更加的注重怎么去保障我们的云服务的质量，同时提升我们的服务质量。那我们可以看一下这张图，就讲到了几个，从V2 V3 V44个版本提出来的几个，包括在的44D啊四个维度，那我们也重点讲一下4D吧，4D呢，主要就强调说我们整个的服务的价值的价值的价值的产生是体现在什么地方的啊，其实是受四大因素来共同来实现的，第一块呢，就组织和人员。

第二块是信息技术块，就是我作伙应最就是我们是什么样子的术，有整个的应然术，整个提一个个流程会大一流程之保同保我们的个服务质量，那合作伙伴与应商，也就是呃在在座大家如何去呃在整个服务的环节当中，其实成为了一个一个服务管理当中的一个非常重要的一个环节。

只有把他这个环节搞好了，那么才能够共同促进整个价值的一个，那么除此之外呢，有六大，六大就是的一个理论呢，就是。呃，战略战略分析的里面经常会提到这个政治环境，法律、技术，社会经济都会影响到整个价值流的一个影响。那什么叫价值流呢？价值流其实我大家可以看一下这张图，那我站在一个就是我们整个交付的一个一一个场景，我来讲一下什么叫价值流，那当客户从这个呃，一个机会啊，就是从客户提出一个需求，比如说我我发现呃，我这个出现了一个故障啊，或者说我我的呃系统不通了，我这款产品需要购买新的产品，增加新的配置，那么就会产生一个新的需求，而我们作为现场的管理人员，或者现场的服务人员，交付人员，我们就会跟客户首先谈好啊，聊好这个需求的背景，以及说聊好这一块遇到底遇到了什么问题，亲身的了解说这块到底是发生了什么样的一个状况，之后呢，就是到一个服务价值链的中心来了，我们要开始去响应客户的这个需求，就是engage啊响应的这个需求，那么呃，去构建整个开始去思考我们这一块到底怎么去响应，用什。

这一个流程啊，比如说我们的事件单啊，我们开始去录这个事件单，那之后呢，我们就开始进入到整个交付与支持这块，完成之后呢，我们怎么去把它交付给用户啊，这其实在之前还有一个设计转换的环节啊，就是说我们这个问题来了，那我们怎么去分析这个问题啊，怎么去把这个问题啊落地，真正的落地，最后呢，向整个用户去交付我们的产品，最后就形成一个服务。产品的服务，那么整个流程我们可以理解为这是一个治理的过程，治理的过程还有一个实践的过程，它是一个循环的。

那么到最后也就是一个价值，我们付成价值，价值流程熟悉。Doris，还有刚刚的那个泽也都讲到，就是说我们怎么去在在整个事件管理，问题管理，还有整个变更，其实都是在整个流程的框架体系之内的，它都是在整个价值流的一个环节里面，成为里面的一个元素。那么我们会发现这里有一条改进的线，就是它是不断的改进和完善的，我们在服务过程当中发现的问题，客户满意度不满意了，我们要去分析原因啊，然后去构建，获取，设计与转换，然后交付与支持，最后呢在不断的改进，根据数据不断的改进，形成一个循环，这就是I4里面强调的一个价值流。只是一个组织负责创建产品和服务，并将其交付给交付消费者的一系列的步骤。那这就是我们整个理论框架上的一个东西，那我们刚刚讲了这么多，我们为什么用来做To B的服务呢？那其实这就是一个有方法和无方法的问题。

当没有方法论的时候呢，更少的人做更更多的人做的更少的事情，整个效率是低下的，而且呢，整个埋头的干活啊，依赖一些bad case来驱动优化，而且呢，我们会发现啊，我们更加的依赖依赖某个角色的一个主观能动性了。当如果如果这个人离职了，或这个人这个人他生病了，那我们发现好像整个流程都走不下去了，那有方法论的情况下呢，我们会发现整个的思想都是统一的，我们的流程是明确的，就像刚刚讲的那几套流程啊，提高整个效率，同时呢，通过数据来驱动优化，最后呢，我们会发现会降低对单个角色的依赖，铁塔的铁塔的流的，那么我们发现it服务管理领域普遍被世界各大领域和组接，其实就只有艾。那这一点就是我们刚刚讲的目的。

那在里面有哪些基本的流程呢？这是我列了几个重点的流程，因为我们可能考试会涉及到的几个流程，尤其是红字的部分，大家可能要重点关注一下，那第一个就是事件管理啊，Incident management事件管理，那事件管理的一个特点是什么呢？其实就是在短时间内，尽量短的时间内恢复中断或性能下降的it服务，比如说客户突然啊。出现了客户，现场出现了一个一个。故障这个时候呢，我们就需要在尽快的时间内把这个问题给恢复啊，把这个事事件给恢复，那么在这个目标其实就是为了响应处理事件啊服务请求啊，确保信息技术服务的一个稳定性，那是会经历哪些过程呢？啊，其实就是我们啊，当我们的交付人员在现场客户出现了问题，那这个时候呢，我们要进行然后分类，然后分优先级去跟进，最后呢，确认这个问这个事情是不是已经解决了，那这一套整个的流程就是我们事件管理要做的事情，那等一下我会讲一下，就是在安里面事件管理是怎么跑的，以及哪些角色，这里的话我们大家只需要了解啊，事件管理其实就是在尽量短的时间内恢复，恢复中断或性能下降的it服务，就可以了。

那么试点管理，其实它并不一定要找到问题发生的根本原因的。那就有点类似于在医院里面，医院里面可能我们首先。你生病了啊，这个事情我们就当做一个事件啊，你生病了是一个事件。但是呢，这个事件啊，医生呢，可能会说，比如说你发烧了，那医生可能会给你啊，呃做一个呃这开一个那个退烧药，赶紧把这个烧给退下去啊，其实这个事情就是一个事件，然后呢，我们尽可能的把你这个呃退烧给退下去了，就把你这个事情给恢复掉，让你先暂时恢复正常，但是发烧之之后的根本原因是什么呢？就需要我们的整个问题管理来承载，那什么是问题管理呢？其实它的目标就是要找出并消除引起事件的根本原因，从此避免事件的再次发生，那么呃，结合到刚刚那个发那个发烧的这个事件啊，那我们。

发烧了，那医生开了个退烧先退了，那这个时候呢，你可能会去问啊，医生为什么为什么为什么会发烧啊，医生可能说啊，最近这个天气啊，变暖啊，最近怎么怎么样，那可能会给你制定出根本的原因是什么，然后同时会告诉你以后你遇到这种事情要怎么办，那这个时候呢，其实就是重点关注并找到这个事情发生的根本原因，并制定完善的解决方案，实施落地，彻底解决，不再重复发生。那这种情况下呢，其实就是我们问题管理要涉及到的，涉及到的一些概念，这里红字的部分大家需要了解，管最大的区别就是试电管理，它只需要恢复。而问题管理要找到问题管理，耗时通常比管理要长。

那么第三块就是我们的变更发布管理啊，就是变更发布管理，这里呢啊，主要的一个目标是对it的组件的变更发布过程加以管理和控制，避免信息混乱或恶性事故的发生。那这个时候呢，就有有点类似于一个手术室了啊，一个手术室啊，当一个人生病了，首先我定位员，呃，首先我把你尽量呃暂时先把你这个给控制下来，就事件管理，那问题管理呢，就是说我找到这个病的具体的原因是什么，那更管理就是我怎么把这个病开始，比如通过手术的方式也好治疗了，治疗也通过手术或者通过药把这个病彻底的给他治疗了，那就是那对整个it的组的变更加以免信息恶，有个就常为常规和急准名，刚刚那个啊do瑞也讲了，那么基本上都是从事件问题啊，还有一些主动变更来发起这个变更发布的流程，那么变更结束之后会更新到C啊，更新到这个置管理当中去，那更新到里面去有什么作用呢？就成为了我们后续的一个，后续的一个。

包括一些组件库啊，不断的去更新这些组件库，那以后当遇到重复问问题的时候呢，其实我们也可以快速的通过问题管理的问题库找到答案啊，通过CMDB去找到这个，呃，更新更新上来的一些比较新的版本啊，新的点新的组件，那么我们通过CMDB就能找到。好，那么几大流程之间有什么关系呢？这个图就是事件管理啊，是为了先把先恢复恢复恢复整个事件，然后呢，对这个事件进行更的话，就事件趋势分析啊升级为问题。

我们让重复问题不再发生，这是问题管理，那需要变更了，那我们就走一个变更管理，然让整个的变更流程可控，变更管理里面涉及到大量的审批啊，审批最后呢，我们变更完成之后，可能要更新到整个的变更发布完成之后，要更新到我们的CM里面去。这就是的啊，几大流程之间的关系，那我们快速的就是呃，说一下具体的一个需要关注的点啊，第一个点就是啊，我们的它到底。艾，他在整个安体系里面到底是怎么去体现的？涉及到几个环节，另外就是的一个价值啊，它的价值共创，目前服务消费者跟商之间的关系是什么。另外就是说我们的整个价值流是怎么体现的？就是我们为什要用做个方法。

这几个核心的一个流程，大家需要对红字的部分进行重点的掌握。那么刚刚讲到了是一个相对大的一个概念，那我们讲一下在安登安登这个平台我们怎么把进行落地的。第一块呢，我想讲一下他安登他解决了什么问题。在没有安之前呢啊，可能我们对于客户说，客户经常会追问灵魂追问就是我这个到底出了什么问题啊，原因是什么，有多久解决啊，为什么这么慢呢？就是客户有经常这样的吐槽声。我们没有办法给客户一种确定性。原因是什么呢？那就是我们的没有顺出呢，客户这都进。那么有了安灯呢，它实现了一个端到端的一个流程。大家可能在腾讯官网提工单就能够发现，我们工单提出之后，客户是能够看到整体的啊，问题的流转的进展，以及说及时的同步，也有很多的状态让客户来选择，增加客户的确定性，最后问题结束了，结束了之后呢，就会这个事情就会让这个客户进行呃单评价整个流程是端到端的。

那面对客户的灵魂追问，我们通过流程进行把控。第二块就是呢，对于内部而言，如果工具和规规范标准化，它是不规范的情况之下，整个协作非常困难的。那于是呢，就会造成一些啊不自动化。啊，缺少流程固话，同时你一个问题，你可能到东问西问，一下问一线，一下问二线，然后到处去问群去问，我们会发现。一个问题可能会惊惊惊动所有的人啊，但其实可能我只要去找到对应的合适的人，真正来解决这个问题的人来解决就好了。那么第三块就是对于整个优先级的区分啊，以前问题只要来了，我们都把它当做高优先级来处理。

那这个时候我们会发现到底解决了什么问题？其实我们解决的工具流程的规范化的问题，整个协作更加的顺畅。那服务流程的闭环，同时我们还能够针对不同的环节持续的改进闭环就是说客户的问题来了，那最后呢，我们要反馈到客户问题那里去，那同时呢，在每一个环节里面，我们都能够对整个客户的每个环节进行考核啊，比如说客户一线啊，面向客户那一线有及时响应客户呢，这是一个考核的环节。那么整个问题我们快速解决呢，啊，在每个环节停留多长时间呢，我们也有考核，那不同的环节哪个时间长了，我们对对这个环节进行持续的改进，那其实就是我们安灯要实现的服务流程的一个闭环，同时呢，要不断的持续改进，这是我们要做的事情。那为什么要叫安灯呢？其实这是一个，呃，一个故事啊，就是安灯，它其实源于一个传统行业收集流水生产线上设备和质量的一个信息管理工具。

啊，在这其实是来自于日本啊，就是说我们在在整个呃，丰田创业啊，他们在这种创精的这个理念之下，他们有一个叫安灯的一个机制。安灯就是一个可以拉下来的一个灯，一个一个响铃一个灯，那么呃在整个呃工厂流水线操作的时候。如果说比如说第一个人把这个问，把这个这个事情处理完了，要留给第二个人，第二个人发现这个问题有这个事情有困难啊，发现好像出现了问题，出现了bug，他就立马会按一下那个灯，按灯把这个灯给按小，这个时候呢，整条流水线都会停止下来，然后那个管理者或者是对应专业的人来对这个问题进行解决。那么对应到我们的啊，这样通过这样的一种流程方式有什么样的好处呢？他不会把一些错误的问题继续的流转下去，同时能够集中精力的把这个错误的节点给它解决掉，然后把这个问题继续继续的流转下去，我们会发现整个流程是可控的，那对于安灯里面是怎么来来来实现的，当我们一个问题啊，呃，比如说录了一个事件单，它是一个事件啊，录了一个事件单，那么这个事件单流转到后面二线的时候，或者是流转到1.5线，转专家团队的时候，突然间发现这个问题我解决不了了。

那我怎么办呢？那我可能就需要升级来解决，通过转单的方式，那给到我们的后端的产品研发团队，那产品研发团队呢，就会对这个问题紧急的进行排查，然后呢，最后啊，排查结束之后啊，整条线又继续的下去，然后呢。这个是整个我们吸取了整个安灯的整个流水线这样的一个精髓。那么围绕整个安登服务流程平台呢，我们也在建造一个智能化，工具化，数据化的一个平台，这里的话呢，大家要了解一下，就是目前我们整个安登，它其实安灯是一个大的一个概念啊，它包含了所有啊这些概念，大的一个概念，那么这里涉及到一个小安，就这一块，它其实是一个服务流程平台，就刚刚讲到的啊，变更管理，事件管理，问题管理，都在这个服务流程平台上面进行管理。

那么它打通了整个服务的渠道，推动问题的解决，那同时呢，我们还有三个小伙伴啊，一个是安置啊，就是智能机器人啊，可能会提升自助解决能力啊，比如说呃，客户提的一些问题能够自助帮忙解决啊，减少单量，那也减少了我们的人力投入，那么安兔呢，就是工具平台啊，简化运维操作的一个好帮手啊，这样的话呢，我们可能尽可能的缩短问题解决的时间，还有个安数啊，安安呢，就是说整个过程当中，我们刚刚也提到了啊，就是我们怎么去持续改性优化呢，我们是需要数据的沉淀的，那么只有通过一个自动化的数据报表，我们能够帮助我们指明服务改进的方向，那这里就是一个要做的事情，所以如果我们整个应商你在，呃，你是一个负责人，你可能需要对整个过程，每个环节过程进行分析，那么来联系安数安就好了，它可以它是一个自动化的一个数据的报表平台。

那简要概括一下啊，就是安灯，它实现的价值是什么呢？第一块就是就是向后传递疑难问题加速后传加速问题的解决，一个工单，它可以串联各线的资源，一线1.5线产品研发团队，无论是串联供应商也好，合作伙伴也好，还是还是串联到我们产研也好，此外呢，就是我们整个问题都是有模板化的，减少低效的交互，还有一些催单优先级S的一些功能，然后明确整个问题的紧急程度，岗位是非常清晰的一个岗位流程规范和责的，最后就是PC端移动端能够尽量避免整个单，那向前能是什么呢？怎么去减少工单，怎么去提升一线的解决能力呢？那这涉及到了安置安兔啊，安安安迪，这里还有一个安灯指引啊，不叫安置安灯指引啊，提供一个知识库的一个平台，助力经验的沉淀。

啊，刚刚，呃。我们刚刚讲的所有的内容都能在安灯指引上找到相应的课程。那么我们今天会重点再来讲一下什么是小安灯，就我们刚刚讲到的一个服务流程平台，服务流程平台小灯。这也是我们整个考试可能重点部分啊，小安灯呢，其实就是一个端，刚刚讲到了端到端的一个工作流程，平台通过明确的A的责啊，通过线上化和透明化，助力腾讯客服运维产共同提升客户的口碑，它有几大特点，第一大特点就是我们肯定是要以客户为中心的。

客户的问题一定一定要对他负责到底，同时受客户的监督。第二块就是我们会通过控制ola的方式来保障S，提升整个解决的效率。等下我也会明确的讲一下什么O，什么是SOA，他们之间的区别是什么。另外就是我们一定注意是一个分工协作的流程平台，它涉及到前后端的分工协作，同时是一个迭代闭环的，它要持续的提升整个服务的水平。最后呢，我们会讲到一个，我们是通过事件问题变更发布三大流程。紧密的配合来实现这个完整的服务闭环。那我们来具体讲一讲啊，就是里面的事件管理，事件管理。其实结合刚刚我讲的的事情管理，其实呃，这就是我们安登如何去落地的一些流程体系啊，首先我们要强调一下，就是再回顾一下，就是首先试件管理是为了快速恢复业务。

然后呢，降低损失，那这里会涉及到一个优先级的概念，当我们遇到很多很多的客户的一个需求啊，来来到你面前的时候，你当然是需要通过优先级，然后来进行啊进行处理，不然会处理不过来啊，同时不同优先级也会触发不同的流程，比如说呃，在公有云这边可能会涉及到，比如说你如果创建了一个优优先级的单子，可能会被触发一键拉起腾讯会议。快速的有人介入到你这个问题里面，来帮助你来解决这个问题啊，这些流程其实都有，所以优先级的选择，第一要合理的利用，第二呢是一定要慎重的选择啊，因为我们要合理的评估，到底是不是真的紧急，那怎么来评估呢？我们等一下，后面也有专门的一页来讲，第二块呢，是我的。那我们来再讲一下事件单的生命周期啊。首先建单啊，建单客户过来我们帮他建单，建单完成之后要响应啊，可能会收到提醒，我们打开工单，那响应完要处理，处理完要转单，如果解决不了要转单，在处理过程当中，我们要明确处理人，明确优先级啊，内外部回复要控制好，填写处理信息，必要时候呢，一键拉群，要拉起群聊，我们来共同解决这个问题，扭转工单的状态，那转单呢，就是啊转当前处理人，转客户代表，那同时问题解决了怎么办呢？啊申请单啊，评价客户评价。

生命周期大概就是这样的一个流程，我这里就不详细讲了。那事件单里面有几个主要的角色，第一客户啊，这里这我就不用说了，那客户代表啊，客户代表其实就是呃，可能就是在座的各位啊，As啊，就是合作伙伴，那么他可能成为客户代表，比如说呃，跟客户直接一对一的，面对面的进行直接的沟通，那么每一个工单同时只能有一个客户代表。

它不会存在，同时只能有一个客户代表，这个叫同时的概念是什么？就是说啊，整个工单的在这个流程里面。在某个环节里面可能存在一个客户。那什么情况下存在两个呢？只有可能是说在在呃，你把这个问，你把这个单子转给了别的客户代表，转给别的别的同事，这个时候他会为客户代表，所以客户代表的职责角色只会有一个。就在一个流程里面只有一个。那当前处理人，当前处理人就是说整个事件恢复解决了一个当前负责人，每个工单同时也会只有一个当前处理人。这就是安登的整个理念啊，安登就是我们整个问题，呃，问题的处理，且只有一个负责人啊，一个一个一个处理人，那事件发起时和客户代表，客户代表如果一开始建了个建了一张工单，那么这个时候客户代表其实也是当前处理人，客户代表把这个单子转给了，比如说转给了专家团队，那么这个时候专家团队就是当前处理人。

啊，这个客户代表要全全程跟踪整个整个服务的一个流程，他并不是把单转完就没事了，他要对整个。环节进行跟进的啊，这一块刚刚昨晚应该也有讲过。那当前处理人呢，可以有什么呢？可以呃，通过转单啊，变成专项运维产品研发团队。那经人指的就是处理当前世界的所有的人，这些都算经人。那问题管理是什么呢？问题管理的目的是为了找到消除，刚刚一直在强调。防止重复发生，从而减少这个事件啊，从减少事件。

问题单的一个流程是这样的，首先创建一个问题单，一个审批，我们审批到底是不是问题单啊，是不是共性的问题。如果它只是一个很简短的一个临时恢复的一个事件，一个问题，那么它就是一个事件，就还一个问题，就不应该走问题管理的流程，那么到处理环节呢，就是要分析更因，制定临时的解决方案，同时还要给出一个最终的方案。然后呢，转助理人申请单。问题管理有几个角色，第一个叫问题经理，问题经理是负责这个问题的审核、推进和解决的。其实整个问题的。有点类似于客户代表，但是他又不是一个概念啊，问题经理呢，主要就是要负责整个问题的审核，当这个问题，这个事件，事件升级为问题的时候，那么问题经理要考核说这个到底是不是一个问题，是不是共性问题呢？那么这个时候呢，就需要问题经理的审核，那当前处理人呢，往往就是一些产品研发团队的人，他可能要验证这个问题他到底是不是真实存在的啊，以及它的准确性，如何进一步的收集相关信息，并进行一些分析，及时的更新原因，然后给出临时的解决方案，除了给出临时解决方案之后呢，我们还要有一个改进措施，然后呢，录入问题单，然后呢。

对这个问题进行持续的跟进，那每一个改进措施的背后，因为问题管理本身就是要把这个找到，同时要给出规避的措施嘛，那么可能会有多个改进措施，那么改进措施里面就要有不同的改进人是什么，要落地到人。整个流程才能跑顺。最后就是变更管理啊，变更管理的目的就是为了实现这个，把这个变更的风险管控起来，降低业务啊，对对业务的整个的影响里面就包含几个环节啊，比如说变更方案的评估与授权，变更资源的协调和安排，以及变更的记录啊。

那变更管理要解决什么痛点呢？其实啊就几个一块，就是缺少审批流，那一没有变更管理的时候呢，我可能想发布就发了。但这个时候你到底有没有发布的这个资质啊，以及说你发布的整个流程规不规范，客户到底同意了没有啊，其实这些都是不可控的，那很容易造成客户的投诉，那这里的话有涉及到几个工具层面的，比如说过程管理，每个步骤该谁来处理，没有变更管理就不可控。第二块就是部门协作，它比较跨，部门协作是很困难的啊，比如说其实产品研发团队跟我们整个服务团不在一个部门里，那这个时候怎么去协作，怎么把整个的流程啊，是否部署，部署是否成功啊，发布是否成功，把它串起来呢？其实就需要一个变更管理来把它管控起来，那么在工具层面还有一点就是说在整个处理变更的时候的效率和风险，我们要通过质量的方式。

来进行沉淀下来，然后呢，对每个环节进行管控，那最后的就是在执行层面上可能缺少一个统一的CMBB，也就是说我可能。发布了，但是这里的一个组件啊，并没有更新到我们的整个整个CMDB里面去，在我们后续的整个呃流程里面就会发现啊，无论是试验单，无论是问题单，我们发现诶缺少了一个组件，那这个组件其实之前已经发布过了，那这个时候其实就会发现没有变更管理，可能就在整个执行层面上会缺少一个CMDB，而变更之后往往需要把一些信息是同步到我们的MDB里面去的。所以这里就涉及到了变更管理能够解决的痛点问题，风险可控，跨部门协作，过程管理是可控的，信息是同步的，最后呢是可视化、量化帮助我们来持续改进的。变更管理也涉及到几个角色啊，首先这里变更阶段的一些活动，包括一些啊，一线的建单啊，收集客户的信息，产品的信息，准备变更的基本信息，同时会有一个变更的控制表。

这是目前已经在跑的流程，那第二块呢，就是啊审批的环节到底是由谁来审批呢？每个审批的环节里面需要对整个信息进行一个监控和把控，同时呢，对整个呃实施人的资质进行管理审核，最后是到一个部署变更的一个阶段，那我们要严格的按照变更控制表来实施变更，变更后呢，也要及时的通知到整个PM，及时的上升联系到P，然后呢，同时对变更异常进行紧急的一个支持，如果变更失败了，也要协助出具一个变更的报告，那最后就是客户的验证，只有客户内部验证了啊，我们才能够当做变更啊完成成功了，那么验收失败，如果验收失败了，要及时的对验收进行一个复盘。变更的整个操作流程大概就是这样的，整体的一个流程是啊，首先确认整个变更的来源啊，建单，然后建变更单，然后审批的环节，部署的环节，最后是客户验收的环节。

首先在操作层面上呢，有几个来源啊，变更啊，行业的人客户也可以啊，也可以对这个发起整个变更的，然后呢，产研运维，主动维护这几个都可能成为一个变更的来源，然后呢，呃，我们的一线或者是变更负责人去建单，然后呢到审批。PM审批，审批通过单转单leader啊，指定的一个操作人，最后结束的部署。最后的一个客户验收的一个环节。好，那我们刚刚其实讲到了我们整个呃内容中最重要的几个环节，就是我们整个安登目前基于承载的角色有哪些？第一块呢，就是事件管理，事件管理的目的是为了快速恢复业务，然后在事件管理过程中要遵守一些流程的规范，比如说我们要明确优先级啊，然后同时呢，我们要明确客户代表和当前处理人之间啊是什么关系。

每个工单同时只可能存在一个客户代表，当前处理人呢，也要对整个呃问题的处理进行一个负责，当然客户代表不是说我把单子提完之后就完事了，我们客户代表还有一个职责，就是他需要跟进整个问题的处理的过程，同时呢，要向客户进行求证，这个事件到底恢复了没有。那在问题管理呢，就基于事件管理啊，我们要。找到这个消除根因并找到找到根因并消除因，防止重复问题发生，从而持续的减少这个事件。在整个流程里面呢，涉及到建问题单，审批、处理、转单和结单的几个环节，问题单的整个角色涉及到问题经理，他需要一个审核的角色，他也是问题单的owner，那当前处理人呢，要及时的去啊，验证这个问题的一个真实性和准确性，同时要更新问题发生的原因是什么啊，给出临时解决方案，以及未来的规避和改进的措施，那另外要明确整个改进人，改进人呢也会对整个每个每问题的每个改进措施负责，直到完成为止。

那变更呢，主要为了就是对整个变更过程进行一个风险的一个管控，降低对业务的整个影响。变更就涉及到了呃几个解决的几个痛点，就是让整个变更风险是可控的啊，让整个跨部门的协作是顺畅的，同时呢，对整个过程是有监控和管理的，信息能够同步到CMDB上，然后呢，呃，即使不要造成信息的混乱，然后同时呢啊整个的变更过程是可视化，可量化的，对每个环节进行一个监控和管理。变更里面也涉及到一些角色啊，一线啊，PM的一线主要负责建单啊，PM有一个审批的环节，同时在部署环节里面呢，一线在部署的时候呢，要变更之后要及时的通知PM，同时啊，如果变更发现异常的情况，要及时的去联系处理，如果变更失败了，要协助出具变更的报告，那客户验证成功之后，整个变更才算完成。

那最后的我会给大家讲一下这个我们安灯里面必须知道的几个概念，还有整个功能点啊，也协助大家之后再做整个事件问题变更时候的，呃，整个。过程会更加的顺畅。第一点呢，我们要讲到一个SL啊，S就是我们的整个服务，服务级别的管理啊，服务别的管理到几概念SOLA啊，我们可以看这张图，S呢，其实简单的理解就是整个组织，我们的组织，比如说腾讯云对客户进行一个承诺啊，比如说我们承诺啊提时24小时服务，我们承诺三分钟响应你我们承诺怎么怎么怎么样，这是我们对客户的承诺，但是呢，我们要实现这个承诺容易不是容易，为什么呢？因为。

啊，整个组织之间，内部组织间的协作，每个环节都要保障，就是ola，我对一线的考核要求是啊，比如说我们三分钟要响应你，那么一线的考核环节就是啊三分钟啊就要响应这个客户三分钟就ola的告警，那如果说客户我们要求啊24小时内解决，那这个时候我们要对每一个环节协作的环节都要进行管控，就比如说一线的ova就是三分钟要响应，同时呢，呃，一线解决的时间必须控制在呃呃是三个小时。然后呢，如果你不解，解决不了，及时的转给后端的产研，而后端的产研解决时间呢，要在要在呃，就是四个小时。那通过这样的ola不断的O的控制来共同的保障s sa LA的完成。那这里还有涉及到一个供应商啊，UC供应商，供应商这里呢，就是啊可以也是跟这个我们内部组织之间形成一个一个这样的一个和一个协议之间的关系啊，我们把这个组织比如说。

把这个活儿交给合作伙伴，合作伙伴也要有一个保障，然后自己者共同推进我们的S的实现。所以呢，我们要强调啊，控制ola才能保障SO，我们可以看这张图就知道了，一线啊，转单一点五线，二线三线，它其实是一个流程。每个环节ola都是不一样的，比如说你是三分，你是五分钟，你是七分钟，你是一个小时啊，那每个ola都能保的情况下，S自然就能够保障。那另外呢，我会，呃，我们来看一下就是什么情况下。O在体现在我们的整个呃安灯里面有个应用啊，就是告警。告警，我们通过ola的告警，及时告知工单的进展，对风险进行提示。

常见的告警呢，就是比如说客户催单告警。响应时间过长的告警、更新时间过长的告警及解决时间过长的告警。其实看这个字面就非常好理解啊，客户催单啊，比如催了好几次了，这个时候系统会发起报警。那第二块是响应时间，客户已经发起这个这个需求了，那这个时候呢，我们半天没有回应他，这个时候呢，系统识别到你三分钟没有响应了，那我也会发起一个告警，那么更新时间就半天没有，呃，回应客户，或者是我们的同意，同意给客户更新进展，但我们没有继续做下去，那其实这里有个更新时间过长的告警，最后就是解决时间，整个问题已经持续了一个月都没解决了，这个时候也会触发告警，那具体的整个告警会根据不同的业务来定，告警的时长也会根据不同的岗位业务来来来来来来确定，那整个告警时长有哪些影响因素呢？第一块肯定是优先级。

啊，很简单的理解啊，优先级越高，告警时长肯定是越短的，比如说最高优先级的，可能有舆情风险的，那我们可能三分钟就要响应，而有一些比较普通的，一般的一些一些一些事情呢，那可能我们一个小时响应就可以了，所以告警的时长是跟优先级相关的。其次呢，不同的岗位，不同的岗位也会对告警时长有所影响，比如说一线和产研，它的告警时长就是不同的。那另外呢，就是我们的工单的来源啊，工单来源比如说什么叫工单来源，就不同的业务啊业务，比如私有云的业务，公有云的业务啊，客户属性不一样啊，大客户还有一中常委的用户啊，他呃来源不一样，那么这个时候告警时长也是不同的，就这一个告警的类型，就刚刚讲到的啊，响应时间，更新时间，解决时间啊，这些告警时长其实都是不一样的。那我们既然讲的告警，那么给谁呢？给谁呢？啊，其实这里有一张非常动漫的一个图片啊，就是它其实是一个双责任人，什么叫双责任人呢？就是双责任人就是客户代表和当前处理人，所以通过这张图我们就能够发现，比如说告警三分钟，我们告警到当前处理人。

啊，可能六五分钟我们就告警助理人和客户代表。十分钟我们会告警，呃，就是持续的，往往就就持续往上去告警，那么这里讲到一个双责任人，通过我们双责任人呢，我们就会发现一个点，客户代表和当前处理人永远是不分开的，也就是说在一个工单里面，客户代表并不是说把这个单子啊，呃，就是转转出去就完事了，而是说他跟进处理，当前处理也有卡点嘛，那么客户代表也要及时的啊，介入处理啊，比如说客户也有投诉了，我们也要及时的向客户代表反映，呃，向当前处理人进行反映，所以呢，客户代表可以理解为他是一个联系当前处理人和客户之间的一个沟通协作的一个桥梁。

那这一块呢，我们就要呃了解客户代表啊，比如他是一个沟通的角色，那么我们必要的时候呢，啊，就要对这个客户代表当对对整个问题的进展进行更新。告警的渠道啊，目前我们对合作伙伴开放的渠道呢，就是呃，有个就是。企业微信啊，企业微信啊这样一个告警渠道，个人微信呢，目前可能合作伙伴还是没有办法用到啊，基本上是用企业微信的方式去告警的，企业微信有一个叫安登企业号的后面如果呃各大的合作伙伴接入进来之后，就会有这样一个安登企业号的存在。那第二个概念叫优先级啊，我们优先级其实很好理解，我们为了合理安排处理力度，明确优先级，那安灯工单在处理前后处理中都会明确优先级，帮助工程师合理的安排处理时间以及投入的力度，让工单处理流程更加的有序啊。告警优先级的高低，其实呃刚刚也讲到了，会跟着告警升级。

也息息相关。那安登是怎么去明确优先级的呢？为了减少大家的误判啊，比如说A同学认为这个这个优先级就应该是紧急，B同学觉得这是一般就行了，那为了减少误判呢，安登给了一个优先级的矩阵啊，影响度和紧急度来共同判断这个优先级，比如说影响度为四啊，紧急度为几，然后同时呢，结合客户等级和催单，那我们就能够啊把帮你们去实现啊优先级的定义啊，定义出一个高优先级的，或者是什么减少在整个的呃，问题处理过程当中的一个优先级的误判啊，造成资源的浪费。好，这是一个优先级的一个概念。之后呢，有一个概念，呃，一个功能点叫讨论呢，这个讨论的话，目前是只开放给合作伙伴的啊，也就是说什么情况下会用到讨论呢？就是讨论在我们工单处理页面的右下角，有一个讨论的一个功能点，那么什么情况下要讨讨论呢？就是我们可能要跟腾讯云的工程师进行协作。

但是呢，工单的协作速率往往是比较慢的，或者是工单里面往往是记录一些比较重点的问题啊，比如说结论啊，比较长的一些问题，一些结论，那这个时候的话。我们的整个，呃，但如果这个时候我们要跟腾讯工程师要要联系，我们怎么联系呢。那我们也没有共同的企业微信啊，加微信有时候我也不知道他的微信是啥，那这个时候怎么办呢？我们就能够在讨论这个功能里面啊，对这个呃，进行联系到我们的腾讯的工程师。那通过讨论的这个功能，我们的整个消息就会推送到各自的一个企业微信里面去啊，他也会在这个里面进行响应你，你也可以在这里面回应他啊，就是这样一个打通不同企业账号之间的沟通，尤其是合作伙伴的账号和腾讯云账号之间的沟通，目前是没有沟通桥梁的，我们得通过。

讨论功能。最后就是一个安灯指引啊，安灯指引在我们安灯顶部的导航的最顶部啊，有个安灯指引，那我们所有的具体操作课程都能够在上面看到全面的讲解，我刚刚讲的其实都是非常粗的啊，非常粗略的一些讲解，比如说艾啊，以及说具体的一些流，呃，流程解决什么问题啊，当然我们考试也会考的很粗，那么这个时候呃，如果大家要对这里面的详细操作进行一些理解的话，我们上这个安灯指引没有权限的控制啊里面。根据这个职责，比如说你是私有云的一线啊，可以进去。你是管理员，你还进去能够看到相应的课程。最后呢，我们再来回顾一下几个必须了解的安顿术语和概念。

呃，我我我我会带大家过几个啊，这里所有几个呢，可能大家不需要全部的去去掌握，但是基本上要有个概念，按我们平常讲的安登单，其实是安灯体系下所有工单的结合。啊，包括刚刚讲到的事件单，问题单，变更单，故障单，可能合作伙伴还用不到。那就是这几个事件单变更单，目前合作伙伴用的最多的。这是安顿单，事件单呢，指的是客户主动提交的问题咨询、技术支持的工单。啊，技术这些工单。那么这是事件单。而问题单呢，是为了找出导致以前事件发生的根本原因，以及提出解决措施或纠正的。这种叫问题单，找根因的问题单。啊，所以以后呢，我们可能在沟整个沟通交流的时候，我们尽可能啊，不要提说啊这个问题，这个问题其实很容易就理解成是问题。

那可能我们要强调就是尽可能的事件啊问题。我们来进行沟通协作。变更单变更单要理解的变更单，就是为了规范技术变更的流程，明确相关角色。同时呢，要规避不不规范变更带来的一些啊，客户投诉的一些风险，提高产品服务质量啊，这样的一个变更的一个工单，这样的一个工具叫变更单。我们在这一页，我们需要了解到安登单是什么，事件单是什么，问题单是什么，单是什么这四个概念就可以了，其他几个概念的话，大家可以呃自己去看一下。那么这里还涉及到几个概念，还是刚刚那几个事件，其实它是一个被动的任务。以确保用户可尽快恢复自己的正常业务。恢复业务是我们的目标，我刚刚讲到的，你发烧，医生赶紧给你退烧，那就是一个事件，那问题就是我们要除到除，这是一个问题。

所以在我们考试题里面也会有一个场景题，类似于说啊，这个你是你是什么什么人，那你可能涉及到业务出现了，出现了什么问题。那如果涉及到找到的，那其实它就是一个问题，如果涉及到要快速恢复的，那其实是一个事件。那变更就是添加、修改或删除可能对服务产生直接或间接影响的任何事物。在环境里面发生的任何一些增删改，查增删改啊，可能都是跟变更相关的啊，就是变更。好，那我基本上呃，就讲完了，我们整个安登平台在腾讯最实践这一块的一个课程，我们在最后来看一下这几块的一个概念。第一块，我们为什么要来做云服务呢？啊，因为有方法论和没方法论当然是不一样的啦，那就聚焦到我刚刚写的那一页，第二块呢，就是我们这个流程解决了什么问题呢？啊，试点管理解决是要快速恢复业务问题，管理是要找到更因，变更管理呢，要让变更的过程可控，有审批的流程可控，然后解避免一些不必要的风险。

那我们能够区分事件、问题、变更之的概念吗？啊，事件它是一个被动的一个概念啊，刚刚我的术语表里面有写问题要找到根因啊，并解决根因，那是一个问题，而变更它其实就是一个增删改，整个环境里发生的变问题都叫变更，所以变更和变更管理是不一样的。变更主要指的就是说在环境里面发生任何变动，它是一个变更，它是一个动作。它是一个动作，而变更管理它其实是一整套，是一个流程。涉及到不同环节之间的协作，这是变更管理，这里到时候可能也会有考到。

那么在安灯层面解决了什么问题呢？我们为什么要安灯呢？啊，解决了什么问题呢？啊，就是端到端的一个流程，让客户问题是能够用端到端的问题是就让保证客户的确定性，同时呢，安灯还解决了一个协作的问题，保证各方在协作的时候能够快速更加的高效。其次呢，安灯还聚焦于持续的改进整个服务的流程，通过数据的呈现，来来来来实现整个的流程。那么那整个在灯里面还涉及到一个，呃，就是其实就是一个大灯的理念，那么这里的灯指的是大灯。大。里面刚刚也会讲到一个安啊，安就是聚焦于一个，呃，数据啊，怎么去数据报表，然后驱动整个整个服务的改进，有安迪塔就能够来实现，那安登有三大流程，事件、问题，变更，它的定义关系，涉及到哪些角色呢？大家也需要有一个大概的了解。

三大流程性的规范是什么呢？啊，这一点其实可能刚刚两位老师有讲到，最后就是安登当中必须知道了几个功能，O啊，优先级这类的概念，我们要通过啊，保障O来来规范ola，来保障S啊，这这一点啊大家要了解，那优先级呢，要通过啊。影响度和紧急度来确认优先级，要合理确认优先级啊。那以上呢，就是我们要讲的安灯这一块讲的所有的内容。大家来看一下有没有什么问题，然后我们呃几位老师也会在线上进行解答。嗯，非常感谢我们三位老师，然后现在呢，会给大家一点时间，可以线上，呃，问一些问题。大概可能呃，两三分钟到五分左右吧，如果没有的话，那就可以呃在线了。

然后课程的话呢，会在呃合作伙伴学院上呃放置会有呃这次的这个录屏，然后还有学习的课件，然后呢，明天呢，将会进行一次这个考试。