绝大多数企业依赖语音和数据通讯，以及本地局域网络和广域网络。随着在网络中投入如此关键和策略性的应用后，你是否对其进行了保护，以避免由于运营商的问题或设备故障引起计划外的业务中断?更进一步，你的网络基础架构是否安全，可以防止非授权的访问、病毒以及黑客的攻击?关键网络基础架构以及相应设备必需通过灾难恢复规划进行保护。
在本篇以及附带的网络灾难恢复规划模板中，我们将检查在准备和部署语音和数据通讯的网络灾难恢复规划中所需解决的各项问题。
网络灾难恢复规划并非总是优先的
当涉及到网络基础架构时，灾难恢复规划并非总是一个很大的优先事物。相反，网络安全通常有着更高的优先级，因为一个不安全的网络环境对绝大多数企业而言都是很大的风险。防止黑客和其他犯罪分子未受认证的访问，以及引入防病毒和拒绝服务式攻击(DOS)通常会有较高的优先级，并且也容易得到管理层的关注。
在语言方面，随着IP语音技术(VoIP)的日益流行，鲁棒的网络安全性也变的更为重要。由于VoIP相当于是使用现有网络资源的另一项应用，和其它基于网络的系统一样有一些缺陷需要弥补。
以往的公共广播服务系统通常使用分离的网络设备，对数据网络并不进行复用。不过，随着通过数字化的T-1线路共享语音和数据传输可以实现更高的成本效益，整个语音通讯系统的风险也同时上升了。在今天，随着语音、数据、互联网访问以及其它网络服务通常共享同一网络资源，保护支持这些服务的底层网络访问线路以及接口设备(例如路由器和交换机)变得尤为重要。
开始网络灾难恢复规划
在你开始创建你的网络灾难恢复规划之前，先了解下这些重要的说明：
1、慎重进行灾难恢复规划流程。假设你希望保护你的网络基础架构以及相关设备，防止计划外的事件中断网络运行，你需要一份计划。这并不需要上百页的纸张报告。信息充足的一页规划远比厚厚一叠没有人用得上的文档要更有用处。
2、使用业务连续性标准作为出发点。在全球至少有二十多份可用的业务连续性和容灾标准可供参考。
3、确保简单可行。视你的语音、数据、因特网、无线网络的配置情况，你的规划应当反映出同样级别的架构和复杂度。
4、对于实际灾难响应动作进行限定。假设你正在创建一份对特定网络相关事故的规划，在其中只需包含响应和随后的恢复操作。
5、确保规划的实时性，并经常进行测试。一旦规划完成，每年至少对其测试两次(如果你的网络配置会频繁调整，你需要更多频繁的测试)来确保你文档中一步步的操作指示是有意义的。
6、具备灵活性。一份简单的灾难恢复模板并不适用于所有的网络，尤其是当你的企业由许多分支机构，通过网络和不同的数据中心接受服务时;你或许可以考虑更为复杂的模板、专业的网络容灾软件或在网络容灾方面的顾问咨询。
网络灾难恢复规划的组成
下一步，我们将检查网络灾难恢复规划模板的结构和内容，并指出一些需要解决的核心问题和进行的工作。
原始数据。一旦你确定了网络事故中主站点和备份网络里需要联系的员工，将其联系方式放在规划的首页，这样在事故中你不必花费宝贵的时间来进行翻页查找。
版本管理。留出一页记录你对管理流程的变更。
目的和适用范围。提供详细的属性，以及假定条件、团队描述、术语列表以及其它背景信息。
告警指示如何激活该规划。明确在何种情况下该计划会被激活，包括中断时间的范围、灾难申报人、紧急联系人和所需使用的响应流程。
政策信息。如果IT部门有业务连续性和容灾政策，请确保能够包含着部分政策信息;这同时也可以用来参考标准性的文档。
规划细化。可能的话，提供详细的一步步流程，这样比起那些宽泛的称述，比如“重新配置网络通道来替换位置”要容易许多，过于宽泛的称述通常要详细的说明才能正确操作。此外，描述该规划的回顾和更新频率，并明确责任人。
检查列表和流程图。假设发生了网络中断事故，明确解决的步骤;这可以以检查列表的形式制作(对于按计划执行并完成任务非常有用)以及流程图，这样对于响应和恢复更加可视化。
收集信息。在正式宣布一次网络事故之前应当要收集足够的信息;这包括网络性能数据和第一手的IT员工和雇员的报告，以及第一响应人(如果需要的话);在进行宣布流程之前尽快和关键IT网络应急团队成员召集会议进行评估。
宣布事故。一旦掌握的网络中断的事实，在宣布网络事故的同时，该规划应当列出所需进行的工作。
从灾难中恢复。一旦形势得以控制，后续部分的计划应当指导如何进行恢复，恢复网络操作、网络连接设备以及其它相关事宜。
附录。在模板的最后应当配有详细的附录;这包括所有IT和非IT应急团队的名单和联系方式，主站点和备用网络供应商，备用网络配置数据，以及其它相关信息。更重要的是要保持这些信息的实时性。
开发一个网络灾难恢复规划的流程可能会相对容易。当然，如果你的网络特别负责，具有多类技术和复杂的拓扑图，那你的规划也会相应变得复杂。关键是要定义出一步步的响应和恢复流程，并通过测试确保这些流程的准确性，并保持其经常更新。
原文链接：http://netsecurity.51cto.com/art/201202/315315.htm
