Finished 'src/d41/business_continuty.md'.

Author: gnu4cn

src/SUMMARY.md

@@ -328,6 +328,7 @@
     - [恰当的风险缓解策略](d41/mitigation_stratigies.md)
     - [适当的事件响应流程](d41/incident_response_procedures.md)
     - [安全相关意识与培训的重要性](d41/importance.md)
+    - [业务连续性的各方面](d41/business_continuty.md)
 
 
 

src/d41/business_continuty.md

@@ -0,0 +1,59 @@
+# 业务连续性的各个方面
+
+精心规划基础设施的目标之一，便是最大化网络服务的可用性。有许多确保业务连续性与高可用的概念，都可应用到基础设施规划，即使面临一些计划外事件时也是如此。这一小节将涵盖以下主题：
+
+- 业务影响分析
+- 消除单点故障
+- 业务连续性规划及测试
+- 运营的连续性
+- 灾难恢复
+- IT 应急预案
+- 继任计划
+
+
+## 业务影响分析
+
+资源应投入于最具成本效益的损失缓解措施<sup>1</sup>。这是通过业务影响分析实现的。某次业务中断的损失，不是根据提供这项服务的成本计算，而应基于服务通常所创造效益的损失计算。例如，某台运行低成本软件的相对廉价服务器的失效成本，便不应以更换成本衡量。而应以该服务器不可用的价值损失衡量。在分配资源以最小化任何给定故障的业务影响时，咱们应该问：“当我们失去某一特定服务或某一特定硬件时，会发生什么？”
+
+> <sup>1</sup>：原文，resources should be put toward mitigating losses with the greatest bang for the buck。
+
+保持业务继续运行的计划，应考虑到可能导致（业务）中断的那些自然灾害或技术灾难，以及这些事件会怎样影响业务。管理员应在注重业务本身下，创建出计划了一些恢复点目标的 IT 应急预案。所谓恢复点目标（RPO），是指因业务中断，而可能丢失的数据的最长时段。绝对有必要保持某一数据库带有完全同步的镜像事务，从而绝对没有数据面临风险，或者一些数据仅需受到按每日甚至按每周的保护。恢复点应根据业务需求而设置。
+
+任何特定业务中断导致服务不可用的时长，都称为恢复时间。针对某次中断后恢复服务所制订的目标，称为恢复时间目标（RTO）。RTO 应根据业务需求设置，例如，当服务器掉电时，是否实施了立即恢复该项服务的计划？或是否允许在备件运输期间让该服务器不可用？
+
+在进行了业务影响分析后，某一满足恢复点目标（RPO）与恢复时间目标（RTO）的计划就应加以创建出来。这些计划会涵盖从一种简单的异地备份，到一个完全冗余的在线异地数据中心。
+
+## 消除单点故障
+
+提升正常运行事件的最基础方法之一，便是通过消除单点故障。当某单一硬件（比如单块硬盘、单台服务器、单个机架或单一站点）出现问题时，某一关键服务是否将遇到停机？服务可用性越关键，那么将冗余构建入基础设施设计中，就越重要。
+
+这一做法，可能意味着多个电源、不间断电源（UPS）、RAID 阵列、冗余的业务供应商（比如电力或 Internet），或某一业务可得以提供的多个地理位置等。
+
+
+## 业务连续性的规划与测试
+
+在建立了恢复点目标（RPO）与恢复时间目标（RTO）后，审查并测试咱们的恢复计划，确保其会切实发挥作用，就非常重要。若没有业务连续性的规划与测试，那么咱们就会面临诸如在某一依赖于从某个在灾难情形下完全失效备份恢复的 RTO 计划的风险，从而同时损坏原始数据，以及读取备份介质的必要驱动器。
+
+“兵棋推演” 各种情形，将确保咱们的计划在灾难情形下是切实可行的。测试恢复将不仅确保咱们的数据保护按所要求的那样运作，同时其将使系统团队准备好在真实灾难恢复期间，更好的响应。定期测试确保了业务连续性规划，将真正实现服务的持续性条款，即便面对某种可能造成灾难性业务影响的灾难亦是如此。
+
+## 运营的连续性
+
+当灾难发生时，确保咱们的业务仍能正常运作至关重要。这被称为运营的连续性。一些通常由技术基础设施方式提供的服务，也可通过其他方式提供。提供关键服务的非技术方式条款，可提供到强有力的 “最坏情况” 后备空间。例如，一种计算机化的目录，通常会提供给汽车经销商一种了解所需零件及服务的快速方式。当该经销商遇到计算机中断，而手头有着这些必需服务手册的硬拷贝时，那么工作仍可在非理想条件下继续，而非彻底停摆。
+
+尽管业务中断的风险无法完全消除，但通过业务连续性的规划和测试，其可被显著降低。即在某种技术性中断下，业务仍能够准备一些持续运营的非技术手段。
+
+衡量某一运营连续性计划，或某一灾难恢复计划有效性的最佳指标，便是恢复的平均时间。在即使某一站点完全、灾难性损失下，要不影响服务条款，那么恢复平均时间就要趋近于零。在一次灾难或技术故障后，咱们能越早恢复完整功能越好。
+
+
+## 灾难恢复
+
+所谓灾难恢复过程，就是为满足恢复点目标（RPO）于恢复时间目标（RTO），已建立的灾难恢复计划的运用。在执行灾难恢复前，计划应已投入并得以测试。咱们首次的从作为灾难恢复计划一部分而构造的备份恢复数据，不应是在某一实际灾难中。一个良好测试的计划，不应出现意外。这一点将在本章稍后讨论。
+
+
+## IT 应急预案
+
+灾难恢复或业务连续性计划中的一部分，应是 IT 的应急预案，这基本上是故障一次发生一点（若真有的话）的预案做法。这可能包括一些最关键业务的冗余系统、一些服务的强有力非技术性后备余地（例如准备在线零件数据库的服务手册），或可临时上线的替代站点等。IT 的应急预案与业务连续性计划密切相关；但其仅关注服务的交付。
+
+## 继任计划
+
+在任何组织中，都有一些不可或缺的岗位。完善的继任计划，确保了不存在只有一人能担任的角色。某特定人员无法再履行指派给他/她的角色的原因可能有多种，比如突然离职或突然丧失能力等。要最小化岗位交接时造成的干扰，就要鼓励关键人员培训其他人履行他们的关键职责。另一可行策略，便是在实际可行的情况下，推行定期岗位轮换。