Release Engineering 就是把上线这件事从“靠老员工经验”变成“像过安检一样规则固定、机器自动拦、出事能立刻撤回”。 ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 下面给你一套 Hyperf 场景可落地的完整流程。 ---1)先定目标上线不是“发版成功”而是“业务无感” 上线成功的标准不是“镜像推上去了”而是这四条1. 用户体验不变差错误率、延迟不恶化2. 出问题能5分钟内止血3. 回滚路径始终可用4. 每次上线都可追溯谁发的、发了啥、为什么发 ---2)变更分级先分级再决定流程 把所有变更按风险分4级 L1 低风险 - 文案、非核心页面、小修复 - 只改单服务、无 DB 变更、无依赖升级 L2 中风险 - 新增非核心接口、普通逻辑变更 - 有配置变更但可快速回退 L3 高风险 - 核心链路逻辑改动下单、支付、登录 - DB 结构变更、消息模型变更、依赖升级PHP/Hyperf/Swoole L4 极高风险 - 跨服务联动改造 - 分布式事务模型改动 - 核心组件替换缓存、网关、MQ ---3)每级对应发布策略不要一刀切 - L1自动发布 短观察 - L2自动发布 灰度 指标门禁 - L3灰度分阶段 人工确认点 必须回滚预案 - L4发布窗口 值班在场 演练通过后才能发 ---4)自动门禁流水线核心 流水线要像收费站不满足条件不给过。4.1提交阶段门禁 - 代码规范、静态检查 - 单测通过 - 关键模块覆盖率达标 - 敏感配置/密钥扫描通过4.2构建阶段门禁 - 依赖漏洞扫描 - 镜像安全扫描 - 版本与变更记录自动生成4.3集成阶段门禁 - 集成测试 - 契约测试上下游接口兼容 - DB migration 检查是否可回滚、是否锁表风险4.4预发布阶段门禁Hyperf重点 - 常驻进程1-2 小时稳定性观察 - 内存曲线不能持续爬升 - 连接池等待不能持续升高 - Worker 异常重启率必须在阈值内 - 消费者无明显积压 ---5)Hyperf 专项风险清单上线前必过1. 协程上下文是否串数据2. 单例对象是否持有请求态信息3. 下游调用是否都设了超时4. 重试是否只用于幂等接口5. 连接池参数是否匹配流量过小排队过大压垮下游6. 消费者失败重试和死信队列是否可用7. 优雅退出是否生效防止发布时丢任务 ---6)灰度策略标准节奏 建议固定节奏不临场发挥1% -5% -20% -50% -100% 每一步观察5-15 分钟核心看这几项 - 错误率 - P95/P99 - 超时率 - 连接池耗尽率 - MQ 积压 - Worker 重启率 任一指标超阈值自动停止推进进入回滚流程。 ---7)自动停止与自动回滚止血能力 必须提前定义“红线” - 错误率基线2倍 持续3分钟 - P95基线1.5倍 持续5分钟 - 连接池等待持续增长且无回落 - 关键消费者积压超阈值 触发后动作1. 自动暂停灰度2. 自动切回上一稳定版本3. 自动通知值班群 负责人4. 自动附带故障上下文变更单、指标图、日志入口 ---8)回滚演练不演练就等于不会回滚 每月至少一次演练覆盖两种场景1. 应用回滚新版本逻辑错误2. 数据回滚DB 变更后兼容问题 演练要记录 - 从报警到回滚完成用了多久 - 哪一步卡住了 - 下次怎么缩短时间 目标核心服务 MTTR恢复时间持续下降。 ---9)数据库变更治理最常见事故点 规则很实用1. 先“向前兼容”再切逻辑最后删旧字段2. 禁止一次发布同时做“结构大改 业务大改”3. 大表变更走在线方案避免长时间锁表4. migration 必须有回退路径5. 先灰度读新字段再灰度写新字段再全量切换 ---10)组织流程谁拍板、谁值班、谁复盘 - 发布负责人控制节奏、确认每个灰度阶段 - 值班 SRE盯指标、执行止血 - 业务负责人判断业务影响 - 复盘 owner24 小时内输出复盘与改进动作 没有明确角色上线时就会“大家都在但没人拍板”。 ---11)指标体系衡量你做得好不好 重点盯这8个1. 变更失败率2. 回滚率3. MTTR4. 灰度中断次数5. 发布 leadtime6. 发布频率7. 发布后 24h 事故数8. 因发布导致的错误预算消耗 ---12)90天落地计划可直接执行 第1-2 周 - 定变更分级规则 - 把发布步骤写成标准作业流程 - 统一灰度节奏与红线阈值 第3-6 周 - CI/CD 接入自动门禁 - 补齐 Hyperf 专项检查 - 做第一次自动回滚演练 第7-10 周 - 核心服务全部接入灰度与自动停止 - 发布可观测看板上线 - 变更复盘流程固定化 第11-12 周 - 用指标复盘失败率、MTTR、回滚率 - 调整门禁阈值减少误报和漏报 - 固化为团队默认发布方式 ---13)最小可执行版先做这6条就有明显提升1. 变更分 L1-L42. 固定灰度比例1/5/20/50/1003. 明确自动停止红线4. 一键回滚到上一稳定版本5. 每月回滚演练一次6. 发布后30分钟强制观察 签出机制 --- 一句话收尾 Hyperf 的变更风险治理关键不是“上线更慢”而是“上线更可控”风险先分级、过程全门禁、发布走灰度、故障能秒停、回滚常演练。 这样你的上线能力会从“看人”变成“看系统”。