【项目介绍】企业级运维管理平台
一站式运维管理平台,整合基础设施管理、部署发布、变更审批与配置管理,支撑百人规模研发团队的日常运维需求。
目录
项目背景
在一家快速发展的金融科技公司担任运维开发工程师,随着业务规模扩张,我们面临着日益复杂的基础设施管理挑战:多云环境(AWS 为主、GCP 为辅)、数十个微服务、多套环境(Dev/Fat/Prod)以及分布在不同时区的研发团队。
市面上的开源运维工具(如 CMDB、发布系统)虽然各有特色,但难以满足我们的定制化需求:
- 现有 CMDB 工具与我们的多云架构集成困难
- 部署工具难以与内部 Jenkins Pipeline 深度整合
- 变更管理流程需要与工单系统联动
基于以上考量,我主导开发了 ops-system —— 一个针对公司业务特点量身定制的企业级运维管理平台。平台采用 Django + DRF + Celery 的技术栈,经过三年的迭代,已成为支撑公司日常运维的核心系统。
技术亮点预告:
- 统一认证中心:Keycloak OIDC + LDAP 双后端支持
- 全流程自动化:工单驱动的 Jenkins 集成
- 多云资源管理:AWS/GCP 资源自动发现与同步
- 插件化部署系统:支持 EC2/EKS 多种部署模式
面临的挑战
在启动项目之前,我们做了深入的痛点分析。这些问题不是凭空想象的,而是来自真实的运维事故和效率瓶颈。
基础设施管理分散
症状:运维工程师需要频繁切换 AWS Console、GCP Console、内部 Wiki 来查找资源信息。
根因:缺乏统一的资源视图。EC2 实例信息散落在 AWS 控制台,服务与实例的映射关系只存在于工程师的脑海中。
影响:
- 故障排查时定位实例耗时过长
- 资源利用率无法有效评估
- 新人入职难以快速了解基础设施全貌
部署流程不规范
症状:同一个服务,不同工程师的部署方式可能完全不同。
根因:部署脚本散落在各处,缺乏标准化的发布流程。Jenkins Job 配置混乱,参数传递靠”口口相传”。
影响:
- 发布事故频发,回滚操作手忙脚乱
- 发布记录缺失,出问题时无法追溯
- 灰度发布、蓝绿部署难以实施
变更管理缺乏审计
症状:”这个配置是谁改的?””昨天的变更记录在哪里?”
根因:变更操作通过 SSH 直连服务器执行,没有统一的变更入口和审批流程。
影响:
- 生产事故难以追溯根因
- 合规审计无法满足
- 变更风险无法评估
多系统认证割裂
症状:Jenkins、GitLab、运维工具各有一套账号体系。
根因:早期各系统独立建设,缺乏统一身份管理规划。
影响:
- 账号管理成本高
- 离职员工权限回收不及时
- 安全审计困难
配置管理混乱
症状:”这个服务的配置文件在哪个仓库?用的是哪个版本?”
根因:配置文件散落在 Git 仓库、服务器本地、Nacos 等多处,版本关系不清晰。
影响:
- 配置漂移导致环境不一致
- 配置变更难以灰度发布
- 配置回滚困难
整体架构设计
架构概览
1 | ┌─────────────────────────────────────────────────────────────┐ |
分层设计
| 层级 | 组件 | 职责 |
|---|---|---|
| 接入层 | ELB + uWSGI | 负载均衡、SSL 终止、请求路由 |
| 应用层 | Django + DRF | 业务逻辑、API 接口、权限控制 |
| 任务层 | Celery Worker | 异步任务执行、Jenkins 集成 |
| 调度层 | Celery Beat | 定时任务、资源同步、健康检查 |
| 数据层 | MySQL + Redis | 持久化存储、缓存、消息队列 |
技术选型与考量
为什么选择 Django + DRF?
作为运维开发团队,我们需要快速迭代、稳定可靠的技术栈。Django 的”开箱即用”特性大大加速了开发进度:
- 成熟的 ORM,减少数据库操作代码
- 内置的 Admin 后台,便于数据维护
- DRF 提供标准化的 RESTful API 开发体验
- 丰富的第三方库生态(django-auth-ldap、mozilla-django-oidc 等)
为什么选择 Celery 而非其他队列?
部署任务通常耗时较长(几分钟到几十分钟),同步执行会阻塞 HTTP 请求。我们需要异步任务框架来处理:
- Celery 与 Django 集成成熟,社区活跃
- 支持任务重试、失败回调等高级特性
- Flower 提供开箱即用的任务监控
- Redis 作为 Broker 性能优异且维护简单
Redis 的多用途设计
为了避免不同用途之间的相互影响,我们将 Redis 按功能分配到不同的 DB:
1 | # DB 0: 通用缓存(用户登录阻止、速率限制等) |
Docker 容器化部署
生产环境采用 Docker Compose 编排,包含以下服务:
1 | services: |
这种设计便于水平扩展:流量高峰时可以增加 web 实例,部署密集期可以增加 worker 实例。
核心功能模块
CMDB:基础设施统一管理
解决的问题:资源信息分散,缺乏统一视图
核心功能:
- 多云资源自动同步:定时任务从 AWS/GCP API 拉取资源信息,自动更新 CMDB
- 环境与服务建模:Environment → Service → Process → EC2 四层关系建模
- 资源关系可视化:服务与实例、负载均衡器的关联一目了然
技术实现亮点:
多云资源同步采用 Celery 定时任务实现,支持增量更新:
1 |
|
数据模型设计:
1 | CmdbEnvironments (环境) |
Ticket:变更与审批流程
解决的问题:变更操作缺乏审批和审计
核心功能:
- 工单状态机:Draft → Pending → Approved → Running → Completed
- 流程模板化:预定义部署、回滚、配置变更等流程模板
- Jenkins 集成:工单审批通过后自动触发 Jenkins Pipeline
技术实现亮点:
工单系统采用”工单 + 流程 + 任务”三层设计:
1 | Tickets (工单) |
这种设计的好处是流程复用:同一个”服务部署”流程可以被多个工单引用,流程变更只需修改一处。
Jenkins 回调机制:
1 | # Jenkins Pipeline 完成后回调 ops-system |
CD2:现代化部署系统
解决的问题:部署流程不规范,缺乏统一的发布管理
核心功能:
- 插件化任务架构:部署、配置发布、进程管理等操作均为可插拔模块
- 多部署类型支持:EC2 滚动部署、EKS 滚动更新、配置热加载
- LB 流量管理:部署前自动从负载均衡器卸载,部署后自动注册
技术实现亮点:
CD2 的核心是模块注册表设计,每种部署类型注册为独立模块:
1 | # cd2/logic.py |
支持的部署类型:
| 模块 | 说明 | 场景 |
|---|---|---|
deploy |
代码部署 | 服务版本更新 |
pm_deploy_all |
配置全量部署 | 配置文件变更 |
pm_reload_all |
配置热加载 | 不重启服务的配置更新 |
batch_deploy |
批量部署 | 多实例并行部署 |
ncm_deploy |
网络配置部署 | 网络设备配置变更 |
process_manage |
进程管理 | 服务启停、重启 |
User:统一认证中心
解决的问题:多系统账号割裂,权限管理混乱
核心功能:
- Keycloak OIDC 集成:与公司统一身份平台对接
- LDAP 自动同步:用户信息从 LDAP 自动同步
- Token 即时阻止:登出后 Token 立即失效
技术实现亮点:
多认证后端的优雅降级设计:
1 | AUTHENTICATION_BACKENDS = ( |
Token 阻止机制(解决 JWT 无法即时撤销的问题):
1 | def set_block(username): |
Config:配置管理
解决的问题:配置散落各处,版本难以追踪
核心功能:
- Nacos 集成:配置集中存储,支持动态推送
- 配置版本管理:每次变更记录版本,支持回滚
- 配置审计:记录配置变更的操作人、时间、变更内容
数据模型:
1 | class ConfigContext(ModelCreate): |
架构演进历程
三年的迭代过程中,ops-system 经历了多次重要的架构升级。这些经历既是踩坑的教训,也是技术成长的见证。
部署系统重构:cd/ → cd2/
旧系统(cd/)的问题:
早期的部署系统设计得比较”简单粗暴”:
- 代码部署、配置部署、进程管理耦合在一起
- 每种新的部署类型都需要修改核心代码
- 流程控制逻辑散落各处,难以维护
- 与 Jenkins 的集成是”硬编码”的
重构思路:
- 解耦:将不同类型的部署操作拆分为独立模块
- 通用化:抽象出 Flow → Step → Record 的通用模型
- 插件化:新部署类型只需注册模块,无需修改框架代码
新旧对比:
| 方面 | cd/(旧) | cd2/(新) |
|---|---|---|
| 架构 | 单体,紧耦合 | 模块化,松耦合 |
| 扩展性 | 低,需改核心代码 | 高,注册新模块即可 |
| 参数管理 | 固定 schema | 灵活的 JSON schema |
| 流程控制 | 线性 | 支持条件分支、并行 |
| 错误恢复 | 有限 | 支持重试、回滚 |
迁移策略:
我们采用了渐进式替换的方式:
- 新功能全部在 cd2/ 中开发
- 旧系统(cd/)保持运行,确保现有流程不中断
- 逐步将存量工单迁移到 cd2/
- 最终标记 cd/ 为 deprecated
教训:技术债务越早还越好。cd/ 在早期满足了业务需求,但随着复杂度增加,维护成本急剧上升。如果一开始就采用模块化设计,后期可以节省大量重构成本。
认证体系升级
演进路径:本地账号 → LDAP → Keycloak OIDC
第一阶段:本地账号
最初使用 Django 内置的用户系统,账号密码存储在本地数据库。问题很快暴露:
- 用户需要记住多套密码
- 离职员工权限回收不及时
- 无法与其他系统实现单点登录
第二阶段:LDAP 集成
引入 django-auth-ldap,与公司 LDAP 对接:
1 | AUTH_LDAP_SERVER_URI = "ldap://ldap.company.com" |
这解决了账号统一的问题,但 LDAP 是”认证”而非”授权”,权限管理仍然需要在 ops-system 内部维护。
第三阶段:Keycloak OIDC
公司推行统一身份平台(Keycloak),我们改造 ops-system 对接 OIDC:
1 | class MyOIDCBackend(OIDCAuthenticationBackend): |
挑战与解决方案:
- Token 即时撤销:JWT 是无状态的,无法即时撤销。我们引入 Redis 存储”阻止名单”,每次请求都检查用户是否在名单中。
- 多后端兼容:保留 ModelBackend 作为降级方案,Keycloak 不可用时可以使用本地账号登录。
从单体到模块化
早期结构:
项目初期只有 cmdb/、ticket/、user/ 三个应用,所有功能都往这三个应用里塞。随着功能增加,代码变得臃肿难维护。
模块化拆分:
我们按照”单一职责”原则,将功能拆分为 11 个独立应用:
| 应用 | 职责 | 独立原因 |
|---|---|---|
| cmdb/ | 基础设施管理 | 核心数据模型 |
| ticket/ | 工单流程 | 独立的业务流程 |
| cd2/ | 部署系统 | 复杂度高,独立维护 |
| user/ | 用户认证 | 与其他应用解耦 |
| config/ | 配置管理 | 独立的数据源(Nacos) |
| task/ | 后台任务 | 与部署系统深度耦合 |
| tools/ | 工具集合 | 独立的运维工具 |
| report/ | 报表导出 | 独立的异步任务 |
| api/ | 外部接口 | Webhook、第三方集成 |
| opsjob/ | 运维任务 | 命令行执行 |
| drp/ | 灾难恢复 | 独立的业务域 |
应用间通信:
应用之间通过 Django ORM 的外键关联,避免直接导入其他应用的代码:
1 | # cmdb/models.py |
关键设计理念
关注点分离
ops-system 的核心设计理念是关注点分离:
1 | CMDB(是什么)→ Ticket(要做什么)→ Task(怎么做)→ 外部服务(执行) |
- CMDB 关注资源的状态:有哪些服务、部署在哪些实例、运行在什么环境
- Ticket 关注变更的流程:谁发起、谁审批、什么时候执行
- Task 关注执行的细节:调用哪个 Jenkins Job、传递什么参数
这种设计的好处是变更影响最小化:
- 新增资源类型?只需修改 CMDB
- 新增审批流程?只需修改 Ticket
- 新增部署方式?只需修改 Task
异步优先
耗时操作一律走 Celery 异步任务:
1 | # 同步:用户体验差 |
异步任务的好处:
- 用户不需要等待耗时操作完成
- 任务失败可以自动重试
- 任务进度可以实时查询
多租户与环境隔离
ops-system 支持多环境(Dev/Fat/Prod)和多业务线的隔离:
1 | class CmdbEnvironmentService(ModelCreate): |
不同环境的服务配置、部署参数、访问权限都是独立的。
可观测性
分层日志:
1 | # ops-system/settings.py |
ops-system.log:主应用日志ops-system.cd_flow.log:部署流程日志ops-system.commands.log:命令执行日志
任务监控:Celery Flower 提供任务的实时监控界面。
Prometheus 集成:关键指标(部署成功率、任务队列长度等)暴露给 Prometheus。
扩展性设计
插件化任务系统:新增部署类型只需注册模块,无需修改框架代码。
通用模型基类:所有模型继承自通用基类,自动包含创建时间、修改时间、创建人等字段。
1 | class ModelCreate(models.Model): |
外部集成生态
ops-system 的价值很大程度上来自于与外部系统的深度集成。
集成全景图
| 领域 | 服务 | 集成方式 | 能力 |
|---|---|---|---|
| 云平台 | AWS | boto3 SDK | EC2、ELB、CloudFront、WAF 管理 |
| GCP | google-cloud SDK | Compute Engine 管理 | |
| CI/CD | Jenkins | REST API | 触发构建、获取状态、回调通知 |
| 监控 | Prometheus | HTTP SD | 服务发现、指标采集 |
| AlertManager | API | 告警静默 | |
| 配置 | Nacos | HTTP API | 配置读写、监听变更 |
| Consul | HTTP API | 服务注册、KV 存储 | |
| 通知 | Slack | Webhook | 部署通知、告警推送 |
| Lark | Webhook | 工单通知 | |
| 消息 | Kafka | kafka-python | 事件流 |
AWS 多账户支持
企业级场景通常有多个 AWS 账户(生产、开发、安全等),ops-system 支持跨账户资源管理:
1 | # 主账户直接访问 |
Jenkins 深度集成
ops-system 与 Jenkins 的集成不仅是”触发构建”,而是完整的双向通信:
- 触发构建:ops-system 调用 Jenkins API 触发 Pipeline
- 参数传递:部署参数通过 API 传递给 Jenkins
- 状态同步:Jenkins Pipeline 执行过程中的状态实时同步
- 回调通知:Pipeline 完成后回调 ops-system,触发后续流程
1 | // Jenkinsfile 中的回调 |
项目成果与数据
用数据说话:
| 指标 | 数值 | 说明 |
|---|---|---|
| 代码规模 | 4291+ commits | 三年持续迭代 |
| 应用数量 | 11 个核心应用 | 模块化设计 |
| API 端点 | 100+ | RESTful API 覆盖全功能 |
| 外部集成 | 8+ 服务 | AWS、Jenkins、Nacos 等 |
| 数据模型 | 50+ 模型 | 覆盖完整的运维场景 |
| Celery 任务 | 40+ 任务类型 | 异步化运维操作 |
业务价值:
- 部署操作从手工执行变为工单驱动,变更可追溯率 100%
- 资源信息从分散查找变为统一查询,故障定位效率提升 50%
- 账号体系从多套密码变为 SSO 单点登录,账号管理成本降低 80%
展望与持续优化
ops-system 仍在持续迭代中,以下是近期规划:
权限体系精细化
当前权限控制粒度较粗(基于用户组),计划引入更细粒度的 RBAC 模型:
- 资源级别的权限控制(某用户只能操作特定服务)
- 操作级别的权限控制(某用户只能查看、不能修改)
EKS/云原生深度支持
随着业务向 Kubernetes 迁移,ops-system 需要增强云原生支持:
- EKS 集群资源管理
- Deployment/Pod 生命周期管理
- Helm Chart 版本管理
Salt 配置管理集成
计划集成 Salt 实现更强大的配置管理:
- 配置文件模板化
- 配置推送与验证
- 配置漂移检测
自动化程度持续提升
- 故障自愈:基于告警自动触发修复流程
- 容量规划:基于历史数据预测资源需求
- 成本优化:识别闲置资源,自动缩容建议
总结与反思
项目带来的业务价值
ops-system 不是为了”有一个运维平台”而建设的,而是为了解决真实的运维痛点:
- 将分散的资源信息集中,降低查找成本
- 将手工的部署操作自动化,减少人为错误
- 将口头的变更流程系统化,确保可审计可追溯
技术选型的经验教训
做对的事情:
- 选择成熟稳定的技术栈(Django + Celery),避免踩坑
- 从第一天就考虑认证与权限,避免后期大改
- 采用模块化设计,便于团队协作和后期维护
可以做得更好的事情:
- 部署系统(cd/)早期设计过于简单,导致后期重构成本高
- 测试覆盖率不足,部分功能依赖人工测试
- 文档编写滞后于开发进度
对运维平台建设的思考
- 从痛点出发:不要为了技术而技术,先搞清楚要解决什么问题
- 渐进式迭代:不要试图一步到位,先解决最紧迫的问题
- 用户体验很重要:运维平台的用户是运维工程师,要站在他们的角度设计
- 自动化不是目的:自动化是手段,提升效率、降低风险才是目的
- 保持开放:与外部系统的集成能力决定了平台的价值边界
关于作者:Bob Zou,运维开发工程师,专注于 DevOps 工具链建设和自动化平台开发。擅长 Python/Golang 后端开发,熟悉 AWS/GCP 云平台。
技术栈:Python (Django/DRF)、Golang (Gin)、Vue 3、Docker、Kubernetes、AWS
本文档最后更新于 2026 年 2 月