Web 业务里 PHP 技术栈使用非常普遍。很多团队初期只关注业务功能交付，随着业务不断迭代、多版本并行、多团队维护，慢慢出现环境版本杂乱、配置不统一、变更缺少管控、线上问题定位慢等问题。
从 SRE 稳定性建设角度看，PHP 环境治理不只是简单的配置整改，而是把资产、基线、变更、观测融合起来，形成一套支撑业务长期稳定运行的体系。本文从稳定性视角，分享这套治理思路。
一、梳理治理目标，避免盲目落地
在启动治理前，先对齐目标，防止治理动作和业务目标冲突：
- 可清点：所有 PHP 实例、配套组件归属清晰，没有黑盒实例；
- 可对齐：同类业务环境配置统一，基线可复用；
- 可管控：所有版本、配置变更有记录、有评审、有回滚方案；
- 可观测：关键运行状态、文件变更、进程行为、资源指标可采集，故障定位更快；
- 可自动化：减少人工登录巡检，把核验动作交给脚本或者自动化平台。
目标先明确，后续的治理动作才不会变成一次性的大扫除。
二、资产建模：给 PHP 环境建立统一元数据模型
很多团队资产清单就是简单的 IP + 版本，信息单薄，支撑不了稳定性治理。我们给每一个 PHP 实例建立元数据模型，字段包含：
- 实例标识、部署形态（rpm 包、源码编译、容器）
- PHP 版本、已加载扩展清单
- 关联 Web 服务、数据库、缓存等依赖组件
- 业务模块、负责人、业务等级
- 部署机房 / 网段、上线时间、预期下线时间
- 当前基线版本、最近一次变更记录
这套元数据是所有后续基线比对、巡检、变更管控的基础。
收集的时候要注意区分开发、测试、预发、生产环境，生产环境优先完成盘点，低优先级环境延后落地，控制治理工作量。
三、基线标准化：分层设计基线，兼顾规范与业务兼容性
我们把基线拆成三层，而不是一份大而全的配置文档：
- 强制基线：权限模型、日志输出规范、资源基础阈值、闲置扩展禁用策略，所有环境必须遵守；
- 推荐基线：php.ini 通用参数、超时配置、内存上限，同类业务优先复用；
- 业务个性化配置：和业务强相关的参数，单独登记、单独评审，不强行统一。
分层的好处：既守住稳定性底线，又不会因为一刀切影响老旧业务。基线定稿之后，作为新环境交付模板，新实例直接套用，从源头减少配置漂移。
基线落地阶段，分批灰度验证：先低流量业务，再核心业务，每一批上线之后持续观察响应指标、报错量、资源占用，确认无异常再扩大范围。
四、变更管控：把 PHP 相关变更纳入变更流水线
配置统一之后，最大的风险来自随意变更。我们把 PHP 版本升级、扩展增减、php.ini 修改这类动作纳入统一变更流程：
- 所有变更提交变更单，写明变更内容、影响范围、验证步骤、回滚方案；
- 变更顺序：测试环境验证 → 预发验证 → 生产分批灰度；
- 变更完成后，自动比对当前实例配置和基线差异，确认变更符合预期；
- 保留完整变更日志，出现问题可以快速追溯是哪一次改动引入。
禁止线上直接临时修改配置，临时调试也要有记录、事后回归基线。
五、构建可观测链路，补齐状态感知能力
基线和变更解决 “不乱改” 的问题，可观测解决 “出问题能快速发现、定位”。针对 PHP 环境，重点采集四类数据：
- 资源指标：CPU、内存、磁盘 IO、连接数、PHP-FPM 进程池状态；
- 应用日志：错误日志、慢请求日志，对接检索平台，做告警规则；
- 进程与文件行为记录：关键目录文件变更、进程启停记录，方便追溯异常改动；
- 基线校验结果：自动比对实例当前配置和标准基线，输出差异项，持续告警。
告警策略做分级：基线偏离、资源持续高水位为 P2；业务报错突增为 P1，配套对应的 oncall 响应流程。
六、自动化巡检闭环，维持长期稳定
人工巡检很难持续，我们把基线校验做成定时自动化任务：
定时拉取实例配置，和基线对比，输出差异清单；差异项自动推送给对应业务负责人，限期整改；整改完成后再次自动核验，形成闭环。
对于规模较大的场景，可以依托自动化运维平台完成采集、比对、告警、工单推送，降低 SRE 团队重复工作量。自动化工具只是执行载体，基线标准、变更规范、告警策略依然需要 SRE 和业务开发一起定义。
七、治理落地过程中的取舍与经验
- 不要追求 100% 统一版本：老旧业务兼容性是硬约束，无法升级的实例单独标记、加强观测；
- 基线文档不要写太复杂：优先落地自动化校验，文档只写规则说明；
- 治理不是一次性项目：基线会随版本迭代更新，观测规则也需要持续调优；
- 和开发团队对齐共识：稳定性是共同目标，而不是运维单方面管控。
总结
PHP 业务栈的稳定性治理，核心思路就是资产建模→分层基线→变更流水线→全链路观测→自动化巡检闭环。这套体系落地之后，环境状态透明、变更可控、故障定位效率提升，减少线上不稳定因素。
稳定性建设是持续迭代的过程，基线、观测规则、变更流程，都要跟随业务迭代持续优化。
声明：本文为 SRE 稳定性工程实践分享，仅用于技术交流。
