如何从 DevOps 的角度出售技术债务？

人们常常戏剧性地、可悲地认为最好不要创造技术债务。是的，当然，没有它更好。但后果还是可以消除的。

我将技术债务指的是所有变化和改进、基础设施修改和流程变化、旨在消除差距的团队结构变化（在发布产品的框架内有意或无意地进行），以及随着时间的推移而产生极大干扰的功能。

由于如果没有生产和运营部门坚定而自信的团队合作，这些问题就无法解决，因此这个故事直接与 DevOps 相关。

技术债务——是谁的？

但首先，问题的根源 - 为什么我要谈论技术债务？因为我很生气企业不分配时间。这条红线贯穿于所有报告、聚会以及开发人员和运营人员之间的沟通。

邪恶、糟糕、糟糕的企业不会分配时间来处理技术债务。甚至出现了一个正义的问题：“他们根本不需要质量吗？”展望未来，我会说：“没有人需要质量。”但我稍后会透露这个想法。

为了分析这种情况，让我们考虑一下为什么企业要这样对我们。为了得到答案，我们需要思考谁是技术债务。谁对此负责？

经过多年的参与，我意识到我们就像佛罗多一样，为每个人提供了一枚戒指。就像是，“帮我承担这个重担！”我们正在等待企业希望（确实希望）我们处理技术债务。但我们与企业相互误解的根本原因是它永远不会愿意。

对我们来说，这是一项工程挑战，是一种提高产品卓越性的方法，甚至是一种增强我们产品自豪感的机制。但对于商业来说，这始终是一种麻烦，一种必须花费时间的必要之恶（或必需品）。

想象一下，你坐进出租车，司机问：“我可以在洗车处停车吗？”

在这种情况下，企业是客户，开发人员是出租车司机。

• 商家愤愤不平：“怎么会？！我付路费，你却去洗车！”

• 出租车司机合理地回答道：“你不想乘坐一辆干净、闻起来很香的车吗？”

• 商家回答：“伙计，我当然愿意！但我默认会这样，而且我现在还不准备为此而去洗车店！”

这就是企业对待技术债务的方式。这就像建议去洗车场一样。我在订购出租车时选择合适的类别以享受干净或豪华的沙龙。在订购阶段，我愿意投资，但去洗车店却不愿意。

因为，正如我之前所说，没有人想要质量。但默认情况下是预期的。

必须的。企业不能甘心不去洗车场，也不能牺牲自己的时间去洗车。那么我们该怎么办？企业是一个火车头。它需要功能、销售和客户。不可能通过我们的“我想要”和“我希望”把技术债卖给企业。但可以通过另一种方式来激励业务。

在我的旅程中，我形成了三类“购买”技术债务的商业动机：

• “胖子”冷漠。当有一个富有的投资者时，首席执行官就可以负担得起由怪异极客组成的开发团队。就像，“好吧，让他们去做吧！主要的事情是完成产品，团队精神很棒，一切都很酷，我们将成为世界上最好的办公室”。

  
  

  在我看来，这是一种很酷的自由风格，但往往会导致灾难，因为技术债务需要实用主义。当我们不务实地这样做时，我们就会创建一个伪酷建筑的利维坦。

• 害怕。这是最有效、最广泛、最高效的技术债务模型之一。当我们害怕的时候，我们能在这里谈论什么样的“想要”？这是关于当发生某些事情时，例如客户因故障或黑客攻击而离开。这都是因为质量低劣、刹车或其他原因造成的。但出于恐惧而直率地抛售也是不好的。带有恐惧的投机不利于信任。您需要尽可能谨慎、诚实地销售。

• 相信。这是指企业为您提供了足够多的时间来处理技术债务。只有当你小心翼翼地减少总份额并尽可能务实地利用这段时间时，信任才会发挥作用并得以保留。否则，信任就会被破坏。而且，它不会积累。一个持续的过程是波浪式的：信任增加然后消失。

接下来，我将讨论我的经验以及对我和我出色的团队有用的方法。

技术债务的兔子洞有多深？

三年前，当我加入新公司时，我需要了解这项技术债务有多少。我从请求统计中知道它的存在，包括来自企业和合作伙伴的请求。我需要弄清楚我一般在处理什么。

这是处理技术债务的正常且强制性的第一步。你不应该急于做你发现的第一件事。你应该对整个情况进行分析。

根据我当时所看到的情况，我假设根本问题之一是大量的代码耦合。现在，我较少让每个人参与这个过程，但当时，我聚集了整个生产团队来修复我们想要在应用程序套件中强调的层。

我们的应用程序至少有 80 个不同的组件（分发版，而不是安装版）。弄清楚情况后，就必须要处理了。

第一阶段：虚拟团队

由于非常聪明，我想出了一个想法：假装每个人都有时间，并围绕每个组件组建一个虚拟团队。它看起来就像是，“伙计们，谁将承担哪个组件？就如何改进它提出你们的建议。”但为了保持专注，我们共同制定了优化第一阶段的标准：

• 松耦合
• 经济高效的可扩展性
• 新开发人员轻松连接（简单明了的原则：这个组件到底能做什么、不能做什么，加上隔离那些不能被所有人“触及”的代码）
• 能够在需要时使用外部 API
• 拟议技术堆栈的可访问性
• 当前解决方案中的 QuickWin 优化
• 易于监控和故障排除
• 审核+许可纯度原则
• 版本控制和废弃原则

当然，这不是一个焦点，而是一套适用于软件开发几乎所有方面的标准。整个列表可以用一个短语来代替：“修复一切”。

这个阶段以惨败告终，从某种意义上说，什么也没发生。我们在实施某些事情方面进展甚微，因为我试图通过共享积压工作来计划它们。这些任务是难以理解的。他们被手动投入工作。我很快意识到这对我和团队来说都很困难，而且冲突和争论不断增加。

所以，我进入了第二阶段。

第 2 阶段：技术债务是我的

在第一阶段，我同意我们公司首席执行官的意见，我们将引入积压配额。我们将花费 70% 用于业务问题，15% 用于消除缺陷，15% 用于技术债务。

第二，在前一个阶段，我认识到如果一个问题每个人都有责任，那么这个问题就没有人负责了。这根本不是一个青绿色的声明。我自己也不喜欢。但相反需要非常高水平的成熟度和团队合作。这就是为什么我决定组建一个技术领导者体系。

但我不只是任命一个人作为一个组件的技术负责人。我尽可能地阐述了我的期望，明确了他们的发展道路，并让他们对生产情况负责。如果您的组件在生产过程中出现混乱，OPS 专家不会醒来。是你在努力解决这个问题。

我们就这样出发了。有技术领导者（负责人）和15%的技术债务配额（有时间）。但现实最终是什么样子呢？

我们遇到的第一件事是我们有金融科技、合规性和职责分离，即我和开发无法访问生产，并且根据定义无法拥有它。然而，我说，“伙计们，你们要对生产中的情况负责！”

给人们日志！

当你赋予人们责任时，请给他们手中的工具。这是我们与 OPS 专家一起做的第一件事，向技术人员提供日志，以便他们可以看到其组件的日志。

我们进行了真正的协作努力 - 我们迈向 DevOps 的第一步，其中运营和开发一起工作。漏洞利用设置了日志传输（Kibana等），而开发则必须确保日志不包含敏感信息（个人数据等）。

5%被认为是幸运的......

现实情况是，尽管有15%的配额，但每次冲刺都会出现一些业务危机和紧急注入，因为“合作伙伴现在需要它，否则他就会离开！”当然，这种技术债务首先被排除在冲刺之外——结果，我们的冲刺是 0%。

也有 15% 的冲刺，但我们平均只有 5-8% 的技术债务。这是一个大问题，因为程序员无法知道他将有多少时间来实现。

就我而言，我试图通过不懈地在所有团队上空放风筝来帮助解决这种情况。我们学会了收集每个冲刺的详细指标，我在最后查看了冲刺。

Sprint 黑客攻击是指系统性违反技术债务配额。如果在一个冲刺中没有达到配额，并不意味着一切都不好。确实，情况不同，需要灵活掌握。

但当它被系统地重复时，我聚集了生产专家，争论并解释了这是多么重要和不可接受，因为配额是商定的。在该模型中移动流程是我的日常工作。

它确实发生了变化，但现在我认为这种方法有其自身的重大缺陷。

该方法的局限性

产品负责人已经习惯了这样的事实：积压的工作都是他们的，所有任务都由他们协调：“配额是好的，但只有我们决定团队在这个技术债务配额中做什么！”

当开发人员提出重构、消除样板等任务（记住强连接性）时，他们会得到合乎逻辑的反应：“什么？！什么样板？我们在谈论什么？！”

结果，任务被那些可以称为技术债务但有条件对供应商有利的任务所取代。所以我必须采取强硬的态度，说：“技术债是我的！而且我主张将其计入每个产品团队的技术债中，计入每个冲刺的技术债配额中。”

我们就是这样生活的。尽管我们生活和工作正常，但不信任感却越来越强烈。当我们做某事而不告诉任何人它是什么，并且时间没有花在业务任务上时，每个人都不清楚我们带来了什么结果。

由于技术债务配额利用率的统计数据飙升，我们面临着无法开展大型项目的事实。此外，大型项目通常需要多个团队。这也是不可能的，因为每个产品团队都专注于其产品并生活在其现实中。不可能将它们固定在一个复杂的主题上。

此外，没有人将操作纳入冲刺中。他们没有像生产那样的冲刺和积压工作。他们忙于生产任务，但这并没有包含在总体计划中。当开发在这些小块技术债务中完成一些事情并推出到生产中时，它可能会在 OPS 的要求中保留相当长的一段时间。

因为他们确实没有时间，还有额外的任务，无法工作。

但尽管这种方法有负面影响，我们还是取得了很多成就。

通过这种方法我们取得了什么成果？

首先，我们建立了自动测试的肌肉量。通过大幅重新设计整个 CI 流程，我们使其成为一个我们不感到羞耻的文明流程。

其次，我们在许多组件中成功地实现了对意大利面条式代码的打击。

我们进行了模块化并减少了样板。即使出于恐惧，这些任务也不能卖给企业。如果您的产品中的技术差距包含这些问题并且您需要解决它们（如果存在，则需要首先完成），您甚至不需要尝试出售它们。这只能通过“技术债务 - 这是我的”模式，只能通过配额来完成。

我看到了很多尝试，并在第一阶段尝试自己做不同的事情。但没有成功。

确实，这种工作模式不可能持续很长时间。管理层给予您有限的全权委托，并信任您作为 CTO 和团队领导者。

第三阶段：合法项目

然后，我们启动了第三阶段——一个解决技术债务的“合法”项目。我们的假设是，我们正在摆脱封闭的配额，通过共同的产品积压进行规划（即产品所有者接受这些项目需要完成），并进行干净的销售。为了实现这一目标，我们做了两件事：

• 我尽可能地缩小了我们在这个项目框架内开始做的工作范围。

• 我对我们在生产中要争取的目标形成了具体的期望。这是对理想主义的完全拒绝，因为我们的任务应该尽可能务实、易于理解并且从业务角度对服务有用。

重要的一点是，我们有一种错觉，认为我们正在尝试计算技术债务的商业价值，尽管这很少可能。而如果仍然可以计算，那么我们就有了噩梦般的技术债！

正值比负值更适合商业。如果你说，“这个客户会离开。他带来了这么多钱”，那么在他离开之前，这是行不通的。这不是商业价值。而且，与风险共事的文化还不是很高，所以模式是：“不走就没有损失”。

也没有必要展示商业价值。你可以在哪里展示它，但你可以展示技术价值，只是它必须被计算。

如何出售技术债务指南

这是此阶段出售技术债务的整个工作流程。

选择一个重点领域（仅一个）

由于这是通过恐惧进行销售，因此请选择一个真正影响您业务的领域。这些领域可能有所不同：可用性、返工速度、A/B 测试和实验的安全性以及返工成本。有大量的领域和主题。

就我而言，我选择了可访问性，因为它受到了企业的关注，并且对我们的服务产生了一些影响。重要的是不要分散注意力并只选择一个主题。

进行积分分析

我分析了这一年的可用性和事件统计数据，并详细分析了全年发生的所有情况的所有事后分析。之后，我对我们需要在技术上尽可能多地开展工作形成了顶层理解，但同样是实质性的。

可用性的首要规则不是尝试构建一个始终可用的系统，而是在发生事件时做好准备。这就是我们必须确保的。

可用性的第二个问题和基本规则是降级协议：总有一天会发生一些事情，您必须准备好保留您的服务，也许以放弃您提供的某些功能为代价。必须维持这一协议，包括在计划层面。

第三个问题涉及监测和可观察性。这就是事件源的快速定位和响应检测时间。如果你有很多不稳定的测试，你将不得不停止信任你的监控。如果您的生产测试有服务台反应的说明，例如“如果 5 分钟内没有消失，请给我打电话” - 您没有监控生产情况。测试应该尽可能明确：“它显示 - 这意味着某处有问题，我们走吧！”

逐个组件进行分析

为此，我们已经确定了每个方向和组件具体要做的事情。我们的意思是我们将把服务网格拖到哪里，我们将如何改变监控，以及基于什么。这里，我们列出了大约15%，但实际上，还有很多程序改进。

我们已经把一切都准备好了，但还没有上市。现在要出去公开展示，我们对这一阶段的每个项目都做了以下工作。

制定实质性、量化指标

我们非常害怕量化指标：如何用量化指标来衡量开发者的工作质量？我们对量化指标有很多反对意见，但我们不应该正面对待它们。

价值不应仅被视为商业价值。例如，它们可以表述为“不超过 X 个误报”。

您可以列出一组特定的组件，对于这些组件来说，提供金丝雀版本或确保补丁回滚的能力至关重要。当然，总体可用性应该是一个定量指标。必须的。

捍卫项目

有了这组务实的项目，尽可能清晰的指标和我们需要实现的结果，我说：“伙计们，我需要一定的技术债务配额。我需要你们将这些项目纳入你们的项目池中，以加速它们的发展，以便它们能够实现。”在完全合法的基础上与业务目标一起进行总体规划。”

我们听到了，我们做到了，而且成功了。我认为这就像如何画猫头鹰的视频：“画一个椭圆形和两条破折号。”最后——魔法——你得到了一只猫头鹰！但最神奇的是，你必须钉牢整个项目并完成它。

不仅仅是朝这个方向做一些事情，而是要带来结果。即达到规定的量化指标并表现出来。这个深渊95%的时间都无法跨越。必须完全跳跃。

该方法的优点

于是，我们开始跳跃（越过深渊）。我们正在成功地做到这一点。现在，我们正在进行这个项目的第二轮。就是说我们拖了第一池的项目，同意了第二池的项目。发生了什么变化？

增加信任

如果我们展示真实的、可量化的指标，信任就会通过开放而得到强有力的增强。但事实是，技术债务出售是出于恐惧。这一步是无法避免的。但您也不必为此感到害怕或羞耻。最主要的不是推测恐惧，而是真正分析它，正如我在不同阶段（整体分析、逐个组件分析）所示的那样。

做大项目

由于这些现在都是合法的项目，我们可以跨团队同步并完成真正的大项目。有些项目是从一个冲刺到另一个冲刺按顺序完成的。我们在该项目中定期（每周一次）由技术团队的组成进行跟踪，并了解谁在哪里（在哪个阶段）。

这些信息尽可能公开和透明。项目的进度和当前状态已发布并可供产品所有者（以及任何其他想要查看的人）使用。

项目中的 OPS 人员

最重要的是，我们意识到我们在基础设施和推出过程中需要重新设计很多东西。 OPS 人员明确包含在该项目中。

在我看来，当 OPS 人员与开发人员讨论如何更改组件的架构，以及开发人员与 OPS 人员讨论如何最好地更改基础设施时，这比 Kubernetes 和 Docker 更像是 DevOps。

我为什么不立即做呢？

在这里，我们回到我在第二阶段结束时所说的：以前是行不通的。因为我们在第二阶段所做的事情（我们重新设计的意大利面条代码、测试的增强以及 CI 流程的重新设计）不可能向业务部门推销可衡量的指标。

这种情况并没有映射到任何特定的恐惧，我们的标准论点是，“我们花了很长时间来编码，因为意大利面条代码”——业内没有人倾听。因此，我们将无法继续采用这种方法。

在我看来，如果你有一个需要如此深入的基础设施改造的技术平台，你就无法避免第二阶段。

你必须全力以赴，但你不仅要做好准备，不仅要像风筝一样一直飘来飘去，还要尽快关闭这家商店，以免失去企业的信任。