运维控制中心白皮书

运维控制中心

白皮书

2013年9月1日

目录

运维控制中心 (1)

运维控制中心——概况 (3)

什么是OCC? (3)

OCC由什么构成？ (11)

为什么客户需要OCC？ (13)

提高业务连续性 (13)

提高业务满意度 (14)

提高IT支持效率 (14)

降低运营成本 (14)

OCC是如何工作的？ (15)

提供透明化 (15)

解决警报 (18)

持续改进 (20)

OCC前提条件 (21)

SAP在客户端OCC中的作用 (21)

OCC中的关键角色 (22)

OCC 团队负责人 (22)

IT运维人员 (技术 /功能) (22)

负责业务连续性的质量经理 (23)

负责业务流程优化的质量经理 (23)

运维控制中心——概况

运维控制中心(OCC)是“工厂化运行SAP”的具体体现。OCC能够确保高度自动化及主动的操作，此举能够在降低运营成本的同时提高IT服务质量，从而提高企业满意度。此外，OCC 能够不断推动业务流程的改进和IT支持。运营控制中心与创新控制中心 (ICC) 和SAP任务控制中心 (MCC) 的紧密联系旨在支持这些目标的实现。

图1: OCC，ICC及MCC

ICC旨在助力SAP客户实现“工厂化建立SAP”。ICC能够最大程度地使用SAP标准功能，通过端到端的集成验证保护和优化投资，并能够保证上线后平稳无中断的运行。MCC基于SAP在全球各地的办事处，随时准备为客户提供关键支持。图1展示了上述三个控制中心。

在OCC，一组IT运营人员负责SAP生产环境的维护。根据环境和业务流程复杂性的差异，两个运营人员一班制（全职雇员）能够理想地进行环境的维护，通过SLA（服务等级协议）达到4小时内解决业务问题的目标。

什么是OCC?

OCC是位于客户现场的IT支持团队，能够积极主动地监控SAP的生产环境（及重要的非SAP应用）。我们建议客户在IT支持部门内设立OCC办公室。图2显示了OCC的外观和整体布局。

图 2: OCC布局

业务流程状态，IT架构部分组分，所有的关键业务，IT异常事件及警报都会显示在大屏幕上。当问题出现时，合作伙伴和SAP可以通过视频会议进行沟通。其他IT支持团队同样可以包含在OCC办公室。例如，部分服务台团队能够提高跨团队沟通的效率。OCC办公室是在SAP AGS的帮助下由客户方建立的，由客户方主导，技术团队和IT功能操作人员密切提供帮助。

图3展示了OCC的几个基本概念：

?OCC收集IT构架组件及业务流程在技术层（“应用系统运维”）和功能层（“业务流程运维”）上的监控信息（此模型由第三个基础设施层进行扩展，见图7）。

?数据存储于SAP解决方案管理器中，并通过“集中监控”（例如OCC办公室的电视屏幕）、报表或仪表盘进行显示。

?基于上述数据，事件管理流程将生成警报并经过预先处理。

?持续优化流程意在改善业务及IT难题。集中监控提供的数据（如趋势数据）对此过程予以了支持。，有几个过程标准（如“PDCA”，“DMAIC”）可用。

对IT服务管理(ITSM)具有强大的集成和依赖性，即事件管理，问题管理和变更管理。

图3：OCC概念展示

OCC能够交付的成果和带来的收益：

更高的业务可用性及商业用户满意度

OCC的基础架构能够全天候不间断收集和评估所有生产组件的信息。技术和业务流程异常事件会引发SAP解决方案管理器中央警报收件箱的警报。 IT运营商（技术和功能）能够在第一时间获悉，并立即进行分析和纠正。

根据初始设置，在业务受到影响之前就可以将问题检测出来并予以解决。至少IT支持有更多的时间来分析形势，并且在收到用户电话前已经开始对问题进行修复。此外，报警系统可以与SAP解决方案管理器的IT服务管理模块（ITSM）进行集成，并与第三方IT服务管理工具进行同步。

与重新激活的操作方法（即IT支持等待业务用户将问题上报的做法）相比，这种积极主动的做法将带来更高的业务可用性，更佳的IT服务质量，从而提高商业用户满意度。

SAP运营工厂化能够带来更高的IT效率

管理和监视活动通常是手动执行(如：“每天早上，检查事务XYZ”)。这些活动通常可以通过设置SAP解决方案服务器警报进行自动监测替换：监控基础架构主动报告问题和异常事件（警报）。没有警报表明不需要手动检查，所有一切运行正常。

“事件管理”这一术语描述了从警报创建至关闭的过程，见图4。在OCC，事件管理是高度结构化的：

o IT运营人员一般从SAP解决方案管理器的中央警报收件箱开始工作。

o需要做的工作（例如特定KPI的历史数据）显示在警报环境及知识数据库中。

o“操作指导”会提供详细说明，对运维人员首先要采取的分析步骤进行指导（“操作指导”是SAP解决方案管理器的向导式应用）

o如果问题不能得到解决，IT运营人员可以轻松通过点击鼠标创建一个事件，并将其传递给下一级支持人员。与ITSM的集成可作为服务台水平的双向接口的

技术基础。

图 4: 事件管理流程

IT运营人员能够解决不需要专业知识的简单问题，以便第二级支持能够腾出更多宝贵资源，专注于项目及持续改进。

SAP解决方案运营状态的整体透明化

整体透明化：OCC能够时时

报告生产环境状态，包括关键业务流程。这可通过多种方式进行:

o运行SAP的企业希望了解其核心业务流程和技术组件的状态。 SAP解决方案管理器能够提供多种方式来监测“可用性”（技术以及相关的业务流程）。此

外，未来趋势信息等关键性能数据能够在OCC显示器内接近实时地收集并显

示。

o除了常见的监控器，客户可能基于其特殊的设置和配置，需要额外的监测数据。

此类需求可能是为了获取关于某关键业务接口的报错细节，或有关业务数据一

致性的信息。这些监控需求可以通过激活额外数据源，或通过使用SAP解决方

案管理器提供的严格定义的扩展选项来满足。

o数据需要根据不同的接收人进行相应处理并报告方案。与CIO相比，IT支持专家需要不同的数据和聚合水平。为了满足所有的需求，SAP解决方案管理器

提供了丰富的报告技术，从静态的PDF文件、高度聚合及互动的仪表盘、直至

各级监测数据（技术以及相关的业务流程）。很多提供的报表已经通过SAP 最

佳实践的方式进行了预配置。

?组件集成的整体透明化

在当今IT世界，SAP和非SAP组件相互紧密协同的情况极为常见。核心生产部件之间的接口成为关键业务，比如接口的可用性，数据的一致性，生产量等等。关键是要不断监控SAP和非SAP接口和组件的集成。OCC的的中央显示器能够从多个角度提供状态和性能整合的完整的画面。具体例子如下：

o最终用户体验监控（EEM）展示终端用户视角

o PI监测展示跨系统信息流

o BI监测展示报表层面

o接口通道 (IC) 监测展示接口层面

值得一提的是，SAP与非SAP组件都能够纳入这一画面。例如，CA Wily Introscope 完整版，及SAP IT基础架构管理能够作为关键业务处理的一部分，为非SAP组件提供相应的集成能力。

?持续改进业务及IT

作为OCC的第二个核心流程，SAP建议设立一个不断完善的过程。一旦启动，持续改进会对问题的根本原因进行结构性的分析及归档。收集、优先化、测试并实施改进建议。不断测量改善活动的成功度。

持续的改进能够帮助解决主要运行难题及面临的挑战。根据改善项目，建议的修改可能影响业务流程或IT支持流程的设置。这可能会带来新的“工厂化运行SAP”项目的实施。

在瞬息万变的商业世界，IT不能始终处于被动状态。商业在不断改变业务应用，业务流程及流程配置。这些变化会引入新的关键业务流程和相应的潜在的异常情况，因此需要OCC的检测控制。换句话说，对当前业务的分析并不是需求变化的唯一来源。为避免上述风险，也许除显示器之外，IT支持流程及业务流程也需进行变更。

持续改进是一个结构化的多步骤过程，市场上现已有几个改进流程定义。比如由戴明博士推广的PDCA循环，共包括4个步骤：计划（Plan），执行（Do），检查

（Check）和执行（Act）：

图 5: PDCA 循环流程

o计划：规划改善先后次序

o执行：将第一时间的想法在现实中进行验证

o检查：检查结果，并定义新标准

o执行：实施新标准

流程步骤的数目和背后的改进理论并不重要。例如DMAIC改进理论或许能提供类似

的结果。然而，重要的方面是建立持续改进IT的理念。此外，改进过程本身需要得到

高级管理层的关注，从而真正解决、纠正新发现的业务挑战及难题。

在建立OCC时，SAP需要考虑将持续改进无缝集成到现有的IT支持环境上。集成通

常是基于两个层面：IT支持工具，和IT支持流程，例如：

o数据取自现有的IT支持工具，以推动这一进程。例如第三方服务台工具的事件管理数据能够帮助识别最终用户经常体验到的痛苦。不断改进过程中所引发的

变更由现有变更请求管理工具进行管理和跟踪。

o根据成熟水平，持续改进现有的事件、问题管理流程可以重复利用概念、角色、流程和程序。

因此，SAP运维作为一个整体将变得更具创新性。通过提高效率，不但可以释放出在

运维环境中需要的资源，同时也可以使IT运维团队在更短的时间段内处理更多的问题。

OCC与ICC和MCC深度集成。

ICC与OCC进行双重集成

一方面，不断改进的过程可能带来新的改进项目，这一项目将由ICC进行管理。另一

方面，ICC需要考虑客户需求，以保证当新的应用进入生产环境后的顺利运维。

o在开发过程中，ICC负责执行共同开发标准（例如：编程过程中，描述该做什么和不该做什么）。产品相关的开发标准可能会定义性能方面的额外要求。

o通过用户测试 (UAT)，ICC需要向OCC递交运维文档，描述包括新发展、系统架构、预期的数据量、重要的新批次处理作业、额外的性能要求在内的业务

流程和接口。

一旦启动传输至生产系统这一流程，通常一个由项目和生产支持环境专家组成的联合

小组将努力确保顺利运维。这是通过ICC“集成验证”(IV) 的方法来实现的。

新引进的应用程序通常包括：

o技术监控涉及所有的IT环境组件。技术监测覆盖技术组件的可用性、性能、技术异常和配置。

o对关键业务流程和业务流程步骤的监测——包括关键业务交易、接口、业务异常事件和后台作业。

o根据新应用程序的类型，基本监测业务数据的一致性十分重要（例如：由于相同的业务数据存储在多个系统，新推出的ERP-CRM方案需要监测业务数据的

一致性）

o估计数据量、增长率、以及它们对硬件设备配置和技术能力的影响

o对特殊组成部分的监测，如SAP PI/BI（包括SAP HANA场景）

o通知所有IT运营人员及负责人注意警报

所有上述列出的项目需要记录到适当的文档。例如，IT架构和业务流程需要记录。必

须有文档记述IT运营人员在警报的情况下或在一个异常的情况下需做什么。如前所述，ICC负责提供基本的文档。这一基本文档由运维方面进行完善，并存储在SAP解决方案管理器中。然而，为了提高工作效率，文档应该尽可能存储在相关的行动中。这即

是SAP引导程序：一个向导类型的应用程序，其能够提供一定的分析或校对功能（本地在SAP解决方案管理器中，远程在被管理系统中）。 IT操作人员可以安全地执行

操作。经验丰富的二级支持专家却可以直接调用专家工具。

引导程序可以用来分析警报，并处理定期和临时的管理流程（如定期的数据库备份）。因此，集成验证还需要确保新的或变更的管理流程能被妥善记录。

ICC和OCC的成员的联合努力对此定义工作很关键。这一阶段的文档和监控设置通常

不会在上线之后就结束。尤其对于最大关怀客户，监测空白区变的显而易见。针对最

大关怀，故障诊断例程的文档需要基于真实情况中的问题来完成。当最大关怀接近尾

声，新引入应用程序的运维负责方已经完全转移到OCC。这意味着：

o.如上所述对新应用程序的监控已被记载和设置。

o配置警报，分析过程被记录及配置为引导程序。

o IT运营人员已就如何合理使用中央监控和警报的收件箱进行了培训。

?当客户需要在故障排除生产环境下获取SAP帮助时，需要SAP MCC与OCC的深层集成。比如在持续改进循环流程的计划阶段，客户想要SAP分析某个对业务或者IT

有巨大影响的问题。如果客户无法找到根本原因，或不能提出改进建议，即可直接与

SAP MCC取得联系，即刻启动相应的分析服务，并在大多数情况下提供远程视频连接。

当然，对于SAP MAXATTENTION客户，与MCC的连接更为直接，因为其可直接访

问SAP个人资源（例如，通过按需专家）。

OCC由什么构成？

?一套中央显示器，能够持久报告业务流程和相关IT架构的状态，包括重要的业务和技术异常事件。

OCC的中央监视器始终以客户的具体需求为重。然而，与SAP的支持标准相对应，

一组标准显示器能在许多情况下进行使用，如图6所示。此标准显示器能够提供业务

流程状态，IT架构组件的状态，以及最终用户角度下的性能和警示收件箱的状态。

图6：OCC标准显示器

客户特定的扩展能够显示系统之间数据不一致的数量，或者关键接口错误信息。根据监控实体，SAP能够区分三个层次：

o业务流程层，由业务流程运维处理

o应用层，由应用运维处理

o IT基础架构层，由 IT架构运维处理

图 7: 监控的三个层面

基础架构运维用来管理IT基础架构层上的（SAP和非SAP）项目（例如：打印机和

网络交换机），通过从SAP基础架构管理（需要额外的许可证）获得强大的集成功能。

主存储库是一个配置管理数据库 (CMDB)。

应用运维能够基于SAP的RCA工具套件，CA Wily Introscope，处理详细的技术监

测、预警和异常数据（如响应时间，数据库的大小和增长率）。同样可以覆盖SAP和

非SAP组件。

业务流程运维能够处理监控、警报和业务流程的异常数据，以及各个业务流程步骤

（例如，创建销售订单的数量）。

作为SAP解决方案管理器的一部分，所有数据都存储在SAP BW中。其可用于监视，

警报和报告。

?警报监测基础架构，无需人工操作，全天候7x24积极监控解决方案，在出现问题的情况下，将触发警报和关联问题。警报附带在警示收件箱中。

?一组小的IT运营团队（“2个运营人员一班制”；技术和功能范围，取决于集中监控），以标准化的方式进行警报（事件管理流程）工作：

o执行初步分析（文档化/引导操作）

o只需点击鼠标，即可将警报上升至事件/服务请求，假如警报无法得到解决，则需要下一级的支持。

?持续改进流程，能够明确运营痛点。这通常是通过基于SAP Solution Manager的监控数据的趋势分析来支持的。一旦过程启动，将是不断优化的过程：

o明确根本原因

o采取必要的行动，减轻风险

o跟踪和报告成功案例

为什么客户需要OCC？

提高业务连续性

客户需要OCC，因为其能够提供透明化，标准化，自动化和主动化的服务。业务连续性能够

通过主动化运营（警示驱动）模式进行提高：在问题对业务造成影响之前，能够理想化的进行自动检测和自动提醒。例如，OCC能够自动检测到一个SAP文件系统的溢出。当SAP系统

受到影响之前，可以启动纠正措施（清理或延长）。集中控制能够提供IT运营人员与支持专家所需的信息，以确保业务流程和IT组件的可用性。

提高业务满意度

持续提高改进业务满意度表现在两个层面。集中支持层面，这一过程重点为防止再次发生单一重大事故和循环发生的微小事故。由于每个事件代表业务的机会成本，减少事故的发生能够带来更好的业务满意度。

此外，持续改进流程使用解决方案中的所有信息，助力IT提高企业用户的业务流程。例如，系统读取指标有助于识别不必要和非生产性的手动操作，这些手动操作可以被自动化所替代。除此之外，可以发现业务流程中隐藏的积压工作及瓶颈。使用这些和其他手段，IT能够从成本中心转变为业务客户的创新伙伴。

提高IT支持效率

与根本原因分析工具集的紧密集成有助于更迅速的找到发展瓶颈。运维支持中心的集中监控能够提供额外的信息，有助于重新建立最佳性能（技术和业务流程相关）。

降低运营成本

系统管理工作的标准化和自动化将伴随运营成本的显著降低，例如：

?系统管理可以通过创建引导程序进行标准化。同时，提高了服务质量、治理和控制水平，降低了经营风险。

?每日手动健康检查可以完全由新的警报监测概念所取代。基于警报的发生、技术和业务流程的性能数据，系统报告状态能够进行自动报告。

IT运营人员提供的额外支持，能够使二级支持专注于复杂及关键项目。总体而言，客户能够投入更少的成本实现更多的价值。

OCC是如何工作的？

提供透明化

OCC中央监视器提供透明化的生产环境（SAP和非SAP）运行状态。集中监控可以在OCC 办公室的壁挂电视屏幕中采用自动刷新模式，或按IT运营和IT支持专家的需求进行调整（参见图2）。

显示器显示的部分为标准化（包含“必须”的监测信息）信息，部分基于运行要求，而每一位客户的运行要求各不相同（例如：一个大型SAP银行系统与一个大型SAP企业仓库管理环境的运行需求有所不同）。集中监控的标准部件或常用部件通常包括四个部分，即“四大屏幕”：技术状态视图，功能及业务流程中的状态视图，最终用户的角度，和警报收件箱（参见图6）：

技术状态视图使用红绿灯来显示所有被纳入监控范围内的生产系统的可用性、性能、配置和异常事件。IT运维人员或者技术支持专家可以从这里直接深入单个系统，并查找到详细的技术指标及这些指标的历史记录。

图8：技术状态视图（系统列表）

专家中心 (COE) 团队负责人和SAP基础管理员希望不断了解核心生产系统的状态。

OCC能够提供在对方的智能手机上安置移动应用程序视图。

?业务流程概述显示每个业务流程，或每个接口步骤的红绿灯。从这里开始，IT运营人员或功能支持专家可以直接深入查看各个警报的细节、历史和分析意见。

图9：业务流程视图

?此外，通常从最终用户的角度来讲，特别是对于连接不同区域间的对话用户。如果监控进程的总响应时间（包括网络时间）超过接受范围，最终用户方面的监控将立即显示。从总体视图角度，IT运营人员与支持专家可以深入到单个模拟活动步骤，历史视

图或仪表板。

图10：最终用户的角度下的性能视图

?第四常见的视图为自动刷新模式下的警报收件箱。下一的章节将详细描述的警报收件箱的使用情况。

然而，除了公认标准，客户定制的额外显示视图也可作为OCC的一部分。

?一位拥有复杂集成场景的用户除使用SAP PI之外或许还使用了其他非SAP的中间件组件。非SAP组件可通过CA Wily集成到SAP解决方案管理器。对于SAP PI，额外的监控视图可以显示不同层面的PI具体信息，如PI的基础架构组件的可用性、PI数

据加载及PI特定警报。未来，还将提供信息流相关的内容。

图11：消息流监控

许多客户已经拥有了先进的BW场景。同时，他们希望SAP BW，SAP BO，以及数据源系统能够显示在一个视图。其中有些客户已经拥有了基于SAP HANA的BW系统，并希望也将其融入进来。OCC能够提供专门的BW视图显示所有组件，IT运营人员可以向下钻取到的各个组成部分并进行详细分析。

图12：在一个视图中监控BW/ BI架构（包括SAP HANA）

解决警报

第一个OCC流程被称为事件管理，并定义了SAP解决方案管理器发生警报时的所有活动，直到警报关闭。为了进一步说明，我们向您提供一个示例。

IT运营人员负责集中监控和警报收件箱。他们将于定期或总览监视器的指标变红时检查警报收件箱。假如警报监控基础架构检测到一处关键后台作业的故障，警报收件箱会出现一个红色警报，并在运行时自动更新。 IT运营人员打开警报，并指派自己为处理者。包括排除故障的描述，重新启动选项及联系人在内的详细工作文件，都会包含在指导流程中，并连接到警报。通过这些信息，IT运营人员能够立即跳转到被管理系统中进行正确的分析作业（在这种情况下，为事务SM37）。 IT操作人员检查作业日志，在特定误差场景下，他应该重新启动该工作。当工作成功重新启动后，IT运营人员将关闭SAP解决方案管理器的警报。

假如无法重新启动工作，IT运营人员只需轻点鼠标，将警报转变为一个事件，并将其转发至工作文档中所任命的负责人进行下一步处理。事件管理流程将通知该负责人。他/她只需一击鼠标就可以及时从事件跳进警报。

图13：SAP解决方案管理器中央警报收件箱的视图

当警报的原因解决后，IT运营人员需要添加注释，并关闭警报。随后警报将从收件箱消失，但如果需要其仍然可以从历史列表中检索到。正常处理过程中，IT运营人员的任务是保证警报收件箱里没有严重警报。

持续改进

第二个OCC流程称为持续改进，旨在明确并优化对业务或IT造成重大运维难题的领域。

我们用以下两例加以说明。

示例1:

第一个示例中，SAP解决方案管理器的中央监控器显示，SAP ERP以及CRM系统中皆存在持续几高频率的ABAP dump。此外，还发现相当数量的失败的更新记录。

SAP事件的结构化分析表明有相当多的一部分事件举报是关于业务部门用户抱怨客户和生产主数据的丢失或不一致。

为分析现状并探索问题的根源，客户端OCC联络了SAP MCC，请求在业务数据维护流程中联合进行解决方案管理评估（SMA）。除了重要的维护流程问题，SMA还发现了CRM与ERP之间一个核心接口存在的问题。SMA为该接口提供了了接口分析服务（IFM）。

SMA与IFM推荐了一系列软件及设置的调整，来避免业务数据不一致问题。但是这

里缺少的是数据一致性监控：客户不了解当前状态，也不清楚拟议的改进建议是否能解决问题。

鉴于业务已经受到影响，客户决定遵循SMA的建议，将相关变更项目的重要性列为

“非常高”，以避免此领域中再次出现任何新的数据不一致问题。

为了使当前和逾期状态的信息具有透明度，OCC中还设立了其他监控器：

o第一台监控器定期检查ERP和CRM中客户及产品主数据的数据一致性。

o第二台监控器自动汇报ERP与CRM之间核心接口中出现的错误。

o第三台监控器汇报dump及中止更新。

现有的记录值可以继续做为基准的衡量标准来参考。

维护交易以及核心接口上的变更项目由ICC进行移交、启动并管理。

此外，数据一致性管理流程最近在IT中实施，业务同行也参与其中。如果新的数据不一致问题被汇报，该流程将分析状况、清理不一致数据并预防新问题产生。负责团队可以就这两个系统中原有的不一致数据立即采取行动。