关键要点
- 可靠性是架构的一种涌现属性，可以包含对客户重要的任何属性，如可用性、延迟、吞吐量、持久性或信息新鲜度。因此，它超越了单个用例。
- 不存在所谓的事故单一根本原因。失败有多种原因，其中一些是社会技术性的。有时为了理解事故，必须了解事故发生前某物是如何工作的。
- 架构师和软件可靠性工程师应建立基于对系统实际工作方式好奇心的协作关系。有关失败的知识应与架构师和设计师共享，这样他们不仅能了解系统在实践中的运行方式，还能利用这些信息在未来设计出更好的系统。
- 事后审查应首先关注“什么”和“如何”，然后再问“为什么”。过早关注“为什么”通常会遗漏重要信息。
- 复杂系统几乎总是处于失败的边缘。
文稿
Michael Stiefel：欢迎来到架构师播客，在这里我们讨论成为架构师意味着什么，以及架构师实际上如何工作。今天，我们将讨论一些对架构师非常重要但通常没有明确讨论的话题。我们已经在这个播客上多次谈到了可靠性和为失败而设计，但我们还没有讨论过如何让我们的系统设计更加健壮，而不仅仅是在失败后进行修复。
今天的嘉宾是David Blank-Edelman。他是微软SRE学院的项目负责人，该学院负责Azure SRE和其他致力于提高可靠性和质量人员的入职和培训。他在运维领域有大约40年的经验，是SREcon会议的联合创始人，也是O’Reilly出版的《Seeking SRE》的策划者，以及同样由O’Reilly出版的《Becoming SRE》的作者。他在最近的InfoQ Dev Summit Boston上发表了演讲，这也是我有机会聆听他演讲并结识他的地方。欢迎来到播客。
David Blank-Edelman：谢谢。很高兴来到这里，很高兴看到海上的所有船只。
成为一名软件可靠性工程师 [01:49]
Michael Stiefel：好的。如果你不是从架构师的角度，而是从站点可靠性工程的角度来看，可靠性看起来会非常不同。你谈到过，明显的问题往往不会带来正确的答案，这种想法可能违反直觉，这让我想问，你是如何决定成为一名站点可靠性工程师的？这种视角与架构师的有何不同？
David Blank-Edelman：我认为我很自然地进入这个领域。我很早就意识到，我喜欢服务他人、让他人能从技术中获得最佳体验的世界。这始于大学早期，我开始进入运维领域，曾负责管理一个VAX/VMS集群，后来又在所在学院的计算机科学部门工作，帮助他们运行系统。因此，我最初进入了系统管理员的领域，也许你们的一些听众有过类似经历或者至少接触过。然后，随着事情的发展，我一直在关注“运维将走向何方，在DevOps出现时它又去了哪里”。
后来我开始与那些自称是站点可靠性工程师的人交往，当时主要是谷歌的人。他们正在谈论如何构建和运行大规模系统，我觉得“这真的非常有趣”，从那时起，我陷入了思考：“好吧，这就是我想进入的领域”。
Michael Stiefel：所以这实际上似乎是一个非常自然的演变。几乎可以说你是在成长为一名站点可靠性工程师。
架构与软件可靠性工程有何共同点？ [03:31]
David Blank-Edelman：是的。但这不像人类的进化图，一边是蝌蚪，另一边是直立人。我并不是说系统管理员后来成长为DevOps，再成长为SRE。我认为这些路径各有其道理，各有其自身的演变。但我也意识到我没有回答你的架构问题。对我来说，我认为对你问题的直接回答是，SRE和架构的区别在于关注点不同。
两者有很大的重叠。如果不关注架构，不具备架构技能，你就无法做SRE的事情。我想论证的是……我不想说一个好的架构师，因为那真的暗示了我的判断，但我欣赏的那些架构师是花时间思考过可靠性问题的人。他们将可靠性理解为系统的涌现属性，并思考他们能做些什么来使其更有可能或更不可能涌现，并关注这一点。
就像我也欣赏那些思考隐私或安全的架构师一样。这些都是涌现属性，对使用我们系统的人来说确实非常重要。最终，我在这里是为了服务，所以在这两种方式中，我都在尝试用SRE来服务，我认为架构师也在尝试用架构做同样的事情。我认为这非常非常重要，而且我认为我们在架构领域还有很多东西要学。
为完整的系统生命周期设计 [04:58]
Michael Stiefel：嗯，你这么表述很有趣，因为我经常认为架构师的角色是担心所有无法写入用例的事情。换句话说，你无法写出一个用例说“让系统可靠、可扩展、安全”。根据我的经验，如果没有人负责，它就不会发生。这与可靠性非常吻合，不过我们可以谈谈这个术语的确切含义，但让我们暂时使用这个术语——可靠性。你不能在用例上写“使系统可靠”。必须有人看到系统的所有部分，并观察该属性的涌现。这也引出了我们俩都读过的里尔克的《给青年诗人的信》中的观点，关于“活出问题”的理念，因为所有这些不适合用例的事情都不是可以一劳永逸解决的，也许你想稍微阐述一下这个想法，因为我认为它非常重要。
David Blank-Edelman：好吧，我在这方面有点挣扎，因为曾经我在日常工作中做了一系列与“完善架构框架”相关的事情，这是微软的一个框架，旨在制定一些原则和指导，说明如何架构事物。我首先想到的是，“好吧，这个类比对我不起作用的地方是，我通常不认为……”就像，你去找一个建筑师说“请给我建一座楼”，然后你们就这座楼是什么、它必须做什么、参数是什么等等进行长谈，然后他给你一个设计，你建起这座楼。但你通常不会指望建筑师一年后敲你的门说，“嗨，我来给你的楼再做些架构设计”。
因此我理解的是，我认为SRE可能对此也有看法，那就是其中一部分是让它保持在某种状态。让它保持在一种良好架构的状态也是架构。只是你不常想到那种情况。当我们谈论的不是软件而是原子时，你不会想到建筑师后来出现给你做更多的架构。如果是这样，那么你和我都相信的A、你永远达不到，以及B、事物不会保持不变，以及所有其他作用于其上的力量，如熵等，你作为建筑师该怎么办？在我心中，当你意识到熵的存在时，你该怎么办？这是一个超级有趣的问题。
我见过一些非常有趣的事情，比如有人走得如此之远，以至于说：“好吧，我要构建一些东西，以便有一种迭代的方式。”我认为这非常酷。我见过有人说：“嗯，我实际上要弄清楚如何让这座建筑随着时间的推移优雅地退化？”然后后来你会想：“酷，然后我们可以重新开始”。我认为现实世界中的建筑师（指建筑设计师）的这些想法非常有趣，我常常想知道软件领域的架构师有多少时候会思考这些事情？我的意思是，根据我的经验，人们通常不考虑关闭一个系统是怎样的？你是在为将来可以关闭它而构建它吗？因为你我都知道总有一天我们会关闭它。它不会永远存在。
软件可靠性工程的目标是什么？ [08:10]
因此，它是否内置了必要的东西来思考不仅仅是“恭喜，我建好了它。恭喜，我正在运行它，并在运行时修复它”，因为这就是世界的状态。然后有一天我想说：“这不再满足我的需求了。对我来说最简单、最优雅的拆除方式是什么？”我觉得这非常有趣。我曾经就破坏和拆除事物以及我们能从从事这些工作的人那里学到什么做过演讲，因为我认为这是我们思考不足的问题。现在，人们的问题通常始于：“恭喜，我构建了某物。它是否在做我想让它做的事？”因为当你谈论可靠性的定义时，通常是“我是否满足了期望？”，因为有很多期望你可能需要满足。
在你提到的演讲中，我谈到可靠性有所有这些不同的方面，因为人们通常谈论可用性。那是我们通常开始对话的地方。“可用性，它在工作还是没工作？它是开还是关？”作为一名SRE，你可能大部分时间都花在这个空间里。但如果你是一名SRE，并且正在处理一个需要满足特定延迟参数的系统，那么你可能要非常关注延迟。我在Xbox的朋友们，他们非常关注延迟，因为在游戏中这至关重要。是的。这是系统的一部分，这是关键所在。但还有，假设我在运行一个流水线，我可能关心吞吐量，或者假设我在运行一个批处理系统，我可能听到很多关于“我是否完成了整个批处理的工作”，或者我在运行体育比分或选举数据。也许我关心数据的新鲜度，或者如果我在运行某种存储系统，我可能关心持久性，对吧？这真的很重要。可靠性确实是……
如果我对你说：“恭喜，我有这张光盘。”我环顾桌面上各种各样的光盘，如果我存了一个比特进去却拿不出来了，你不会称那是可靠的。但这些都是可靠性的各个方面，当我与人交谈时，我试图扩展他们对可靠性的想法，好消息是我们还没用到“韧性”这个词。我期待着当我们进入那个世界，但我想明确一点，我暂时停留在可靠性的领域。如果我们想稍后谈谈韧性和恢复力，那也会是一次有趣的谈话。关于你的定义，有趣的一点是，你在要求人们知道他们不知道的事情，我不知道人们有多少准备，或者知道如何处理他们不知道的事情。
SRE思维模式
开放性 [10:25] Michael Stiefel：关于这一点，我能说的是，首先你必须保持开放。换句话说，这包含在里尔克著名的“活出问题”表达中，因为架构永远没有完成。你永远不应该认为它完成了。这是你必须理解的第一件事。回到你的房子例子，大多数人有了房子后，不会回去找建筑师说“请把按摩浴缸放在客厅正中央”。但在软件中我们总是这样做。
David Blank-Edelman：哦，是的，完全正确。
随着系统演变保持可靠性 [11:03]
Michael Stiefel：这就是为什么你必须假设，如果你有这些架构问题，其中一些你提出了，一些你……我很感谢你明确了我们所说的可靠性是什么意思，因为我认为这非常重要。但是系统会演变。你今天可能有一个可靠的系统，但有人要求一个新功能，这会影响可靠性，因为它进入了你之前谈到的某个定义，即可靠性是从客户的角度来看，而不是系统的角度。我将继续使用可靠性这个词作为你刚才提到的所有那些事情的简写。所以不仅你的系统会演变，而且还有你将要设计的未来系统。所以你永远无法最终理解甚至这些概念意味着什么。这就是我说的你必须对未知事物保持开放的意思。
David Blank-Edelman：是的，那么你打算怎么做呢？仅仅因为不知道而感到很酷吗？对我来说，我们正朝着三个不同的方向前进，我脑海中连接着许多神经元，所以我会尽力理清我们所讨论的路径。关于开放性的问题，我想说不仅是开放性，对于SRE来说，还有一种非常强烈的愿望，即确保我们理解如何获取数据，如何获取系统的信号，以便我们能够理解它。不仅仅是现在，还有未来。我们如何知道它是否在工作？我们如何知道它不工作？我们如何知道某物是否在影响它？在很多方面，有很多获取信号的方式。一种是你内置的东西，发出哔哔声，你听到的背景音，那是你内置的。然后是“它发生了一次失败”，我们回去查看那次失败。
从失败中学习 [12:55]
因此，从失败中学习对SRE绝对至关重要，我想断言，希望对架构也是如此。我有所有关于建筑师（建筑设计师）的伟大书籍。我说不出他的名字。它以P开头。是个波兰名字，我肯定你知道我说的是谁。有关于系统的非常棒的书，以及当它们紧密耦合时如何出问题。总之，这是事情的一个方面，我们从哪里获取信息，使我们不仅能保持开放，还能积极应对，创建那个反馈循环，因为可靠性通过反馈循环得到改善。我非常明确地愿意提出这个断言。这是第一部分。
复杂系统几乎总是处于失败的边缘 [13:31]
第二部分是，当你谈到添加功能时。在很多情况下，可能是很多事情，你非常了解系统的组件，你理解组件，你构建了它，你理解它，你理解它的故障模式，你理解它，这一切对你来说都有意义。然后有人来找你说：“如果能把你的东西嵌入我的东西里，那会很酷”，或者“也许，只是也许，如果我能从那里查询你的东西并包含进来，会不会很棒”，或者“如果我们有这个能结合我们两个东西的功能，会不会很棒”。然后你开始遇到失败，你会说：“等等，一切在我设计时都完全按设计工作”。然而，这是重叠的促成因素汇集在一起的情况，现在突然间，复杂系统开始以复杂系统的方式运行，也就是说它们几乎总是处于失败的边缘。
我可能谈到的另一件事是，我鼓励你的听众去找找看，如果他们还没看过的话，理查德·库克博士的研究，他是一位麻醉师，花了很多时间在韧性工程领域工作，超级、超级了不起的人写了一篇短论文。每个人都能读。大约五页，叫《复杂系统如何失败》。如果你想读，有一个网站叫 howcomplexsystems.fail。
Michael Stiefel：我们可以在节目说明里放个链接。
David Blank-Edelman：哦，是的。是的，好的。但他指出的其中一点是……现在我们开始进入这个复杂性领域，这种复杂性不是因为我们构建了复杂的东西，而是因为这些事物之间的相互作用不一定被预见到，或者如果被预见到了，你很幸运，但总会有你不知道的事情，比如谦逊。所以也许开放性和谦逊作为架构师、作为SRE也紧密联系在一起，只是说“好吧，我并不知道一切，但我真的想学习”。因为我认为SRE的基础、SRE的思维模式是好奇心。
我告诉人们的事情，我们可以专门谈谈SRE的定义，但我告诉人们，它都基于系统如何工作，然后系统如何失败？当我说系统如何工作时，我不是指在你的白板上。我是指当系统实际运行时，它如何工作？当我说系统如何失败时？我的意思是，这样我就能更多地了解系统如何工作，这才是重点。
以及它如何为客户工作？当我扩展它时如何工作？当我带入英语不好的人时如何工作？当我带入不讲英语且书写系统方向相反的人时如何工作？或者我如何确保色盲的人能看到？
Michael Stiefel：或者有人在现场做了改动，而原始文档中没有记录。如果你对消防工程有所了解，建筑物必须有所谓的竣工图纸。换句话说，消防专业人员到达燃烧的建筑时，仅有建筑师的设计图是不够的。他们需要看到建筑物实际建成的样子。
David Blank-Edelman：对。包括消防员在内的每个人都会说，“这让我了解了……”。我不知道百分比，“……一部分”。但不是全部，因为你可能建好了，但我敢保证有人现在重新布置了那些桌子，或者他们把隔墙移到了不同的方向，或者——
Michael Stiefel：……或者在墙里放了些石棉。
David Blank-Edelman：是的。或者有人决定：“我真正需要做的是在房间中央放一个按摩浴缸”，突然间，恭喜，那个特定情况下消防员的挑战就来了。所以我认为所有这些都非常重要，要明白我们理解事物到一定程度，并且我们有责任尽可能地去更多地理解，因为只有对我们现在所能理解的真实情况有更深的理解，我们才能有效。这同样适用于那个时刻，然后下一个时刻到来，现在我们处于不同的位置，现在我们处在不同的河流中。所以我认为保持那种开放性真的很重要。我的意思是，我真的很喜欢你对它的描述，这也是我们俩如此喜欢里尔克的原因。
Michael Stiefel：对。亨利·基辛格曾经说过，“外交政策的成功只是进入下一场危机的入场券”。本质上，当你遇到一次失败并从失败中学习时，因为你正在做出改变。所以你正在改变系统。所以不能保证系统会以与以前完全相同的方式工作。所以你只是在等待下一次失败。
David Blank-Edelman：是的。我们在交换亨利·基辛格的名言，这很糟糕，因为我不是特别欣赏他，但他也说过：“不可能有危机。我的日程表上没有空位。”
Michael Stiefel：是的。是的。
David Blank-Edelman：我经常想到这个。是的，我的意思是，嗯，这是另一个棘手的问题。我和一个人讨论过，他说：“嘿，我们坚信你应该做的是解决当前的问题，而不是试图追溯很久以前的债务。”我说：“酷。但你意识到，在解决当前问题的同时，你正在创造下一个问题吗？”我的意思是，我喜欢跑步机，我知道这是我们所有人都在上的跑步机，但不要试图安慰自己说：“酷，事情更好了。”不，它们只是不同了，并且正在为下一个不同的事情做准备。
失败没有根本原因 [18:37]
Michael Stiefel：这引出了你谈到的一些重要内容，这也是我有点讨厌的事情。当我们遇到失败并试图理解我们的系统时……我想你知道接下来是什么。有人会告诉我们：“好吧，让我们找出失败的根本原因。”
David Blank-Edelman：哦，我明白了。你只是想激怒我。我没问题。
Michael Stiefel：我认为这很重要。这很重要。
David Blank-Edelman：是的。这不是你第一次听我对此发表看法，所以我很乐意为你听众再谈一次。所以我认为你想向我指出的是……我尝试将其作为我的使命之一，试图让人们停止称之为根本原因，停止谈论根本原因或根本原因分析，因为在几乎所有情况下，尤其是现在系统更复杂了，我们发现没有单一的根本原因。不像我们可以说：“马斯塔德上校在厨房用烛台杀了某某某，恭喜，我们可以绝对确定地描述一件事”，因为当我们这样做时，结果那并不是全貌，如果我们那样谈论，我们只是在欺骗自己。我的问题是，当我们说根本原因分析时，我们试图断言可能存在一个根本原因。
所以人们会绞尽脑汁试图找到那个东西并将其归咎于一个原因，有时是个人。我学会不相信根本原因分析，因为每次你看到这个，你都会说：“好吧，酷。我知道你认为磁盘满了。”所以我们应该防止它变满吗？不，不。那个产生如此多日志以至于填满磁盘的系统有什么问题？这不是一件事吗？所以在我的世界里，最好谈论诸如触发器之类的东西，比如“是什么触发了这一系列事情？”，以及“促成因素是什么？”对我来说，这是描述出现问题时更好的方式，比如“促成因素是什么？”因为事情是这样的，有时候这些促成因素，我保证我马上闭嘴，是社会技术性的。事实上，几乎总是社会技术性的。
不像是人很糟糕，也不像是那个组件失败了。如果这是我们唯一关注的点，那么我们永远无法真正提升水平。如果我对你说：“恭喜，这个东西坏了，我们花了三个小时才修好”，你说：“好吧，我们修好了”，但没人回去问：“为什么花了三个小时？”“哦，因为文档错了。”如果在你开始思考这些事情时，在你开始检查这些事情时，没有人带你走这条路，那么你就永远不会修复文档，恭喜你在下一次中断时，又要花三个小时或更长时间。我的意思是，也许短一些，因为有人想起来了，也许他们凭记忆解决了。但下次宕机时，你想依赖某人的记忆吗？我不想。
所以这是我对此术语担忧的部分原因。我在一家公司工作，这家公司过去称这类事情为根本原因分析，有时趁我不注意时仍然这么叫。我努力去说：“看，嘿，让我们以一种真正代表实际情况的方式来谈论这件事。”这就是我想做的事情。
Michael Stiefel：好吧，让我从一个对人们来说非常直接的角度来看。
David Blank-Edelman：当然。
人为错误是一种症状 [21:40]
Michael Stiefel：假设有一次飞机坠毁，有人去说：“嗯，飞行员按错了开关。”那么问题就变成了：“为什么飞行员认为这是正确的开关？是开关设计不当吗？仪器给出了不正确或误导性的读数吗？这个人接受的培训文档错了吗？是否有人对飞机将在何种条件下运行做出了假设，而他们从未预料到某个部件会以这种故障模式失灵？是否有其他东西失灵了，而飞行员在按开关时没有被警告……？”所以就像你会说的那样，那次失败没有一个根本原因，而且很多时候我们想找到一个受害者来指责。
David Blank-Edelman：是的。所以这就是把人为错误当作一个问题的问题，因为人为错误是一种症状，它根本不是原因。当你说人为错误时，通常意味着你将在即将停止的时刻停止调查问题。为了让人们不认为你是在编造这个抽象的事情，二战期间的B-12轰炸机有一个非常具体的问题，它们中的一些，相当数量的在战区着陆，其中一些东西仍然是保密的，但大部分已经公开了。但有些会着陆，然后在返回滑行道的路上，它们会直接拍在跑道上。它们就直接啪地拍在跑道上，很多B-12都发生了这种情况。当时战区里的其他任何飞机都没有发生这种情况，即使当时其他飞机的数量更多。
所以他们请来了所有专家来检查机械状况。他们检查了电气设备，根本没有发现任何问题。所以他们就直接称之为人为错误。但后来空军雇了一个人来。他是一名工业心理学家，他采访了人，他去查看了B-12的驾驶舱，B-12有两个开关挨在一起。它们看起来几乎一模一样。它们很小，彼此相邻。一个控制襟翼，另一个控制起落架。因为它们靠得太近，并且在这些方面没有区别，人们会错误地拨动它们。这就是为什么今天有FAA规定，要求“你的襟翼必须看起来像这样。你的起落架必须看起来像这样”，并且它们是外观非常不同的旋钮。
所以这对我来说，真的非常非常重要。我的意思是，这是根本原因概念的另一个问题。我的意思是，那里的根本原因是什么？是的，当然，有人按错了开关，但这真的不是重点。
Michael Stiefel：所以我想到的一件事是，根本原因的想法源于对简单系统的看法。当事物不复杂、不是非线性的时候，但当我们构建更复杂的系统，并且可能变得更加非线性时，有许多因素促成某事的发生，甚至是成功。我的意思是，失败的反面是，为了让事情成功，许多事情必须正确运作。所以当某事失败时，是因为许多事情没有正确运作，这应该不足为奇，这意味着在任何给定的时间点，我们都在考虑成功与失败的概率。
例如，有人踢到电缆或你的地方出现停电，以及你的备用系统的地方停电，这都有一个有限的概率。换句话说，你永远无法达到100%，无论你有多少个9，仍然存在成功或失败的概率。因此，我们必须开始将概率判断作为工程判断的一部分，并且不要对事情的成败感到惊讶，因为这都是概率问题。
David Blank-Edelman：好的，对此我有很多话要说，因为我认为这是一个超级好的问题。首先，我不知道我是否会同意根本原因源于一个更简单、更温和、更善良的时代，那时我们只是坐着搅黄油。
Michael Stiefel：我的意思是，如果你有一把斧头，斧柄掉了，很明显是什么问题。
David Blank-Edelman：嗯，但是不，我的意思是，让我们争论一下这个问题——
Michael Stiefel：好的。
David Blank-Edelman：……因为我认为这很有趣。我的意思是，我可能会争辩说，同样未改变的是我们分析的复杂性、深度和对相互关联性的理解。所以如果你的斧头柄掉了，即使在那个时候你可能也会说：“那么，谁应该负责确保斧头得到妥善维护”，或者“这取决于我”，或者“我之前注意到它松了。为什么我没有留出时间来维护我的工具？”，或者随便什么。我把你的类比延伸得太远了，但你知道我的意思。
Michael Stiefel：是的，是的。
David Blank-Edelman：所以这是我想说的第一件事。第二件事是，人们可以从概率角度来看待它，但我不认为有人会说……嗯，我不知道我们数据中心的人是否这样，但我不知道有多少人坐在那里说：“好吧，让我以这种保险的方式想想所有我能想到的可能的失败方式，然后尽我所能计算它的概率。”
适当的可靠性水平 [27:02]
Michael Stiefel：嗯，我的意思不是要计算概率，而是理解你永远无法达到……
David Blank-Edelman：是的。所以好消息是，我在这一点上和你一致，因为SRE谈论的是适当的可靠性水平，你试图寻找适当的水平，因为，如果我们把斧头和其他东西或电缆放在一边，如果我对你说：“很好，我想要100%的可靠性”，这意味着几件事。第一件事是，你的依赖关系呢？假设你希望你的客户100%能访问某物，情况是否如此？我不了解你，但我的电缆最近断了一小会儿。那儿的100%就没了，但除此之外，如果我考虑100%这件事，我就没有进行更改的余量，因为如果我们断言，即使更改需要时间，但如果我们断言我没有机会进行这些更改，因为我没有那个余量，那也不行，那么我们永远无法演进我们的系统。
这就是为什么SRE有非常具体的方式来谈论如何思考可靠性目标、如何标记它们。在这些情况下，如果你有一个系统，你只需要每个星期四用它生成一次报告，我是否应该在星期天凌晨2点它不工作时叫醒你？也许不应该。这就是我们所说的“适当”的意思。所以我同意，更好地理解事情并不总是工作或总是工作，这真的非常重要。另外我想补充的一点是，MIT一位名叫Nancy Leveson的研究人员在韧性工程社区做了一些非常有趣的研究。
Nancy Leveson做了一些非常出色的工作，关于我们称之为安全二或安全三的内容，她首先说：“好吧，各位，我很高兴我们花了很多时间研究你们中断的那30分钟。那其余的时间呢？你可以把所有时间都花在弄清楚那30分钟发生了什么。或者你也可以花很多时间弄清楚前两天一切正常时做对了什么，促成那些成功的因素是什么，我们能否识别它们并加强它们，而不是仅仅处理例外情况？”
我认为这是一种超级有趣的方式，对我来说，这打破了RCA的想法。正如你所说，我轻描淡写地说（这是我从韧性工程的另一位人士John Ospa那里偷来的）：昨天一切顺利的根本原因是什么？我第一次听到John这么说并直接引用他的话时，我的头嗡地一下。突然间，我以一种有助于阐明那次中断本质的方式颠覆了情况。
Michael Stiefel：关于成功和失败的这种洞见，正如你所说，失败实际上是一个信号，是关于为什么——
David Blank-Edelman：可能是。
Michael Stiefel：可能是。
David Blank-Edelman：可能是。
架构师和系统可靠性工程师需要沟通……经常 [29:56]
Michael Stiefel：可能是，是的。那么问题是，这个信号如何传递回架构师，以便架构师能够理解：“嗯，我的系统工作方式并非如我所想”，或者“我能改进它吗？”我们如何从一线人员那里获得反馈循环给架构师或设计师？
David Blank-Edelman：我想表达一个非常，我不知道你会怎么称呼它，观点，那就是我们几乎从不这样做。
Michael Stiefel：是的。
David Blank-Edelman：这就是我想说的。所以如果我们想从理论层面谈论这个问题，我完全赞成，因为我希望它发生得更频繁。
Michael Stiefel：问题是这样的。我希望我们的听众开始思考这个问题，并思考也许只是偶尔和SRE一起吃个午饭。我的意思是，换句话说，正如你之前提到的，障碍往往就是社会技术性的事物，试图将其制度化是错误的想法。关键是要在人们之间建立这种沟通，然后他们会在自己的组织中找出“确保这种情况发生的最佳方式是什么”。
David Blank-Edelman：据我们所知。我继续不想显得太像“哦，如果你知道，一切都会好起来”。
Michael Stiefel：不，不，但我是说，也许如果他们每个月聚一次午餐，然后他们会想：“好吧，原来你就在我隔壁办公室，也许我们可以见面。”换句话说，我只是想强调这一点的重要性，然后人们可以想出自己如何做的方法。
David Blank-Edelman：我有两个想法。第一，我强烈鼓励你的听众想办法在设计时内置获取那些数据的机制，并对“我的系统在生产中会如何行为？”这个问题保持渴望。它在我写下来时的行为是另一回事，但要真正渴望了解，然后试着思考：“我将如何收集这些信息？”因为有时候SRE会回去找架构师说：“酷，我喜欢你的系统。我怎么知道它什么时候成功，什么时候失败？你对成功的定义是什么？因为你对成功的定义可能包含一个我不知道的关于延迟的隐含概念，或者可能包含一个你没有真正告诉我的关于规模的隐含概念。”“只要你不启动四个实例，三个就没事，但我不保证四个实例的情况。”
所以我认为，尽可能明确你的期望非常重要，但也要尝试传递这些信息，并思考作为架构师我将如何为自己获取这些信息，并且想要这些信息。我不会试图把任何东西强加给任何人，但我希望他们想要这些信息。这很有趣，因为中间有一群人，理论上他们在构建你设计的任何东西，然后我们把这种情况想象成好像坐在那里的人、这些罐子里的大脑在思考宏大的想法。他们告诉制作饼干的侏儒，侏儒做了一堆饼干。然后有一群人的工作是确保饼干运行。然后我们有过所有这些争论，说：“真酷。这些人中任何一个如何知道系统的其他部分？”
这个问题的部分答案也是邀请SRE，就像你应该邀请安全人员一样，参加你的架构会议、设计会议。你希望有人走进房间，走到白板前说：“你打算如何处理那里的信号指针故障？”因为他们已经见过这种配置失败14次了。
也许你当时不知道，当你把那个配置画在白板上时，我假设你不知道，但如果你能找到一个人来说：“嘿，这是我的经验”，并传递下去，那就太好了。所以我真的鼓励这样做。我还谈到花时间在其他团队也很好，可以说“我要去和……待在一起”。比如，带你的架构师去工作日，让他们和你待在一起。有些组织有这种内置机制，你基本上会在不同团队之间轮换，作为真正了解他人生活的方式。我认为这很棒。我认为这是实现正确事情的另一种方式。
Michael Stiefel：好吧，用一个稍微不同的例子来说明同样的想法：如果你想拥有能够非常迅速、非常频繁地发布更改的系统，你必须设计一个能够做到这一点的系统，因为你必须从本质上理解系统的耦合性。也许在SRE世界中有一些类似耦合的概念，架构师可以理解，如果他们想了解如何使系统更可靠、可用、对客户合理以得到他们想要的，使系统优雅降级等等，等等，他们应该考虑什么？
David Blank-Edelman：我想说，在SRE中我们称之为耦合。不像法国人对所有事物都有不同的词。我们同样理解紧耦合系统，或者有很多连接的事物。所以这是第一点。我认为对两组人都有用的另一点是，用已知的、非高度复杂的模块来构建东西，这样我们就可以推理这些模块以及它们之间的交互。如果我知道这个组件会这样表现，我理解它，我理解它的故障模式，我开始把它和其他东西放在一起，那么当它落到我手里时，对我来说更容易说：“哦，我明白了。这看起来像是那个组件的故障模式”，因为我见过这种情况。
但如果就像是：“嘿，我要给你一只你从未见过的动物，请照顾好它”，那就难多了。而不是说：“哦，我明白了。好吧，爬行动物。爬行动物需要这个和那个。”我知道我在这里左一个右一个地混合隐喻，但我主要想说的是，拥有可组合的、被充分理解的部件，并且被充分监测，这有很大帮助。如果你要耦合事物，请确保你很好地监测那个耦合点。
Michael Stiefel：这是一个重要的想法，因为如果你使用第三方系统，它们并不总是能让你完全了解所有故障模式。所以这听起来像是一个非常重要的原则：监测与第三方系统的连接点，监测聚合在一起的组件或部件，因为很可能你的真正故障会发生在那里。因为如果一个组件失败，现在我只是从架构的角度思考，如果你是为失败而设计，你总是理解一个组件可能失败。所以你对那个组件失败时会发生什么做出一些假设。你通常不理解的是多个组件之间的交互，以及/或者如何检测系统正在退化而不是完全失败。所以按照你的观点，更关键的是组件之间的交互，这比组件本身更难理解。
David Blank-Edelman：我不确定我是否会声称“更”关键，我会说“同样”重要。
Michael Stiefel：好的。
David Blank-Edelman：你明白我的意思吗？
Michael Stiefel：是的，是的，是的。
David Blank-Edelman：是这样的。我不认为监测中间部分必然会使两边工作得更好，但它可能会让你了解，当然，关于两个组件之间通信中发生的那类问题。我只是断言那是一类问题。
Michael Stiefel：好的。
David Blank-Edelman：我认为这真的非常重要。但如果你只盯着中间，从不看两边，你仍然会有问题，这就是我想说的。
事后审查的实用建议 [38:00]
Michael Stiefel：好的。那么我想讨论的最后一件事是，在发现系统故障、从近因出发并思考所有导致此事发生的原因的过程中，你对于必须提出的问题类型有什么想法吗？因为有些问题，例如，检察官喜欢问有是或否答案的问题，你通过问题的本质排除了某些事情，比如“你什么时候停止打你妻子的？”
David Blank-Edelman：对，对。我和我妻子都不太喜欢这个问题，奇怪的是。但我想说的是：所以在我的世界里，我们经常考虑事后审查，对吧？
Michael Stiefel：是的。
David Blank-Edelman：当你这么说时，我的思路就转到那里了。当你说这个时，我认为真正重要的是，在谈到“为什么”之前，先坚持“如何”和“什么”。我知道这听起来非常非常基础，但让我解释一下我的意思。在尝试达到“如何修复它？”和“问题是什么？”之前，尽可能多花时间描述发生了什么。如果你立即跳到“嘿，磁盘过载了”，那么你并没有真正了解“我们是如何检测到的？谁参与了？我们看到了什么？什么进展顺利？什么不顺利？”如果我们立即试图“修复它！”如果你立即转向修复它，那么你就跳过了一大堆可能有用的东西来学习。
现在，在中断期间，你可能希望在甚至不知道发生了什么的情况下就进行缓解。比如，“如果我能通过将所有流量转移到不同区域、回滚到之前的版本，即使不知道问题所在，也能停止客户的痛苦”，而不是说“好吧，我要花接下来的四五个小时试图找出错误在哪里”。所以在这种情况下，我想说的是，在深入“为什么”之前，先充分理解“如何”，因为人们真的喜欢跳到“好吧，酷。找到问题了，完成，再见，我走了。我拿到了我的修复项。我走了”。我只想说，这种行为会导致非常肤浅的审查，并且在进行这些审查时，你可能会陷入许多其他陷阱，但那种语言真的很重要，还有那种关注点。
你还听我批评过另一件事，那就是有些人非常、非常迷恋的“五个为什么”，人们说“哦，这是分析的一部分，你应该运行这五个为什么”，对于那些没听说过的人来说，你应该问：“好吧，问题是什么？”“嗯，服务器宕机了。”“好吧，为什么？”“嗯，因为磁盘空间用完了。”“为什么？”“嗯，因为……”我不知道。
Michael Stiefel：“缺少一个配置文件”。
David Blank-Edelman：“日志太多。”然后，“嗯，为什么有太多日志？”“嗯，因为清理系统没运行好。”“嗯，那是为什么？”“因为配置搞错了。”问题在于，当你试图这样做，并希望得到一个根本原因时，你已经忽略了一大堆东西。比如，“嗯，那个产生大量日志的东西，它有问题吗？我们是否应该知道你的东西是否在痛苦地尖叫，而你只看到了磁盘空间不足的事实？”所以对我来说，坚持什么是真实的。比如，“我们知道的所有事情是什么？我们知道什么？我们不知道什么？谁参与了？他们知道什么？”这类事情同样重要。就像你的飞行员例子。飞行员在那个时刻知道什么对我来说和他们是否拨动开关一样重要，因为这样我就能弄清楚，在给那些绝对需要情境和控制的人提供情境方面，我做得有多差。
Michael Stiefel：这几乎就像在犯罪现场，在开始归咎于人的动机之前，你想知道事实。“血在哪里？指纹在哪里？入口在哪里？”而不去担心“他们为什么从门进来而不是窗户？”
David Blank-Edelman：这本身就是一个有趣的问题。我认为“这个而不是那个”是一个更好的为什么，但事实上你注意到他们从窗户进来是很好的。比如“实际上发生了什么？”但如果你是：“显然他们开枪打了他”，然后你没有注意到还有另外三颗来自三把不同枪的弹壳。那么你的调查有多好？
Michael Stiefel：或者有一个非常聪明的罪犯，认为你会注意到子弹，但没看到毒药。那才是实际上……
David Blank-Edelman：对。我们又陷入了另一个类比集。
Michael Stiefel：但重点是，事情可能具有误导性。
David Blank-Edelman：嗯，不仅具有误导性，而且是在浪费，因为之前我们谈到的是，中断和失败可能导致时间、金钱、健康、声誉、招聘问题等方面的损失，或者它们可以帮助你提升水平。由你决定。如果你只是想经历同样的事情，每次发生这种情况，你都按下那个大红按钮，然后每次发生，你又按下那个大红按钮，每次你这样做都失去客户，完全取决于你。你自己做决定。但如果你能从中学习并意识到：“哦，等等。每次都是这样。我刚注意到这一点。让我们去修复那个东西，现在我们不再失去客户了。”由你决定是否利用这一点，并以此为基础提升。我很感兴趣教人们如何在他们做出决定后利用这一点。
架构师问卷 [43:10]
Michael Stiefel：在这一点上，我想问我的客人一些问题，让人性化访谈背后的人。
David Blank-Edelman：抱歉，他注意到我不是人。不管怎样，继续吧。抱歉。因为我取下了我的爬行动物面具。我以为我能戴着这个物种面具完成整个采访。好吧，很好。问吧。
Michael Stiefel：那是因为我在寻找根本原因。
David Blank-Edelman：听着，你不能永远用那个来嘲弄我。不是只有你一个人对我提根本原因。所以我对这个有点麻木了。
Michael Stiefel：那么你工作中最喜欢的部分是什么，作为一名SRE？
David Blank-Edelman：嗯，我的工作还包括为SRE、刚接触可靠性的人运行一个培训项目。所以我两个答案都可以给你。
Michael Stiefel：但你给出任何你想给的答案都可以。
David Blank-Edelman：嗯，我会两个都给你。我的意思是，带领人们，帮助人们理解如何提升水平，以及如何以真正服务他们的方式思考，这真的很有趣。我真的很喜欢这部分。关于SRE，真正有趣的是