系统运维知识综述
综述概述:系统运维是保障零售业务系统稳定运行的支撑层,覆盖环境认知(服务器/数据库拓扑)、运行机制(日结/参数变更)、故障处置(报错自愈/白名单)三方面。本文聚合 7 张概念卡,是运维人员处理系统级问题的入口。
体系框架
系统运维
├── 环境认知
│ ├── 系统环境信息速查(服务器/数据库/Web 入口)
│ └── 核心数据表速查(表结构认知)
├── 运行机制
│ ├── 系统日结机制(22点/凌晨2点/错误日志)
│ └── 系统参数配置变更单(单据驱动+审批)
└── 故障处置
├── 功能报错自愈与应用程序池回收(自愈→回收)
├── 储值卡报表查询白名单报错(连接白名单)
└── WorkBuddy更换电脑迁移指南(环境迁移)
脉络一:环境认知是运维起点
运维任何问题先定位环境:查系统环境信息速查确认该业务跑在哪台服务器、哪个数据库(如储值卡=192.168.11.8/enjoy_card),再结合核心数据表速查定位数据表。环境错了排查方向就错了——白名单问题本质就是环境间的网络信任配置。
脉络二:运行机制决定操作窗口
系统日结(22 点后)和参数变更(日结生效/随时生效)构成系统的「操作节律」:日结期间停止业务操作;参数修改用单据驱动(可追溯+审批);日结报错查 tb_log_err。理解机制才能判断「什么能改、什么时候改、怎么生效」。
脉络三:故障处置的三级策略
系统级故障处置遵循「先自愈、再回收、后重建」的层级:
- 功能报错先等待自愈(应用池自动恢复)
- 不行回收 WS/client 应用程序池
- 环境损坏才考虑迁移重建
不要一报错就重启服务器。
实践要点
- 环境定位先行:报错先查系统环境信息速查 → 确认服务器/数据库归属
- 日结排错:查 tb_sum_status(执行情况)+ tb_log_err(子过程错误)
- 参数修改:用系统参数配置变更单(可追溯/审批/指定生效),日结生效必须大于当天
- 报错处置:等自愈(分钟级)→ 回收应用程序池(WS+client)→ 再考虑重建
- 白名单问题:确认目标服务器 IP 是否在数据库白名单(储值卡 192.168.11.8)
- 环境迁移:备份整个配置文件夹(config/skills/integrations/automations/memory)
概念卡索引
| 概念 | 角色 |
|---|---|
| 系统环境信息速查 | 服务器/数据库/Web 入口(前置) |
| 核心数据表速查 | 高频核心表分类 |
| 系统日结机制 | 22点后/凌晨2点归属/错误日志 |
| 系统参数配置变更单 | 单据驱动+审批 |
| 功能报错自愈与应用程序池回收 | 自愈→回收处置 |
| 储值卡报表查询白名单报错 | 连接白名单 |
| WorkBuddy更换电脑迁移指南 | 环境迁移 |