云计算中心运维事件与问题管理流程Word文档格式.docx

云计算中心运维事件与问题管理流程Word文档格式.docx

《云计算中心运维事件与问题管理流程Word文档格式.docx》由会员分享，可在线阅读，更多相关《云计算中心运维事件与问题管理流程Word文档格式.docx（63页珍藏版）》请在冰豆网上搜索。

技术中心的日常维护（包括账单方向、数据库方向、系统方向、网络方向、账户申请等）技能初级人员纳入一线运维中，按日常所管工作内容和支持项目划分到相应支持组中

1.2.2二线运维人员

二线运维人员是相关问题领域的专家。

负责提供对一线运维人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职责:

进行事件/故障的深入调查研究

根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动

必要时引入研发Team、AWSSupport或第三方供应商的支持

及时提供有效解决方案

已解决的故障转回一线运维服务台，由一线运维人员关闭故障

深厚的技术背景，对所维护范畴的技术深入掌握

熟悉事件与故障处理流程，熟悉问题管理流程

技术中心的专向技能工程师组成

1.2.3项目经理

云计算中心技术中心项目经理负责事件与故障解决过程中的协调和监控，以及对故障升级的判断以及具体执行。

监控问题的根因排查进度，并整理最终用户报告。

负责对重大、紧急（P1/P2）故障的解决协调资源，保证故障的最终排除；

当故障优先级为紧急或者故障将超过规定的时限，负责按照升级方法对故障进行处理确保有效协调资源，促进各支持小组（一线运维、二线运维）高效的恢复客户服务；

确保事件流程、故障流程、问题管理流程的有效关联；

确保问题的根因排查能有效进行；

确保正确和广泛地收集和分析故障数据，及时发现和业务相关的问题。

了解技术架构和项目环境；

较强的口头表达能力和与客户沟通技巧；

处理纠纷的能力；

深刻了解技术中心事件、故障、问题管理流程；

较强的领导能力。

由技术中心专门的PM来担任

1.2.4流程管理负责人

运维管理流程由技术中心运维负责人从宏观上监控流程，确保相关流程在技术中心范围内被正确的执行。

当流程不能够适应项目需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

确定运维管理流程的衡量指标

确保运维管理流程能够取得管理层的参与和支持

确保运维管理流程符合项目实际状况和公司IT发展战略

总体上管理和监控流程，建立事件流程、故障流程、问题管理等流程的实施、评估和持续优化机

制

确保运维管理流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进，从而实现技术中心服务的可持续提高

深刻理解运维管理流程；

能够很好地理解业务对于运维流程管理的需求；

有决策权，能够确保运维管理流程设计要求在实施项目中得到贯彻和执行；

具有很好的沟通技能，获得所需资源。

由技术中心总负责人担任

1.3岗位与方案角色的映射

运维管理流程（运维服务台）

角色

角色细分

说明

成员

负责接收所有的事件报警与故障申报，对事件和故障进行初

步判断，并根据实际工作负载和紧急程度对事件和故障进行响应处

一线运维

技术中心

通用支持组

理

岗位：

技术中心的日常维护人员纳入一线运维中，按日常所管工作

内容和支持项目划分到相应支持组中

负责账号相关模版开发、资源账单深度分析

AWS账单优化方向

AWSAssociate认证。

至少6个月以上深度分析过客户账单，

完成3个完整项目账单优化支持工作

负责数据库参数调优、性能分析，架构测试与建议

数据库方向

有DB相关认证，DB专向运维实践工

作超过2年

系统与应用运维方向

负责操作系统，系统内应用的问题排查与优化

有MSCEorRHCE相关认证，系统运维实践工作超过2年

二线运维

网络方向

有MSCEorRHCE相关认证，系统运维

实践工作超过2年

CICD与容器方向

负责CICD与容器类方案实施，配置调试与流程完善

Devops运维开发2年以上经验，docker

实践经验1年以上

对架构、系统、应用、权限、安全合规等方面进行全面审计

与建议

安全方向

对安全领域有全面了解，做过企业级

安全顾问

AWS其它高级服务

调研与实践AWS高级服务（如IOT,ML，AIops等）

AWSDevops认证。

精通python编程

项目经理

负责督导与监控公司运维处理过程的正常运转，接收故障的升级通知和处理超时通知，完成问题根因排查的进度跟进等

具有PMP认证。

项目管理工作超过3年

问题经理

✓开发和维护问题管理流程；

✓回顾问题控制流程的效率和效果；

✓管理问题解决小组；

✓问题处理过程中的资源分配；

✓监督问题处理过程中的进展情况；

✓必要时引入第三方厂商的支持；

✓定期对配置库中的信息进行检查，定期分析基础设施的运行趋势，主动发现问题；

✓确认问题是否得到解决；

✓问题管理中相关标准的制定；

岗位：

由项目经理或二线组长兼任

问题评审小组

✓对升级进行授权；

✓解决方案评审；

✓问题处理流程的审计；

✓重大问题处理过程的审计；

问题解决小组

✓问题的录入；

✓根据问题的分类和优先级，对问题进行分类、分优先级；

✓问题调查和诊断

✓提出问题的解决方案；

✓及时向问题经理汇报问题处理的进度和进展情况；

✓更新问题记录，记录问题解决方案和问题的状态；

✓将无法在时限内处理的问题提请进行升级；

✓跟踪第三方厂商的问题发布和定期检查、分析事件数据库，主动发现问题；

定期对多次重复的事件进行分析主动发现问题；

流程管理总负责人

负责人从宏观上监控运维管理流程，确保流程在技术中心范围内被正确的执行。

当流程不能够适应项目需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

具有ITILexpert认证，AWSPRO认证。

技术中心负责人

2事件管理

事件定义

“可侦测、可识别的发生，对服务管理提供可参考的资讯，去评估冲击或服务偏差，通常是由监控工具产生的通知”。

2.1事件管理的目标

为提前发现故障提供定位基础

为异常情况的自动恢复（自愈）提供基础，释放人力成本，提升处理效率

监控整个管理流程的状态变化，让相关人员可以及时响应，更快速的定位故障

2.2事件监控的范围

指标

➢固定指标：

基础的需要持久监控的指标，如ping

➢动态指标：

需要不断计算动态结果，判断是否触发条件的指标，如S3存储策略的更新

合规性：

合法的授权监控，如lic证书，授权用户等

安全：

如入侵检测

常规状态检测：

如磁盘、性能负载等的变化

2.3事件的分类

信息（INFO）：

不触发任何动作，不代表任何异常的事件

告警（Warning）：

当阈值达到警告标准产生的事件

故障（Incident）：

按照预先定义的标准，判定为产生了异常情况的事件

2.4L2C针对事件流程的处理分级

监控平台：

通过探针进行事件上报，如CloudWatch，自定义监控脚本，Agent等，触发SQSorLambda；

事件分类系统：

ECSorLambda对上报事件进行分类处理

➢通知类的直接进入通知告警平台的不同消息队列

➢满足自动化修复的进入自动化处理平台

自动化处理平台：

基于Lambda和系统agent对不同规则的问题进行第一次修复，并上报结果

通知告警平台（OneAlert）：

集成SNS进行报警压缩，接收人分组，完成事件通知

2.5事件处理流程

2.5.1

流程图

2.5.2流程描述

事件触发

根据监控平台中已设置的初始阈值，当某个指标发生变化时即启动事件触发流程，下发事件消息到事件分类系统

事件分类

事件分类系统是由事件分类器和自动化触发器组成，对于接收的消息队列按照info，warning，

Incident进行分类。

➢分别对故障（Incident）与非故障类型的事件置入不同的通知队列，下发给报警平台进行通报；

➢同时，对于info，warning，Incident根据自动化规则库进行判定，判定匹配则下发到自动化处理平台，尝试自动化进程修复异常。

自动化处理

自动化处理平台由自动化规则库和对应的修复程序组成，其中修复程序主要是由lamdba函数和

ansible组成。

当接收分类下发的消息队列时，先根据自动化规则库判断是否触发自动修复，如果匹配促发规则，则使用计划内的修复程序对异常做自动修复，并将修复结果下发到通知告警平台

➢减少事件的处理时间，省去了人工的介入，沟通时间

➢减少事件对业务的影响，更快速的恢复应用可用

➢降低事件的误操作，标准化的流程，避免了人工的许多不确定因素

➢实现整个事件可塑性，有完整的处理流程

➢降低运维人员的负荷

➢降低整体运维的成本

事件通知

事件通知平台用于接收事件分类平台与自动化处理平台下发的消息队列。

在事件通知平台中定义了不同等级的通知分发策略与通知群组。

根据事件消息的分类将不同等级将警报信息下发到不同的后端运维团队

➢Info：

为绿色通报，属于事件通报队列。

仅表示自然事件信息的变化状态，用于通知，但不需要运维人员重点介入。

如：

有用户登录了console控制台的通知

➢Warning：

黄色通报，属于事件通报队列。

表示一些告警信息，运维人员收到后根据实际情况判断

是否要进一步处理。

磁盘容量报警的警告

➢Incident：

红色通报，属于故障通知队列。

表示出现了异常，需要运维人员介入处理，触发故障事件解决流程。

web页面返回404无法登录

事件记录

➢所有被触发的事件都会在报警平台进行记录

➢日志在报警平台进行归档处理

事件检查

运维人员介入的事件，需要建立单独的故障工单。

按照故障流程的处理对事件结果进行复查，确保异常事件的修复完整。

对于自动化修改的异常程序做检查，确认是否还需要人工进行修复，事件检查完成后，进入下一步事件关闭流程

事件关闭

事件关闭包括自动关闭和人工关闭两种方式。

➢对于info，warning事件定义2小时超时自动关闭

➢对于Incident故障事件必须人工手动关闭，填写关闭原因

2.6与其他流程的关系

2.6.1和变更管理流程的关系

建立变更请求

➢探测到异常情况：

如，对AWS平台扫描发现root用户未开启MFA登录

➢规则关联到确定的变更：

如，OS磁盘探测到容量达到75%，满足变更条件

2.6.2和故障管理流程的关系

建立故障工单

与变更请求一样，探测到异常情况时，触发执行故障工单，进入故障处理流程。

如果有自愈脚本会同步进行第一次修复

2.6.3和问题管理流程的关系

通过触发故障，进一步判定是否需要触发问题管理流程

3故障管理

云计算中心故障管理流程的主要功能是尽快解决出现的异常事件，保持业务支撑系统的稳定性。

3.1故障管理的目标

3.1.1在技术中心允许的SLA范围内尽快为客户恢复服务

快速响应客户的服务请求（工单/电话/邮件等）

为客户提供在线支持

沟通故障解决的进度状态

和客户确认故障的解决结果

3.1.2对故障进行有效的控制

按规范记录jira事件工单

就故障的优先级，影响度进行分类

分析，诊断，必要时进行升级

监视并关闭故障工单

进行定期服务流程回顾

3.1.3为IT管理与成本核算提供数据支撑

人力资源利用情况

故障处理情况

支持效率

3.2与其他流程的关系

3.2.1和问题管理流程的关系

故障管理流程将提供故障的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的故障解决并恢复服务后，做为问题进行进一步的分析和处理。

3.2.2和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系，来定位故障和帮助快速的恢复。

3.2.3和变更管理流程的关系

运维服务台一线人员应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的故障。

在故障的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变

更请求来解决故障。

3.3故障流程设计

3.3.1故障管理设计流程图

“故障管理流程”用于帮助云计算中心技术中心迅速解决这些故障，最小化降低对客户业务的不利影响。

本流程始于故障的接收和记录，结束于故障的解决。

该流程包含下述主要内容：

序号

步骤名称

责任人

1.1

故障甄别

1.1.1在线的一线运维人员对来自客户和系统监控自动产生的故障进行故障甄别

✓根据故障优先级别标准确认故障是否为紧急故障，对于判断为紧急的故障提升处理的优先级

✓对于判断为紧急的故障立即升级给项目经理，转1.8紧急故障处理子流程

1.1.2故障工单填写必须包含如下内容：

✓故障标题和描述

✓必要的附件

✓故障发生时间和故障发现时间（不完整的由一线运维人员补充完善）

✓故障分类（tag）

1.2

一线尝试解决

1.2.1如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位；

1.2.2对于非紧急故障进行调查诊断，开始正常故障解决流程

✓对于需要通过变更解决的故障提出变更申请，通过变更流程实施解决方案

✓对于需要通过问题解决的故障提出问题申请，通过问题流程实施解决方案

✓需要AWS后台协助的，转到1.4AWS后台support协助，并负责最后核查

✓完全不能判断解决的故障，转1.3二线尝试解决

✓客户主动取消或重复的故障，转1.9关闭工单（取消工单）

1.2.3故障解决后，在故障管理平台记录故障解决方案并更新故障状态

1.3

二线尝试解决

1.3.1二线运维人员接受到来自一线运维的故障后，二线运维方向组长进行判断，分配给合适的二线运维工程师

1.3.2如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位；

1.3.3二线运维根据重复故障原则，判断该故障工单是否属于重复故障，如果属于重复故障，转回到对应的一线工程师处理，走“重复故障关闭流程”

1.3.4二线运维工程师开始诊断，尝试解决方案

✓对于需要AWS后台协助的，转到1.4AWS后台support协助，并负责最后核查

1.3.5故障解决后，在故障管理平台记录故障解决方案并更新故障状态

1.3.6客户主动取消的故障，转1.9关闭工单（取消工单）

1.4

AWS后台Support

一、二线运维

1.4.1涉及AWS底层或深层问题可以向AWS后台寻求协助，根据实际情况，尝试找出并实施解决方案

1.4.2故障解决后，在故障管理平台记录故障解决方案并更新故障状态

1.4.3指定时限内未能解决的故障，通告项目经理，由项目经理负责协调资源，组建“专向问题小组”查找解决方案，直到解决问题为止

1.5

记录解决方案细节

1.5.1在故障得到解决后，各线支持人员负责详细记录故障解决过程及方案并更新故障信息

✓填写“解决方案”

✓确定“故障分类”是否正确

✓填写“结束代码”

✓确定“故障优先级”的等级是否正确

✓对于故障和告警，应该明确是哪个配置项发生的，关联正确的配置项

1.5.2针对故障，一、二线运维人员必须记录业务恢复时间

1.6

关闭工单（已解决）

1.6.1一线运维人员与客户确认故障是否已得到解决，如果解决，故障以成功解决关闭；

1.6.2一线运维人员在关闭故障的同时必须确认故障工单记录的业务恢复

时间是否准确

1.7

故障处理的监控

1.7.1负责监控所有未关闭的故障的处理状况，对接收到的超时告警应及时关注，并负责协调资源，保证故障的最终解决

1.7.2当故障优先级为紧急时，应按照紧急故障处理流程处理紧急故障

1.7.3由于处理不及时而可能导致客户满意度下降的故障或疑难故障，项目经理负责召集相应二线专家，共同商讨并制定解决方案，并实施解决方案

1.8

紧急故障处理流程

1.8.1项目经理主持应急会议，成立应急小组，组织讨论、协调各方资源，分析紧急故障处理方案，并将紧急故障情况通报技术中心负责人和相关公司领导

1.8.2应急小组根据紧急故障现象和影响程度，判断是否需要启动相应系统的应急预案？

✓如果没有应急预案，应急小组负责分析紧急故障，制定相应的处

理方案；

■处理方案在实施前应得到应急小组和相关领导的认可；

■故障处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求

■根据各系统制定的应急预案中的实施步骤，处理紧急故障

✓如果有应急预案，则按照应急预案处理

1.8.3在紧急故障处理方案实施后，应急小组和业务相关部门对紧急故障是否解除进行确认

✓紧急故障如果没有解除，则重新进入1.8.2组织相关人员分析紧

急故障，制定处理方案并处理；

✓如果解除，则进入1.8.4紧急故障善后处理和总结分析

1.8.5紧急故障解除后，应急小组向客户报告紧急故障处理过程，解决方法，故障解除时间，业务恢复情况

✓对于影响度为重大的紧急故障，必须向用户提供《故障报告》

✓紧急故障的处理人需要创建一个新问题，将紧急故障处理过程的详

细信息记录到问题单中，提交到项目经理，由项目经理组织相关专家进行问题根源的分析

1.9

关闭工单（取消工单）

一线运维、项目

经理

1.9.1故障处理过程中客户主动取消的，一线运维要联系客户，说明情况，将该故障工单状态置为“关闭”，结束代码为“误报”，保存关闭

1.9.2故障过程中判断为重复的故障由一线运维人员手动关闭，并做好备注关联，状态置为“XX工单处理中”，保存关闭

1.9.3故障过程中由项目经理判断后符合关闭的,将该故障工单状态置为

“关闭”，结束代码为“已取消”，保存关闭

3.4故障流程执行原则

3.4.1常规原则

所有技术中心故障管理范围内发生的故障，都应该记录在工单服务管理平台中，记录的信息应足够详细，包括故障处理交互过程，详细的解决方案和相应的附件

故障优先级为紧急（P1P2）的故障最先分配，拥有最高优先处理级别

SLA属于“危险的、违规的、快到期的”拥有优先处理级别

每月生成故障管理报表，并对重复发生的故障和变通方法解决的故障，举行定期的故障管理会议对这些故障进行评估

每半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进故障管理流程

3.4.2流程关联原则

和问题管理的关联

➢所有优先级为紧急的故障在恢复服务后，都应该创建问题单（问题单必须和故障工单建立关联）

➢支持人员在解决故障的过程中，可以通过问题记录在KEDB中查找出相应的解决方案

和变更管理的关联

➢故障处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求（变更单必须和故障工单建立关联），变更完成后，继续故障工单的处理

➢紧急故障（优先级为紧急（P1P2）的故障，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管