灾难恢复和您

这很有趣。非常有趣。我有世界上最酷的姐妹。我已经练柔道20多年了。这是我的爱。所以我做了很多柔道的参考，让我来看看…关于我的有趣事实下面那张穿奇装异服的小妞的照片，是我妹妹，那是我在主持她的婚礼。

我是被任命的牧师，如果有人想要一个世俗的婚礼，我是你的女孩。我说的够多了。

我们来谈谈什么是灾难恢复计划?你经常听到这种说法。至少我做到了，但我并不是百分百确定什么是真正需要覆盖的，这应该是什么?让我们开始吧。这一切都是关于预测可能发生的最坏的事情，并提前减轻它们。

这个话题真的触动了我的灵魂。事实上，当我在上一家公司被分配创建一个DR计划时，几个人基本上都说，Valarie，你激怒了谁，让谁陷入了这个困境?我当时想，伙计，我有复杂的创伤后应激障碍，思考可能出错的事情是我的强项。因为我一生都在思考可能会发生什么，以及我该如何先发制人地解决问题，所以这很棒。我喜欢这个，这就是我的大脑工作方式。所以当我意识到这一点时，我感到很兴奋，所有的问题都是思考哪里可能出错，我们必须要做什么才能把我们的产品送到最终用户那里，比如什么为了让这个过程，你知道的，顺利，不能出错还有100%的正常运行时间，这就是我们的目标。

保持准备。酷。所以说到你的DR计划，你知道，我们接下来要讨论的是其中的内容，但请记住，一个没人看到的计划也可能不存在。所以它需要被广泛使用，这取决于你的公司规模，你的团队规模。

你只是为一个庞大组织中的一个小团队写这个计划吗?还是说你是一家创业公司，这是为所有人准备的?这将决定你如何将它提供给所有人。一旦它对每个人开放，你就会想要经常进行训练，我们会更多地讨论这个，比如它是什么样子的，不同的场景，我们会讲到，但是记住，未经测试的计划可能不存在。再说一遍，我还会说很多次，这个问题的关键在于思考如何在事情坏掉之前把它修好。我们从哪里开始呢?

我们从哪里开始呢?因为我是说，我有点不知所措。整个过程让我有点不知所措。我们将讨论你的产品，IT问题，服务器问题，这些事情，因为我猜对于大多数人来说，如果你在制定DR计划，主要是关于将你的产品交付给最终用户。

然而，当我写我的计划时，我不是在一家初创公司，而是在一家非常大的公司的子公司我们得像创业公司一样经营。还有几个……

我不知道只是我写进计划的软件之外的事情，这可能与你们有关，所以我们将简要地讨论一些其他的事情，如果你没有办公室经理负责DR计划，你知道，更多与办公室有关的事情，你可以被评估，在你的团队中脱颖而出，在你的老板面前脱颖而出。你也可以想想这些事情。

首先是人。在现实生活中认识我的人，都以人为本。谁该对此负责呢?

这是一个非常重要的部分，因为即使你有一个经过彻底测试和排练的惊人计划，每个人都知道它，一切都很好。你必须指定谁来做这些事，他们做什么所以我们会深入讨论这个问题。你需要一个灾备小组。所以你可以根据你的公司，你的角色，你的工作，你在写什么来选择?

要按角色、按名称委派职责吗?如果你在一家小公司，人员流动率非常低，团队关系非常紧密，一段时间内没有人去任何地方，你可能会说，嘿，罗伯，你负责这个，莎拉你负责这个，加布里埃尔你负责这个。很好，这可能对你的团队有用。或者你可能会说，工程经理对此负责。

首席后端工程师对此负责。这取决于你的团队、你的公司以及什么适合你。但你要具体一点。

就像你知道的，如果你在公共场合，有人心脏病发作了，你永远不会说"有人打911吗"，你会尴尬地和一个人进行眼神交流，然后说"你，打911吧"或者没有人会去做。

顺便说一句，我有心理学学位。是的，DR计划也是如此，你总是想要非常具体地说明谁做了什么，并指定一个备份，因为人们生病了，人们在计划重做之前离开了。总有需要后援的原因。

现在，你需要考虑的是确保计划中的每个人都能获得他们履行职责所需的一切。它看起来像什么?也许您的备份通常不需要云提供商中的特定权限集。如果它们是DR计划的备份，那么它们需要拥有履行职责所需的任何权限。如果我们谈论的是办公室后勤类型的事情，在我以前的公司，有几个房间可能只有三个人有钥匙。好吧，如果你指定了一个后备人员，他们可能需要进入那个房间，他们可能应该得到一张钥匙卡，或者至少在办公室的某个地方应该有一张紧急钥匙卡。想想这些事情，确保你让谁去做这些事情，他们都有做这些事情所需要的工具和途径。

领导，谁来做这件事?所以对于每一种不同的情况，或者，你知道，潜在的灾难，你想要非常清楚谁宣布有灾难，谁负责说，好吧，我们现在开始实施这个，这看起来可能不同，同样，基于团队规模，公司规模，你知道，你的DR计划有多广泛，但要非常具体。

你想成为…这可以是角色，可以是你想指定的任何形式，但你需要确保人们知道谁应该负责说，好吧，这是一场灾难，我负责，我负责，让我们这样做。

谁拥有每一步?这又回到了……在一群人中，如果你说，嘿，一群人执行一项任务，很可能没有人会去做。但是如果你说你做这个，你做这个，你做这个，你更有可能得到响应，所以谁做什么，或者至少谁领导什么过程，并确保有人做。这是一个有趣的问题，当我开始写我的文章时，我并没有想到过，但是谁会在什么时候和媒体谈话?所以，根据你公司的规模，你的团队和你写的东西，你可能想要考虑在什么时候停机，什么时候，你知道，用户无法访问你的产品有人需要发表声明吗?这将如何发生呢?那会是什么样子呢?

你是否预先写好了公告，以便当时可以修改，谁负责?

只是需要考虑一下。所以，不管你写了什么计划，不管里面有什么，如果人们没有沟通，那就是一个问题。我们会稍微讲一下这个。我不知道你们是怎么想的，但在过去的几年里，在不同的时候，我都在我就像，我松弛了吗?

我用谷歌聊天吗?我是不是用了别的软件?我们是发短信还是发邮件?我们在做什么?我猜在你们公司，你们有很多不同的沟通方式。在DR计划中，你可能需要考虑的一件事就是我所说的标准使用顺序。

所以基本上，当出现问题时，我们首先通过我们的寻呼系统进行沟通，然后是Slack，然后是电子邮件，然后是手机，就像指定每个人应该如何沟通一样。假设Slack垮了，你已经知道了二级和三级的沟通方式，所以人们大概知道要开放什么，要注意什么，去哪里寻找他们的队友。

你不仅要考虑你的队友和公司的员工，当你撰写计划时，你也要考虑服务提供商和供应商。假设你正在写的东西，你知道，与你实际的办公楼有关，你的水线破裂或其他东西，对吧?

谁拥有你的大楼?谁是你的维修工?谁该对此负责呢?你知道，谁是负责打电话给水管工的大楼经理?你是谁，对吧?这些都是你要写进计划的东西。因此，如果发生了什么事情，不一定是你的问题，但可能是谷歌云的问题，你会联系谷歌云的谁?比如，你应该联系谁?

因为如果真的有紧急情况，你肯定不想通过标准的客户服务渠道。所以好好想想。你所拥有的任何依赖关系，显然，任何为你提供服务的人，他们都是依赖关系，这是一个因素。最重要的是，在这一点上，定期更新内容。再说一次，我在不同的地方读到过，你知道，你每个季度，每个月都更新你的计划，不管是什么，都没有正确答案，我只想说，没有正确答案。

看看你的团队，看看你的公司，看看你的需求，看看你有多频繁地出现问题，然后出现有一个时间表并坚持下去，把它放在日历上自动ping，不管是谁负责更新它。

我们将以这个频率更新，这里是要更新的东西的清单。清单的忠实粉丝。记住这一点。好吧，我们来讨论一下。发生了什么?我们试图减轻什么?再说一次，这不是一个详尽的清单，但这些只是一些更经常出现的事情。我要提一下，当我最初写这篇文章的时候，我向社区里的各种人发送了一份调查，询问他们关于出错的可怕故事，所以我们将要谈论的所有事情都出错了，或者有人回应了。所以我们将从使用的硬件和产品开始，这是第三方的。hth华体会最新官方网站所以你要清点所有东西，对吧?

你会想知道，而不仅仅是…假设你是一个小团队，你不想说，我们有10台电脑，你想说我们有4台hp，这是他们的模型，等等等等……你知道，我们有六台MacBook pro，这是它们的序列号，如果我们的硬件出了问题，我们可以打电话给他们，对吧?也许你所在的公司有办公室经理，如果你的电脑完全坏了，你就得找他，或者你所在的公司很大，有一整个团队的人你必须以特定的方式联系他们。

知道，你知道，如果你有prem服务器，谁制造的，序列号是什么，如果有硬件问题你找谁?这些都很重要。然后你想要继续思考，如果有坚固的东西坏了，我们要替换它吗?也许你在这样的公司工作，如果你的电脑坏了，他们就会把它报废，重新开始，然后有人会给你寄来一台崭新的。酷。顺便说一句，恭喜你，你的公司做得很好。或者可能有一个翻新或修理的过程，或者你寄出去，他们再寄回来。

如果你要把替换计划写进你的计划，那就制定预算，和你需要的人讨论这个问题，这样你就知道你的限制是什么，如果发生了什么事情，应该去哪里，如果你整个服务器机架都出了问题，比如，好吧，我们如何替换这些吗?我们该给谁打电话?我们在做什么?

有什么计划吗?让我们讨论一下自动故障转移和站点切换。所以这可能是最大的一块,因为我有很多恐怖的故事走了进来,说了很多,你知道的,我们有这个问题,我们有备份站点,但它没有自动走过去,我们不知道如何处理数据,你知道的,暂停和重新思考,创建一个计划,这样如果发生,你有一个备份网站几乎自动,你将它自动,我的意思是，很明显，人类会参与其中，但你会尽你所能来减少你的产品停机的时间。

如果您有一个镜像站点，需要频繁地签入和更新，那么请继续下去，在您的计划中加入一个用于下沉数据库、维护镜像站点和故障站点的时间表。还要经常进行现场切换演练，对吗?这看起来就像你指定谁负责站点切换，你设置了一个时间表，他们会去做，你会很好地记录它是如何进行的，任何出错的地方，一切顺利的地方。然后在网站启动后进行事后分析，我们需要改进什么?我们怎样才能加快速度呢?

我们怎么能让这事简单一点?因为当真正糟糕的事情发生时，很明显，你不会有…你知道，计划时间，我实际上和Salesforce的一个SRS交谈过，他真的很棒，他说，是的，他们有一个固定的时间表，这是可以接受的，在切换站点的日子里，我们做检查表，检查表，切换站点，检查文件，事后分析。

这是一个非常有效的系统，当有不好的事情发生时，它会更快地过去。你肯定想监控不寻常的流量，这显然是你无论如何都想做的，但很多可怕的事情发生在软件上，其中流量峰值是不寻常的，没有人真正注意到，因为它有点……基本上DDoS攻击正在发生，没有人注意到，因为它们总是有峰值。所以这些东西都是你要写进去寻找的东西。如果你看到异常交通，你会怎么做?你能多快做出反应?

另一件我没有想到的事情是你的版本控制，对吧?你想在你的计划中写一个固定的时间表来从你的回购中取出特定的人，特定的仓库在特定的时间表里?我为什么这么说?一些人分享了他们遇到的问题……这是Bitbucket, GitHub, GitLab，就像它不是一个组织一样，但他们会有一天随机停机。好吧，我想我们都慢下来了。

现在，如果这不是一个大问题，你不需要把它写进去。但如果你不断地交互和推送代码，如果你需要不断地与版本控制系统交互，你可能会想，好吧，你是这个存储库的代码所有者，请每天早上拉一下。同样，这并不总是必要的，但需要考虑，因为您的版本控制可能会出错。

数据库，我把这个放在这部分的最后，因为，天哪，对我来说，可能发生的最糟糕的事情就是数据丢失。对吧?一旦它消失了，它就消失了。这就是为什么你总是有备份和简报之类的。但数据丢失对我来说是最大的问题，因为作为一个用户，我的意思是，想想当你打开你的亚马逊应用程序时，对吧?

作为一个用户，如果我打开那个应用，什么都没发生，它就出来了，这是有问题的。我有点生气。几分钟后就会回来。我相信他们会重新站起来。酷。然而，如果它工作得很好，但我看不到我去年订购的任何东西，那我就生气了，对吧?我们刚开始讲的是完全镜像恢复站点。这是非常重要的。你需要考虑的是，当你有一个镜像站点时，或者当你遇到问题时你需要考虑如何处理数据下沉，对吧?举个例子，如果你在做站点切换的练习，你想要考虑什么时候削减用户创建更多数据或与数据交互的能力?

你打算什么时候把它切断这样你就能进入开关了，对吧?你肯定不希望在转换过程中丢失任何东西。在真正的紧急情况下如何处理切断数据以访问全镜像站点?这些都是你想写的东西。我们要怎么处理呢?对吧?我们不希望我们的用户在切换时与坏掉的旧设备交互。

写下来。想想看。

是的，确实有很多关于数据丢失的恐怖故事，我的意思是，有些事情你可以计划，有些事情你不能，对吧?我记得是几年前，一名公共事业工人在亚马逊的一个大数据中心外切断了一条线路。你猜怎么着?这是个问题。你不能为此计划。你不能计划如果一只蝴蝶在密尔沃基扇动翅膀。这对我的软件有什么影响?但是你可以说，好吧，让我们假设我们的任何一个数据中心都可能遇到问题。

我们有广泛可用的数据吗?我们是否在不断后退和反思?我们的回收站随时都准备好了吗?尽可能接近所有时间。这些都是你可以控制的事情。更重要的是，团队中的每个人都知道灾难发生时到达现场的情况吗?然后再研究这个?所以，是的，我的意思是，如果你只是做直接的产品灾难恢复，这就是你想要的真正的肉和土豆。

但如果你想成为一个有价值的人，或者你在一家小公司工作，我们将简要地谈谈几件事。首先，我在2020年1月写了灾难恢复计划。

我是一个书呆子，从感恩节开始就在BBC世界新闻上关注冠状病毒。所以我感觉有什么事情要发生。我没有预见到2021年还会很遥远，但我感觉有什么事情要发生了。

这是一件更大的事情，也让我被嘲笑为危言耸听，但是如果你不能在办公室工作怎么办，对吧?

谢谢你,大流行。它看起来像什么?所以有几种选择，对吧?假设你因为流感大流行而不能在办公室工作。好吧，希望我们不会再遇到这样的问题了。但也许可以写进计划里。从办公室里的大多数人或灵活的安排过渡到每个人100%的虚拟会是什么样子?

你如何确保所有员工在家都有工作所需的一切?这是可以考虑的，但如果你不能在办公室工作，因为水线破裂或火灾损坏或正在熏蒸或任何拥有一栋大楼的事情，你想考虑一个备用地点吗?所以对于SalesForce这样的公司来说，这并没有什么意义。

我们在办公室的时候员工太多了……但如果你是一家初创企业，后备地点是什么样子的?看起来像出租共享办公空间吗?如果你们是一个很小的团队，那是不是像，你们10个人去一个人的家里?你需要当面谈谈吗?这些都是你可能想要考虑的事情，特别是因为我很抱歉，比如，我们经历了这场大流行，你知道，七年前我们就被警告过了。现在发生了。我的意思是，我希望在我的有生之年不会再发生这种事，但它有可能发生，我们可能会考虑一下。安全问题。这就是我经常被称为危言耸听的原因。但这是值得思考的。

我住在美国，我有上学的孩子。所以我确实想到了活跃枪手的情况。如果你在办公室里工作，尤其是没有严格安全措施的办公室，我上一间办公室就像是一个生活-工作-娱乐的空间，在那里真的任何人都可以随时进来。你会怎么做?这是需要考虑的事情，你知道，很明显，有很多不同的事情要做，你知道，大多数是隐藏，逃跑。最坏的情况是打架，但这些都是要考虑的事情。如果我们怀疑大楼里发生了这种事，我们该躲在哪里?谁负责检查每个人?

如果可以报警，谁负责?这些都是你需要考虑的。同样，这取决于，你知道，你在哪里工作，如果你工作，你知道，如果你在为疾病预防控制中心做软件，那么，你猜怎么着?炸弹威胁是家常便饭。

另一件事可能永远不会发生，但你可能会发生我想在事情发生之前好好想想。火。你有指定的消防逃生计划吗?你练习过吗?我知道，作为一个成年人，做消防演习听起来很俗气，我甚至不是鼓励你在桌子下面蹲下。但我想说的是，一旦大楼发生火灾，每个人都知道紧急出口在哪里，以便尽快逃离大楼吗?

办公室里的每个人都知道一个指定的开会地点吗?这样你就可以清点人数，确保每个人都安全离开?值得思考。然后比最后那些令人沮丧的更有可能。人类的问题，对吧?让我们来谈谈群体性疾病，特别是在一个小团队中，或者在一个团队中，你的代码所有者只是主题专家，可能没有那么多其他人能够完成他们的任务。

如果一半的队员都生病了怎么办?你们有保险吗?你们是否有人和其他人进行交叉培训来学习这些技能?这是需要考虑的。如果所有人同时兑现PTO会怎样?现在很明显，如果你有这样的公司你必须得到专利商标权的批准这是可以减轻的，但如果你在一家不受专利商标权限制的公司工作，你长大了，该去的时候就去，如果出现问题，一半的团队都在度假怎么办?是否有适当的协议?每个人都知道他们的期望吗?这是需要考虑的。然后是伸展的叶子。现在这个，作为一个经历过，你知道，怀孕的人，在我上一家公司工作时，要考虑一些事情，你知道，人们遇到车祸，人们生孩子，人们有为了照顾年长的家庭成员，人们有很多理由可能需要延长假期。

所以批判性地审视你的团队，是否有一个或几个人，如果他们突然离开三个月，你的团队会如何适应?你会怎么处理?有什么协议?你们是交叉训练的人吗?现在就像产假，或者陪产假，你应该知道，嘿，这即将到来，尽管我们都看过那个节目“我不知道我怀孕了”，这种情况会发生，朋友们，这种情况会发生。但你应该能够为此做好计划，说，好吧，你知道，这位先生将休产假去见他的新生儿，耶。

我们需要培训谁来确保他不在的时候，我们有足够的保障?只是需要思考一下。这是随机的建议。这些基本上都是在调查中出现的人们说能引起我共鸣的事情，对吧?那些我觉得值得分享的东西，或者随便说说。所以，并非所有的依赖关系都是相等的。有些事情出了问题，有些事情坏了，有些过程不能工作，这是绝对关键的任务，没有它们你就不能工作。还有一些事情可以等一天。还有一些东西要花一周的时间，把这些潜在的问题，比如，这有多重要，对吧?

有什么大不了的?我们把这个纳入计划，好吗?所以如果你在看某些情况，你在分类，好吧，这是第一级，这是最重要的，我们稍后再讲，现在很重要。想想看。这真的是一个很大的问题，尤其是对像我这样患有复杂创伤后应激障碍的人来说。不是所有灾难的可能性都一样，对吧?所以，你知道，我谈到了一个问题，你知道，潜在的数据丢失，然后我谈到了一个活跃的枪手情况，你猜怎么着?其中一个甚至比另一个更有可能住在美国。所以，你知道，是的，你可能会承认一些，你知道，一些孤立的情况，一些可能出错的小众事情，但要知道，你可能不想在那上面花那么多时间。

让我们花更多的时间来规划站点切换，让我们花更多的时间来创建更新和维护镜像站点的时间表，对吗?并非所有的事情都有同样的可能性。我在开始的时候提到过这个我要再讲一遍。测试，测试很重要，对吧?所以你有这些计划，也许是一年一次的消防演习，或者任何时候，你知道，有一些新员工，消防演习。然后，对于站点切换，可能是一个月一次，一个月两次，这取决于你的软件，以及它有多重要你的用户一天24小时都可以访问，不管有什么意义，不管你在计划什么潜在的灾难，无论什么，你都必须测试它，它必须是一个固定的间隔，每个人都必须参与测试。

我喜欢用不太可能的障碍来测试这个计划。这是一条疯狂的裤子，但我们在我的老公司做了一个演习，当我很新，你知道，我刚刚开始，他们基本上想知道发生了什么。当时我正在开发的软件与自然灾害密切相关，所以我们的使用量肯定会激增。在飓风季节到来之前，我们想看看这个产品的用户高峰是什么样的?比如，我们能处理好吗?所以我们有了一个假飓风。这很巧妙，他们让我一个对软件一无所知的人，比如扮演保险理算员的角色，我只是尽量表现得愚蠢，做一些愚蠢的事情，然后对此感到愤怒，因为我在客户服务部门工作过，我知道那是怎么回事。嗯，用一些奇怪的东西来测试这个计划，比如……特别是如果你在一个较小的团队，也许这个人最擅长切换站点的人就坐在一边，让一个没有经验的人来运行这个站点，然后看着它。就像学徒一样，对吧?

加入一些小问题来检验你的计划。先给自己做个仓鼠实验，然后再做一次测试。我的意思是，绝大多数人，我想几乎每个回答的人都提到了一些事情，要么我们测试得非常频繁，要么因为我们测试得不够，这就是发生的事情。你知道，我喜欢它，你知道，我曾经做过保护工作，我必须要做射击认证，我的射击教练会让我们，你知道，画武器要超慢，因为慢即平滑，平滑即快速。所以在可控的情况下，慢慢地测试，慢慢地测试，你在这个过程中会很顺利，所以当你必须快速行动时，你可以。就是这样。厄运和忧郁。我不想做个扫兴的人，但事情总会出错。事实证明，事情出了问题，而我不知道但我越是准备充分，就越能意识到可能出错的地方以及出错时该怎么做，这对我来说非常安慰。所以我希望你们已经了解了一些可以写进你的DR计划的东西，

我想说的是，我相信IBM有一种免费的模板，可以用于DR规划，而且做得很好。所以你可能需要调查一下。但是，是的，总的来说，我希望你觉得你已经有了一个很好的起点，如何开始编写一个灾难恢复计划，这将为你的团队和公司增加价值，并进一步推进你的职业生涯。一如既往，欢迎随时联系我。我喜欢与社区联系，我希望得到你的反馈。

非常感谢你来swampamp。

这是我在现实生活中从未参加过的最喜欢的会议。

我希望你们和我一样喜欢这门课。

谢谢。