ERP/WMS 业务系统运维与库存差异排查项目

这篇项目复盘围绕“围绕 ERP/WMS 岗位要求整理的业务系统运维项目，重点体现商品、订单、入库出库、退货、盘点、库存差异核对和故障排查能力。”展开，目标不是把项目写成单纯的功能清单，而是把业务场景、系统维护、数据核对、流程实施和问题闭环放在一起说明。面向运维工程师岗位，项目重点对应 ERP、WMS、BI、低代码平台、数据库和企业业务沟通等要求。

关键词：ERP、WMS、库存差异、订单流转、MySQL、系统运维、故障排查。

项目背景

项目模拟企业商品流通和仓储作业场景，覆盖商品资料维护、采购入库、销售出库、订单状态流转、退货回补、库存盘点、异常单据处理和后台权限管理。系统运行中最常见的问题不是单个页面打不开，而是业务人员反馈“库存不对”“订单状态卡住”“退货后数量没有回补”“同一个商品不同报表数量不一致”。这些问题需要结合 WMS 作业流程、ERP 单据状态和数据库记录进行定位。

在这个项目中，我把工作拆成几个层面：第一是系统能稳定运行，第二是业务人员能按流程使用，第三是数据出现异常时能够追溯，第四是后续可以形成操作手册、问题记录和复盘文档。岗位要求里提到的系统日常维护、监控、故障排除、数据集成、流程优化、低代码开发、项目管理和文档汇报，都可以在这个项目里对应到具体动作。

业务流程梳理（第 1 轮复盘）

项目开始时先把商品、仓库、库位、订单、入库单、出库单、退货单、盘点单和库存流水拆成独立对象，再梳理它们之间的状态变化。商品资料是基础数据，订单是业务入口，库存流水是追溯依据，盘点单和调整单是修正手段。只有先把这些关系说清楚，后续排查库存差异时才不会只盯着一个数字。

围绕岗位中提到的 ERP、WMS 架构和原理，我把业务过程拆成“单据创建、审核确认、库存占用、实际出库、签收完成、异常退回、库存回补”几个节点。每个节点都对应数据库字段和操作日志，例如订单状态、支付状态、发货状态、库存扣减标记、退货状态、更新时间和操作人。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

日常维护与监控（第 1 轮复盘）

日常维护不只是看服务是否启动，还要看业务是否能完整走通。我会每天检查服务进程、Nginx 访问状态、接口错误日志、数据库慢查询、磁盘空间和关键表增长情况，并抽查订单、库存和退货流程是否有异常状态堆积。

对业务系统来说，监控指标要贴近业务。除了 CPU、内存和端口，还要关注待审核订单数量、待出库数量、库存预警数量、失败接口次数、重复提交记录和异常单据比例。这些指标能帮助运维人员提前发现问题，而不是等业务部门集中反馈。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

库存差异排查（第 1 轮复盘）

库存差异通常从三个方向排查：第一是订单是否重复扣减或没有扣减，第二是退货、取消、盘点调整是否正确回补，第三是报表口径是否把占用库存、可用库存、实际库存混在一起。排查时先确认业务口径，再写 SQL 对库存表和流水表做联表核对。

典型处理步骤是先记录问题现象，例如某商品后台显示可用库存为 8，但仓库实际盘点为 10；然后查询商品基础表、库存表、库存流水、订单明细和退货记录；接着按时间线复盘每一次入库、出库、取消和调整；最后给出原因、修复 SQL、影响范围和预防措施。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

数据修复与风险控制（第 1 轮复盘）

涉及库存和订单的数据修复必须谨慎，不能直接改一个数字就结束。我的做法是先备份相关记录，再用 SELECT 语句确认影响范围，必要时在测试库复现，最后再通过事务执行修复。修复后还要补充备注、记录工单，并通知业务人员复核。

对于高风险字段，例如库存数量、订单金额、发货状态、退款状态，我会建立修复前后对比表，保留商品编号、订单编号、旧值、新值、操作原因和操作时间。这样既方便项目复盘，也符合企业系统对数据可追溯的要求。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

业务流程梳理（第 2 轮复盘）

项目开始时先把商品、仓库、库位、订单、入库单、出库单、退货单、盘点单和库存流水拆成独立对象，再梳理它们之间的状态变化。商品资料是基础数据，订单是业务入口，库存流水是追溯依据，盘点单和调整单是修正手段。只有先把这些关系说清楚，后续排查库存差异时才不会只盯着一个数字。

围绕岗位中提到的 ERP、WMS 架构和原理，我把业务过程拆成“单据创建、审核确认、库存占用、实际出库、签收完成、异常退回、库存回补”几个节点。每个节点都对应数据库字段和操作日志，例如订单状态、支付状态、发货状态、库存扣减标记、退货状态、更新时间和操作人。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

日常维护与监控（第 2 轮复盘）

日常维护不只是看服务是否启动，还要看业务是否能完整走通。我会每天检查服务进程、Nginx 访问状态、接口错误日志、数据库慢查询、磁盘空间和关键表增长情况，并抽查订单、库存和退货流程是否有异常状态堆积。

对业务系统来说，监控指标要贴近业务。除了 CPU、内存和端口，还要关注待审核订单数量、待出库数量、库存预警数量、失败接口次数、重复提交记录和异常单据比例。这些指标能帮助运维人员提前发现问题，而不是等业务部门集中反馈。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

库存差异排查（第 2 轮复盘）

库存差异通常从三个方向排查：第一是订单是否重复扣减或没有扣减，第二是退货、取消、盘点调整是否正确回补，第三是报表口径是否把占用库存、可用库存、实际库存混在一起。排查时先确认业务口径，再写 SQL 对库存表和流水表做联表核对。

典型处理步骤是先记录问题现象，例如某商品后台显示可用库存为 8，但仓库实际盘点为 10；然后查询商品基础表、库存表、库存流水、订单明细和退货记录；接着按时间线复盘每一次入库、出库、取消和调整；最后给出原因、修复 SQL、影响范围和预防措施。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

数据修复与风险控制（第 2 轮复盘）

涉及库存和订单的数据修复必须谨慎，不能直接改一个数字就结束。我的做法是先备份相关记录，再用 SELECT 语句确认影响范围，必要时在测试库复现，最后再通过事务执行修复。修复后还要补充备注、记录工单，并通知业务人员复核。

对于高风险字段，例如库存数量、订单金额、发货状态、退款状态，我会建立修复前后对比表，保留商品编号、订单编号、旧值、新值、操作原因和操作时间。这样既方便项目复盘，也符合企业系统对数据可追溯的要求。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

业务流程梳理（第 3 轮复盘）

项目开始时先把商品、仓库、库位、订单、入库单、出库单、退货单、盘点单和库存流水拆成独立对象，再梳理它们之间的状态变化。商品资料是基础数据，订单是业务入口，库存流水是追溯依据，盘点单和调整单是修正手段。只有先把这些关系说清楚，后续排查库存差异时才不会只盯着一个数字。

围绕岗位中提到的 ERP、WMS 架构和原理，我把业务过程拆成“单据创建、审核确认、库存占用、实际出库、签收完成、异常退回、库存回补”几个节点。每个节点都对应数据库字段和操作日志，例如订单状态、支付状态、发货状态、库存扣减标记、退货状态、更新时间和操作人。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

日常维护与监控（第 3 轮复盘）

日常维护不只是看服务是否启动，还要看业务是否能完整走通。我会每天检查服务进程、Nginx 访问状态、接口错误日志、数据库慢查询、磁盘空间和关键表增长情况，并抽查订单、库存和退货流程是否有异常状态堆积。

对业务系统来说，监控指标要贴近业务。除了 CPU、内存和端口，还要关注待审核订单数量、待出库数量、库存预警数量、失败接口次数、重复提交记录和异常单据比例。这些指标能帮助运维人员提前发现问题，而不是等业务部门集中反馈。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

库存差异排查（第 3 轮复盘）

库存差异通常从三个方向排查：第一是订单是否重复扣减或没有扣减，第二是退货、取消、盘点调整是否正确回补，第三是报表口径是否把占用库存、可用库存、实际库存混在一起。排查时先确认业务口径，再写 SQL 对库存表和流水表做联表核对。

典型处理步骤是先记录问题现象，例如某商品后台显示可用库存为 8，但仓库实际盘点为 10；然后查询商品基础表、库存表、库存流水、订单明细和退货记录；接着按时间线复盘每一次入库、出库、取消和调整；最后给出原因、修复 SQL、影响范围和预防措施。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

数据修复与风险控制（第 3 轮复盘）

涉及库存和订单的数据修复必须谨慎，不能直接改一个数字就结束。我的做法是先备份相关记录，再用 SELECT 语句确认影响范围，必要时在测试库复现，最后再通过事务执行修复。修复后还要补充备注、记录工单，并通知业务人员复核。

对于高风险字段，例如库存数量、订单金额、发货状态、退款状态，我会建立修复前后对比表，保留商品编号、订单编号、旧值、新值、操作原因和操作时间。这样既方便项目复盘，也符合企业系统对数据可追溯的要求。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

业务流程梳理（第 4 轮复盘）

项目开始时先把商品、仓库、库位、订单、入库单、出库单、退货单、盘点单和库存流水拆成独立对象，再梳理它们之间的状态变化。商品资料是基础数据，订单是业务入口，库存流水是追溯依据，盘点单和调整单是修正手段。只有先把这些关系说清楚，后续排查库存差异时才不会只盯着一个数字。

围绕岗位中提到的 ERP、WMS 架构和原理，我把业务过程拆成“单据创建、审核确认、库存占用、实际出库、签收完成、异常退回、库存回补”几个节点。每个节点都对应数据库字段和操作日志，例如订单状态、支付状态、发货状态、库存扣减标记、退货状态、更新时间和操作人。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

日常维护与监控（第 4 轮复盘）

日常维护不只是看服务是否启动，还要看业务是否能完整走通。我会每天检查服务进程、Nginx 访问状态、接口错误日志、数据库慢查询、磁盘空间和关键表增长情况，并抽查订单、库存和退货流程是否有异常状态堆积。

对业务系统来说，监控指标要贴近业务。除了 CPU、内存和端口，还要关注待审核订单数量、待出库数量、库存预警数量、失败接口次数、重复提交记录和异常单据比例。这些指标能帮助运维人员提前发现问题，而不是等业务部门集中反馈。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

库存差异排查（第 4 轮复盘）

库存差异通常从三个方向排查：第一是订单是否重复扣减或没有扣减，第二是退货、取消、盘点调整是否正确回补，第三是报表口径是否把占用库存、可用库存、实际库存混在一起。排查时先确认业务口径，再写 SQL 对库存表和流水表做联表核对。

典型处理步骤是先记录问题现象，例如某商品后台显示可用库存为 8，但仓库实际盘点为 10；然后查询商品基础表、库存表、库存流水、订单明细和退货记录；接着按时间线复盘每一次入库、出库、取消和调整；最后给出原因、修复 SQL、影响范围和预防措施。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

数据修复与风险控制（第 4 轮复盘）

涉及库存和订单的数据修复必须谨慎，不能直接改一个数字就结束。我的做法是先备份相关记录，再用 SELECT 语句确认影响范围，必要时在测试库复现，最后再通过事务执行修复。修复后还要补充备注、记录工单，并通知业务人员复核。

对于高风险字段，例如库存数量、订单金额、发货状态、退款状态，我会建立修复前后对比表，保留商品编号、订单编号、旧值、新值、操作原因和操作时间。这样既方便项目复盘，也符合企业系统对数据可追溯的要求。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

业务流程梳理（第 5 轮复盘）

项目开始时先把商品、仓库、库位、订单、入库单、出库单、退货单、盘点单和库存流水拆成独立对象，再梳理它们之间的状态变化。商品资料是基础数据，订单是业务入口，库存流水是追溯依据，盘点单和调整单是修正手段。只有先把这些关系说清楚，后续排查库存差异时才不会只盯着一个数字。

围绕岗位中提到的 ERP、WMS 架构和原理，我把业务过程拆成“单据创建、审核确认、库存占用、实际出库、签收完成、异常退回、库存回补”几个节点。每个节点都对应数据库字段和操作日志，例如订单状态、支付状态、发货状态、库存扣减标记、退货状态、更新时间和操作人。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

日常维护与监控（第 5 轮复盘）

日常维护不只是看服务是否启动，还要看业务是否能完整走通。我会每天检查服务进程、Nginx 访问状态、接口错误日志、数据库慢查询、磁盘空间和关键表增长情况，并抽查订单、库存和退货流程是否有异常状态堆积。

对业务系统来说，监控指标要贴近业务。除了 CPU、内存和端口，还要关注待审核订单数量、待出库数量、库存预警数量、失败接口次数、重复提交记录和异常单据比例。这些指标能帮助运维人员提前发现问题，而不是等业务部门集中反馈。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

库存差异排查（第 5 轮复盘）

库存差异通常从三个方向排查：第一是订单是否重复扣减或没有扣减，第二是退货、取消、盘点调整是否正确回补，第三是报表口径是否把占用库存、可用库存、实际库存混在一起。排查时先确认业务口径，再写 SQL 对库存表和流水表做联表核对。

典型处理步骤是先记录问题现象，例如某商品后台显示可用库存为 8，但仓库实际盘点为 10；然后查询商品基础表、库存表、库存流水、订单明细和退货记录；接着按时间线复盘每一次入库、出库、取消和调整；最后给出原因、修复 SQL、影响范围和预防措施。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

数据修复与风险控制（第 5 轮复盘）

涉及库存和订单的数据修复必须谨慎，不能直接改一个数字就结束。我的做法是先备份相关记录，再用 SELECT 语句确认影响范围，必要时在测试库复现，最后再通过事务执行修复。修复后还要补充备注、记录工单，并通知业务人员复核。

对于高风险字段，例如库存数量、订单金额、发货状态、退款状态，我会建立修复前后对比表，保留商品编号、订单编号、旧值、新值、操作原因和操作时间。这样既方便项目复盘，也符合企业系统对数据可追溯的要求。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

业务流程梳理（第 6 轮复盘）

项目开始时先把商品、仓库、库位、订单、入库单、出库单、退货单、盘点单和库存流水拆成独立对象，再梳理它们之间的状态变化。商品资料是基础数据，订单是业务入口，库存流水是追溯依据，盘点单和调整单是修正手段。只有先把这些关系说清楚，后续排查库存差异时才不会只盯着一个数字。

围绕岗位中提到的 ERP、WMS 架构和原理，我把业务过程拆成“单据创建、审核确认、库存占用、实际出库、签收完成、异常退回、库存回补”几个节点。每个节点都对应数据库字段和操作日志，例如订单状态、支付状态、发货状态、库存扣减标记、退货状态、更新时间和操作人。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

日常维护与监控（第 6 轮复盘）

日常维护不只是看服务是否启动，还要看业务是否能完整走通。我会每天检查服务进程、Nginx 访问状态、接口错误日志、数据库慢查询、磁盘空间和关键表增长情况，并抽查订单、库存和退货流程是否有异常状态堆积。

对业务系统来说，监控指标要贴近业务。除了 CPU、内存和端口，还要关注待审核订单数量、待出库数量、库存预警数量、失败接口次数、重复提交记录和异常单据比例。这些指标能帮助运维人员提前发现问题，而不是等业务部门集中反馈。

从运维视角看，这一部分的价值不只是“做过功能”，而是能够把功能运行状态、业务口径、数据库记录、用户操作路径和交付文档串起来。企业系统里很多问题并不是代码报错那么简单，更多时候是业务流程、权限配置、数据状态、接口参数和人员操作共同造成的结果，所以排查时需要先问清楚场景，再看日志和数据。

如果把它放到面试表达里，我会强调三点：一是我能理解商品、订单、库存、客户、审批、报表这些业务对象之间的关系；二是我能用 SQL、日志、配置和流程复盘定位问题；三是我能把处理过程写成文档，让后续同类问题有标准做法。

项目总结

这个项目最适合用来证明我不是只会部署服务或写简单脚本，而是能够站在业务系统运维和实施交付的角度工作。面对 ERP、WMS、BI、低代码平台这类企业系统，我会先理解业务流程，再确认数据结构和权限边界，最后通过日志、SQL、接口和用户反馈完成闭环。这样的经验可以迁移到用友、金蝶、帆软 BI、简道云以及企业内部业务系统的日常维护和项目实施中。