让托管基础设施配合业务连续性目标

业务连续性目标说明企业在正常运作受到干扰时，需要维持、恢复或保护哪些服务，以及可以承受多久的中断。托管基础设施不是单纯的技术成本项目，也是业务连续性目标的一部分。

具备韧性的规划，需要把业务优先次序与服务器、网络、存储、安全、支持及恢复程序连接起来。合适的设计不是设备最多，而是在实际情况下，能够符合已订立的恢复时间、恢复点及可用性要求。

从业务连续性目标开始

业务连续性规划应由企业不能承受长时间中断的服务开始，而不是由预设的服务器规格开始。按业务影响、客户依赖程度、数据敏感度及长时间停机的后果，为应用程序排序。

• 列出在服务中断时仍必须维持的服务。
• 为每项重要工作负载订立恢复时间目标（RTO）及恢复点目标（RPO）。

记录 DNS、身份验证、数据库、存储、网络路由、支付系统及第三方整合等依赖项目。

提示：如果所有工作负载都被标记为最重要，代表优先次序仍未清楚定义。

把业务目标转化为基础设施要求

工作负载排序后，便要把每项目标转化为运营要求。RTO较短的应用程序，可能需要热备份、自动故障转移或第二个地点；恢复时间较宽裕的工作负载，则可以从已验证的备份恢复，但前提是恢复流程曾经测试。

• 按服务层级，配对所需的计算、内存、存储、网络及安全容量。
• 记录恢复服务所需的人员、权限、供应商支持及操作手册。

这样可以避免业务连续性规划变成一套一般性的控制措施，也能揭示企业期望与现有环境实际能力之间的差距。备份可能符合RPO，但如果没有经过测试的恢复流程，RTO仍然不切实际。

以独立服务器建立可预测的基础

当企业需要独享资源、管理控制权及稳定的关键工作负载基线时，独立服务器可以支持业务连续性规划。在选定设计前，可参考 Dataplugs 的 独立服务器方案，并一并评估处理器、内存、存储、网络容量、位置及远程管理要求。

• 独享的处理器、内存、存储及网络资源，令性能更容易建立基线及监控。
• 对实体服务器有更多控制，可以简化操作系统配置、安全加固、备份代理程序及恢复测试。

独立服务器本身并不是业务连续性计划，仍需要具备韧性的电力及网络连接、经过验证的备份、受控权限、清晰的责任分工，以及记录完整的服务恢复路径。

按故障范围设计冗余

冗余设计应针对企业希望承受的故障类型。第二部位于同一机柜的服务器，或许可应付硬件故障，但未必能抵御机房中断、网络故障、区域性事件或共同配置错误。

可参考 主机托管与业务连续性规划，评估独立机房、地理位置、电力设计、网络连接及远程支持如何加强恢复架构。

• 把主要及恢复资源分布在有实际意义的故障范围内。
• 即使主要环境无法使用，也要保留恢复所需的权限、管理路径及文件。

冗余程度取决于每项工作负载的价值及恢复要求。在所有地方建立相同架构，可能增加成本，却未必改善真正重要的风险。

提示：说明每项冗余组件要应付的故障，然后测试相应的恢复路径。

把网络韧性纳入设计

即使服务器保持正常，业务连续性仍可能失败。电信商故障、路由变更、防火墙错误、DNS问题或链路饱和，都可能令原本可用的应用程序无法连接。因此，网络设计与选择服务器一样，需要优先处理。

• 如工作负载有需要，使用多元化连接、独立路径或经过测试的故障转移路由。
• 分开生产、管理、备份及复制流量，避免单一流量耗尽所有可用容量。

从相关地点测量故障转移时间、DNS表现、连接恢复、数据复制延迟及用户可达性。架构图上的冗余，仍可能共用电信商、机房或配置依赖。

保护备份及恢复数据

恢复不只是拥有一份数据副本。备份必须完整、可访问、避免未经授权的修改，并且能与所依赖的应用程序及基础设施一同使用。

• 保留多于一份恢复副本，并把至少一份副本与主要环境隔离。
• 保护备份权限，并测试文件、数据库、配置及权限能否一并还原。

记录保留期、复制延迟、加密、数据位置，以及有权批准恢复的人员。

把恢复运营与日常运营分开

当恢复工作与生产流程互相竞争时，业务连续性工作会更困难。应把备份验证、映像建立、补丁测试及恢复演习纳入受控及有安排的流程，并预留足够资源，避免影响现行服务。

• 使用贴近实际测试、但足够隔离以降低运营风险的恢复环境。
• 在主要环境以外，保存最新的操作手册、联系方式、访问方式及基础设施图。

恢复团队应清楚知道如何按正确次序重建或还原依赖项目。记录所有假设、前置条件，以及何时需要由业务负责人批准故障转移或返回正常运作。

为托管事故做好准备

硬件故障只是其中一种业务连续性情境。权限被入侵、恶意软件、DDoS攻击、错误变更或管理界面外泄，都可能中断服务，并令人无法确定还原后的系统是否可信。

• 定义谁可以宣布事故、隔离系统、批准紧急变更，以及向客户或利益相关者发出通知。
• 在可行情况下，先保存日志、快照、配置历史及证据，才进行会破坏数据的修复。

Dataplugs 的 托管基础设施事故响应规划指南，可供企业参考如何制定检测、责任分工、遏制、恢复、沟通及事故后检讨流程。相关原则仍应按企业实际架构及责任调整。

测试目标，而不只是测试设备

业务连续性设计只有能证明预期结果，才算可信。测试完整的服务路径，包括应用程序启动、依赖项目、网络访问、身份验证、数据完整性及用户通知。

• 进行桌面演练，确认责任、升级路径、决策及沟通安排。
• 进行技术恢复测试，量度实际RTO、RPO、故障转移时间及服务表现。

每次演练后，记录失败事项、超出预期的时间，以及需要更改的假设。测试也应包括返回主要环境；无法安全逆转的紧急故障转移，可能造成第二次中断。

提示：量度用户再次可以使用服务的时间，不只是服务器重新可连接的时间。

平衡韧性、成本及运营工作

最强的业务连续性设计不一定是最昂贵的方案。应把冗余硬件、额外地点、网络多元化、备份容量、监控、支持及定期测试的成本，与停机对业务造成的影响进行比较。

按工作负载的重要程度分层安排控制措施。面向客户的交易系统，可能值得采用较短RTO及地理分隔的恢复环境；内部存档则可能只需要可靠备份及记录清楚的还原流程。当应用程序、供应商、数据量及服务期望改变时，也要重新检视设计。

总结

让托管基础设施配合业务连续性目标，意味着把业务影响连接到可量度的技术结果。服务器、网络、存储、安全、支持及恢复程序，都应根据哪些服务必须维持、需要多快恢复，以及企业可以承受重建多少数据来选择。

独立服务器可以提供受控而可预测的基础，而冗余、主机托管、经过测试的备份、事故响应及实际演练，才可把这个基础转化为可运作的业务连续性计划。Dataplugs 可以协助企业按工作负载、位置、连接及恢复要求，评估独立服务器环境。

如需了解更多信息，请浏览 Dataplugs 网站或联系 sales@dataplugs.com。