简介这份资源是一套基于Django框架搭建的轻量级运维平台源码面向具备Python基础、希望了解Web运维系统实现思路的开发者与运维人员可用于学习主机管理、服务监控、日志查看、任务调度、权限控制、资源统计、脚本执行与故障告警等常见模块的落地方式。压缩包共164个文件以39个py源码、38个js脚本、23个css样式、11个html模板及若干图片与字体资源为主整体约3.63MB前后端不分离的结构清晰便于按模块阅读与二次改造。目前已有2718人学习下载。代码中保留了Django项目常见的模型、视图、模板与静态资源组织方式读者可据此理解运维平台从数据建模到页面呈现的完整链路并借鉴审计追踪、知识库等设计思路适合作为课程设计或小型运维工具的参考原型。1. 运维平台不是“又一个后台”Django 这套骨架到底能扛什么活很多团队第一次做运维平台都是从一张 Excel 资产表开始的机器 IP、负责人、到期时间、部署了哪些服务全靠人肉维护。等到机器过百、服务上云、值班轮换这张表就开始翻车——改一处漏三处查一台机器要问三个人。我见过最离谱的一次是某公司上线前发现一台“已下线”的机器还在跑核心任务因为资产表里没人更新状态。这类问题的根子不在人在于没有一个把资产、任务、权限、日志串起来的系统。这份基于 Django 的运维平台源码包解决的就是这个“串起来”的问题。它用 Python 生态里最成熟的 Web 框架做底座把 CMDB 资产管理、批量命令执行、定时任务、操作审计这几块运维日常高频需求做成可运行的模块。适合两类人一是想给团队搭内部工具的后端或运维开发二是拿它当 Django 实战项目练手、顺便理解 DevOps 工具链怎么落地的人。下面我按“这套东西怎么跑起来、每个模块怎么改、哪里容易踩坑”的顺序拆参数和命令都给到能直接抄的程度。2. 把项目跑起来环境、依赖与数据库初始化拿到一个 Django 项目最怕上来就runserver报错一串接一串。我的习惯是先看依赖清单和配置文件把环境对齐再动手。这套平台的目录结构是典型的 Django 多 app 布局核心配置集中在settings.py资产、任务、审计各自独立成 app改起来边界清楚。2.1 依赖安装与虚拟环境隔离Python 项目第一件事永远是虚拟环境别往系统 Python 里装。项目一般会带requirements.txt里面主要是 Django 本体、数据库驱动、任务调度和 SSH 执行相关的库。常见组合是 Django MySQL 驱动 paramiko远程命令 APScheduler 或 celery定时任务具体以包内清单为准。# 创建并激活虚拟环境Python 3.8 以上均可 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖建议加国内镜像加速 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 确认 Django 版本和项目要求对齐 python -c import django; print(django.get_version())这里的关键是版本对齐。Django 3.x 和 4.x 在urls.py的path写法、settings里部分配置项上有差异如果requirements.txt锁了版本就别手动升级。paramiko 负责 SSH 连接它依赖 cryptography在某些老系统上编译会失败遇到报错优先升级 pip 再重装。虚拟环境隔离的意义在于这套平台可能和你机器上其他项目依赖冲突尤其是 Django 版本混装是血泪教训。2.2 数据库配置与迁移运维平台的数据是有状态的资产、任务记录、审计日志都要落库。开发阶段用 SQLite 能跑但真要给团队用建议直接上 MySQL 或 PostgreSQL并发和后续扩展都更稳。配置在settings.py的DATABASES段改完执行迁移。# settings.py 数据库配置示例MySQL DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: ops_platform, # 库名提前建好 USER: ops_user, # 专用账号别用 root PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, # 支持中文和特殊字符 } }# 生成并执行迁移建表 python manage.py makemigrations python manage.py migrate # 创建后台管理员账号用于登录 Django admin python manage.py createsuperuser # 启动开发服务默认 8000 端口 python manage.py runserver 0.0.0.0:8000utf8mb4这个字符集别省运维平台里机器备注、任务描述经常带中文甚至特殊符号用utf8会在某些字符上截断报错。HOST填127.0.0.1而不是localhost能避开一部分 socket 连接问题。迁移命令的顺序不能反makemigrations是根据模型生成迁移文件migrate才是真正建表。如果迁移报“表已存在”多半是之前手动建过表或者迁移记录不一致别硬删库先看django_migrations表里的记录。2.3 静态文件与初始数据Django admin 的样式依赖静态文件开发模式下runserver会自动处理但一旦用 nginx 部署就得先collectstatic。另外这类平台通常带初始化脚本用来灌入默认角色、菜单或示例资产跑之前先看脚本内容别盲目执行。# 收集静态文件到 STATIC_ROOT 指定目录 python manage.py collectstatic --noinput # 如果包内有初始化脚本先看再跑 python manage.py loaddata initial_data.json--noinput是跳过交互确认适合脚本化。loaddata加载的是 fixture 文件里面可能是权限组、菜单配置。执行前打开 JSON 看一眼确认没有覆盖你已有数据的风险。到这一步平台应该能在浏览器打开登录页用createsuperuser建的账号进去能看到后台菜单说明骨架通了。3. CMDB 资产模块模型设计决定后面好不好改运维平台的地基是 CMDB资产模型设计得好后面批量执行、监控对接都顺设计得烂加个字段都要改三处。这套源码的资产 app 一般会有主机、机房、业务线、标签这几张表用外键和中间表关联。理解模型关系是二次开发的前提。3.1 资产模型与外键关系典型的资产模型长这样主机表存 IP、主机名、操作系统、CPU/内存、状态业务线表存业务归属主机和业务线是多对一主机和标签是多对多。看模型别只看字段重点看on_delete和related_name这两个参数决定了删除行为和反向查询写法。# 资产模型简化示例字段以实际包内为准 class Host(models.Model): ip models.GenericIPAddressField(uniqueTrue) # IP 唯一防重复录入 hostname models.CharField(max_length128) os_type models.CharField(max_length64, blankTrue) status models.CharField(max_length16, defaultonline) # online/offline business models.ForeignKey( Business, on_deletemodels.SET_NULL, # 业务线删除时主机保留 nullTrue, blankTrue, related_namehosts ) tags models.ManyToManyField(Tag, blankTrue, related_namehosts) class Meta: db_table cmdb_host indexes [models.Index(fields[status])] # 状态查询加索引on_deletemodels.SET_NULL是资产系统的常见选择业务线下线不该连带删主机记录否则审计断链。related_namehosts让你能从业务线对象反查主机写查询时business.hosts.all()比手写 join 清爽。GenericIPAddressField自带格式校验比CharField靠谱。索引加在status上是因为列表页按状态筛选是高频操作数据量上来后没索引会明显卡。二次开发加字段时记得同步改序列化、表单和列表展示漏一处就出现“存进去了但页面看不到”的玄学问题。3.2 资产录入与批量导入手工一条条录资产不现实实际落地都靠批量导入。这套平台一般提供 Excel 或 CSV 导入入口后端解析后逐行校验入库。核心逻辑是读文件、校验必填和格式、去重、批量创建、返回失败明细。import csv from django.db import transaction def import_hosts(file_path): success, failed 0, [] with open(file_path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: ip (row.get(ip) or ).strip() if not ip: failed.append({row: row, reason: IP 为空}) continue try: with transaction.atomic(): # 单行事务失败不影响其他行 Host.objects.update_or_create( ipip, defaults{ hostname: row.get(hostname, ), os_type: row.get(os_type, ), status: row.get(status, online), } ) success 1 except Exception as e: failed.append({row: row, reason: str(e)}) return success, failedupdate_or_create以 IP 为唯一键存在就更新、不存在就新建适合资产表反复导入的场景。transaction.atomic()包在单行循环里保证某一行失败不污染其他行同时避免整批回滚导致“导了一半全没了”。返回failed明细很重要运维导入几百行必须告诉用户哪几行错了、为什么错否则就是黑匣子。注意 CSV 编码Windows 导出的文件常是 GBK读的时候encoding要对应不然中文全乱码。3.3 资产查询与筛选接口资产列表页的体验取决于查询接口。常见做法是用 Django ORM 的filter链式拼接配合Q对象做多条件组合。前端传 IP 模糊、状态、业务线后端动态组装查询集。from django.db.models import Q def query_hosts(request): qs Host.objects.select_related(business).prefetch_related(tags) ip request.GET.get(ip) status request.GET.get(status) biz request.GET.get(business_id) if ip: qs qs.filter(Q(ip__icontainsip) | Q(hostname__icontainsip)) if status: qs qs.filter(statusstatus) if biz: qs qs.filter(business_idbiz) return qs.order_by(-id)select_related用于外键一次 join 拿回业务线信息避免列表页 N1 查询prefetch_related用于多对多标签单独一次查询再拼装。这两个是 Django 性能优化的基本功资产列表一页几十条不加的话数据库压力肉眼可见。icontains是大小写不敏感模糊匹配IP 和主机名共用一个搜索框时用Q做或关系。参数为空就不拼条件别写成filter(ip__icontains)那会匹配全表还拖慢查询。4. 批量命令执行与定时任务从单机 SSH 到任务编排资产管起来之后运维最想要的就是“一次对多台机器执行命令”。这块是平台的技术核心涉及 SSH 连接管理、并发控制、结果收集和超时处理。定时任务则是在此之上加调度层让巡检、备份这类重复劳动自动化。4.1 基于 paramiko 的远程执行封装paramiko 是 Python 里最常用的 SSH 库。封装要点连接超时、命令超时、异常捕获、结果结构化。别把连接和执行写成一坨拆成函数便于复用和测试。import paramiko def run_command(host, username, password, command, timeout10): client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # 首次连接自动信任 try: client.connect(host, usernameusername, passwordpassword, timeouttimeout, banner_timeouttimeout) stdin, stdout, stderr client.exec_command(command, timeouttimeout) out stdout.read().decode(utf-8, errorsignore) err stderr.read().decode(utf-8, errorsignore) code stdout.channel.recv_exit_status() # 拿退出码判断成败 return {host: host, code: code, stdout: out, stderr: err} except Exception as e: return {host: host, code: -1, error: str(e)} finally: client.close() # 必须关否则连接泄漏AutoAddPolicy省去首次连接确认内网环境常用但生产上更稳妥的是预置 known_hosts。timeout要设不设的话一台机器网络不通能把整个任务卡死。recv_exit_status()拿退出码比只看输出判断成败可靠很多命令失败时 stdout 是空的、错误在 stderr。errorsignore防止非 UTF-8 输出解码崩溃。finally里关连接是硬要求批量执行几百台连接不关很快耗尽文件描述符。4.2 并发执行与结果汇总串行执行一百台机器每台两秒就是三分多钟体验很差。常见做法是用线程池控制并发数既提速又不至于把目标机器和本机压垮。from concurrent.futures import ThreadPoolExecutor, as_completed def batch_run(hosts, username, password, command, max_workers10): results [] with ThreadPoolExecutor(max_workersmax_workers) as pool: futures { pool.submit(run_command, h[ip], username, password, command): h for h in hosts } for fut in as_completed(futures): results.append(fut.result()) return resultsmax_workers10是经验值内网批量执行够用机器多、命令重就调小避免目标机负载飙升。as_completed按完成顺序收集不用等最慢的那台才返回。注意线程池里每个任务独立建 SSH 连接账号密码别硬编码在代码里实际项目应从配置或加密字段读取。结果汇总后按code分组展示成功的、失败的、超时的分开列运维一眼能看出哪几台要跟进。4.3 定时任务接入与调度配置巡检、日志清理、备份这类任务适合定时跑。Django 生态里常见两种方案APScheduler 轻量、进程内调度celery 重一些、适合分布式。源码包用哪种以实际为准这里说 APScheduler 的接法因为它对单机部署更友好。from apscheduler.schedulers.background import BackgroundScheduler from django_apscheduler.jobstores import DjangoJobStore scheduler BackgroundScheduler() scheduler.add_jobstore(DjangoJobStore(), default) # 每天凌晨 2 点对在线主机做一次磁盘巡检 scheduler.add_job( functasks.jobs.disk_check, # 任务函数路径 triggercron, hour2, minute0, iddisk_check_daily, replace_existingTrue, # 重启后覆盖旧任务防重复 max_instances1, # 同一任务不并发 ) scheduler.start()replace_existingTrue很关键服务重启时如果不覆盖同一个 job id 会报冲突或产生重复任务。max_instances1防止上一轮没跑完下一轮又起来巡检这种任务尤其要限。调度器要放在应用启动时初始化通常写在apps.py的ready()里注意别在开发模式的自动重载下起两份。任务函数里要有日志和异常捕获定时任务失败没人盯着日志是唯一的后悔药。5. 避坑与排查这套平台落地时最容易翻车的五处源码能跑通只是起点真正部署到团队环境问题才一个个冒出来。下面五条是我在类似项目里反复遇到的按“现象 → 原因 → 解决”记下来照着排查能省不少时间。5.1 页面能开但静态资源 404现象登录页样式全丢浏览器控制台一堆 CSS/JS 404。原因DEBUGFalse后 Django 不再自动托管静态文件而 nginx 没配static路径。解决先collectstatic再在 nginx 里把/static/指向STATIC_ROOT确认STATIC_URL和 nginx location 一致。开发阶段图省事可以临时DEBUGTrue但别带到线上。5.2 批量执行部分机器一直超时现象批量任务里总有几台返回超时单独 SSH 又能连上。原因目标机 SSH 并发连接数限制或者线程池并发太高把对端打满。解决把max_workers降到 5 左右给connect和exec_command分别设超时失败机器单独重试一轮。另外检查目标机sshd_config的MaxStartups内网批量场景适当调大。5.3 定时任务重复执行现象同一个巡检任务一晚上跑了两次日志重复。原因开发模式runserver自动重载会启动两个进程调度器各起一份或者多 worker 部署时每个进程都初始化了调度器。解决调度器初始化加进程判断或用文件锁保证单实例生产上用独立进程跑调度别和 Web 进程混在一起。replace_existing只能防同 id 冲突防不了多进程。5.4 资产导入中文乱码现象导入 CSV 后主机名、备注全是问号或乱码。原因文件编码是 GBK代码按 UTF-8 读。解决读文件时先探测编码或用chardet判断统一要求导出方用 UTF-8。数据库字符集也要确认是utf8mb4否则存进去就坏了改起来更麻烦。5.5 权限越权访问现象普通用户能通过直接改 URL 访问管理员页面或他人资产。原因只在菜单层做了隐藏视图函数没做权限校验。解决视图上加login_required和基于角色的装饰器接口层用 Django 权限系统或自定义中间件统一拦截。菜单隐藏不是权限这是新手最容易犯的错接口必须自己校验。6. 二次开发与验证把平台改成自己团队的样子源码包的价值不在“能跑”在于“能改”。真正落地时每个团队的业务线、审批流、通知渠道都不一样照搬往往水土不服。我的做法是先跑通主流程再挑一个最小改动点验证扩展性确认架构没把自己堵死再动大手术。6.1 新增一个业务模块的标准动作以加一个“发布记录”模块为例标准动作是建 app、写模型、迁移、注册 admin、加路由和视图、挂菜单。这套流程走一遍能验证项目的分层是否清晰。# 新建 app命名按团队规范 python manage.py startapp release # 在 settings.py 的 INSTALLED_APPS 里注册 release # 写完 models.py 后执行迁移 python manage.py makemigrations release python manage.py migrate release模型里关联主机和操作人用外键指向已有表别重复造资产表。视图优先复用项目里的基类或装饰器保持权限和日志风格一致。菜单一般在初始化数据或权限表里配置加完记得清缓存或重启。这一步能暴露的问题很典型如果加个模块要改五六个地方说明耦合偏重后续维护成本会高。6.2 用一条命令验证整条链路改完之后别只点页面写个管理命令把“资产查询 → 批量执行 → 结果落库”串起来跑一遍比手工点十次可靠。# management/commands/smoke_test.py from django.core.management.base import BaseCommand from cmdb.models import Host from tasks.executor import batch_run class Command(BaseCommand): help 冒烟测试取在线主机执行 echo 并打印结果 def handle(self, *args, **options): hosts list(Host.objects.filter(statusonline).values(ip)[:3]) if not hosts: self.stdout.write(无在线主机跳过) return results batch_run(hosts, ops, password, echo ok, max_workers3) for r in results: self.stdout.write(str(r))values(ip)只取需要的字段减少数据传输。限制三台是控制影响面冒烟测试不该全量跑。输出直接打印结果字典成功失败一目了然。这个命令可以进 CI每次改动后自动跑比人工回归省心。参数里的账号密码实际应从配置读示例里写死只为说明结构。6.3 部署前的检查清单上线前有几项必须过一遍我用表格记避免漏项。检查项关注点常见问题DEBUG 状态必须为 False忘了改报错页暴露源码路径密钥管理SECRET_KEY、数据库密码走环境变量硬编码进仓库静态文件collectstatic 已执行、nginx 已配样式丢失日志文件日志 错误告警出问题无据可查备份数据库定期备份误删无法恢复权限接口层校验非仅菜单隐藏越权访问这张表不复杂但每一条都对应过真实翻车。尤其DEBUG和密钥前者泄露信息后者泄露即失守。日志建议按天切分、保留至少两周运维平台的操作审计本身就是合规需求。6.4 一个我坚持的习惯这套平台我前后改过几版最大的体会是别急着加功能先把“资产准确”和“操作可追溯”这两件事做扎实。资产不准批量执行就是盲打操作没审计出了问题连谁改的都查不到。所以我现在每次动完代码都会强制走一遍冒烟命令加检查清单哪怕只改了一个字段。看着麻烦但比上线后半夜被叫起来排查强太多。希望这套拆解能帮到你少走几段弯路。本文还有配套的精品资源点击获取 简介这份资源是一套基于Django框架搭建的轻量级运维平台源码面向具备Python基础、希望了解Web运维系统实现思路的开发者与运维人员可用于学习主机管理、服务监控、日志查看、任务调度、权限控制、资源统计、脚本执行与故障告警等常见模块的落地方式。压缩包共164个文件以39个py源码、38个js脚本、23个css样式、11个html模板及若干图片与字体资源为主整体约3.63MB前后端不分离的结构清晰便于按模块阅读与二次改造。目前已有2718人学习下载。代码中保留了Django项目常见的模型、视图、模板与静态资源组织方式读者可据此理解运维平台从数据建模到页面呈现的完整链路并借鉴审计追踪、知识库等设计思路适合作为课程设计或小型运维工具的参考原型。1. 运维平台不是“又一个后台”Django 这套骨架到底能扛什么活很多团队第一次做运维平台都是从一张 Excel 资产表开始的机器 IP、负责人、到期时间、部署了哪些服务全靠人肉维护。等到机器过百、服务上云、值班轮换这张表就开始翻车——改一处漏三处查一台机器要问三个人。我见过最离谱的一次是某公司上线前发现一台“已下线”的机器还在跑核心任务因为资产表里没人更新状态。这类问题的根子不在人在于没有一个把资产、任务、权限、日志串起来的系统。这份基于 Django 的运维平台源码包解决的就是这个“串起来”的问题。它用 Python 生态里最成熟的 Web 框架做底座把 CMDB 资产管理、批量命令执行、定时任务、操作审计这几块运维日常高频需求做成可运行的模块。适合两类人一是想给团队搭内部工具的后端或运维开发二是拿它当 Django 实战项目练手、顺便理解 DevOps 工具链怎么落地的人。下面我按“这套东西怎么跑起来、每个模块怎么改、哪里容易踩坑”的顺序拆参数和命令都给到能直接抄的程度。2. 把项目跑起来环境、依赖与数据库初始化拿到一个 Django 项目最怕上来就runserver报错一串接一串。我的习惯是先看依赖清单和配置文件把环境对齐再动手。这套平台的目录结构是典型的 Django 多 app 布局核心配置集中在settings.py资产、任务、审计各自独立成 app改起来边界清楚。2.1 依赖安装与虚拟环境隔离Python 项目第一件事永远是虚拟环境别往系统 Python 里装。项目一般会带requirements.txt里面主要是 Django 本体、数据库驱动、任务调度和 SSH 执行相关的库。常见组合是 Django MySQL 驱动 paramiko远程命令 APScheduler 或 celery定时任务具体以包内清单为准。# 创建并激活虚拟环境Python 3.8 以上均可 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖建议加国内镜像加速 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 确认 Django 版本和项目要求对齐 python -c import django; print(django.get_version())这里的关键是版本对齐。Django 3.x 和 4.x 在urls.py的path写法、settings里部分配置项上有差异如果requirements.txt锁了版本就别手动升级。paramiko 负责 SSH 连接它依赖 cryptography在某些老系统上编译会失败遇到报错优先升级 pip 再重装。虚拟环境隔离的意义在于这套平台可能和你机器上其他项目依赖冲突尤其是 Django 版本混装是血泪教训。2.2 数据库配置与迁移运维平台的数据是有状态的资产、任务记录、审计日志都要落库。开发阶段用 SQLite 能跑但真要给团队用建议直接上 MySQL 或 PostgreSQL并发和后续扩展都更稳。配置在settings.py的DATABASES段改完执行迁移。# settings.py 数据库配置示例MySQL DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: ops_platform, # 库名提前建好 USER: ops_user, # 专用账号别用 root PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, # 支持中文和特殊字符 } }# 生成并执行迁移建表 python manage.py makemigrations python manage.py migrate # 创建后台管理员账号用于登录 Django admin python manage.py createsuperuser # 启动开发服务默认 8000 端口 python manage.py runserver 0.0.0.0:8000utf8mb4这个字符集别省运维平台里机器备注、任务描述经常带中文甚至特殊符号用utf8会在某些字符上截断报错。HOST填127.0.0.1而不是localhost能避开一部分 socket 连接问题。迁移命令的顺序不能反makemigrations是根据模型生成迁移文件migrate才是真正建表。如果迁移报“表已存在”多半是之前手动建过表或者迁移记录不一致别硬删库先看django_migrations表里的记录。2.3 静态文件与初始数据Django admin 的样式依赖静态文件开发模式下runserver会自动处理但一旦用 nginx 部署就得先collectstatic。另外这类平台通常带初始化脚本用来灌入默认角色、菜单或示例资产跑之前先看脚本内容别盲目执行。# 收集静态文件到 STATIC_ROOT 指定目录 python manage.py collectstatic --noinput # 如果包内有初始化脚本先看再跑 python manage.py loaddata initial_data.json--noinput是跳过交互确认适合脚本化。loaddata加载的是 fixture 文件里面可能是权限组、菜单配置。执行前打开 JSON 看一眼确认没有覆盖你已有数据的风险。到这一步平台应该能在浏览器打开登录页用createsuperuser建的账号进去能看到后台菜单说明骨架通了。3. CMDB 资产模块模型设计决定后面好不好改运维平台的地基是 CMDB资产模型设计得好后面批量执行、监控对接都顺设计得烂加个字段都要改三处。这套源码的资产 app 一般会有主机、机房、业务线、标签这几张表用外键和中间表关联。理解模型关系是二次开发的前提。3.1 资产模型与外键关系典型的资产模型长这样主机表存 IP、主机名、操作系统、CPU/内存、状态业务线表存业务归属主机和业务线是多对一主机和标签是多对多。看模型别只看字段重点看on_delete和related_name这两个参数决定了删除行为和反向查询写法。# 资产模型简化示例字段以实际包内为准 class Host(models.Model): ip models.GenericIPAddressField(uniqueTrue) # IP 唯一防重复录入 hostname models.CharField(max_length128) os_type models.CharField(max_length64, blankTrue) status models.CharField(max_length16, defaultonline) # online/offline business models.ForeignKey( Business, on_deletemodels.SET_NULL, # 业务线删除时主机保留 nullTrue, blankTrue, related_namehosts ) tags models.ManyToManyField(Tag, blankTrue, related_namehosts) class Meta: db_table cmdb_host indexes [models.Index(fields[status])] # 状态查询加索引on_deletemodels.SET_NULL是资产系统的常见选择业务线下线不该连带删主机记录否则审计断链。related_namehosts让你能从业务线对象反查主机写查询时business.hosts.all()比手写 join 清爽。GenericIPAddressField自带格式校验比CharField靠谱。索引加在status上是因为列表页按状态筛选是高频操作数据量上来后没索引会明显卡。二次开发加字段时记得同步改序列化、表单和列表展示漏一处就出现“存进去了但页面看不到”的玄学问题。3.2 资产录入与批量导入手工一条条录资产不现实实际落地都靠批量导入。这套平台一般提供 Excel 或 CSV 导入入口后端解析后逐行校验入库。核心逻辑是读文件、校验必填和格式、去重、批量创建、返回失败明细。import csv from django.db import transaction def import_hosts(file_path): success, failed 0, [] with open(file_path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: ip (row.get(ip) or ).strip() if not ip: failed.append({row: row, reason: IP 为空}) continue try: with transaction.atomic(): # 单行事务失败不影响其他行 Host.objects.update_or_create( ipip, defaults{ hostname: row.get(hostname, ), os_type: row.get(os_type, ), status: row.get(status, online), } ) success 1 except Exception as e: failed.append({row: row, reason: str(e)}) return success, failedupdate_or_create以 IP 为唯一键存在就更新、不存在就新建适合资产表反复导入的场景。transaction.atomic()包在单行循环里保证某一行失败不污染其他行同时避免整批回滚导致“导了一半全没了”。返回failed明细很重要运维导入几百行必须告诉用户哪几行错了、为什么错否则就是黑匣子。注意 CSV 编码Windows 导出的文件常是 GBK读的时候encoding要对应不然中文全乱码。3.3 资产查询与筛选接口资产列表页的体验取决于查询接口。常见做法是用 Django ORM 的filter链式拼接配合Q对象做多条件组合。前端传 IP 模糊、状态、业务线后端动态组装查询集。from django.db.models import Q def query_hosts(request): qs Host.objects.select_related(business).prefetch_related(tags) ip request.GET.get(ip) status request.GET.get(status) biz request.GET.get(business_id) if ip: qs qs.filter(Q(ip__icontainsip) | Q(hostname__icontainsip)) if status: qs qs.filter(statusstatus) if biz: qs qs.filter(business_idbiz) return qs.order_by(-id)select_related用于外键一次 join 拿回业务线信息避免列表页 N1 查询prefetch_related用于多对多标签单独一次查询再拼装。这两个是 Django 性能优化的基本功资产列表一页几十条不加的话数据库压力肉眼可见。icontains是大小写不敏感模糊匹配IP 和主机名共用一个搜索框时用Q做或关系。参数为空就不拼条件别写成filter(ip__icontains)那会匹配全表还拖慢查询。4. 批量命令执行与定时任务从单机 SSH 到任务编排资产管起来之后运维最想要的就是“一次对多台机器执行命令”。这块是平台的技术核心涉及 SSH 连接管理、并发控制、结果收集和超时处理。定时任务则是在此之上加调度层让巡检、备份这类重复劳动自动化。4.1 基于 paramiko 的远程执行封装paramiko 是 Python 里最常用的 SSH 库。封装要点连接超时、命令超时、异常捕获、结果结构化。别把连接和执行写成一坨拆成函数便于复用和测试。import paramiko def run_command(host, username, password, command, timeout10): client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # 首次连接自动信任 try: client.connect(host, usernameusername, passwordpassword, timeouttimeout, banner_timeouttimeout) stdin, stdout, stderr client.exec_command(command, timeouttimeout) out stdout.read().decode(utf-8, errorsignore) err stderr.read().decode(utf-8, errorsignore) code stdout.channel.recv_exit_status() # 拿退出码判断成败 return {host: host, code: code, stdout: out, stderr: err} except Exception as e: return {host: host, code: -1, error: str(e)} finally: client.close() # 必须关否则连接泄漏AutoAddPolicy省去首次连接确认内网环境常用但生产上更稳妥的是预置 known_hosts。timeout要设不设的话一台机器网络不通能把整个任务卡死。recv_exit_status()拿退出码比只看输出判断成败可靠很多命令失败时 stdout 是空的、错误在 stderr。errorsignore防止非 UTF-8 输出解码崩溃。finally里关连接是硬要求批量执行几百台连接不关很快耗尽文件描述符。4.2 并发执行与结果汇总串行执行一百台机器每台两秒就是三分多钟体验很差。常见做法是用线程池控制并发数既提速又不至于把目标机器和本机压垮。from concurrent.futures import ThreadPoolExecutor, as_completed def batch_run(hosts, username, password, command, max_workers10): results [] with ThreadPoolExecutor(max_workersmax_workers) as pool: futures { pool.submit(run_command, h[ip], username, password, command): h for h in hosts } for fut in as_completed(futures): results.append(fut.result()) return resultsmax_workers10是经验值内网批量执行够用机器多、命令重就调小避免目标机负载飙升。as_completed按完成顺序收集不用等最慢的那台才返回。注意线程池里每个任务独立建 SSH 连接账号密码别硬编码在代码里实际项目应从配置或加密字段读取。结果汇总后按code分组展示成功的、失败的、超时的分开列运维一眼能看出哪几台要跟进。4.3 定时任务接入与调度配置巡检、日志清理、备份这类任务适合定时跑。Django 生态里常见两种方案APScheduler 轻量、进程内调度celery 重一些、适合分布式。源码包用哪种以实际为准这里说 APScheduler 的接法因为它对单机部署更友好。from apscheduler.schedulers.background import BackgroundScheduler from django_apscheduler.jobstores import DjangoJobStore scheduler BackgroundScheduler() scheduler.add_jobstore(DjangoJobStore(), default) # 每天凌晨 2 点对在线主机做一次磁盘巡检 scheduler.add_job( functasks.jobs.disk_check, # 任务函数路径 triggercron, hour2, minute0, iddisk_check_daily, replace_existingTrue, # 重启后覆盖旧任务防重复 max_instances1, # 同一任务不并发 ) scheduler.start()replace_existingTrue很关键服务重启时如果不覆盖同一个 job id 会报冲突或产生重复任务。max_instances1防止上一轮没跑完下一轮又起来巡检这种任务尤其要限。调度器要放在应用启动时初始化通常写在apps.py的ready()里注意别在开发模式的自动重载下起两份。任务函数里要有日志和异常捕获定时任务失败没人盯着日志是唯一的后悔药。5. 避坑与排查这套平台落地时最容易翻车的五处源码能跑通只是起点真正部署到团队环境问题才一个个冒出来。下面五条是我在类似项目里反复遇到的按“现象 → 原因 → 解决”记下来照着排查能省不少时间。5.1 页面能开但静态资源 404现象登录页样式全丢浏览器控制台一堆 CSS/JS 404。原因DEBUGFalse后 Django 不再自动托管静态文件而 nginx 没配static路径。解决先collectstatic再在 nginx 里把/static/指向STATIC_ROOT确认STATIC_URL和 nginx location 一致。开发阶段图省事可以临时DEBUGTrue但别带到线上。5.2 批量执行部分机器一直超时现象批量任务里总有几台返回超时单独 SSH 又能连上。原因目标机 SSH 并发连接数限制或者线程池并发太高把对端打满。解决把max_workers降到 5 左右给connect和exec_command分别设超时失败机器单独重试一轮。另外检查目标机sshd_config的MaxStartups内网批量场景适当调大。5.3 定时任务重复执行现象同一个巡检任务一晚上跑了两次日志重复。原因开发模式runserver自动重载会启动两个进程调度器各起一份或者多 worker 部署时每个进程都初始化了调度器。解决调度器初始化加进程判断或用文件锁保证单实例生产上用独立进程跑调度别和 Web 进程混在一起。replace_existing只能防同 id 冲突防不了多进程。5.4 资产导入中文乱码现象导入 CSV 后主机名、备注全是问号或乱码。原因文件编码是 GBK代码按 UTF-8 读。解决读文件时先探测编码或用chardet判断统一要求导出方用 UTF-8。数据库字符集也要确认是utf8mb4否则存进去就坏了改起来更麻烦。5.5 权限越权访问现象普通用户能通过直接改 URL 访问管理员页面或他人资产。原因只在菜单层做了隐藏视图函数没做权限校验。解决视图上加login_required和基于角色的装饰器接口层用 Django 权限系统或自定义中间件统一拦截。菜单隐藏不是权限这是新手最容易犯的错接口必须自己校验。6. 二次开发与验证把平台改成自己团队的样子源码包的价值不在“能跑”在于“能改”。真正落地时每个团队的业务线、审批流、通知渠道都不一样照搬往往水土不服。我的做法是先跑通主流程再挑一个最小改动点验证扩展性确认架构没把自己堵死再动大手术。6.1 新增一个业务模块的标准动作以加一个“发布记录”模块为例标准动作是建 app、写模型、迁移、注册 admin、加路由和视图、挂菜单。这套流程走一遍能验证项目的分层是否清晰。# 新建 app命名按团队规范 python manage.py startapp release # 在 settings.py 的 INSTALLED_APPS 里注册 release # 写完 models.py 后执行迁移 python manage.py makemigrations release python manage.py migrate release模型里关联主机和操作人用外键指向已有表别重复造资产表。视图优先复用项目里的基类或装饰器保持权限和日志风格一致。菜单一般在初始化数据或权限表里配置加完记得清缓存或重启。这一步能暴露的问题很典型如果加个模块要改五六个地方说明耦合偏重后续维护成本会高。6.2 用一条命令验证整条链路改完之后别只点页面写个管理命令把“资产查询 → 批量执行 → 结果落库”串起来跑一遍比手工点十次可靠。# management/commands/smoke_test.py from django.core.management.base import BaseCommand from cmdb.models import Host from tasks.executor import batch_run class Command(BaseCommand): help 冒烟测试取在线主机执行 echo 并打印结果 def handle(self, *args, **options): hosts list(Host.objects.filter(statusonline).values(ip)[:3]) if not hosts: self.stdout.write(无在线主机跳过) return results batch_run(hosts, ops, password, echo ok, max_workers3) for r in results: self.stdout.write(str(r))values(ip)只取需要的字段减少数据传输。限制三台是控制影响面冒烟测试不该全量跑。输出直接打印结果字典成功失败一目了然。这个命令可以进 CI每次改动后自动跑比人工回归省心。参数里的账号密码实际应从配置读示例里写死只为说明结构。6.3 部署前的检查清单上线前有几项必须过一遍我用表格记避免漏项。检查项关注点常见问题DEBUG 状态必须为 False忘了改报错页暴露源码路径密钥管理SECRET_KEY、数据库密码走环境变量硬编码进仓库静态文件collectstatic 已执行、nginx 已配样式丢失日志文件日志 错误告警出问题无据可查备份数据库定期备份误删无法恢复权限接口层校验非仅菜单隐藏越权访问这张表不复杂但每一条都对应过真实翻车。尤其DEBUG和密钥前者泄露信息后者泄露即失守。日志建议按天切分、保留至少两周运维平台的操作审计本身就是合规需求。6.4 一个我坚持的习惯这套平台我前后改过几版最大的体会是别急着加功能先把“资产准确”和“操作可追溯”这两件事做扎实。资产不准批量执行就是盲打操作没审计出了问题连谁改的都查不到。所以我现在每次动完代码都会强制走一遍冒烟命令加检查清单哪怕只改了一个字段。看着麻烦但比上线后半夜被叫起来排查强太多。希望这套拆解能帮到你少走几段弯路。本文还有配套的精品资源点击获取