稳定性运营体系Incident Management就是把“出事了靠高手救火”变成“谁值班、怎么判断、先止血再修复、最后不再复发”的标准化流水线。 在 Hyperf 场景里常驻进程、协程、连接池、消费者这套体系比普通 PHP-FPM 项目更重要。 ---1. 先定义目标不然大家各说各话 稳定性运营目标不是“没有告警”而是这5条1. 出问题能快速发现分钟级2. 影响范围能快速判断谁受影响3. 能快速止血先恢复服务4. 根因能被确认不是猜5. 同类问题不再反复发生闭环 常用指标 - MTTD发现时长 - MTTA响应时长 - MTTR恢复时长 - 复发率30天内同类事故 - 告警噪音比无效告警占比 ---2. 告警分级先分级再处理 建议4级 - P1严重核心业务不可用/大面积失败 例如登录、支付、下单挂掉。 处理立即拉群电话5分钟内有人接手。 - P2高核心功能明显退化但未全挂 例如错误率上升、P95飙升、MQ积压严重。 处理15分钟内响应。 - P3中局部异常或趋势异常 例如单实例内存缓慢上涨、某下游偶发超时。 处理工作时段跟进。 - P4低优化类提醒 例如磁盘利用率偏高、可优化项。 处理排期处理。 告警必须包含的字段 - 服务名、环境、版本号 - 告警规则和阈值 - 影响接口/租户 - 最近发布链接 - 一键跳转日志、指标、链路、Runbook ---3. 值班流程谁在、谁拍板、谁复盘3.1角色分工 - ICIncident Commander事故指挥负责决策和节奏 - Ops/SRE执行止血、回滚、扩容、流量切换 - 服务Owner技术排查和修复 - 业务Owner业务影响评估与外部沟通 - 记录员实时记录时间线后续复盘依据3.2值班制度 - 主值班 备值班避免单点 - 交接班必须有状态摘要未解决告警、风险变更 - 值班电话/IM必须可达超时自动升级3.3升级路径Escalation -5分钟无人响应 -自动升级到备值班 -10分钟未止血 -升级平台主管/技术负责人 - P1超30分钟 -启动应急机制冻结发布管理层同步 ---4. 事故处理标准流程最核心 Phase A识别0-5分钟 做三件事1. 这是不是“真实事故”排除误报2. 影响范围有多大全站/局部/单租户3. 当前严重等级P1/P2/P3 Phase B止血5-20分钟 原则先恢复再定位。 常见止血动作 - 回滚到上个稳定版本 - 关闭高风险开关 - 限流/降级非核心功能 - 扩容实例 - 暂停有问题的消费者 - 熔断异常下游 Phase C定位并行进行 - 看变更最近30分钟发布了什么 - 看链路从入口到下游哪个环节先异常 - 看资源CPU、内存、FD、连接池、队列积压 - 看日志错误码、超时、重试风暴 Phase D恢复确认 - 核心SLO回到阈值内 - 观察至少15-30分钟 - 宣布“已恢复”但保留监控 Phase E复盘立项 -24小时内初版复盘 -72小时内闭环动作定责与排期 ---5. Hyperf 场景的高频事故类型与速查动作1. 协程上下文污染 - 现象数据串号、用户信息错乱 - 速查单例是否持有请求态Context使用是否规范 - 止血回滚关闭新逻辑路径2. 连接池耗尽DB/Redis - 现象大量 timeoutP95飙升 - 速查池大小、等待时长、慢查询 - 止血临时扩容限流慢SQL兜底3. 消费者堆积 - 现象MQ backlog激增业务延迟 - 速查消费异常率、重试死循环、下游依赖 - 止血暂停异常消费组、扩消费者、死信隔离4. 常驻进程内存泄漏 - 现象内存持续上涨worker重启 - 速查近期变更、对象缓存、静态变量 - 止血滚动重启回滚限流5. 重试风暴 - 现象下游稍慢导致上游重试放大 - 速查超时配置和重试策略是否合理 - 止血关闭重试或降级开启熔断 ---6. Runbook操作手册标准化 每个 P1/P2 告警都要对应 Runbook结构固定1. 告警说明触发条件2. 影响判断业务面3.5分钟止血步骤4. 深入排查步骤5. 回滚步骤6. 升级联系人7. 恢复确认标准 这样值班新人也能处理不依赖“某个大神在线”。 ---7. 复盘机制不是找人背锅 复盘目标找系统问题不做情绪输出。 复盘模板建议固定1. 事故摘要影响范围、时长、等级2. 时间线分钟级3. 根因技术根因 机制根因4. 为什么没提前发现监控/流程缺口5. 止血动作评估哪些有效哪些慢6. 长期修复项负责人、截止日期7. 预防项监控、门禁、演练、文档 重点 - 每个复盘动作必须进工单系统 - 设定截止时间 - 周会上追踪完成率 ---8. 问题闭环与复发预防真正拉开差距 闭环做4类动作1. 监控补洞新增指标和告警减少盲区2. 发布门禁把事故触发条件变成发布前检查3. 自动化止血阈值触发自动暂停灰度/自动回滚4. 演练固化把事故类型做成季度演练剧本 一句话 同类事故第二次出现说明第一次没有闭环。 ---9. 运营节奏按周期跑 - 每日值班交接 告警清理 - 每周Top告警分析噪音、漏报、误报 - 每两周一次故障演练GameDay - 每月事故复盘动作完成率审计 - 每季度SLO与告警阈值重校准 ---10. CI/CD联动稳定性前移 上线前自动检查 - 核心接口压测回归 - 关键告警是否覆盖新改动 - 回滚路径是否可执行 - 依赖兼容是否通过PHP/Hyperf/扩展 - 高风险变更是否有演练记录 上线后自动检查 -30分钟稳定观察窗 - 指标异常自动阻断继续灰度 ---11.90天落地路线可直接用0-30天 - 建告警分级和值班表 - P1/P2告警补齐 Runbook - 打通事故群升级流程31-60天 - 统一复盘模板和工单闭环 - 上线自动暂停灰度/自动回滚规则 - 做2次典型事故演练连接池耗尽、消费者堆积61-90天 - 复盘动作完成率纳入团队KPI - 告警降噪合并、去重、抑制 - 建“高频事故预防清单”并接入发布门禁 ---12. 最后一句大白话 稳定性运营体系的本质不是“把图表做漂亮”而是“事故发生时人人知道该做什么系统能自动帮你先止血事后还能保证不再重犯” 。 在 Hyperf 里把“连接池、协程、消费者、常驻进程”这四类风险纳入统一 Incident 流程你的线上稳定性会明显提升。