Oracle 全球化经验
作者：Bret Fuller

Oracle 的应用程序 IT 部门的高级副总裁 Bret Fuller 讲述了 Oracle 如何将其全球范围的电子商务系统（70 多个实例）合并成全球单一实例，同时实现了业务过程的标准化。

本文从大约六年前 Larry Ellison 提出的一个简单的问题出发：“有多少员工在为 Oracle 工作？”

在过去，回答这个问题需要从 70 多个国家获取数据，汇总数据并得出总数 — 到这个过程完成时，这个数字已经发生了变化。教训很明显：拥有如此多不同的系统 — 不止是人力资源 (HR)，还包括财务、咨询和客户关系管理 (CRM) — 将难以在一个全球公司内部获得准确和及时的信息。

因此 Oracle 开始着手从 70 多个数据库实例中开发一个全球单一实例 (GSI)，将其全球范围的所有业务数据合并成单个全球视图。今天，利用我们的全球 HR 系统，Larry 可以获得每日更新的为 Oracle 工作（在哪些国家）的人员信息，并且可以获得 Oracle 所有业务的财务、咨询和 CRM 的类似的总数据。此外，Oracle GSI 项目使 Oracle 能够实现其的业务过程的标准化并将其服务合并成四个区域中心（爱尔兰、澳大利亚、印度和美国），从而比以前更有效和廉价地为 Oracle 的全球业务提供共享服务。

在本文中，我将重点介绍 Oracle 在长达六年的 GSI 整合项目中所遇到的一些业务、流程和技术难题 — 以及它开发的解决方案。我们的很多经验适用于许多要求更好地监督世界各地业务的全球公司，这些公司同时可努力降低其 IT 和服务成本。我们为业务管理人员提供了进行全球业务流程标准化的基本原则，我们还为那些要承担艰苦的全异系统整合工作的高级系统架构师、DBA、集成人员和开发人员提供了一个实施图。

从一开始，最重要的事情是设定恰当的目标。着手进行数据库/应用程序整合项目的任何全球性公司都必须首先确定它想达到什么样的整合级别 — 项目的各个方面的范围是区域的还是全球的。

在我们看来，任何整合都可以分成四种级别，每一种级别都基于其前一级别。第 1 级日工作涉及将所有单独的数据库转移和聚合成单个（区域或全球的）数据中心。第 1 级整合的好处是降低了系统管理的设备和人力成本，以及实现了更好的系统服务和可用性。

那就是说，我们必须清楚：仅仅进行数据中心聚合实现不了实际的信息价值。因此，您需要进一步将单独的实例整合成单个数据库。这是第 2 级，这个目标我们称之为“技术整合”。通过第 2 级整合，您可以实现改善的访问和从数据中获取更好的信息，甚至您可以进一步降低硬件成本。

除此，您可以进行第 3 级整合，完成业务流程的标准化，只有这样，才能从您的单个数据库实例中获得更进一步的信息。拥有标准的全球业务流程可以对所有业务进行横向比较，无论您的数据来源于哪个国家。第 3 级整合不仅降低了处理和事务成本，而且还提高了跨公司实施最佳实践的能力。

最后，当您完成了业务流程的标准化 — 并在您的地区或全球实例中进行它们的实例化后—，就能够利用区域或全球服务中心提供共享服务。您现在能够以数量少得多的服务专家，更紧密地集中支持跨不同国家的标准过程，而不用在每个国家配备许多服务代表来执行各种任务。例如，现在 Oracle 有一种标准的方式来输入订单，欧洲、中东和非洲 (EMEA) 地区的共享服务中心中的员工可以为法国、意大利、西班牙、葡萄牙等地区输入订单，并确保他或她能正确输入订单。

Oracle 选择了第 4 级整合作为 GSI 项目的最终目标，虽然我们在 EMEA 和拉丁美洲对项目的各个方面进行了不同的排序，如下所示。但最终的结果是，Oracle 在奥斯丁构建了一个 HR、财务、咨询和 CRM 的 GSI — 并且我们所有的业务流程都实现了全球标准化。最后，我们还为我们的财务服务选择了区域服务中心，在 Dublin、Sidney、Bangalore 和 Rocklin, Calif. 构建了一些服务中心，因为我们觉得这种策略可以更好地服务于每个地区。

其他的战略性决策

当您确定了要进行整合的级别时，就必须有一个由此至彼的全面战略。记住，Oracle 最终的目标是全球整合，但我们首先在各个区域完成大多数工作。我们从区域数据中心中已经存在的不同实例 — EMEA 两个（我们已将其合并），亚太地区一个，拉丁美洲一个、美国一个 — 开始我们的整合工作，并利用这些中心来执行整合。

例如，在拉丁美洲，我们进行了第 2 级整合，其中 10 个单独的国家级数据库被合并成单个区域数据库实例，而无需先改变任何业务流程。这种纯技术整合能够快速推进该项目，在过程最初将节省几个月时间，但它也意味着我们必须在以后再进行这一过程，以进行业务流程的标准化并构建拉丁美洲的共享服务中心。

按这种顺序实施还有其他的缺点。不仅我们最初采用的一些策略使我们无法预先估计我们实际引入的数据的数量和质量，而且我们发现重新进行这一过程将抵消我们最初节省的一些时间。

相比而言，在 EMEA，我们从一开始的目标是第 4 级整合，从而预先进行了业务过程标准化的工作。这使得整合工作更加困难，但它也允许 EMEA 更直接地朝着区域共享服务中心目标前进 — 直到第 4 级。我们不仅在数据中心端降低了技术整合的成本，还在设备和管理 (F&A) 端取得了相应的成本节省。此外，在我们进行整合时由于实现了业务过程的标准化，整合的实例为管理业务预先提供了更有价值的数据。当启动限于公司范围内的计划后（包括新的电子商务计划），所需的改变在所有操作上是相同的，因此可以更快更容易地进行实施。

商务挑战和解决方案

在开始时，我们设立了一个 GSI 建议委员会来监督整个项目 — 一个由来自业务、IT 和开发部门的高级管理人员组成的小组。为了在全球过程和优先级上取得一致，我们之后设置了一个分区域表示的全球组织结构。对于我们想标准化的每个业务过程，我们在业务以及 IT 端设置了一个全球过程所有者。此外，我们从每个区域中指定本地业务和 IT 代表，他们负责确保解决区域内的每个国家的需求。主导企业通过确定它们的业务需求从而取得领先，而 IT 代表提供关于系统功能的指导，帮助企业专注于过程的实际改善 — 在需要时，建议应用程序的一般的改进方法。然后这些工作小组为每一个流程开发新的全球过程。如果小组不能解决某个问题，将提交到我们的 GSI 建议委员会进行解决。

我们调整了我们的工作，根据我们使用的软件的实际情况对全球所有的业务过程进行标准化，以满足我们的业务需求，并在进行整合时尽量实施能够被应用程序的标准版本解决的过程。我们从定义大约 12 个业务流程开始，这些业务流程是跨应用程序模块的，并最终定义了大约 100 个标准的过程，其中一些例子是 HR、提交 (Commissions)、支持续展 (Support Renewal)、采购到支付 (Procure to Pay) 和报价到现金 (Quote to Cash)。我们仅对一个过程进行进一步分析：在报价到现金 (Quote to Cash) 过程中，我们确定过程中的所有功能，如报价、合约、订单输入和产品发送，到发票、收帐和邮寄到 GL。然后我们为每一种功能定义最佳实践，并平衡全球优先级与本地需求。注意 Oracle 电子商务应用程序已经针对世界货币进行了全球化，并针对语言和许多国家特有的法规和经济需求进行了本地化。

全球整合项目中存在大量的技术和数据问题，但我将在此重点介绍管理这些问题所需的过程，而不是它们本身的细节。最困难的情况包括设置、数据移植和转换、数据质量和完整性以及与性能相关的问题。

确定一组达成一致的全球业务过程所需的系统设置是项目的一个关键的组成部分。我们将设置需求分为两个部分 — 全局和局部，以反映两种逻辑需求。全局设置是在实例内运作的所有机构都需要遵循的一种配置。局部设置是在特定的法律实体或国家中进行业务往来所必需的那些设置（例如，通过 EFT 在美国进行支付和通过银行转帐在德国进行支付）。这两种设置都只能在业务流程建立以后才能确定。建立设置要与业务所有者进行合作，但一般而言，取得并将业务流程的定义转换成应用程序设置的配置是 IT 部门的责任。设置的例子包括分配弹性域和它们的验证以及 GL 帐目表定义。

这些设置的一个复杂的因素是它们直接与过程相关，反过来它们也要改变。不过，整合项目的成功要求在设置上实施适当的修改控制。我们在业务过程上实施了版本控制。因此，对过程和/或设置的任何重大的修改都需要对我们的标准单一实例实施模型进行修改。这里重要的一点是修改是不可避免的，但需要管理、记录和控制。

一旦您实现了您的“标准”设置，您就可以实际着手映射各个源实例，以将其转移到目标实例。我们使用电子数据表来比较和分析数据结构、事务类型、主键和外部键映射等。对于每一次移植，我们执行三次测试移植：一次初始技术测试、一次会议室模拟测试（以验证局部环境下的全局过程），一次用户接受测试（事务和容量测试）。然后我们执行最后的生产移植。在 UAT 期间，我们在系统上负载了我们能承受的尽可能多的用户，以进行性能测试，并确保用户的查询能够很好地伸缩以满足日常使用。在月底之后，还将执行 ERP 测试移植（通常在该月的第二个星期），从而我们可以获得两个星期的时间以在下一个月底之前解决所有的问题。

在数据移植期间要解决的另一个问题是实际要移植多少数据。整合项目提供了一个机会，对引进全球单一实例的历史数据的数量进行检查。在 GSI 项目中，我们决定从引进所有的数据开始进行标准化。这允许整合项目向前推进，而不用花时间来分析我们实际能实现和消除什么。

吸取的教训 我们的 GSI 项目的成就是四重的： 我们将我们不同的电子商务系统整合成了一个全球单一的实例。 我们在全球范围对我们的业务过程进行标准化。 我们对应用程序内存覆盖范围进行了标准化。 我们将我们的服务整合成为区域共享服务中心。 这是一条很长的路，但我们在其中吸取到了一些经验教训。 首先，通过指定整合的范围来开始您的项目。根据更佳性能的主要驱动因素，实施尽可能多的标准业务过程。利用全球范围内使用的最佳实践，但同时适时地重新考虑业务。跨公司范围的过程改善所提供的回报比通过简单整合数据库实例实现的回报要大得多。建立一个由执行主管、主要的业务用户和 IT 员工组成的全球小组，并给予他们在公司内部推动业务变革的权力。制定您的项目计划，以基于经验基础进行构建，进而使机构获得成功。大胆但切合实际 — 特别是在您将新的数据加载到整合的实例中时，允许时间来解决不可预见的问题和新的过程机遇。 要获得成功，您必须尽可能地利用您的业务社区。这些社区中的人将通过由整合的系统中获得的更有价值的信息获益。不过，花时间来解释优先级并对小组设定合适的期望级别是非常重要的。标准过程无疑将获得公司范围内的改善，但一些小组可能必须为了其他小组的利益而放弃一些东西。IT 收益与生产效率和信息收益之间的折衷是要实现的一种困难的平衡，但它对于最终结果的总体成功是非常关键的，如果成功执行，您的公司将获益深远。

除了决定要将多少数据引进到整合的实例中之外，您还要在移植过程中关注数据质量和完整性。可以从整合的实例中获得的信息的质量与从单独的实例中引进的数据的质量是直接关联的。在我们的过程中，我们要求每一个国家预先进行一定的数据清理，在过程上设置时间限制，以在实现了移植后执行进一步的清理。如果数据没有清理，我们就不会继续进行移植。因而，进行整合项目的每一个公司都必须审查各个实例中的数据质量，如果必须，还要预先确定清理数据时要应用的相应的资源水平。当然，要专注的主要的领域之一是客户信息。这里是 90/10 规则的一个很好的应用：如果您清理代表着您的最大的客户的 10% 的数据，那么您将在信息方面获得 90% 的好处。

性能和网格

最后，任何执行整合项目的人关心的主要的领域之一是性能。您需要了解三种性能问题并相应作出计划。第一个当然是工作中的整合实例的系统性能。必须小心确保整合的实例能够满足业务所需的性能。这里 UAT 非常关键。

所有相关标准领域都需要进行研究后解决问题，以达到令人满意的水平。当您添加越来越多的数据并增加负载时，您必须为稳定增加的 CPU 和内存、磁盘、并发使用和高峰负载以及网络带宽需求作好计划。它还要求管理用户期望并重新培训用户，以执行更多有效的查询。

我们第二个性能相关领域是实际的移植脚本本身，以及通过 Oracle 工具（如导入/导出和 SQL Loader）传送的数据移植流的带宽。我们必须解决诸如“在任意给定的时间段内我们可以将多少实例转移到一个区域实例中？”以及“要完成转移，区域实例要处于离线状态多久？”之类的问题。我们在指定的一个月内将三个实例转移到了整合的实例中。这个限制促使我们执行并行的区域整合，然后将这些整合后的实例合并成两个全局实例，然后我们将这两个实例组合成最终的 GSI。我们曾希望一旦我们的全球设置建立起来，就将所有的实例转移到 GSI 数据库中。这可以使我们不必将一些实例转移两次 — 一次转移到区域整合的实例中，接着将区域整合的实例转移到 GSI 中。

然而，由于我们紧迫的安排，我们需要多个“渠道”，以在项目的时间期限内完成所有的实例移植。因此，我们决定在后面的阶段继续对两个实例进行整合 — EMEA 实例和美国的实例，然后变为 GSI。2003 年中期，我们将 EMEA 实例移植到了美国的全球实例中。在 2004 年 10 月，我们将（我们已在 2001 年开发的）全球 CRM 系统移植到了 GSI 中。我们现在有了一个真正的财务、咨询、HR 和 CRM 的全球电子商务套件单一实例。

最后，当然必须确保产生的整合 GSI 的性能。这里是 Oracle 即将推出的一个“商用网格”的版本将起作用的地方。我们为奥斯丁数据中心设计了一个可高度伸缩的体系结构，该体系结构在由 50 个商用 2650 Dell Dual 处理器箱组成的中间层群上构建 — 利用了它们快速的处理器以及跨 “BigIP” Gigabit 以太网内部网对特定应用程序功能进行的负载均衡。中间层与一个后端集群连接，该集群由四台 Sun 12K 多处理器服务器组成，服务器运行有基于 Oracle9i 数据库的 Oracle 真正应用集群 (RAC)。Linux 箱根据应用程序和处理类型将处理过程路由至正确的后端节点：例如，节点 1 执行订单处理，节点 2 执行所有的自助式服务，节点 3 执行 Oracle 财务管理，节点 4 执行 HR 和 Payroll，虽然这些负载可以在需要时变动。

电子商务套件的一个单一的应用程序代码树安装在一个在 Oracle 应用服务器上运行的 Network Appliance Filer Cluster 600 上 — 从而减少了我们的系统的内存的占用并简化了打补丁和升级过程。Linux 箱只支持这个代码树，并使用并发管理器完成过程间的负载均衡。单个代码树支持所有的 Linux 箱。反过来，所有的数据库数据 — 6TB 的数据 — 分布在一个 EMC DMX 3000 磁盘阵列上。（参见下图。）最后，出于灾难恢复的目的，在 Colorado Springs, Colo. 中对整个 GSI 系统进行了备份。

全球系统，今天和明天