Exchange 的人力资源规划

 

适用于: Exchange Server 2010 SP3

上一次修改主题: 2016-11-28

您可能想知道:“需要多少 IT 专业人士来管理我的 Microsoft Exchange Server 环境?”遗憾的是,要回答此问题没有那么简单。但是为了帮助您进行规划,本主题介绍了在计算最佳人力水平时必须考虑的几个主要因素。本主题将帮助您评估组织的许多方面,以便您可以在人力水平方面做出明智的决策。

注释注意:
虽然本主题侧重于 Microsoft Exchange Server 2010 部署,不过也可以使用其指导来估计用于管理以前版本的 Exchange 的人力。

就高层次而言,人力水平基于组织成熟度和所需任务。组织成熟度基于以下原则:操作过程成熟度、经验、硬件、可靠性和设计。所需任务因公司而异,由评估和管理过程的 Exchange 管理员决定。

组织成熟度

实际上,组织成熟度由组织制定内部策略和过程的水平确定。例如,如果某个组织的用于管理邮件环境的已定义过程很少,并且没有用于服务器配置的标准操作过程,则与认真记录了有关驱动程序更新、修补程序安装和服务器配置的策略的其他组织相比,该组织可能会遇到更多事故和中断。

但是,组织成熟度并不限于策略使用。它还包括管理员管理环境的“方式”。例如,管理员可以通过依次登录每个服务器,然后在每个服务器上下载和安装修补程序,将修补程序应用于 10 个服务器。此过程十分低效。相反,一个使用自动修补程序部署系统的管理员可以轻松地在几分钟内将修补程序部署到 100 个服务器,从而使效率呈指数级提高。然而,该修补程序管理解决方案本身必须进行积极管理。此要求需要更多资源,并且必须遵循特定策略和过程以确保实现正常、准确的解决方案。

组织成熟度基于以下原则:

-
操作过程成熟度:   通常,如果创建了记录良好并且可重复的操作做法,则可减少对经常维护或被动维护的需要,因为大多数任务会自动执行。

-
经验:   操作团队成员拥有的知识和相关工作经验水平对团队管理企业邮件解决方案的能力具有正面影响。

-
硬件:   高效系统和良好存储做法可帮助保持高度的用户满意度并且可以极大减少支持电话或中断的数量。

-
可靠性:   相对于硬件,可靠性由所使用的硬件、软件、功能的组合以及系统需求决定。通常,可靠的解决方案是为满足给定工作负荷的全部需求而专门选择的一个解决方案。

<table>
<thead>
<tr class="header">
<th><img src="images/Dd335218.note(EXCHG.141).gif" title="注释" alt="注释" />注意:</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>可靠性不是聚类分析的同义词。聚类分析解决方案引入了额外复杂性,可能不适用于没有经验的组织。</td>
</tr>
</tbody>
</table>
  • 设计:   Exchange 环境的合适设计可提高上述所有原则的有效性。相反,糟糕的设计可能会导致硬件或人员经验不太有效。

组织成熟度的原则可整理为称为“基础架构优化”模型的组织配置文件,如下表所示。

基础架构优化模型

级别 特征

基本

系统比较复杂并且不兼容。大多数 IT 人员将其时间花费在应对问题上并且只是尝试使各项功能正常运行。如果几乎不使用标准和自动化工具,则 IT 支持需要很多人力且成本很高。

标准化

IT 部门更加集中且有效。但是系统仍然比较复杂、不兼容且维护成本较高。各项独立系统位于业务组中。

合理化

IT 和业务组制定战略并定义 IT 策略(这些战略和策略会通过技术进行实施)。通过制定标准和谨慎地工程设计,应用程序可同时运行并提高了兼容性。

动态

业务灵活性优先级高于成本节约。IT 系统高度自动化、灵活且可快速响应不断变化的业务条件。

有关基础架构优化的详细信息,请参阅 Microsoft 基础架构优化

各种基础架构优化模型级别之间的关键差异在于如何使用技术以及许多级别和组间的系统标准化。通常,组织成熟度级别越高,管理环境所需的人员水平便越低。但是,技术本身不会提高组织的成熟度级别。所有解决方案都必须置于管理之下才能成功支持准确性、效率、可靠性和稳定性。组织的策略应由业务需求所驱动,并且技术应支持或促进这些策略。

定义角色和分配任务

人员水平也在很大程度上取决于对企业邮件团队的需求。这些需求可能在各个组织之间有显著不同。仅需要邮件管理员部署、配置、管理和维护 Exchange Server 2010 系统的组织所需的人员要少于需要管理员管理 Exchange、备份、消息传送安全机制、移动设备、网络、存储和虚拟化技术的组织。

下面的列表包括在评估组织中的邮件管理员角色时要考虑的一些关键问题:

  • Exchange 团队是否主要负责运行 Exchange 的服务器上的基础 Windows 操作系统?

  • Exchange 团队是否负责其他技术(如 Active Directory 域服务、Microsoft SharePoint Foundation 2010 或 Microsoft SQL Server)?

  • Exchange 团队是否管理 Exchange 环境的物理硬件(如服务器、网络和存储)?或者,如果 Exchange 服务器进行了虚拟化,Exchange 管理员是否管理虚拟化解决方案?

  • Exchange 团队是否管理 Exchange 服务器的备份(基于磁带或基于磁盘)?

  • Exchange 团队是否管理消息传送安全机制基础结构?Exchange 团队是否管理非 Exchange 软件或硬件?

  • 组织是否将用于邮件的操作和设计/体系结构的角色彼此分开?

  • Exchange 团队是否管理用于邮件的网络或外围安全?

  • Exchange 团队是否直接执行最终用户支持?如果是,该团队是接收所有与邮件相关的票证还是仅接收从第 1 层提升到第 2 层的票证?

  • Exchange 团队成员是否执行标准的每天、每周、每月、每季度或每年任务?如果是,则这些任务是什么?应将哪些其他任务添加到列表?

  • Exchange 团队成员是否负责响应涉及邮件资源的安全问题?

  • 是否要求 Exchange 团队成员执行发现搜索并处理其他与合规性相关的问题?

  • Exchange 团队成员是否执行容量管理?

此列表并未包含全部问题。上面可能未列出针对您所在组织中的邮件管理员的关键任务。此外,还有其工作描述和所需任务与邮件管理员显著不同的其他职位(如操作经理)。重要的是考虑整个团队环境中的所有职位而不是侧重于单个职位。

下面的列表介绍分配给许多大中型企业邮件部署的常见角色和功能的可能职责。在许多情况下,列出的角色是现有角色(例如主管)而不是特定职位的子集。例如,操作工程师便是这种情况。

-
主管

  - 提供基于邮件技术远景的技术功能和业务需求。

  - 协调邮件操作和邮件系统工程设计的活动。

  - 向内部和外部源描述企业邮件系统的各个方面。
  • 经理,邮件操作

    • 确保邮件系统以最佳性能运行。

    • 确保邮件操作团队在系统反应迟缓和性能下降影响用户之前了解这些问题。

    • 确保所有邮件操作技术人员和所有操作分析师具有进行工作所需的工具。

    • 向用户描述邮件操作。

  • 经理,邮件系统工程

    • 按照提高邮件系统性能的目标,推动邮件团队进行不断分析和设计审阅。

    • 确保邮件团队具有进行工作所需的工具和培训。

    • 响应来自操作团队的相应呈报并将资源分配给这些呈报。

  • 助理操作分析师

    • 安装、配置和记录邮件环境中的新生产服务器。

    • 执行邮件系统问题的基本疑难解答。

  • 操作分析师

    • 安装、配置和记录邮件环境中的新生产服务器。

    • 执行邮件系统问题的所有疑难解答。

    • 确保在每天日志中正确记录问题。

  • 高级操作分析师

    • 协助指导新操作分析师;在需要时执行操作分析师的职责。

    • 处理操作分析师和技术人员未解决的呈报问题。

    • 确保每天日志保留系统疑难解答信息的有用存储库。

  • 助理操作工程师

    • 与操作分析师和技术人员合作执行基本分析和设计。

    • 向工程团队的其他成员提出想法和建议以进行进一步讨论。

  • 操作工程师

    • 与操作分析师和技术人员合作执行详细分析和设计。

    • 处理来自操作方面的初始呈报

    • 对来自操作团队的所有呈报进行疑难解答和跟进。

    • 评估已发布产品功能在企业邮件系统中的可用性。

  • 高级操作工程师

    • 评估已发布和未发布的邮件系统。

    • 提供针对要实现的功能的详细测试计划。

    • 尝试最大程度减少邮件产品下一代版本的所有影响。

    • 极端呈报并在必要时与 Microsoft 技术支持人员联系。

  • 邮件操作技术人员

    • 处理对邮件系统的日常监视和报告。

    • 确保在每天日志中正确记录事件。

    • 确保记录并向合适人员报告在其班次期间发生的所有事件。

    • 也处理来自标准“PC 支持人员”部门的呈报请求。

若要提高任何工作人员水平计算的准确性,那么清楚地定义各个邮件团队成员的角色,然后客观地评估这些角色的需求会十分有帮助。

评估技术影响

在组织定义了各种角色和职责之后,下一步是评估技术,然后将所需任务映射到解决方案的技术组件。通常,软件中的改进可以使管理员完成特定任务的速度大大超过以前版本,可以使管理员自动执行常见工作流,或是可以使管理员向其他人员或其他团队委托特定任务。

请看此例。Woodgrove Bank 管理员经常收到还原邮箱的请求来取回误删除的项目。这些请求需要涉及邮件工程师(拥有访问 Exchange Server 2003 系统的所需权限)以及备份工程师(处理实际还原操作)。在 Woodgrove Bank 部署 Exchange Server 2010 之后仍需要还原已删除内容,但是如果他们选择对所有用户启用单个项目恢复,则会由邮件管理员(通过基于角色的访问控制向其授予了合适权限)或人力资源部门中的合规性管理员执行实际还原工作。因为还原操作不再涉及备份工程师,则整体过程更加简单,也许可能在更少时间内完成。

Exchange Server 2010 包括的几个功能可使管理员可以在不同级别将任务重新分配给不同团队,或完全不必执行该任务。下表介绍 Exchange Server 2010 中的几个重要功能以及这些功能可以支持的任务的更改。此表中介绍的功能并不是全部功能。当然,您可以自己决定选择使用这些功能。

功能 可能的任务更改

数据库可用性组

通过具有三个或更多数据库副本,Exchange 管理员可以采用本机数据保护策略,从而减少对备份团队的需求。

单个项目恢复

无需为仅仅恢复单个已删除项目而还原备份。

基于角色的访问控制 (RBAC)

使管理员可以在粒度级别委托任务,而不会使组织面临重大安全风险。

PowerShell(在 Exchange Server 2010 中进行了扩展,也存在于 Exchange Server 2007 中)

使管理员可以通过 PowerShell 脚本自动执行常见任务,包括许多用户、组、邮箱和数据库维护任务。

多邮箱搜索

与 RBAC 相结合,使管理员可以将发现委托给其他人员(很可能是人力资源的人员)。

使受信任的人员可以在不使用第三方工具的情况下对环境中的邮箱执行发现。

Exchange 控制面板

使用户可以管理其邮件体验的特定方面(包括通讯组和邮件跟踪),从而减少对支持人员的需求。

个人存档

使管理员可以吸收以前由个人文件夹(.pst 文件)提供的功能,从而消除支持电话的一个常见来源。

保留策略

使管理员可以控制电子邮件生命周期(通过设置最大电子邮件期限),从而可以减少邮件环境中的合规性问题数。

虽然上面的列表特定于 Exchange Server 2010,但是无论使用哪个版本,都应遵循使任务与技术匹配的原则。通过充分使用技术,管理员可以尽量以最高效的方式执行其职责,从而可将其时间留出来用于其他任务,并且还可减少对其他团队的需求。

计算人员水平

如本主题开头处所述,无法通过简单的公式来提供用于管理给定 Exchange 组织的具体建议人数。因素的范围太复杂并且差别太大。根据管理员的所需职责、管理员管理 Exchange 的经验以及环境中的自动化程度,大小和范围类似的两个组织需要的人员水平可能有很大不同。

在计算人员水平时要考虑的最重要因素是在当前基础结构中执行所有所需任务所需的时间量。如果将对环境进行会提高操作成熟度级别的重大更改,则可能还适合计算在理想化基础结构中执行所有所需任务所需的时间量。随后可将小时总数转换为建议人员水平,同时考虑其他因素(包括工作日长度、工作周长度以及假期和病假的平均天数)。人员水平应始终舍入为下一个整数值,以确保人员水平超过所需时间(而不是不足)。

下面的示例 Exchange 操作任务检查表指示在计算人员水平之前任务应达到的详细级别。

示例 - Exchange 操作任务检查表(按职位)

活动

估计时间(小时)

频率

每年工作量

规划

     

     

     

     参与下一个版本评估讨论

8

每年

8

     来自操作的反馈

2

每季度

8

     SLA 定义

4

每年

4

     操作文档

1

每年

1

Exchange 管理

     

     

备份和还原

1

每天

260

     执行定期备份

1

每天

260

     备份 Active Directory 系统状态

1

每天

260

     验证备份媒体

1

每月

12

     非现场备份媒体

1

每天

260

     定期更改备份媒体

1

每天

260

     在所有客户端服务器上设置邮箱和邮件保留时间

1

每季度

4

     对邮箱和公用文件夹存储进行碎片整理

1

每月

12

     验证邮箱和公用文件夹存储的完整性

1

每周

52

风险管理

     

     

     

标识

1

每年

1

     分析和优先顺序

.5

每年

.5

     缓解和应变规划

.5

每年

.5

分配的其他工作

     新项目

100

每年

100

     支持人员呈报支持

1

每天

260

     检查开放的服务票证

2

每天

520

     现场访问(出差时间)

2

每月

24

总计

     

     

9791.5

     每个人力年的可用小时数

     

     

1635

     Exchange 任务消耗的工作百分比

     

     

599%

在此示例中,组织确定任务总数需要 9,792 个小时。如果某个全职员工工作 1,635 个小时,则此分析建议组织需要单个人员的 600%(更合适的是 6 FTE)来管理其 Exchange 组织。请注意,此示例任务列表仅适用于操作团队。客户还必须为工程和支持人员团队执行相同分析。

职位数还取决于组织的复杂性和大小。小型组织可能合并角色或完全省略它们,而大型组织可能在特定角色中拥有多个人员。例如,一个大型金融服务公司的邮件团队会每周七天、每天 24 小时为 45,000 个用户管理资源。其邮件服务人员通常在下表显示的职位中包含 30-32 个人员(其角色和职责在本主题前面的“定义角色和分配任务”中定义)。

职务 人员数

主管

1

     经理,邮件操作

1

          高级操作分析师

2

          操作分析师

3

          助理操作分析师

0-1

          技术人员

17

     经理,邮件系统工程

1

          高级操作工程师

2

          操作工程师

2

          助理操作工程师

1

总结

若要确定管理特定 Exchange 环境所需的工程师、管理员和其他支持人员数,必须仔细收集业务要求、考虑各种因素,并且最重要的是进行规划。仅当确定用户群体的需求、定义实现这些需求的角色、评估技术、将技术与角色匹配,最后计算执行所需任务所需的时间之后,才能确定所需人员水平。这是一个参与过程,但是最终结果应使邮件团队的功能尽可能满足业务(和用户)的需求,而不需要用多余的人员来妨碍组织或团队。

 © 2010 Microsoft Corporation。保留所有权利。