企业官网建设流程全解析

环境整理（pro、sit、uat、test、pre、dev、fat）——这七个缩写，几乎刻在每个中大型软件交付团队的每日站会白板上，也高频出现在CI/CD流水线日志、Jenkins构建任务名、Kubernetes命名空间标签、Git分支策略文档里。如果你刚接手一个遗留系统运维，或者正被测试环境反复“飘移”搞得焦头烂额；如果你在部署时总被问“这个配置改过没？在哪改的？”，又或者开发提测前突然发现UAT环境数据库版本比DEV高了两版……那今天这篇，就是为你写的。它不讲抽象理论，不堆概念图谱，只拆解真实项目里怎么把这七类环境从“口头约定”变成“可验证、可追溯、可重建”的实体——包括命名规范怎么定、网络隔离怎么落地、数据同步如何防污染、配置管理怎么避免“改一处崩三处”，以及最关键的：为什么必须严格区分FAT和SIT，而PRE和UAT在验收流程中根本不能互换。我带过12个跨行业交付项目，从金融核心账务系统到工业IoT平台，踩过所有环境混乱的坑：比如某次上线前夜，因DEV环境误连生产Redis导致缓存雪崩；又比如客户在UAT签字后，发现FAT环境跑的是旧版前端静态资源，回滚失败直接延期两周。这些都不是技术故障，而是环境治理失效。本文将用你每天打交道的工具链（Docker Compose、Ansible、GitLab CI、Nginx Ingress、Vault）还原一套轻量但完整的环境治理体系，所有配置可直接复制粘贴，参数值附带计算依据，每一步都标注“为什么这么设”。尤其针对国内企业普遍存在的混合部署场景（部分服务在VMware Workstation Pro本地调试、部分在物理机集群、部分跑在云厂商VPC内），给出网络拓扑与DNS解析的实操方案。关键词pro、sit、uat、test、pre、dev、fat不是标签，是责任边界——这篇文章，就是帮你把边界画清楚、守得住。

1. 环境分层的本质：不是技术分区，而是责任流与风险漏斗

1.1 七类环境的真实定位与不可替代性

很多人把pro、sit、uat、test、pre、dev、fat简单理解为“从开发到上线的七道关卡”，这是最大误区。它们本质是不同角色对同一套代码/配置/数据行使决策权的法定沙盒，每一层都对应明确的责任主体、准入门槛和退出机制。混淆任意两层，等于让财务人员审批采购合同的同时兼任仓库验货员——流程看似快了，风险却指数级放大。

• DEV（Development）：开发者私有工作区。关键特征是可随意破坏、无需审计、允许单点调试。我见过最典型的错误是把DEV数据库挂载到共享NAS，结果A同事删表重建，B同事正在联调接口，整个下午全员阻塞。正确做法是每人本地运行Docker容器化DB（PostgreSQL或MySQL），通过docker-compose.yml绑定host路径做schema备份，启动命令加--rm确保容器退出即销毁。DEV环境唯一产出物是Git commit，其他任何变更都不应进入CI流水线。

• FAT（Factory Acceptance Test）：设备/系统出厂验收测试环境。常被误认为“内部UAT”，实则定位完全不同——FAT由集成商主导、客户代表旁观、第三方监理见证，目标是验证软硬件整体交付包是否满足合同技术条款。例如某电力SCADA系统FAT需实测“5000点遥信变位响应时间≤200ms”，这就要求FAT环境必须复现客户现场的网络延迟（用tc命令注入20ms RTT）、IO负载（fio压测磁盘IOPS）和终端数量（locust模拟300并发HMI连接）。FAT通过后签署《出厂验收证书》，法律效力等同于交付完成。

• SIT（System Integration Test）：系统集成测试环境。核心任务是验证本系统与上下游依赖系统的协议兼容性与数据一致性。典型场景：银行核心系统升级后，需在SIT中对接支付网关（模拟银联前置机）、反洗钱系统（对接人行AML平台）、电子渠道（对接手机银行APP）。这里的关键陷阱是“假集成”——用Mock服务代替真实依赖。我曾处理过一个案例：SIT用Mock返回固定JSON，结果上线后真实网关返回XML格式，SOAP解析直接崩溃。正确做法是SIT必须部署真实依赖的最小可用实例（如用Docker跑简化版支付网关），仅关闭其资金结算功能，保留报文收发与签名验签逻辑。

• UAT（User Acceptance Test）：用户验收测试环境。决策权完全归属业务方，技术团队仅提供支持。UAT成功标志不是“所有用例通过”，而是“业务负责人签字确认满足业务需求”。因此UAT环境必须100%复现生产数据结构（脱敏后）、终端设备（真实POS机或柜面终端）、操作流程（使用客户实际培训手册）。常见错误是UAT用Chrome浏览器测试，而客户生产环境强制使用IE11——结果上线后JS语法报错。解决方案：UAT环境部署IE兼容模式的Web服务器（如Nginx配置add_header X-UA-Compatible "IE=EmulateIE11"），并预装客户指定的Java Runtime版本。

• PRE（Pre-production）：准生产环境。这是技术团队最后的风险过滤器，目标是暴露生产环境特有的非功能性问题。PRE必须与PRO完全同构：相同服务器型号（哪怕虚拟化）、相同网络拓扑（包括防火墙策略）、相同中间件版本（WebLogic 14.1.1.0而非14.1.0.0）、相同监控探针（Zabbix agent配置项逐条比对）。PRE不执行业务用例，只做三件事：全链路压测（JMeter模拟峰值流量）、灾备切换演练（手动触发主备库切换）、配置变更回归（修改一个Nginx timeout参数，验证所有服务健康检查通过）。PRE失败意味着PRO必然失败，必须立即冻结发布。

• TEST（Testing）：专项测试环境。常被当作“测试人员的DEV”，实则承担质量门禁职能。TEST环境由QA团队独占，禁止开发人员登录。所有自动化测试（单元测试、API测试、UI测试）必须在此环境执行，且测试报告自动归档至Jira。关键设计是TEST的数据库必须每次测试前重置——我们用Flyway管理migration脚本，每次CI构建时执行flyway clean && flyway migrate，确保测试基线纯净。曾有个项目因TEST环境DB残留历史数据，导致“订单超时取消”用例始终失败，排查三天才发现是上轮测试未清理测试订单。

• PRO（Production）：生产环境。唯一目标是持续稳定提供业务服务。PRO严禁任何未经审批的变更，所有操作必须通过堡垒机审计、所有配置必须经GitOps同步（Argo CD监听config repo）、所有数据库变更必须走Liquibase灰度发布。PRO的监控阈值（如CPU>85%告警）必须比PRE低5%，因为PRO需要预留缓冲应对突发流量。

提示：七类环境不是并列关系，而是嵌套式责任漏斗。DEV的输出是SIT的输入，SIT的输出是UAT的输入，UAT的输出是PRE的输入，PRE的输出才是PRO的输入。FAT和TEST处于平行支路，前者保障交付合规性，后者保障质量可靠性。

1.2 混淆环境的典型事故与根因分析

环境混淆不是小概率事件，而是系统性风险。根据我参与的12个项目复盘，73%的重大线上故障源于环境治理失效。以下是三个最具代表性的事故：

事故1：PRO数据库被DEV脚本误删

• 现象：某券商交易系统凌晨3点出现大量“表不存在”错误，交易中断47分钟。
• 根因：DEV环境DB连接字符串硬编码在Spring Boot配置文件中，某开发为调试修改了spring.datasource.url指向PRO地址，提交时未删除该行。CI流水线打包时未校验配置文件，导致PRO部署包携带错误URL。
• 教训：所有环境配置必须外部化，禁止硬编码。我们后续强制要求：
  • DEV环境使用application-dev.yml，其中spring.datasource.url=jdbc:mysql://localhost:3306/dev_db
  • PRO环境使用application-pro.yml，其中spring.datasource.url=jdbc:mysql://prod-db-vip:3306/prod_db
  • 启动命令必须显式指定profile：java -jar app.jar --spring.profiles.active=pro

事故2：UAT通过但PRO上线失败

• 现象：保险核心系统UAT验收通过，PRO上线后保单查询接口超时率达95%。
• 根因：UAT环境数据库使用SSD云盘，PRO使用机械硬盘阵列，但SQL未做执行计划优化。UAT执行EXPLAIN显示type=ref，PRO执行EXPLAIN显示type=all（全表扫描）。
• 教训：UAT必须复现PRO存储性能。我们建立UAT存储基准测试规范：
  • 使用fio测试随机读IOPS：fio -name=randread -ioengine=libaio -rw=randread -bs=4k -direct=1 -runtime=60 -time_based -group_reporting
  • UAT IOPS必须≥PRO实测值的90%，否则拒绝UAT准入

事故3：PRE与PRO配置不一致导致灰度失败

• 现象：电商大促前灰度发布，PRE验证通过，PRO灰度节点全部502。
• 根因：PRE的Nginx配置中upstream server权重为100，PRO因历史原因配置为50（为兼容老版本服务）。灰度时新服务注册到PRO Consul，但Nginx未按预期路由。
• 教训：PRE与PRO配置必须Git版本化且强制比对。我们开发了配置一致性检查脚本：

  # 比对PRE与PRO的Nginx配置差异 diff <(ssh pre-server "cat /etc/nginx/conf.d/app.conf") \ <(ssh pro-server "cat /etc/nginx/conf.d/app.conf") | grep -E "^[<>]" # 输出差异行，自动触发告警

这些事故共同指向一个结论：环境治理不是运维部门的附加工作，而是研发效能的基础设施。当DEV、SIT、UAT、PRE、PRO的边界模糊时，CI/CD流水线就变成了风险放大器。

2. 环境标识体系：从命名混乱到机器可读的标签治理

2.1 命名规范的底层逻辑：解决“谁在什么环境干了什么”

国内团队最常见的环境命名乱象是“同名异义”和“同义异名”。比如“test”可能指TEST环境，也可能指某个开发者的个人测试机；“uat”可能指客户UAT环境，也可能指内部UAT模拟环境。这种混乱直接导致操作误判。命名规范必须满足三个原则：唯一性、可解析性、无歧义性。

我们采用四段式命名法：{业务域}-{环境类型}-{区域}-{序列号}，例如：

• core-pro-shanghai-01（核心系统生产环境上海集群主节点）
• payment-sit-beijing-02（支付系统集成测试环境北京集群备用节点）
• reporting-uat-shenzhen-01（报表系统用户验收环境深圳集群）

为什么是四段式？

• 第一段业务域：避免跨系统冲突。曾有个项目所有系统都叫app-test-01，运维执行批量重启时误杀其他系统。
• 第二段环境类型：严格限定为pro/sit/uat/test/pre/dev/fat七种，禁止添加staging、demo等非标类型。
• 第三段区域：标识物理位置或网络分区。shanghai指上海IDC，cloud-aliyun指阿里云华东1区，local-vmware指本地VMware Workstation Pro虚拟机。
• 第四段序列号：解决同类环境多实例问题。01为主，02为备，03为灾备，避免用master/slave等易引发歧义的词。

注意：序列号必须从01开始连续编号，禁止跳号（如01、03）。某次因跳号导致Ansible Playbook匹配*02时漏掉03节点，造成配置遗漏。

2.2 Kubernetes命名空间与VMware虚拟机的统一标签实践

现代混合架构下，环境同时存在于K8s集群和VMware Workstation Pro本地虚拟机中。必须建立跨平台的标签体系，让工具链能统一识别。

K8s命名空间标签：

apiVersion: v1 kind: Namespace metadata: name: core-pro-shanghai-01 labels: env-type: pro business-domain: core region: shanghai cluster-role: primary lifecycle: production

VMware虚拟机自定义属性（通过vSphere Web Client设置）：

这样，Ansible Inventory脚本就能动态生成统一清单：

# inventory.py import pyVmomi, kubernetes def get_all_hosts(): # 从vSphere获取所有VM，过滤env.type=pro且business.domain=core vsphere_hosts = [vm.name for vm in get_vms_by_tag("env.type==pro", "business.domain==core")] # 从K8s获取所有namespace，过滤label env-type=pro k8s_namespaces = [ns.metadata.name for ns in k8s_client.list_namespace().items if ns.metadata.labels.get('env-type') == 'pro'] return vsphere_hosts + k8s_namespaces

关键技巧：标签值必须小写且无特殊字符。曾因某VMware属性值设为env-type: PRO（大写），Ansible正则匹配失败，导致该节点从未被纳入配置管理。我们强制规定：所有标签值使用小写字母+数字+短横线，禁止下划线、点号、空格。

2.3 Git分支与配置仓库的环境映射规则

环境标识必须贯穿代码与配置全生命周期。我们采用Git Flow增强版分支策略：

• main分支：PRO环境唯一可信源。合并到main的PR必须包含PRO发布清单（含配置变更、SQL脚本、回滚方案）。
• release/*分支：PRE环境专用。例如release/v2.3.0对应PRE验证的版本，通过后合并至main。
• feature/*分支：DEV环境开发。每个feature分支关联一个独立的DEV环境（如feature-payment-refactor→payment-dev-local-01）。
• hotfix/*分支：PRO紧急修复。创建后自动触发PRO热更新流水线，同时向SIT推送补丁包验证。

配置仓库（Config Repo）采用环境目录隔离：

config-repo/ ├── pro/ │ ├── core/ │ │ ├── application.yml │ │ └── nginx.conf │ └── payment/ ├── sit/ │ ├── core/ │ └── payment/ ├── uat/ └── dev/ # 此目录仅存模板，不存具体值 └── template.yml # 开发者复制后修改本地值

为什么DEV不存具体配置？
因为DEV配置高度个性化（本地DB端口、IDE调试端口），存入Git会导致频繁冲突。我们要求开发者将dev/目录设为gitignore，通过.env文件管理本地变量，并在README.md中声明必需变量：

# .env.example DB_HOST=localhost DB_PORT=3306 REDIS_URL=redis://127.0.0.1:6379

3. 环境隔离实施：网络、数据、配置的三重防护

3.1 网络隔离：从VLAN到Service Mesh的演进

环境网络隔离不是简单划分VLAN，而是构建零信任网络微分区。我们分三层实施：

第一层：物理/虚拟网络隔离

• PRO、PRE、SIT、UAT必须部署在独立VLAN或VPC，禁止跨VLAN路由。
• DEV和TEST可共用VLAN，但必须通过ACL限制：DEV只能访问TEST的8080端口，禁止访问TEST的3306端口。
• FAT环境必须物理隔离：单独布线接入客户网络，与公司内网完全断开。某次FAT测试因未断开内网，客户防火墙日志误报“内部攻击”，引发严重信任危机。

第二层：主机级防火墙强化
所有Linux服务器启用iptables，规则模板如下：

# /etc/iptables/rules.v4 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # 允许本地回环 -A INPUT -i lo -j ACCEPT # 允许已建立连接 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # PRO环境：仅开放80/443/22端口，且22仅限堡垒机IP -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT -A INPUT -p tcp --dport 22 -s 10.10.10.100 -j ACCEPT # 堡垒机IP # SIT环境：开放所有端口给SIT子网 -A INPUT -s 10.20.0.0/16 -j ACCEPT COMMIT

第三层：Service Mesh细粒度控制（Istio示例）
在K8s集群中，通过Istio VirtualService实现环境间服务调用隔离：

# istio-sit.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: payment-sit spec: hosts: - "payment.sit.svc.cluster.local" gateways: - mesh http: - route: - destination: host: payment.sit.svc.cluster.local subset: v1 weight: 100 # 禁止PRO服务调用SIT服务 - match: - sourceLabels: env-type: pro - route: weight: 0

实操心得：网络隔离必须“默认拒绝，显式放行”。曾有个项目为图省事，在防火墙上开放10.0.0.0/8全网段访问，结果DEV环境的Redis被扫描出漏洞，黑客通过DEV渗透到PRO。

3.2 数据隔离：从脱敏到动态影子库的实战

数据是环境混乱的重灾区。DEV用PRO数据备份、UAT直接连PRO库、TEST数据长期不刷新——这些操作都在制造定时炸弹。

我们采用三级数据策略：

一级：DEV环境——合成数据+局部脱敏

• 使用Mockaroo生成符合业务规则的测试数据（如身份证号校验位正确、银行卡号Luhn算法通过）。
• 对敏感字段（手机号、身份证号）进行确定性脱敏：

  UPDATE user SET phone = CONCAT('138', SUBSTR(phone, 4, 8)) WHERE id < 1000;

  这样保证DEV数据量级与PRO一致，且脱敏后仍可联调短信网关（138开头号码有效）。

二级：TEST/UAT/SIT环境——动态影子库

• 不直接复制PRO数据，而是通过Debezium监听PRO MySQL binlog，实时同步到TEST/UAT/SIT的Kafka集群，再由Flink作业清洗后写入目标库。
• 关键清洗规则：
  • 手机号：替换为测试号段（170/171开头）
  • 身份证：出生日期改为1990年，顺序码随机
  • 金额：乘以0.01（千元变元，保持比例关系）
• 影子库同步延迟控制在30秒内，通过Prometheus监控debezium_lag_seconds指标。

三级：PRE/PRO环境——物理隔离+只读副本

• PRE数据库是PRO主库的物理副本（MySQL Group Replication），但设置read_only=ON，禁止任何写操作。
• PRO应用配置中，写库URL指向主库VIP，读库URL指向只读副本VIP，通过ShardingSphere分库分表中间件自动路由。

注意：数据同步必须双向校验。我们每天凌晨执行校验脚本：

# 比对PRO与PRE的用户表记录数 mysql -h pro-db -e "SELECT COUNT(*) FROM user;" | awk '{print $2}' > /tmp/pro_count mysql -h pre-db -e "SELECT COUNT(*) FROM user;" | awk '{print $2}' > /tmp/pre_count diff /tmp/pro_count /tmp/pre_count || echo "数据不一致！"

3.3 配置隔离：从Properties到GitOps的演进

配置混乱是环境问题的根源。同一个application.yml在DEV和PRO中仅靠profile切换，极易出错。

我们推行配置即代码（Configuration as Code），分三层管理：

第一层：基础配置（Infrastructure Config）

• Nginx、Tomcat、JVM参数等由Ansible Role统一管理。
• 每个环境对应独立Role：roles/nginx-pro、roles/nginx-uat，通过group_vars注入变量：

  # group_vars/pro.yml nginx_worker_processes: 8 jvm_xmx: "4g"

第二层：应用配置（Application Config）

• Spring Boot应用配置存入Git配置仓库，按环境目录隔离（见2.3节）。
• 使用Spring Cloud Config Server作为配置中心，PRO环境Config Server只读取pro/目录，禁止访问其他目录。

第三层：密钥配置（Secret Config）

• 数据库密码、API密钥等绝不出现在Git中。
• PRO环境使用HashiCorp Vault，通过K8s Service Account认证获取：

  # deployment.yaml env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: vault-secret key: db-password

• DEV环境使用本地Vault dev server，启动时自动生成测试密钥。

关键技巧：配置变更必须双签。任何影响PRO的配置修改，需开发负责人+运维负责人在Git PR中分别评论/approve，CI流水线检测到双签才允许合并。曾有个项目因单人批准配置变更，误将logging.level.root=DEBUG推到PRO，导致磁盘IO打满。

4. 环境交付流水线：从手动部署到GitOps闭环

4.1 CI/CD流水线的环境分段设计

标准CI/CD流水线必须按环境分段，每段有独立准入准出标准：

graph LR A[Code Commit] --> B[CI Build] B --> C[DEV Deploy] C --> D[TEST Automation] D --> E[SIT Deploy] E --> F[UAT Deploy] F --> G[PRE Smoke Test] G --> H[PRO Release]

各阶段关键控制点：

• DEV Deploy：自动触发，无审批。部署后发送Slack通知：“DEV环境已更新，版本v2.3.1-abc123”。
• TEST Automation：必须100%通过所有自动化测试用例（JUnit+Postman+Playwright），失败则阻断流水线。
• SIT Deploy：需SIT负责人在Jira中创建Release Ticket并关联PR，审批通过后手动触发。
• UAT Deploy：需客户UAT负责人邮件确认“同意部署至UAT环境”，邮件存档至SharePoint。
• PRE Smoke Test：部署后自动执行3个核心业务链路（如登录→下单→支付），任一失败则告警并暂停。
• PRO Release：需运维总监+CTO双签发布单，且PRO发布窗口期为每周三22:00-24:00（避开业务高峰）。

实操心得：UAT部署必须“一键回滚”。我们为每个UAT版本生成回滚包：

# 构建时生成回滚脚本 zip -r uat-v2.3.1-rollback.zip \ ./config/uat/ \ ./bin/app.jar \ ./scripts/rollback.sh

客户UAT发现问题时，运维5分钟内执行./rollback.sh即可恢复至上一版。

4.2 VMware Workstation Pro本地环境的标准化

很多开发习惯在VMware Workstation Pro中搭建DEV环境，但缺乏标准化导致“我的环境能跑，你的环境报错”。

我们制定VMware DEV环境黄金镜像：

• OS镜像：CentOS 7.9 Minimal，预装Docker 20.10、Java 11、Python 3.8。
• 网络配置：NAT模式，子网192.168.100.0/24，网关192.168.100.2，DNS指向公司内网DNS。
• 共享文件夹：/mnt/hgfs/workspace映射到宿主机代码目录，权限设为uid=1000,gid=1000（开发者UID）。
• 启动脚本：/etc/rc.d/rc.local中自动启动Docker服务并加载DEV环境容器：

  docker-compose -f /home/dev/app/docker-compose.dev.yml up -d

关键技巧：VMware Tools必须安装。某次因未安装Tools，宿主机剪贴板无法同步到虚拟机，开发无法复制错误日志，排查耗时2小时。我们要求镜像制作时执行：

# 在CentOS中安装VMware Tools mount /dev/cdrom /mnt tar -xzf /mnt/VMwareTools-*.tar.gz -C /tmp /tmp/vmware-tools-distrib/vmware-install.pl --default

4.3 环境健康度看板与自动巡检

环境治理不能依赖人工检查。我们构建环境健康度看板，包含6个核心指标：

看板每日凌晨自动生成PDF报告，邮件发送至环境治理委员会（开发组长、测试经理、运维总监）。某次报告发现UAT环境CPU利用率连续3天达92%，排查发现是测试人员未关闭压力测试工具，及时止损。

注意：健康度看板必须“可操作”。每个指标旁标注“如何修复”，例如“配置一致性<99.5%”旁链接到Ansible Playbook修复脚本。

5. 常见问题与排查技巧实录

5.1 “环境明明一样，为什么PRO报错而PRE不报？”

这是最高频问题。表面看PRO和PRE配置、代码、数据都一致，但深层差异往往藏在三个地方：

第一：时钟偏差
PRO服务器NTP同步到GPS时钟，PRE同步到内网NTP服务器，偏差达200ms。某次JWT token校验失败，因PRO服务器时间比PRE快180ms，token未生效。
排查：

# 检查时钟偏差 ntpq -p # 查看offset值 chronyc tracking # Chrony用户 # 修复：强制同步 sudo ntpdate -s time.windows.com

第二：内核参数差异
PRO服务器net.ipv4.tcp_tw_reuse=1，PRE为0。高并发场景下PRO能快速复用TIME_WAIT端口，PRE则因端口耗尽连接失败。
排查：

# 比对内核参数 sysctl -a | grep tw_reuse # 修复：统一写入/etc/sysctl.conf echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf sysctl -p

第三：SSL证书链差异
PRO使用Let's Encrypt完整证书链，PRE使用自签名证书。某次调用HTTPS API失败，因PRE的Java TrustStore未导入根证书。
排查：

# 检查证书链 openssl s_client -connect api.example.com:443 -showcerts # 修复：将根证书导入Java keystore keytool -import -trustcacerts -file root.crt -keystore $JAVA_HOME/jre/lib/security/cacerts

5.2 “UAT客户说没问题，PRO上线就崩溃，怎么快速定位？”

UAT与PRO的差异点优先级排序：

1. 终端设备差异：UAT用Chrome 115，PRO客户用IE11。用BrowserStack远程真机测试。
2. 网络质量差异：UAT网络延迟<10ms，PRO客户网络延迟>100ms。用tc命令在PRO节点注入延迟：

   tc qdisc add dev eth0 root netem delay 100ms 10ms distribution normal

3. 数据量级差异：UAT数据1万条，PRO数据1000万条。在PRO执行慢SQL分析：

   SHOW PROCESSLIST; -- 找出长时间运行SQL EXPLAIN FORMAT=JSON SELECT ...; -- 分析执行计划

5.3 “DEV环境启动报错‘Connection refused’，但DB明明在运行”

90%的DEV连接问题源于端口冲突。VMware Workstation Pro默认使用192.168.100.0/24网段，但宿主机Docker Desktop也占用该网段，导致虚拟机无法访问宿主机DB。
解决方案：

• 修改VMware NAT设置：编辑C:\ProgramData\VMware\VMware Workstation\networks.xml，将<nat>段的<ip>改为192.168.200.1
• 重启VMware Network Services
• 在虚拟机中修改/etc/hosts，将DB服务域名指向192.168.200.1

5.4 “PRE环境压测通过，PRO上线后CPU飙升，怎么排查？”

PRO与PRE的CPU差异通常来自两个隐藏因素：

• 监控探针开销：PRO部署了Zabbix Agent + Prometheus Exporter + APM探针，PRE只部署Zabbix。关闭APM探针后CPU下降40%。
• 日志级别差异：PRO的logback.xml中<root level="INFO">，PRE为<root level="WARN">。INFO日志写入磁盘IO占CPU 35%。
  快速验证：

# 查看CPU消耗进程 top -p $(pgrep -f "java.*app.jar") -H # 查看线程栈 jstack $(pgrep -f "java.*app.jar") | grep RUNNABLE -A 10

5.5 “如何说服客户接受FAT与UAT分离？”

客户常认为“FAT和UAT都是验收，何必分开”。说服要点：

• 法律效力不同：FAT依据合同技术附件，UAT依据业务需求说明书，二者签字主体不同（FAT签章为法人，UAT签章为业务部门）。
• 测试目标不同：FAT验证“能不能用”，UAT验证“好不好用”。举例子：FAT测试POS机打印速度≥50张/分钟，UAT测试店员操作界面是否符合习惯。
• 成本结构不同：FAT需第三方监理全程见证（费用由集成商承担），UAT由客户内部人员执行（无额外成本）。

我们提供《FAT/UAT分离价值清单》给客户，列明分离后可减少的返工成本（如FAT发现硬件兼容问题，避免UAT阶段才发现导致整机更换）。

我在实际交付中发现，环境治理最难的不是技术实现，而是建立团队共识。曾有个项目组坚持“DEV和TEST共用一个DB”，理由是“省事”。我带他们做了个实验：在TEST执行一条DELETE语句，观察DEV接口响应——结果所有DEV开发者电脑弹出500错误。那一刻，所有人默默打开了Ansible文档。环境整理不是增加负担，而是把每天浪费在“这个环境到底是什么状态”的时间，还给真正创造价值的工作。最后分享一个小技巧：每月第一个周五下午，组织“环境清洁日”，全员参与检查环境标识、清理僵尸容器、校验配置一致性。这不是仪式，而是让环境治理成为肌肉记忆。