云计算中心运维事件与问题管理流程

1、云计算中心运维事件与问题管理流程目录 HYPERLINK l _bookmark0 技术中心综合运维管理流程设定4 HYPERLINK l _bookmark1 流程管理的目的4 HYPERLINK l _bookmark2 关键角色、职责定义4 HYPERLINK l _bookmark3 技术中心运维服务台一线运维人员4 HYPERLINK l _bookmark4 二线运维人员5 HYPERLINK l _bookmark5 项目经理5 HYPERLINK l _bookmark6 流程管理负责人6 HYPERLINK l _bookmark7 岗位与方案角色的映射7 HYPERLINK

2、 l _bookmark8 事件管理9 HYPERLINK l _bookmark9 事件管理的目标9 HYPERLINK l _bookmark10 事件监控的范围9 HYPERLINK l _bookmark11 事件的分类9 HYPERLINK l _bookmark12 L2C 针对事件流程的处理分级9 HYPERLINK l _bookmark13 事件处理流程10 HYPERLINK l _bookmark14 流程图10 HYPERLINK l _bookmark15 流程描述10 HYPERLINK l _bookmark16 与其他流程的关系11 HYPERLINK l _b

3、ookmark17 和变更管理流程的关系11 HYPERLINK l _bookmark18 和故障管理流程的关系12 HYPERLINK l _bookmark19 和问题管理流程的关系12 HYPERLINK l _bookmark20 故障管理13 HYPERLINK l _bookmark21 故障管理的目标13 HYPERLINK l _bookmark22 在技术中心允许的 SLA 范围内尽快为客户恢复服务13 HYPERLINK l _bookmark23 对故障进行有效的控制13 HYPERLINK l _bookmark24 为 IT 管理与成本核算提供数据支撑13 HYPE

4、RLINK l _bookmark25 与其他流程的关系13 HYPERLINK l _bookmark26 和问题管理流程的关系13 HYPERLINK l _bookmark27 和配置管理流程的关系13 HYPERLINK l _bookmark28 和变更管理流程的关系13 HYPERLINK l _bookmark29 故障流程设计14 HYPERLINK l _bookmark30 故障管理设计流程图14 HYPERLINK l _bookmark31 故障流程执行原则17 HYPERLINK l _bookmark32 常规原则17 HYPERLINK l _bookmark33

5、 流程关联原则17 HYPERLINK l _bookmark34 责任人原则17 HYPERLINK l _bookmark35 再分派原则18 HYPERLINK l _bookmark36 重复故障原则18 HYPERLINK l _bookmark37 关闭原则18 HYPERLINK l _bookmark38 升级原则18 HYPERLINK l _bookmark39 人员岗位与角色落实原则19 HYPERLINK l _bookmark40 故障工单流转原则19 HYPERLINK l _bookmark41 故障工单状态更新19 HYPERLINK l _bookmark42

6、 流程相关定义20 HYPERLINK l _bookmark43 故障信息项20 HYPERLINK l _bookmark44 故障性质21 HYPERLINK l _bookmark45 故障优先级22 HYPERLINK l _bookmark46 故障响应时限和解决时限22 HYPERLINK l _bookmark47 故障状态24 HYPERLINK l _bookmark48 故障结束代码28 HYPERLINK l _bookmark49 处理是否超时29 HYPERLINK l _bookmark50 客户反馈29 HYPERLINK l _bookmark51 制定各系统

7、应急处理预案29 HYPERLINK l _bookmark52 服务质量关键指标定义29 HYPERLINK l _bookmark53 问题管理31 HYPERLINK l _bookmark54 问题管理的目标：31 HYPERLINK l _bookmark55 术语定义31 HYPERLINK l _bookmark56 问题处理流程31 HYPERLINK l _bookmark57 流程分类：31 HYPERLINK l _bookmark58 流程图32 HYPERLINK l _bookmark59 流程说明：32 HYPERLINK l _bookmark60 流程详解33

8、 HYPERLINK l _bookmark61 问题处理33 HYPERLINK l _bookmark62 问题关闭34 HYPERLINK l _bookmark63 问题后续处理子流程34 HYPERLINK l _bookmark64 问题管理中的相关标准34 HYPERLINK l _bookmark65 问题识别标准34 HYPERLINK l _bookmark66 问题的分类34 HYPERLINK l _bookmark67 问题的优先级标准34 HYPERLINK l _bookmark68 问题转向已知错误的判别标准35 HYPERLINK l _bookmark69

9、问题触发变更管理流程的标准35 HYPERLINK l _bookmark70 解决方案的分类标准35 HYPERLINK l _bookmark71 问题的记录与状态跟踪35 HYPERLINK l _bookmark72 问题的记录35 HYPERLINK l _bookmark73 问题的状态35 HYPERLINK l _bookmark74 与其他流程的关系36 HYPERLINK l _bookmark75 故障管理36 HYPERLINK l _bookmark76 变更管理36 HYPERLINK l _bookmark77 配置管理36技术中心综合运维管理流程设定流程管理的目

10、的技术中心综合运维管理流程的主要功能是尽快解决出现的事件与故障工单，并根据需要查找根本原因，保持业务支撑系统的稳定性，为客户提供持续可靠的运维服务关键角色、职责定义云计算中心技术中心管理流程主要分为以下几个职责/角色，分别简述如下：技术中心运维服务台一线运维人员技术中心运维服务台一线人员负责接收所有的事件与故障，对事件与故障进行初步判断与分类，并根据实际工作负载和故障紧急程度响应处理故障。同时，配合二线运维人员完成重大问题的根本原因排查职责： 响应：在指定的响应时间内响应所有提交到服务台的工单、热线电话、邮件等事件报警与故障申报； 事件过滤：对监控报警的事件进行过滤，对需要人工干预的触发事件进

11、行分析与判断，确认后续（故障/问题、变更）流程的创建与维护 事件跟踪：负责审查事件的后续活动，并确保事件录入相关的(故障/问题/变更)流程 故障申报：如果诊断为故障的，需要完整记录所有接收的故障信息，包括：记录故障来源的详细信息、故障描述、发生时间等； 故障判断：为故障进行适当的分类、为故障分配优先级等属性； 故障处理：根据优先级提供有效的解决方案；尝试使用知识库、初步诊断、分析相关信息并决定需要采取何种措施恢复服务并实施有效的解决措施；如果一线不能解决这个故障，应当决定选择最合适的二线运维小组/人员来处理;检查故障记录的处理进度，保持与客户的联系，适时通知故障处理进展； 故障跟踪：与客户确认

12、故障解决方案及客户满意度反馈，关闭故障工单。技能要求： 熟悉技术平台和项目环境 较强的沟通能力 快速诊断故障和解决故障的能力 熟悉事件与故障处理流程，熟悉问题管理流程人员安排： 技术中心的日常维护（包括账单方向、数据库方向、系统方向、网络方向、账户申请等）技能初级人员纳入一线运维中，按日常所管工作内容和支持项目划分到相应支持组中二线运维人员二线运维人员是相关问题领域的专家。负责提供对一线运维人员无法解决的问题进一步进行调研， 找出解决方案并尽快恢复服务。职责: 进行事件/故障的深入调查研究 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动 必要时引入研发 Team、AWS Su

13、pport 或第三方供应商的支持 及时提供有效解决方案 已解决的故障转回一线运维服务台，由一线运维人员关闭故障技能要求： 深厚的技术背景，对所维护范畴的技术深入掌握熟悉事件与故障处理流程，熟悉问题管理流程人员安排： 技术中心的专向技能工程师组成项目经理云计算中心技术中心项目经理负责事件与故障解决过程中的协调和监控，以及对故障升级的判断以及具体执行。监控问题的根因排查进度，并整理最终用户报告。职责： 负责对重大、紧急(P1/P2)故障的解决协调资源，保证故障的最终排除； 当故障优先级为紧急或者故障将超过规定的时限，负责按照升级方法对故障进行处理确保有效协调资源，促进各支持小组（一线运维、二线运维

14、）高效的恢复客户服务； 确保事件流程、故障流程、问题管理流程的有效关联； 确保问题的根因排查能有效进行； 确保正确和广泛地收集和分析故障数据，及时发现和业务相关的问题。技能要求： 了解技术架构和项目环境； 较强的口头表达能力和与客户沟通技巧； 处理纠纷的能力； 深刻了解技术中心事件、故障、问题管理流程； 较强的领导能力。人员安排： 由技术中心专门的 PM 来担任流程管理负责人运维管理流程由技术中心运维负责人从宏观上监控流程，确保相关流程在技术中心范围内被正确的执行。当流程不能够适应项目需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。职责： 确定运维管理流程的衡

15、量指标 确保运维管理流程能够取得管理层的参与和支持 确保运维管理流程符合项目实际状况和公司 IT 发展战略 总体上管理和监控流程，建立事件流程、故障流程、问题管理等流程的实施、评估和持续优化机制 确保运维管理流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进，从而实现技术中心服务的可持续提高技能要求： 深刻理解运维管理流程； 能够很好地理解业务对于运维流程管理的需求； 有决策权，能够确保运维管理流程设计要求在实施项目中得到贯彻和执行； 具有很好的沟通技能，获得所需资源。人员安排： 由技术中心总负责人担任1.3 岗位与方案角色的映射运维管理流程（

16、运维服务台）角色角色细分说明成员职责：负责接收所有的事件报警与故障申报，对事件和故障进行初步判断，并根据实际工作负载和紧急程度对事件和故障进行响应处一线运维技术中心通用支持组理一线运维岗位：技术中心的日常维护人员纳入一线运维中，按日常所管工作内容和支持项目划分到相应支持组中职责：负责账号相关模版开发、资源账单深度分析AWS 账单优化方向岗位：AWS Associate 认证。至少 6 个月以上深度分析过客户账单，完成 3 个完整项目账单优化支持工作职责：负责数据库参数调优、性能分析，架构测试与建议数据库方向岗位：AWS Associate 认证。有 DB 相关认证，DB 专向运维实践工作超过

17、2 年系统与应用运维方向职责：负责操作系统，系统内应用的问题排查与优化岗位：AWS Associate 认证。有 MSCE or RHCE 相关认证，系统运维实践工作超过 2 年二线运维技术中心二线运维网络方向职责：负责操作系统，系统内应用的问题排查与优化岗位：AWS Associate 认证。有 MSCE or RHCE 相关认证，系统运维实践工作超过 2 年CICD 与容器方向职责：负责 CICD 与容器类方案实施，配置调试与流程完善岗位：AWS Associate 认证。Devops 运维开发 2 年以上经验，docker实践经验 1 年以上职责：对架构、系统、应用、权限、安全合规等方面

18、进行全面审计与建议安全方向岗位：AWS Associate 认证。对安全领域有全面了解，做过企业级安全顾问AWS 其它高级服务职责：调研与实践 AWS 高级服务（如 IOT,ML，AI ops 等）岗位：AWS Devops 认证。精通 python 编程项目经理技术中心职责：负责督导与监控公司运维处理过程的正常运转，接收故障的 升级通知和处理超时通知，完成问题根因排查的进度跟进等岗位：具有 PMP 认证。项目管理工作超过 3 年问题经理技术中心职责：开发和维护问题管理流程；回顾问题控制流程的效率和效果；管理问题解决小组；问题处理过程中的资源分配；监督问题处理过程中的进展情况；必要时引入第三方

19、厂商的支持；定期对配置库中的信息进行检查，定期分析基础设施的运行 趋势，主动发现问题；确认问题是否得到解决；问题管理中相关标准的制定； 岗位：由项目经理或二线组长兼任问题评审小组职责：对升级进行授权；解决方案评审；问题处理流程的审计；重大问题处理过程的审计；问题解决小组职责：问题的录入；根据问题的分类和优先级，对问题进行分类、分优先级；问题调查和诊断提出问题的解决方案；及时向问题经理汇报问题处理的进度和进展情况；更新问题记录，记录问题解决方案和问题的状态；将无法在时限内处理的问题提请进行升级；跟踪第三方厂商的问题发布和定期检查、分析事件数据库， 主动发现问题；定期对多次重复的事件进行分析主动发

20、现问题；流程管理总负责人职责：负责人从宏观上监控运维管理流程，确保流程在技术中心范 围内被正确的执行。当流程不能够适应项目需要时，流程负责人必 须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提 高。岗位：具有 ITIL expert 认证，AWS PRO 认证。技术中心负责人事件管理 事件定义“可侦测、可识别的发生，对服务管理提供可参考的资讯，去评估冲击或服务偏差，通常是由监控工具产生的通知”。事件管理的目标 为提前发现故障提供定位基础 为异常情况的自动恢复（自愈）提供基础，释放人力成本，提升处理效率监控整个管理流程的状态变化，让相关人员可以及时响应，更快速的定位故障事件监控的范围

21、指标固定指标：基础的需要持久监控的指标，如 ping动态指标：需要不断计算动态结果，判断是否触发条件的指标，如 S3 存储策略的更新 合规性：合法的授权监控，如 lic 证书，授权用户等 安全：如入侵检测 常规状态检测：如磁盘、性能负载等的变化事件的分类 信息(INFO)：不触发任何动作，不代表任何异常的事件 告警（Warning）：当阈值达到警告标准产生的事件 故障（Incident）：按照预先定义的标准，判定为产生了异常情况的事件L2C 针对事件流程的处理分级 监控平台：通过探针进行事件上报，如 CloudWatch，自定义监控脚本，Agent 等，触发 SQS or Lambda； 事件

22、分类系统：ECS or Lambda 对上报事件进行分类处理通知类的直接进入通知告警平台的不同消息队列满足自动化修复的进入自动化处理平台 自动化处理平台：基于 Lambda 和系统 agent 对不同规则的问题进行第一次修复，并上报结果 通知告警平台（OneAlert）：集成 SNS 进行报警压缩，接收人分组，完成事件通知事件处理流程流程图流程描述 事件触发根据监控平台中已设置的初始阈值，当某个指标发生变化时即启动事件触发流程，下发事件消息到事件分类系统 事件分类事件分类系统是由事件分类器和自动化触发器组成，对于接收的消息队列按照 info，warning，Incident 进行分类。分别对故

23、障（Incident）与非故障类型的事件置入不同的通知队列，下发给报警平台进行通报；同时，对于 info，warning，Incident 根据自动化规则库进行判定，判定匹配则下发到自动化处理平台，尝试自动化进程修复异常。 自动化处理自动化处理平台由自动化规则库和对应的修复程序组成，其中修复程序主要是由 lamdba 函数和ansible 组成。当接收分类下发的消息队列时，先根据自动化规则库判断是否触发自动修复，如果匹配促发规则，则使用计划内的修复程序对异常做自动修复，并将修复结果下发到通知告警平台减少事件的处理时间，省去了人工的介入，沟通时间减少事件对业务的影响，更快速的恢复应用可用降低事件

24、的误操作，标准化的流程，避免了人工的许多不确定因素实现整个事件可塑性，有完整的处理流程降低运维人员的负荷降低整体运维的成本 事件通知事件通知平台用于接收事件分类平台与自动化处理平台下发的消息队列。在事件通知平台中定义了不同等级的通知分发策略与通知群组。根据事件消息的分类将不同等级将警报信息下发到不同的后端运维团队Info：为绿色通报，属于事件通报队列。仅表示自然事件信息的变化状态，用于通知，但不需要运维人员重点介入。如：有用户登录了 console 控制台的通知Warning：黄色通报，属于事件通报队列。表示一些告警信息，运维人员收到后根据实际情况判断是否要进一步处理。如：磁盘容量报警的警告I

25、ncident：红色通报，属于故障通知队列。表示出现了异常，需要运维人员介入处理，触发故障事件解决流程。如：web 页面返回 404 无法登录 事件记录所有被触发的事件都会在报警平台进行记录日志在报警平台进行归档处理 事件检查运维人员介入的事件，需要建立单独的故障工单。按照故障流程的处理对事件结果进行复查，确保异常事件的修复完整。对于自动化修改的异常程序做检查，确认是否还需要人工进行修复，事件检查完成后，进入下一步事件关闭流程 事件关闭事件关闭包括自动关闭和人工关闭两种方式。对于 info，warning 事件定义 2 小时超时自动关闭对于 Incident 故障事件必须人工手动关闭，填写关闭

26、原因2.6 与其他流程的关系和变更管理流程的关系 建立变更请求探测到异常情况：如，对 AWS 平台扫描发现 root 用户未开启 MFA 登录规则关联到确定的变更：如，OS 磁盘探测到容量达到 75%，满足变更条件和故障管理流程的关系 建立故障工单与变更请求一样，探测到异常情况时，触发执行故障工单，进入故障处理流程。如果有自愈脚本会同步进行第一次修复和问题管理流程的关系通过触发故障，进一步判定是否需要触发问题管理流程故障管理云计算中心故障管理流程的主要功能是尽快解决出现的异常事件，保持业务支撑系统的稳定性。故障管理的目标在技术中心允许的 SLA 范围内尽快为客户恢复服务 快速响应客户的服务请求

27、（工单/电话/邮件等） 为客户提供在线支持 沟通故障解决的进度状态 和客户确认故障的解决结果对故障进行有效的控制 按规范记录 jira 事件工单 就故障的优先级，影响度进行分类分析，诊断，必要时进行升级 监视并关闭故障工单进行定期服务流程回顾为 IT 管理与成本核算提供数据支撑 人力资源利用情况 故障处理情况 支持效率3.2 与其他流程的关系和问题管理流程的关系故障管理流程将提供故障的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势， 以及在优先级为紧急的故障解决并恢复服务后，做为问题进行进一步的分析和处理。和配置管理流程的关系需要从配置管理数据库中查询配置项的属性和配置项间的关联

28、关系，来定位故障和帮助快速的恢复。和变更管理流程的关系运维服务台一线人员应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的故障。在故障的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决故障。3.3 故障流程设计3.3.1 故障管理设计流程图“故障管理流程”用于帮助云计算中心技术中心迅速解决这些故障，最小化降低对客户业务的不利影响。本流程始于故障的接收和记录，结束于故障的解决。该流程包含下述主要内容：序号步骤名称责任人说明1.1故障甄别一线运维在线的一线运维人员对来自客户和系统监控自动产生的故障进行故障甄别根据故障优先级别标准确认故障是否为紧

29、急故障，对于判断为紧急的故障提升处理的优先级对于判断为紧急的故障立即升级给项目经理，转 1.8 紧急故障处理子流程故障工单填写必须包含如下内容：故障标题和描述必要的附件故障发生时间和故障发现时间（不完整的由一线运维人员补充完善）序号步骤名称责任人说明故障分类（tag）1.2一线尝试解决一线运维如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位；对于非紧急故障进行调查诊断，开始正常故障解决流程对于需要通过变更解决的故障提出变更申请，通过变更流程实施解决方案对于需要通过问题解决的故障提出问题申请，通过问题流程实施解决方案需要 AWS 后台协助

30、的，转到 1.4 AWS 后台 support 协助，并负责最后核查完全不能判断解决的故障，转 1.3 二线尝试解决客户主动取消或重复的故障，转 1.9 关闭工单（取消工单）故障解决后，在故障管理平台记录故障解决方案并更新故障状态1.3二线尝试解决二线运维二线运维人员接受到来自一线运维的故障后，二线运维方向组长进行判断，分配给合适的二线运维工程师如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位；二线运维根据重复故障原则，判断该故障工单是否属于重复故障，如果属于重复故障，转回到对应的一线工程师处理，走“重复故障关闭流程”二线运维工程师开始

31、诊断，尝试解决方案对于需要通过变更解决的故障提出变更申请，通过变更流程实施解决方案对于需要通过问题解决的故障提出问题申请，通过问题流程实施解决方案对于需要 AWS 后台协助的，转到 1.4 AWS 后台 support 协助，并负责最后核查故障解决后，在故障管理平台记录故障解决方案并更新故障状态客户主动取消的故障，转 1.9 关闭工单（取消工单）1.4AWS 后台 Support一、二线运维涉及 AWS 底层或深层问题可以向 AWS 后台寻求协助，根据实际情况， 尝试找出并实施解决方案故障解决后，在故障管理平台记录故障解决方案并更新故障状态指定时限内未能解决的故障，通告项目经理，由项目经理负责

32、协调资源，组建“专向问题小组”查找解决方案，直到解决问题为止1.5记录解决方案细节一、二线运维在故障得到解决后，各线支持人员负责详细记录故障解决过程及方案并更新故障信息填写“解决方案”确定“故障分类”是否正确填写“结束代码”序号步骤名称责任人说明确定“故障优先级”的等级是否正确对于故障和告警，应该明确是哪个配置项发生的，关联正确的配置项1.5.2 针对故障，一、二线运维人员必须记录业务恢复时间1.6关闭工单（已解决）一线运维一线运维人员与客户确认故障是否已得到解决，如果解决，故障以成功解决关闭；一线运维人员在关闭故障的同时必须确认故障工单记录的业务恢复时间是否准确1.7故障处理的监控项目经理负

33、责监控所有未关闭的故障的处理状况，对接收到的超时告警应及时关注，并负责协调资源，保证故障的最终解决当故障优先级为紧急时，应按照紧急故障处理流程处理紧急故障由于处理不及时而可能导致客户满意度下降的故障或疑难故障，项目经理负责召集相应二线专家，共同商讨并制定解决方案，并实施解决方案1.8紧急故障处理流程项目经理项目经理主持应急会议，成立应急小组，组织讨论、协调各方资源， 分析紧急故障处理方案，并将紧急故障情况通报技术中心负责人和相关公司领导应急小组根据紧急故障现象和影响程度，判断是否需要启动相应系统的应急预案？如果没有应急预案，应急小组负责分析紧急故障，制定相应的处理方案；处理方案在实施前应得到应

34、急小组和相关领导的认可；故障处理过程中如果需要中断业务或对系统的 IT 组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求根据各系统制定的应急预案中的实施步骤，处理紧急故障如果有应急预案，则按照应急预案处理在紧急故障处理方案实施后，应急小组和业务相关部门对紧急故障是否解除进行确认紧急故障如果没有解除，则重新进入 1.8.2 组织相关人员分析紧急故障，制定处理方案并处理；如果解除，则进入 1.8.4 紧急故障善后处理和总结分析紧急故障解除后，应急小组向客户报告紧急故障处理过程，解决方法，故障解除时间，业务恢复情况对于影响度为重大的紧急故障，必须向用户提供故障报告紧急故障的处理

35、人需要创建一个新问题，将紧急故障处理过程的详细信息记录到问题单中，提交到项目经理，由项目经理组织相关专家进行问题根源的分析1.9关闭工单（取消工单）一 线 运维、项目经理1.9.1 故障处理过程中客户主动取消的，一线运维要联系客户，说明情况， 将该故障工单状态置为“关闭”，结束代码为“误报”，保存关闭序号步骤名称责任人说明故障过程中判断为重复的故障由一线运维人员手动关闭，并做好备注关联，状态置为“XX 工单处理中”，保存关闭故障过程中由项目经理判断后符合关闭的, 将该故障工单状态置为“关闭”，结束代码为“已取消”，保存关闭3.4 故障流程执行原则常规原则 所有技术中心故障管理范围内发生的故障，

36、都应该记录在工单服务管理平台中，记录的信息应足够详细，包括故障处理交互过程，详细的解决方案和相应的附件 故障优先级为紧急（P1P2）的故障最先分配，拥有最高优先处理级别 SLA 属于“危险的、违规的、快到期的”拥有优先处理级别 每月生成故障管理报表，并对重复发生的故障和变通方法解决的故障，举行定期的故障管理会议对这些故障进行评估 每半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进故障管理流程流程关联原则 和问题管理的关联所有优先级为紧急的故障在恢复服务后，都应该创建问题单（问题单必须和故障工单建立关联）支持人员在解决故障的过程中，可以通过问题记录在

37、KEDB 中查找出相应的解决方案 和变更管理的关联故障处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求（变更单必须和故障工单建立关联），变更完成后，继续故障工单的处理紧急故障（优先级为紧急（P1P2）的故障，下同）的处理过程中，如果需要对系统进行变更， 必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急故障工单建立关联 和配置管理的关联故障处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的故障、问题或变更，来帮助故障的定位故障处理过程中，如果可以将故障定位到某个配置项，则必须将故障工单与该配置项关联责任人原则责任人原则用

38、来确保每个故障在任何时段都有适当的人员负责，服务台一线人员是故障的负责人。 由客户报告的故障工单，服务台一线运维人员是该故障的责任人，必须确保故障得到有效跟踪与解决，并负责故障工单的关闭再分派原则故障的再分派原则是确保故障在服务目标时段内处理和解决的重要因素。因此，应当尽量减少故障工单再分派的几率。故障工单默认分配到其它工作空闲的一线人员或二线人员组长，再由组长分配组内的支持人员处理。故障工单的重分派次数不允许超过 5 次。 故障工单由一线运维人员响应一线运维可以将故障工单重新分配其他一线运维组（人员），二线运维组长（人员），由二线运维组长评测后派发给对应二线运维（人员） 二线运维可以将故障工

39、单重新分配给一线运维组（人员），其他二线运维组（人员）重复故障原则重复故障是指在一个较短时间段（30 分钟内至 1 小时），由监控平台上报的同一个配置项上现象相同的故障或一人/多人报告的同一来源（系统、应用）现象相同的故障。当被报告的故障与某个已经创建且尚未解决的故障工单相同，则该故障被认为是重复的。由于此时已创建的故障尚未解决，还没有采取修正措施来恢复服务，因此，新报告的故障被认为是原有故障工单的重复故障工单。在原有故障工单获得解决时，所有的重复故障工单将同时获得解决。 重复的故障信息必须被标识，并且不计入故障流程的关键衡量指标 如果一线运维人员可以判断到重复故障，则由服务台一线人员对重复故

40、障标识并关闭，结束代码为“重复提交，否则由一线运维人员负责重复故障的处理关闭原则由客户报告的故障工单，关闭必须在工单系统完成。 故障处理人员在解决完成故障时，根据实际解决情况填写故障的结束代码。服务台一线运维人员和客户再次确认故障的解决 由客户认可获得关闭的故障工单的结束代码为已解决关闭 已解决的故障工单如果没有得到客户的认可，由项目经理关闭 已关闭的故障工单不允许重开。如果故障重复发生，则创建一个新的故障工单 技术中心运维服务部的维护人员（一线、二线）自行创建的故障工单，本着谁开单，谁负责关闭的原则 监控平台产生的故障发送到一线运维人员创建工单，一线运维人员无法决定的升级到项目经理， 由项目

41、经理分派一线人员，处理人员解决并关闭工单升级原则制定升级原则的目的是确保故障在规定的解决时限内能够及时通知相关技术人员和项目负责人，引起更多的重视，提供合适的资源，从而快速找到解决故障的方案。 优先级为紧急（P1P2）的故障，应立即由相应一线运维响应，一线运维再次确认确认了优先级为紧急，则立即升级到项目经理（通过工单管理平台），由项目经理启动紧急故障处理流程 各支持人员应及时响应和处理分配到自己的故障工单，如果超出规定的响应时限和解决时限（SLA），项目经理周期性巡检超出 SLA 的工单，并对超出 SLA 的工单进行复查与督查优化 运维服务台的一线运维应及时将不能解决的故障升级到下一级，若未及

42、时升级，项目经理需及时介入，负责协调升级处理人员岗位与角色落实原则 一线运维按照人员工作负载空闲进行工单响应大客户项目由项目组内人员优先响应 二线人员由对应组长分配具体响应人员目前流程中的各角色的分组可以进行扩充故障工单流转原则 公司内部故障管理通过 CRM 流转，最终由项目经理在技术中心运维服务台创建故障工单 客户工单原则上由客户自行创建，需要代替创建的，由项目经理代替客户提交，提交人必须指向客户用户 运维服务台负责受理公司服务客户提交的所有请求，运维服务台一线运维人员首先对客户提交的请求进行尝试解决，不能解决的通过服务分组目录自动提交到技术中心二线相应支持组或人 技术中心一线人员负责第一级

43、响应和处理运维服务台的工单，对于属于公司内部的故障在一线内部处理解决，不能解决的将工单提交到项目经理，由项目经理协调资源处理 二线负责处理一线转派的工单，首先在二线内部尝试解决，不能解决的提交到项目经理，由项目经理协调资源进行处理 对于技术中心内部人员自行创建的工单，根据服务目录直接转派给本公司项目经理，由项目经理视情况手工分派给相关人员进行处理 对于技术中心内部人员创建的工单，关闭原则是谁创建工单，谁关闭工单故障工单状态更新 一线运维默认情况下在工单系统内打捞工单 打捞原则以 P1P2 为最高优先级别，在满足优先级基础上优先对“危险的、违规的、快到期的”SLA 工单队列进行处理 非工单系统的

44、故障处理：客户通过电话、微信等方式直接找到的，P3P4 由一线运维/项目经理代建工单。P1P2 优先处理客户故障，允许在保证约定 SLA 情况下后补工单 故障工单的状态按照工单流程进行更新，客户在前台进行即时状态的查看客户的工单随着状态的更新,可随时收到状态更新的通知 故障工单如果发生了依赖 AWS 或第三方的 pending，需要提前在系统告知客户，必要的由项目经理同步给客户。对 P1P2 要保证每小时跟客户同步一次进度，P3P4 保证至少 2 天同步一次进度3.5 流程相关定义故障信息项故障工单包含如下信息项：序号信息项是否必填说明故障创建和分类时填写1问题分类是参见“故障分类”定义，在工

45、单创建时选择合适分类2申请人否故障提交人3概要是故障问题简单描述（如.跳板机无法登录）4附件否上传附件相关附件，敏感信息附件需要加密5到期日否期望解决故障的最后时间6故障描述是描述故障问题具体细节7优先级否参见“故障优先级”定义8标签否参见“故障标签”定义，由 L2C 一线运维人员对故障进行归类校准9审批人否当前故障是否需要审批提交故障工单时，系统自动产生10工单 ID是故障工单流水号（系统自动产生）11报告人（工单创建人）是创建故障请求工单的记录人12经办人（工单处理人）是实际处理工单的人员13创建时间是在服务台生成故障记录的时间（系统自动产生）14更新时间是工单的更新时间15SLA是分为：

46、第一响应时间、解决时间、决议后关闭时间16相关知识库文章是会自动提示知识库中相关文档17故障状态是参见“故障状态”定义18故障完成期限否对应每一个故障优先级，系统根据流程相关定义中“故障解决时限”自动设定最终的完成期限 （系统自动产生）同 15附件否上传附件一线、二线、项目经理尝试解决时填写：序号信息项是否必填说明19发生时间否针对故障发生的时间（手工填写）20发现时间否针对故障发现的时间（手动填写）21恢复时间否针对故障恢复的时间（手动填写）22活动日志是记录故障处理的经过，以及解决方案23优先级否判断优先级是否正确，如果不匹配，进行降级操作一线、二线、项目经理尝试解决时，系统自动产生同 1

47、9故障状态是参见“故障状态”定义24故障解决人是故障的最终解决人（系统填写）25处理是否超时否参见“处理是否超时”定义（系统自动产生）26实际完成时间是记录故障最后解决的时间（系统自动产生）关闭工单时填写27客户反馈是参见“客户反馈”定义，满意度调查28故障结束代码是参见“故障结束代码”定义29故障解决人角色是参见“故障解决人角色”定义30解决结果是用于记录工单解决的结果31故障关闭时间是记录故障被关闭的故障故障性质技术中心根据当前业务场景在工单系统定义如下七类故障：编号代码描述1计算包含 EC2、安全组、EBS、AutoSacling、ECS、等服务器计算类资源相关问题；AMI 镜像与实例备

48、份还原相关问题；OS 操作系统内部相关问题； 应用异常等相关问题；2网络包含 VPC、路由、VPN、专线等链路异常相关问题； 第三方防火墙规则等相关问题；3数据库MySQL、Oracle、SQLServer、Redis、Redshift 等数据库配置和所有数据操作相关问题；4存储AWS 原生存储相关服务（S3、Glacier、Storage Gateway）等相关问题； 第三方存储产品相关问题；5监控审计安全漏扫等相关问题； 安全加固等相关问题；编号代码描述数据加密等问题；监控报警配置（Cloud Watch、CloudTrial）等相关问题； 第三方安全与监控产品相关问题；6账户与账单AWS

49、 账单相关问题；AWS 账户相关问题；7其它无法明确归类的其它问题分类；故障优先级工单系统优先级决定处理故障的顺序及所需的资源，L2C 定义故障优先级为四级（P1、P2、P3、P4）。编号优先级故障定义1P1(注：仅适用于生产环境)该故障导致工作完全中断，并影响主要的业务流程或广泛的最终客户群，如整个公司、业务部门或外部客户，且没有可用的解决方案。2P2(注：仅适用于生产环境)该故障会导致系统运行受严重影响，业务功能严重退化，影响范围大于 80%，或者关键客户受到影响。3P3(注：仅适用于生产环境)系统的效率受影响，操作性能受损，但系统仍然可以运作4P4(注：仅适用于生产环境)该故障对正常的业

50、务流程几乎没有影响，可以按预定的方式处理。故障响应时限和解决时限在故障处理过程中，L2C 通过服务 SLA 对故障定义解决时间的限制和响应时间的限制。 一方面，要求相关工程师协同合作，在解决故障时有时间的概念，另一方面也要求项目经理必须实时地督促故障的解决。 对于影响度为高或者紧急的故障，需要及时通告项目经理。如果该故障的响应或解决超过了时限，必须通告项目经理，同时也要根据具体情况通告给其他相关项目人员。 第一响应时间指的是故障状态从“已创建”到“等待客户”经过的时间； 解决时间指的是故障状态从“已创建”到“已解决”经过的时间； 故障优先级对应的故障响应时限和解决时限参考下表编号服务优先级响应

51、时间解决时间1P1(24*7)30 分钟4 小时2P2(24*7)1 小时6 小时3P3（5*8）2 小时2 个工作日4P4（5*8）4 小时3 个工作日 故障发生时的通知定义当工单系统收到故障时，自动按照表中的人员列表发出邮件或短信通知。优先级别通知人员列表P1技术中心负责人，项目经理，一、二线运维人员,客户 PMP2项目经理，一、二线运维人员,客户 PMP3通知一、二线运维人员P4通知一线运维人员 超出响应时间的通告定义当工单系统判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。优先级别通知人员列表故障响应时限P1技术中心负责人，项目经理，一、二线运维人员15 分钟P2项

52、目经理，一、二线运维人员,客户 PM30 分钟P3项目经理，一、二线运维人员1 小时P4项目经理，一线运维人员2 小时 超出和即将超出解决时限的通告定义优先级别通知时间通知人员列表故障解决时限P13 小时技术中心负责人，项目经理，一、二线运维人员,客户 PM4 小时4 小时技术中心负责人，项目经理，一、二线运维人员,客户 PMP25 小时项目经理，一、二线运维人员,客户 PM6 小时6 小时技术中心负责人，项目经理，一、二线运维人员,客户 PMP347 小时项目经理，一、二线运维人员48 小时48 小时项目经理，一、二线运维人员P471 小时项目经理，一、二线运维人员72 小时72 小时项目经

53、理，一、二线运维人员当工单系统判断到判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知故障状态 故障状态代码表明故障所处的处理状态，故障状态如下：编号代码描述1等待支持新开故障记录或故障已创建，等待一线支持2进行中一线/二线人员开始处理故障工单3等待客户等待客户回复问题/确认处理结果4已升级进入二线或故障已分配到一线运维，一线还未响应5其它工单介入需要依赖 AWS 后台 support 的故障6CMDB 录入将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）7已取消工单被客户/项目经理取消8已解决故障已解决，支持人员联系客户验证故障是否获得

54、解决9已关闭故障已关闭- 故障状态变迁图用来标明：当一个故障单处于某个状态时，它可以去到的下一个状态。- 当前状态为等待批准状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障单初始状态或客户已经对问题进行反馈等待客户否客户提交故障请求，首先分派到服务台，一线人员进行响应已升级否如果问题紧急，客户可以直接进行升级操作进行中否确认客户问题后开始进行处理，如果信息充足则开始处理其他工单介入否在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入否将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消是如果客户误报，可以直接取消工单已解决是客户问

55、题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为等待支持状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障单初始状态或客户已经对问题进行反馈等待客户是客户提交故障请求，首先分派到服务台，一线人员进行响应已升级是如果问题紧急，客户可以直接进行升级操作进行中是确认客户问题后开始进行处理，如果信息充足则开始处理其他工单介入是在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入否将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消是如果客户误报，可以直接取消工单已解决是客户问题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为等待

56、客户状态时，可迁移的状态状态切换合规描述等待支持是已登记为故障单初始状态或客户已经对问题进行反馈等待客户否客户提交故障请求，首先分派到服务台，一线人员进行响应已升级否如果问题紧急，客户可以直接进行升级操作进行中否确认客户问题后开始进行处理，如果信息充足则开始处理其他工单介入是在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入否将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消是如果客户误报，可以直接取消工单已解决是客户问题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为已升级状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障

57、单初始状态或客户已经对问题进行反馈等待客户否客户提交故障请求，首先分派到服务台，一线人员进行响应已升级否如果问题紧急，客户可以直接进行升级操作进行中是确认客户问题后开始进行处理，如果信息充足则开始处理其他工单介入否在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入否将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消否如果客户误报，可以直接取消工单已解决否客户问题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为“进行中”状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障单初始状态或客户已经对问题进行反馈等待客户否客户提交故障请

58、求，首先分派到服务台，一线人员进行响应已升级是如果问题紧急，客户可以直接进行升级操作进行中否确认客户问题后开始进行处理，如果信息充足则开始处理其他工单介入是在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入是将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消是如果客户误报，可以直接取消工单已解决是客户问题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为其它工单介入状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障单初始状态等待客户是客户提交故障请求，首先分派到服务台，一线人员进行响应进行中是确认客户问题后开始进行处理，如果信

59、息充足则开始处理已升级否如果问题紧急，客户可以直接进行升级操作其他工单介入否在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入是将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消是如果客户误报，可以直接取消工单已解决是客户问题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为CMDB 录入状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障单初始状态等待客户否客户提交故障请求，首先分派到服务台，一线人员进行响应进行中否确认客户问题后开始进行处理，如果信息充足则开始处理已升级否如果问题紧急，客户可以直接进行升级操作其他工单介入否在

60、处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入否将本工单涉及到的变动记录到 Insight 中（仅针对“发布上线”和“变动更新”）已取消否如果客户误报，可以直接取消工单已解决是客户问题已经得到解决已关闭否客户问题已经永久关闭- 当前状态为已取消状态时，可迁移的状态状态切换合规描述等待支持否已登记为故障单初始状态等待客户否客户提交故障请求，首先分派到服务台，一线人员进行响应进行中否确认客户问题后开始进行处理，如果信息充足则开始处理已升级否如果问题紧急，客户可以直接进行升级操作其他工单介入否在处理过程中发现依赖其他工单介入或者需要 AWS 介入CMDB 录入否将本工单涉及到的变