上线首周：自动化排课初见成效，但底层数据“带病运行”

排课管理系统在该校正式启用第1天即完成全校12个学院、897门理论课的首轮智能排课，较人工排课周期缩短6.8个工作日。系统内置的约束引擎（含教室容量、教师授课时段偏好、课程周学时连续性等17类硬性规则）成功规避了83%的历史高频冲突类型，如“同一教师同时间段跨校区授课”“阶梯教室安排小班研讨课”等。但后台日志显示，首轮排课中仍有156处未解决冲突，主要集中在实验课模块——原因在于实验室预约系统未开放实时占用状态API，排课管理系统仅能读取静态课表快照，导致23间专业实验室出现日均2.4次时段重叠。更关键的是，教务处提供的基础数据包中，“课程属性”字段存在三类混用：原Excel模板中用“必修/选修/限选”文本值，而系统要求布尔型flag（is_required: true/false）与枚举值（course_category: "major_required"|"general_elective"）双轨并存；实际导入时因ETL脚本未做字段标准化清洗，造成327门课程被错误归类为“通识选修”，进而触发错误的教室分配策略（默认匹配多媒体普通教室而非专业实验室）。我们现场核查发现，该问题并非系统缺陷，而是数据治理断层所致：教务科录入端沿用旧版教学计划表，未同步更新字段语义规范。

第二周：接口联调暴露关键链路脆弱性

第二周重心转向与教务核心系统的双向对接。排课管理系统通过RESTful API与学校统一身份认证平台（UISP）、教务综合管理系统（JWGL）、教室资源调度平台（CRSP）完成三级联调。其中，与UISP的OAuth2.0令牌交换流程正常，但教师信息同步出现显著延迟：系统每2小时拉取一次教职工主数据，而UISP侧对职称变更、院系调整等操作实行T+1同步机制，导致排课管理系统中17位新晋副教授仍显示为“讲师”身份，其可授课程范围被系统自动收缩（限制不得承担研究生课程），引发3个学院的教学调度投诉。更严峻的是与JWGL的数据格式不兼容：排课管理系统要求课程开课数据以JSON Schema v1.2格式提交，关键字段包括"course_id"(string, required)、"teaching_weeks"(array of integers, minItems=1)、"class_capacity"(integer, minimum=5)，但JWGL导出接口仍输出旧版XML格式，且"teaching_weeks"字段被封装为逗号分隔字符串（如"1,2,3,5,6,7"），未转为整数数组。技术团队紧急编写中间件转换服务，但测试发现当单门课程授课周数超过12周时，字符串解析会因内存溢出中断，该Bug在压力测试中复现率达100%。我们建议校方立即冻结JWGL侧所有非必要数据导出任务，优先升级其API网关至支持OpenAPI 3.0规范，并将"teaching_weeks"字段强制改为JSON数组格式——这不仅是技术适配问题，更是数据契约意识的落地节点。

第三周：教师端体验塌方与权限模型重构

第三周用户反馈陡然升级：教师端App登录失败率攀升至21%，教务大厅窗口日均处理登录咨询43.6人次，峰值达单日79例。经全链路追踪，问题根因锁定在JWT（JSON Web Token）签发环节：排课管理系统调用UISP签发token时，传入的audience参数硬编码为"https://kebiao.example.edu.cn"，而该校统一门户实际域名为"https://portal.univ.edu.cn"，导致UISP返回的token在教师端验证时因aud校验失败被拒绝。该配置项深藏于部署清单的config.yaml第87行，实施团队误将其与测试环境参数混淆。更深层问题是角色权限粒度失控：系统预设的"任课教师"角色默认拥有"查看本人课表""导出课表PDF""申请调课"三项权限，但未隔离"查看他人课表"能力。结果有8位教师无意中通过URL参数篡改（如将?teacher_id=1001改为?teacher_id=1002）访问到同事课表，虽无敏感信息泄露，却触发安全审计告警。我们协同信息中心启动权限模型重构：将原7类角色压缩为5类（含"教学秘书（院级）""教务专员（校级）""督导员""任课教师（只读）""任课教师（可调）"），所有权限开关采用RBAC+ABAC混合策略，关键操作（如调课审批）增加二次短信验证。截至第三周末，登录失败率降至4.3%，但仍需观察第四周真实教学周启动后的并发压力表现。

第四周：常态化运行瓶颈与可持续运维方案

进入第四周，系统已支撑全校16,284名本科生、2,107门次课程的日常课表查询与微调，日均API调用量稳定在28.4万次。但两个隐性瓶颈浮出水面：一是缓存雪崩风险，系统采用Redis集群缓存课表数据，TTL统一设为3600秒，但每周一早8:00大量教师集中刷新课表，导致缓存击穿，数据库QPS瞬时突破1200，慢查询日志中"SELECT * FROM schedule_view WHERE teacher_id = ? AND week_no = ?"占比达63%；二是历史课表归档机制缺失，当前仅保留近3学期数据，而教务评估需追溯5年课表用于教学工作量核算，现有方案无法满足《普通高等学校本科教育教学审核评估实施方案》第4.2.1条要求。我们提出三项即刻行动：第一，将课表缓存TTL改为随机区间（3200–3800秒），并为高频查询字段（teacher_id+week_no）建立复合索引；第二，在排课管理系统中嵌入轻量级归档模块，每月1日零点自动将上学期课表压缩为Parquet格式，同步至校级数据湖HDFS路径/dw/academic/schedule_archive/；第三，向教务处提交《排课管理系统数据字典V2.1》，明确标注27个核心字段的业务含义、来源系统、更新频率及脱敏规则（如student_id采用SHA-256哈希后截取前8位）。这些动作并非单纯技术修补，而是推动该校从“系统可用”迈向“数据可信”的实质性跃迁——当排课管理系统真正成为教学治理的数字基座，其价值才超越课表生成本身。