# 2024-2025年度教育E卡通功能点梳理
## 新增需求
1. 学校与大数据平台统一；
2. 提供给大数据平台接口；
3. H5页面，增加E卡通卡号2150开头的
4. 修改注册报道的提示词和逻辑
5. 服务器网络架构要调整；
6. 实时乘车要上线；
##  数据处理
### 2023需求未完成的数据库排查
1. 检查所有毕业班，是否为6年级或初三；所有六年级或初三，是否为毕业班；并修正；
2. 检查所有手动升级的年级，是否为毕业班或特殊学校；所有毕业班或特殊学校，是否设置为手动升级；并修正；
3. 检查每一所学校的年级设置情况，是否设置完善（3、6、9个年级，年级序号是否正常）；并修正、自动补齐；
4. 同一个年级内，班级序号是否有重复；如有，列出并手动修正；
5. 搜索所有毕业班和今年刚毕业的学生，搜索出毕业年龄不符的学校年级班级，进行排查，以排查是否在毕业时发生了错误。（列出毕业年龄超过2年的学生，通过大平台接口进行学生查询，再通知学校管理员核对）
6. 根据每个年级学生的年龄，来判断班级是否设置错误的升级，进行排查升级是否发生了错误。
### 2023未完成的业务逻辑修正
1. 学校无权进行年级管理。必须由我们来进行管理。设置好了小学，就自动创建1-6年级，设置好了初中就自动创建7-9年级；并设定6年级和9年级，默认手动升级、设置毕业班，其余默认自动升级，非毕业班；不能设定年级昵称，统一叫“一、二、三、四、五、六、七、八、九年级”；
2. 新建班级时，只可选择是属于几年级的几班（从阿拉伯数字1班开始排到99班），班数就是班级编号，不可重复；设置班级昵称、备注等选项，其他一概不显示；
3. 批量导入数据时，年级选项、班级选项固定（模版里确定，并注释如何填写）

### 其他
1. 对新数据进行限制输入：
   1. 创建新学校时，一次性全部创建所有年级；对所有年级，自动设定非毕业班、毕业班，且学校无权修改；（人工也行，但权限不能给学校、区，必须我们自己维护）
   2. 创建班级时，只能选择班级序号，且不可重复；
   3. 新生批量导入数据、注册报道时，限制年级选项、班级选项为阿拉伯数字；否则导入出错；
2. 对老数据进行排查、修正：
   1. 参考2023需求
## 基础平台
1. 注册报到批量导入异常
    - 外籍学生建议手动，如果数量少的话
2. 说明文字：
    - 注册报道用于小升初学生E卡通的注册，从原毕业小学注册到现在所在的初中。
    - 导入前请先点击“导入模板下载”下载模板，请勿对模板进行任何样式及格式的修改，否则可能影响您的正常导入。
    - 根据{school_name}资料，初一年级名称是“xx”，初一所有班级的名称是：“xxx”“xxx”。。。。。，请按照上述名称填写年级、班级。如没有所在班级，请在“组织机构”-“班级管理”进行添加。
    - 一次批量导入不要超过500条数据。
2. 学生信息录入页面（删除重复数据报错）
    - 直接限制重复录入；
    - 增加字段“提交时间”：移动端采集点击“提交”的时间戳或PC端“保存”/“提交”的时间戳；
3. 服务器日志磁盘满了导致平台登录页面验证码无法加载
    - 写监控脚本；
4. 学生信息管理页面学生没有照片（数据库与迁移照片存在大小写不匹配情况）
    - 统一设置成大写，去空格，去CJK字符等非ascii字符；
    - 跑一遍数据，查询重复的数据，并删除；
5. 报到注册审核异常（毕业升级/毕业离校，之前卡状态为空造成审核报错）
    - 不判断卡状态；
6. 制卡确认查询页面（查询条件是数据创建时间）
    - 查询条件改成 【确认制卡的确认时间】
## 卡务平台
1. 临时增效
    - 每年9月1日自动剔除临时表里初三已毕业的学生；
    - 每年10月1日自动剔除临时表里非正常状态学生；
2. 制卡订单管理页面区域、学校不匹配
    - 区域、学校不匹配的：从大数据平台拉取进行匹配；
    - 制卡订单管理页面的“申请制卡时间”字段改成“区审核通过时间”；
3. 制卡数据检查
    - 录入时提前判断：制卡数据0KB、1KB、区域代码null、性别为空等；
4. 增效记录（根据E卡通查询不到小写的卡序列号的记录）
    - E卡通号查询增效记录时，不区分卡序列号大小写，显示该E卡通号下的全部增效记录
## H5端
1. 用户名密码错误，重置密码后登录还是报错
    - 数据采集入库时大小写设置成不敏感，前端自动转换
2. 首页要增加市民卡卡号

## 网络和服务器
### 服务器网络架构调整

## 智慧教育大平台
教育E卡通对接教育大数据平台
### 用户体系对接
1. 用大平台的用户体系；
2. 如果大平台用户体系无法登录，则用原身份证密码登录。
### 数据字段核对
1. 学校数据
   <br>与教育E卡通学校信息逐一核对匹配。以大平台学校为准进行修复。
2. 年级数据
   <br>不动
3. 班级数据
   <br>不动
4. 学生数据
   <br>核对一遍，看下核对的情况再考虑是否修正学生数据。
### 数据对接
1. 新采集的数据，推送到大平台；以区审核通过为标准；
2. 提供给大平台学生信息查询接口。
### 支付对接
1. 验证在小程序里嵌入H5以后，是否可以实现微信支付；如可行，则进行小程序微信支付的改造；
2. 如不可行，考虑是否做个独立的小程序版本的E卡通；
### 管理平台对接
1. 用户对接
   1. 大数据平台登录时，提供管理员的角色信息，如果是学校管理员，教育E卡通管理平台为其分配账号及对应的学校管理员权限。班主任和区级管理员暂不对接。
   
## 志教融合
### POS刷卡
### 平台同步
### 数据上传
### 刷卡数据查询

## 苏服办
纳入日常运维

## 其他项目
1. 数据回流工作。定义各数据回流接口；
2. 
## 日常运维
### 中间件
1. 常规安全检查和性能检查
### 网络
1. 根据电教馆要求，进行网络的常规检查
### 安全
1. 根据电教馆要求，进行安全漏洞修复等工作
### 日常运维监测告警
1. 重新梳理各主机的功能、业务和负载情况，调整优化；
2. 对主机进行业务监控，发现异常情况及时报警，上线报警监控应用；
3. 定期对各业务进行健康检查、日志巡查，发现异常情况及时修复；
### 重要时间节点保障
1. 党会、两会、国庆、党庆等重大时间节点，24小时待命；
2. 关键时刻根据要求关停服务器、屏蔽外网访问、静态页面访问等措施

## 制度规范及文档
### 运维部分
#### 每日检查
- 检查项  
1. 各主机业务运行正常。
2. 各业务日志正常。
3. 各业务数据正常。
4. 各业务配置正常。
5. 各业务服务正常。
6. 各业务告警处理。
#### 每周检查
- 检查项  
#### 每月检查
- 检查项  
#### 季度检查
- 检查项  
根据检查项，写脚本，每日、每周等定期运行，自动生成报表。

#### 故障处理流程
1. 故障发现：根据故障现象、日志、监控等信息，确定故障原因。
2. 故障上报：将故障原因及相关信息上报给相关负责人，并及时跟进处理。
3. 故障分类：将故障原因分类，并制定相应的处理流程。
4. 故障排查：根据故障原因，分析故障现象、日志、监控等信息，确定故障根因。
5. 故障修复：根据故障根因，制定故障修复方案，并实施故障修复。
6. 故障复盘：根据故障修复情况，总结经验教训，提升工作效率。
## 时间表