保持我们的软件正常运行与保持我们的组织运作并没有什么不同。我们可以互相学习，使用相同的技术。
我是在1999年开始写代码的，正好赶上了千年虫。在很长一段时间里，我写代码，检查它，这就差不多了。然后，随着我们开始采用分布式架构，转移到云端，并更频繁地发布代码，我需要扩大我的技能，包括部署管道，基础设施，可观察性，等等。
但后来我在《金融时报》担任了一个新的角色，是负责运营和可靠性的技术总监。我在入职后才知道，我现在也需要了解和关心业务连续性。
从本质上讲，业务连续性是指确保你的业务在出错时继续运作，无论是地震、炸弹恐慌还是大流行病。
它意味着为你的办公室、电力、网络和关键软件系统失去联系时的情况制定计划，也意味着了解如果你的一半员工同时生病，你会怎么做。
这是关于有一个备份计划，并知道什么是关键，什么可以暂时不完全工作。这听起来很像可靠性工程。
事实证明，我们用来确保我们的软件保持功能的一些技术也适用于更广泛的组织。对我来说，这种学习是双向的：公司长期以来一直在为业务连续性进行规划，并对哪些是有效的、哪些是无效的有经验。
让我先跟你说说《金融时报》的一些业务连续性考虑。
我们能印刷报纸吗？
印刷报纸并不是FT的唯一关键功能，但它结合了紧凑的时间安排和相当大的影响，如果我们弄错了，所以它是一个主要焦点。金融时报》从未错过印刷版，作为业务连续性计划的新主人，这让人感到恐惧。
对于《金融时报》来说，在午后/傍晚时分，有一个关键时期，就是印刷报纸的拼接。报纸的印刷和发行是一项复杂的业务，在这个过程中，物理拷贝要经过一个扇形的过程，最后往往是有人在面包车上开着一捆捆的报纸。如果你错过了印刷的最后期限，很多人就得不到他们的报纸了。
在这个关键的下午，我们可能有30分钟的时间来应对任何重大问题，并 "失败 "到备用计划。
直到最近，FT的办公室、电力、网络等损失的计划是在离我们伦敦办公室20分钟路程的地方建立一个灾难恢复点。我们在那里为一小群人提供了一个永久的套房，这些人对报纸的出版至关重要。
我们还有一个更大的套房，可以在一天之内建立起来，为大约10%的员工提供空间。每个部门都会预先提名他们需要的 "关键 "人员，以便在我们无法进入办公室的几天里提供 "足够好 "的业务功能。
我们在其他办公室也有类似的设置，特别是在马尼拉的办公室。
你可能听起来不太可能失去在办公室工作的能力，但在短短四年内，火山和地震都影响了我们的马尼拉办公室，我们在伦敦发生了炸弹恐慌，我们都被疏散了几个小时，而我们在博罗市场恐怖袭击的警戒线外只有几百米。如果我们在警戒线内，我们的办公室将有长达一周的访问限制。因此，这些事情经常发生。
当然，还有一件大事：冠状病毒大流行。
Covid-19：巨大的挑战
2020年初，我们的第一个办公室关闭，在香港。如果你像我一样，密切关注新闻，它似乎很有可能正向我们走来，在我们所有的地方。
很明显，我们的备份站点在这里不是解决方案：我们需要一个应对封锁的计划，这意味着人们要在家里工作，安全隔离。
幸运的是，我们最大的办公室--伦敦的FT在2019年中期完成了办公室搬迁，大多数人现在都有笔记本电脑和VoIP软电话。我们已经在公共互联网上提供了许多东西，而不是通过我们的办公网络。很多人每周有一天在家里工作。所有这些变化都有助于我们让每个人在家工作的行动。
我们最大的顾虑是小故障对所有人的影响。一个大数字的一小部分仍然可以产生很大的影响。我们认为我们的服务台会超负荷工作，我们可能会有一些团队，每个人都在努力能够有效地工作，如果这意味着公司无法执行一些关键任务，就会有明显的风险。
为了减轻这种情况，在二月中旬，我们开始要求一个部门每次在家工作一天。
作为一项演习，这意味着如果人们真的被卡住了，他们可以到办公室去，并得到解决。这也迫使各部门仔细考虑如何处理他们的 "亲自 "要求--例如，签署支票。
我们还开始预测在很短的时间内被封锁，要求人们确保他们把笔记本电脑带回家过夜，并定期提醒人们注意这一点。
在政府封锁前一周，我们在伦敦发出了在家工作的呼吁，每个部门都进行了演习，过程相当顺利。
业务连续性与运营和可靠性有许多共同之处，其中之一就是你可能不得不在降级模式下运行一段时间。
它们也有相似之处，即现实可能与你计划的不太一样。在这两者中，你要在压力下处理事件，而要做到这一点，有效的沟通和建立共同的理解是至关重要的。
我将介绍一些我认为特别有价值的东西，无论你是在研究你的软件还是你的组织的可靠性，都要牢记在心。
理解什么是关键功能
对什么是关键功能有一个共同的理解是非常重要的，因为你必须在危机中迅速做出决定。你需要根据你已经了解的信息采取行动。
几年前，我们试图对公司中所有依赖软件的业务功能流进行分类--当然，这基本上是所有的功能。我们开始识别那些对品牌至关重要的流程，也就是说，如果我们不能做到这一点，就会影响人们对我们品牌的看法。出版报纸和保持我们的付费墙的安全适合这里，以及保持网站的可用性。
然后，我们看了看关键业务的东西。这不太可能成为一个大事件，但会阻止我们做我们的工作。丢失的客户服务工具或财务系统就在这个领域。
我们把这些东西都与一个服务等级联系起来。品牌关键是白金级，这就有了高水平的可靠性要求，例如，我们希望它们在多个云区域运行，而不仅仅是在多个可用性区域。我们还希望这些服务能够在非工作时间内得到修复，开发团队能够随叫随到。关键业务是黄金级别，对可靠性的要求略低。
FT也有一个青铜级，许多系统都在这里。如果这些系统发生故障，它们不会在正常工作时间之外被修复。它们不太可能在多个地区，虽然它们有可能在多个可用区，但这是为了零停机时间的发布。
这些种类的区别真的可以帮助你专注于最重要的东西。同时发生多个问题是很常见的，我们会根据服务层级来看待问题。这与业务连续性首先关注品牌关键的东西的方式完全平行--实际上，在试图评估事情的位置时，这对我们是一个很好的指导：这个软件是否被设置为可以访问灾难恢复站点的人使用？
了解什么是关键性的另一个方面，在谈论诸如5个9的可用性时不容易捕捉到，这就是需要系统的关键时间：很多流程类似于报纸的生产，它们只在特定的时间是关键的。
对许多公司来说，一个常见的例子是工资单的运行。它需要在月底进行，如果财务系统在这时出现故障，影响是很大的。没有人愿意错过支付他们的员工。
金融时报的其他例子包括网站发布：新内容是定期发布的，但银行假日的故障比预算日的影响要小得多，而且你可能以不同的方式进行调查和修复。
更为棘手的是，当编辑即将发表一篇独家报道时，你会遇到一个问题：你只有通过与利益相关者建立良好的关系，才能知道这是个关键时刻。
弄清短期内可以接受的情况
业务连续性规划教给你的一件事是，当你处于 "危机模式 "时，你可以接受什么。
如果我们不得不撤离我们的办公大楼，因为我们失去了电力，并依靠备用发电机工作，我们不会期望一天的标准工作。同样，当我们派人在家工作时，我们预计有些人的工作条件会不太理想。也许他们没有一个安静的工作场所、一张桌子、一台显示器或一把舒适的椅子。
回想一下2020年初。你可能和我一样，认为我们会离开办公室一两个月。但在某个时候，我们意识到这将是我们在很长一段时间内的工作方式。因此，向WFH的转变有两个阶段。让每个人都离开办公室，然后让每个人都能正常工作。
在处理软件事故时，我经常发现，开发人员专注于找出出错的地方并加以修复。但这忽略了一些重要的东西，那就是缓解。
即使你还不了解发生了什么，你也可以尝试一些可能有帮助的事情。这可以是故障转移到一个没有奇怪的错误高峰的区域，或者增加实例，看看这是否是由负载引起的。
这也可以是一个决定，退回到一个减少的功能集：如果有问题，付费墙的一个选择是关闭它，让任何人都可以访问，甚至是非订阅者。如果你事先做好了计划，在发生事故时就会容易得多。对FT来说，"失败的开放 "是一种弹性选择。Netflix也同样为宽松的退化进行了架构，例如使用非个性化的或缓存的结果。
我最近还看到SeatGeek的Vitor Pellegrino和Anderson Parra关于高需求门票销售的演讲，他们非常清楚SeatGeek在极端负载下有不同的操作模式，即你打开一个等待室，让人们排队进入。
这不是你想要的标准模式，但对于真正尖锐的需求来说，这是一个伟大的方法。
准备
优雅的退化往往是以前的事件留下的疤痕造成的。例如，FT的操作运行手册的数据--解释如何排除故障和修复系统的东西--生活在一个非多区域的图形数据库中。为了确保更高的可靠性，这些数据被定期提取并放入多个地区的s3桶中。
然而，当我们失去了我们的单点登录系统，我们发现我们无法访问它的运行手册！这导致我们增加了一个相当大的附加值。这导致我们增加了一个额外的相当基本的备份水平，那就是将这些文件压缩并粘在Google Drive中。
这就是混乱实验的真正用处，即你故意模拟一个你认为你的系统可以处理的故障，因为你已经建立了弹性。即使只是计划一个混沌实验的过程，也能给你带来价值，因为你要思考你预期会发生什么。
例如，大约5年前，FT仍然在数据中心运作，我们想测试一下，我们是否可以成功地从一个中心运行。
我的团队正在编写一个新的系统，它还不需要高水平的弹性，而且我们没有在两个数据中心运行。事实上，我们是在将被切断的数据中心中运行，以进行测试。我们知道在测试期间，我们将被关闭，这很好。但是，当我们在测试前在白板上浏览流程时，我们意识到在运行中的数据中心有一些代码会调用我们的系统，而这个调用会超时。
不幸的是，这个调用来自一个关键系统，即用于发布文章的主要内容管理系统。更糟糕的是，这个超时被设置为10分钟，并且隐藏在一个消息队列的配置中，这意味着任何记者在这个测试期间发布一个故事，都会在相当长的时间内被阻止做其他事情。
如果不知道这个测试即将到来，我们绝不会考虑这个问题，但想到这个问题意味着我们有机会及时实施一个变通办法。
与业务连续性类似，准备工作也会得到回报。金融时报》向WFH的转变得益于几个层面的前期准备。
首先，我们的IT部门已经为更灵活的工作做出了改变：笔记本电脑、软电话、网络访问软件。这是一个战略性的选择，并且得到了回报。如果大流行病在一年前发生，我们会有一个更困难的转换。
但其次，我们最大的两个部门之前已经进行了在家工作的演习，这意味着我们有一个模板，也可以关注那些从未进行过演习的部门。尽管有人员流动和办公室变化，我们仍然感到安全，这些部门已经有足够的人准备好成功地在家工作。
试一试
我自己的部门，产品和技术部，是第二个进行在家工作测试的部门，基本上复制了另一个部门的方法；提前宣布测试，设定一个日期，并要求每个人确保他们把工作用的笔记本电脑带回家。
然而，与第一个部门不同的是，我们没有预先与每个人核对；我们只是分享将要发生的事情，并为任何问题或关切建立了一个Slack频道。这确实减少了工作量，因为我们所要做的就是商定一个日期并让外部利益相关者知道。
当天，有几个人遇到了问题，但大多数人都很好，他们用这个频道分享了他们最后工作地点的照片--包括酒吧、火车和许多花园。
不出所料，有些人无法在家里工作：有几个人正在搬家，没有WIFI；还有一些人没有地方可以工作，无法分心。我们告诉他们，这绝对没问题，这也是我们所期望的，但这也意味着要确保他们不会受到经理的刁难。有几个人因为与外部人员有约，或者因为他们知道自己不能在家工作，而来到办公室，这对我们来说也没有问题。
保持简单的事情
有许多情况下，你可能会在家里没有工作用的笔记本电脑。你可能在离开你的办公桌时，火警警报响起，不得不在没有它的情况下离开。或者你可能一夜之间被告知第二天不能来上班。
一个 "完整 "的测试会让人们在没有通知的情况下突然发生这种情况，但这更具有破坏性，而且你仍然可以从给人们的提前通知中获得很多价值。
事实上，我们确实要求人们在一天中把工作用的笔记本电脑放在一边几个小时，使用他们现有的任何东西。这导致一些人花了几个小时在家里的笔记本电脑上设置他们的开发环境。其他人则选择了其他工作。
有几个人告诉我，他们没有家用笔记本电脑，并问我如果这是我们的业务连续性计划，FT是否会买一台。我的回答是，实际上，我们的业务连续性计划是有足够多的人可以在家工作，而不是每个人，但如果问题持续数天，我们会想办法把工作用的笔记本电脑送回家，或找到其他解决方案。
期待你的预测是错误的
我们没有完美的信息：你的预测很可能是错误的。
在2020年3月，我认为我们的大流行病的最大挑战之一将是疾病对团队的影响。我的运营主管和我花了很多时间来计算我们可以运行一个一线支持团队的绝对最低人数，以及我们可以在哪里引入额外的事件经理等。但我们非常幸运，可能是因为金融时报提前将人们送入了禁闭状态。我们没有一下子有很多人请病假。
反过来说，一般来说，当你有多个办公室时，你的业务连续性计划的一部分依赖于将工作转移到不受影响的办公室。在2020年，有一段时间没有未受影响的办公室，封锁意味着所有地点的访问都受到严重限制。我们没有预测到这一点，不得不为那些需要亲临现场的活动或使用专业设备的事情找到其他解决方案。
沟通
无论你考虑的是业务连续性还是复原力，沟通都很重要。其中的一部分是选择正确的沟通渠道。
在我开始加入我们的业务连续性小组的时候，我们建立了一个WhatsApp小组，作为解决该问题的中心。我们认识到，当事情发生时，人们更有可能带着手机而不是笔记本电脑，即使他们有笔记本电脑，也没有人愿意在疏散点时把它放在一个垃圾桶上。大多数人的手机上都有WhatsApp，而Slack可能不在其中。
在WhatsApp群中，协调我们应对措施的人，会以任何可行的方式向他们的部门发送信息。不同的部门喜欢不同的通信工具
对于运营事件，Slack是主要渠道。这是技术团队花费大部分时间的地方，我们使用Slack机器人来管理事件（基于Monzo的开源响应机器人）。
但你也需要一个备份计划，以应对失去主要沟通渠道的情况。当Slack第一次出现故障时，你会意识到你需要计划在没有它的情况下能够运行一个事件。在英国金融时报的案例中，这就是通过谷歌聊天（或谷歌当时的任何同等渠道）。
一旦你们都进入了正确的渠道，你们就需要开始交谈。
你需要反复沟通，而且你仍然应该期待有人错过沟通的机会。
例如，在在家工作的测试日，我们仍然有很多人来到办公室。他们没有看到--或者也许没有登记--任何沟通！这就是为什么我们要把这些人带到办公室。
同样，尽管我们有一个通过文本提供紧急信息的系统，但一些人在我们锁定后的第二天仍然来上班，因为他们在非工作时间不看电子邮件或Slack，没有收到文本。
当你运行一个混乱的实验时，同样的事情也会发生。也许你正在关闭一个API，以测试网站的优雅降级能力。我们曾经做过一次，API团队的一个开发人员在几分钟内就重新启动了网站，因为他们看到了警报，但他们错过了关于实验的通讯。
几乎每个问题都是不同的
业务连续性和可靠性工程都是为了应对突发事件，而几乎每个问题都是不同的。
即使你有类似的原因，例如，办公室停电，你也可能要做出不同的反应。早上5点断电可能意味着你要优先考虑阻止人们上班。下午3点断电，可能意味着要想办法把人们从电梯里救出来！这并不意味着你可以不顾一切地去救人。
这并不意味着你们不能为自己做好准备。建立沟通渠道，编写模板和运行手册，建立关系，尝试事情，并确保正确的人参与。然后享受其中的乐趣!