【项目介绍】企业级运维管理平台

【项目介绍】企业级运维管理平台

二月 03, 2026

一站式运维管理平台,整合基础设施管理、部署发布、变更审批与配置管理,支撑百人规模研发团队的日常运维需求。

目录


项目背景

在一家快速发展的金融科技公司担任运维开发工程师,随着业务规模扩张,我们面临着日益复杂的基础设施管理挑战:多云环境(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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
┌─────────────────────────────────────────────────────────────┐
│ 前端 (Vue 3) │
└─────────────────────────────┬───────────────────────────────┘

┌─────────────────────────────▼───────────────────────────────┐
│ AWS ELB / 反向代理 │
└─────────────────────────────┬───────────────────────────────┘

┌───────────────────┼───────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ uWSGI │ │ Celery │ │ Celery │
│ Worker │ │ Worker │ │ Beat │
│ (Django) │ │ (异步任务) │ │ (定时调度) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└───────────────────┼───────────────────┘

┌───────────────────┼───────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ MySQL │ │ Redis │ │ Flower │
│ (主库) │ │ (缓存/队列)│ │ (任务监控) │
└───────────┘ └───────────┘ └───────────┘

外部服务集成
┌───────────────────┼───────────────────┐
│ │ │ │ │
AWS EC2 Jenkins Nacos Consul Slack
GCP VM Pipeline Config Discovery 通知

分层设计

层级 组件 职责
接入层 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
2
3
4
5
6
7
8
# DB 0: 通用缓存(用户登录阻止、速率限制等)
REDIS_DB_CACHE = 0

# DB 1: Django 缓存(ORM 查询缓存、DRF 响应缓存)
REDIS_DB_DJANGO = 1

# DB 2: Celery Broker & Results
REDIS_DB_CELERY = 2

Docker 容器化部署

生产环境采用 Docker Compose 编排,包含以下服务:

1
2
3
4
5
services:
web: # uWSGI 服务器,处理 HTTP 请求
worker: # Celery Worker,执行异步任务
beat: # Celery Beat,定时任务调度
flower: # Celery Flower,任务监控界面

这种设计便于水平扩展:流量高峰时可以增加 web 实例,部署密集期可以增加 worker 实例。


核心功能模块

CMDB:基础设施统一管理

解决的问题:资源信息分散,缺乏统一视图

核心功能

  • 多云资源自动同步:定时任务从 AWS/GCP API 拉取资源信息,自动更新 CMDB
  • 环境与服务建模:Environment → Service → Process → EC2 四层关系建模
  • 资源关系可视化:服务与实例、负载均衡器的关联一目了然

技术实现亮点

多云资源同步采用 Celery 定时任务实现,支持增量更新:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@shared_task
def cmdb_ec2_todb(aws_id=None):
"""同步 AWS EC2 实例到数据库

流程:
1. 调用 boto3 describe_instances 获取实例列表
2. 对比 CMDB 现有数据,识别新增/变更/删除
3. 批量更新数据库
4. 同步实例标签到 CMDB 字段
"""
for aws_config in AWS_ACCOUNTS:
instances = get_ec2_instances(aws_config)
for instance in instances:
CmdbEc2.objects.update_or_create(
instance_id=instance['InstanceId'],
defaults={
'name': get_tag(instance, 'Name'),
'private_ip_address': instance['PrivateIpAddress'],
'instance_type': instance['InstanceType'],
# ... 更多字段
}
)

数据模型设计

1
2
3
4
CmdbEnvironments (环境)
└── CmdbEnvironmentService (环境-服务关联)
└── CmdbEnvironmentServiceEc2 (实例组)
└── CmdbEc2 (EC2 实例)

Ticket:变更与审批流程

解决的问题:变更操作缺乏审批和审计

核心功能

  • 工单状态机:Draft → Pending → Approved → Running → Completed
  • 流程模板化:预定义部署、回滚、配置变更等流程模板
  • Jenkins 集成:工单审批通过后自动触发 Jenkins Pipeline

技术实现亮点
工单系统采用”工单 + 流程 + 任务”三层设计:

1
2
3
4
5
6
7
Tickets (工单)
├── TicketDetail (工单详情,包含 JSON 格式的参数)
└── TicketRecord (执行记录,关联流程步骤)

TicketFlow (流程模板)
└── TicketFlowTask (流程步骤)
└── TicketFlowTaskParam (步骤参数定义)

这种设计的好处是流程复用:同一个”服务部署”流程可以被多个工单引用,流程变更只需修改一处。

Jenkins 回调机制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Jenkins Pipeline 完成后回调 ops-system
@api_view(['POST'])
def jenkins_callback(request):
"""Jenkins 构建完成回调

1. 根据 build_number 找到对应的 TicketRecord
2. 更新步骤状态(Finished/Failed)
3. 如果配置了自动继续,触发下一步骤
"""
build_number = request.data.get('build_number')
status = request.data.get('status')

record = TicketRecord.objects.get(jenkins_number=build_number)
record.status = 'Finished' if status == 'SUCCESS' else 'Failed'
record.save()

if record.ticket_flow_task.is_next:
trigger_next_step(record)

CD2:现代化部署系统

解决的问题:部署流程不规范,缺乏统一的发布管理

核心功能

  • 插件化任务架构:部署、配置发布、进程管理等操作均为可插拔模块
  • 多部署类型支持:EC2 滚动部署、EKS 滚动更新、配置热加载
  • LB 流量管理:部署前自动从负载均衡器卸载,部署后自动注册

技术实现亮点

CD2 的核心是模块注册表设计,每种部署类型注册为独立模块:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# cd2/logic.py
module = {
"deploy": {
"record_runtime": task_deploy.get_runtime_info,
"record_pre_runtime": task_deploy.get_pre_runtime_info,
"action": task_deploy.flow_action,
"jenkins_callback": task_deploy.jenkins_callback,
},
"pm_deploy_all": {
"action": task_service_configfile.flow_action_deploy,
# ...
},
"batch_deploy": {
"action": task_batch_deploy.flow_action,
# ...
},
# ... 更多模块
}

支持的部署类型

模块 说明 场景
deploy 代码部署 服务版本更新
pm_deploy_all 配置全量部署 配置文件变更
pm_reload_all 配置热加载 不重启服务的配置更新
batch_deploy 批量部署 多实例并行部署
ncm_deploy 网络配置部署 网络设备配置变更
process_manage 进程管理 服务启停、重启

User:统一认证中心

解决的问题:多系统账号割裂,权限管理混乱

核心功能

  • Keycloak OIDC 集成:与公司统一身份平台对接
  • LDAP 自动同步:用户信息从 LDAP 自动同步
  • Token 即时阻止:登出后 Token 立即失效

技术实现亮点
多认证后端的优雅降级设计:

1
2
3
4
AUTHENTICATION_BACKENDS = (
'utils.keycloak.MyOIDCBackend', # 主认证:Keycloak OIDC
'django.contrib.auth.backends.ModelBackend', # 降级:本地数据库
)

Token 阻止机制(解决 JWT 无法即时撤销的问题):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
def set_block(username):
"""阻止用户登录(8小时有效)

场景:用户登出、账号禁用、安全事件
"""
redis_client.set(f"block:{username}", 1, ex=8*3600)

def check_is_block(username):
"""检查用户是否被阻止"""
return redis_client.exists(f"block:{username}")

# 在认证中间件中检查
class TokenAuthenticationMiddleware:
def authenticate(self, request):
token = get_token_from_header(request)
payload = decode_token(token)

if check_is_block(payload['username']):
raise AuthenticationFailed('Token has been revoked')

return payload

Config:配置管理

解决的问题:配置散落各处,版本难以追踪

核心功能

  • Nacos 集成:配置集中存储,支持动态推送
  • 配置版本管理:每次变更记录版本,支持回滚
  • 配置审计:记录配置变更的操作人、时间、变更内容

数据模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class ConfigContext(ModelCreate):
"""配置上下文(配置项的分组)"""
name = CharField(max_length=255)
key = CharField(max_length=255, unique=True)

class ConfigInfo(ModelCreate):
"""配置项"""
context = ForeignKey(ConfigContext)
key = CharField(max_length=255)
value = TextField()
version = IntegerField(default=1)

class Changes(ModelCreate):
"""变更审计日志"""
model_name = CharField(max_length=64)
change_type = CharField(choices=['create', 'update', 'delete'])
before_value = TextField()
after_value = TextField()

架构演进历程

三年的迭代过程中,ops-system 经历了多次重要的架构升级。这些经历既是踩坑的教训,也是技术成长的见证。

部署系统重构:cd/ → cd2/

旧系统(cd/)的问题

早期的部署系统设计得比较”简单粗暴”:

  • 代码部署、配置部署、进程管理耦合在一起
  • 每种新的部署类型都需要修改核心代码
  • 流程控制逻辑散落各处,难以维护
  • 与 Jenkins 的集成是”硬编码”的

重构思路

  1. 解耦:将不同类型的部署操作拆分为独立模块
  2. 通用化:抽象出 Flow → Step → Record 的通用模型
  3. 插件化:新部署类型只需注册模块,无需修改框架代码

新旧对比

方面 cd/(旧) cd2/(新)
架构 单体,紧耦合 模块化,松耦合
扩展性 低,需改核心代码 高,注册新模块即可
参数管理 固定 schema 灵活的 JSON schema
流程控制 线性 支持条件分支、并行
错误恢复 有限 支持重试、回滚

迁移策略

我们采用了渐进式替换的方式:

  1. 新功能全部在 cd2/ 中开发
  2. 旧系统(cd/)保持运行,确保现有流程不中断
  3. 逐步将存量工单迁移到 cd2/
  4. 最终标记 cd/ 为 deprecated

教训:技术债务越早还越好。cd/ 在早期满足了业务需求,但随着复杂度增加,维护成本急剧上升。如果一开始就采用模块化设计,后期可以节省大量重构成本。

认证体系升级

演进路径:本地账号 → LDAP → Keycloak OIDC

第一阶段:本地账号

最初使用 Django 内置的用户系统,账号密码存储在本地数据库。问题很快暴露:

  • 用户需要记住多套密码
  • 离职员工权限回收不及时
  • 无法与其他系统实现单点登录

第二阶段:LDAP 集成

引入 django-auth-ldap,与公司 LDAP 对接:

1
2
AUTH_LDAP_SERVER_URI = "ldap://ldap.company.com"
AUTH_LDAP_USER_DN_TEMPLATE = "uid=%(user)s,ou=users,dc=company,dc=com"

这解决了账号统一的问题,但 LDAP 是”认证”而非”授权”,权限管理仍然需要在 ops-system 内部维护。

第三阶段:Keycloak OIDC

公司推行统一身份平台(Keycloak),我们改造 ops-system 对接 OIDC:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class MyOIDCBackend(OIDCAuthenticationBackend):
def create_user(self, claims):
"""根据 OIDC claims 创建用户"""
user = AuthUserLDAP.objects.create_user(
username=claims['preferred_username'],
email=claims.get('email', ''),
displayname=claims.get('name', ''),
)
return user

def update_user(self, user, claims):
"""根据 OIDC claims 更新用户信息"""
user.email = claims.get('email', user.email)
user.displayname = claims.get('name', user.displayname)
user.save()
return user

挑战与解决方案

  • 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
2
3
4
5
6
7
8
9
10
11
# cmdb/models.py
class CmdbEnvironmentService(ModelCreate):
cmdb_environments = ForeignKey('cmdb.CmdbEnvironments')
cmdb_service = ForeignKey('cmdb.CmdbService')

# cd2/models.py
class CdFlowRecord(ModelCreate):
# 通过 ContentType 实现与 Task 应用的松耦合
content_type = ForeignKey(ContentType)
object_id = PositiveIntegerField()
content_object = GenericForeignKey()

关键设计理念

关注点分离

ops-system 的核心设计理念是关注点分离

1
CMDB(是什么)→ Ticket(要做什么)→ Task(怎么做)→ 外部服务(执行)
  • CMDB 关注资源的状态:有哪些服务、部署在哪些实例、运行在什么环境
  • Ticket 关注变更的流程:谁发起、谁审批、什么时候执行
  • Task 关注执行的细节:调用哪个 Jenkins Job、传递什么参数

这种设计的好处是变更影响最小化

  • 新增资源类型?只需修改 CMDB
  • 新增审批流程?只需修改 Ticket
  • 新增部署方式?只需修改 Task

异步优先

耗时操作一律走 Celery 异步任务:

1
2
3
4
5
6
7
8
9
# 同步:用户体验差
def deploy_sync(request):
result = jenkins_build(job_name, params) # 可能等待5分钟
return Response({'result': result})

# 异步:立即返回
def deploy_async(request):
task = jenkins_build.delay(job_name, params) # 立即返回
return Response({'task_id': task.id})

异步任务的好处:

  • 用户不需要等待耗时操作完成
  • 任务失败可以自动重试
  • 任务进度可以实时查询

多租户与环境隔离

ops-system 支持多环境(Dev/Fat/Prod)和多业务线的隔离:

1
2
3
4
5
6
class CmdbEnvironmentService(ModelCreate):
cmdb_environments = ForeignKey(CmdbEnvironments) # 环境隔离
cmdb_service = ForeignKey(CmdbService)

class Meta:
unique_together = ('cmdb_environments', 'cmdb_service')

不同环境的服务配置、部署参数、访问权限都是独立的。

可观测性

分层日志

1
2
3
4
5
6
7
8
# ops-system/settings.py
LOGGING = {
'handlers': {
'main': {'filename': '/data/logs/ops-system.log'},
'cd_flow': {'filename': '/data/logs/ops-system.cd_flow.log'},
'commands': {'filename': '/data/logs/ops-system.commands.log'},
},
}
  • ops-system.log:主应用日志
  • ops-system.cd_flow.log:部署流程日志
  • ops-system.commands.log:命令执行日志

任务监控:Celery Flower 提供任务的实时监控界面。

Prometheus 集成:关键指标(部署成功率、任务队列长度等)暴露给 Prometheus。

扩展性设计

插件化任务系统:新增部署类型只需注册模块,无需修改框架代码。

通用模型基类:所有模型继承自通用基类,自动包含创建时间、修改时间、创建人等字段。

1
2
3
4
5
6
7
8
9
10
11
12
13
class ModelCreate(models.Model):
create_time = DateTimeField(auto_now_add=True)
create_user = CharField(max_length=255)

class Meta:
abstract = True

class ModelModify(ModelCreate):
modify_time = DateTimeField(auto_now=True)
modify_user = CharField(max_length=255)

class Meta:
abstract = True

外部集成生态

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 主账户直接访问
client = boto3.client('ec2', aws_access_key_id=ACCESS_KEY)

# 从账户通过 STS AssumeRole
sts_client = boto3.client('sts')
assumed_role = sts_client.assume_role(
RoleArn=f'arn:aws:iam::{account_id}:role/{role_name}',
RoleSessionName='ops-systemSession'
)
credentials = assumed_role['Credentials']

client = boto3.client(
'ec2',
aws_access_key_id=credentials['AccessKeyId'],
aws_secret_access_key=credentials['SecretAccessKey'],
aws_session_token=credentials['SessionToken']
)

Jenkins 深度集成

ops-system 与 Jenkins 的集成不仅是”触发构建”,而是完整的双向通信:

  1. 触发构建:ops-system 调用 Jenkins API 触发 Pipeline
  2. 参数传递:部署参数通过 API 传递给 Jenkins
  3. 状态同步:Jenkins Pipeline 执行过程中的状态实时同步
  4. 回调通知:Pipeline 完成后回调 ops-system,触发后续流程
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Jenkinsfile 中的回调
post {
always {
script {
def status = currentBuild.result ?: 'SUCCESS'
httpRequest(
url: "${ops-system_URL}/api/jenkins/callback/",
httpMode: 'POST',
contentType: 'APPLICATION_JSON',
requestBody: """
{
"build_number": "${BUILD_NUMBER}",
"job_name": "${JOB_NAME}",
"status": "${status}"
}
"""
)
}
}
}

项目成果与数据

用数据说话:

指标 数值 说明
代码规模 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/)早期设计过于简单,导致后期重构成本高
  • 测试覆盖率不足,部分功能依赖人工测试
  • 文档编写滞后于开发进度

对运维平台建设的思考

  1. 从痛点出发:不要为了技术而技术,先搞清楚要解决什么问题
  2. 渐进式迭代:不要试图一步到位,先解决最紧迫的问题
  3. 用户体验很重要:运维平台的用户是运维工程师,要站在他们的角度设计
  4. 自动化不是目的:自动化是手段,提升效率、降低风险才是目的
  5. 保持开放:与外部系统的集成能力决定了平台的价值边界

关于作者:Bob Zou,运维开发工程师,专注于 DevOps 工具链建设和自动化平台开发。擅长 Python/Golang 后端开发,熟悉 AWS/GCP 云平台。

技术栈:Python (Django/DRF)、Golang (Gin)、Vue 3、Docker、Kubernetes、AWS


本文档最后更新于 2026 年 2 月