运维应急流程
原创 gaolc888 运维笑谈 2023-11-16 08:00 发表于广东 收录于合集#运维流程3个1. 目的
规范IT紧急故障的处理过程，以最快时间诊断和定位故障原因，采取或制定最佳应急方案，在最短时间内恢复系统故障。
2. 正文
2.1 术语定义
紧急故障处理是运营体系服务保障中的重要组成部分，目的是在服务异常发生时迅速响应，并将所有处理故障的应急人员集中在同一地点，以最快时间诊断和定位故障原因，采取或制定最佳应对方案，使之在最短时间内恢复服务。
2.2 职责分工
流程责任人
1) 确保本流程的设计、实施、回顾和改进；
2) 负责本流程及附件文档的更新维护；
3) 回顾流程执行情况，反映存在问题，提出改进建议，制定改进计划；
4) 组织故障回顾，邀请相关人员对故障处理过程、故障原因分析及改进措施进行评审。
应急处理组
1) 应急处理组包含运维（含业务运维人员、各专业组资深人员及运维领导）、研发人员、通讯人员等 。各专业组人员须为专业组内资深人员，以保证诊断结果及原因定位的有效性，提高紧急故障处理时效。主要职责：
2）接受当前决策人的工作安排；
3）诊断、定位故障点；
4）根据诊断结果，提供解决方案；
5）执行决策人决策的恢复方案；
6）为系统或IT组件运维人员撰写故障报告提供相关信息，如故障处理过程信息；如为责任方，需提供提供事件的原因分析及解决方案。
通讯人员
由运维组承担邮件、电话、企业微信等沟通工作。信息知会机制如下：
1) 启动时：发送故障通知和发起电话会议，及时进行信息传递共享；
2) 处理过程中：每30分钟发布进展信息，确保异常的及时跟进及应对；
3) 关闭时：发送故障关闭通知。
故障知会格式
XX紧急故障通知示例模板如下：
故障时间：10:00-现在异常原因：网关接口请求出现大量超时影响范围：部分客户下单交易预计恢复时间：11:00紧急程度：高处理人：
XX紧急故障进度同步示例模板如下：
故障时间：10:00-现在异常原因：网关接口请求出现大量超时影响范围：部分客户下单交易预计恢复时间：11:00紧急程度：高处理人：当前进度：已找到具体原因，并发量太高，导致超时，目前正在紧急扩容恢复中
运维人员（含业务运维人员、IT组件专业组资深人员及运维总监）
1) 针对处理的事件或发现的异常现象，如无法单独解决，需立即将问题现象、可能或已造成业务影响信息升级至组长，由组长与总监决策是否启动及召集应急处理组。
2) 确认是否更新应急预案。
3) 收集故障信息，撰写故障报告并跟进故障报告中改进措施完成情况。如为应用系统故障,则由系统运维人员负责撰写及改进跟踪，如为IT组件故障，如存储、网络、中间件或数据库等故障，则由对应IT组件的人员负责撰写及改进跟踪。
决策人
决策人安排如下：第一决策人：资深组长及组员；第二决策人：运维总监；第三决策人为CTO。
1) 根据运维人员或运维组长提供的故障信息，决策人负责集结资源对系统故障进行诊断、定位与恢复；
2) 全权负责指挥紧急故障的处理，决策各专业组提供的解决方案是否执行；
3) 故障发生后，审核并决定故障处理进展信息的发布；
4) 第一决策人：第一决策人可为资深组长及组员。负责判定是否启动应急处理组，召集相关人员处理重大故障 ，30分钟内如故障未恢复，将升级至第二决策人；
5) 第二决策人：故障启动60分钟内，应用仍未恢复，将升级至第三决策人（CTO）；
6) 故障处理完成后，确认是否需要制定或更新应急预案。
| 重大事件（P0/P1）升级机制 | ||||
|---|---|---|---|---|
| 故障处理决策人 | 运维工程师 |
第一决策人 （运维组长/资深组员） |
第二决策人 （运维总监） |
第三决策人 |
| 处理时效 | 10分钟内 | 30分钟内 | 60分钟内 | |
2.3 管理内容
2.3.1 故障来源及优先级
根据业务及管理要求，定义如下故障来源：
|
编号 |
来源 |
描述 |
|---|---|---|
| 1 | 用户报障 | 指因业务系统错误、反映系统部分或全部功能不能正常使用的用户报障以及系统用户根据业务需求提出的应用类请求和咨询； |
| 2 | 监控告警 | 监控管理平台上报的影响系统正常使用的告警； |
| 3 | 运维发现 | 指运维人员的日常维护作业中发现的事件； |
事件优先级：故障发生时，为了在判断优先级时增强实际可操作性，可以根据事件的影响范围和影响程度在优先级映射表中定位优先级。
|
影响状况 影响范围 |
系统完全中断 |
系统核心功能不可用 |
系统核心功能异常 （含缓慢） |
系统非核心功能异常 （含缓慢） |
数据异常 |
本地客户端异常 |
其他 |
|---|---|---|---|---|---|---|---|
| 全网用户 | P0 | P0 | P1 | P2 | P2 | P3 | P3 |
| 部分用户 | P1 | P1 | P2 | P3 | P3 | P3 | P3 |
| 个别用户 | P3 | P3 | P3 | P3 | P3 | P3 | P3 |
| 其他 | P3 | P3 | P3 | P3 | P3 | P3 | P4 |
应急处理组启动条件
监控报警或用户报障后，事件处理人无法单独处理且必须召集各专业组配合处理的故障，需立即升级至组长，组长判定无法解决且必须召集各专业组配合处理的故障反馈给运维总监。（已有解决方案的除外）。
判断维度参考如下：
1) 两个以上（含）区域同时缓慢或不可用；
2) 两个节点以上（含）同时不可用；
3) 系统核心功能不可用，无论影响范围如何；
4) 生产机房的基础架构设备故障。
满足以上维度之一，且预计在20分钟内无法解决，需召集相关人员处理紧急故障。
-
紧急故障类型：应用或基础架构异常未造成业务影响，则启动类型为内部故障。如造成业务影响则启动类型为故障；
-
紧急故障通知机制：如故障类型为内部故障，则通知对象为应急处理人员（含对应的总监）及服务管理组；如故障类型为故障，则通知对象为则通知对象为应急处理人员（含应急处理总监）及服务管理组、产品经理等；
-
故障报告：所有影响业务系统的P1\P2类事件，运维人员需按照故障报告模板撰写故障报告，并按照故障报告的要求提交给相关人员评审。运维人员对造成的系统影响进行分析，责任方提供事件的原因分析及解决方案。
2.3.2 流程概况
| 流程目的 | 规范紧急事件的处理过程，以最快事件诊断和定位故障原因，采取或制定最佳应对方案，在最短事件内恢复系统故障。 | ||
|---|---|---|---|
| 流程起点 | 故障启动 | 流程终点 | 故障报告撰写 |
| 关键控制点 |
01 故障启动 02 专业组集合 03 故障诊断 04 应急方案 05 制定恢复方案 06 实施方案 07 服务恢复 08 故障报告撰写 |
||
2.3.3 流程图
2.3.4 流程说明
|
活动编号 |
活动名称 |
时效要求选填 |
活动说明 |
输出信息 |
执行角色 |
|---|---|---|---|---|---|
| 01 | 启用紧急故障处理 | / | 符合启动条件，启动紧急故障。决策人可为总监或总监授权的资深组长及组员。 | / | 决策人 |
| 02 | 发送启动短信/邮件 | 5分钟 | 紧急故障决策人决定启动时，通讯员立即根据固定格式发送启动邮件/短信通知。发送对象：系统应急处理组人员、所有管理相关人员、产品经理。 | 短信/邮件通知 | 通信人员 |
| 03 | 紧急故障处理集合 |
5分钟 |
收到召集短信和邮件后，所有受邀参与人员均应在5分钟内到达紧急故障处理现场并服从第一决策人工作分配，如无法到达现场，需在5分钟内电话接入现场。 | / | 应急处理组 |
| 04 |
故障诊断 |
20分钟 |
各专业组根据各自的故障处理分析思路，将初步诊断结果反馈给决策人。 | / | 应急处理组 |
| 05 |
应急方案 |
/ |
根据故障现象、诊断结果各专业组提供解决方案建议，共同制定恢复方案，当前决策人决策恢复应用所使用的恢复方案时，应急处理组根据恢复方案实施步骤，处理系统故障，尝试恢复应用，进行恢复方案的选择时，需注意如下事项： 1、如近期有相关联的发布或者变更，优先判定是否回滚可解决，如回滚方案可行则执行回滚方案； 2、在选择一套方案的同时，可安排备选方案。需要时，可在第一套方案实施同时安排备选方案的测试工作，以便在首选方案异常时进行方案切换； 3、当前决策人每30分钟必须对选择方案的实施进展进行跟踪，当反馈异常时，考虑进行备选方案的切换； 4、没有做过的方案，如果有条件，一定要测试后方能在生产环境实施，如果解决事件需要进行重大变更，需要紧急通知相关人员对风险进行充分评估后才能上生产环境。 |
/ | 当前决策人 |
| 06 | 制定恢复方案 | / | 当前决策人负责组织应急小组进行共同分析（可能包括运维、研发、供应商），各专业组根据故障点，提供解决方案建议，并共同制定恢复方案。 | / | 应急处理组 |
| 07 |
实施方案 |
/ |
当前决策人决策恢复应用所使用的恢复方案； 应急处理组根据恢复方案实施步骤，处理系统故障，尝试恢复应用。 |
/ | 应急处理组 |
| 08 | 发送处理进展通知 | 30分钟 | 事件处理人每30分钟收集一次处理进展情况并通知邮件，发送对象与通知邮件对象保持一致 | 处理进展通知 | 通讯人员 |
| 09 |
恢复验证 |
/ | 应急处理组确认故障现象消失后，如用户已报障，事件处理人应与关键用户确认应用是否完全恢复。如已恢复，进入步骤10；如未恢复，返回步骤4。 | / | 应急处理组 |
|
10 |
关闭故障 | / | 用户确认应用完全恢复后，发送“紧急故障关闭通知”，发送对象与启动通知一致，如用户已报障，发送对象需增加终端用户。 | 关闭通知 | 通讯人员 |
| 11 |
故障报告撰写 |
2个工作日 |
运维人员组织故障原因分析，收集故障信息撰写报告，提交审批并跟进审批结果以及改进项完成情况。 如未找到故障原因，决策人需在1个工作日内反馈再次出现该异常时的应急预案。 |
/ | 应急处理组 |
| 12 | 组织故障回顾 | / | 定期组织故障回顾，协调相关人员对故障处理过程、故障原因分析及改进措施进行评审并持续优化流程。 | / | 流程owner |
2.3.5 故障报告提交时效说明
故障发生后，以故障开始时间为准， 2个工作日内编写及提交故障报告至上级领导，详见附件1《故障报告模板》。
2.3.6 故障报告审核时效说明
故障报告提交后2个工作日内需完成审核。提交故障后，故障报告编写人应该跟进报告的审批进度。完成审批后将故障报告提交至IT服务管理组。
服务管理组定期组织故障回顾，推动并确保改进措施落地及应急处理方案更新。
3. 解释
本流程制度由运维中心负责解释。
4. 附录
1、故障报告模板
| 故障报告 | |||||||
| 故障主题 | |||||||
| 发生时间 | 发现时间 | 影响时长 | |||||
| 恢复时间 | 发现途径 | 故障级别 | |||||
| 事故归属 | |||||||
| 原因分类 | |||||||
| 故障内容 | 影响范围： | ||||||
| 影响内容： | |||||||
| 事故原因： | |||||||
| 处理过程： | |||||||
| 改进措施 | 序号 | 改进项 | 计划完成时间 | 负责人 | |||
| 1 | |||||||
| 2 | |||||||
| 3 | |||||||
| 4 | |||||||
https://www.processon.com/view/link/5c05e5d0e4b0059238d51465
重大故障处理流程图
- END -
求分享、求在看、求点赞
人划线
标签：P3,运维,处理,流程,决策,故障,应急 From： https://www.cnblogs.com/cherishthepresent/p/17865121.html