Lync Server 2013 中的更改管理

 

上次修改的主题： 2014-08-18

对 IT 环境的更改是不可避免的。 更改包括新技术、系统、应用程序、硬件、工具、流程以及角色和职责的更改。 通过有效的更改管理系统，可以快速地引入对 IT 环境的更改，并尽量减少服务中断。 更改管理系统将参与更改系统的团队汇集在一起。 例如，决定利用 Office Web 应用。 这是一个集成的 Lync 服务应用程序，使用户能够在浏览器中读取和编辑文档。 在投入生产后，此服务的实现需要多个团队的参与：

• 测试团队此团队在测试服务器上加载测试 Office Web 应用，在此过程中提供有关生产服务器的预期使用模式和预期性能的信息。

• Lync 管理员 此团队确定部署策略，并在可能的情况下编写安装脚本。 该团队负责确保在生产环境中部署更改，并负责事后的管理。 在将更改投入生产之前，团队必须了解更改的效果并将其纳入过程

• 网络团队 此团队负责更改允许从 Internet 访问内部 Lync 池服务器的防火墙规则。 该团队还负责与 Lync 管理员合作，确保可用带宽可以支持额外的负载。

• 安全团队 此团队评估安全性并最大程度地降低风险。 安全团队必须查看已知的漏洞，并帮助确保安全风险最小化。

• 用户验收团队 此团队由愿意测试系统并提供改进反馈的用户组成。

更改管理过程定义每个团队的职责，并计划要执行的工作，并结合检查和测试，其中需要这些检查和测试。 更改控件将因更改的复杂性和预期效果而异。 它们可能因对次要更改的自动批准、更改评审会议和完整的项目级别评审而异。 为了更好地解释这一点，本部分将讨论更改组。

• 重大更改 重大更改对系统具有全局影响，可能需要各种团队的输入。 此示例是升级到 Lync Server 2013。 重大更改会影响许多团队，或许影响不同的系统。 更改管理过程可能包括一个或多个更改评审会议，以通知将参与更改或受更改影响的团队。

• 重大更改 重大更改需要大量资源来规划、生成和实现。 应引入适当的更改控制，以帮助确保了解更改的效果，测试部署过程，并准备好回滚和应变计划。 重大更改的一个示例是部署新的累积更新。

• 次要更改次要更改不会显著影响 IT 环境，例如，通过 Microsoft Lync Server 2013 控制面板更改某些 Lync 策略。

• 标准更改 标准更改会定期执行，并且非常了解和记录。 更改管理过程应查看对过程的所有更改。 创建内容数据库或添加用户等常规更改不应需要此功能。

下面的更改管理示例检查不同的团队如何交互以及部署新服务包时执行的操作。 这些操作由更改管理过程组织和管理。

• 提出更改请求 安全团队评估了最新的服务包，并确认它解决了生产系统中可能存在的漏洞。 团队发出更改请求，要求将新的累积更新应用到运行 Lync Server 的所有服务器。

• Service Pack 发行说明评审 Lync 管理员团队会查看服务包发行说明，以确定对系统的影响。

• 执行一系列实验室测试 Lync 管理员团队必须在测试环境中的服务器上执行测试更新，以确定是否可以在不影响任何已安装的应用程序和服务器系统的情况下成功应用该服务包。 如果有第三方或内部创建的应用程序在生产环境中与 Lync Server 接口，则还应测试这些应用程序。 这些测试还可用于估计执行升级所需的时间。

• 系统会通知用户中断 Lync 管理员团队、通信团队或用户支持人员向所有受影响的用户告知计划内维护周期以及服务不可用的时间。

• 在升级之前执行 Lync 的完整备份 如果服务包安装失败，Lync 管理员团队必须验证是否有有效的备份可用于还原到原始系统状态。 如果出现问题，建议将备份还原到备用服务器，使此系统随时可用。

• 已部署累积更新 Lync 管理员团队在计划内维护周期内执行安装。

管理更改的时间

建议实施计划更改的过程，以避免工作重叠部分出现中断。 例如，两个团队可能都在计划对系统进行轻微更改。 一个团队可能会在池上应用累积更新，而另一个团队正在将旧用户迁移到该池中。 这两个团队都不受另一个团队正在规划的更改的影响，并且每个团队可能不一定知道另一个团队正在规划的更改。 如果同时发生这两个更改，则在实现更改时可能会出现问题。 此外，如果应用更改后出现问题，例如，如果用户迁移失败，则可能很难决定应回滚哪些更改。 应在 IT 与管理之间设置定期维护期，以测试更改并接受更改。