简介：这份文档是中国移动通信有限公司网络部制定的《IDC维护管理规定——云计算资源管理分册》2023版，面向IDC运维人员、云计算资源管理者及通信行业从业者，用于规范云计算资源的定义、构成、管理对象与全流程维护工作。资源包内含1个doc文件，大小约1008KB，共37页，结构完整、层级清晰。文档从概述、维护组织、维护工作内容三大板块展开，细化了资源管理原则、资源需求与建设、申请与需求评估、分派与业务上线、运行评估及调整回收、流程管理、资产管理与日常维护等环节，并延伸至故障、性能、安全、投诉、网络策略及现场作业管理，同时记录了V1.0至V1.2的修订历史。已有65人学习关注，适合需要了解运营商级云计算资源管理规范、搭建运维制度框架或编写内部管理文档的读者参考借鉴。

1. 从一份维护管理规定看 IDC 云计算资源怎么管才不翻车

很多做 IDC 运维的同行，第一次拿到《中国移动IDC维护管理规定云计算资源管理分册》这类文档时，第一反应是「这不就是个制度文件吗，跟技术有什么关系」。我一开始也这么想，直到某次资源池扩容后虚拟机批量掉线，排查了六个小时才发现是资源分配台账和实际宿主机容量对不上——制度里那句「资源变更须同步更新台账」不是走形式，是血泪经验换来的。这份分册本质上解决的是：在 IDC 机房这个物理边界内，云计算资源（计算、存储、网络）从规划、分配、变更到回收，每一步该谁做、做什么、留什么记录。它适合三类人：一是刚接手 IDC 云资源池的运维工程师，二是需要把制度翻译成自动化脚本的开发，三是负责资源审计和容量规划的管理岗。下面我按「制度怎么读 → 资源怎么管 → 自动化怎么做 → 坑在哪」的顺序，把这份分册拆成能落地的操作路径。

2. 云计算资源管理分册到底管什么：资源模型与职责边界

2.1 三类资源池的划分逻辑与命名规范

这份分册最核心的底层设计，是把 IDC 内的云计算资源按用途切成三类资源池：生产池、测试池、灾备池。生产池承载对外业务，SLA 要求最高；测试池给内部研发和验证用，允许超分；灾备池平时不跑业务，只做数据同步和定期演练。每类池子在命名上必须带标识，常见做法是「区域码-机房码-池类型-序号」，比如BJ-01-PROD-003表示北京区域 01 号机房生产池第三组。这个命名规则不是拍脑袋定的，它直接决定了后面资源分配脚本能不能自动识别池子类型并套用不同的配额策略。

为什么非要分池？因为不分池的后果我见过太多次：测试环境跑个压测把生产存储的 IOPS 打满，或者灾备池的同步任务把生产池的上行带宽占死。分池之后，每类池子的资源上限、超分比、告警阈值都可以独立配置。分册里对生产池的超分比要求最严，CPU 超分一般不超过 1:3，内存不超过 1:1.5；测试池可以放到 1:8 甚至更高。这些数字不是随便写的，是拿业务峰值的 P95 压出来的。

2.2 资源分配的三级审批与台账字段

分册里把资源分配流程拆成三级：申请人提交需求 → 资源管理员审核容量 → 运维主管审批变更。听起来像普通 OA 流程，但关键在于每一步都要落台账字段。台账不是一张 Excel 表那么简单，它至少要包含这些字段：资源 ID、所属池、宿主机集群、CPU/内存/存储配额、分配时间、申请人、审批人、到期时间、回收状态。其中「到期时间」和「回收状态」是最容易被忽略的，也是后面自动化回收脚本的触发依据。

我一般会把台账设计成一张宽表，用资源 ID 做主键，每次变更写一条新记录而不是覆盖旧记录，这样能追溯任意时间点的资源归属。分册里虽然没有明说要用版本化台账，但「变更须留痕」这条要求实际上就是这个意思。如果你用数据库存台账，建议加一个version字段和is_current标记，查询当前状态时过滤is_current = true，查历史时按资源 ID 拉全量。

2.3 容量水位与告警阈值的对应关系

分册对容量管理的要求是「分级告警、提前扩容」。具体来说，生产池的 CPU 分配率超过 70% 触发提醒，超过 85% 触发紧急告警；内存分配率超过 75% 提醒，超过 90% 紧急；存储池使用率超过 80% 提醒，超过 90% 紧急。这些阈值和监控系统里的告警规则要一一对应，不能制度写一套、监控配另一套。我见过最离谱的情况是制度要求 85% 告警，结果监控里配的是 95%，等告警响的时候资源已经快满了，扩容根本来不及。

这里有个实操细节：分配率和实际使用率是两回事。分配率是已经分给虚拟机的配额总和除以物理容量，使用率是虚拟机实际消耗的资源。分册里盯的是分配率，因为分配率高了意味着没有余量再分新资源，而使用率高了才需要优化虚拟机规格。两个指标要分开监控，告警规则也要分开配。

3. 把制度翻译成脚本：资源台账自动化管理实操

3.1 用 Python 读取资源池配置并校验命名规范

制度落地第一步是让脚本能自动识别资源池配置。我一般会维护一个 YAML 文件描述每个池子的属性，然后用 Python 读取并校验命名是否符合规范。下面这段代码做两件事：加载池配置、检查池名称是否匹配「区域码-机房码-池类型-序号」的正则。

import re import yaml # 加载资源池配置，配置文件里每个池子包含 name、type、cpu_overcommit 等字段 with open("resource_pools.yaml", "r", encoding="utf-8") as f: pools = yaml.safe_load(f) # 命名规范：两个大写字母-两位数字-池类型-三位序号 PATTERN = re.compile(r"^[A-Z]{2}-\d{2}-(PROD|TEST|DR)-\d{3}$") def validate_pool_name(pool): """校验池名称是否符合命名规范，返回布尔值和错误信息""" name = pool.get("name", "") if not PATTERN.match(name): return False, f"池名称 {name} 不符合规范" # 池类型字段必须和名称中的类型一致 name_type = name.split("-")[2] if name_type != pool.get("type"): return False, f"池名称类型 {name_type} 与配置类型 {pool['type']} 不一致" return True, "" for pool in pools: ok, msg = validate_pool_name(pool) if not ok: print(f"[FAIL] {msg}") else: print(f"[OK] {pool['name']} 类型 {pool['type']} 超分比 {pool.get('cpu_overcommit')}")

这段代码的关键在于正则和类型一致性检查。正则里PROD|TEST|DR对应生产、测试、灾备三种池类型，序号固定三位数方便排序。类型一致性检查是防止有人改了名称但忘了改配置字段，这种低级错误在人工维护时特别常见。参数方面，resource_pools.yaml里每个池子至少要有name、type、cpu_overcommit、mem_overcommit、alert_threshold五个字段，缺一个后面配额计算就会出错。

3.2 资源分配台账的 SQL 表结构与变更记录写入

台账用关系型数据库存是最稳的，查询和审计都方便。下面这张表结构是我在多个资源池项目里沉淀下来的，核心思路是「当前状态 + 变更历史」双表分离。

-- 资源当前状态表，每个资源 ID 只保留一条当前记录 CREATE TABLE resource_current ( resource_id VARCHAR(64) PRIMARY KEY, -- 资源唯一标识 pool_name VARCHAR(32) NOT NULL, -- 所属资源池 host_cluster VARCHAR(64) NOT NULL, -- 宿主机集群 cpu_quota INT NOT NULL, -- CPU 配额（核） mem_quota INT NOT NULL, -- 内存配额（GB） storage_quota INT NOT NULL, -- 存储配额（GB） applicant VARCHAR(32) NOT NULL, -- 申请人 approver VARCHAR(32) NOT NULL, -- 审批人 allocate_time DATETIME NOT NULL, -- 分配时间 expire_time DATETIME NOT NULL, -- 到期时间 recycle_status TINYINT DEFAULT 0 -- 0 未回收 1 已回收 ); -- 资源变更历史表，每次变更写一条，不覆盖 CREATE TABLE resource_history ( id BIGINT AUTO_INCREMENT PRIMARY KEY, resource_id VARCHAR(64) NOT NULL, change_type VARCHAR(16) NOT NULL, -- ALLOCATE/UPDATE/RECYCLE change_detail JSON NOT NULL, -- 变更前后字段快照 operator VARCHAR(32) NOT NULL, change_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_resource (resource_id), INDEX idx_time (change_time) );

resource_current表用resource_id做主键，保证每个资源只有一条当前记录，查询快。resource_history表用自增 ID 做主键，resource_id建普通索引，每次变更写一条 JSON 快照，记录变更前后的字段值。这样查历史时按resource_id拉出来就是完整的时间线。recycle_status字段配合expire_time可以做自动回收：每天跑一次定时任务，把expire_time < NOW()且recycle_status = 0的资源标记为待回收，通知申请人确认后置为已回收。

3.3 容量水位计算与分级告警的定时任务

容量水位计算不能只算当前分配量，还要算上已申请未分配、已分配未使用、预留缓冲三部分。下面这段 Python 代码演示如何从数据库拉取当前分配量，结合物理容量算出分配率，并按分册要求触发分级告警。

import pymysql from datetime import datetime # 物理容量配置，实际项目中从 CMDB 或配置文件读取 PHYSICAL_CAPACITY = { "BJ-01-PROD-003": {"cpu": 2000, "mem": 8000, "storage": 500000}, } # 分册要求的分级阈值 THRESHOLDS = { "PROD": {"cpu": (0.70, 0.85), "mem": (0.75, 0.90), "storage": (0.80, 0.90)}, "TEST": {"cpu": (0.85, 0.95), "mem": (0.85, 0.95), "storage": (0.85, 0.95)}, "DR": {"cpu": (0.80, 0.90), "mem": (0.80, 0.90), "storage": (0.80, 0.90)}, } def calc_water_level(pool_name, pool_type): """计算指定池的 CPU/内存/存储分配率，返回告警级别""" conn = pymysql.connect(host="localhost", user="ops", password="***", database="idc") cursor = conn.cursor() # 只统计未回收的资源配额总和 cursor.execute( "SELECT SUM(cpu_quota), SUM(mem_quota), SUM(storage_quota) " "FROM resource_current WHERE pool_name=%s AND recycle_status=0", (pool_name,) ) cpu_used, mem_used, storage_used = cursor.fetchone() conn.close() cap = PHYSICAL_CAPACITY[pool_name] rates = { "cpu": cpu_used / cap["cpu"], "mem": mem_used / cap["mem"], "storage": storage_used / cap["storage"], } alerts = [] for metric, rate in rates.items(): warn, critical = THRESHOLDS[pool_type][metric] if rate >= critical: alerts.append(f"[紧急] {pool_name} {metric} 分配率 {rate:.1%}") elif rate >= warn: alerts.append(f"[提醒] {pool_name} {metric} 分配率 {rate:.1%}") return alerts # 遍历所有池子，输出告警 for pool_name, cap in PHYSICAL_CAPACITY.items(): pool_type = pool_name.split("-")[2] for alert in calc_water_level(pool_name, pool_type): print(f"{datetime.now():%Y-%m-%d %H:%M} {alert}")

这段代码的核心逻辑是「按池类型套不同阈值」。THRESHOLDS字典里生产池的阈值最严，测试池最松，灾备池居中。calc_water_level函数只统计recycle_status=0的资源，已回收的不算进分配率。告警输出分「提醒」和「紧急」两级，对应分册里的分级告警要求。实际部署时把这个脚本挂到 crontab 里每小时跑一次，告警结果推到监控平台或邮件组。参数方面，PHYSICAL_CAPACITY最好从 CMDB 动态拉取而不是硬编码，否则宿主机扩容后忘了改配置，分配率就算不准了。

4. 资源回收与变更管理：最容易出事的两个环节

4.1 到期资源自动回收的确认机制与后悔药设计

资源回收是制度里写得最清楚、执行时最容易出事的环节。分册要求「到期前 7 天通知、到期后 3 天确认、确认后 1 天回收」，但实际操作中经常遇到申请人没看到通知、或者看到了但忘了确认，结果资源被回收后业务方找上门。我一般会在自动回收流程里加一道「后悔药」：资源标记为待回收后不立即删除，而是先关机并保留 7 天，7 天内申请人可以申请恢复，7 天后才真正释放配额。这样既执行了制度，又给了缓冲。

具体实现是在resource_current表里加一个pending_recycle_time字段，定时任务把到期资源置为待回收并记录时间，同时发通知。申请人确认回收则直接置recycle_status=1；申请人申请恢复则清空pending_recycle_time并延长expire_time。超过 7 天未处理的，定时任务自动置为已回收并释放配额。这套机制的关键是通知要发到位，我一般会同时发邮件和企业内部消息，确保申请人至少看到一个。

4.2 资源变更的审批链与回滚方案

资源变更包括扩容、缩容、迁移、规格调整四类。分册要求所有变更走审批链，但审批链的长度可以按变更影响面动态调整：扩容和规格调整影响小，两级审批即可；缩容和迁移影响大，必须三级审批。变更前必须做回滚方案，回滚方案要写清楚「什么条件下回滚、回滚步骤是什么、回滚预计耗时」。我见过一次缩容变更没做回滚方案，结果缩容后业务峰值扛不住，临时扩容又因为资源池没余量而失败，最后只能从测试池借资源，折腾了一整夜。

回滚方案不是写给自己看的，是写给半夜被叫起来处理故障的同事看的。所以步骤要具体到命令级别，比如「执行virsh setmem把内存调回原值」而不是「恢复内存配置」。变更记录里要把回滚方案一起存进resource_history的change_detail字段，方便事后审计。

4.3 跨池资源调度的约束条件

分册允许跨池调度资源，但有三个硬约束：生产池不能从测试池借资源、灾备池不能借给生产池、跨机房调度必须走专线且带宽预留不低于 20%。这三个约束背后都是血泪教训。生产池从测试池借资源，测试池的脏数据或异常负载可能影响生产；灾备池借给生产池，真出故障时灾备池没资源可切；跨机房调度不预留带宽，同步任务会把专线打满导致业务抖动。

跨池调度在台账里要单独记录，不能简单改pool_name字段，而是新建一条资源记录并标记来源池。这样查历史时能看出资源是从哪个池子调过来的，回收时也能正确归还。我一般会在resource_current表里加一个source_pool字段，默认等于pool_name，跨池调度时填实际来源池。

5. 避坑与排查：资源管理里最常见的五个翻车现场

5.1 台账和实际不一致：现象是分配率算出来偏低，原因是有人手动改了虚拟机规格没更新台账

现象：容量告警一直不响，但宿主机实际已经快满了。原因：运维人员通过虚拟化平台直接调整了虚拟机 CPU/内存，没有走台账变更流程，导致台账里的配额还是旧值。解决：一是把虚拟化平台的变更接口和台账系统对接，变更自动写台账；二是每天跑一次对账脚本，比对虚拟化平台实际配置和台账记录，不一致的生成差异报告人工确认。对账脚本的核心是拉取所有虚拟机的实际规格，按资源 ID 关联台账，比对cpu_quota、mem_quota字段。

5.2 到期时间设成永久：现象是资源池越用越满，原因是申请时到期时间填了 2099 年

现象：资源池分配率持续上涨，但回收记录几乎为零。原因：申请人为了省事，到期时间填了 2099-12-31，制度里又没有强制校验。解决：在申请入口加校验，到期时间不得超过当前日期加一年；超过一年的需要额外审批。同时定期扫描expire_time超过一年的资源，生成清单要求申请人重新确认。这个坑的本质是制度执行缺少技术卡点，光靠人工审核挡不住。

5.3 告警阈值和监控配置不一致：现象是制度要求 85% 告警但 95% 才响，原因是两套配置各改各的

现象：容量评审时发现制度写的阈值和监控平台配的不一样。原因：制度修订后没有同步更新监控配置，或者监控配置由不同的人维护。解决：把阈值配置收敛到一个地方，比如配置中心或数据库表，制度和监控都从同一个源读取。我一般会在resource_pools.yaml里定义阈值，监控脚本和制度文档都引用这个文件，改一处全生效。

5.4 跨池调度没记来源：现象是回收时不知道该还哪个池，原因是调度时直接改了池名字段

现象：跨池调度的资源回收时，系统按当前池名字归还配额，导致来源池配额对不上。原因：调度时直接更新了pool_name字段，没有记录来源池。解决：调度时新建资源记录并填source_pool字段，回收时按source_pool归还。如果已经发生了这种情况，只能靠人工排查历史变更记录来修正，所以最好一开始就设计好字段。

5.5 回收确认通知漏发：现象是资源被回收后业务方说没收到通知，原因是通知只发了邮件没发内部消息

现象：业务方投诉资源被回收但没收到通知。原因：通知只发了邮件，而业务方主要看内部消息，邮件被淹没了。解决：通知渠道至少覆盖两个，邮件加内部消息，重要资源回收还要电话确认。通知记录要落库，记录发送时间、渠道、接收人，方便事后追溯。这个坑看起来是小事，但真出故障时业务方会拿「没收到通知」说事，有记录才能说清楚。

6. 从制度到平台：把分册要求变成可验证的自动化检查

制度落地到最后，一定要有一套自动化检查来验证执行情况，否则制度就是墙上的纸。我一般会做一个「合规检查」脚本，每周跑一次，输出一份检查报告。检查项包括：台账和虚拟化平台对账差异数、到期未回收资源数、超期未确认资源数、告警阈值一致性、跨池调度记录完整性。每项检查对应一个分数，总分低于 90 分就触发整改通知。

下面这个检查项表格是我常用的模板，你可以直接套：

检查脚本用 Python 写，输出 Markdown 格式的报告，直接推到内部文档平台。报告里每项检查列出具体的不合格资源 ID 和责任人，方便跟进。这套检查跑顺了之后，资源管理的合规率能从 70% 拉到 95% 以上，而且不用人工翻台账。

最后说个我自己的习惯：每次制度修订后，第一件事不是发通知，而是改检查脚本。制度改了但检查脚本没改，执行一定走样。检查脚本是制度的「牙齿」，没有牙齿的制度咬不动人。希望帮到你。

本文还有配套的精品资源，点击获取