PHP 项目如何应对突发伤病的变数？
这个问题有点歧义,我先按两种常见理解展开，你可以对照你的实际场景取用。
团队人员"突发伤病"（最常见场景）
PHP 项目往往人手紧、文档少，核心开发一病倒就抓瞎，应对思路：
降低"单点依赖"
- 代码所有权分散：关键模块至少 2 人能上手，避免"只有张三懂支付回调"。
- 结对/轮岗：核心链路定期轮换负责人。
- 文档即代码：部署步骤、环境变量、第三方密钥位置、定时任务清单写进仓库 README，别只存在某人脑子里。
让系统能"带病运行"
- 灰度与开关：新功能用 feature flag，出问题能一键关闭，不必等原负责人回来改代码。
- 降级预案：支付、短信、推送等外部依赖要有 fallback（如队列重试、人工补偿入口）。
- 监控告警：Sentry/Prometheus + 值班告警，伤病期间靠系统报警而非靠人盯。
交接机制
- 建立 on-call 备份人 制度，主备双人。
- 关键操作（发版、数据修复、密钥轮换）走 runbook，任何人照文档可执行。
- 紧急联系人清单（含第三方服务商、云厂商工单通道）。
流程兜底
- 代码评审强制 ≥1 人，防止知识只进不出。
- 发版窗口与变更冻结期结合,人员缺位时自动进入"只修 bug 不发版"模式。
- 用 CI/CD 固化发布流程，减少"必须某人在场才能发"。
业务运行中"突发流量/故障"变数（系统侧）
如果你的"伤病"是比喻系统突发异常：
- 弹性伸缩：PHP-FPM 进程数、容器副本按负载自动扩，配合 opcache/preload 降低单请求成本。
- 限流熔断：Nginx/网关层限流，核心接口熔断，防止雪崩。
- 队列削峰：耗时任务丢队列（Redis/RabbitMQ），Web 层快速返回。
- 多活/降级页：静态降级页、只读模式开关。
- 快速回滚：镜像/代码 tag 可秒级回退，DB 迁移用 expand-contract 模式保证可回滚。
给你的落地清单（按优先级）
- 列出核心链路和唯一负责人，本周内补齐备份人。
- 写 3 份 runbook：发版、回滚、常见故障处理。
- 给关键功能加 feature flag 和降级开关。
- 配好告警到群,确保伤病期间有人/有系统兜底。
- 做一次"负责人请假一天"的演练，看哪里断。
如果你能说明具体是团队人员伤病还是系统突发故障，以及项目规模（几人团队、什么业务），我可以给更针对性的方案。
