用Spring Boot搭建校园网络运维工单与设备监控系统

我们学校原来那个网络报修的流程，说出来同行都得摇头——学生宿舍断网了，先打电话给信息中心，信息中心登记完再转给对应的运维师傅，师傅修完了再回来填个Excel表。遇到设备离线、交换机端口异常这些问题，基本靠巡检时肉眼发现，等用户投诉了才知道哪里有问题。去年我决定把这个流程彻底改造一遍，用Spring Boot从零搭了一套学校网络运维系统，跑了大半年，现在不管是日常的故障报修、设备巡检，还是领导要的网络运行报告，全都在系统里走，总算把运维工作从“救火模式”拽回到了正经轨道上。

这篇博文就把整个项目的来龙去脉掰开揉碎讲清楚，从需求分析、技术选型到模块拆分、代码实现，最后再到上线后遇到的坑，适合两类人看：一类是学校信息中心或者做驻场运维的兄弟，想自己搞一套顺手的管理工具；另一类是正在做Spring Boot毕设或者练手项目的学生，这个场景比随便做个增删改查有意思得多，涉及的知识点也够扎实。

1. 学校网络运维的真实痛点与系统定位

1.1 校园网络运维到底难在哪

先说清楚校医院，校园网和电信运营商网络最大的区别在于——服务对象复杂、设备种类杂、故障响应要求高。学生宿舍、教学楼、行政楼、图书馆、食堂，几十栋楼，几百台交换机，上千个AP，再加上认证网关、DHCP服务器、DNS服务器这些基础设施，任何一个环节出问题，影响的都是几百上千人的正常用网。

过去我们沿用一套老方法：填表格、打电话、贴公告。这套方法最大的问题是信息断层——报修渠道混乱，用户不知道找谁；运维师傅干没干活，管理员不知道；修完之后有没有复现，没人跟进。设备侧更头疼，核心交换机CPU飙高了、某台POE交换机跳电了，往往要等到用户大规模反馈才能发现，主动性一点没有。

当时也想过去采购商业网管平台，一看报价直接劝退，大几十万的费用，而且很多商业产品的模块是面向企业场景设计的，放在学校反而不适配——我们不需要那么复杂的SLA计费，但需要跟学生花名册、教职工名单对接，需要支持学生宿舍这种强分区的报修逻辑，这些需求商业产品做起来又重又别扭。

1.2 为什么最终定位成“运维工单 + 设备监控”双核系统

跟信息中心的同事开了三次需求会，反复聊下来，最终把系统的核心定位收敛成两个词：工单流转和状态可视化。

工单流转解决的是“人”的问题，学生报修、师傅接单、处理反馈、用户确认，全流程线上化，不再靠微信群里爬楼找聊天记录。状态可视化解决的是“设备”的问题，交换机、AP、服务器的在线状态、流量情况、告警记录集中展示，运维师傅上班先看面板，哪里红了点哪里。

这个定位对开发工作量非常友好，Spring Boot做一套RESTful API后端，配合一个前端管理面板，核心代码量其实不大，但每一块都是实际工作中高频使用的功能。我见过不少同类项目喜欢堆技术，什么微服务、容器编排、消息队列全塞进去，最后发现一个规模几十人的学校信息中心根本用不上这些，运维系统最怕的不是功能少，而是复杂到没人愿意用。

2. 技术选型：为什么是Spring Boot而不是其他框架

2.1 Spring Boot在这个场景里的三个关键优势

做这个项目之前，我特意对比了Spring Boot、Django和Node.js三种技术栈。Django的admin后台确实好用，Python写脚本方便，但信息中心后续想让计算机专业的学生参与开发，Java的生态他们更熟；Node.js胜在轻量，但Spring Boot的家族体系对传统IT团队更友好。反复权衡之后，选Spring Boot的原因归结为三点：

第一，自带的生产级特性。内嵌Tomcat，一键启动，不需要单独装Web容器；Spring Data JPA或者MyBatis对接MySQL，省去大量JDBC模板代码；Spring Security做登录认证和权限控制，配合JWT实现无状态会话，很契合运维系统这种后台工具的使用方式。

第二，部署运维贴合学校环境。学校信息中心通常不是专门的DevOps团队，能简单就别复杂，Spring Boot打一个可执行JAR包扔到服务器上就能跑，Swagger自动生成API文档，后续交接给学生维护也好上手。我见过有兄弟用微服务架构搞校园系统，一台服务器上跑了五六个服务，出了问题自己都分不清先查哪个，完全没必要。

第三，社区资源和招人友好度。学校网管队伍里会Java的人一抓一大把，真要出问题，随便找个计算机学院的老师或者大四学生都能帮忙看代码。技术栈越主流，系统的长期可维护性就越高。反过来说，如果选个小众框架，一旦自己调走了，后续接手的人可能完全摸不着头脑。

2.2 核心依赖与版本选择的经验之谈

这个项目我用的JDK 17搭配Spring Boot 3.x。有同学可能还在纠结JDK 8和Spring Boot 2.x，实话实说，新项目直接上3.x没问题，Spring Boot 3基于Jakarta EE规范，整体更干净，而且Spring Security 6的配置方式虽然变化不小，但网上资料已经非常丰富，踩坑成本完全可控。

除了基础依赖，我额外引入的工具包括：

版本配套上有一个坑提前说，Spring Boot 3.x必须配合Java 17及以上，别惯性思维用Java 8，不然启动直接报ClassNotFoundException。另外如果用MyBatis-Plus，注意检查版本是否适配当前Spring Boot版本，3.5.3之后的版本才稳定兼容Spring Boot 3。

2.3 为什么不做前后端分离的过度设计

现在很多教程都在鼓吹前后端分离、Vue/React+Spring Boot微服务什么的，但放到学校自用系统这个场景，过度设计就是最大的风险。我最终用的是Thymeleaf服务端渲染加少量原生JS的方式，后端用Spring MVC直接返回视图，配合简单的fetch调用接口。

为什么这么做？因为在校园内网环境下，用户量级撑死几千人，服务端渲染的并发表现完全够用，而且部署时只需管一个应用，不用同时维护Nginx静态资源服务和后端API服务两个节点。前端渲染解决了“用户不登录就不能访问”、“页面需要按角色显示不同菜单”这类状态问题，而这正是服务端渲染最擅长的。

3. 核心模块设计与实现解析

3.1 用户与权限模块：三套角色的边界划分

系统面向三类角色：学生/教职工（报修人）、运维师傅（处理人）、管理员（监管人）。三个角色的权限边界必须清晰，否则后面工单流转会乱套。

我的设计是：用户表、角色表、用户角色关联表，加上Spring Security的注解式权限控制。关键接口上的做法是：

@PreAuthorize("hasRole('ADMIN')") @GetMapping("/api/devices") public Result listDevices() { return Result.success(deviceService.listAll()); } @PreAuthorize("hasAnyRole('ADMIN','OPERATOR')") @PostMapping("/api/tickets/{id}/handle") public Result handleTicket(@PathVariable Long id, @RequestBody HandleRequest req) { return Result.success(ticketService.handle(id, req)); }

这里有个细节值得展开说：学生账号不走单独注册，而是对接学校统一身份认证系统，用学号作为唯一标识，工号和学号天然具备唯一性，不需要像互联网应用那样搞邮箱验证那一套。用户登录后，后端根据账号前缀或者部门字段自动判断角色，省去管理员手动分配账号的体力活。

3.2 工单管理模块：让故障报修形成闭环

工单是系统的核心业务对象，所有其他功能都围绕它展开。我设计的工单流程是：用户提交报修 → 管理员分配 → 运维师傅接单 → 线上处理反馈 → 用户确认完成，整个过程记录操作日志，每一步都有时间戳和操作人信息。

状态机是工单模块的骨架：

public enum TicketStatus { PENDING, // 待分配 ASSIGNED, // 已分配待处理 PROCESSING, // 处理中 RESOLVED, // 已解决待确认 CLOSED, // 已关闭 REJECTED // 已驳回 }

每个状态之间的流转规则写在Service层里做校验，比如只有管理员能把PENDING状态的工单改成ASSIGNED，运维师傅只能把ASSIGNED改成PROCESSING，用户确认之后才能走到CLOSED。这样设计的好处是，不管谁误操作，状态都不会跳出合法路径，数据一致性有保障。

表结构设计时我把工单扩展字段放在一张子表里，比如报修类型（网络断开、网速慢、无线连不上、设备故障），报修楼栋、宿舍号/办公室号、描述文本、图片附件路径。为什么要单独建子表？因为不同工单类型的附加信息差异很大，全部塞主表会导致大量稀疏字段，查询列表时反而不方便。

3.3 设备监控模块：心跳机制与阈值告警

设备监控用最朴素的心跳上报方案实现。网络设备支持SNMP协议的，我写了一个定时任务通过SNMP抓取CPU、内存、端口流量；不支持的设备（比如某些老的傻瓜交换机），就用定时Ping加Telnet探测的方式判断在线状态。

心跳超时的判定逻辑在Redis里做。每台设备在Redis中维护一个心跳KEY，设备端（或采集脚本）每隔30秒写入当前时间戳，后台定时任务扫描所有KEY，超过90秒没更新的就标记为离线。这么设计的好处是，即使采集脚本临时挂掉，Redis里的数据作为中间层还是能保留现场，方便排查是设备问题还是采集程序问题。

告警阈值这块我踩过几次坑。刚开始把阈值设得太敏感，CPU超过50%就告警，结果每天收几十条无用消息，运维师傅直接把通知屏蔽了。后面改成两级阈值策略:超过80%发告警，超过95%发紧急告警，同时对同一设备同一指标做了告警去重，同一问题12小时内不重复提醒，这才让告警回到了有用的状态。

3.4 数据统计与报表模块：让运维看得见价值

运维工作干了多少，不能光靠嘴说，要拿数据说话。报表模块我实现的功能有三个：工单处理时效统计（平均响应时间、平均处理时长、按时完成率）、设备在线率统计、故障类型分布统计。这些数据通过定时任务每天凌晨汇总到统计表里，而不是每次现算，因为学校高峰期那个时间段的数据库查询性能不太稳定，定时汇总的方案更稳妥。

一开始觉得统计报表没什么技术含量，无非是几个COUNT和GROUP BY。真正做起来才发现，最麻烦的是数据口径的统一。比如“平均处理时长”，是从工单分配时间算到师傅接单时间，还是从接单算到完成？不同口径差很多。最终我跟信息中心商量统一了一套定义：响应时长=接单时间-提交时间，处理时长=完成时间-接单时间，关闭时长=确认时间-完成时间。定义清晰之后，所有报表才能横向对比，不然统计出来的数字自己都解释不清楚。

4. 从零到一：系统搭建与关键代码实现

4.1 项目初始化和数据库设计

项目我用Spring Initializr快速初始化，选中的依赖包括Spring Web、Spring Data JPA（实际用MyBatis-Plus就换掉）、MySQL Driver、Spring Security、Validation、Thymeleaf、Lombok。初始化完成后，第一步先把日志配置改好，开发环境和生产环境用不同的日志级别和输出目录，这一点很多初学者会忽略，等上线排障时才发现日志配置得太粗糙。

数据库我建了9张表：用户表、角色表、用户角色关联表、工单表、工单操作日志表、设备表、设备告警记录表、公告表、统计报表日汇总表。用Navicat建表时有个经验，所有表的创建时间和更新时间都加上，用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护，排查问题的时候时间线一目了然，这个成本非常低但收益很大。

4.2 工单流转的Service层实现

工单流转的核心逻辑集中在TicketService里，分享一段分配工单的代码逻辑：

@Transactional public void assign(Long ticketId, Long operatorId, Long adminId) { Ticket ticket = ticketMapper.selectById(ticketId); if (ticket == null) { throw new BizException("工单不存在或已被删除"); } if (ticket.getStatus() != TicketStatus.PENDING) { throw new BizException("当前工单状态不允许分配"); } User operator = userMapper.selectById(operatorId); if (operator == null || !operator.getRoleCode().equals("OPERATOR")) { throw new BizException("指定的处理人无效"); } ticket.setOperatorId(operatorId); ticket.setStatus(TicketStatus.ASSIGNED); ticket.setAssignTime(LocalDateTime.now()); ticketMapper.updateById(ticket); // 写操作日志 logService.record(ticketId, adminId, "分配工单给 " + operator.getRealName()); }

这段代码值得注意的有两处：一是@Transactional保证分配过程的原子性，修改工单和写操作日志要么同时成功要么同时失败；二是所有状态流转都先做前置校验，符合状态机规则才往下走。这里面的防御性编程思路，是官网教程里不会教但实际开发中必须要有的意识。

4.3 定时任务与设备状态采集

Spring Boot的定时任务用起来非常简单，在启动类加@EnableScheduling，然后在任务方法上标注@Scheduled即可。我用于采集设备状态的定时任务长这样：

@Scheduled(cron = "0 */1 * * * ?") public void collectDeviceStatus() { List<Device> devices = deviceService.listActiveDevices(); for (Device device : devices) { // 先尝试SNMP采集 boolean alive = snmpPoller.checkDevice(device.getIpAddress()); // 更新Redis中的心跳KEY String key = "device:heartbeat:" + device.getId(); if (alive) { redisUtil.set(key, String.valueOf(System.currentTimeMillis()), Duration.ofSeconds(120)); } // 采集端口流量用于后续分析 deviceService.recordStatus(device.getId(), alive); } }

采集数据的频率我设置为每分钟一次，因为校园网的规模不大，这样的频率足够及时发现问题，也不会给网络设备造成额外负担。真要说秒级发现故障，那要上专门的监控系统做流量采样，但对学校场景来说，分钟级的心脏响应已经很实用。

采集到的历史状态数据，我建了一张设备状态记录表，按天归档，保留30天。做设备在线率统计时直接按月查询，这样不会因为长期运行导致单表数据量过大。

4.4 前端页面的极简实现

前端页面我用Thymeleaf模板引擎加Bootstrap写了一套基础管理界面。整体布局是左边菜单栏、右边内容区，菜单按角色动态渲染。设备监控页用表格列出所有设备，在线状态用红绿圆点直观标记，配合一个简单的Dashboard页面，展示今日工单数、待处理工单、设备离线数和最近告警记录。

有同行看过之后问，为什么不搞大屏可视化，用ECharts画几个图表多好看。说实话，真实运维场景里最有用的不是绚丽的大屏，而是列表里醒目的红色状态和工单超时的倒计时。可视化当然可以加，但对于几个关键指标，我用Bootstrap和简单的CSS就能表达清楚，没必要为了视觉效果引入额外的前端工程复杂度。

5. 上线后踩过的坑与排查实录

5.1 数据库连接池爆掉与连接泄漏

系统上线第一周，运维师傅反映查询工单列表时页面经常卡住，偶尔报Connection is not available的异常。排查思路分三步：先看MySQL的连接数，发现已经满了；再看应用日志，发现大量SQL执行超时；最后定位到是代码里有个查询设备状态的定时任务，每次循环都新开一个数据库连接，但异常时没有正确关闭。用MyBatis-Plus的时候，只要把数据源交给Spring管理，默认就会用HikariCP连接池，按理说不该出这种问题，问题出在采集代码里我直接用了SqlSessionTemplate，手动获取了连接却没在finally块中释放。

修复方案是在采集逻辑中统一走MyBatis-Plus的IService接口，让框架管理连接生命周期。同时给HikariCP设置了maximum-pool-size: 20和connection-timeout: 30000，避免极端情况全部连接被占满后请求无限等待。

5.2 定时任务重复执行引发重复告警

学校有两台应用服务器，我一开始图省事直接用sigar那套方案做负载均衡，结果@Scheduled定时任务在每台服务器上都执行了一遍，导致设备离线告警重复发送。这个问题的标准解法是用分布式锁，引入Redisson或者Spring Integration的锁机制。但在只有两台服务器的场景下，我换了一个更轻量的方案：用MySQL的GET_LOCK函数实现跨节点互斥。

SELECT GET_LOCK('device_monitor_lock', 0)

只有拿到锁的节点才执行采集任务，执行完再RELEASE_LOCK。这个方案简单有效，不用额外引入分布式组件，学校环境完全够用。不过如果节点超过三台，建议还是上Redisson，锁的管理会更规范。

5.3 学生批量报修高峰期的性能优化

开学第一周，新生报到，宿舍网络问题集中爆发，一小时内工单量从日均50涨到300多。工单列表页面开始变慢，原因是首页渲染时直接把所有工单都查出来，加上关联用户和设备信息，SQL关联了四张表，数据量一大就很吃力。

我做了两个优化：一是在工单列表查询中增加分页，每页显示20条；二是把列表接口改成只查询主表基础字段，用户姓名和设备名称等关联信息通过批量查询后再填充，而不是让MyBatis-Plus自动关联查询。改完之后，高峰期接口响应时间从3秒降到200毫秒以内。这里有个通用思路供参考——列表页不要直接返回全字段，给前端什么数据就用什么字段，关联查询尽量减少，能用两次简单查询解决的就别用一次复杂JOIN解决。

5.4 安全细节：接口权限审计

系统上线后，我还补了一层接口访问审计。每次请求都会记录操作人、操作时间、操作类型、请求参数和返回值状态，写到操作日志表里。这样做有两个好处：一是出了问题可以回溯是谁在什么时间做了什么操作；二是学校信息中心每年有等保测评要求，操作日志是硬性指标。Spring Boot实现这个很简单，自定义一个HandlerInterceptor或者AOP切面即可。

我用的方案是Spring MVC的HandlerInterceptor，在preHandle里记录请求开始时间，在afterCompletion里记录请求结果和耗时。注意千万不能把请求参数直接序列化存日志，里面可能包含密码等敏感信息，我这边只记录工单ID、设备ID这类业务标识和状态码。

5.5 给同行的四点运维建议

系统跑稳之后，回看整个项目，我梳理了几条对同行真正有用的经验：

第一，先跑通核心流程再叠加功能。工单流转是灵魂，其他都是锦上添花。我第一版只做了工单和用户登录，用了两周稳定运行后才开始加设备监控，保证任何时刻系统都有可用的核心功能。

第二，能买现成的不重复造轮子。比如Excel导出，直接用Hutool的ExcelWriter，没必要自己封装POI操作。Snmp协议解析用SNMP4J，不用自己解析BER编码。这些轮子经过长期社区验证，比自己写更可靠。

第三，时刻为接手人考虑。我在代码里写注释时，默认读者是对系统完全不熟悉的后来者，关键业务逻辑的注释写得特别详细。信息中心这种地方人员流动频繁，一个系统能做五年十年，靠的不是某个人记得所有细节，而是代码和文档让后面任何人接手都能快速上手。

第四，重视非功能需求。日志规范、异常处理、慢查询优化，这些不像功能模块那么显眼，但决定了系统能活多久。我见过太多毕业设计级别的项目，功能齐全但日志一塌糊涂，出了问题根本没法排查。

6. 系统上线后的真实使用效果与后续规划

6.1 实际落地后的数据变化

系统从上线到现在运行了大半年，简单汇报几组实际数据，供大家评估效果：工单平均响应时间从过去的半天（靠人盯微信群）缩短到目前一个半小时以内；设备离线发现的平均时间从用户投诉后才发现的以天为单位，缩短到巡检周期内的分钟级；工单处理完成率从没有统计过到现在的月度98%，另外用户的报修体验也有了明显改观，什么时候处理的、谁在处理、处理到哪一步了，三维状态可查。

有意思的一个变化是，系统上线之前，信息中心领导对运维工作的评价基本靠印象；上线之后，每个月我拉一张统计报表，多少人报修、平均多久处理完、哪些楼栋故障最集中，一目了然。汇报工作轻松很多，也更有说服力。

6.2 后续可以扩展的几个方向

目前的系统功能已经能满足学校的核心运维需求，但后续有几个方向值得继续完善。

首先是知识库模块。把高频故障（比如某宿舍楼注册认证失败、某型号交换机端口down）的处理手册沉淀进系统，运维师傅处理工单时可以快速关联以往方案，新人也更容易上手。这个功能我还没来得及做，但值得开发。

其次是移动端适配。现在的页面在手机上能用，但体验一般，很多运维师傅干活时其实是拿着手机在机房里看工单，做一套移动端H5或者直接用现成的移动端框架重构前端，能明显提升使用意愿。

最后是与学校通知渠道的集成。比如工单完成时自动发邮件或企业微信通知，设备告警时推送短信。当时没做是因为信息中心希望控制通知打扰，但后续维护中可以按需打开。

做这类学校内部系统，最大的体会就是：技术只是手段，解决实际问题才是根本。Spring Boot给了我们一个稳定高效的基础框架，但真正让系统发挥价值的，是对学校运维场景的深刻理解和对用户使用习惯的尊重。如果你也在学校信息中心做类似的事情，或者正在用Spring Boot做系统开发的练手项目，希望这篇博文能给你一些参考。后续我还会把设备SNMP采集和告警去重的代码进一步整理分享出来，咱们评论区交流。