iOS版下载
安卓版下载
这是第二场比赛，华盛顿国民队出现了问题。当然不是在球场上：即将成为世界大赛冠军的选手们表现得很好。但就在他们等待下雨延迟的时候，幕后出了问题。团队分析基础架构中的一个任务调度程序停止运行。
调度人员负责为国民队的分析团队收集和汇总比赛时间数据。像许多同类工具一样，这一工具是基于cron的，这是一种有几十年历史的定期调度工具。当工作需要在特定的一天、一小时或一分钟开始时，Cron的工作效果特别好。当工作需要与下雨推迟的棒球比赛同时开始时，它的效果尤其糟糕——或者根本不起作用。尽管数据团队尽了最大努力将自定义逻辑添加到简单的调度程序中，但双头的情况让它感到困惑……它只是停止了对新工作的调度。
直到第二天，一位分析师才意识到这一差异，因为数据——构成球队赛后分析和建议基础的关键数字——没有包括一场特别令人难忘的比赛。没有任何警告或红灯，因为这个过程根本没有运行。因此，数据分析堆栈中增加了一项新的、耗时的活动：每天早上手动检查数据库，以确保一切正常。
这不是一个灾难性失败的故事。事实上，我确信任何读到这篇文章的工程师都能想出无数种方法来解决这个特殊的问题。但很少有工程师会发现提前坐下来对每一个边缘案例进行头脑风暴是一种很好的时间利用方式，甚至不可能主动预测数十亿的潜在故障。事实上，工程师们有足够多的紧迫问题需要担心，而不会出现新的错误。
因此，这里的问题不在于发生了错误。即使在最复杂的基础设施中，也总是会出现错误。真正的问题是团队解决这个问题的选择有多有限。面对一个关键的商业问题和一个欺骗性的原因，他们被迫浪费时间、精力和人才，以确保这个意想不到的怪癖不会再次出现。
负向工程是“保险即代码”
那么，什么是更好的解决方案呢？我认为这类似于代码的风险管理，或者更简洁地说，是负面工程。消极工程是工程师为确保其主要目标的成功而进行的耗时且有时令人沮丧的工作。如果将积极工程视为工程师为实现富有成效的预期成果所做的日常工作，那么消极工程就是通过保护这些成果免受无限可能失败的影响来保护这些成果的保险。
毕竟，即使在一个精心设计的系统中，我们也必须对失败负责。大多数现代软件都包含了一定程度的重大错误预期，或者至少包含了错误恢复能力。与此同时，负面工程框架更进一步：它们允许用户处理故障，而不是对抗故障。故障实际上成为应用程序的一级组成部分。
你可能会考虑像汽车保险这样的负向工程。购买汽车保险不会防止你发生事故，但它可以大大减轻这样做的负担。同样，当出现问题时，拥有适当的仪器、可观察性，甚至代码的编排，可以提供类似的好处。
“保险即代码”可能看起来是一个奇怪的概念，但它非常恰当地描述了负面工程工具如何提供价值：它们确保了正面工程工具所能实现的结果。这就是为什么调度或重试等看似玩具般的功能——也就是说，过于简单或初级的功能——可能至关重要：它们是用户将期望输入保险框架的手段。它们越简单（换句话说，就越容易利用它们），保险成本就越低。
例如，在应用程序中，重试失败的代码是一项关键操作。用户所采取的每一步都反映在代码中的某个位置；如果该代码的执行被中断，用户的体验将从根本上被破坏。想象一下，如果一个应用程序时不时地拒绝向你的购物车添加商品、导航到某个页面或向你的信用卡收费，你会多么沮丧。事实是，这些小的拒绝经常发生，但用户永远不会知道，因为系统致力于拦截这些错误并再次运行错误代码。
对于工程师来说，这些重试机制可能看起来相对简单：“只需”隔离出现错误的代码块，并再次执行。对用户来说，它们形成了实现其目的的产品和从未赢得他们信任的产品之间的区别。
在任务关键型分析管道中，捕获和重试错误代码的重要性被放大了，对负面工程也需要类似的复杂方法。在这个领域，错误不会导致用户丢失购物车中的项目，而是导致企业根据不良数据制定策略。理想情况下，这些公司可以快速修改代码，以识别和减轻故障情况。采用正确的工具或技术越困难，想要实现这些工具或技术的工程团队的“集成税”就越高。这项税收相当于支付高昂的保险费。
但是，超越一个功能并提供保险般的价值意味着什么？考虑一下日程安排的日常活动：一个将事情安排在上午9点运行的工具是一种廉价的商品，但一个警告你上午9点进程未能运行的工具却是基础设施的关键部分。使用负面工程框架的一个主要优势是通过使用商品特征来推动防御性见解，从而提升商品特征。从某种意义上说，这些“琐碎”的功能成为向保险层传递指令的手段。通过更好地表达他们期望发生的事情，工程师可以更了解与该计划的任何偏差。
为了更进一步，请考虑“识别故障”到底意味着什么。如果一个进程在崩溃的机器上运行，它甚至可能没有机会在它消失之前通知任何人它自己的故障。一个只能捕获错误消息的系统甚至永远不会发现它失败了。相比之下，一个对成功有明确期望的框架可以推断，当这个期望没有得到满足时，这个过程就失败了。这通过围绕预期成功的缺失创建逻辑，而不是等待可观察到的失败，实现了新的置信度。
为什么是负面工程？因为事情会发生
对于大公司来说，宣称其数据堆栈的复杂性是一种时尚。但事实是，大多数团队——即使是那些执行复杂分析的团队——都使用相对简单的堆栈，这些堆栈是在重大资源限制下做出的一系列务实决策的产物。这些工程师没有足够的时间来实现他们的商业目标和思考每一种失败模式。
更重要的是，工程师讨厌处理失败，而且没有人真正期望自己的代码失败。再加上负面的工程问题往往源于最普通的功能——重试、日程安排等——很容易理解为什么工程团队会决定掩盖这类工作，或者将其视为他人的问题。这似乎不值得花费时间和精力。
在某种程度上，工程团队确实认识到了这个问题，我在实践中看到的最常见的方法之一是制作创可贴和胶带的雕塑：这是一百万个微小补丁的复合总和，而不考虑总体设计。在巨石的重量下颤抖的是一个过度劳累、资源不足的数据工程师团队，他们把所有的时间都花在监控和试验同事失败的工作流程上。
受FAANG启发的通用数据平台被宣传为解决这一问题的方案，但却没有意识到在仍在努力实现工程稳定性的企业中部署影响深远的解决方案的巨大成本。毕竟，他们都没有FAANG规模的工程团队。为了避免高昂的整合税，公司应该在特定方法的潜在好处与实施该方法的不便之间取得平衡。
但问题是：与负面工程相关的任务通常来自软件的主要目的之外，或者与外部系统相关：速率受限的API、格式错误的数据、意外的null、工作崩溃、缺少依赖项、超时的查询、版本不匹配、错过计划等等。事实上，由于工程师几乎总是在自己的代码中解释最明显的错误来源，因此这些问题更有可能来自意外或外部来源。
人们很容易忽视小错误的破坏性潜力，因为人们没有意识到它们将如何以难以理解的方式、在不方便的时候或在没有做好正确解释准备的人的屏幕上表现出来。例如，一个供应商的API中的一个小问题可能会触发内部数据库的重大崩溃。一行格式错误的数据可能会极大地扭曲驱动业务决策的汇总统计信息。微小的数据问题可能会导致“蝴蝶效应”造成不成比例的损害。
另一个简单修复和级联故障的故事
以下故事最初是作为一个挑战与我分享的，好像在问，“太好了，但一个消极的工程系统怎么可能帮助解决这个问题？”场景如下：另一个数据团队——这次是在一家高增长的初创公司——在管理一个高级分析堆栈时，他们的整个基础设施突然完全失败了。有人注意到一份报告中充满了错误，当五名工程师组成的团队开始调查时，他们几乎在堆栈的每一层都收到了大量的错误信息。
从坏掉的仪表板开始，逆向工作，团队发现了一个又一个神秘的错误，就好像管道的每一步不仅无法完成任务，而且实际上都在完全混乱中举手。团队最终意识到，这是因为每个阶段都将自己的失败传递给下一阶段，就好像这是预期的数据一样，导致每个步骤都试图处理根本无法处理的输入，从而导致不可预测的失败。
该团队需要三天的数字考古才能发现催化剂：其一家SaaS供应商的信用卡已经过期。供应商的API在管道中相对较早地被访问，由此产生的计费错误在随后的每个阶段都会猛烈地传播，最终污染了仪表板。在几分钟内，团队就解决了问题。
再一次，一个微不足道的外部催化剂对企业造成了严重破坏，产生了非同寻常的影响。事后看来，情况非常简单，以至于我被要求不要透露相关公司或供应商的名称。（让任何从未遇到过简单问题的工程师先下第一块石头吧！）这种情况没有什么是复杂的，甚至是困难的，前提是要意识到根本问题并有能力解决它。事实上，尽管它看起来很不寻常，但这实际上是一种相当典型的负面工程情况。
一个消极的工程框架不能神奇地解决像这个这样特殊的问题——至少不能通过更新信用卡——但它可以包含它。一个正确检测的工作流会识别根本故障，并阻止下游任务执行，因为它知道这些任务只会导致后续错误。除了依赖性管理之外，具有明确的可观察性的影响同样非同寻常：总的来说，团队浪费了15个人天的时间来测试这个问题。即时了解根本错误可以将整个停机及其解决方案减少到最多几分钟，这意味着生产力提高了99%以上。
记住：他们所要做的就是输入一个新的信用卡号。
恢复生产力
任何其他名称的“负工程”仍然同样令人沮丧——它还有很多其他名称。我最近采访了一位前IBM工程师，他告诉我，早在90年代，IBM的一本红皮书就指出，任何软件的“快乐之路”都不到其代码的20%；其余部分专门用于错误处理和恢复能力。这反映了现代工程师报告用于试验负面工程问题的时间比例——高达他们工作时间的90%，令人震惊。
这似乎几乎令人难以置信：数据科学家和工程师怎么能在琐碎的问题上浪费这么多时间来处理世界上最复杂的分析？但这正是这类问题的本质。看似简单的问题在不受控制地传播时，可能会产生意想不到的时间破坏性后果。
出于这个原因，公司可以在关注负面工程方面找到巨大的杠杆作用。如果选择将模型开发时间减少5%或将跟踪错误的时间减少5%，大多数公司会天真地选择模型开发，因为它具有感知到的商业价值。但在一个工程师90%的时间都花在负面工程问题上的世界里，专注于减少错误的影响力可能是前者的10倍。考虑一下，将这些负工程时间减少10%——从90%的时间减少到80%——将使生产率从10%翻倍到20%。这是一个相对较小的动作带来的非凡收获，完美地反映了这些框架的工作方式。
采取小步骤来解决负面的工程问题可以带来巨大的生产力胜利，而不是小错误成为主要障碍。
App Store
Android
