应对 DevOps 中的技术债务:创新与稳定性的微妙平衡

本贴最后更新于 304 天前,其中的信息可能已经东海扬尘

技术性债务在 DevOps 到底意味着什么?从本质上讲,这是小的开发缺陷的积累,需要不断地返工。它可能由多种原因引起,例如快速交付新功能的压力,这可能会导致团队不得不牺牲代码的整洁和完善。但这些不完整的小代码,如经济上的债务一样,随着时间的推移会产生“利息”,在软件工程里就表现为修改的挑战或添加新功能的困难。

一、技术债务的原因

技术债务的主要原因之一是组织的开发方和业务方之间的脱节。开发团队经常会感到保持高特性速度的压力,有时会以适当的服务规划为代价。例如,不计划服务生命周期的结束可能会导致所谓的“老年服务”。这些服务可能做得不多,但对业务运营至关重要,并且可能在以后产生更多的技术债务。它们可能很难迁移,也可能是未知影子或僵尸 API 的产物。结果是,开发过程可能会被更高效的工作方式所阻碍,从而招致更多的技术债务。

二、技术债务的症状

没有严格的监控,技术债务可能会减缓整个开发和部署过程,降低产品质量,并限制组织在不断变化的市场中进行创新的能力。技术债务过多的一些迹象可能包括修复技术债务的成本和时间增加,每次发布和部署所需的时间持续增加,以及由于在遗留系统上工作和处理频繁故障带来的挫折,让员工的流动率更高。

三、什么情况下可以忽视技术债务?

虽然技术债务的负面影响是真实存在的,但并不总是需要立即解决,而且这也并不现实。在一些情况下,让债务累积是有意义的。例如,如果解决技术债务的成本在当下大大高于将来,如果债务没有影响短期业务需求,或者有紧急版本发布(如重大安全漏洞修复程序)。在做出正确的权衡时,牢记全局至关重要,管理良好的技术债务是缩短交付周期的有效工具,可以优先考虑重要部署。

这里存在一个关键点:区分“好的”技术债务和“坏的”技术债的上下文。这种分离归结为理解对客户和团队的实际影响。忽略一些技术债务毕竟并没有那么糟糕,只要有有共同的上下文来指导自己的决策就好。

四、忽视技术债务成为挑战

当技术债务开始阻碍组织有效运作的能力时,忽视技术债务就成了问题。当这种情况发生时,就是需要解决技术债务的明显信号了。如果不加以解决,累积的技术债务可能导致经营业绩不佳和收入损失,从这个本质上来说,技术债务也成为了经济债务。产品和品牌的形象可能会受损,导致失去机会。

五、管理技术债务

管理技术债务需要采取积极主动的协作方法。以下是一些可能有所帮助的策略:

  • **确定债务类型:**所有的技术债务不能等量齐观。区分目前尚可接受的债务和不适合积压的技术债务。
  • **分析和自动化:**分析债务的来源,并寻找方法来收紧工作流或自动化某些测试和流程。这有助于减少常见错误和隐藏的错误,防止它们滚雪球般地变成技术债务。
  • **制定新的规则和标准:**需要明确技术债务在什么情况是可以被接受的,什么情况会造成不可逆转的损失。例如,发布即时安全修补程序可能被认为是可以接受的,而允许最终导致相当长的停机时间的错误则不会被接受。
  • **沟通成本:**决策者和 DevOps 团队必须了解技术债务对产品质量和开发人员保留的影响。当另一个截止日期到来时,确保这些关键利益相关者意识到风险。如完全了解潜在成本,他们可能更可能调整交付日期或为其他开发商提供资金。

总之,技术债务如果得到有效管理,可以成为短期内优化交付速度和创新的工具。然而,重要的是要保持平衡,不要让它累积到开始降低产品质量、减缓开发速度或损害团队士气的程度。通过主动识别、分析、管理和沟通技术债务,开发运营团队可以在软件开发的这个具有挑战性的方面进行导航,并维护其基础设施的健康。

  • DevOps

    DevOps(Development 和 Operations 的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

    47 引用 • 25 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...