简介：这份PPT是埃森哲大型集团管控信息化战略规划项目系列中的蓝图设计方案，聚焦基础设施架构与BPIT运营模式，面向集团信息化规划人员、企业架构师及IT咨询从业者，帮助解决多板块系统难集成、难共享、重复建设等长期痛点。资源包共1个pptx文件，约4.58MB，内容以架构蓝图、目标原则、解决方案等图文页为主，便于直接用于汇报或方案参考。目前已有398人学习下载。资料围绕智能混合云、物理集中与逻辑集中、服务平台化、集成平台、云资源管理与云服务交付等原则展开，并给出总体基础设施架构蓝图及IaaS、PaaS、传统交付三种模式，涵盖统一平台集成、业务应用集成、运行平台与数据架构需求等落地要点，可帮助读者快速理解集团级基础设施规划思路，对照梳理自身架构现状与演进路径。

1. 大型集团管控信息化蓝图里，基础设施架构到底在画什么

如果你接过集团型企业的信息化规划项目，大概率遇到过这种场面：业务部门抱怨系统慢、扩容难，IT 部门说预算不够、机房快满了，而集团高层只想知道——未来三年钱该往哪投、系统能不能撑住并购和扩张。这份「大型集团管控信息化战略规划项目系列之蓝图设计方案」里的基础设施架构部分，本质上就是回答这个问题的。它不聊某个具体产品怎么装，而是把整个集团的算力、存储、网络、容灾、云资源怎么分层、怎么归口、怎么演进，画成一张能落地、能评审、能拆预算的图。BPIT 运营模式是这套蓝图里最容易被忽略却最要命的一环——它决定了基础设施建完之后，谁来运营、按什么流程运营、成本怎么摊。混合云则是当前绝大多数集团在蓝图阶段绕不开的落地形态。这篇文章面向正在做或即将做集团信息化规划的人，把基础设施架构这一章从「画什么」讲到「怎么画、参数怎么定、评审时会被问什么」。

2. 基础设施架构蓝图的分层逻辑与 BPIT 运营模式的咬合点

2.1 为什么集团基础设施不能按单企业思路画

单体公司的 IT 基础设施架构，核心诉求是「够用、稳定、别太贵」。集团公司的诉求完全不同：它要处理多法人、多地域、多业态的管控关系。一个制造集团下面可能有十几个工厂、三四个事业部、若干合资公司，每个主体的 IT 自主权、预算来源、合规要求都不一样。如果基础设施架构不考虑这层管控关系，画出来的图就是一张好看但没法执行的网络拓扑。

我一般会把集团基础设施架构分成四个层次来看，这个分法在蓝图评审时最容易被各方接受：

这四层里，资源层和管控层是集团必须抓死的，平台层和服务层则要根据 BPIT 运营模式的成熟度来决定放权程度。BPIT 的核心含义是「Business Process & IT」，强调的是 IT 运营要嵌入业务流程，而不是 IT 自己关起门来运维。放到基础设施架构里，就是每一个基础设施能力都要对应到明确的业务服务承诺——比如「新工厂上线，网络和算力多久能就绪」这种问题，答案不在技术方案里，在运营模式里。

2.2 BPIT 运营模式在基础设施架构中的三个落点

BPIT 运营模式听起来抽象，落到基础设施架构上其实就三件事：谁决策、谁执行、谁买单。

决策权：哪些基础设施变更需要集团审批，哪些子公司可以自主决定。常见做法是设定投资额和影响范围两个阈值。比如单项目投资超过某个金额、或者涉及核心业务系统的基础设施变更，必须走集团评审；否则子公司 IT 自行决策，报备即可。

执行权：集团统一建设的基础设施，由集团 BPIT 运营团队负责日常运维；子公司自建部分，集团提供标准和工具，子公司自行运维但接受集团审计。这里最容易翻车的是边界模糊——子公司觉得集团管太多，集团觉得子公司不听话。解决办法是在蓝图阶段就把服务目录和职责矩阵（RACI）写清楚。

成本分摊：集团统一基础设施的成本怎么摊到各子公司，这是 BPIT 运营模式里最敏感的部分。常见做法有三种：按用量摊、按营收比例摊、按人头摊。混合云场景下，我一般建议按实际资源用量为主、固定比例为辅，因为云资源的用量是可计量的，按用量摊最容易被各方接受。

注意：成本分摊模型一定要在蓝图阶段就和财务部门对齐，否则基础设施建好了，账摊不下去，运营团队第一个季度就会被预算问题拖死。

2.3 混合云在集团蓝图中的定位与选型判断

混合云在集团基础设施架构里不是「要不要用」的问题，而是「哪些放私有、哪些放公有、怎么打通」的问题。我见过太多蓝图把混合云画成两朵云加一条线，评审时被问到「哪些业务放哪边、为什么」就答不上来。

选型判断我一般用四个维度来打分：

• 数据敏感度：核心财务数据、生产数据、客户隐私数据，优先私有云或专有环境。
• 弹性需求：有明显波峰波谷的业务（比如电商大促、月末结算），适合公有云的弹性资源。
• 合规要求：行业监管有明确数据驻留要求的，按监管要求定。
• 成本结构：长期稳定负载放私有更划算，短期弹性负载放公有更经济。

这四个维度打分之后，把业务系统分成三类：私有云优先、公有云优先、混合部署。混合部署的系统需要额外考虑网络延迟、数据同步、灾备切换，这些在蓝图里都要有明确的架构决策记录（ADR）。

2.4 画基础设施架构蓝图的最小步骤清单

如果你现在就要动手画这一章，按下面这个顺序走，不容易漏项：

1. 盘点现状：现有数据中心数量、机房等级、服务器和存储规模、网络带宽和拓扑、虚拟化平台版本、云资源使用情况。这一步的产出是一张现状架构图和一份资源清单。
2. 梳理业务需求：未来三年集团业务规划（并购、新工厂、新业务线）、各业务系统对基础设施的SLA要求、峰值负载预估。
3. 定义目标架构：按资源层、平台层、服务层、管控层分别画出目标态，标注哪些是新建、哪些是改造、哪些是迁移。
4. 设计 BPIT 运营模式：明确决策权、执行权、成本分摊三项机制，输出 RACI 矩阵和服务目录。
5. 制定演进路线：把目标架构拆成两到三个阶段，每个阶段有明确的里程碑和交付物。
6. 做投资估算：按阶段估算 CAPEX 和 OPEX，和财务部门对齐分摊模型。

这个顺序里，第 4 步是最容易被跳过的，但恰恰是决定蓝图能不能落地的关键。很多蓝图技术画得很漂亮，一到执行就卡在「谁出钱、谁运维」上。

3. 混合云基础设施架构的具体设计与参数设定

3.1 私有云侧的计算与存储参数怎么定

私有云侧的参数设定，核心是回答「建多大、留多少余量」。我一般按以下逻辑来算：

计算资源：先统计现有物理服务器的 CPU 和内存总核数，算出当前平均利用率和峰值利用率。目标架构的计算容量 = 峰值需求 × 1.3（冗余系数）。如果现有利用率已经超过 70%，说明该扩容了；如果低于 30%，说明该整合或迁移到公有云了。

存储资源：分成三类来算——生产存储（数据库、核心系统）、文件存储（文档、影像）、备份存储。生产存储按 IOPS 和容量双维度规划，文件存储按容量规划，备份存储按保留策略规划。常见做法是生产存储保留 20% 以上余量，备份存储按全量备份 + 增量备份的保留周期来算。

网络资源：集团总部到各分支机构的带宽，按业务系统访问量和并发用户数估算。核心链路建议双线冗余，带宽预留 40% 以上余量。

下面是一个容量估算的参考脚本，用 Python 做简单的计算：

# 集团私有云容量估算参考 # 输入：现有资源清单和业务增长预期 # 现有物理服务器资源 current_cpu_cores = 800 # 现有 CPU 总核数 current_memory_gb = 3200 # 现有内存总量 GB current_storage_tb = 200 # 现有存储总量 TB avg_cpu_utilization = 0.65 # 平均 CPU 利用率 peak_cpu_utilization = 0.85 # 峰值 CPU 利用率 # 业务增长预期 annual_growth_rate = 0.15 # 年增长率 15% planning_years = 3 # 规划周期 3 年 # 冗余系数 redundancy_factor = 1.3 # 计算资源冗余 storage_reserve = 1.2 # 存储余量 # 计算三年后的需求 growth_factor = (1 + annual_growth_rate) ** planning_years target_cpu = current_cpu_cores * growth_factor * redundancy_factor target_memory = current_memory_gb * growth_factor * redundancy_factor target_storage = current_storage_tb * growth_factor * storage_reserve print(f"三年后 CPU 需求: {target_cpu:.0f} 核") print(f"三年后内存需求: {target_memory:.0f} GB") print(f"三年后存储需求: {target_storage:.0f} TB") # 判断是否需要扩容 if peak_cpu_utilization > 0.8: print("警告：当前峰值利用率过高，建议优先扩容") elif avg_cpu_utilization < 0.3: print("提示：当前平均利用率偏低，可考虑资源整合或迁移")

这段脚本的逻辑很直白：用现有资源乘以增长系数和冗余系数，得到目标容量。参数方面，annual_growth_rate要根据集团实际业务规划来调，如果是并购活跃期，这个值可能到 25% 以上；redundancy_factor一般取 1.2 到 1.5，取决于业务对弹性的要求。跑完这个脚本，你手里就有一组可以拿去和财务、采购对话的数字了。

3.2 公有云侧的选型与接入参数

公有云侧的参数设定，重点不在「选哪家」，而在「怎么接、怎么管、怎么控成本」。集团场景下，我一般建议至少接入两家公有云，避免单一供应商锁定，但也不要超过三家，否则管理成本会吃掉多云带来的收益。

接入参数方面，需要明确这几项：

• 网络接入方式：专线还是互联网链路。核心业务系统建议专线，非核心的互联网链路即可。专线带宽按业务峰值流量 × 1.5 来定。
• 账号体系：集团统一管理主账号，各子公司或业务线使用子账号，通过企业组织（Organization）或资源目录来管理。这一步在蓝图里就要定好，否则后期账号混乱，成本根本管不住。
• 网络互通：私有云和公有云之间的网络互通，常见做法是建立专用通道或使用云厂商的混合云网络产品。延迟要求高的业务，要评估物理距离和链路质量。
• 安全策略：统一的安全组策略、访问控制、加密传输，这些在蓝图里要有明确的基线要求。

3.3 容灾与备份架构的关键指标

容灾和备份是集团基础设施架构里最花钱的部分，也是最容易被砍预算的部分。我的经验是：不要试图对所有系统做同等容灾，而是按业务重要性分级。

RTO 是恢复时间目标，RPO 是恢复点目标。这两个指标直接决定了容灾方案的成本。一级系统做双活，成本可能是三级系统的几十倍。所以在蓝图阶段，一定要和业务部门确认每个系统的等级，不能由 IT 单方面定。

备份策略方面，常见做法是「全量 + 增量 + 日志」三层组合。全量备份每周一次，增量备份每天一次，日志备份按需（比如每 15 分钟）。保留周期根据合规要求来定，一般至少保留 6 个月。

3.4 基础设施架构蓝图的评审要点

蓝图画完之后，评审是最关键的一关。根据我的经验，评审时被问得最多的是这几个问题：

1. 这个架构能支撑未来三年的业务增长吗？你需要拿出容量估算的数据来回答。
2. 混合云的网络延迟对业务有影响吗？你需要有具体的延迟测试数据或估算。
3. 容灾切换做过演练吗？蓝图阶段至少要有演练计划。
4. 成本分摊模型财务认可吗？这是 BPIT 运营模式的核心，必须提前对齐。
5. 和现有系统的兼容性怎么处理？特别是老系统的迁移路径要清晰。

评审前，建议把这些问题做成一份自查清单，逐项准备好答案。我见过太多蓝图因为成本分摊模型没和财务对齐，在评审会上被当场打回。

4. 基础设施架构落地时最容易翻车的五个地方

4.1 容量规划拍脑袋，上线三个月就告急

现象：蓝图里写的计算和存储容量，系统上线三个月就不够用了，业务部门投诉不断。

原因：容量估算只看了现有利用率，没考虑业务增长和新技术引入带来的额外开销。比如容器化之后，虽然单实例资源占用降低了，但实例数量可能翻倍，总体资源需求反而上升。

解决：容量规划至少按三年做，每年回顾一次。冗余系数不要低于 1.3，业务增长快的板块单独估算。另外，预留一部分「缓冲池」资源，不分配到具体业务，专门应对突发需求。

4.2 混合云网络打通了，但延迟让业务没法用

现象：私有云和公有云之间的网络通了，但业务系统跨云访问时延迟高得离谱，用户体验极差。

原因：只关注了网络连通性，没关注链路质量和物理距离。跨地域的云访问，延迟可能到几十毫秒甚至上百毫秒，对交互式业务是致命的。

解决：在蓝图阶段就做延迟评估。核心业务系统尽量部署在同一朵云或同一地域内，跨云访问只用于非实时场景。如果必须跨云，考虑使用云厂商的加速链路或边缘节点。

4.3 BPIT 运营职责不清，出问题互相推诿

现象：系统出故障了，集团 IT 说是子公司运维没做好，子公司说是集团平台不稳定，最后没人负责。

原因：蓝图里只画了技术架构，没画运营职责矩阵。谁负责监控、谁负责响应、谁负责升级，没有明确。

解决：在蓝图里加入 RACI 矩阵，明确每项基础设施服务的 Responsible、Accountable、Consulted、Informed 角色。特别是跨集团和子公司的服务，边界要写清楚。我一般建议在蓝图评审时，让各方的运维负责人签字确认。

4.4 成本分摊模型太复杂，财务算不清账

现象：基础设施建好了，但每个月的成本分摊算不出来，财务部门拒绝入账。

原因：分摊模型设计得太复杂，涉及太多变量，财务部门没法从现有账务系统里取数。

解决：分摊模型要简单可执行。按用量摊就用云平台自带的计量数据，按比例摊就用财务现有的营收或人头数据。不要设计需要额外手工统计的模型。蓝图阶段就和财务确认取数来源和计算逻辑。

4.5 容灾方案只写在纸上，从没演练过

现象：蓝图里写了完整的容灾方案，但真出故障时切换失败，业务中断远超 RTO。

原因：容灾方案没有经过实际演练，配置错误、脚本失效、人员不熟悉流程等问题在真实故障时集中爆发。

解决：蓝图里必须包含演练计划。一级系统至少每半年演练一次，二级系统每年一次。演练后要有复盘报告，更新容灾方案。我一般会把演练结果作为蓝图验收的一项硬指标。

5. 用架构决策记录把蓝图里的「为什么」留下来

做集团基础设施架构蓝图，最怕的不是技术选型难，而是过了半年有人问你「当初为什么这么定」的时候，你答不上来。我自己的习惯是，蓝图里每一个关键决策都配一份架构决策记录（ADR），格式很简单：

# ADR-001: 核心业务系统采用私有云优先部署 ## 状态 已批准 ## 背景 集团核心 ERP 和财务系统承载敏感数据，行业监管要求数据驻留境内， 且业务对延迟敏感，峰值时段并发高。 ## 决策 核心 ERP 和财务系统部署在集团私有云，不迁移至公有云。 公有云仅用于非核心系统的弹性扩展和灾备。 ## 理由 1. 数据敏感度和合规要求 2. 延迟要求：核心系统跨云访问延迟不可接受 3. 长期稳定负载，私有云成本更优 ## 后果 - 私有云需要预留足够容量，CAPEX 投入较高 - 弹性扩展能力受限，需通过混合云灾备弥补 - 需建立私有云运维团队，BPIT 运营模式需覆盖

ADR 的好处是，它把决策的背景、理由和后果都记录下来了。半年后有人质疑这个决策，你不需要重新论证，直接翻出 ADR 就行。评审时，ADR 也是最有说服力的材料——它证明你不是拍脑袋，而是有逻辑地做了取舍。

我一般会在蓝图交付物里单独放一个 ADR 目录，每个关键决策一份。数量不用多，一个集团基础设施架构蓝图，十到十五份 ADR 就够了。重点覆盖：混合云策略、容灾等级划分、网络架构选型、成本分摊模型、BPIT 运营职责边界。

还有一个实操技巧：ADR 不要写完就锁进文件夹。每次蓝图回顾或架构变更时，同步更新 ADR 的状态。被推翻的决策不要删，标记为「已废弃」并写上废弃原因。这样整个决策链条是完整的，后来的人能看懂架构演进的来龙去脉。

我自己踩过最大的坑，是早期做蓝图时只画图不写 ADR，结果项目换了负责人之后，新来的人把之前的容灾方案推倒重来，多花了半年时间和一笔冤枉钱。从那以后，我每份蓝图都强制配 ADR，哪怕客户没要求。这个习惯帮我省下的返工时间，远比写 ADR 花的时间多。希望帮到你。

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