简介这份PPT是埃森哲大型集团管控信息化战略规划项目系列中的蓝图设计方案聚焦基础设施架构与BPIT运营模式面向集团信息化规划人员、企业架构师及IT管理者用于解决多业务系统难集成、难共享、重复建设等长期痛点。资源共1个pptx文件压缩包约4.58MB内容以架构蓝图、目标原则、解决方案等图文页为主结构清晰便于汇报与参考。目前已有398人学习下载。资料系统梳理了基础设施架构目标与架构原则涵盖物理集中、逻辑集中、服务平台化、集成平台、云资源管理与云服务交付等要点并给出总体基础设施架构蓝图包括新一代智能混合云、企业级流程规范与标准化管理、统一平台、资源集中与平台化应用同时从统一平台集成、业务应用集成与集中、运行平台、数据架构及规划原则等维度展开解决方案可帮助读者快速理解集团级基础设施架构的规划逻辑与落地路径。1. 从一份 80 页 PPT 说起大型集团基础设施架构到底在规划什么如果你手里正躺着一份《埃森哲-大型集团管控信息化战略规划项目系列之蓝图设计方案 – 基础设施架构BPIT运营模式.pptx》翻了两页发现全是“智能混合云”“资源总线”“服务门户”这类词却不知道它到底能拿来干什么这篇就是写给你的。这份 PPT 不是技术白皮书而是一份典型的大型集团管控信息化战略规划蓝图设计交付物核心解决的是集团总部与下属板块之间基础设施怎么统、怎么分、怎么管的问题。它把基础设施架构拆成目标原则、总体蓝图、解决方案三层覆盖计算存储、网络、机房、备份容灾、任务调度、云服务门户等模块每个模块都给出了组件能力和规划原则。适合谁看正在做集团级 IT 规划、需要写基础设施架构方案、或者要评估混合云落地路径的从业者。它不教你怎么装一台服务器但能告诉你一个多板块集团的基础设施应该长成什么样以及每一步的决策依据是什么。2. 智能混合云的目标与原则为什么先定“集中化、平台化、云服务”2.1 架构目标不是口号是六条可验证的约束这份方案开篇就把基础设施架构目标定在“建立新一代的智能混合云”但真正有价值的是目标背后的六条约束。第一条是提升 BPIT 基础设施在全集团的协同效应说白了就是各板块不能再各建各的机房、各买各的存储。第二条是支撑集团管控能力提升基础设施要能承载企业级流程规范和标准化管理。第三条是单一界面集中控制所有信息化资产这条直接决定了后面服务门户和资源总线的设计。第四条是基于分析的策略驱动方法意味着资源分配不能靠拍脑袋要有计量和监控数据支撑。第五条是开放、可扩展、可集成的混合云平台避免被单一厂商锁死。第六条是智能集成基础设施、应用程序、数据和流程向业务提供服务。这六条不是并列关系而是层层递进协同效应是结果管控能力是目的单一界面是手段策略驱动是方法开放可扩展是底线智能集成是最终形态。你在写自己的方案时可以把这六条直接改写成验收标准比如“是否实现了跨板块资源统一调度”“是否具备资源使用计量能力”。2.2 集中化、平台化、云服务三条原则怎么落到具体决策方案把规划原则收敛为三条集中化、平台化、云服务。集中化又分物理集中和逻辑集中。物理集中是共性系统总部统一建设、集中运营比如财务应用、人力资源系统逻辑集中是同一应用逻辑上为一套保证流程和管控规范哪怕物理上分散部署。平台化分服务平台和集成平台服务平台把应用拆成独立的业务能力服务单元每个单元完成独立任务集成平台通过应用集成和服务集成把独立服务按需求编排成业务应用。云服务分云资源管理和云服务交付云资源管理对基础设施、运行环境等资源集中管控和灵活调度云服务交付提供服务管理、服务计量和服务质量保证。这三条原则不是拍脑袋来的而是针对三个具体问题同类应用多地部署造成资源浪费和缺乏规范用集中化解决应用系统集中后跨系统流程整合困难用平台化解决技术资源统筹管理、灵活调度和资源交付服务化不足用云服务解决。我一般会在方案里把这三条原则和具体问题一一对应评审时谁问“为什么要集中化”直接翻到问题页。2.3 从原则到落地物理集中和逻辑集中的操作边界物理集中和逻辑集中最容易混淆方案里给了明确的落地边界。物理集中的操作包括集团总部数据中心扩展计算能力构建云服务计算资源中心支持集团管控应用运行容灾中心扩展存储能力构建行业测试中心为下属子公司提供异地容灾服务。逻辑集中的操作包括集团总部规范应用系统运行环境的技术路线逐步实现应用运行、测试、运维管理环境的集中化明确行业数据中心的组成建设行业统一的数据中心为各类用户提供统一数据服务。这里的关键区别是物理集中动的是硬件和机房逻辑集中动的是运行环境和技术路线。常见做法是先把新建系统纳入物理集中范围已建系统通过逻辑集中逐步收敛。参数上方案没有给具体的服务器数量或存储容量但给出了判断标准共性系统总部统一建设分级部署系统由云服务与各下属子公司私有云资源依据承载应用范围分工合作。你在实操时可以按“新建系统必须物理集中、已建系统先逻辑集中再评估物理迁移”的节奏推进。3. 总体基础设施架构蓝图技术能力提供与交付怎么拆3.1 两大部分技术能力提供和技术能力交付总体架构蓝图把基础设施架构分成两大部分技术能力提供和技术能力交付。技术能力提供包括基础设施架构中各项物理的技术能力组件是技术能力的提供中心通过基础设施、数据等资源的部署、配置、安全和运营管理借助集成、展现等技术平台保证集团具备所需的技术提供能力。技术能力交付通过云计算的架构模式通过资源总线实现对技术能力单元的动态调配通过服务总线实现技术能力的服务化运维管理和服务化编排在服务门户的统一管理下实现面向各级用户的服务化交付。这个拆法的好处是提供和交付分离提供侧关注资源怎么建、怎么管交付侧关注服务怎么编排、怎么给。你在画自己的架构图时可以左边画提供侧的能力单元右边画交付侧的总线和门户中间用虚拟层隔开。方案里还给了实现及保障、需求及编排两个横向支撑前者对应安全、备份、监控等保障能力后者对应服务目录、订单管理等编排能力。3.2 IaaS、PaaS 和传统交付三种模式的选择依据方案明确未来技术能力的交付将分为 IaaS、PaaS 和传统交付三种模式。IaaS 模式是基础设施资源通过云平台实现服务化包括基础硬件、计算、存储、网络、机房通过虚拟化资源池形成虚拟主机、虚拟存储、虚拟网络再通过 IaaS 资源总线接入服务总线。PaaS 模式分两种PaaS 模式 1 是数据、集成、运行环境等资源在 IaaS 基础上通过云平台实现服务化PaaS 模式 2 是这些资源在物理资源基础上通过云平台实现服务化。传统模式是非云化资源沿用传统的能力交付模式不通过云平台交付。选择依据很直接新建的、标准化的、共性化的系统走 IaaS 或 PaaS 模式已建的、非标准化的、有特殊硬件依赖的系统走传统模式。方案里特别提到交互服务和云平台服务门户在 SaaS 模式下将存在连接这意味着如果你的集团有 SaaS 层应用服务门户需要预留对接能力。我一般会在方案里画一张决策树系统是否新建、是否标准化、是否有特殊硬件依赖三个问题定交付模式。3.3 计算与存储主机、存储、备份的组件能力与规划原则计算与存储部分方案拆成主机、存储、备份三个组件。主机分开放架构主机和主机架构开放架构设备以 PC Server 为主小型机设备一般不选择开放架构对开放架构的 PC Server 平台应明确虚拟化技术方向实现资源平台化并为行业私有云建设准备条件主机架构用于对高可靠性、高计算能力需求的核心业务系统提供计算服务主机架构应尽量统一保证兼容性。存储部分行业核心存储网络以 SAN 为主要技术方案新建计算中心可考虑 IP 网络和存储网络的融合解决方案集团总部计算中心应建立存储分级机制实现存储资源高效利用。备份部分行业各级本地备份由各级单位自行建设各下属子公司的异地备份应通过集团总部上海容灾中心进行建立针对数据分类的备份介质的离场管理和归档管理机制。这里有几个参数值得注意SAN 是核心存储网络的主要技术方案不是唯一方案存储分级机制是集团总部的强制要求异地备份的归口是上海容灾中心。你在写自己的存储方案时可以把这三条直接作为评审要点。4. 云服务架构与网络虚拟化、资源总线、服务门户怎么配4.1 虚拟化技术组件虚拟主机、虚拟网络、虚拟存储、资源管理云服务架构的虚拟化部分拆成四个组件虚拟主机、虚拟网络、虚拟存储、资源管理。虚拟主机的规划原则是集团主机虚拟化平台应以开放架构虚拟化主机为基本路线主机架构虚拟化以单机虚拟化应用为主开放平台架构虚拟化以高端 PC Server 为核心硬件平台。虚拟网络的规划原则是集中式计算中心虚拟平台虚拟网络应以集中虚拟交换机为主前置环境等分散计算环境应以分散式虚拟交换机为主虚拟网络分区应首先保证安全分区隔离的需求。虚拟存储的规划原则是行业应用目前仍以集中式关系型数据库为主以事务交易为主应为虚拟平台配置集中式存储由于数据基本按属地存储暂不考虑存储的异地迁移。资源管理的规划原则是每个虚拟环境部署独立的虚拟资源管理平台集团总部通过联邦机制对分散的虚拟资源管理平台进行集中管理。这四个组件的配置逻辑是虚拟主机定硬件路线虚拟网络定隔离方式虚拟存储定数据存放策略资源管理定管控粒度。常见坑是虚拟网络分区没做好安全隔离导致不同安全域的业务跑在同一虚拟交换机上。我一般会在方案里强制要求虚拟网络分区必须与安全分区一一对应集中环境用集中虚拟交换机分散环境用分散式虚拟交换机。4.2 资源总线资源定义、计量、编排、可靠性的配置顺序资源总线实现云资源的分配、回收、变更过程的自动化负责管理资源的工作负载将服务请求转化为资源请求并调度资源。方案给了四个组件资源定义、资源计量、资源编排、资源可靠性。资源定义的规划原则是与资源编排组件、资源监控和容量管理等组件共同完成资源模块化的交付资源定义和模型化是实现资源服务化管理的基础在云服务建设初期应进行规划部署。资源计量的规划原则是资源计量组件为云服务服务总线提供资源使用情况信息是基础性的云服务技术组件集团总部云服务建设初期应规划部署技术实现应与 ITSM 系统相关组件集成实现信息交换。资源编排的规划原则是云服务应实现按照负载均衡原则对资源池组件的编排管理应实现根据预定义工作流系统自动对 IaaS 资源进行编排应支持人工资源编排PaaS 资源可仅通过人工进行资源编排。资源可靠性的规划原则是云服务服务初期规划部署非核心应用暂缓部署资源高可靠性相关技术组件。配置顺序很关键先做资源定义和资源计量再做资源编排最后考虑资源可靠性。方案里明确说资源可靠性初期暂缓这意味着不要一上来就追求高可用先把资源定义和计量跑通。你在实操时可以按“定义→计量→编排→可靠性”的顺序分阶段上线。4.3 服务门户服务目录、订单管理、使用报告、计费管理的上线节奏服务门户为用户提供服务查询、订单管理等功能实现自助化并提供服务推广等功能云服务门户应与 ITSM 服务门户集成建设。方案给了四个组件服务目录、订单管理、使用报告、计费管理。服务目录的规划原则是云服务优先考虑 PaaS 类服务的服务目录展示IaaS 主要针对集团总部内部用户的阶段可暂不纳入门户中展示服务目录管理与 ITSM 服务管理整合。订单管理的规划原则是订单管理是实现用户自助服务的前提在提供用户自助服务前可不部署此类组件订单管理的关键点在于订单向服务的转换特别是主计算中心和上海容灾中心间的多点转换问题。使用报告的规划原则是使用报告技术能力应实现对各类用户实际对云服务平台上服务使用情况的统计和报表化展现包括服务质量、服务成本等多样化的统计分析使用报告相应管理流程应与 ITSM 平台整合。计费管理的规划原则是云服务主要针对行业内部客户使用初期可不部署计费管理模块但应设计相应接口可实现模拟的服务计量作为云服务平台收益的评估参考重点在于计费模块应支持多种方式的计费管理和定价模型应与 ITSM 服务成本管理集成整合。上线节奏建议先上服务目录和使用报告再上订单管理最后上计费管理。方案里明确说计费管理初期可不部署但接口要预留这是典型的“先通后优”思路。4.4 网络节点、连接、远程访问的规划原则网络部分拆成三个组件网络节点、网络连接、远程访问。网络节点的规划原则是行业各级单位分别负责各自网络节点建设行业核心网络节点应具备充分的交换能力各级网络节点应依据应用系统安全分类进行可靠的安全隔离同一安全区域内不同架构层级设备宜通过虚拟网络进行隔离集团总部对行业提供服务的区域应单独部署网络。网络连接的规划原则是行业网络连接采用北京、上海双中心的结构符合行业需求对通过上海容灾中心进行异地数据备份的单位连接带宽应评估优化北京和上海间的连接带宽为满足数据中心数据复制的需求建议评估优化。远程访问的规划原则是各网络节点可分别建立远程访问技术组件集团总部对行业性用户提供统一接入服务。这里的关键参数是北京、上海双中心结构以及北京和上海间的连接带宽需要评估优化。常见坑是异地数据备份的带宽没算够导致备份窗口超时。我一般会在方案里要求北京和上海间的连接带宽按数据复制峰值流量的 1.5 倍配置并预留扩容能力。5. 避坑与排查基础设施架构规划里最容易翻车的五件事5.1 现象虚拟化平台选型时开放架构和主机架构混用导致兼容性问题频发原因方案里明确说开放架构设备以 PC Server 为主主机架构用于高可靠性、高计算能力需求的核心业务系统但实操中经常有人把两种架构混在一个虚拟化平台里以为虚拟化层能屏蔽差异。实际上主机架构虚拟化以单机虚拟化应用为主开放平台架构虚拟化以高端 PC Server 为核心硬件平台两者的虚拟化技术路线不同混用会导致资源池无法统一调度。解决按业务系统分级核心业务系统用主机架构非核心业务系统用开放架构两套虚拟化平台分开建设通过资源管理平台的联邦机制做集中管理不要强行合并资源池。5.2 现象资源总线先上了资源可靠性组件结果资源定义和计量还没跑通整个云服务交付卡住原因方案里明确说资源可靠性初期暂缓部署资源定义和资源计量是基础性组件应在云服务建设初期规划部署。但实操中经常有人觉得高可用重要先把可靠性组件上了结果资源定义没做完资源编排没有模板可用资源计量没做完服务总线拿不到使用数据整个交付链路断掉。解决严格按“资源定义→资源计量→资源编排→资源可靠性”的顺序推进初期只部署资源定义和资源计量资源编排先支持人工编排资源可靠性等非核心应用跑通后再考虑。5.3 现象服务门户先上了计费管理结果服务目录和订单管理还没建好用户根本用不起来原因方案里明确说计费管理初期可不部署但应设计相应接口服务目录优先考虑 PaaS 类服务展示订单管理在提供用户自助服务前可不部署。但实操中经常有人觉得计费是云服务成熟的标志先把计费上了结果服务目录没建好用户不知道有什么服务可买订单管理没建好用户买了服务没人处理。解决先上服务目录和使用报告让用户看到有什么服务、用了多少再上订单管理让用户能自助下单最后上计费管理初期只做模拟计量接口预留等 ITSM 服务成本管理成熟后再对接。5.4 现象异地备份带宽没算够备份窗口超时容灾演练失败原因方案里明确说对通过上海容灾中心进行异地数据备份的单位连接带宽应评估优化北京和上海间的连接带宽为满足数据中心数据复制的需求建议评估优化。但实操中经常有人按日常流量估算带宽没算备份峰值流量导致备份窗口内传不完容灾演练时数据不一致。解决按数据复制峰值流量的 1.5 倍配置北京和上海间的连接带宽并预留扩容能力备份策略按数据分类分级核心数据优先备份非核心数据错峰备份容灾演练前先做带宽压力测试。5.5 现象虚拟网络分区没做安全隔离不同安全域的业务跑在同一虚拟交换机上原因方案里明确说虚拟网络分区应首先保证安全分区隔离的需求同一安全区域内不同架构层级设备宜通过虚拟网络进行隔离。但实操中经常有人图省事把所有虚拟主机挂在同一个虚拟交换机上靠防火墙做隔离结果虚拟交换机层面的广播风暴和安全漏洞无法隔离。解决虚拟网络分区与安全分区一一对应集中环境用集中虚拟交换机分散环境用分散式虚拟交换机同一安全区域内不同架构层级设备通过虚拟网络隔离跨安全区域流量必须经过防火墙。6. 从蓝图到落地用“组件能力规划原则”做架构评审的实操技巧这份 PPT 最值钱的地方不是架构图而是每个技术组件都配了“组件能力”和“规划原则”两段话。组件能力告诉你这个组件能干什么规划原则告诉你这个组件应该怎么配。我一般会把这两段话直接改写成架构评审的检查项。比如虚拟化技术组件组件能力是开放架构资源虚拟化技术组件和主机架构资源虚拟化技术组件规划原则是开放架构虚拟化主机为基本路线、主机架构虚拟化以单机虚拟化应用为主、开放平台架构虚拟化以高端 PC Server 为核心硬件平台。评审时直接问你的虚拟化平台是开放架构还是主机架构开放架构是不是以 PC Server 为主主机架构是不是单机虚拟化三个问题就能判断方案是否合规。再比如资源总线组件能力是资源模板设计和资源模板应用管理规划原则是与资源编排组件、资源监控和容量管理等组件共同完成资源模块化的交付资源定义和模型化是实现资源服务化管理的基础在云服务建设初期应进行规划部署。评审时直接问资源定义和模型化做了没有资源模板设计有没有资源编排组件、资源监控和容量管理组件是否协同三个问题就能判断资源总线是否具备上线条件。我习惯把这份 PPT 的每个技术组件做成一张检查表左边是组件能力右边是规划原则中间是评审问题。比如服务门户的检查表服务目录的组件能力是服务目录展示、服务目录同步规划原则是优先考虑 PaaS 类服务展示、IaaS 暂不纳入门户、与 ITSM 服务管理整合评审问题是服务目录是否优先展示 PaaS 服务、IaaS 是否暂不纳入、是否与 ITSM 整合。订单管理的组件能力是订单接收、订单分解、订单请求分发规划原则是提供用户自助服务前可不部署、关键点是订单向服务的转换、特别是主计算中心和上海容灾中心间的多点转换评审问题是自助服务是否已提供、订单向服务转换是否跑通、多点转换是否处理。使用报告的组件能力是服务使用统计和使用报告展现规划原则是统计服务质量和服务成本、与 ITSM 平台整合评审问题是统计维度是否包含服务质量和服务成本、是否与 ITSM 整合。计费管理的组件能力是服务计费、服务定价规划原则是初期可不部署、设计接口、支持多种计费管理和定价模型、与 ITSM 服务成本管理集成评审问题是初期是否暂不部署、接口是否预留、计费模型是否支持多种方式、是否与 ITSM 集成。这套检查表的好处是评审时不用争论“要不要做”直接对照组件能力和规划原则缺什么补什么。我一般会在项目启动会上就把检查表发给各模块负责人让他们自己先对照一遍评审时只讨论有争议的条目。从那以后我每次做基础设施架构评审都强制走一遍“组件能力→规划原则→评审问题”的检查表再也没出现过方案写完才发现漏了关键组件的情况。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/23 16:58:42 · 阅读 1.2k 大型集团智能混合云基础设施架构规划：组件能力与规划原则全解析
简介这份PPT是埃森哲大型集团管控信息化战略规划项目系列中的蓝图设计方案聚焦基础设施架构与BPIT运营模式面向集团信息化规划人员、企业架构师及IT管理者用于解决多业务系统难集成、难共享、重复建设等长期痛点。资源共1个pptx文件压缩包约4.58MB内容以架构蓝图、目标原则、解决方案等图文页为主结构清晰便于汇报与参考。目前已有398人学习下载。资料系统梳理了基础设施架构目标与架构原则涵盖物理集中、逻辑集中、服务平台化、集成平台、云资源管理与云服务交付等要点并给出总体基础设施架构蓝图包括新一代智能混合云、企业级流程规范与标准化管理、统一平台、资源集中与平台化应用同时从统一平台集成、业务应用集成与集中、运行平台、数据架构及规划原则等维度展开解决方案可帮助读者快速理解集团级基础设施架构的规划逻辑与落地路径。1. 从一份 80 页 PPT 说起大型集团基础设施架构到底在规划什么如果你手里正躺着一份《埃森哲-大型集团管控信息化战略规划项目系列之蓝图设计方案 – 基础设施架构BPIT运营模式.pptx》翻了两页发现全是“智能混合云”“资源总线”“服务门户”这类词却不知道它到底能拿来干什么这篇就是写给你的。这份 PPT 不是技术白皮书而是一份典型的大型集团管控信息化战略规划蓝图设计交付物核心解决的是集团总部与下属板块之间基础设施怎么统、怎么分、怎么管的问题。它把基础设施架构拆成目标原则、总体蓝图、解决方案三层覆盖计算存储、网络、机房、备份容灾、任务调度、云服务门户等模块每个模块都给出了组件能力和规划原则。适合谁看正在做集团级 IT 规划、需要写基础设施架构方案、或者要评估混合云落地路径的从业者。它不教你怎么装一台服务器但能告诉你一个多板块集团的基础设施应该长成什么样以及每一步的决策依据是什么。2. 智能混合云的目标与原则为什么先定“集中化、平台化、云服务”2.1 架构目标不是口号是六条可验证的约束这份方案开篇就把基础设施架构目标定在“建立新一代的智能混合云”但真正有价值的是目标背后的六条约束。第一条是提升 BPIT 基础设施在全集团的协同效应说白了就是各板块不能再各建各的机房、各买各的存储。第二条是支撑集团管控能力提升基础设施要能承载企业级流程规范和标准化管理。第三条是单一界面集中控制所有信息化资产这条直接决定了后面服务门户和资源总线的设计。第四条是基于分析的策略驱动方法意味着资源分配不能靠拍脑袋要有计量和监控数据支撑。第五条是开放、可扩展、可集成的混合云平台避免被单一厂商锁死。第六条是智能集成基础设施、应用程序、数据和流程向业务提供服务。这六条不是并列关系而是层层递进协同效应是结果管控能力是目的单一界面是手段策略驱动是方法开放可扩展是底线智能集成是最终形态。你在写自己的方案时可以把这六条直接改写成验收标准比如“是否实现了跨板块资源统一调度”“是否具备资源使用计量能力”。2.2 集中化、平台化、云服务三条原则怎么落到具体决策方案把规划原则收敛为三条集中化、平台化、云服务。集中化又分物理集中和逻辑集中。物理集中是共性系统总部统一建设、集中运营比如财务应用、人力资源系统逻辑集中是同一应用逻辑上为一套保证流程和管控规范哪怕物理上分散部署。平台化分服务平台和集成平台服务平台把应用拆成独立的业务能力服务单元每个单元完成独立任务集成平台通过应用集成和服务集成把独立服务按需求编排成业务应用。云服务分云资源管理和云服务交付云资源管理对基础设施、运行环境等资源集中管控和灵活调度云服务交付提供服务管理、服务计量和服务质量保证。这三条原则不是拍脑袋来的而是针对三个具体问题同类应用多地部署造成资源浪费和缺乏规范用集中化解决应用系统集中后跨系统流程整合困难用平台化解决技术资源统筹管理、灵活调度和资源交付服务化不足用云服务解决。我一般会在方案里把这三条原则和具体问题一一对应评审时谁问“为什么要集中化”直接翻到问题页。2.3 从原则到落地物理集中和逻辑集中的操作边界物理集中和逻辑集中最容易混淆方案里给了明确的落地边界。物理集中的操作包括集团总部数据中心扩展计算能力构建云服务计算资源中心支持集团管控应用运行容灾中心扩展存储能力构建行业测试中心为下属子公司提供异地容灾服务。逻辑集中的操作包括集团总部规范应用系统运行环境的技术路线逐步实现应用运行、测试、运维管理环境的集中化明确行业数据中心的组成建设行业统一的数据中心为各类用户提供统一数据服务。这里的关键区别是物理集中动的是硬件和机房逻辑集中动的是运行环境和技术路线。常见做法是先把新建系统纳入物理集中范围已建系统通过逻辑集中逐步收敛。参数上方案没有给具体的服务器数量或存储容量但给出了判断标准共性系统总部统一建设分级部署系统由云服务与各下属子公司私有云资源依据承载应用范围分工合作。你在实操时可以按“新建系统必须物理集中、已建系统先逻辑集中再评估物理迁移”的节奏推进。3. 总体基础设施架构蓝图技术能力提供与交付怎么拆3.1 两大部分技术能力提供和技术能力交付总体架构蓝图把基础设施架构分成两大部分技术能力提供和技术能力交付。技术能力提供包括基础设施架构中各项物理的技术能力组件是技术能力的提供中心通过基础设施、数据等资源的部署、配置、安全和运营管理借助集成、展现等技术平台保证集团具备所需的技术提供能力。技术能力交付通过云计算的架构模式通过资源总线实现对技术能力单元的动态调配通过服务总线实现技术能力的服务化运维管理和服务化编排在服务门户的统一管理下实现面向各级用户的服务化交付。这个拆法的好处是提供和交付分离提供侧关注资源怎么建、怎么管交付侧关注服务怎么编排、怎么给。你在画自己的架构图时可以左边画提供侧的能力单元右边画交付侧的总线和门户中间用虚拟层隔开。方案里还给了实现及保障、需求及编排两个横向支撑前者对应安全、备份、监控等保障能力后者对应服务目录、订单管理等编排能力。3.2 IaaS、PaaS 和传统交付三种模式的选择依据方案明确未来技术能力的交付将分为 IaaS、PaaS 和传统交付三种模式。IaaS 模式是基础设施资源通过云平台实现服务化包括基础硬件、计算、存储、网络、机房通过虚拟化资源池形成虚拟主机、虚拟存储、虚拟网络再通过 IaaS 资源总线接入服务总线。PaaS 模式分两种PaaS 模式 1 是数据、集成、运行环境等资源在 IaaS 基础上通过云平台实现服务化PaaS 模式 2 是这些资源在物理资源基础上通过云平台实现服务化。传统模式是非云化资源沿用传统的能力交付模式不通过云平台交付。选择依据很直接新建的、标准化的、共性化的系统走 IaaS 或 PaaS 模式已建的、非标准化的、有特殊硬件依赖的系统走传统模式。方案里特别提到交互服务和云平台服务门户在 SaaS 模式下将存在连接这意味着如果你的集团有 SaaS 层应用服务门户需要预留对接能力。我一般会在方案里画一张决策树系统是否新建、是否标准化、是否有特殊硬件依赖三个问题定交付模式。3.3 计算与存储主机、存储、备份的组件能力与规划原则计算与存储部分方案拆成主机、存储、备份三个组件。主机分开放架构主机和主机架构开放架构设备以 PC Server 为主小型机设备一般不选择开放架构对开放架构的 PC Server 平台应明确虚拟化技术方向实现资源平台化并为行业私有云建设准备条件主机架构用于对高可靠性、高计算能力需求的核心业务系统提供计算服务主机架构应尽量统一保证兼容性。存储部分行业核心存储网络以 SAN 为主要技术方案新建计算中心可考虑 IP 网络和存储网络的融合解决方案集团总部计算中心应建立存储分级机制实现存储资源高效利用。备份部分行业各级本地备份由各级单位自行建设各下属子公司的异地备份应通过集团总部上海容灾中心进行建立针对数据分类的备份介质的离场管理和归档管理机制。这里有几个参数值得注意SAN 是核心存储网络的主要技术方案不是唯一方案存储分级机制是集团总部的强制要求异地备份的归口是上海容灾中心。你在写自己的存储方案时可以把这三条直接作为评审要点。4. 云服务架构与网络虚拟化、资源总线、服务门户怎么配4.1 虚拟化技术组件虚拟主机、虚拟网络、虚拟存储、资源管理云服务架构的虚拟化部分拆成四个组件虚拟主机、虚拟网络、虚拟存储、资源管理。虚拟主机的规划原则是集团主机虚拟化平台应以开放架构虚拟化主机为基本路线主机架构虚拟化以单机虚拟化应用为主开放平台架构虚拟化以高端 PC Server 为核心硬件平台。虚拟网络的规划原则是集中式计算中心虚拟平台虚拟网络应以集中虚拟交换机为主前置环境等分散计算环境应以分散式虚拟交换机为主虚拟网络分区应首先保证安全分区隔离的需求。虚拟存储的规划原则是行业应用目前仍以集中式关系型数据库为主以事务交易为主应为虚拟平台配置集中式存储由于数据基本按属地存储暂不考虑存储的异地迁移。资源管理的规划原则是每个虚拟环境部署独立的虚拟资源管理平台集团总部通过联邦机制对分散的虚拟资源管理平台进行集中管理。这四个组件的配置逻辑是虚拟主机定硬件路线虚拟网络定隔离方式虚拟存储定数据存放策略资源管理定管控粒度。常见坑是虚拟网络分区没做好安全隔离导致不同安全域的业务跑在同一虚拟交换机上。我一般会在方案里强制要求虚拟网络分区必须与安全分区一一对应集中环境用集中虚拟交换机分散环境用分散式虚拟交换机。4.2 资源总线资源定义、计量、编排、可靠性的配置顺序资源总线实现云资源的分配、回收、变更过程的自动化负责管理资源的工作负载将服务请求转化为资源请求并调度资源。方案给了四个组件资源定义、资源计量、资源编排、资源可靠性。资源定义的规划原则是与资源编排组件、资源监控和容量管理等组件共同完成资源模块化的交付资源定义和模型化是实现资源服务化管理的基础在云服务建设初期应进行规划部署。资源计量的规划原则是资源计量组件为云服务服务总线提供资源使用情况信息是基础性的云服务技术组件集团总部云服务建设初期应规划部署技术实现应与 ITSM 系统相关组件集成实现信息交换。资源编排的规划原则是云服务应实现按照负载均衡原则对资源池组件的编排管理应实现根据预定义工作流系统自动对 IaaS 资源进行编排应支持人工资源编排PaaS 资源可仅通过人工进行资源编排。资源可靠性的规划原则是云服务服务初期规划部署非核心应用暂缓部署资源高可靠性相关技术组件。配置顺序很关键先做资源定义和资源计量再做资源编排最后考虑资源可靠性。方案里明确说资源可靠性初期暂缓这意味着不要一上来就追求高可用先把资源定义和计量跑通。你在实操时可以按“定义→计量→编排→可靠性”的顺序分阶段上线。4.3 服务门户服务目录、订单管理、使用报告、计费管理的上线节奏服务门户为用户提供服务查询、订单管理等功能实现自助化并提供服务推广等功能云服务门户应与 ITSM 服务门户集成建设。方案给了四个组件服务目录、订单管理、使用报告、计费管理。服务目录的规划原则是云服务优先考虑 PaaS 类服务的服务目录展示IaaS 主要针对集团总部内部用户的阶段可暂不纳入门户中展示服务目录管理与 ITSM 服务管理整合。订单管理的规划原则是订单管理是实现用户自助服务的前提在提供用户自助服务前可不部署此类组件订单管理的关键点在于订单向服务的转换特别是主计算中心和上海容灾中心间的多点转换问题。使用报告的规划原则是使用报告技术能力应实现对各类用户实际对云服务平台上服务使用情况的统计和报表化展现包括服务质量、服务成本等多样化的统计分析使用报告相应管理流程应与 ITSM 平台整合。计费管理的规划原则是云服务主要针对行业内部客户使用初期可不部署计费管理模块但应设计相应接口可实现模拟的服务计量作为云服务平台收益的评估参考重点在于计费模块应支持多种方式的计费管理和定价模型应与 ITSM 服务成本管理集成整合。上线节奏建议先上服务目录和使用报告再上订单管理最后上计费管理。方案里明确说计费管理初期可不部署但接口要预留这是典型的“先通后优”思路。4.4 网络节点、连接、远程访问的规划原则网络部分拆成三个组件网络节点、网络连接、远程访问。网络节点的规划原则是行业各级单位分别负责各自网络节点建设行业核心网络节点应具备充分的交换能力各级网络节点应依据应用系统安全分类进行可靠的安全隔离同一安全区域内不同架构层级设备宜通过虚拟网络进行隔离集团总部对行业提供服务的区域应单独部署网络。网络连接的规划原则是行业网络连接采用北京、上海双中心的结构符合行业需求对通过上海容灾中心进行异地数据备份的单位连接带宽应评估优化北京和上海间的连接带宽为满足数据中心数据复制的需求建议评估优化。远程访问的规划原则是各网络节点可分别建立远程访问技术组件集团总部对行业性用户提供统一接入服务。这里的关键参数是北京、上海双中心结构以及北京和上海间的连接带宽需要评估优化。常见坑是异地数据备份的带宽没算够导致备份窗口超时。我一般会在方案里要求北京和上海间的连接带宽按数据复制峰值流量的 1.5 倍配置并预留扩容能力。5. 避坑与排查基础设施架构规划里最容易翻车的五件事5.1 现象虚拟化平台选型时开放架构和主机架构混用导致兼容性问题频发原因方案里明确说开放架构设备以 PC Server 为主主机架构用于高可靠性、高计算能力需求的核心业务系统但实操中经常有人把两种架构混在一个虚拟化平台里以为虚拟化层能屏蔽差异。实际上主机架构虚拟化以单机虚拟化应用为主开放平台架构虚拟化以高端 PC Server 为核心硬件平台两者的虚拟化技术路线不同混用会导致资源池无法统一调度。解决按业务系统分级核心业务系统用主机架构非核心业务系统用开放架构两套虚拟化平台分开建设通过资源管理平台的联邦机制做集中管理不要强行合并资源池。5.2 现象资源总线先上了资源可靠性组件结果资源定义和计量还没跑通整个云服务交付卡住原因方案里明确说资源可靠性初期暂缓部署资源定义和资源计量是基础性组件应在云服务建设初期规划部署。但实操中经常有人觉得高可用重要先把可靠性组件上了结果资源定义没做完资源编排没有模板可用资源计量没做完服务总线拿不到使用数据整个交付链路断掉。解决严格按“资源定义→资源计量→资源编排→资源可靠性”的顺序推进初期只部署资源定义和资源计量资源编排先支持人工编排资源可靠性等非核心应用跑通后再考虑。5.3 现象服务门户先上了计费管理结果服务目录和订单管理还没建好用户根本用不起来原因方案里明确说计费管理初期可不部署但应设计相应接口服务目录优先考虑 PaaS 类服务展示订单管理在提供用户自助服务前可不部署。但实操中经常有人觉得计费是云服务成熟的标志先把计费上了结果服务目录没建好用户不知道有什么服务可买订单管理没建好用户买了服务没人处理。解决先上服务目录和使用报告让用户看到有什么服务、用了多少再上订单管理让用户能自助下单最后上计费管理初期只做模拟计量接口预留等 ITSM 服务成本管理成熟后再对接。5.4 现象异地备份带宽没算够备份窗口超时容灾演练失败原因方案里明确说对通过上海容灾中心进行异地数据备份的单位连接带宽应评估优化北京和上海间的连接带宽为满足数据中心数据复制的需求建议评估优化。但实操中经常有人按日常流量估算带宽没算备份峰值流量导致备份窗口内传不完容灾演练时数据不一致。解决按数据复制峰值流量的 1.5 倍配置北京和上海间的连接带宽并预留扩容能力备份策略按数据分类分级核心数据优先备份非核心数据错峰备份容灾演练前先做带宽压力测试。5.5 现象虚拟网络分区没做安全隔离不同安全域的业务跑在同一虚拟交换机上原因方案里明确说虚拟网络分区应首先保证安全分区隔离的需求同一安全区域内不同架构层级设备宜通过虚拟网络进行隔离。但实操中经常有人图省事把所有虚拟主机挂在同一个虚拟交换机上靠防火墙做隔离结果虚拟交换机层面的广播风暴和安全漏洞无法隔离。解决虚拟网络分区与安全分区一一对应集中环境用集中虚拟交换机分散环境用分散式虚拟交换机同一安全区域内不同架构层级设备通过虚拟网络隔离跨安全区域流量必须经过防火墙。6. 从蓝图到落地用“组件能力规划原则”做架构评审的实操技巧这份 PPT 最值钱的地方不是架构图而是每个技术组件都配了“组件能力”和“规划原则”两段话。组件能力告诉你这个组件能干什么规划原则告诉你这个组件应该怎么配。我一般会把这两段话直接改写成架构评审的检查项。比如虚拟化技术组件组件能力是开放架构资源虚拟化技术组件和主机架构资源虚拟化技术组件规划原则是开放架构虚拟化主机为基本路线、主机架构虚拟化以单机虚拟化应用为主、开放平台架构虚拟化以高端 PC Server 为核心硬件平台。评审时直接问你的虚拟化平台是开放架构还是主机架构开放架构是不是以 PC Server 为主主机架构是不是单机虚拟化三个问题就能判断方案是否合规。再比如资源总线组件能力是资源模板设计和资源模板应用管理规划原则是与资源编排组件、资源监控和容量管理等组件共同完成资源模块化的交付资源定义和模型化是实现资源服务化管理的基础在云服务建设初期应进行规划部署。评审时直接问资源定义和模型化做了没有资源模板设计有没有资源编排组件、资源监控和容量管理组件是否协同三个问题就能判断资源总线是否具备上线条件。我习惯把这份 PPT 的每个技术组件做成一张检查表左边是组件能力右边是规划原则中间是评审问题。比如服务门户的检查表服务目录的组件能力是服务目录展示、服务目录同步规划原则是优先考虑 PaaS 类服务展示、IaaS 暂不纳入门户、与 ITSM 服务管理整合评审问题是服务目录是否优先展示 PaaS 服务、IaaS 是否暂不纳入、是否与 ITSM 整合。订单管理的组件能力是订单接收、订单分解、订单请求分发规划原则是提供用户自助服务前可不部署、关键点是订单向服务的转换、特别是主计算中心和上海容灾中心间的多点转换评审问题是自助服务是否已提供、订单向服务转换是否跑通、多点转换是否处理。使用报告的组件能力是服务使用统计和使用报告展现规划原则是统计服务质量和服务成本、与 ITSM 平台整合评审问题是统计维度是否包含服务质量和服务成本、是否与 ITSM 整合。计费管理的组件能力是服务计费、服务定价规划原则是初期可不部署、设计接口、支持多种计费管理和定价模型、与 ITSM 服务成本管理集成评审问题是初期是否暂不部署、接口是否预留、计费模型是否支持多种方式、是否与 ITSM 集成。这套检查表的好处是评审时不用争论“要不要做”直接对照组件能力和规划原则缺什么补什么。我一般会在项目启动会上就把检查表发给各模块负责人让他们自己先对照一遍评审时只讨论有争议的条目。从那以后我每次做基础设施架构评审都强制走一遍“组件能力→规划原则→评审问题”的检查表再也没出现过方案写完才发现漏了关键组件的情况。希望帮到你。本文还有配套的精品资源点击获取