服务管理职能
作业调度
本页内容
文档用途这份指南面向那些在其数据中心或其它类型的企业计算环境当中业已部署或正在考虑部署Microsoft技术的组织机构提供了有关作业调度服务管理职能（SMF）的详细信息。这是 Microsoft? Operations Framework (MOF) 定义和说明的 20 余个 SMF 中的一个。该指南假设读者熟悉 MOF 的含义、背景和基本概念，以及所述的 Microsoft 技术。 “服务管理功能”指南简要介绍了 MOF 及其配套技术——Microsoft Solutions Framework (MSF)?￡此概述性指南还提供了 MOF 所定义的每种服务管理功能的摘要信息。以下链接处的技术文章提供了有关各个框架的概念和原理的详细信息：http://www.microsoft.com/solutions/msm/. 摘要作业调度服务管理职能（SMF）的目标在于按照预先确定的时间和指定的顺序来确保高效的数据处理流程，从而最大限度的使用系统资源并将对在线用户所造成的影响降至最低限度。批处理流程是一种在无需最终用户干预的方式下在后台通过顺序方式运行的系统数据库交互操作。批处理流程可以通过自动或手工方式启动执行。批处理操作通常在系统用户交互量较低的非工作时段内执行。 批处理操作通常具有自身特有的体系结构，它们一般对资源较为敏感，运行时间较长且属于重复性流程。该流程通常需要从数据库中读取大量数据，对这些数据加以处理并将结果集返回至数据库。这种批处理流程通过执行脚本的方式完成。 组织机构所执行的作业类型包括：
过程与活动作业调度概述作业调度涉及将一连串作业与流程按照最具效率的方式加以组织,实现最大系统吞吐能力与利用效率,从而满足服务级别协议（SLA）需求。作业调度与服务监控及性能管理存在密切联系. 作业调度定义如下内容：
目的与目标作业调度的目的在于在对与系统资源进行交互的用户造成最低影响的同时，确保批处理流程的成功执行。作业调度的主要活动包括批处理运行方式的监控、分析、调优和实现。 内容范围作业调度在将对系统资源用户所产生的影响控制在最低限度的同时，确保批处理操作的成功执行。作业调度的主要活动包括批处理运行方式的监控、分析、调优和实现：
关键定义警告。 针对重要事件的一种标识。警告通过流程规则加以定义。 基线。 在确定IT环境结构并理解环境组件间相互依赖关系的时刻针对IT环境所生成的“静态”图像。从可用性管理角度考虑，该术语同时还用以规范一系列得到公认的IT服务可用性定义及目标。通常情况下，这些定义和目标将通过建模的方式加以证明，并且一旦确定后，便将作为关键可用性设计与报告标准使用。 批处理系统。 一套由一系列命令或作业构成，在无需人工参与的情况下执行这些命令或作业并返回最终结果的系统。这与运行过程中需要通过用户命令和计算机响应方式进行交互的交互式系统恰恰相反。批处理系统通常从磁盘文件（最早为打孔卡或磁带）中获取命令并将执行结果返回到一个文件当中（或将其打印出来）。通常情况下，存在一个等待系统资源可用情况下进行处理的作业队列。 错误检测。 一项用于检测传输过程中数据丢失情况的技术。这项技术允许软件产品通过通知传输方计算机某些数据需要传输的方式来恢复丢失的数据。 事件。 系统或应用中需要通知用户或向日志中添加记录的重要事件。 作业调度。 运行领域内的一项MOF服务管理功能。该功能旨在通过连续方式按照最具效率的顺序对作业和规程加以组织，实现满足SLA需求的最大系统吞吐量及利用率。 任务调度程序。 在规定时间自动调用脚本或程序的系统或应用。 主要过程如下所示，作业调度由四个主要流程和一些子流程组成：
 图 1：处理流程图 批处理体系结构在开始讨论每日操作批处理活动之前，应当首先理解组成批处理体系结构的基本组件。批处理体系结构由用以高效管理批处理流程的规程及组件构成。这部分内容简要介绍了批处理体系结构当中的典型组件。 批处理体系结构的目标在于通过在非高峰时段内运行批处理操作的方式来优化处理方式（提高系统资源响应时间及利用效率）。这种体系结构应当为性能管理者提供一种易于使用接口，并允许其以集中的标准化方式批量执行调度、监控及错误纠正操作。这种体系结构应当具有高度可伸缩能力，以便满足组织机构未来的需求。同时，它还应当具备高度可用性，通过并行执行批处理操作的方式将停机时间以及对在线操作所造成的影响降至最低限度。某些组织机构可能要求对诸如事件服务器这样的组件进行备份，以便确保所有任务关键性批处理作业的顺利完成。 图 2显示了构成批处理体系结构的基本组件，其中包括管理服务器、性能数据库（CDB）、监视器、打印机、应用服务器以及数据库。除管理服务器外接监视器外，每台应用服务器也应连接一台监视器，以便能够查看本地批处理活动；这将有助于简化本地级别上的错误分析方式。 管理服务器批处理体系结构的核心是用于承载批处理调度工具的管理服务器。这种工具允许自动执行预先确定好的调度化批处理作业。这种调度工具通常能够自动执行以下功能：
请注意，不同的作业调度工具在功能上存在很大差异.某些工具可能能够执行以上所列出的任务，而另一些工具则可能只能在特定时间启动某个批处理作业。高级调度工具应允许性能管理者完成以下任务：
调度工具的用户界面对于性能管理者来说应当易于理解和使用。性能管理者应当能够从集中位置上执行以上所描述的功能。从这个位置上，性能管理者应当能够访问控制批处理过程和实施故障诊断所需要的全部信息。 性能数据库（CDB）由调度工具控制的有关每个批处理作业和标准的通用信息通常存储在批处理（或应用程序）日志当中。脚本中应当包含一个能够在三个不同日志文件中记录作业执行信息的作业步骤（脚本代码部分）：批处理日志文件、错误日志文件以及用于存储重要系统事件（包括批处理流程错误和批处理作业执行成功或失败信息）的系统事件日志文件。 CDB是面向所有性能相关信息的集中存储库。理想情况下，批处理与错误日志应作为CDB的一部分或与之实现集成。批处理日志包含有关每个批处理作业的一般信息，以及作业执行过程中与系统性能相关的信息。错误日志负责记录批处理执行过程中的错误以及在批处理执行过程中出现的系统组件警告信息。日志信息的集中存储简化了信息的提取与管理方式。请注意，CDB未必只是一个单一的存储机制，它可能由一组包含在IT环境中所收集到所有性能信息的存储库构成。 在将作业部署到生产环境中前，应针对每个作业收集一般性信息包括：
应当收集的与性能和错误相关的信息包括：
批处理运行过程中所涉及的每台应用服务器应当在本地日志中记录作业处理结果以及性能指标。此后，这些信息将被传送至能够将所有日志信息合并到单一数据库——批处理日志或CDB——的集中平台上。对批处理/错误日志和描述性作业信息进行集中存储的方式使性能管理者能够轻松访问并管理相关信息——用以优化系统性能以及分析并纠正错误的信息。此外，性能数据库还能够轻松备份重要信息。运行报告通常便是利用该数据库中所存储的信息生成出来的。 应用程序服务器负责执行批处理作业的应用服务器同样是批处理体系结构的组成部分之一。每台服务器均安装有一个调度工具实例，它允许对与批处理相关的信息进行本地监控与记录，并向集中位置报告这些信息。应用服务器与相应的后端数据库进行交互，以访问批处理作业所使用的数据。本地调度工具启动由事件处理器分配给其的作业，并向集中调度工具发送完成或错误信息。 监视器与打印机与管理服务器相连接的监视器能够同调度工具和批处理过程进行交互。调度工具通常能够以图形化方式显示性能、状态和执行结果信息。从监视器上，性能管理者可以手动控制批处理过程。打印机被性能管理者用来生成用以评估系统性能并对错误或性能管理器所关心的其它信息予以处理的运行报告。 批处理这部分内容将对批处理过程进行介绍。其中描述了调度化批处理操作如何被执行以及结果信息如河被记录。 在讨论调度化批处理流程之前,有必要首先理解批处理过程的层次结构以及批处理脚本中的内容.图3显示了批处理过程的层次结构。批处理过程由多个以重复方式调度执行的独立批处理作业构成。根据实际需要处理的资源量，大型组织机构每天可能需要执行多个批处理过程。每个批处理作业由多个用以控制特定作业执行活动的批处理作业步骤组成。 组织机构通常需要处理大量批处理作业。为确保以统一的方式执行每一个作业，批处理作业架构应当包含每个作业所需要的标准化代码；与作业相关的特殊信息应当书写在框架中指定的区域内。该框架同时还能够通过对每个作业脚本的内容和结构实施标准化的方式简化开发及维护需求。例如，诸如批处理作业执行成功或失败通知和业务数据归档与删除之类的标准化操作类型应当包含在所有被执行的脚本代码当中。 通常情况下，调度化批处理过程在预先定义的批处理窗口时段内用户访问量最低的时刻被调度工具启动执行。一旦调度工具通过编程实现，除非出现工具无法恢复的错误，否则，性能管理者将不必人为干预批处理过程的执行。 图 4显示了典型调度化批处理过程的流程图。高级别概述意味着使读者对批处理作业的处理方式有一个一般性了解。请注意，调度工具的性能直接决定着哪些功能能够自动执行。 调度工具发起所有批处理过程。如果这些过程未能按计划启动，调度工具会将其中止并在错误日志中记录相应的错误信息，某些调度工具或许还能够尝试重新启动这些批处理过程。如果初始化成功，第一个批处理作业将被执行。调度程序对负责执行批处理过程的每台应用服务器上的作业执行情况进行管理。如果在作业执行过程中未出现错误，那么该工具将在批处理日志中记录作业成功完成并继续执行下一个作业。 如果在批处理作业执行过程中发生错误，那么，调度工具将停止处理该作业并将错误信息发送至错误日志当中。批处理作业的实际执行情况取决于一系列输入条件，这些输入条件决定了作业能否被执行。举例来说，批处理作业可能要求提供以下输入条件：
作业处理过程中也可能出现警告信息，例如，某台用于处理批处理作业的应用服务器的CPU或磁盘空间性能超过阈值。警告应当不会导致批处理作业无法完成；然而，由于这些警告可能导致后面的作业处理过程失败，因此，性能管理者应当尽可能解决所有警告。如果某个错误导致作业被停止，那么，某些调度工具将会尝试自动对所出现的问题进行恢复，并从处理过程停止时所执行的作业步骤开始重新对作业进行处理。对于处理时间很长的批处理作业来说，由于被中断的作业无需从头开始重新执行，因此，恢复机制显得尤为实用。如果恢复过程无法进行，作业就需要重新启动。 如果调度工具无法重新启动或恢复执行失败的作业（或者无法在特定实例中重新启动或恢复执行），性能管理者则必须手工发起重新启动或恢复执行过程。这种情况将在后面的“作业调度活动”部分中详细介绍。 作业调度活动理想情况下，批处理体系结构应当按照将性能管理者所需交户操作减少到最低限度的方式进行配置。尽管如此，性能管理者仍需执行许多日常任务，其中包括：
这些活动均属于完整作业调度过程中不可缺少的部分。如图5中所示,活动的监控、分析、调优与实现构成了一个交互过程。该过程的输入包括资源利用情况以及批处理体系结构所监控的OLA阈值。这些属于旨在优化体系结构性能和利用效率的后续活动。其余活动将根据不同事件、请求或需求加以执行。 监控监控是一项旨在改善日常批处理性能并对未来性能需求予以规划的关键性活动。为确保软硬件资源得到最优化使用以及所有协商确定的服务级别得到遵守，对每项资源和服务的利用情况进行后续监控变得十分重要。收集到的信息（指标）通常存储在性能数据库（CDB）中。这些指标将用以进行趋势分析，对系统体系结构进行必要的调整，并在未来添加新增批处理作业时辅助规划作业用时和相互依赖关系。通常所收集的性能指标包括：
这些数据应当按照总体资源利用率级别和每个系统组件的详细工作负载情况进行收集，来自批处理过程的执行结果应当予以处理。这些信息应用与那些同在线用户相关联的系统组件信息结合使用。这张完整的示意图将帮助性能管理者评估批处理过程会对资源利用率以及整体IT基础架构的系统性能造成哪些影响。 部分监控活动需要建立基线、培植文件或常规操作级别。例如，性能管理者应当针对每个批处理作业建立一个配置文件，以便性能问题以及作业调整对资源使用造成的影响进行评估。如果事先设定的阈值被超过，系统将报警并向错误日志中记录警告信息。 此外，需要指出的是，监控机制将占用一定系统资源并对系统性能造成影响。监控机制应关注于性能测量和OLA阈值。操作级别需求和其它必要的监控元素通常取决于它们为满足OLA所作出的整体贡献。 在批处理运行过程中，性能管理者应当通过集中式调度工具界面来监控批处理过程活动，该界面允许查看所有调度化作业状态（在图6中，该界面由监视器表示）。 批处理作业的成功或失败结果、日志信息以及有关每个作业步骤的详细描述均应能够通过该界面获得。此外，有关系统性能及利用情况的详细信息也应通过图形化方式提供，以便使性能管理者能够通过这些数据评估变化趋势。对性能信息的监控还能够帮助性能管理者存在于批处理体系结构中的瓶颈。当批处理过程中出现错误时，性能管理者将得到出错通知，如果调度工具无法从问题中恢复或重启，他们将采取必要的纠正措施。 所收集到的相关数据应存储在CDB中以便使其它SMF能够进行访问。例如，性能管理功能应能够访问历史数据信息，以便对未来的性能需求进行规划。这些信息是性能关键功能得以提前对系统调整进行规划，从而实现更好的系统可用性与性能，并减少处理错误。 分析监控和收集到的数据将被使用和分析以便对批处理体系结构进行调优。在开始进行调优前，必须进行适当的分析，以确保被调整的组件确实是导致问题的原因。由监控活动所收集到的数据应当进行分析，以便确定用以评估发展趋势的常规利用率和服务级别，或者基准。通过定期监控并与基准数据进行对比，针对特定组件利用率的异常情况或服务阈值将得以定义，与OLA相违背的情况将被报告并采取适当的措施。应针对每一个批处理过程执行数据分析，在此过程中可能会发现如下问题：
在采取适当的调优措施前，性能管理者必须对批处理体系结构优化技术将会对所有系统“客户”造成那些影响具有一个全面的认识。如图6所示，所有批处理请求均是由三个源头发起的：在线请求、调度化请求以及按需发起的请求。 在线请求可以进一步划分为内部请求和外部请求。举例来说，外部用户可能通过Web站点查询组织机构所销售的服装信息，而内部客户可能提交有关客户发货单信息的请求。在线请求会对系统产生较大影响，这种影响可以预测但导致的错误比较严重（可能导致在线使用中断）。所有在线请求均需利用系统资源并且必须在优化批处理性能时予以考虑。在线请求的资源利用率指标应当能够从收集到的系统监控信息中获得。为了规划未来的资源需求，性能管理同样需要使用这些信息。 调度化请求是贯穿本文全篇所讨论了自动化批处理过程。这些请求对系统资源具有很大影响；此类影响具有高度可预见性，性能管理者需要对批处理过程进行调度以便实现系统性能的优化。按需发起的请求由性能管理者针对用户的信息请求（例如获取利用系统资源的并发用户数）手工执行的。这类请求无法进行预测并且对系统资源的影响较低。当尝试确定如何面向调度化批处理过程进行系统性能优化时，上述三种请求来源均需加以分析。 请记住，影响优化过程的最重要因素是支持在线请求所需的性能。由于外部用户将不会访问那些慢速Web站点，而内部用户在遭遇系统响应速度缓慢的情况时工作效率会受到严重影响，因此，内部及外部用户应当享有访问系统资源的优先权。 分析工作在处理异常报告和由调度工具发出的报警信号时同样非常有用。理想情况下，所有阈值均应设置在资源被过度利用的级别以及OLA中的目标以下。这使得性能管理者能够在OLA中的目标被破坏或者资源被过度利用以至系统性能在一段时间内显著下降之前采取必要的纠正措施。然而，在许多情况下，分析工作必须在某种错误或警告发出后才会进行。多这些情况的处理将在本文稍后的“事件管理”部分中详细介绍。 调优性能调优是一项旨在在最大负载情况下实现可以接受的交易响应时间的系统资源优化工作。对监控数据所进行的分析或许能够确定能够通过调优方式更好的利用系统资源并提高性能的批处理体系结构或应用程序领域。 一旦性能影响得到评估，性能管理者便可采取相应的措施来缓解对系统性能所造成的不利影响。在批处理体系结构当中，主要存在四个可以进行调优的领域：
请记住，在硬件设备级别上进行调优的方式并非永远能够提高性能的“简单”解决方案。如果性能瓶颈存在于体系结构的其它部分当中，那么，添加更多计算能力的方式可能无法提供系统性能。 上述每种调优方案均可用于提高批处理性能。然而，在实施这些调整之前，性能管理者必须掌握调优决策将会对IT运行环境的其它部分造成哪些影响。例如，如果对服务器设置负载均衡，那么，由于系统性能可能受到负面影响，因此，将调度化作业分配给在线用户永久使用的服务器可能并非一种很好的方式。出于这一原因，除非变更请求（RFC）被提交并通过变更管理审核，否则，不应进行任何调整。调整过程需要确保IT环境的变化不会对整个环境造成负面影响（如需获取更多相关信息，请参考变更管理SMF）。 实施在对系统指标和错误日志进行分析后，如果性能管理者决定需要对批处理体系结构进行调整，那么，必须向变更管理提交一个RFC。变更管理将确保只有授权变更可以在IT运行环境当中实施，并且这些变更的实施只对整套环境造成最小化影响。变更管理过程同时还确保将IT环境变更记录到配置管理数据库（CMDB）中，配置管理数据库是与所有IT组件（硬件设备、软件产品、处理过程、规程、文档等）信息及相互关系的集中存储机制。与CDB相同，这个数据库同样未必是一个单一存储库。CDB在现实环境中可能是CMDB的组成部分之一（如需了解更多相关信息，请参考变更管理和配置管理SMF指南）。 当提交RFC时，性能管理者应当提供与在IT环境中实施相关修改所造成影响相关的信息。这些信息应当通过对新组件（例如批处理作业）进行测试以及对其对现有体系结构所造成的影响进行评估来获得。在提交RFC时提供完整的影响分析有助于加快变更审核处理速度。变更管理将对RFC进行评估进而将其批准或拒绝。如果RFC遭到拒绝，则应提供描述拒绝原因的相应解释。得到批准的RFC应当在下一个调度化批处理过程之前加以实施。在实施变更的过程中，性能管理者不应忘记利用新增信息更新批处理日志。 变更管理在变更实施过程中将为性能管理者提供指导，以便使其对系统的影响降至最低限度。当变更实施完毕后，性能管理者应对其进行测试或在批处理过程下次运行时观察变更组件的执行情况，以确保实施成功完成。如果出现错误，变更应及时得到回滚，同时，应将环境恢复至原状。变更实施的结果——成功或失败——应及时通知变更管理。（如需获取更多相关信息，请查考发布管理SMF指南。） 事件管理事件管理是对批处理过程成功与失败情况的监控机制。这部分内容关注于批处理过程出现错误时所应采取的措施。事件管理通常是调度工具功能的组成部分之一。 事件监控负责验证生产系统能否按照定义好的服务级别持续不断的正常运转。作业调度工具收到事件后，将通知信息传递至相应的组件进行后续处理（例如，来自应用程序、硬件设备等的电子消息）。它能够提供系统体系结构中发生的历史事件记录。 被跟踪和记录的事件包括错误和警告。批处理作业失败的结果属于致命错误，在作业完成和其它依赖性作业开始运行之前，这种错误必须被纠正。警告通常预示着需要进行调查的系统组件问题（例如阈值被超越）。警告应当不会阻碍批处理作业的成功完成，但其或许以为后续和/或依赖性作业有可能会失败。 当某个批处理作业被执行时，成功或未成功的代码应被返回至调度工具。在某些情况下，调度工具或许能够纠正错误并对失败的作业进行重启或恢复。此外，调度工具还可以对批处理过程进行调整，以便使依赖于失败作业输出结果的批处理作业不会再失败得到纠正前运行。此外，性能管理者需要在错误状况得到纠正后手工重启或恢复失败的作业。需要针对手工重启或恢复操作（如有必要，甚至包括失败的批处理作业）定义并编制一系列规程。 当出现错误时，需要从错误日志文件所记录的信息中确定导致原因，并通知受到影响的最终用户以及批处理作业的所有者。当性能管理者无法纠正错误时，则应将工作移交至服务台（如需获取更多相关信息，请参考事故管理与服务台SMF指南）。根据导致错误的原因，可能需要确定问题所在，如果错误的纠正需要依靠在批处理体系结构中添加、删除或调整配置项目，则应当向变更管理提交一份RFD（如需获取更多相关信息，请参考变更管理与配置管理SMF指南）。 同其它所有系统一样，预先的规划应当减少系统运行过程中出现错误的频率及影响。性能管理和存储管理应对未来的批处理需求进行规划，以减少诸如处理能力不足或存储可用性差之类的问题。这种提前采取的方式应当有助于减少性能管理者在日常操作过程中所面对的错误。预先进行的规划应进而减少采取应急响应措施的需求数量。 事件管理活动应当具备高度自动化。根据实际系统能力，调度工具或者（在调度工具能够有限的情况下）应用脚本应当执行以下任务：
如果调度工具缺乏执行上述任务的能力，则应通过编写脚本的方式来完成这些任务当中的一部分或全部。所有这些的目的在于尽可能实现自动化处理。这将避免用户错误进入到批处理活动当中，并确保纠正措施具有最小延迟。 报警这部分内容介绍了提示自动化系统和手工性能管理者执行事件管理操作的报警机制。报警通常是在某些错误（例如批处理作业失败）或警告（例如阈值被超越）发生时所发出的听得见或看得见的通知形式。性能管理者应当及时对错误或警告报警做出响应，以确保系统正常运行。 错误意味着批处理作业未能正常完成。通常情况下，可能会出现的错误类型包括：
警告意味着某种阈值被超越，同时，性能管理者有责任采取必要的措施以防止系统出现问题。可能出现以下类型的阈值警告：
性能管理者应当尝试通过调优部分所描述的方法对批处理体系结构进行优化的方式来纠正警告问题。无法纠正的错误和警告应当以服务票证的形式提交至服务台。 针对批处理体系结构组件利用率的阈值通过性能管理建立并且记录在操作级别协议（OLA）当中。当建立系统监控点时，应正确输入适当的阈值级别。除非相应的RFC获得变更管理批准，否则不应进行任何针对阈值的修改。 在将系统配置监控特性阈值级别后，还需要由具备相应资质的人员来执行系统监控任务。无法识别并诊断系统问题的性能管理者将无法纠正错误。性能管理者需要接受足够的培训，同时，相应的文档应当能够帮助工作人员确定并纠正问题。如果可能的话，将调度工具配置为在出现错误或警告时自动生成服务票证将非常有效。这种方式有助于确保问题得到及时确定并且能够将解决问题的时间缩短到最低限度。 按需发起的请求处理按需发起的请求通常是用户为手工执行批处理作业而发起的非重复性请求。图7显示了按需发起请求的处理过程。  图 7：按需发起请求处理过程 所有按需发起的请求均应按照图7所描述的流程提交。所有请求均应按照旨在简化请求审批方式的批处理框架格式提交。性能管理者通过对提交的请求进行评估从而确定其是否包含所有需要的信息来开始整个处理过程。如果缺少相关信息，请求将被取消，同时，系统将向请求所有者发送通知并提供相应的解释；请求所有者或许可以随时重新提交请求。 获得接受的按需发起请求应当在测试环境中执行，同时，应当制订批处理作业配置文件以及一系列旨在描述作业执行性能指标。配置文件应当归档至重新提交请求的事件当中。如果测试工作未获成功，系统将尝试确定导致失败的原因，将请求返回至其所有者并给出相应的解释。通常情况下，错误是由不完整或不准确的批处理作业脚本所导致的。 基于配置文件，性能管理者将决定何时执行作业，并统筹考虑作业的资源需求以及批处理体系结构的可用资源需求。性能管理者应当将作业的执行时间通知其所有者，并提供附有完整运行情况的作业执行结果。相应的报告将根据用户的要求和脚本的执行情况打印、归档或发行。归档报告应当存储在批处理体系结构以外的数据库中。 计划变更计划中的变更可能是经过规划或未经规划的。未经规划的变更通常由处理错误或系统警告所导致。事先规划的变更则是系统优化分析的结果。由于生产环境中的变更需要提交RFC，经过规划的调度化批处理过程变更应利用变更管理过程加以跟踪。这将确保只有经过授权的变更能够被实施，同时为作业调度过程的日常操作提供控制与职责级别（如需了解更多相关信息，请参考变更管理SMF指南）。图 8显示了批处理计划变更过程。 对调度化批处理过程进行调整通常采用以下两种方式之一：
对批处理作业所进行的任何修改都将影响批处理过程处理性能，因而在批处理环境中实施前必须首先经过测试和批准。这些变更必须伴随一份经过批准的RFC。添加或修改的批处理作业应当在测试环境中进行测试，并且，与按需发起的请求类似，应为新增作业制订配置文件。需要收集的配置文件指标包括：
通过作业配置文件可以推断中作业变更情况下所需要的资源与时间需求。举例来说，如果配置文件建立在包含1,000条记录的作业基础上，那么，性能管理者可以推断出配置结果，从而确定如果作业包含3,000条记录的话，整个作业需要花费多长时间以及相应的资源利用情况。之后，性能管理者可以确定对作业输入所进行的调整（例如记录条数）将对这个作业以及其它作业的完成造成那些负面影响。换句话说，修订后的作业是否会使其它作业无法获得充足的资源或执行时间？在测试资源有限的情况下，这一点非常实用。 如果作业无法正确执行，则应对变更进行重新评估或将其取消。如果其通过测试，则应将作业分配给某个批处理过程。随后，应对整个运行过程进行测试并对添加或修改作业所产生的影响进行评估。如果将作业从运行过程中删除或通过某种方式对批处理计划进行调整，那么整个运行过程同样需要执行以便对变更所产生的影响进行评估。无论在哪种情况下，如果批处理运行测试无法成功执行，变更均应被取消或重新评估。当批处理运行成功通过测试时，性能管理者应向变更管理提交一份RFC以申请批准实施变更。 在测试批处理运行时，性能管理者必须记住对其可能对在线用户所使用的系统资源造成的影响进行评估。值得再次提到的是，在确定资源利用需求的过程中，在线用户应具备最高优先级。同用户相比，批处理过程的资源需求始终位于次席。除进行实际测试外，如果测试工作无法实施，性能管理者也可在历史在线和批处理数据基础上进行工作负载预测。借助历史信息和批处理作业配置信息，性能管理者应当能够推断出预期的批处理性能结果。当然，没有什么可以替代真实测试和性能监控所具备的效果。 根据组织机构的实际变更流程，针对错误所做出的未经规划的临时调度调整应当无需向变更管理提交RFC。性能管理者应当在其日志记录所有临时变更，以便今后进行查阅与参考。临时变更可能包括：
如果可能的话，此类调整应当加以避免，因为在未对可能产生的影响进行评估前实施调整会对IT环境产生负面影响并且有可能对在线用户的性能造成妨碍。例如，在错误可能导致高优先级批处理作业无法正常执行时，性能管理者应尝试限制未经测试的变更。 针对错误所做出的未经规划的永久变更必须向变更管理进行通报。然而，由于针对错误所进行的调整必须立即实施以确保批处理作业的完成，因此，变更管理必须授权性能管理者在无需首先提交RFC的情况下（按照变更管理所定义的方式）执行必要的调整。未避免对IT环境造成负面影响，应尽可能在实施前对变更进行必要的测试。性能管理者应当在日志中记录所有变更并在时间允许的时候提交RFC（尽可能在调整完成后的最短时间内）。这将确保所有环境变更均能记录在配置数据库中(参考配置管理SMF指南）。 系统备份应当对交易数据和批处理日志信息进行定期备份，以确保业务数据及其它信息的可用性与完整性并提供一种灾难情况下的数据恢复方式。系统备份活动应当关注于为遭到破坏的关键数据提供备份并通过自动方式恢复信息。 与所有运行系统一样，批处理体系结构同样应当定期进行备份。应当进行备份相关信息以及建议备份频率为：
除迁移数据外，系统灾难恢复过程中需要使用的批处理系统体系结构中的所有信息都需要定期进行备份。（如需获取更多相关信息，请参考服务连贯性管理SMF指南。） 归档数据归档是将业务数据写入替代存储机制并随后从批处理体系结构数据库中清除的过程。数据归档的目的是将不断增长的数据库所造成的长期影响降至最低限度；随着生产数据库中的信息不断增加，可能会对批处理体系结构的性能造成一定的潜在负面影响。此外，归档机制还是满足合法的记录保留要求（例如财务及税务报表）所必需的。 性能管理者需要区分应当进行归档的业务数据以及应当删除的数据。需要归档的信息范围取决于组织机构的商务需求（例如财务数据）。这种需求应当记录在批处理日志以及批处理日志OLA中。此外，用户还应掌握那些数据已被归档并删除，从而确定这些数据已经无法在生产环境中进行访问。 在对信息进行归档时，掌握正在归档的信息量十分重要，这将有助于为归档数据提前分配适当的磁盘空间，并解决系统性能问题。一种比较可行的方式是通过表1所给出的表格形式记录每种报告类型的归档存储需求。 表 1 归档存储信息
这份表格使性能管理者得以为负责规划未来存储性能需求的存储管理机制提供存储需求信息（参考存储管理SMF指南）。 审核系统审核应当定期执行。审核的目标在于确保批处理体系结构按照预期的方式运行。性能管理者应当检查每个批处理过程执行过程中所收集到的数据信息，并评估是否需要通过每日执行的任务获取更多或更少的信息。性能管理者还应对CDB、相关日志（批处理和错误日志）以及所有业务数据进行分析，以便确保在一定时间后将历史数据归档并删除（具体时间周期取决于OLA中的特定需求）请注意，某些信息，诸如财务报告等，同其它非关键性数据相比必须保留很长一段时间。 性能管理者日志记录性能管理者应当维护一份性能管理器日志，以便手工记录所有每天执行的操作。应当在这份日志中记录的任务（但不仅限于这些任务）包括：
在向这个日志中添加记录时，还需要包含执行任务的人员名称。 报告功能批处理作业报告需求应当在批处理日志和通过编码方式自动生成相应报告的批处理脚本中指定。某些调度工具可能具有报表生成功能，能够通过配置方式自动生成针对特定批处理作业的报告以及运行相关报告。生成的报告将存储在相应的数据库中，并根据需要自动进行打印。所生成的运行报告类型包括批处理计划报告、错误报告以及性能报告。按需生成的报告也经常会根据用户的要求生成。这些报告包含用户所需数据的组合。 批处理计划批处理计划报告包含调度化批处理过程执行情况的信息。这些报告应当定期进行审核，特别是当批处理过程被修改时，以确保批处理过程的正常调度执行以及系统资源的合理优化。这些报告通常包含以下信息：
这份报告中还应包括有关批处理日志中所列出的每项作业的一般信息。 错误报告这份报告应当在记录相关错误后进行打印和复查。这份报告中所包含的信息有助于性能管理者确定导致错误的原因。相关信息是从错误日志中读取而来的。 性能报告这份报告应当包含有关批处理过程执行性能的信息。有关每项作业的特定信息包括：
这份报告中所包含的信息有助于性能管理者对系统性能实施优化并确定性能下滑趋势。性能管理机制同时还使用这份报告对批处理体系结构的未来性能需求进行规划。 文档与培训所有策略与规程均应提供详细的文档描述，以便性能管理者能够作为日常操作运行参考。文档应当包含以下信息：
如果未经必要的培训，性能管理者将无法执行本文中所讨论的任务。对性能管理者进行必要的培训以使其能够及时对错误做出响应并采取纠正措施非常重要。如果条件允许的话，性能管理者应当参加由组织机构所使用的调度工具开发厂商提供了培训课程。 角色与职责作业调度的主要角色和相关职责将根据行业最佳实践方式进行定义。依据具体的规模、结构以及 IT 部门与其上级企业间的基础服务级别协议，组织可能需要整合一些角色。 性能管理者性能管理者是作业调度SMF的所有者。他负责确保所有批处理作业能够在不影响用户资源可用性的情况下成功完成。在小型组织机构当中，性能管理者可能配有一至两名负责执行日常作业调度活动的助手。然而，在每天需要处理数以千计批处理报告的大型组织机构中，性能管理者可能是一支负责执行以下日常作业调度任务的庞大的团队（本文中统称为性能管理者）：
与其他过程的关系作业调度是Microsoft? Operations Framework （MOF）运行领域内的一项服务管理职能（SMF）。作业调度的主要活动包括监控、分析、调优和实施。同样，作业调度与稍后所描述的MOF体系结构中的一系列SMF存在关联关系。 由于具备与生俱来的后续过程自我完善能力,因此,Microsoft Operations Framework中的每一项功能均可从监控机制中受益.这一点在MOF处理模型的运行领域内尤为显著。作业调度是MOF运行领域内的一项基本SMF。下图描述了作业调度与其它MOF SMF之间的关系。 系统管理系统管理负责处理组织所用的管理模型。某些组织机构倾向于采用所有IT功能均在单一站点上由配属于该站点的IT专业团队统一执行的模型。其他组织更愿意采用分布式分支机构模型（技术和支持队伍在地理上均是分散的）。系统管理会检查每种模型的权衡情况。每种类型系统管理模型均具备特有的批处理过程管理需求。 安全管理安全管理是一项关注于安全控制机制实施与管理的IT规程，这些安全控制机制旨在强化企业安全策略，从而确保IT生产环境内的数据与系统安全性。由于某些通过作业调度过程创建的企业输出数据（例如报表）必须确保安全性，因此，作业调度与安全管理之间存在着一定的关联关系。系统管理员和安全管理员需要相互协作，以确保企业数据安全策略得到切实贯彻。 服务监控服务监控允许运行维护人员对服务的健康状况进行实时监测。 注意： 实时在这里的主要含义是“及时”。例如，定时方式可以由数据源的上下文环境以及管理信息或纠正操作的需求来确定。（服务是否处于运行、停止或临界状态？） 尽管非常重要，然而这种观察方式完全是一种自然反映，在当前竞争激烈的市场领域内，仅仅允许运行维护人员对IT环境中所出现的服务问题做出反应是远远不够的。此外，极为重要的一点是，服务监控机制为运行维护人员提供了对通过前瞻性方式（例如在实际故障发生前发现问题和潜在的服务中断可能）对服务行为进行检测的机制。为运行维护人员提供具有良好响应能力和前瞻性的监控机制是服务监控最佳实现方式的实际定义。 然而，除非运行维护人员有能力采取必要的应对措施，或者至少通知相应的团队加以预防，否则，仅仅了解当前服务的健康状态或确定服务可能将会中断的意义不大。这便是术语控制的意义所在。通过合理的结合与实施，服务监控将为运行维护人员提供确保服务级别所需的关键能力。缺少适当的服务监控机制，服务级别协议将名存实亡。 服务监控为确定服务性能级别奠定了基础。服务性能的优化意味着需要对应用的端到端响应时间进行监控。在运行良好的IT环境中，性能级别将得到预测，监控系统将设置阈值报警，以便服务客户感觉问题之前触发警报。由于批处理过程必须进行评估与优化，以便使在线用户不会因批处理运行所导致的系统性能下滑而受到影响，因此，监控是作业调度中的一项重要活动。 网络管理网络管理是一项关注于在变更控制与配置管理控制之下管理所有生产网络的IT流程。网络管理必须与作业调度协同工作，以便共同努力优化网络资源并确保严格遵守网络管理服务级别目标。 网络管理应当提供网络使用情况、带宽情况以及趋势分析等数据，以确保能够对集中存储在性能数据库（CDB）中的预测性能规划信息进行访问。作业调度应当为网络管理提供网络性能需求，以确保在批处理运行过程中能够获得足够的带宽。 存储管理存储管理涉及旨在在IT环境中运行并维护存储管理的日常活动。批处理过程需要大量可用磁盘空间来存储业务数据。性能管理者应当通过存储管理来调整预期的磁盘存储需求。 容量管理性能管理是为满足用户需求而对服务解决方案性能进行规划、评估与控制的过程。批处理系统需求以及所有运行数据信息均应提供给性能管理机制，以便精确规划未来的性能需求。 变更管理变更管理负责处理组织机构内部的变更协调，其中包括软件升级、整套系统的彻底检查、组织机构或人员调整、业务调整等等。对批处理体系结构的日常运行调整可能旨在尝试纠正系统错误并通过调节批处理体系结构的方式优化系统性能。针对IT环境的所有调整都是以变更请求（RFC）的形式通过变更管理渠道实现的。 由于批处理过程通常会占用大量系统资源，因此，对时间的调整必须与可用性管理协调进行，以便确保批处理过程在IT环境中的执行效率。合理的协调对于确保执行批处理过程所需的充足资源和满足在线用户的服务级别需求而言非常重要。 配置管理配置管理是一项旨在对IT环境中的硬件设备、软件产品、文档以及其它所有组件进行跟踪与统计的流程。配置管理负责维护用于跟踪所有IT相关组件的配置管理数据库（CMDB）。在批处理体系结构环境中实施的所有变更都必须记录到CMDB当中。 服务级别管理许多组织机构当中存在着IT服务提供者与消费者之间的协议，然而，其中某些协议是非官方的、想当然或对于一方或双方而言不够明确的。服务级别协议（SLA）和操作级别协议（OLA）的审核与准备是服务级别管理的一项主要工作。批处理过程指南服务级别管理负责准备的OLA加以定义。 服务台服务台负责提供有效、及时的高质量用户支持与事故管理机制。批处理过程中遇到的所有问题都应当直接通报至服务台以及所有受到影响的所有者和拥护。 投稿人本文所述的具体操作中有许多都是来源于 Accenture、Avanade、Microsoft Consulting Services、Fox IT、Hewlett-Packard Company、Lucent Technologies/NetworkCare Professional Services 和 Unisys Corporation 等公司和部门多年的 IT 实践经验。 Microsoft 十分感谢上述组织机构在为本文档提供信息资料方面所给予的慷慨协助。 项目管理小组Jeff Yuhas，Microsoft公司 William Bagley，Microsoft公司 主作者Curt Humes, Accenture 联合撰稿人William Bagley，Microsoft公司 Vicky Howells，Fox IT Jeff Yuhas，Microsoft公司 编辑Patricia Rytkonen，Volt Technical Services 本文所包含的信息代表Microsoft公司在文章发表之日对相关问题所持有的观点由于 Microsoft 必须响应不断变化的市场条件，因此本文档不应该被理解为 Microsoft 的承诺，Microsoft 不能保证在文档发布之日以后文中所提供信息的准确性。 本文档仅供参考。MICROSOFT 对本文档中的信息不提供任何形式的（包括明示或暗示的）保证。用户有责任遵守所有适用的版权法。在版权法所赋予权利的前提下，未经 Microsoft Corporation 明确的书面许可，任何人不得将本文复制、存储或引入可检索系统，或是以任何形式或通过任何方式（电子、机械、影印、录制或其他方式）传播本文的任何部分。本文主题可能涉及 Microsoft 的专利、专利申请、商标、版权或其它知识产权。除非获得 Microsoft Corporation 明确的书面许可，否则提供本文档并不代表许可您使用这些专利、商标、版权或其它知识产权。除非另外注明，否则此处作为例子提到的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件纯属虚构，不得与任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件相联系或随意推测。 2002 Microsoft Corporation.保留所有权利。 Microsoft 是 Microsoft Corporation 在美国和/或其他国家（地区）的注册商标或商标。 本文中提及的实际公司和产品的名称可能是其各自所有者的商标。
|
本文内容
|
