简介中国移动IDC维护管理规定云计算资源管理分册2023版是一份面向IDC运维与云计算资源管理人员的规范文件旨在统一资源管理流程、明确岗位职责适用于通信行业机房管理者、网络维护工程师及企业云资源规划人员。资源包为单个doc文档容量约1008KB包含完整37页正文及目录文件内部层级清晰方便按章节检索。文档系统梳理了云计算资源的定义与构成、维护组织机构及职责并围绕资源管理原则、资源需求和建设管理、申请与需求评估、分派与业务上线、运行评估及调整回收等全流程展开同时对故障管理、性能管理、安全管理、投诉管理和现场作业管理等配套内容提出要求覆盖日常维护的关键环节。修订历史记录了从V1.0到V1.2的修改状态、修订人、审核人及日期体现文档随业务需求持续完善的过程。目前已有65人学习/下载适合作为制定内部云计算资源管理制度、优化运维流程以及开展人员培训的参考范本。1. 中国移动IDC维护管理规定云计算资源管理分册IDC云化后维护规矩该怎么改IDC机房刚上云那阵子我们手里还揣着旧版维护管理规定按物理服务器的套路做台账、巡检、故障处理结果虚拟机一多立刻乱套。中国移动IDC维护管理规定里的云计算资源管理分册就是把这种乱套变成可执行规则的范本。它解决的是IDC从“卖机架”转向“卖云主机”之后维护边界、容量、配额、变更和故障处理该怎么重新定义。适合机房维护主管、云资源运维工程师、流程规范制定者以及正在把自有维护制度往云化方向修订的团队。2. 资源分册先划边界云资源池里哪些对象该被维护并纳入台账2.1 与IDC基础设施分册的分工管虚拟机不等于管服务器先说一个最常见的认知偏差以为云资源管理分册是在管“服务器”。不对它管的是物理服务器之上那一层逻辑资源。我见过太多维护团队把宿主机和虚拟机混在一本台账里硬盘故障了去查虚机虚拟机迁移了又去物理机列表里找两头都落空。正常的分工是这样的基础设施分册负责机柜、UPS、空调、物理服务器硬件、交换机和存储阵列云计算资源管理分册负责这上面的租户、虚拟机、镜像、云硬盘、虚拟网络和配额。两者交集在宿主机故障场景硬件告警走基础设施分册但故障导致的虚拟机自动迁移、HA触发、数据盘挂载校验必须走云计算资源分册的流程。如果这两本册子的责任矩阵没写好故障处理到一半就会出现“有人换硬盘、没人管业务恢复”的真空。我一般建议在分册开头先用一张责任矩阵把边界钉死而不是急着写巡检项。这张表没有固定模板关键是回答三个问题虚拟机出现故障谁处理宿主机出现故障谁处理两者交叉的迁移场景谁发起、谁确认、谁回滚。2.2 分册中的核心对象虚拟机、镜像、存储卷与配额生命周期云计算资源分册的维护对象和物理服务器最大的区别在于“生命周期”三个字。物理服务器的生命周期从到货验收开始到报废下架结束中间位置基本固定虚拟机则可以在几分钟内创建、克隆、迁移、调整规格、删除没有一套独立的生命周期管理规则资源池迟早变成黑匣子。分册里至少要覆盖四类对象的生命周期规则。第一类是虚拟机从创建审批、部署规范、日常开停机到最终回收每一步要有明确入口和责任人。第二类是镜像和模板重点是版本管理和补丁基线镜像一旦发布就不能随便改改必须出新版本否则线上虚拟机之间配置漂移排查问题全靠猜。第三类是云硬盘与快照快照保留周期和存储容量要关联管理很多资源池被撑爆不是业务数据涨了是没人管快照堆积。第四类是配额分区也就是租户级别能用的vCPU、内存、存储和网络带宽上限这块放在第三章细说。分册里还应该写清楚一个原则所有对象必须归属于某个租户或业务分区不允许存在“无主资源”。无主虚拟机、无主镜像、无主快照是后期审计和成本核算里最常见的黑洞也是维护规定最容易失守的地方。2.3 一张能落地的云资源台账登记表维护规定如果没有台账字段设计后面巡检和容量分析就没有数据底座。下面这张表是我基于IDC云资源池常见需求整理的最小字段集做分册时可以直接抄字段名示例值说明资源编号VM-2024-0187全局唯一按年份流水所属租户/部门计费系统部决定配额归属和责任人资源名称bj-billing-web-01命名规范地域-业务-角色-序号规格4C/8GvCPU核数/内存GB系统盘容量80G系统盘一般不超配扩容数据盘容量500G数据盘关联独立存储池所属宿主机HV-003迁移后必须更新管理IP10.20.3.15带外管理地址不随业务漂移维护负责人张三变更和故障的第一联系人创建时间2024-03-12用于生命周期审计计划回收时间2025-03-12到期自动进入回收流程状态运行中/停机/维护/回收中状态机切换需走工单台账登记表后面还要配一条维护规则每周从云平台API拉一次全量资源清单和这张表自动比对发现差异就生成待办。差异来源通常是有人绕过流程直接在平台上创建或删除了资源这种情况下一旦审计分册就是废纸。参数上注意两点。一是资源编号不要跟着虚拟机内部主机名走主机名可能重复编号必须不改。二是计划回收时间不能只是摆设到期前30天、7天各发一次提醒确认保留就顺延不确认就冻结冻结期间业务访问会受限这个机制比“登记一下”有效得多。3. 容量与配额管理分册里决定资源池不崩的硬指标与计算公式3.1 三层容量指标物理水位、逻辑水位与业务水位容量管理是云计算资源管理分册里最容易写成空话的章节。很多人写一句“定期检查资源使用率”就交差了结果资源池什么时候会满谁也说不清。我一般会把容量拆成三个层次来监控每一层对应不同的维护动作。物理水位看宿主机池的真实消耗包括CPU使用率、内存使用率、存储池已用空间。这一层指标直接决定要不要采购扩容。逻辑水位看租户已经分配出去的虚拟资源总和占物理池的比例也就是超配比。这个参数决定的是“分配出去的资源能不能兑现”。业务水位看业务系统实际用掉了多少分配资源这是缩容和成本优化的依据。三个层次之间是递进关系业务水位高于逻辑水位说明业务在超用逻辑水位高于物理水位说明超配有风险。举个例子某个租户分配了8核16G实际业务峰值只用2核4G那它占用的逻辑资源就是虚的如果大量租户都这样物理池看似分配出去80%了实际负载才30%一旦某个大业务做活动把负载拉起来超配的风险才真正暴露。这三层指标的监控阈值是分册里可以量化的部分建议直接参考下面这张表指标层指标项正常区间预警阈值处置动作物理水位宿主机CPU使用率30%-60%85%持续15分钟迁移负载、扩容物理水位宿主机内存使用率40%-70%85%持续15分钟迁移负载、扩容物理水位存储池已用空间70%85%清理快照/扩容逻辑水位CPU超配比1:2 - 1:41:6回收闲置资源逻辑水位内存超配比1:1 - 1:1.51:2回收或扩容业务水位租户资源利用率30%-70%90%持续7天提高配额或规格预警阈值不是死数字但上面这组是IDC场景里比较稳妥的起点。注意“持续15分钟”这个条件很重要没有持续时间限制的告警会在半夜把值班人员刷疯。3.2 配额计算公式与默认组设置配额管理写在分册里不是为了给业务部门添堵是为了避免某个租户把整个资源池拖垮。没有配额约束的云平台一个业务部门的一次批量创建操作就能把存储池打爆其他所有租户一起遭殃。配额项目一般包含vCPU核数、内存GB、存储GB系统盘数据盘、最大虚拟机数量、带宽上限。默认值怎么给我常用的方式是“业务申请量乘以一个系数再加安全余量”vCPU配额 业务峰值预计使用核数 × 1.5再向上取整到4的倍数内存配额 业务峰值预计使用内存 × 1.2再向上取整到4的倍数存储配额 业务预估数据量 快照预留一般按数据量的20% 至少50G系统盘余量虚拟机数量上限 预计需要的主机数 × 1.3保留重建和扩容空间这套公式的出发点很简单配额要给够日常使用的量但又不能给到没有上限。给够了之后业务部门不需要频繁提扩容申请设了上限资源池的物理安全就有保障。分册里还要写一个配额调整周期——我建议是每季度评估一次结合业务水位做动态调整而不是配额发下去就三年不动。3.3 云覆盖度计算在容量评估里的用法“云覆盖度”这个词不是标准术语但在容量评估报告里很实用它衡量的是物理资源池对逻辑分配资源的支撑程度。通俗说就是“物理池的家底”够不够覆盖“已经答应出去的资源”。计算方式很简单覆盖度 物理池可用资源 ÷ 租户逻辑已分配资源 × 100%。CPU和内存要分开算存储一般不参与超配所以存储覆盖度直接用已用空间算。举个可复现的例子# 云覆盖度计算评估物理池对逻辑分配的支撑能力 physical_cpu_total 960 # 宿主机池总核数 physical_mem_total 8192 # 宿主机池总内存单位GB logical_alloc_cpu 3840 # 租户已分配vCPU核数 logical_alloc_mem 12288 # 租户已分配内存单位GB print(CPU覆盖度: {:.1f}%.format(physical_cpu_total / logical_alloc_cpu * 100)) print(内存覆盖度: {:.1f}%.format(physical_mem_total / logical_alloc_mem * 100)) print(CPU超配比: 1:{:.1f}.format(logical_alloc_cpu / physical_cpu_total)) print(内存超配比: 1:{:.1f}.format(logical_alloc_mem / physical_mem_total))这段脚本跑出来的数值如果CPU超配比超过1:6内存超配比超过1:2就该进容量预警流程。我一般会在分册里规定覆盖度低于30%的资源池必须出具容量分析报告说明逻辑分配是否合理、是否有闲置资源可以回收。提示覆盖度不是越高越好。覆盖度过高说明物理资源大量冗余、采购成本浪费覆盖度过低说明超配风险大业务高峰可能引发资源争抢。要结合三层容量指标一起看单看任何一个数字都会误判。4. 标准化维护流程落地巡检、变更与故障升级的动作拆解4.1 巡检计划设计虚拟化层与硬件层分开巡巡检是维护规定里最能体现“分册价值”的章节。传统IDC巡检表里的“检查服务器电源指示灯”“听风扇声音”这类项在云资源分册里几乎没有意义而真正该巡的东西恰恰是传统巡检表里没有的。我建议把巡检拆成两条线。硬件线继续走基础设施分册检查宿主机电源、硬盘状态、RAID卡日志虚拟化线走云资源分册检查集群资源平衡度、虚拟机运行状态、存储IO延时、迁移失败记录、镜像漏洞扫描结果。两条线不能合并成一张表否则操作人员在巡检时只挑看得见的东西勾选看不见的虚拟化层风险全漏掉。下面这张表是虚拟化层巡检项的最小集合可以直接抄进分册的附录巡检对象巡检内容周期异常判断标准宿主机CPU steal时间占比每日超过10%持续30分钟宿主机内存交换分区用量每日swap使用率超过20%存储池数据盘IO等待时间每日await超过30ms集群虚拟机迁移失败记录每日有任一失败即告警虚拟机无故重启事件每周有任一事件即核查镜像漏洞扫描状态每月高危漏洞未修复数0巡检执行完之后分册里必须写“巡检结论闭环”这一步发现问题就生成工单工单关联到责任人责任人在限期内回填处理结果。没有闭环的巡检表填完就是一张废纸。4.2 变更管理与维护窗口在线迁移与离线迁移的时间估算变更管理在云计算资源分册里占据大量篇幅因为云环境里变更频率远高于传统物理机。虚拟机规格调整、存储迁移、镜像更新、安全组规则修改这些都算变更。分册要做的就是把这些变更按风险分级不同级别走不同的审批通道。维护窗口的定义要具体。不能只写“夜间进行”要给出迁移方式对应的停机时间预估逻辑在线迁移的停机时间基本等于“最后一次数据同步的差量复制时间 切换时间”差量时间和业务写频率强相关离线迁移的停机时间等于“全量数据拷贝时间 目标主机启动时间”。有了这个估算公式变更审批时才能算清楚这个窗口够不够用。变更流程的六个动作申请、影响评估、审批、实施、验证、回退。回退方案必须在实施前写好不能到变更失败现场再想。我之前吃过一次亏迁移完成后发现业务端口起不来回退方案里没写数据一致性校验步骤结果花了三个小时比对数据这比单次变更的耗时还长。4.3 故障处理流程告警分级与升级机制故障处理是分册里最不该含糊的部分。我见过太多分册写“发现故障及时上报”至于什么算故障、上报给谁、多长时间必须响应完全没有量化。云计算资源分册要把告警分级和升级机制写成一张可核对的责任表告警级别定义响应时限恢复时限通知对象一级业务整体中断15分钟2小时值班经理运维主管二级部分业务受影响或性能严重下降30分钟4小时运维主管三级资源池性能下降但业务可用1小时8小时一线运维工程师四级告警但不影响业务24小时72小时一线运维工程师升级机制要规定“一级故障每30分钟同步一次进展二级故障每2小时同步一次”避免故障处理变成少数人孤军奋战。另外分册里要写清楚故障复盘的动作根因分析、时间线梳理、整改措施、措施验证。没有复盘同样的故障大概率会在另一个宿主机上重演。5. 避坑指南执行分册常见的5个翻车点从现象到排查办法5.1 翻车点一台账与实际资源对不上现象季度清查时发现台账上写着380台虚拟机平台上实际有470台多出来的90台里有相当一部分已经超过3个月没有开机还占着存储配额。原因创建虚拟机走了审批流程回收虚拟机没有配套流程。管理员在平台上直接点删除台账没人更新也没有自动对账机制。解决在分册里加一条“台账自动对账”规定每周通过云平台API拉取全量资源清单与台账表比对差异项自动生成核查工单连续90天不登录的虚拟机自动冻结冻结后仍无人认领进入回收流程。这条规则落地后台账差异率会从十几个百分点降到接近零。5.2 翻车点二配额只设不放业务部门绕开流程现象配额设得很紧业务部门提扩容申请要经过三层审批、耗时一周于是业务部门直接在平台上自建虚拟机安全组规则自己配整个平台变成无政府状态。原因配额制度只考虑了资源安全没有考虑业务真实需求。审批流程过长导致业务方“用脚投票”。解决把配额默认值调到位按第三章的公式给足余量审批流程压缩到两层常规扩容24小时内完成同时在分册里明确“未纳入配额管理的资源视为违规创建一经发现立即回收”的处罚条款。配额制要让人“不想绕”而不是“不敢绕”。5.3 翻车点三容量预警阈值设置成“玄学”现象运维群一晚上收到40多条宿主机内存告警值班人员跑到机房一看业务运行平稳纯粹是内存使用率在85%附近反复横跳。原因阈值直接套用了物理机时代的经典值没有加“持续时间”条件也没有区分物理水位和逻辑水位。超配比高的池子里物理内存波动本来就频繁。解决预警阈值设置两个参数使用率阈值和持续时长阈值85%必须持续15分钟才触发告警同时把逻辑水位超配比单独设监控超配比超标比单台宿主机内存波动更需要关注。调完之后告警量至少降一半。5.4 翻车点四巡检只看云平台面板不看宿主机底层现象云平台管理界面上所有虚拟机状态都是“运行中”但客户投诉业务响应慢。排查后发现宿主机CPU的steal时间占比超过30%虚机在排队等物理核。原因云平台面板只反映逻辑层的健康状态物理层的争抢、存储链路的延迟在管理界面上经常被隐藏和美化。只看面板等于只看了黑匣子的外壳。解决巡检项里加入宿主机底层的硬指标CPU steal时间、内存swap用量、磁盘await、存储控制器IOPS这些数据要直连宿主机操作系统拿到不能依赖云平台管理面转发。分册里明确两条巡检线各自的数据来源管理面板一条宿主机操作系统一条。5.5 翻车点五变更文档与实际操作脱节现象变更方案里写的是在线迁移预估停机时间30分钟实际执行停机整整90分钟。业务窗口被击穿客户直接投诉到集团。原因源宿主机的磁盘类型是SSD目标宿主机是HDD存储差异导致在线迁移退化成数据全量复制方案编写时只看了文档模板没做环境预检。解决分册里把“迁移前置条件检查”设为硬性步骤变更新增一张预检表源和目标宿主机CPU型号是否兼容、存储类型是否一致、网络带宽是否满足差量数据同步要求。预检不通过变更不允许进入实施环节。这个动作能筛掉八成以上的迁移时长超预期事故。6. 把分册从纸面落成习惯用检查清单和模拟故障验证维护规定分册写完了最怕的就是放进文件柜吃灰。我自己的经验是用三件事检验规定到底有没有生效。第一件是月度检查清单巡线把分册里的关键动作浓缩成一张A4纸比如台账差异率、闲置资源数量、配额调整记录、巡检闭环率每个月花一小时逐项打勾哪个指标连续两个月不达标就说明对应章节在执行层面出了问题。第二件是季度模拟故障随机选一台宿主机强制断网看虚拟机自动迁移是否触发、告警链路是否畅通、值班人员是否能按分级响应表的时间线动作。演练当然会累但比起真实故障时的手忙脚乱成本低得多。第三件是月度容量评审把物理水位、逻辑水位、业务水位和云覆盖度四组数据放一起看趋势提前一个月发现超配风险比事后扩容便宜太多。我做维护规定修订这些年最大的教训是制度写得再完美都不如把关键动作做成自动化检查项。手动登记的台账会失真自动对账不会人写的变更方案会漏项预检脚本不会。如果你现在正要推行这样一份分册我建议先从“台账自动对账”和“迁移前置预检”这两个机制开始它们见效最快也最能赢得一线维护人员的信任。希望帮到你。本文还有配套的精品资源点击获取