云计算中心运维事件与问题管理流程.docx
- 文档编号:4196641
- 上传时间:2022-11-28
- 格式:DOCX
- 页数:63
- 大小:198.43KB
云计算中心运维事件与问题管理流程.docx
《云计算中心运维事件与问题管理流程.docx》由会员分享,可在线阅读,更多相关《云计算中心运维事件与问题管理流程.docx(63页珍藏版)》请在冰豆网上搜索。
云计算中心运维事件与问题管理流程
云计算中心
运维事件与问题管理流程
1技术中心综合运维管理流程设定
1.1流程管理的目的
技术中心综合运维管理流程的主要功能是尽快解决出现的事件与故障工单,并根据需要查找根本原因,保持业务支撑系统的稳定性,为客户提供持续可靠的运维服务
1.2关键角色、职责定义
云计算中心技术中心管理流程主要分为以下几个职责/角色,分别简述如下:
1.2.1技术中心运维服务台一线运维人员
技术中心运维服务台一线人员负责接收所有的事件与故障,对事件与故障进行初步判断与分类,并根据实际工作负载和故障紧急程度响应处理故障。
同时,配合二线运维人员完成重大问题的根本原因排查
职责:
响应:
在指定的响应时间内响应所有提交到服务台的工单、热线电话、邮件等事件报警与故障申报;
事件过滤:
对监控报警的事件进行过滤,对需要人工干预的触发事件进行分析与判断,确认后续
(故障/问题、变更)流程的创建与维护
事件跟踪:
负责审查事件的后续活动,并确保事件录入相关的(故障/问题/变更)流程
故障申报:
如果诊断为故障的,需要完整记录所有接收的故障信息,包括:
记录故障来源的详细信息、故障描述、发生时间等;
故障判断:
为故障进行适当的分类、为故障分配优先级等属性;
故障处理:
➢根据优先级提供有效的解决方案;
➢尝试使用知识库、初步诊断、分析相关信息并决定需要采取何种措施恢复服务并实施有效的解决措施;
➢如果一线不能解决这个故障,应当决定选择最合适的二线运维小组/人员来处理;
➢检查故障记录的处理进度,保持与客户的联系,适时通知故障处理进展;
故障跟踪:
与客户确认故障解决方案及客户满意度反馈,关闭故障工单。
技能要求:
熟悉技术平台和项目环境
较强的沟通能力
快速诊断故障和解决故障的能力
熟悉事件与故障处理流程,熟悉问题管理流程
人员安排:
技术中心的日常维护(包括账单方向、数据库方向、系统方向、网络方向、账户申请等)技能初级人员纳入一线运维中,按日常所管工作内容和支持项目划分到相应支持组中
1.2.2二线运维人员
二线运维人员是相关问题领域的专家。
负责提供对一线运维人员无法解决的问题进一步进行调研,找出解决方案并尽快恢复服务。
职责:
进行事件/故障的深入调查研究
根据经验和专业技能,决定需要采取何种措施恢复服务并实施有效的行动
必要时引入研发Team、AWSSupport或第三方供应商的支持
及时提供有效解决方案
已解决的故障转回一线运维服务台,由一线运维人员关闭故障
技能要求:
深厚的技术背景,对所维护范畴的技术深入掌握
熟悉事件与故障处理流程,熟悉问题管理流程
人员安排:
技术中心的专向技能工程师组成
1.2.3项目经理
云计算中心技术中心项目经理负责事件与故障解决过程中的协调和监控,以及对故障升级的判断以及具体执行。
监控问题的根因排查进度,并整理最终用户报告。
职责:
负责对重大、紧急(P1/P2)故障的解决协调资源,保证故障的最终排除;
当故障优先级为紧急或者故障将超过规定的时限,负责按照升级方法对故障进行处理确保有效协调资源,促进各支持小组(一线运维、二线运维)高效的恢复客户服务;
确保事件流程、故障流程、问题管理流程的有效关联;
确保问题的根因排查能有效进行;
确保正确和广泛地收集和分析故障数据,及时发现和业务相关的问题。
技能要求:
了解技术架构和项目环境;
较强的口头表达能力和与客户沟通技巧;
处理纠纷的能力;
深刻了解技术中心事件、故障、问题管理流程;
较强的领导能力。
人员安排:
由技术中心专门的PM来担任
1.2.4流程管理负责人
运维管理流程由技术中心运维负责人从宏观上监控流程,确保相关流程在技术中心范围内被正确的执行。
当流程不能够适应项目需要时,流程负责人必须及时的对此进行分析、找出缺陷、进行改进,从而实现可持续提高。
职责:
确定运维管理流程的衡量指标
确保运维管理流程能够取得管理层的参与和支持
确保运维管理流程符合项目实际状况和公司IT发展战略
总体上管理和监控流程,建立事件流程、故障流程、问题管理等流程的实施、评估和持续优化机
制
确保运维管理流程实用、有效、正确地执行,当流程不能够适应公司的情况时,必须及时的对此进行分析、找出缺陷、进行改进,从而实现技术中心服务的可持续提高
技能要求:
深刻理解运维管理流程;
能够很好地理解业务对于运维流程管理的需求;
有决策权,能够确保运维管理流程设计要求在实施项目中得到贯彻和执行;
具有很好的沟通技能,获得所需资源。
人员安排:
由技术中心总负责人担任
1.3岗位与方案角色的映射
运维管理流程(运维服务台)
角色
角色细分
说明
成员
职责:
负责接收所有的事件报警与故障申报,对事件和故障进行初
步判断,并根据实际工作负载和紧急程度对事件和故障进行响应处
一线运维
技术中心
通用支持组
理
一线运维
岗位:
技术中心的日常维护人员纳入一线运维中,按日常所管工作
内容和支持项目划分到相应支持组中
职责:
负责账号相关模版开发、资源账单深度分析
AWS账单优化方向
岗位:
AWSAssociate认证。
至少6个月以上深度分析过客户账单,
完成3个完整项目账单优化支持工作
职责:
负责数据库参数调优、性能分析,架构测试与建议
数据库方向
岗位:
AWSAssociate认证。
有DB相关认证,DB专向运维实践工
作超过2年
系统与应用运维方向
职责:
负责操作系统,系统内应用的问题排查与优化
岗位:
AWSAssociate认证。
有MSCEorRHCE相关认证,系统运维实践工作超过2年
二线运维
技术中心
二线运维
网络方向
职责:
负责操作系统,系统内应用的问题排查与优化
岗位:
AWSAssociate认证。
有MSCEorRHCE相关认证,系统运维
实践工作超过2年
CICD与容器方向
职责:
负责CICD与容器类方案实施,配置调试与流程完善
岗位:
AWSAssociate认证。
Devops运维开发2年以上经验,docker
实践经验1年以上
职责:
对架构、系统、应用、权限、安全合规等方面进行全面审计
与建议
安全方向
岗位:
AWSAssociate认证。
对安全领域有全面了解,做过企业级
安全顾问
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)的故障,下同)的处理过程中,如果需要对系统进行变更,必须按照变更管
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 计算中心 事件 问题 管理 流程