容量分析与治理模型

这是系统架构概览的技术伴随文档。它为任何规模的部署提供详细的容量规划指导，并描述了运营 openDesk Edu 平台的治理模型——如何做出决策、如何管理变更，以及平台如何随着时间演进。

容量部分帮助您在部署前为基础设施定尺寸。治理部分描述了部署后如何保持平台持续运行——升级周期、生命周期管理、变更控制和组织角色。

容量分析

定尺寸的理念

openDesk Edu 被设计为参考架构，而非固定尺寸的设备。不存在单一的"推荐"硬件规格，因为每个机构都有不同的用户数量、工作负载、峰值负载特征和服务选择。容量规划遵循模块化方法：基于每个服务的需求独立定尺寸，然后汇总（加上集群操作的开销）。

部署层级

平台跨多个部署层级进行扩展。这些层级是规划的概念性指南，而非刚性配置。机构可以在服务类别之间混合层级——例如，可以在大型 LMS 层级旁边运行中等文件存储层级。

层级	活跃并发用户	总用户数	集群节点	典型 CPU	典型内存	典型存储
层级 0（试点）	0–500	2,000	1–2	4–8 vCPU	16–32 GB	500 GB–2 TB
层级 1（学校）	500–5,000	2,000–10,000	3–5	16–32 vCPU	64–128 GB	2–10 TB
层级 2（大学）	5,000–50,000	10,000–100,000	8–15	64–256 vCPU	256–1024 GB	10–100 TB
层级 3（大型大学/联盟）	50,000+	100,000+	20+	512+ vCPU	2+ TB	100+ TB

服务特定的容量需求

身份与认证

服务	CPU	内存	存储	备注
Keycloak	0.5–2 vCPU	1–4 GB	5–10 GB	按活跃会话扩展
Shibboleth SP	0.25–1 vCPU	0.5–2 GB	1–2 GB	每个 SAML 服务一个实例
Nubus	0.5–2 vCPU	1–4 GB	5–10 GB	门户和 IAM 层

文件存储与协作

服务	CPU	内存	存储	备注
Nextcloud (应用)	2–8 vCPU	4–16 GB	1–5 GB	文件在 PV 上
Nextcloud (数据库)	2–4 vCPU	4–8 GB	20–50 GB	元数据
Nextcloud (Redis)	0.5–1 vCPU	1–2 GB	1 GB	缓存
OpenCloud	1–4 vCPU	2–8 GB	5–10 GB	比 Nextcloud 更轻量

存储增长公式: 总计 ≈ 用户数 × 平均存储 × 1.7（版本控制 + 开销）

邮件与协作套件

服务	CPU	内存	存储	最大邮箱数	备注
OX App Suite	4–16 vCPU	8–32 GB	50–200 GB	10k–100k	企业级协作套件
SOGo	2–4 vCPU	4–8 GB	20–50 GB	5k–25k	轻量级 Webmail
Grommunio	4–8 vCPU	8–16 GB	30–100 GB	5k–50k	支持 ActiveSync
MariaDB	4–16 vCPU	8–32 GB	50–200 GB	–	协作套件数据库

学习管理系统

服务	CPU	内存	存储	最大并发	备注
Moodle	2–8 vCPU	4–16 GB	20–100 GB	500–5k	LAMP 架构
Moodle (数据库)	4–16 vCPU	8–32 GB	50–200 GB	–	建议 PostgreSQL
ILIAS	4–16 vCPU	8–32 GB	50–200 GB	1k–10k	基于 Java
ILIAS (数据库)	4–16 vCPU	8–32 GB	100–500 GB	–	Java 数据库开销

视频会议

服务	CPU	内存	带宽	最大并发	备注
Jitsi	2–8 vCPU 每场会议	4–16 GB	1–8 Mbps/参与者	50–100 每个实例	WebRTC 转码
BigBlueButton	4–16 vCPU	8–32 GB	0.5–2 Mbps/参与者	100–200 每个实例	建议使用 GPU 转码

协作与生产力

服务	CPU	内存	存储	备注
Collabora	2–8 vCPU	4–16 GB	1–5 GB	WOPI 实例
Etherpad	0.5–2 vCPU	1–4 GB	1–5 GB	轻量级
CryptPad	1–4 vCPU	2–8 GB	5–10 GB	端到端加密
XWiki	2–4 vCPU	4–8 GB	10–50 GB	Java CMS
BookStack	1–2 vCPU	2–4 GB	5–20 GB	轻量级 Wiki
OpenProject	2–4 vCPU	4–8 GB	10–50 GB	Ruby 项目管理

实时通信

服务	CPU	内存	存储	最大并发	备注
Element/Matrix	0.5–2 vCPU	1–4 GB	5–10 GB	500–5k	Synapse 服务器
Zammad	2–4 vCPU	4–8 GB	10–50 GB	500–2k	工单系统

基础设施

服务	CPU	内存	存储	备注
PostgreSQL	2–8 vCPU	4–16 GB	20–100 GB	每个实例
MariaDB	2–8 vCPU	4–16 GB	20–100 GB	每个实例
Redis	0.5–2 vCPU	1–4 GB	1–5 GB	每个实例

存储规划

公式： 总存储 = (用户数据 × 增长因子) + 服务开销 + 备份开销 + 缓冲

用户数据 = N × 平均存储 × (1 + 年增长率 × 年数)
服务开销 ≈ 用户数据的 15%
备份开销 ≈ 用户数据的 250%（每日 2 次 + 每周 1 次）
缓冲 = 总计的 20%

简化估算： 每个用户 40–60 GB（包含备份和开销，计算 3 年）

存储类别：

类别	用例	访问模式	成本	性能
本地 SSD	数据库	频繁随机读写	高	非常高
Ceph/RBD	持久卷	混合	中等	高
CephFS	共享文件	共享读写	中等	中等
NFS	共享配置	频繁读，偶尔写	低	中等
S3	备份/归档	很少访问，顺序读	低	低

网络规划

外部带宽

活动	每个用户带宽
基础浏览	100–500 kbps
文档编辑	200–1000 kbps
视频会议（Jitsi）	500–8000 kbps
视频会议（BigBlueButton）	0.5–2 Mbps
视频播放	1–5 Mbps
文件上传/下载	1–10 Mbps

公式： 总带宽 = 峰值用户数 × 平均带宽 × 峰值因子（1.5–3.0）

层级 2 示例（5,000 用户）： 5,000 × 0.5 Mbps × 2 = 5 Gbps 出口带宽

Kubernetes 集群开销

组件	CPU	内存	存储	备注
etcd	2–4 vCPU	8–16 GB	20–50 GB	建议 3 或 5 节点 HA
控制平面	2–4 vCPU	4–8 GB	5–10 GB	每个控制平面节点
节点操作系统	0.5 vCPU 每个 Worker	1–2 GB 每个 Worker	20–50 GB 每个 Worker	操作系统
CNI	0.5 vCPU 每个节点	1 GB 每个节点	–	Calico/Flannel
Prometheus	2–4 vCPU	8–16 GB	50–100 GB	按集群大小扩展
Loki	2–8 vCPU	8–32 GB	100–500 GB	按日志量扩展
Traefik	1–2 vCPU	2-4 GB	1 GB	每个 Ingress

总开销： 10–20 vCPU, 20–40 GB RAM（不包括节点操作系统）

扩展策略

水平扩展

无状态服务： 添加 Pod 副本
有状态服务： 添加读副本或分片
存储： 添加 Ceph OSD 或 NFS 服务器
Ingress： 添加 Ingress 控制器

HPA 示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nextcloud
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nextcloud
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

垂直扩展

增加每个 Pod 的 vCPU 和内存
使用更大的节点规格
分离读写工作负载到不同节点

集群自动扩展

扩展上限： 当 Pod 无法被调度时
扩展下限： 当节点资源使用率过低时（默认 10 分钟）
最小/最大节点数： 设置边界

治理模型

运营模型

openDesk Edu 被设计为自托管运营的平台。平台提供：参考 Helm chart、values 文件和文档。机构负责：部署平台、运营基础设施、管理用户账户、监控和支持、升级和维护。

这是共同责任模式，旨在保持机构自主权和数据主权。

组织角色

角色	职责	典型团队
平台所有者	战略方向、预算、总体责任	IT 领导、CIO
平台运营者	日常运营、监控、事件响应	基础设施团队、DevOps
服务管理员	单个服务的配置和管理	应用团队
联邦管理员	身份联邦、SAML/OIDC 配置、IdP 连接	IAM 团队
存储管理员	存储配置、Ceph/NFS、备份配置	存储团队
安全官员	安全策略、合规性、漏洞管理	安全团队
数据库管理员	数据库调优、备份、复制	DBA 团队

注意： 在较小的机构中，多个角色可能由一个人或一个团队兼任。在较大的机构中，每个角色可能有专门的专家和子团队。

决策流程

所有对平台的更改都遵循结构化的决策流程：

提议： 通过工单、问题或变更请求提出更改
影响评估： 评估对用户、服务、基础设施和依赖关系的影响
可行性研究： 验证技术可行性和资源需求
批准： 由适当的权限机构批准（根据影响和风险）
规划： 制定实施计划、回滚计划和时间表
沟通： 通知利益相关者更改及其影响
实施： 在维护窗口期内实施更改（如需要）
验证： 测试和验证实施
文档： 更新相关文档
关闭： 完成后续的后实施审查

批准矩阵

更改类型	需要的批准	前置时间	维护窗口
紧急修复（安全、故障）	运营者 + 安全官员	0–1 小时	根据需要
轻微更改（配置、小版本更新）	运营者	1–3 天	可选
标准更改（新服务、大版本更新）	所有者 + 运营者	1–2 周	需要
重大更改（架构、Kubernetes 版本）	运营者 + 所有者	2–4 周	需要，延长

变更管理（基于 ITIL）

更改分类

分类	描述	风险	示例
标准	预批准、低风险、常规更改	低	配置更改
普通	需要批准、中等风险	中	新服务部署
紧急	紧急、高影响的更改以解决事件	高	安全补丁

工作流程 — 标准

在变更管理系统中记录更改
选择预批准的模板
在计划时间实施更改
记录为已完成

工作流程 — 普通

创建 RFC（变更请求）
变更咨询委员会（CAB）审查
批准或拒绝
如果批准：创建实施计划和时间表
在维护窗口期内实施
验证和记录
CAB 审查（后实施）

工作流程 — 紧急

识别事件，需要紧急修复
计划和测试修复（如果可能，在 staging 中）
紧急变更咨询委员会（ECAB）审查和批准
实施修复
与完整 CAB 进行后实施审查
追溯应用标准变更流程

维护窗口

计划维护： 每周或每两周，2–4 小时，在业务时间之外（02:00–06:00）
延长维护： 每季度或根据需要，4–12 小时，周末（周六 02:00–14:00）
紧急维护： 根据需要，持续时间不定，立即或尽快

升级和生命周期管理

升级策略

组件	升级频率	流程	停机时间	回滚
Kubernetes	每季度或根据需要	蓝绿或滚动更新	需要	需要（快照）
Helm chart	每个版本	滚动更新	可选	可选
应用服务	每个版本	滚动更新	可选	可选
数据库	根据需要	蓝绿	需要	需要（转储）
Ceph 存储	根据需要	滚动更新	无（有复制）	基于快照
证书	每季度	自动（cert-manager）	无	自动

策略：

Kubernetes: N-2 支持策略
应用服务：遵循上游支持策略
数据库：所有服务使用相同主版本
依赖项：定期更新以获取安全补丁

安全管理

漏洞管理

扫描： 容器镜像（Trivy、Kubescape）、依赖项（npm audit、OWASP）、配置（kube-bench）、网络（Nmap）
修复： 严重（24 小时）、高（7 天）、中等（30 天）、低（90 天）
豁免： 记录并设置到期日期

访问控制

访问审查：每季度
审计日志：为 Kubernetes API、Keycloak 和关键服务启用
保留期限：至少 1 年（合规性要求可能更长）
完整性保护：只读存储，与应用数据分离

合规性

将合规性要求映射到平台控制
定期进行合规性评估
保存合规性状态和证据文档
解决差距和不合规发现
向审计师提供合规性报告

备份和灾难恢复治理

备份策略

频率： 数据库每日，其他数据每周
保留： 30 天每日备份，12 个月每周备份，7 年每月备份
测试： 每季度从备份恢复以验证完整性
加密： 所有备份都使用单独的备份密钥加密
异地： 所有备份存储在异地
不可变： 关键备份为 WORM（一次写入，多次读取）

恢复目标

层级	RTO（恢复时间目标）	RPO（恢复点目标）
0	未定义（试点）	24 小时
1	4–8 小时（关键） / 24 小时（全部）	1 小时
2	1–4 小时（关键） / 8–24 小时（全部）	15 分钟
3	< 1 小时（关键） / 4–12 小时（全部）	5 分钟

灾难恢复计划

事件声明，激活灾难恢复计划
评估事件的影响和范围
按优先级顺序恢复服务
验证和测试已恢复的服务
通知用户和利益相关者服务已恢复
进行事件后审查

事件管理

严重程度等级

严重程度	影响	响应时间	升级
SEV-1	完全服务中断/数据丢失/安全漏洞	立即	24/7，全员
SEV-2	严重服务降级/多个服务受影响	15 分钟	扩展团队
SEV-3	輕微服务降级/单个服务受影响	1 小时	标准团队
SEV-4	界面问题/非关键 Bug	4 小时	个人贡献者

事件响应流程

检测（监控、用户报告）
分诊（严重程度、影响、范围）
声明（严重程度、分配责任人）
升级（团队、利益相关者）
调查（识别根本原因）
缓解（临时修复或解决方案）
解决（永久修复）
恢复（服务完全正常运行）
事后分析（文档、识别改进措施）
关闭（完成所有后续操作）

沟通

内部： 团队聊天、事件管理系统
外部（用户）： 状态页面显示当前事件状态和预计解决时间
利益相关者： SEV-1 和 SEV-2 事件的定期电邮/电话更新
事件后： SEV-1 和 SEV-2 的事后分析报告

文档和知识管理

架构： 系统架构、服务依赖关系、数据流
运营： 部署、配置、故障排除、维护程序
安全： 安全策略、流程、标准
合规： 合规要求、控制、证据
变更： 变更请求模板、批准流程、CAB 会议记录
事件： 事件报告、事后分析、经验教训
用户： 用户指南、FAQ、教程

标准：

保存在 Git 版本控制中
使用 Markdown 格式
与每个变更一起审查
保持与当前状态同步
使用图表和示例来阐明复杂概念

社区和贡献

openDesk Edu 是一个社区驱动的项目。欢迎以下形式的贡献：

通过 GitHub Issues 提交 Bug 报告和功能请求
改进文档
通过 Pull Request 贡献代码
在 Matrix 上提供社区支持 (#opendesk-ce-public:matrix.opendesk-edu.org)
发表演讲、博客文章和会议报告

贡献流程：

Fork 仓库并创建功能分支
使用清晰的提交信息提交更改
打开带有描述和上下文的 Pull Request
与维护者讨论更改
解决反馈并进行更新
合并后通过所有测试

维护者指南：

及时回复 Issue 和 PR
提供清晰和建设性的反馈
对所有贡献者保持欢迎和包容
遵循行为准则
与社区达成共识后做出发布决策

总结

这份伴随文档为您提供了规划和运营成功的 openDesk Edu 部署所需的工具：

容量分析： 帮助您为基础设施定尺寸
治理模型： 描述如何在整个生命周期中管理平台

下一步：

规划部署：使用层级描述和服务表来估算资源需求
设计治理：采用并适应流程到您的机构
部署：使用系统架构概览作为指导
监控：设置可观测性和告警
迭代：定期回顾容量和治理，并进行改进

容量规划关注的是准备。治理关注的是可持续性。它们共同确保您的 openDesk Edu 平台能够与您的机构一起发展，并年复一年地保持可靠运行。

容量部分帮助您在部署前为基础设施定尺寸。治理部分描述了部署后如何保持平台持续运行——升级周期、生命周期管理、变更控制和组织角色。

容量分析

定尺寸的理念

部署层级

层级	活跃并发用户	总用户数	集群节点	典型 CPU	典型内存	典型存储
层级 0（试点）	0–500	2,000	1–2	4–8 vCPU	16–32 GB	500 GB–2 TB
层级 1（学校）	500–5,000	2,000–10,000	3–5	16–32 vCPU	64–128 GB	2–10 TB
层级 2（大学）	5,000–50,000	10,000–100,000	8–15	64–256 vCPU	256–1024 GB	10–100 TB
层级 3（大型大学/联盟）	50,000+	100,000+	20+	512+ vCPU	2+ TB	100+ TB

服务特定的容量需求

身份与认证

服务	CPU	内存	存储	备注
Keycloak	0.5–2 vCPU	1–4 GB	5–10 GB	按活跃会话扩展
Shibboleth SP	0.25–1 vCPU	0.5–2 GB	1–2 GB	每个 SAML 服务一个实例
Nubus	0.5–2 vCPU	1–4 GB	5–10 GB	门户和 IAM 层

文件存储与协作

服务	CPU	内存	存储	备注
Nextcloud (应用)	2–8 vCPU	4–16 GB	1–5 GB	文件在 PV 上
Nextcloud (数据库)	2–4 vCPU	4–8 GB	20–50 GB	元数据
Nextcloud (Redis)	0.5–1 vCPU	1–2 GB	1 GB	缓存
OpenCloud	1–4 vCPU	2–8 GB	5–10 GB	比 Nextcloud 更轻量

存储增长公式: 总计 ≈ 用户数 × 平均存储 × 1.7（版本控制 + 开销）

邮件与协作套件

服务	CPU	内存	存储	最大邮箱数	备注
OX App Suite	4–16 vCPU	8–32 GB	50–200 GB	10k–100k	企业级协作套件
SOGo	2–4 vCPU	4–8 GB	20–50 GB	5k–25k	轻量级 Webmail
Grommunio	4–8 vCPU	8–16 GB	30–100 GB	5k–50k	支持 ActiveSync
MariaDB	4–16 vCPU	8–32 GB	50–200 GB	–	协作套件数据库

学习管理系统

服务	CPU	内存	存储	最大并发	备注
Moodle	2–8 vCPU	4–16 GB	20–100 GB	500–5k	LAMP 架构
Moodle (数据库)	4–16 vCPU	8–32 GB	50–200 GB	–	建议 PostgreSQL
ILIAS	4–16 vCPU	8–32 GB	50–200 GB	1k–10k	基于 Java
ILIAS (数据库)	4–16 vCPU	8–32 GB	100–500 GB	–	Java 数据库开销

视频会议

服务	CPU	内存	带宽	最大并发	备注
Jitsi	2–8 vCPU 每场会议	4–16 GB	1–8 Mbps/参与者	50–100 每个实例	WebRTC 转码
BigBlueButton	4–16 vCPU	8–32 GB	0.5–2 Mbps/参与者	100–200 每个实例	建议使用 GPU 转码

协作与生产力

服务	CPU	内存	存储	备注
Collabora	2–8 vCPU	4–16 GB	1–5 GB	WOPI 实例
Etherpad	0.5–2 vCPU	1–4 GB	1–5 GB	轻量级
CryptPad	1–4 vCPU	2–8 GB	5–10 GB	端到端加密
XWiki	2–4 vCPU	4–8 GB	10–50 GB	Java CMS
BookStack	1–2 vCPU	2–4 GB	5–20 GB	轻量级 Wiki
OpenProject	2–4 vCPU	4–8 GB	10–50 GB	Ruby 项目管理

实时通信

服务	CPU	内存	存储	最大并发	备注
Element/Matrix	0.5–2 vCPU	1–4 GB	5–10 GB	500–5k	Synapse 服务器
Zammad	2–4 vCPU	4–8 GB	10–50 GB	500–2k	工单系统

基础设施

服务	CPU	内存	存储	备注
PostgreSQL	2–8 vCPU	4–16 GB	20–100 GB	每个实例
MariaDB	2–8 vCPU	4–16 GB	20–100 GB	每个实例
Redis	0.5–2 vCPU	1–4 GB	1–5 GB	每个实例

存储规划

公式： 总存储 = (用户数据 × 增长因子) + 服务开销 + 备份开销 + 缓冲

用户数据 = N × 平均存储 × (1 + 年增长率 × 年数)
服务开销 ≈ 用户数据的 15%
备份开销 ≈ 用户数据的 250%（每日 2 次 + 每周 1 次）
缓冲 = 总计的 20%

简化估算： 每个用户 40–60 GB（包含备份和开销，计算 3 年）

存储类别：

类别	用例	访问模式	成本	性能
本地 SSD	数据库	频繁随机读写	高	非常高
Ceph/RBD	持久卷	混合	中等	高
CephFS	共享文件	共享读写	中等	中等
NFS	共享配置	频繁读，偶尔写	低	中等
S3	备份/归档	很少访问，顺序读	低	低

网络规划

外部带宽

活动	每个用户带宽
基础浏览	100–500 kbps
文档编辑	200–1000 kbps
视频会议（Jitsi）	500–8000 kbps
视频会议（BigBlueButton）	0.5–2 Mbps
视频播放	1–5 Mbps
文件上传/下载	1–10 Mbps

公式： 总带宽 = 峰值用户数 × 平均带宽 × 峰值因子（1.5–3.0）

层级 2 示例（5,000 用户）： 5,000 × 0.5 Mbps × 2 = 5 Gbps 出口带宽

Kubernetes 集群开销

组件	CPU	内存	存储	备注
etcd	2–4 vCPU	8–16 GB	20–50 GB	建议 3 或 5 节点 HA
控制平面	2–4 vCPU	4–8 GB	5–10 GB	每个控制平面节点
节点操作系统	0.5 vCPU 每个 Worker	1–2 GB 每个 Worker	20–50 GB 每个 Worker	操作系统
CNI	0.5 vCPU 每个节点	1 GB 每个节点	–	Calico/Flannel
Prometheus	2–4 vCPU	8–16 GB	50–100 GB	按集群大小扩展
Loki	2–8 vCPU	8–32 GB	100–500 GB	按日志量扩展
Traefik	1–2 vCPU	2-4 GB	1 GB	每个 Ingress

总开销： 10–20 vCPU, 20–40 GB RAM（不包括节点操作系统）

扩展策略

水平扩展

无状态服务： 添加 Pod 副本
有状态服务： 添加读副本或分片
存储： 添加 Ceph OSD 或 NFS 服务器
Ingress： 添加 Ingress 控制器

HPA 示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nextcloud
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nextcloud
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

垂直扩展

增加每个 Pod 的 vCPU 和内存
使用更大的节点规格
分离读写工作负载到不同节点

集群自动扩展

扩展上限： 当 Pod 无法被调度时
扩展下限： 当节点资源使用率过低时（默认 10 分钟）
最小/最大节点数： 设置边界

治理模型

运营模型

这是共同责任模式，旨在保持机构自主权和数据主权。

组织角色

角色	职责	典型团队
平台所有者	战略方向、预算、总体责任	IT 领导、CIO
平台运营者	日常运营、监控、事件响应	基础设施团队、DevOps
服务管理员	单个服务的配置和管理	应用团队
联邦管理员	身份联邦、SAML/OIDC 配置、IdP 连接	IAM 团队
存储管理员	存储配置、Ceph/NFS、备份配置	存储团队
安全官员	安全策略、合规性、漏洞管理	安全团队
数据库管理员	数据库调优、备份、复制	DBA 团队

注意： 在较小的机构中，多个角色可能由一个人或一个团队兼任。在较大的机构中，每个角色可能有专门的专家和子团队。

决策流程

所有对平台的更改都遵循结构化的决策流程：

提议： 通过工单、问题或变更请求提出更改
影响评估： 评估对用户、服务、基础设施和依赖关系的影响
可行性研究： 验证技术可行性和资源需求
批准： 由适当的权限机构批准（根据影响和风险）
规划： 制定实施计划、回滚计划和时间表
沟通： 通知利益相关者更改及其影响
实施： 在维护窗口期内实施更改（如需要）
验证： 测试和验证实施
文档： 更新相关文档
关闭： 完成后续的后实施审查

批准矩阵

更改类型	需要的批准	前置时间	维护窗口
紧急修复（安全、故障）	运营者 + 安全官员	0–1 小时	根据需要
轻微更改（配置、小版本更新）	运营者	1–3 天	可选
标准更改（新服务、大版本更新）	所有者 + 运营者	1–2 周	需要
重大更改（架构、Kubernetes 版本）	运营者 + 所有者	2–4 周	需要，延长

变更管理（基于 ITIL）

更改分类

分类	描述	风险	示例
标准	预批准、低风险、常规更改	低	配置更改
普通	需要批准、中等风险	中	新服务部署
紧急	紧急、高影响的更改以解决事件	高	安全补丁

工作流程 — 标准

在变更管理系统中记录更改
选择预批准的模板
在计划时间实施更改
记录为已完成

工作流程 — 普通

创建 RFC（变更请求）
变更咨询委员会（CAB）审查
批准或拒绝
如果批准：创建实施计划和时间表
在维护窗口期内实施
验证和记录
CAB 审查（后实施）

工作流程 — 紧急

识别事件，需要紧急修复
计划和测试修复（如果可能，在 staging 中）
紧急变更咨询委员会（ECAB）审查和批准
实施修复
与完整 CAB 进行后实施审查
追溯应用标准变更流程

维护窗口

计划维护： 每周或每两周，2–4 小时，在业务时间之外（02:00–06:00）
延长维护： 每季度或根据需要，4–12 小时，周末（周六 02:00–14:00）
紧急维护： 根据需要，持续时间不定，立即或尽快

升级和生命周期管理

升级策略

组件	升级频率	流程	停机时间	回滚
Kubernetes	每季度或根据需要	蓝绿或滚动更新	需要	需要（快照）
Helm chart	每个版本	滚动更新	可选	可选
应用服务	每个版本	滚动更新	可选	可选
数据库	根据需要	蓝绿	需要	需要（转储）
Ceph 存储	根据需要	滚动更新	无（有复制）	基于快照
证书	每季度	自动（cert-manager）	无	自动

策略：

Kubernetes: N-2 支持策略
应用服务：遵循上游支持策略
数据库：所有服务使用相同主版本
依赖项：定期更新以获取安全补丁

安全管理

漏洞管理

扫描： 容器镜像（Trivy、Kubescape）、依赖项（npm audit、OWASP）、配置（kube-bench）、网络（Nmap）
修复： 严重（24 小时）、高（7 天）、中等（30 天）、低（90 天）
豁免： 记录并设置到期日期

访问控制

访问审查：每季度
审计日志：为 Kubernetes API、Keycloak 和关键服务启用
保留期限：至少 1 年（合规性要求可能更长）
完整性保护：只读存储，与应用数据分离

合规性

将合规性要求映射到平台控制
定期进行合规性评估
保存合规性状态和证据文档
解决差距和不合规发现
向审计师提供合规性报告

备份和灾难恢复治理

备份策略

频率： 数据库每日，其他数据每周
保留： 30 天每日备份，12 个月每周备份，7 年每月备份
测试： 每季度从备份恢复以验证完整性
加密： 所有备份都使用单独的备份密钥加密
异地： 所有备份存储在异地
不可变： 关键备份为 WORM（一次写入，多次读取）

恢复目标

层级	RTO（恢复时间目标）	RPO（恢复点目标）
0	未定义（试点）	24 小时
1	4–8 小时（关键） / 24 小时（全部）	1 小时
2	1–4 小时（关键） / 8–24 小时（全部）	15 分钟
3	< 1 小时（关键） / 4–12 小时（全部）	5 分钟

灾难恢复计划

事件声明，激活灾难恢复计划
评估事件的影响和范围
按优先级顺序恢复服务
验证和测试已恢复的服务
通知用户和利益相关者服务已恢复
进行事件后审查

事件管理

严重程度等级

严重程度	影响	响应时间	升级
SEV-1	完全服务中断/数据丢失/安全漏洞	立即	24/7，全员
SEV-2	严重服务降级/多个服务受影响	15 分钟	扩展团队
SEV-3	輕微服务降级/单个服务受影响	1 小时	标准团队
SEV-4	界面问题/非关键 Bug	4 小时	个人贡献者

事件响应流程

检测（监控、用户报告）
分诊（严重程度、影响、范围）
声明（严重程度、分配责任人）
升级（团队、利益相关者）
调查（识别根本原因）
缓解（临时修复或解决方案）
解决（永久修复）
恢复（服务完全正常运行）
事后分析（文档、识别改进措施）
关闭（完成所有后续操作）

沟通

内部： 团队聊天、事件管理系统
外部（用户）： 状态页面显示当前事件状态和预计解决时间
利益相关者： SEV-1 和 SEV-2 事件的定期电邮/电话更新
事件后： SEV-1 和 SEV-2 的事后分析报告

文档和知识管理

架构： 系统架构、服务依赖关系、数据流
运营： 部署、配置、故障排除、维护程序
安全： 安全策略、流程、标准
合规： 合规要求、控制、证据
变更： 变更请求模板、批准流程、CAB 会议记录
事件： 事件报告、事后分析、经验教训
用户： 用户指南、FAQ、教程

标准：

保存在 Git 版本控制中
使用 Markdown 格式
与每个变更一起审查
保持与当前状态同步
使用图表和示例来阐明复杂概念

社区和贡献

openDesk Edu 是一个社区驱动的项目。欢迎以下形式的贡献：

通过 GitHub Issues 提交 Bug 报告和功能请求
改进文档
通过 Pull Request 贡献代码
在 Matrix 上提供社区支持 (#opendesk-ce-public:matrix.opendesk-edu.org)
发表演讲、博客文章和会议报告

贡献流程：

Fork 仓库并创建功能分支
使用清晰的提交信息提交更改
打开带有描述和上下文的 Pull Request
与维护者讨论更改
解决反馈并进行更新
合并后通过所有测试

维护者指南：

及时回复 Issue 和 PR
提供清晰和建设性的反馈
对所有贡献者保持欢迎和包容
遵循行为准则
与社区达成共识后做出发布决策

总结

这份伴随文档为您提供了规划和运营成功的 openDesk Edu 部署所需的工具：

容量分析： 帮助您为基础设施定尺寸
治理模型： 描述如何在整个生命周期中管理平台

下一步：

规划部署：使用层级描述和服务表来估算资源需求
设计治理：采用并适应流程到您的机构
部署：使用系统架构概览作为指导
监控：设置可观测性和告警
迭代：定期回顾容量和治理，并进行改进

容量规划关注的是准备。治理关注的是可持续性。它们共同确保您的 openDesk Edu 平台能够与您的机构一起发展，并年复一年地保持可靠运行。

容量分析

定尺寸的理念

部署层级

服务特定的容量需求

身份与认证

文件存储与协作

邮件与协作套件

学习管理系统

视频会议

协作与生产力

实时通信

基础设施

存储规划

网络规划

外部带宽

Kubernetes 集群开销

扩展策略

水平扩展

垂直扩展

集群自动扩展

治理模型

运营模型

组织角色

决策流程

批准矩阵

变更管理（基于 ITIL）

更改分类

工作流程 — 标准

工作流程 — 普通

工作流程 — 紧急

维护窗口

升级和生命周期管理

升级策略

安全管理

漏洞管理

访问控制

合规性

备份和灾难恢复治理

备份策略

恢复目标

灾难恢复计划

事件管理

严重程度等级

事件响应流程

沟通

文档和知识管理

社区和贡献

总结

Share this article

Related Posts

身份与认证架构

网络和流量架构

安全架构

容量分析

定尺寸的理念

部署层级

服务特定的容量需求

身份与认证

文件存储与协作

邮件与协作套件

学习管理系统

视频会议

协作与生产力

实时通信

基础设施

存储规划

网络规划

外部带宽

Kubernetes 集群开销

扩展策略

水平扩展

垂直扩展

集群自动扩展

治理模型

运营模型

组织角色

决策流程

批准矩阵

变更管理（基于 ITIL）

更改分类