您将收获您所编写的代码

这是我在新冠肺炎时代的在线会议--荒岛DevOps夏季送行上的一份松散的讲稿。它有一个非常特别的地方，那就是整个会议都是通过动物穿越视频游戏进行的，设置相当有趣。

这是本赛季最后一次这样的会议，我被邀请去演讲，几乎没有什么要求。我决定将我考虑了近一年的一场演讲压缩成一个版本，并安排了至少一次面对面的会议，这场会议在4月份被取消/报道，并在工作中完成了长达一小时的内部会议。最后的结果是一个简短的30分钟，涉及到各种话题，其中一些是借用了我之前的演讲和博客帖子。

如果我真的想这样做，我可能会在每一两张幻灯片中写一篇更短的博客帖子，但我决定追求覆盖面，而不是深度。这里什么都没有。

因此，今天我想谈谈作为软件开发人员和工程师，我们编写代码和部署东西的趋势，这种趋势最终会给我们带来巨大的痛苦，而这种痛苦是我们没有计划到的。

在软件中，一个令人愉快的惊喜是不编译一次就写了一个小时，然后它就可以工作了；一个令人讨厌的惊喜是似乎可以工作的软件，6个月后你会发现它毒害了你的生活。

这场演讲将是一场高水平的活动，我想警告你们，我将首先讨论一些哲学问题，然后再进行人类因素和认知科学方面的研究，并将其与广泛的建议联系起来，我认为这些建议在系统思考和设计东西时可能对每个人都有用。其中很多内容可能感觉有点过时，但我希望到最后它会对您有所帮助。

这才是我们要开始研究的真正有哲理的东西。伊万·伊里奇是个狂野的哲学家，他讨厌现代医学和义务教育之类的东西。他写了一篇名为“权力与公平”的文章(我是通过读斯蒂芬·克雷尔的一篇演讲而被介绍到这篇文章的)，在这篇文章中，他决定也不喜欢各种机动化交通工具。

伊万·伊利奇斯引入了压迫性垄断的概念；如果我们看看那些以步行和骑自行车为目的的社会，你通常可以使用任何交通工具，并有效地设法在那里生活和发展。无论你是住在帐篷里还是住在豪宅里，你都可以四处走动。

他指出，骑自行车天生就是公平的，因为它不需要超过作为操作基线所需的能量：如果你能走路，你就可以骑自行车，而骑自行车的能量与步行相同，效率高得令人难以置信。汽车没有这一点；它们相当昂贵，而且与普通人相比，需要的能源数量不成比例。

他的建议是，所有非货运交通工具，无论是汽车还是公交车和火车，都应该被限制在比骑自行车的人的平均速度高出固定百分比的水平，这是基于正常人体自身能够产生的能量。他建议我们这样做是为了防止..。

我们很容易把汽车想象成减轻现有负担的方式：它创造了自由，拓宽了我们接触货物和人员的途径。这是一匹更好的马，也是一辆不那么消耗体力的自行车。因此，社会将发展到在其基础设施中拥抱汽车。

现在，每个人的工作不再是让商家把商品送到城镇广场，送牛奶的人把牛奶放在门廊上，把市场缩小到离他们方便的地方更近的地方，而是每个人都开着车去买这些东西，而商店则去土地便宜的地方，而不是人多的地方。当社会在考虑到汽车的情况下发展时，你现在需要一辆汽车才能发挥作用。

简而言之，参与社会的成本上升了，这就是压迫性垄断。

对我来说，伊里奇所做的关键是将问题扭转为另一种方式：如果大多数人拥有汽车，会对社会产生什么影响，对我们其他人又会产生什么影响？

我现在想问的问题是，我们在软件世界中是否有类似的东西。有哪些事情我们认为可以提高我们做事的能力，但最终却让我们付出了更多的代价来参与其中呢？我们认为这些事情会提高我们的做事能力，但最终却会让我们付出更多的代价才能参与其中？

我们可以通过我们使用用户可能拥有的所有带宽的能力来认识到这一点；如今，试图使用旧的拨号连接是完全不可行的。但是我们的认知成本也是一样的吗？工具，文档，程序？

我对这些都没有明确的答案，但这是我在设计工具和软件时经常问自己的一个问题。

关键的一点是，我们选择使用的软件和实践不仅仅是我们在真空中做的事情，而是生态系统的一部分；无论我们向其中添加什么，都会以我们无法控制的方式改变和改变预期，并再次影响我们。软件不是被我们困住了，我们是被软件困住了。

难道我们最终不会因此而使我们的生活变得更糟吗？我想把重点放在这一点上，在这一点上，我们作为开发人员，让自己的生活变得更糟。当我们编写或采用软件来帮助自己，但最终却在这个过程中伤害了自己，因为这说明了我们自己的可持续性。

在这里，我不只是哲学上的，我想让现实世界中的事情产生实际的效果。因为这是研究人员已经研究过的东西。自动化的讽刺之处是认知研究(Bainbridge，1983)的一部分，该研究调查了人们自动执行任务的情况，发现其效果并不像预期的那么好。

主要是注意力与实践的冲突。这些年来有很多这样的例子，但让我们来看看现代的自动驾驶汽车。

自动驾驶汽车是笨拙的自动化的绝佳案例。汽车行业中最老牌的参与者正在做的是车道跟踪、盲点检测和处理平行停车。

但高科技公司(特斯拉、Waymo、优步)正在努力实现全自动驾驶，特斯拉的自动驾驶仪是向公众发布的最雄心勃勃的一款。但所有这些现在都是按照班布里奇在1983年完全预测的方式运作的：

司机不再积极参与，而是转变为监视角色

尽管司机不再驾驶汽车，但他必须充分意识到汽车正在做的每一件事。

当汽车处于一种奇怪的情况时，预计司机会再次控制。

因此，汽车可以处理所有简单的情况，但所有困难的情况都留给了司机。

这样做的部分风险是双重的：人们对他们没有参与的任务的注意力有限--如果你不积极驾驶它，你将很难长时间专心；如果你只在最糟糕的情况下很少开车，你可能会缺乏应对最糟糕情况的练习。

这样的自动化是在航空公司完成的，否则他们会在模拟器时间内弥补这一点，并且仍然手动处理计划中的困难区域，如起飞和降落。尽管如此，一系列航空公司事件发现，这种交接往往很复杂，进展不顺利。

显然，当我们忽略人的部分及其在事物中的责任时，我们可能会使软件变得比原来更糟糕。

一般说来，这些错误大多来自以下观点。这被称为Fitts&34；模型，也称为"；Haba-Maba&34；，因为"；人更擅长，机器更擅长"；(最初的版本称为Maba-Maba，使用的是人而不是人)。这个模型把人类描绘成能够判断的缓慢的、敏锐的生物，而机器是快速的、无法辨别的、永不疲倦的东西。

即使在今天，我们也经常听到这样的话。礼貌地说，这些都是自动化设计的初学者方法。它基于过时的科学概念，直观但错误的情绪，令人欣慰的是，它让你认为只有预测的结果才会发生，而完全忽略了任何紧急行为。它是根据我们认为我们现在看到的东西运作的，而不是基于更强有力的基本原则，而且当它在实践中应用时，往往有很强的局限性。

它与人机交互的现实脱节，当选择不是人与机器交互时，它会将选择框定为二元选择，目的通常是在你不应该的时候把人赶出方程式。简而言之，这是自动化具有讽刺意味的背后的一个重要因素。

这里是一个由认知专家建立的补丁版本。相反，他们将人机关系重新构建为联合认知系统，这意味着，我们不应将人类和机器视为必须在不同环境中用于特定任务的无关事物，而应将人类和计算机视为共同工作的团队伙伴。简而言之，这就将话语从一个人如何局限于一个人如何补充另一个人的角度转移到了另一个人身上。

团队成员会做一些事情，比如相互预测，分享上下文和语言，能够注意到自己的行为可能会影响他人并做出相应的调整，沟通以建立共同点，并对每个人的个人和共同目标有一个想法，以便能够适当地帮助他人或确定优先顺序。

当然，我们必须承认，作为当今最先进的队友，我们离计算机还很遥远。由于目前的计算机需要我们一直重新调整它们，我们必须承认，系统不仅仅是代码和计算机，它还包括代码、计算机以及所有与它们和彼此交互的人。如果我们想要我们的软件帮助我们，我们需要能够帮助它，并且帮助它，这意味着软件需要知道它会充满局限性，并让我们努力使其更容易诊断问题，形成和改进心理模型。

所以问题是：是什么造就了一个好的模式？我们怎样才能帮助人们使用我们创造的东西呢？

注：这张幻灯片和下一张幻灯片摘自我关于可操作软件的演讲。

这是一张英国伦敦市的地图。它不是伦敦城，只是它的代表。它非常准确：它有街道的名称、交通方向、建筑物名称、河流、火车站、地铁站、人行桥、码头、公园，给出了关于规模、距离等的详细信息。但它不是伦敦市本身：它不会显示交通或道路施工情况，也不会显示生活在那里的人，也不会告诉你哪里有好的餐厅。这是一个有限的型号，而且可能是过时的。

但是，即使它真的很有限，它也是非常详细的。细节足够详细，几乎每个人都不能把它全部装进自己的脑子里。大多数人会对它的某些部分有一些详细的了解，比如图像中放大的方块，但几乎没有人会只知道所有维度的全部内容。

简而言之，您系统中的几乎每个人都只是从部分、不完整、经常不准确和过时的数据开始工作，而这些数据本身只是系统中发生的事情的抽象表示。事实上，我们使用的可能更类似于以下内容：

这更像是一件事。这仍然不是伦敦市，但这张伦敦旅游地图更接近我们的工作。看看你的架构图(如果你有的话)，它们很可能看起来更像这张地图，而不是非常详细的伦敦地图。这张地图有游客想看的大多数东西：重要的建筑，到达那里的主要动脉，以及一些建议如何导航的路径。这张地图没有清晰的比例尺，我很肯定在伯罗路上的两个巨人不适合大本钟。还有很多未定义的领域，但您可能会用其他资源来补充它们。

但这没关系，因为心理模型和它们的预测能力一样好；如果它们能让你正确地做出决定或完成一项任务，它们就是有用的。我们的头脑有点聪明，因为他们只会根据需要建立复杂的模型。如果我是一个在主要景点之间寻找路线的游客，这张地图可能比另一张要有用得多。

关于这一点有一句有趣的话：一些东西只有在它被打破后才会存在。从主观上讲，你可以完全满足于长时间运行一个系统，而不知道它的所有方面。当它们开始崩溃，或者你对系统的预测不再起作用时，你就不得不回去重新调整你的心理模型。由于这些都是非常主观的，所以每个人都有不同的模式。

对于什么是好的模式，这是一个模糊的答案，后续的问题是我们如何创建和维护它们？

在所有技术组件之外，一个简单的步骤是挑战和帮助彼此，以同步和建立更好的心理模型。我们不能轻易地将我们自己的模型相互转换，事实上，控制它们几乎是不可能的。我们能做的就是挑战他们，确保他们没有被太多侵蚀，并尝试一些事情来确保他们仍然是准确的，因为事情会随着时间的推移而变化。

因此，在一家公司中，我们可能做的事情包括培训、文档记录、事件调查，所有这些都有助于向每个人展示我们系统的各个方面和更改。游戏日和混沌工程学也是发现我们的模型在受控环境下可能被破坏的极好方法。

它们绝对是我们应该做和关心的事情，特别是在组织层面。这就是说，我想更多地关注我们作为个人可以做的技术工作。

我们不能仅仅打开一块所谓的玻璃窗，就能一下子看到所有的东西。那是太多的噪音，太多的信息，太少的结构。只有知道要过滤和过滤掉什么的人才能看到一切。你不可能一下子就形成一个事事的心理模型。为了辅助模型的形成，我们应该构造可观测性来讲述故事。

您使用的大多数易于操作的应用程序和组件都不会向您公开它们的内部结构，它们的主要目的是提供对您与它们交互的可见性。用户正在做的事情与它在系统中或对系统产生的影响之间必须存在联系，您将希望建立这种联系。这意味着：

记录在您想要调试的下面的层，这样可以节省时间以及需要在代码库中插入多少可观察性探测。我们倾向于将一切都停留在应用程序层面，但这是被误导的。

这意味着给定端点周围的日志必须是关于用户与该端点的交互的，并且不需要了解其实现细节。

对于开发人员日志，您可以通过将一条日志语句插入框架内端点下方的一层来使其由所有控制器共享，而不必为每个端点插入一条日志语句。

这些互动将让人们在脑海中描绘出应该发生的事情，并更容易发现期望被打破的地方。通过分层视图，您可以根据预期被打破的层和它们拥有的知识在各层之间跳过。

在某一层不能轻易观察到的地方，人们必须通过其上下各层的推论来处理。它成了一种障碍。

通常，我们只能在最高级别(应用程序)或最低级别(操作系统)保持可观察性，两者之间几乎没有什么有用的东西。我们有一个黑盒三明治，我们只能看到某些部分，这可能是我们选择的工具的结果。您将希望实际选择运行时、语言和框架，以及允许您讲述可观察性故事并对其进行适当分层的基础设施。

帮助模型形成的另一件事是保持人与机器之间的关系顺畅。这是一种信任关系，提供被认为具有误导性或无益的信息会削弱这种信任。有几件事你可以用日志来做，它们可以帮助你不会毁了你与电脑的婚姻。

主要是记录事实，而不是解释。您通常无法从单个日志行中获得所有上下文，只是其中的一小部分。如果你开始试图提供帮助，并向人们提供建议，你就会把收集事实的探险转变为谋杀-神秘的调查，在这种调查中，系统的一些部分不能被信任，或者你不得不在字里行间胡思乱想。那是没有用的。显示TLS验证错误：SEC_ERROR_UNKNOWN_ISSUER的日志行比显示错误：无论您有多少经验都被黑客攻击的日志行要好得多。

结构化日志记录对此有帮助，它比常规文本更好。它使人们更容易使用脚本或程序来解析、聚合、路由和转换日志。它使您不需要全文搜索来找出发生了什么。如果您确实想提供人类可读的文本或解释，请将其添加到结构化日志记录中的字段中。

还有一件事叫做必备变化法则，它说只有复杂性才能控制复杂性。如果一个代理人不能代表它试图控制的事物周围的所有可能的状态和情况，那么它就不能控制所有的事情。想一想一架飞机的飞行稳定器；它们只能进行有限的调整，而且通常比我们人类的调整速度更快。不幸的是，一旦它的行动和所能感知的事物达到一定的极限，它就不能正常工作了。

这就是控制要么无效，要么转嫁给下一个最好的东西的时候。就我们运行和运营的软件而言，那就是我们，我们是第二好的。在这里，我们陷入了一种古老的想法，即如果你尽可能聪明地写东西，你就有麻烦了，因为你需要加倍聪明才能调试它。

这是因为要调试一个在自动化下行为不正常的系统，您需要了解系统，然后了解自动化，然后了解自动化对系统的看法，然后采取行动。

这总是有些问题，但本质上，脆弱的自动化迫使你比没有自动化的情况下知道更多，以便让事情在困难时期工作。然后，情况可能会变得比一开始没有自动化的情况更糟糕。

当您开始创建解决方案时，要意识到它可能会变得脆弱，需要将控制权交给人。关注自动化出现故障的路径以及交接将如何进行。你将如何传达这一点，以及操作员将不得不采取哪些线索或行动来接管事情？

当我们接受并假设自动化将达到其极限，而它所做的事情就是向人类寻求帮助时，我们就转向了自动化。让这条可切换的路径更容易工作。让它变得友好，并使人类有可能了解自动化在给定时间点的状态，这样您就可以弄清楚它在做什么，以及如何解决它。使引导自动化做正确的事情成为可能。

一旦您找到了解决方案的方法，您就可以逐步实现自动化，扩展解决方案，并与这些需求保持一致。它是糟糕经历的后盾，类似于让代码崩溃，所以做好它是关键。

我认为另一件有趣的事情是路缘切割效应。路缘切割效应是从60年代开始的各种关于无障碍的美国法律中被注意到的。这个想法是为了让坐轮椅的人可以进入人行道和街道，你可以削减。

.