ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

思杰XenApp金融行业案例详解:应用集中化破解六大IT难题

思杰XenApp金融行业案例详解:应用集中化破解六大IT难题 简介金融IT负责人在应对并购整合、安全接入、合规遵从、移动办公、分支机构转型与业务连续性等挑战时需要兼顾效率与合规并寻求可落地的技术参考。思杰金融行业解决方案及案例汇编正是面向金融机构IT决策者、架构师及运维人员的完整PDF文档共1个文件压缩包仅767KB便于离线阅读。文档以金融行业IT挑战为主线介绍按需应用交付架构软件模型阐释集中化与虚拟化技术如何降低运营成本并保障应用性能同时收录中国建设银行、河北中行、中信实业银行东莞分行、大华银行马来西亚、雷曼兄弟及Tryg-Baltica保险公司的实践案例从真实部署中展示思杰方案在提升安全性、业务连续性、响应速度与成本控制方面的具体成效帮助读者快速验证方案落地思路。目前已有437人学习该资源。1. 思杰金融行业解决方案及案例.PDF一份 2008 年的方案汇编为什么现在还能拆思杰金融行业解决方案及案例这份 PDF 是思杰系统有限公司在 2008 年 3 月发布的行业方案汇编它不堆产品参数而是先把金融行业的 IT 挑战拆成六条主线——兼并与收购、安全接入、合规性、移动办公、分支机构转型、业务持续性——再用 Citrix XenApp 的应用交付架构逐一回答。文档里含金量最高的是五个真实客户案例中国建设银行、河北中行、中信实业银行东莞分行、大华银行马来西亚、雷曼兄弟每个都带部署方式和收益数字。对于正在评估桌面虚拟化、应用虚拟化选型的金融行业 IT 人员这份 PDF 可以直接当需求清单用它展示了银行当年怎么把 OA、国际结算、贷款管理这些核心应用集中到数据中心再通过 ICA 协议发布给分支机构。今天换个产品名底层逻辑依旧是同一套。2. 按需应用交付模型用集中化破解并购、合规与安全三道题文档的核心论点一句话就能讲完金融行业的大部分商业挑战答案在 IT 部署方式上而当时主流的分布式计算环境本身就是障碍。思杰给的解法叫“按需应用交付架构”说直白点就是应用在数据中心集中运行用户端只做显示和输入网络上传的只是键盘、鼠标和屏幕刷新数据。这个模型放在今天就是 SBCServer-Based Computing或 VDI 的早期形态但 2008 年这份 PDF 已经把模型和金融行业的六大具体挑战绑定在了一起。理解这个框架是后面拆案例的前提。2.1 六大挑战拆解并购、安全接入、合规、移动办公、整合、业务持续性文档开篇列举的六个挑战我按它的逻辑整理成下面这张对应表挑战商业痛点思杰方案对应点兼并与收购多套网络/系统/应用要快速融合时间紧、资源少应用集中发布客户端无需安装软件异构平台统一接入安全接入企业资源客户资料与金融数据高敏感未授权接入风险大以安全为出发点设计基于策略控制接入与传输加密合规性GLBA、HIPAA、SEC、FTC、NASD 等法规持续加压集中化环境便于审计用户接入行为可追溯移动办公销售、交易员、现场外勤需要随时随地接入应用ICA 低带宽占用支持有线和无线切换分支机构转型/服务器整合80% IT 预算用于维护仅 20% 用于转型服务器集中化、应用统一部署、瘦终端替换 PC业务持续性计划内/外中断时关键应用必须保持可用应用与数据集中存放支持快速恢复和异地点接入单看并购这一项就能体会集中化的价值。两家银行合并网络架构、系统架构、业务应用、邮件系统完全不同按传统方式逐台 PC 装客户端兼容性测试就能拖几个月。把应用装到数据中心服务器上分支机构通过 ICA 协议访问客户端操作系统和硬件差异被屏蔽整合复杂度从“端到端融合”降级成“数据中心内部整合”这是质的改变。合规性同理。金融机构面对 GLBA、HIPAA、SEC、FTC、NASD 等一堆监管核心诉求是数据安全和隐私保护。分布式环境下用户数据散落在 PC 硬盘里IT 部门管不住应用集中化之后数据不落地管理员可以精确到“什么人在什么时间用什么设备访问了什么应用”审计时拿得出完整记录。这一点在金融行业选型里往往是第一优先级比省成本更重要。2.2 集中化和虚拟化为什么应用执行要回到数据中心这里有两个层次要分开。应用集中化是应用软件装在数据中心服务器上用户远程操作虚拟化则是把应用和操作系统解耦让一台服务器同时承载多个隔离的用户会话。文档里的 Citrix XenApp 走的正是这条路线所有应用执行都发生在数据中心本地接入设备只作为显示和输入平台。这个模型带来的直接好处是端点安全。客户端没有安装包、没有数据落地病毒和恶意软件的切入面被大幅压缩。河北中行案例特意提到这一点客户端基本都是瘦终端应用数据被感染病毒的可能性大降系统管理员不必再为病毒问题反复处理。反过来看如果应用装在本地 PC 上2000 台设备就有 2000 个安全弱点合规审计时每一项都是风险。第二个好处是升级维护的杠杆效应。传统模式下2000 台 PC 装一个新应用要逐台安装、逐台测试集中化之后应用在服务器上装一次所有用户下次登录就是新版本。大华银行马来西亚案例写得很清楚2000 多台桌面电脑分散在 36 个分支机构安装新应用“已经成为一项非常耗时的操作”。部署思杰方案后这个耗时项从客户端转移到了服务器端而且不受地理距离限制。还有一点容易忽略兼容历史系统。银行里大量遗留应用是 C/S 架构有的只能跑在旧版 Windows 甚至 UNIX 上。文档反复强调“无需重写应用程序”这正是思杰方案的卖点——改变的是应用分发方式不是应用本身。对银行这种核心系统不能随意动的行业这个条件是选型时的硬门槛。2.3 经济意义人员成本高于硬件采购成本文档引用了 IDC 的总体拥有成本TCO研究结论非常反直觉硬件和软件不是最主要的成本管理、操作、开发、支持、软件安装升级和培训这些人员成本远远超出硬件和软件的购置总成本。这意味着做预算时只算服务器和软件授权费用是远远不够的维护人员的工时才是大头。文档给了一组很扎眼的数据80% 或更多的银行 IT 资源和预算用于维护现有业务只有 20% 用于业务增长或转型。应用交付架构把维护动作集中到数据中心人为错误和重复劳动减少那 80% 的维护预算就有机会挤出一部分投向转型。IDC 还统计了北美金融服务公司在系统和网络管理软件上的支出2002 年是 25 亿美元2007 年预计涨到 35 亿美元复合年增长率 6.9%。管理复杂度逐年增加集中化是有效的对冲手段。我在实际项目里一般会请客户把三个隐性成本单列出来每台 PC 每年的维护工时、每次密码重置的人工成本、应用升级时全网点逐个安装的时间。这三个数字在大华银行案例里全部兑现了后面避坑章我会单独展开。算完这三个数字大多数甲方会重新掂量分布式部署的代价。提示TCO 测算不要只看硬件采购把维护工时和 Help Desk 呼叫量折算成金额结论往往完全不同。3. 六个客户案例拆解从建行到雷曼兄弟的落地细节3.1 建设银行总行OA 发布与“非典”期间的远程办公2002 年 8 月建设银行总行率先在办公自动化系统上部署 Citrix XenApp。首批用户包括总行行长、信息技术管理部、北京开发中心和上海信用卡中心业务人员。方案的核心价值是远程办公能力员工出差在外通过多种网络方式连回总行服务器远程运行 OA 处理公文、督办查办紧急事项。文档引用了项目经理刘磊的原话特别提到“非典”肆虐京城期间员工在家办公依然能通过远程接入及时处理重要工作保证了连续性和高效性。这个案例里真正值得注意的不是“远程办公”这个结果而是部署的起点——OA 这种内部系统按当时的条件完全可以在局域网里跑为什么要引入 Citrix答案是应用部署和升级的半径问题。总行、信用卡中心、异地开发中心分布在多个城市OA 客户端版本管理极其麻烦。用 Citrix 发布以后客户端只需要 ICA 客户端或浏览器就能接入版本差异问题被天然屏蔽。建行深圳分行随后复制了同一套方案把国际结算系统发布到 XenApp 上覆盖深圳 100 多个营业网点。国际结算系统实现了汇划、清算、对账、查询、监控一体化网点职员通过标准 PC 浏览器用 Web 方式访问。思杰方案极大简化了部署过程后续的升级维护也轻松很多。这个案例说明一条规律先在一个内部系统上验证架构再横向复制到核心业务系统是金融行业常见的推进路径。3.2 河北中行瘦客户端与加密专线的集中管理组合河北中行案例最完整的部分是“CitrixWYSE加密专线”三件套。背景是河北中行有邮件、OA、日常业务等 C/S 结构应用总部与分公司之间需要保持实时数据传送和远程维护同时希望降低软硬件采购和人员维护成本。方案用 Citrix 集中发布 OA、Office、IE用 WYSE 瘦客户端替换 PC用加密隧道构建总部与分公司之间的专用网络通道保证数据传输入口的安全性。河北中行选型理由里有几条值得细看。第一是瘦客户机的故障率不到 PC 的七分之一这对分支机构多的银行很重要——网点没有专职 IT 人员设备故障就意味着业务停摆。第二是客户端没有软驱、硬盘等存储设备有效防止数据非法外泄和不良数据侵入系统。这是金融行业“数据不落地”原则的早期实践。第三是服务器端采用 NTFS 文件系统严格控制文件权限配合磁盘配额管理防止用户过多占用磁盘空间。这套方案还强调了一个决策点思杰平台无需二次开发直接发布现有业务应用给各地授权人员使用。对银行来说“不改代码”是最大的定心丸。文档里提到“结合思杰自身提供安全功能河北中行的网络非常安全”实际上加密协议RDP、ICA都自带完善的加密算法客户端通过加密隧道访问数据安全性由两层叠加保障。3.3 中信实业银行东莞分行CitrixWBT 的技术细节最密集中信东莞分行是文档里技术细节最丰富的一个案例。传统方案的痛点写得很真实每台计算机需要安装软件、部署时间长远程维护和技术支持困难广域网传输导致速度没保障提高带宽代价高昂软硬件频繁升级客户端设备容易被淘汰。思杰方案是在信息中心部署 XenApp 服务器组把 Lotus Notes 客户端和 Office 集中安装客户端采用固化 ICA 协议的 Windows 终端。这个案例给出了明确的带宽参数ICA 连接通常只需要 20K-30K 带宽支持 128 位数据加密客户端与服务器之间传输的只有键盘、鼠标和屏幕刷新数据。这组参数是后续所有带宽规划的基础参照。XenApp 高级版还提供了几项被反复验证的功能Seamless Windows 把本地和远端应用无缝集成在同一个桌面用户感知不到程序在哪运行Business Recovery Client 支持客户端自动安装、自动升级、自动恢复负载均衡能自动把用户请求路由到负载最轻的服务器。打印机集中管理也是这个案例里的重点。在思杰服务器之间复制打印机驱动程序指定所用打印机驱动限制打印数据流占用带宽简化整个服务器群内驱动管理。通用打印机驱动把不同打印机的驱动要求统一为一种既降低管理成本又减少了多个桌面打印机场景下的打印时间。这些细节在早期 Citrix 项目里经常被当成“非核心功能”忽略但实际运维时会发现它们决定了用户体验好坏。3.4 大华银行马来西亚量化到每年的 TCO 账本大华银行马来西亚是文档里数据最完整的案例。背景36 家分支机构、2000 多台桌面电脑分布从马来西亚东部到西部。三个核心问题一是分布式 IT 环境让应用发布和升级极其耗时二是异构环境里旧配置 PC 跑不了新应用三是分支机构之间带宽只有 128Kb 到 348Kb打开一个 650Kb 的邮件附件要等 70 多秒员工效率和客户响应都受影响。解决方案是 20 台 Windows Server 2003 上部署 Citrix XenApp 和 Citrix Password Manager首批面向 500 并发用户主要覆盖销售部门和后勤支持部门计划到 2006 年中期扩展到 2000 多用户。发布的应用包括 Microsoft Office 2000、Exchange 2000、银行资金业务、信用评估、人力资源系统和贷款管理系统一共六种关键业务应用。文档给出的收益是每年节省 IT 费用 76.6 万美元主要来自 PC 升级费用和网络带宽费用。另外有个很容易被忽略的数据每月约 300 次密码重置占 IT Help Desk 呼叫总量的 35%。这两个数据放在一起看TCO 的构成就很清晰了——节省的不是服务器硬件采购而是终端升级、带宽扩容和一线支持人力。IBM 的文档中还有一句关键评价“在评估了多个替代方案之后最终选择思杰是因为以往记录、市场领先地位和产品性能。”选型阶段就引入厂商技术顾问参与试点也是大华银行这个项目能快速落地的原因之一。3.5 雷曼兄弟与 Tryg-Baltica业务连续性和无线接入的极端测试雷曼兄弟的案例篇幅很短但分量很重9·11 事件发生后雷曼兄弟在思杰软件的协助下实现了持续交易能力。当时基础设施受损交易员通过备用地点接入交易应用保持交易不断。这是业务持续性最极端的场景——灾难发生了关键应用必须保持可用。文档在业务连续性的论述中提到一个观点“采用最小化中断恢复业务比应用环境和数据的异地备份更有效。”这句话对金融行业尤其适用因为长时间停机会直接表现为收入损失和客户流失。Tryg-Baltica 保险公司则代表了另一种场景移动办公。现场人员通过无线设备接入理赔应用不需要回到办公室就能处理案件。文档里的对应功能是 Citrix SmoothRoaming跨越设备、位置和网络提供个人接入连续性用户只需一次登录就能接入所有应用。设想一个场景业务人员从办公室走到会议室设备可能从有线切换到无线SmoothRoaming 会自动重新连接所有打开的会话位置变了但工作状态不中断。3.6 案例共性为什么都在用 XenApp把这几个案例放在一起看案例用户规模网络条件核心驱动建行总行总行深圳100网点互联网/专线OA 与国际结算系统远程发布河北中行总部分公司加密专线集中管理、瘦终端替换中信东莞分行分行级20K-30K ICAOA 办公、TCO 压降大华银行马来西亚500→2000用户128K-348K 线路升级成本、带宽瓶颈、密码重置雷曼兄弟总部备用点灾备网络业务连续性Tryg-Baltica移动人员无线移动办公共性归纳起来就三条应用必须集中管理、客户端环境不可控、带宽不宽裕。这三条正好对应 XenApp 的核心能力——应用集中化、ICA 协议低带宽、客户端无关性。这也是为什么这份 PDF 过了十几年再翻选型逻辑依然没有过时。4. 金融行业 XenApp 部署三件事安全接入策略、带宽基线和集中管理案例讲完落到实际项目。如果今天你要在金融行业评估或实施 XenApp有三个决策点是绕不过去的安全接入策略怎么设计、带宽基线怎么定、集中管理组件怎么取舍。后面的避坑章会讲失败案例这一章先给判断框架。4.1 安全接入策略先回答“谁、哪台设备、在哪”再做权限文档里有个提法叫“以安全为出发点设计而非事后的弥补”。应用全部集中在思杰服务器上IT 员工完全掌握接入控制权。基于策略的控制让 IT 部门能轻松限制什么人能接入哪些信息、什么时候接入。这里的策略需要考虑三种接入因素谁正在接入应用他们用的是什么类型的客户端设备比如台式机、笔记本、PDA 还是自助查询终端他们所处的位置比如常规办公点、其他办公室、路途中。这意味着接入控制不是简单的“允许或拒绝”而是选择性信任。文档举了一个很典型的场景私营银行老板在办公室打开客户投资组合应用通过 SmoothRoaming 在不同设备和位置间漫游时可以无缝重连到所有打开的应用。但当他从办公室转移到柜员机工作台时SmartAccess 会根据公司策略禁止他打开客户投资组合应用——系统判断这个位置不允许接入该应用。在实际项目里我一般会建议先做一张“接入场景矩阵”用户组设备类型网络位置允许应用附加条件客户经理笔记本办公室CRM、OA、邮件双因子认证客户经理笔记本客户现场CRM只读会话超时 15 分钟柜员瘦终端网点核心业务、OA固定 IP 白名单高管iPad任意位置OA、邮件指纹或智能卡这张矩阵做完再映射到 XenApp 的策略引擎里。文档提到思杰与合作伙伴提供双因子认证支持令牌、智能卡和生物识别客户可以选择自己熟悉的安全认证供应商。对于金融行业我倾向于推荐令牌加智能卡的组合兼顾体验和审计要求。4.2 带宽基线20K-30K 是起点压力测试才是终点文档里反复出现一个参数ICA 连接通常只需要 20K-30K 带宽。这个数字被很多人当成万能公式到处套但它有三个前提普通办公类应用、不是图像密集型操作、没有大量打印作业并发。中信东莞分行的 OA 系统跑 20K-30K 没问题大华银行马来西亚的 128K 线路也能跑银行资金业务但换成一个带大量图片扫描件的理赔系统带宽需求就会明显上升。更务实的做法是按应用分类测速我给客户做 POC 时的带宽估算表大致这样应用类型单用户带宽参考评估要点OA、邮件、公文流转20K-30K最典型的 ICA 场景C/S 业务系统30K-50K取决于表单刷新频率图像浏览/文档扫描件80K-150K需配合缓存策略视频/多媒体培训200K 以上建议单独走流媒体通道本地打印额外预留需限制打印数据流文档里提到的 Citrix 通用打印机驱动和带宽限制策略就是专门对付“打印数据流堵住网络”这个问题的。POC 时我要求厂商提供“最差路径”测试模拟最低带宽、最高延迟的网络条件让真实用户做半天业务操作而不是只跑一个登录界面。注意20K-30K 这个数字来自特定应用场景拿它当全行业标准是常见误用。图像密集型、打印密集型场景要单独测算。4.3 集中管理组件负载均衡、单点登录、打印机管理的取舍部署 XenApp 不只是把应用装上服务器围绕集中管理的几个组件决定了项目是“能用”还是“好用”。负载均衡。文档里说的先进负载平衡Advanced Load Balancing动态路由用户至“最休闲”的服务器实现优化的负载均衡和集群管理。没有负载均衡每台服务器单独运行用户随机连一台很可能一台挤爆另一台空闲。部署负载均衡后可以简单经济地扩展思杰服务器在多台服务器上支撑数以千计的用户同时保证例行应用和数据库维护不影响在线用户。单点登录。大华银行案例里每月 300 次密码重置、占 Help Desk 呼叫量 35%这个数字在金融行业很典型。部署 Citrix Password Manager 后用户只需记住一个密码其他应用的密码由密码管理器统一托管。我遇到的项目里这是投入产出比最高的组件之一但也是被砍掉概率最高的组件——因为它不直接影响业务功能只影响运维体验。等到 Help Desk 呼叫量爆表再回头补反而要承担二次集成的成本。打印机管理。思杰服务器之间复制打印机驱动、指定驱动、限制打印数据流带宽这套功能看起来琐碎但分支机构远程打印的体验全靠它。通用打印机驱动减少驱动兼容问题的同时也简化了管理员维护多台打印机的负担。部署顺序上建议核心应用发布第一单点登录第二打印机和负载均衡在初始阶段就规划好不要等到用户投诉才补。5. 避坑与排查从案例反推六条真实踩坑记录案例文档展示的是成功版本试错过程通常被省略。但数字和参数可以反推出当时的坑。这一章我把项目里常见的六类问题按“现象 → 原因 → 解决”拆开每条都从前面案例里的参数出发。5.1 带宽规划翻车拿着 20K-30K 当成万能公式现象某分支机构用 348K 线路接入 Citrix 发布的业务系统操作响应很慢偶发白屏。原因20K-30K 是 ICA 协议在普通办公操作下的典型带宽但前提是应用渲染不复杂、没有大量图片刷新、没有打印作业同时进行。公文系统、结算系统这类 C/S 程序适用但图像密集型应用、带视频的培训系统、大文件打印会在短时间内挤满整条线路。解决按应用分类测速图像密集型应用单独评估启用带宽限制和优先级策略。POC 阶段做最差路径测试用最低带宽、最高延迟的真实网络条件跑半天业务操作。不要用一个办公应用的测试结论覆盖所有业务类型。5.2 密码重置没人管Help Desk 35% 的呼叫量是隐性成本现象XenApp 上线后IT Help Desk 的密码重置请求没有明显下降用户依然记不住多套密码。原因XenApp 解决了应用接入但没有解决账号体系整合。用户要记 Windows 密码、业务系统密码、邮件密码重置请求自然居高不下。大华银行案例里每月 300 次、35% 呼叫占比就是没做单点登录前的常态。解决配套部署 Password Manager 或身份管理方案优先把高频业务系统的密码统一托管。预算不足时先做 Web 门户层的单点登录把最常用的两三个应用覆盖掉呼叫量能降一大半。5.3 老 PC 的“复活”预期落空不是所有旧设备都适合当接入终端现象甲方期望 2000 台旧 PC 全部保留通过 Citrix 客户端接入新应用结果部分机器连 ICA 客户端都跑不顺畅。原因ICA 客户端对硬件要求低但旧 PC 的操作系统版本可能不受支持内存不足时本地浏览器渲染门户页面也会卡。还有一个常见误解用户习惯在本地打开 Office 编辑文档这个操作还是会落到本地执行并不能被虚拟化。解决明确“旧设备能继续用”是有边界的——只要能装 ICA 客户端、能正常跑浏览器就能当接入终端用。对配置过低的设备直接换 WYSE 瘦客户端替换成本通常低于升级 PC 到新操作系统的费用。5.4 打印机映射堵住网络打印数据流没做限制现象远程用户打印大文件时其他业务操作明显变慢ICA 会话卡顿。原因打印作业走 ICA 会话通道如果不做限制一份几百页的报表可能占满整条可用带宽拖垮同一链路上的所有用户。中信东莞分行案例里特意提到“限制打印数据流占用带宽”这是部署后最容易忽略的参数。解决启用打印机带宽限制策略设置单用户打印流量上限。优先使用通用打印机驱动减少不同型号打印机的驱动兼容问题同时压缩打印数据流的体积。5.5 升级节奏失控“东西没坏就别修”的另一面现象方案上线后IT 部门觉得集中发布太方便开始频繁更新应用某次升级直接导致业务系统中断。原因集中化的优势是升级快副作用是单次升级的影响面变大——服务器端一次发布几千用户全部受影响。文档里对思杰方案有句评价叫“东西没坏就别修”这句话反过来理解就是要克制升级冲动。解决建立标准发布流程分批升级。先测试环境验证再开放试点用户组最后全量发布。每次升级保留回滚点避免一次意外中断影响全部网点。5.6 业务连续性只做备份不演练雷曼兄弟的幸存不是靠运气现象客户采购了异地备份真遇到机房断电恢复耗时远超业务可承受范围。原因文档强调“采用最小化中断恢复业务比应用环境和数据的异地备份更有效”但很多机构只做了数据备份没有考虑应用层面的快速恢复。雷曼兄弟能在 9·11 后实现持续交易靠的是应用整体集中化部署加上备用接入点而不只是把数据复制一份。解决至少做两种场景的月度演练——数据中心整体故障和单应用故障。演练要检验的是“从故障发生到业务恢复”的完整路径而不是只验证数据文件能还原。金融行业的监管要求越来越严业务连续性的验证记录是审计必看项。6. 落地验证用这份 PDF 做一张部署前 TCO 测算表把这份 PDF 里的案例参数提炼成一张测算表是验证它价值最快的方式。每次做金融客户选型我会先让客户填一组数字终端设备总数、分支机构数量、IT 维护人员编制、Help Desk 月度通话量、平均带宽成本和 PC 年度升级预算。然后对照文档里的案例比例做估算。测算项填写值参考案例终端设备总数例如 2000 台大华银行 2000 台分支机构数例如 36 个大华银行 36 家分行年 PC 升级费用例如 60 万元大华银行节省 76.6 万美元/年月密码重置次数例如 300 次占 Help Desk 呼叫量 35%单用户带宽占用例如 1 用户 20K-30K中信东莞分行 ICA 参数应用安装耗时全网点例如 2 周河北中行集中管理填完以后做两个换算第一把 Help Desk 月度呼叫量里密码重置占比乘以客服人工成本得出单点登录的预期收益第二把全网点应用升级耗时乘以停机损失得出集中化部署的隐性收益。这两个数字一出来结论通常比任何厂商白皮书都有说服力。然后进入验证环节。选一个非核心业务系统做小范围试点用真实网点、真实带宽、真实业务量跑两到三周。期间只做三件事记录每个操作的响应时间、监控峰值带宽占用、统计 Help Desk 呼叫类型变化。试点通过后再复制到核心业务系统复制时保留原有策略配置只调整资源规格。这份 PDF 的价值不在于它介绍的功能有多新而在于它把金融行业应用交付项目的关键参数和决策点提前写清楚了。我做了这么多年金融行业 IT 项目回头再看这份 2008 年的文档里面那些银行踩过的坑、算过的账今天换一套产品名字仍然适用。从那以后我每次给金融客户做选型都强制自己先走一遍这张测算表用案例里的数字倒逼客户把隐形成本摆到桌面上再谈要不要上虚拟化。希望帮到你。本文还有配套的精品资源点击获取
返回列表