142 lines
7.1 KiB
Markdown
142 lines
7.1 KiB
Markdown
# 2024-2025年度教育E卡通功能点梳理
|
||
|
||
## 常规运维
|
||
|
||
### 2023 需求未完成的数据库排查：
|
||
1. 检查所有毕业班，是否为6年级或初三；所有六年级或初三，是否为毕业班；并修正；
|
||
2. 检查所有手动升级的年级，是否为毕业班或特殊学校；所有毕业班或特殊学校，是否设置为手动升级；并修正；
|
||
3. 检查每一所学校的年级设置情况，是否设置完善（3、6、9个年级，年级序号是否正常）；并修正、自动补齐；
|
||
4. 同一个年级内，班级序号是否有重复；如有，列出并手动修正；
|
||
5. 搜索所有毕业班和今年刚毕业的学生，搜索出毕业年龄不符的学校年级班级，进行排查，以排查是否在毕业时发生了错误。（列出毕业年龄超过2年的学生，通过大平台接口进行学生查询，再通知学校管理员核对）
|
||
6. 根据每个年级学生的年龄，来判断班级是否设置错误的升级，进行排查升级是否发生了错误。
|
||
|
||
### 年级和班级设置检查与修正流程
|
||
|
||
1. **检查毕业班级设置：**
|
||
- **目标：** 确保所有毕业班级为六年级或初三，并确保所有六年级或初三均为毕业班级。
|
||
- **操作：** 检查所有班级的年级设置，确保六年级和初三为毕业班，非毕业班级年级不为六年级或初三。对于不符合的班级进行修正。
|
||
|
||
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. 对老数据进行排查、修正：
|
||
参考2023需求
|
||
|
||
|
||
### 中间件
|
||
1. 常规安全检查和性能检查。
|
||
### 网络
|
||
1. 根据电教馆要求，进行网络的常规检查。
|
||
### 安全
|
||
1. 根据电教馆要求，进行安全漏洞修复等工作。
|
||
|
||
### 日常运维监测告警
|
||
1. 重新梳理各主机的功能、业务和负载情况，调整优化。
|
||
2. 对主机进行业务监控，发现异常情况及时报警。上线报警监控应用。
|
||
3. 定期对各业务进行健康检查、日志巡查，发现异常情况及时修复。
|
||
|
||
### 重要时间节点保障
|
||
1. 党会、两会、国庆、党庆等重大时间节点，24小时待命；
|
||
2. 关键时刻根据要求关停服务器、屏蔽外网访问、静态网页访问等措施。
|
||
|
||
### 规范制度、检查表、文档等标准流程
|
||
#### 运维部分
|
||
##### 每日检查
|
||
- 检查项
|
||
1. 各主机业务运行正常。
|
||
2. 各业务日志正常。
|
||
3. 各业务数据正常。
|
||
4. 各业务配置正常。
|
||
5. 各业务服务正常。
|
||
6. 各业务告警处理。
|
||
|
||
##### 每周检查
|
||
- 检查项
|
||
|
||
##### 每月检查
|
||
- 检查项
|
||
|
||
##### 季度检查
|
||
- 检查项
|
||
|
||
根据检查项，写脚本，每日、每周等定期运行，自动生成报表。
|
||
|
||
##### 故障处理流程
|
||
1. 故障发现：根据故障现象、日志、监控等信息，确定故障原因。
|
||
2. 故障上报：将故障原因及相关信息上报给相关负责人，并及时跟进处理。
|
||
3. 故障分类：将故障原因分类，并制定相应的处理流程。
|
||
4. 故障排查：根据故障原因，分析故障现象、日志、监控等信息，确定故障根因。
|
||
5. 故障修复：根据故障根因，制定故障修复方案，并实施故障修复。
|
||
6. 故障复盘：根据故障修复情况，总结经验教训，提升工作效率。
|
||
|
||
|
||
|
||
## 志教融合项目
|
||
#### POS刷卡
|
||
#### 平台同步
|
||
#### 数据上传
|
||
#### 刷卡数据查询
|
||
## 其他项目
|
||
|
||
1. 数据回流工作。定义各数据回流接口；
|
||
2.
|
||
|
||
### 苏服办
|
||
纳入日常运维
|
||
|
||
### 大平台
|
||
教育E卡通对接教育大数据平台
|
||
#### 用户体系对接
|
||
1. 用大平台的用户体系；
|
||
2. 如果大平台用户体系无法登录，则用原身份证密码登录。
|
||
|
||
#### 数据字段核对
|
||
1. 学校数据
|
||
与教育E卡通学校信息逐一核对匹配。以大平台学校为准进行修复。
|
||
2. 年级数据
|
||
不动。
|
||
3. 班级数据
|
||
不动。
|
||
4. 学生数据
|
||
5. 核对一遍，看下核对的情况再考虑是否修正学生数据。
|
||
#### 数据对接
|
||
1. 新采集的数据，推送到大平台；以区审核通过为标准；
|
||
2. 提供给大平台学生信息查询接口。
|
||
#### 支付对接
|
||
1. 验证在小程序里嵌入H5以后，是否可以实现微信支付；如可行，则进行小程序微信支付的改造；
|
||
2. 如不可行，考虑是否做个独立的小程序版本的E卡通；
|
||
#### 管理平台对接
|
||
1. 用户对接
|
||
大数据平台登录时，提供管理员的角色信息，如果是学校管理员，教育E卡通管理平台为其分配账号及对应的学校管理员权限。班主任和区级管理员暂不对接。
|
||
|
||
## 项目计划 |