这是第四一系列帖子增加服务或系统的总体可用性。
你有没有得到分页并立即知道这个问题不像您本周处理的最后15个操作问题?这个问题很特别,真的很糟糕吗?您知道,您一直在潜意识中一直担心的那种问题已有数周之久了,并且您一直希望永远不会发生?
好吧,当它发生时,您会怎么做?Often in these high-pressure situations, you’ll have a very brief period of time (say, minutes) before a problem goes from ‘pretty-bad-but-our-customers-will-forgive-us-and-some-might-not-even-notice’ to simply catastrophic. If you’re a男孩或女童军,您只需打开事先准备的压力释放阀,并防止问题逐渐失控。
建造压力释放阀
在建立或维护自己拥有的系统或服务之一时,您是否曾经对自己说:“您知道,如果情况X发生,那么不可能,我们会遇到真正的麻烦”?情况X可能是您给定系统的任何假设的灾难性灾难场景:Master和Slave Datastores同时下降;您的所有客户或客户都决定一次将您的交通峰值淹没;您选择的云提供商会遭受多可用性区域中断;您的基于多播的消息传递系统患有反馈循环;等等
问题是,如果您使用给定系统足够长的时间,那么“情况X”实际上会出现的可能性更高。
所以,你可以做什么?是的,您可以尝试设计一个系统,以防止这些灾难性的失败。但是,建立这样的东西可能是时间和成本较小的,如果您走得太远,很容易导致过度设计的系统。花费大量的开发时间针对故障方案,这可能在您一生中有5%的机会发生,这并不是您的资源的最佳利用[1]。
而是创建压力释放阀。您可以将这些视为一种杠杆或旋钮,您可以在失败期间进行调整,以减少问题的严重性。他们通常可以采取基于配置在紧急情况下可以轻松更改的布尔或常数,但也可以以其他形式出现。
您可以使用这些压力释放值轻松地翻转(或打开)一些关键功能,或拨打或向上或向上拨打或向上使用的某些重要值。我将在下面进行一些示例。
头脑风暴
为了提出这些压力释放阀,请与您的团队聚集在一起,并在系统或服务中集思广益(也许是半出境)的方式可能会灾难性地失败。
对于这些故障模式中的每一种,都找出一种可以临时修补,重新布置,短路或通常被黑客入侵以暂时减少问题幅度的方式。目标是将系统重新恢复到功能状态:您可能会被迫牺牲功能。通常,最熟悉给定系统的1-2个人必须设计这些黑客。由于这些人并不总是在紧急情况下可用,因此最好提前探索这些想法。
在创建所有灾难性故障模式的列表以及将系统重新恢复(半)工作状态所需的相应黑客之后,您还可以开始弄清黑客中的常见模式:
- 在此类故障情况下,在传入的请求中添加油门会有所帮助吗?
- 在网站上禁用计算价格昂贵的小部件X或Y会减少负载吗?
- 从数据中心A重新汇总所有传入请求的能力是否会将部分中断变成一些延迟问题?
- 会放松您的一致性要求会导致一些损坏的数据,但会使您的系统可用再次?
- 您还能从数据存储中牺牲其他功能,以使其再次发挥作用?耐用性?历史数据?写作能力(通过使用仅读取的从属)?
- 会为您的更重要的工作流换掉一些非关键背景工作流程吗?
- 实习生的仪式牺牲会安抚行动神吗?[2]
仅在部分功能上lim绕比完整的停电要好得多,并且在他们的待命工作人员中也要承受压力开始他们有条理的S.O.P解决问题的根本原因。
正如我之前说的,你可以尝试过度工程系统,以防止这些罕见的异国情调灾难发生,但这通常不值得。另外,即使那样,也可能仍然成为其他偶数可怕的,但可以陷入困境的失败模式,这些模式可能会受益于这些集思广益的讨论。因此,不一定浪费大量时间工程方法来防止这些晦涩的问题,但是也不要忽略他们的可能性。谈论他们!
如果有人有更多的压力释放阀示例,您将保留在自己的操作工具包中,我将非常有兴趣在评论中听到有关它们的消息。
[1]如果您要构建核反应堆之类的东西,请忽略此建议。让那个狗屎工作。
[2]只是在开玩笑。行动的神不会比全职纽豪尔大学毕业生不少地起床。