简介这份PPT是埃森哲大型集团管控信息化战略规划项目系列中的蓝图设计方案聚焦基础设施架构与BPIT运营模式面向企业信息化规划人员、架构师及集团IT管理者帮助解决多系统难集成、难共享、重复建设等长期痛点。资源包共1个pptx文件约4.58MB内容以图文架构蓝图与规划框架为主便于直接用于方案汇报与内部培训。目前已有398人学习下载。资料系统梳理了基础设施架构目标与架构原则涵盖物理集中、逻辑集中、服务平台化、集成平台、云资源管理与云服务交付等核心原则并展开总体基础设施架构蓝图包括新一代智能混合云、企业级流程规范与标准化管理、统一平台、资源集中与平台化应用同时给出解决方案核心要素涉及统一平台集成、业务应用集成与集中、运行平台需求、数据架构需求及集中化、平台化、云服务三大规划原则可帮助读者快速理解集团级基础设施架构的顶层设计思路与落地路径。1. 大型集团管控信息化蓝图里基础设施架构到底在解决什么问题如果你在大型集团的信息化部门待过大概率遇到过这种场面集团总部要上一套管控平台下面十几家子公司各有各的系统、各有各的机房、各有各的云账号数据口径对不上权限理不清预算花了不少但没人说得清基础设施到底该怎么摆。这时候一份「蓝图设计方案」里的基础设施架构章节就是要把这团乱麻理成一张能落地的图。BPIT 运营模式是这套蓝图里的关键抓手——它把业务Business、平台Platform、信息Information、技术Technology四条线拉到一张运营表上让基础设施不再是「买服务器」这么简单的事而是承接集团管控需求的底座。混合云在这里几乎是绕不开的选项核心管控数据放私有环境保安全合规弹性计算和数据分析放公有云控成本。这篇笔记拆的是这类蓝图方案里基础设施架构部分怎么做、参数怎么定、哪些坑最容易翻车适合正在牵头或参与集团级信息化规划的人对照着走一遍。2. 先想清楚 BPIT 运营模式怎么落到基础设施层2.1 BPIT 四条线各自对基础设施提了什么要求BPIT 不是四个字母随便拼的。业务线决定哪些系统必须 7×24 不能断平台线决定中间件和数据库的部署形态信息线决定数据在哪里存、怎么流转、谁能看技术线决定用什么样的计算、存储、网络资源去承载前三者。很多蓝图方案翻车就是因为只画了技术线的架构图没回答业务线「双十一当天扩容谁批」这种问题。落到基础设施上四条线的诉求会打架。业务线要弹性信息线要隔离技术线要统一纳管平台线要低延迟。我的做法是先做一张诉求映射表把每条线的硬约束标出来再去找满足所有硬约束的最小架构集合。比如集团财务管控系统信息线要求数据不出境、不出私有环境那它的数据库和存储就必须落在私有云侧公有云只承接报表展现和移动端接入这类不碰核心数据的负载。这张表不用很复杂三列就够业务域、硬约束、可妥协项。硬约束是红线可妥协项是后面做混合云调度时的弹性空间。把这张表做出来后面选型和参数配置才有依据不然就是拍脑袋。2.2 从管控需求推导基础设施分层集团管控信息化的基础设施我一般按四层来切接入层、应用承载层、数据层、基础资源层。接入层管的是集团总部和子公司的网络互通、身份认证、终端准入应用承载层管的是管控应用的部署单元、容器编排、服务发现数据层管主数据、交易数据、分析数据的存储和同步基础资源层就是计算、存储、网络、安全这些底层资源池。分层的好处是每一层可以独立演进。子公司网络改造不影响应用部署方式数据层换存储引擎不影响上层应用。蓝图方案里如果把这四层混在一起画评审的时候一定被问懵。常见做法是在蓝图里给每层定义清楚「谁负责、交付什么、验收标准是什么」这样后面做实施计划时能直接拆成工作包。混合云的引入点通常在基础资源层和应用承载层之间。私有云池承载稳态业务公有云池承载突发和弹性业务中间用统一的资源调度和镜像管理打通。这里的关键不是技术能不能通而是运营模式上谁有权在公有云上开资源、开多少、怎么回收。BPIT 运营模式里的「运营」两个字落点就在这。2.3 一张可评审的基础设施架构图该包含哪些元素蓝图方案里的架构图不是画给领导看的是画给后面做实施的人看的。我评审过不少方案能落地的图一般包含这些元素资源池划分私有云几个可用区、公有云用哪些地域、网络拓扑专线还是互联网、带宽多少、有没有冗余、安全域划分哪些区域之间必须过防火墙、策略谁管、数据流向核心数据从哪到哪、同步还是异步、运维边界监控覆盖到哪一层、告警谁接。图上的每个元素都要能对应到一个配置项或一个管理流程。比如画了一条专线就要写清楚带宽、冗余方式、故障切换时间画了一个安全域就要写清楚域间策略的审批流程。没有这些图就是装饰。提示架构图评审时最容易被挑战的不是技术选型而是「这个资源谁批、故障谁扛、成本谁出」。提前把这三件事写进图注里能省掉后面很多扯皮。3. 混合云资源池怎么划分和配置3.1 私有云池的可用区与资源规格设计私有云池是集团管控的稳态底座划分可用区时我一般按「业务域 安全等级」两个维度来切。比如财务管控一个可用区、人力管控一个可用区、共享服务一个可用区每个可用区内再按安全等级分生产、测试、灾备三个资源组。可用区之间用高速内网互联延迟控制在 1ms 以内这样跨域调用不会成为瓶颈。资源规格上管控类应用通常是 CPU 密集和内存密集混合型。我的经验值是应用服务器按 8C16G 起步数据库服务器按 16C64G 起步缓存节点按 8C32G 起步。这个规格不是拍脑袋是按集团总部加子公司并发用户数、单次请求资源消耗、峰值系数三个参数算出来的。峰值系数一般取 3 到 5看业务波动性。存储方面私有云池至少要有三档高性能 SSD 给数据库和缓存容量型 SSD 给应用日志和中间件大容量 HDD 给备份和归档。三档存储的配比大概是 2:5:3具体看数据增长预测。网络方面管理网、业务网、存储网三网分离是底线别为了省交换机把三网混在一起后面出问题排查起来就是黑匣子。3.2 公有云侧承接哪些负载、怎么控成本公有云在集团管控场景里不是主力是补充。我一般把这几类负载放公有云面向外部用户的门户和移动端接入、数据分析和报表展现、开发和测试环境、灾备接管环境。核心交易和核心数据不放公有云这是红线。控成本的关键是标签体系和预算告警。每个公有云资源必须打三个标签业务域、环境、负责人。没有标签的资源不允许创建。预算告警按业务域设置月度阈值超过 80% 发提醒超过 100% 自动限制新资源创建。这套机制不复杂但能挡住大部分意外账单。# 公有云资源标签规范示例以命令行方式描述具体命令按所用云平台调整 # 创建资源时必须携带以下标签 # business_domain: finance | hr | shared | ... # environment: prod | test | dev | dr # owner: 工号或邮箱前缀 # cost_center: 成本中心编码 # 预算告警配置逻辑 # 1. 按 cost_center 聚合月度消费 # 2. 阈值 80% 触发通知100% 触发限制策略 # 3. 限制策略禁止创建新的计算和存储资源已有资源不受影响上面这段是标签和预算告警的配置逻辑说明。标签是成本归属的基础没有标签的成本数据在集团层面没法分摊到各业务域财务那边对不上账。预算告警的阈值和动作要提前和财务、各业务域负责人对齐不然限制策略一触发业务那边会直接找上门。3.3 跨云网络打通与数据同步的关键参数跨云网络打通一般走专线带宽按峰值数据同步量加 30% 余量来定。比如每天需要同步 500GB 数据同步窗口 4 小时那带宽至少要 500GB×8/4h/3600s≈285Mbps加余量取 400Mbps。专线要双线冗余主备切换时间控制在 60 秒以内。数据同步分两种结构化数据用数据库复制或 CDC 工具非结构化数据用对象存储同步。结构化数据同步要关注延迟和一致性核心管控数据一般要求秒级延迟、最终一致非结构化数据同步可以放宽到分钟级。同步任务要有监控和重试机制失败超过三次告警到运维值班。# 数据同步任务的关键参数配置示例 sync_config { source: private_cloud_db, # 源端私有云数据库 target: public_cloud_dw, # 目标端公有云数据仓库 sync_mode: cdc, # 同步模式cdc 增量 / full 全量 batch_size: 5000, # 每批同步行数按网络延迟调整 max_retry: 3, # 最大重试次数 retry_interval_sec: 30, # 重试间隔 alert_threshold: 3, # 连续失败几次告警 latency_sla_sec: 60, # 延迟 SLA超过则告警 } # batch_size 太大会导致单批超时太小会增加同步延迟 # 一般从 5000 起步根据实际网络和数据库负载调整这段配置里 batch_size 和 latency_sla_sec 是最需要根据实际情况调的。batch_size 太大单批同步容易超时失败太小同步延迟上不去。我的做法是先按 5000 跑一周看同步日志里的平均批次耗时和失败率再决定调大还是调小。latency_sla_sec 是告警阈值不是硬性限制设得太紧会天天告警设得太松出了问题发现不了。4. 基础设施架构落地时的避坑与排查4.1 可用区划分太细导致跨区调用延迟飙升现象应用部署时按业务域分了六个可用区上线后发现跨区调用平均延迟从 1ms 涨到 8ms部分接口超时。原因可用区划分维度太多每个可用区资源池小应用之间跨区调用频繁网络跳数增加。可用区不是越多越好每个可用区要有足够规模才能摊薄网络开销。解决合并可用区按「安全等级 大业务域」两个维度切控制在三到四个可用区。跨区调用走内部高速通道关键接口做本地缓存减少跨区请求。4.2 公有云标签缺失导致成本无法分摊现象季度成本复盘时公有云账单里 40% 的资源没有标签财务要求各业务域认领没人认。原因资源创建时没有强制标签策略开发测试人员随手开资源用完不删也不打标签。解决在资源创建入口做强制校验没有标签不允许创建。存量无标签资源做一次集中清理能打标签的打上打不上的走审批流程特批。预算告警按成本中心聚合倒逼各业务域管好自己的资源。4.3 专线带宽按平均流量估算峰值时同步中断现象数据同步任务在业务高峰期频繁中断排查发现专线带宽被打满。原因带宽按日均流量估算没考虑峰值。集团管控场景的峰值系数一般在 3 到 5 之间按平均值算肯定不够。解决带宽按峰值流量加 30% 余量重新核算。同步任务做限流和错峰调度非实时同步任务放到业务低峰期执行。专线做双线冗余主备切换时间纳入监控。4.4 安全域策略审批流程太长业务上线被卡现象应用上线前需要开通跨安全域策略审批走了两周还没下来业务方投诉。原因安全域策略审批没有分级所有策略都走同一个流程小额低风险策略也被卡。解决策略按风险分级低风险策略走快速通道一个工作日内完成高风险策略走完整审批。常用策略做成模板减少重复审批。审批流程和工单系统打通进度可查。4.5 监控覆盖不到存储和网络层故障定位靠猜现象应用响应变慢排查了半天发现是存储 IO 瓶颈但监控只覆盖到应用层。原因监控建设时只关注了应用和主机存储和网络层的指标没接进来。解决监控覆盖扩展到存储 IOPS、延迟、网络丢包率、专线利用率这些底层指标。告警规则按层设置底层指标异常时能快速定位。监控数据保留至少 90 天方便事后复盘。5. 用容量模型验证基础设施架构是否撑得住5.1 容量模型的三个输入和两个输出容量模型不复杂三个输入用户规模、单次请求资源消耗、峰值系数。两个输出计算资源需求、存储资源需求。用户规模按集团总部加子公司活跃用户数算单次请求资源消耗按应用类型取经验值峰值系数按业务波动性取 3 到 5。我一般会做一个简单的表格来推演把不同业务域的输入参数列出来算出各自的资源需求再加总看整体资源池够不够。这个表在蓝图评审时特别有用领导问「这套架构能撑多少人」的时候直接翻到这一页。业务域活跃用户数单次请求 CPU(ms)单次请求内存(MB)峰值系数计算需求(vCPU)存储需求(TB)财务管控30005020424012人力管控5000301531808共享服务80002010532020数据分析50020010028050这张表里的数字是示例实际项目要按真实调研数据填。计算需求按「活跃用户数 × 单次请求资源 × 峰值系数 / 单核处理能力」估算存储需求按「用户数 × 人均数据量 × 增长系数」估算。算出来的结果加 30% 余量就是资源池的最小规模。5.2 压测验证从单接口到全链路容量模型算出来的是理论值能不能撑住要压测验证。压测分三步单接口压测、单应用压测、全链路压测。单接口压测验证单个服务的处理能力单应用压测验证应用整体的并发能力全链路压测验证跨系统调用的稳定性。压测工具用常见的开源方案就行关键是压测场景要贴近真实业务。我一般会从生产环境摘取一段真实请求日志回放到压测环境这样比人工构造请求准确得多。压测时重点看三个指标TPS、响应时间 P99、错误率。TPS 要达到容量模型预测值的 1.2 倍P99 响应时间要在 SLA 以内错误率要低于 0.1%。压测发现瓶颈后先定位是应用层还是基础设施层。应用层瓶颈调代码和配置基础设施层瓶颈加资源或调架构。每次调整后重新压测直到达标。5.3 把验证结果回写到蓝图方案里压测和容量验证的结果要回写到蓝图方案里作为架构选型的依据。回写的内容包括实测 TPS 和响应时间、瓶颈点和优化措施、资源池最终规格建议、扩容触发条件。这些内容写进方案后后面做实施和运维的人就有据可依。扩容触发条件特别重要。我一般设三个阈值CPU 利用率持续 15 分钟超过 70%、内存利用率持续 15 分钟超过 80%、存储利用率超过 75%。触发任一阈值就启动扩容评估评估周期不超过三个工作日。这套机制写进方案里运维团队后面照着执行就行。注意容量模型和压测结果都是基于当前业务预测的业务变化快的话每半年要重新跑一次。别把一次验证结果当成永久结论。我自己的习惯是每做完一个集团级的基础设施蓝图都会把容量模型、压测报告、避坑记录三份材料单独归档。后面再做类似项目时这三份材料就是最快的参考。基础设施架构这件事技术选型只是一半另一半是运营模式和管理流程能不能跟上。BPIT 运营模式的价值就在于把这两半绑在一起让蓝图不只是图而是能落地的方案。希望帮到你。本文还有配套的精品资源点击获取