note/work/教育E卡通/2024-07-25EKT.md

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条数据。
3. 学生信息录入页面（删除重复数据报错）
   • 直接限制重复录入；
   • 增加字段“提交时间”：移动端采集点击“提交”的时间戳或PC端“保存”/“提交”的时间戳；
4. 服务器日志磁盘满了导致平台登录页面验证码无法加载
   • 写监控脚本；
5. 学生信息管理页面学生没有照片（数据库与迁移照片存在大小写不匹配情况）
   • 统一设置成大写，去空格，去CJK字符等非ascii字符；
   • 跑一遍数据，查询重复的数据，并删除；
6. 报到注册审核异常（毕业升级/毕业离校，之前卡状态为空造成审核报错）
   • 不判断卡状态；
7. 制卡确认查询页面（查询条件是数据创建时间）
   • 查询条件改成 【确认制卡的确认时间】

卡务平台

1. 临时增效
   • 每年9月1日自动剔除临时表里初三已毕业的学生；
   • 每年10月1日自动剔除临时表里非正常状态学生；
2. 制卡订单管理页面区域、学校不匹配
   • 区域、学校不匹配的：从大数据平台拉取进行匹配；
   • 制卡订单管理页面的“申请制卡时间”字段改成“区审核通过时间”；
3. 制卡数据检查
   • 录入时提前判断：制卡数据0KB、1KB、区域代码null、性别为空等；
4. 增效记录（根据E卡通查询不到小写的卡序列号的记录）
   • E卡通号查询增效记录时，不区分卡序列号大小写，显示该E卡通号下的全部增效记录

H5端

1. 用户名密码错误，重置密码后登录还是报错
   • 数据采集入库时大小写设置成不敏感，前端自动转换
2. 首页要增加市民卡卡号

网络和服务器

服务器网络架构调整

智慧教育大平台

教育E卡通对接教育大数据平台

用户体系对接

1. 用大平台的用户体系；
2. 如果大平台用户体系无法登录，则用原身份证密码登录。

数据字段核对

1. 学校数据
   与教育E卡通学校信息逐一核对匹配。以大平台学校为准进行修复。
2. 年级数据
   不动
3. 班级数据
   不动
4. 学生数据
   核对一遍，看下核对的情况再考虑是否修正学生数据。

数据对接

1. 新采集的数据，推送到大平台；以区审核通过为标准；
2. 提供给大平台学生信息查询接口。

支付对接

1. 验证在小程序里嵌入H5以后，是否可以实现微信支付；如可行，则进行小程序微信支付的改造；
2. 如不可行，考虑是否做个独立的小程序版本的E卡通；

管理平台对接

1. 用户对接
   1. 大数据平台登录时，提供管理员的角色信息，如果是学校管理员，教育E卡通管理平台为其分配账号及对应的学校管理员权限。班主任和区级管理员暂不对接。

志教融合

POS刷卡

平台同步

数据上传

刷卡数据查询

苏服办

纳入日常运维

其他项目

1. 数据回流工作。定义各数据回流接口；

日常运维

中间件

1. 常规安全检查和性能检查

网络

1. 根据电教馆要求，进行网络的常规检查

安全

1. 根据电教馆要求，进行安全漏洞修复等工作

日常运维监测告警

1. 重新梳理各主机的功能、业务和负载情况，调整优化；
2. 对主机进行业务监控，发现异常情况及时报警，上线报警监控应用；
3. 定期对各业务进行健康检查、日志巡查，发现异常情况及时修复；

重要时间节点保障

1. 党会、两会、国庆、党庆等重大时间节点，24小时待命；
2. 关键时刻根据要求关停服务器、屏蔽外网访问、静态页面访问等措施

制度规范及文档

运维部分

每日检查

• 检查项

1. 各主机业务运行正常。
2. 各业务日志正常。
3. 各业务数据正常。
4. 各业务配置正常。
5. 各业务服务正常。
6. 各业务告警处理。

每周检查

• 检查项

每月检查

• 检查项

季度检查

• 检查项
  根据检查项，写脚本，每日、每周等定期运行，自动生成报表。

故障处理流程

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

时间表