系统故障分级上报与处置流程

系统故障分级上报与处置流程一、总则1.1目的与适用范围系统故障造成的损失，三分取决于故障本身，七分取决于发现、上报与处置的速度。同样一次数据库主从切换，15分钟内按预案执行的业务影响是短暂降级，2小时后仍无人处置则可能演变为数据不一致、订单丢失、客诉爆发。本流程旨在将故障处置从「依赖个人经验」转变为「按级别走既定动作」，让值班工程师、部门负责人、管理层在故障发生的每一分钟都知道自己该做什么、什么时候必须升级、向谁求助。适用范围：本公司生产环境全部对外业务系统（含门户网站、订单系统、支付相关系统、内部ERP、办公协同系统）及其依赖的基础设施（服务器、网络、数据库、中间件、云资源）。测试环境、开发环境故障不在本流程范围内，由开发团队自行处理。1.2基本原则•先恢复、后溯源：故障期间一切动作以恢复业务为最高优先级，根因分析在业务恢复后48小时内完成。•宁可误报、不可漏报：拿不准级别时按高一级上报。漏报导致处置延误的责任重于误报。•留痕：所有处置动作必须实时记录在故障工单系统中，事后以工单记录为准，不接受口头补充。二、故障分级标准分级是本流程的枢纽：级别决定响应时限、上报路径和处置权限，定级错误会直接导致资源错配。判断级别时看三个维度——影响范围（多少用户/多少业务）、影响程度（完全不可用还是部分降级）、有无数据损失风险。三个维度取最高者定级。2.1四级定义级别名称判定标准（满足任一条即定级）典型场景P1重大故障核心业务系统整体不可用超过5分钟；涉及资金交易错误或数据丢失；影响用户数超过50%；安全事件（被入侵、数据泄露）订单系统宕机、支付回调全部失败、数据库主库损坏、遭勒索攻击P2严重故障核心业务可用性低于50%或持续降级超过15分钟；非核心业务完全不可用；性能劣化导致核心接口P99响应时间超过5秒数据库主从延迟持续扩大、缓存集群过半节点失效、CDN故障导致页面加载超10秒P3一般故障非核心功能异常，不影响主流程；核心业务降级但可用性不低于90%且预计2小时内可恢复消息推送延迟、某个非关键报表打不开、单台从库故障P4轻微故障无用户感知，仅监控告警或个别内部人员反馈；不影响任何业务功能日志磁盘告警、单次定时任务失败且可重跑、监控探针抖动2.2定级争议裁决•值班工程师5分钟内完成初步定级；拿不准时按高一级处理，后续可降级。•P1与P2的争议由值班的部门负责人（或其授权人）在10分钟内裁决，裁决结果记入工单。•故障处置过程中影响范围扩大的（如P3的报表异常实际暴露出订单数据错误），立即重新定级并按新级别重新上报，不得沿用原级别。三、上报路径与时限上报的核心是「时间触发升级」：不是等处置完才上报，而是超时未恢复就必须升级，把决策权交给更高层级和更多资源。3.1各级上报要求级别首报时限首报对象升级规则P1发现后5分钟内值班工程师→运维主管→IT部门负责人→分管副总（电话，逐级或越级同时进行）每30分钟未恢复，向上级层通报一次进展；恢复前不得中断通报P2发现后15分钟内值班工程师→运维主管→IT部门负责人（工单+电话）1小时未恢复升级为P1流程，通知分管副总P3发现后1小时内值班工程师→运维主管（工单即可）4小时未恢复升级为P2，改为工单+电话上报P4发现后4小时内值班工程师记录工单无自动升级；连续3天同类P4告警累计5次以上，按P3立项排查3.2通报内容（首报六要素）首报不要求查清原因，但必须包含以下六项，缺项视为上报不合格：1.故障现象（什么系统、什么表现、从几点开始）2.初步定级及依据3.影响范围（受影响的业务、用户量估算）4.已采取的动作及结果5.初步怀疑方向6.当前是否需要额外资源或授权3.3严禁事项•严禁隐瞒故障不上报——未按本流程上报的故障，事后在监控或用户投诉中暴露的，无论故障本身大小，一律按责任事故追责。理由：隐瞒使团队失去最宝贵的处置窗口，且失去复盘机会。•严禁在未留痕的情况下口头处置后不补工单——替代方案：先建工单再动手，哪怕工单内容只有一句话。•严禁绕过工单系统直接在聊天群里「解决」故障——替代方案：群里只做同步和协调，动作记录必须在工单内更新。四、处置流程与职责4.1角色与职责角色职责授权范围值班工程师发现、初判定级、首报、一线处置、全程记录可执行标准预案内操作（重启服务、切换从库、回滚最近发布）运维主管（P1/P2担任故障指挥官）确认/调整定级、调度资源、对外通报、决策重大操作可授权停用子系统、切换机房流量IT部门负责人P1现场总协调、跨部门协调、重大决策（如对外公告）可决定暂停对外服务、启动业务降级预案分管副总P1重大决策（对外声明、赔付方案、报案）全部资源相关业务系统开发负责人配合定位代码/数据问题、执行紧急修复可执行紧急代码修复，须双人复核后发布4.2处置标准动作（按时间轴）0~15分钟（遏制）：•确认故障真实性与范围（排除监控误报），比照runbook执行预案内止血动作：优先使用预案内自动切换（如数据库主从切换、服务摘除）；无预案可用时，执行最近一次变更的回滚。机理：80%以上的故障由近24小时内的变更引起，先回滚到已知稳定版本，再排查根因，比在故障现场边排查边修复快得多。严禁在未回滚的情况下带故障现场「热修复」新版本——新代码叠加未知状态会使故障更难定位。•P1/P2同时在指挥群（预建、常驻）同步进展，每15分钟一次。15~60分钟（恢复）：•若预案动作无效，故障指挥官组织二线（对应系统开发负责人、DBA、云厂商支持）介入。•评估是否启动业务降级：优先使用预案内降级开关（如关闭非核心推荐、切静态页）；无降级开关的系统，可决定暂停该服务并对外展示维护公告；严禁让系统带着全线报错的状态继续对外服务——大量失败请求的重试风暴会把故障扩散到健康的上游系统。60分钟~恢复（攻坚）：•每次操作前先在工单记录「打算做什么、预期结果」，操作后记录实际结果。机理：多人同时处置时，无记录的并行操作会互相覆盖，典型后果是A刚恢复的服务被B的排查动作再次打停。•P1超过4小时未恢复，由IT部门负责人决定是否启用灾备环境整体接管（RTO目标4小时，按现有同城灾备架构推算）。4.3恢复确认与关闭•恢复判定标准：核心业务指标连续30分钟恢复至故障前基线水平的95%以上，且无新增告警。•P1/P2恢复后观察期2小时，观察期内值班工程师不得离岗；P3/P4观察期30分钟。•满足标准后由故障指挥官在工单中宣布恢复，向受影响业务方通报，关闭应急状态。五、应急预案与异常处置5.1处置失败的回退机制任何处置动作必须有回退路径，执行前明确「这一步失败怎么办」：•数据库主从切换失败：优先重试一次完整切换流程；仍失败则保持现状并评估新主库数据一致性（比对GTID/日志位点），不一致时以原主库为数据基准做最终一致修复；严禁在数据一致性未确认的情况下双写两个主库——双写造成的数据分叉，修复成本是故障本身的十倍以上。•紧急修复发布失败：回滚到上一版本，改用降级或停服方案；严禁连续快速重试发布超过2次。•云资源故障：优先启用多云/多可用区冗余；无冗余的，向云厂商提交紧急工单（P1案例通常可获得优先响应），同时评估业务侧临时方案（如引导用户至人工渠道）。5.2次生风险阻断次生风险演化路径阻断措施重试风暴下游故障→上游超时重试→流量放大数倍→上游也被压垮→故障全链路扩散故障期间在上游网关关闭或指数退避重试，熔断非核心调用数据不一致主从切换→切换瞬间部分事务未同步→库存/订单数据分叉→超卖或丢单切换后立即启动数据比对脚本，差异记录并人工裁决修复顺序故障期间误操作多人同时登录生产环境→并发操作互相覆盖→二次故障P1期间生产变更须故障指挥官口头批准+工单登记，单人单操作舆情风险用户侧长时间不可用→社交平台投诉发酵→媒体关注P1超过1小时，由市场部准备对外口径，经分管副总批准后统一发布5.3外部依赖故障的特殊处置当故障根因在第三方（云厂商、运营商、支付通道、短信服务商）：•仍按本流程定级上报，不得因「不是我们的问题」降低响应级别。•30分钟内联系对方技术支持并索取故障单号，记录在工单。•启用备选通道：优先切换至备用服务商标配置好的热备通道（切换目标15分钟内完成）；无热备的，启用人工/线下兜底流程并对外公告；严禁无兜底方案的业务在上游故障时让用户反复重试。六、复盘与改进复盘的目的不是追责个人，而是找到系统性缺陷——每一次未复盘的故障，都在为下一次同样的故障缴费。P1/P2故障恢复后3个工作日内召开复盘会，由IT部门负责人主持，参与处置的全部人员及受影响业务方代表参加；P3按季度批量复盘。复盘会产出物（会后2个工作日内归档）：1.时间线：从故障发生到恢复的完整动作时间线，精确到分钟，标注每个决策点。2.根因分析：用「五个为什么」追问至系统性层面（如「磁盘满了→没人清理→没有自动清理任务→监控项缺失→监控清单从未随架构变更更新」），停在「某人的失误」即为不合格的根因。3.改进项清单：每项写明负责人、完成时限、验收标准。改进项逾期未完成的，由IT部门负责人在月度例会通报，连续逾期两次升级至分管副总。4.预案更新：本次故障暴露的预案缺口（如缺少降级开关、缺少runbook）登记入预案待办清单，下季度末前完成补齐率不低于80%。改进闭环（PDCA）：改进项完成→下一次例行演练中验证（每半年一次故障演练，随机抽取一个历史故障场景模拟）→演练不达标的改进项重开→结果计入下季度复盘。七、附则•本流程自发布之日起施行，由IT部门负责解释和修订，每年评审一次。•全员（含新入职运维、开发人员）须在入职后2周内完成本流程培训并通过考核（笔试+一次模拟故障演练），培训记录由人力资源部存档。•本流程与《中华人民共和国网络安全法》及公司《信息安全管理制度》《生产变更管理办法》配套执行；涉及数据泄露、网络攻击的事件同时按公司《信息安全事件管理制度》上报。附件一：故障处置记录单（样表）字段填写内容工单号（工单系统自动生成）故障发现时间2025-XX-XXXX:XX发现人/发现渠道张某某/监控告警初步定级及依据P2/核心接口P99超5秒，持续20分钟影响范围订单查询功能降级，影响用户约XX%定级调整记录XX:XX由P2升级为P1，裁决人：李某某处置动作时间线XX:XX回滚v2.3.1发布；XX:XX切换只读流量至备库介入人员值班：王某某；指挥官：运维主管；二线：订单系统开发负责人恢复确认时间与标准XX:XX，核心指标连续30分钟达基线95%以上复盘会日期恢复后3个工作日内附件二：应急联络通讯录（模板，实际发放时填写）角色姓名手机备用联系方式升级顺序值班工程师（当日）值班群@值班第一响应运维主管第二级IT部门负责人第三级分管副总第四级DBA/网络工程师按需云厂商紧急支持（厂商工单入口）紧急工单电话按需通讯录每季度核对更新一次，由运维主管负责；变更后2