摘要：CIO们常年应对技术债务的风险、成本和复杂性。虽然遗留系统的影响可以量化，但技术债务还常常以更为微妙的方式存在于整个IT生态系统中，这使得人们很难列出全部的问题和风险。
IT领导者需要超越遗留系统，看清究竟是什么阻碍了IT议程，致其无法实现变革性成果。
CIO们常年应对技术债务的风险、成本和复杂性。虽然遗留系统的影响可以量化，但技术债务还常常以更为微妙的方式存在于整个IT生态系统中，这使得人们很难列出全部的问题和风险。
Forrester的报告显示，30%的IT领导者面临高额或关键性的技术债务问题，另有49%的IT领导者面临中度的技术债务问题。即便是在中度至低度风险的情况下，随着业务需求的变化，技术债务的影响也可能迅速改变。毕竟，当某个关键应用程序需要现代化以支持数字化转型举措时，原本低风险的烦恼就可能变成一块巨大的绊脚石。
Accenture的报告指出，技术债务的主要来源是企业应用程序、AI和企业架构。这些问题相当严重，但数据、安全、文化以及解决过去问题的捷径如今成为负债的领域又该如何呢?另一个问题是：如何区分随机修复的技术债务与可能使企业陷入瘫痪的关键性技术债务?
为了应对可能阻碍企业转型的已知和未知因素，CIO们应考虑以下七种技术债务类型、它们为何关键以及应如何应对。
1. 妨碍决策的数据债务
在《数字开拓者》一书中，我分享了一个私营公司的故事。该公司向董事会报告称某一年度盈利，但假期过后却发现，由于数据质量问题和计算错误，该年度实际上并未盈利。
那些改变文化，使之更加以数据为驱动，并实施公民数据科学的CIO们受数据债务的影响最大，因为日期、金额或阈值的错误解释或计算都可能导致错误的业务决策。数据债务的类型包括暗数据、重复记录和未与主数据源集成的数据。
将公司的数据用于大型语言模型(LLM)、智能体或其他GenAI模型会带来更多风险。数据偏见、数据分类中的空白以及授权政策不足的数据源都可能导致错误决策、合规风险以及影响客户的问题。因此，数据债务沉重的组织可能会发现，追求许多GenAI机会更具挑战性和风险性。
CIO们可以做什么：通过在敏捷数据团队中纳入数据治理和分析职责、实施数据可观测性以及制定数据质量指标来避免和减少数据债务。
2. 拖慢性能的数据管理债务
数据管理债务可能瞬间产生，也可能随时间累积，可能因缺乏自动化而产生，也可能由事件响应所驱动：
• 瞬间产生：IT部门将大型数据库迁移到云端，但未优化数据架构，这可能导致数据库管理债务随着时间的推移而不断增加。
• 随时间累积：数据库在规模、复杂性和使用上不断增长，需要随着时间的推移重新构建模型和架构以支持这种增长。
• 缺乏自动化：数据库管理员在手动操作程序上花费了太多时间，而这些操作本应实现自动化，包括创建备份、管理权限、跨系统同步数据或配置基础设施。
• 事件响应：每日处理紧急问题、应对重大事件或进行根本原因分析，使数据库管理员无法进行更多主动性的任务。
Redgate的CTO Graham McMillan表示：“即使在数据库工具上进行适度投资并偿还一些数据管理债务，也能使数据库管理员摆脱手动更新或响应式监控的乏味工作。这将使他们能够将自己的技能和创造力用于更高价值的活动，如增强数据安全和为客户提供创新解决方案。”
CIO们可以做什么：衡量数据库管理员在手动操作程序和事件响应上花费的时间，以评估数据管理债务。减少数据管理债务的选项包括自动化任务、迁移到数据库即服务(DbaaS)产品以及归档旧数据集。
3. 开源依赖债务拖慢DevOps速度
作为软件开发者，自己编写代码要比审阅他人的代码并了解如何使用它来得更容易。搜索和集成开源库和组件甚至可能更容易，因为当开发者面临在截止日期前完成任务和频繁部署的压力时，长期支持的重担并不会时刻萦绕在他们心头。
Sonatype的首席产品交付官(CPDO)Mitchell Johnson表示：“许多团队忽视了依赖项卫生，任由过时、冗余或不受支持的开源组件堆积如山。平均每个应用程序包含180个组件，如果不进行更新，就会导致代码臃肿、安全漏洞和不断累积的技术债务。正如没有人愿意在关键任务系统上运行十年前的硬件一样，现代的软件开发生命周期(SDLC)和DevOps实践也必须以同样的方式对待软件依赖项——保持更新、精简和安全。”
根据Black Duck发布的《2025年开源安全与风险分析报告》，在接受风险评估的代码库中，有81%存在高风险或严重风险漏洞，90%包含的组件落后于最新版本10个或更多版本。CIO应寻找开源依赖项债务削弱DevOps生产力的迹象，包括破坏性代码更新的频率、安全警报数量的增加，或解决依赖项冲突所花费的时间。
CIO可以做什么：向DevOps团队普及开源安全风险知识，制定评估和批准开源包的治理政策，并使用SAST工具来查找代码漏洞。
4. 将需要大量重做的AI债务
GenAI工具和能力正在引入新的技术债务来源。即使CIO已经制定了AI治理方案，快速变化的GenAI模型、法规和自主式AI能力也将产生AI债务问题。
PagerDuty的CIO Eric Johnson表示：“AI系统中的技术债务表现形式与传统架构债务不同，它不仅仅关乎代码的可维护性，而是关乎整个数据和模型治理生命周期。如今，急于构建自定义AI解决方案的公司可能会产生新的技术债务形式，这些债务可能比过去我们面临的架构挑战更加昂贵和复杂，难以解决。关键是，在投入AI实施之前，要建立强大的数据治理和基础设施基础。”
虽然许多形式的技术债务会导致持续的维护问题，但AI模型漂移是AI债务逐渐增加的一个例子。但有些AI债务可能需要CIO停用并替换AI功能，例如，当新模型在准确性、性能或成本方面有了显著改善时，旧模型就会被淘汰。另一个令人担忧的问题是，如果法规要求全面重新训练模型，CIO将不得不改用其他方案以保持合规性。
CIO可以做什么：为了使过渡到新的AI功能成本更低，应投资回归测试和围绕AI驱动的大规模工作流程的变更管理实践。
5. 侵蚀并产生遗留系统的架构债务
一些应用架构债务可以通过现代化、将应用迁移到新平台或使用GenAI工具来记录和解释遗留代码库来补救。一些更大的架构债务来源包括：
·嵌入在ERP和其他企业系统中的重大代码定制
·系统之间未使用数据织物或集成平台的点对点集成
·未遵循安全、测试、版本控制和可观察性标准而部署的微服务和API
·为早期部署利益而配置的多云架构，需要大量成本、时间和专业知识来维护
拥有庞大架构的CIO应考虑简化架构，并建立架构可观察性实践。这些实践包括通过聚合应用级监控、可观察性、代码质量、总成本、DevOps周期时间和事件指标来创建架构和平台性能指标，以此作为评估架构如何影响业务运营的工具。
vFunction的联合创始人兼CTO Amir Rapson表示：“如果没有架构可观察性和治理，AI驱动的开发可能会引发微服务蔓延，加速架构漂移，并导致隐藏的依赖项，这些依赖项会加剧架构技术债务，这是影响性能和可扩展性的最具破坏性的技术债务形式。工程团队也可能会陷入混乱的服务交互中，而无法交付新功能。GenAI是一个强大的推动者，但要实现长期创新，可持续的成功取决于架构可观察性。”
CIO可以做什么：技术的发展会产生架构债务，所有CIO都必须随着时间的推移来解决这个问题，否则，债务将变成无法支持的遗留系统。CIO可以控制的一个领域是管理是否以及如何实现定制，以避免将业务规则复杂性内置到代码中。第二个领域是重新考虑架构审查委员会，并制定自组织标准，明确敏捷开发团队和企业架构师之间关于架构的决策权限。
6. AI实施中难以解释的安全债务
安全债务有多种形式，如缺乏可执行的政策、终端用户培训不足以及未将安全实践向DevOps左移。CISO在不断循环中弥补这些安全漏洞，同时应对最新的威胁。
但赶上AI模型的步伐可能没那么容易。虽然组织可以采取措施防止机密信息被用于训练AI模型，但很难知道模型中有什么私人信息，也不知道是否有删除它们的选项。
Xebia的数据董事总经理Giovanni Lanzani表示：“GenAI模型可能会引入新的安全风险，如模型本身存在漏洞、数据泄露和对抗性攻击。”如果这些风险没有得到充分解决，安全债务就会不断累积。
Lanzani分享了一个银行面向客户的聊天机器人的例子。“该实例需要一个强大的GenAI框架，实施强大的提示注入防护栏，以避免提供财务建议或发表对银行不利的言论。它还匿名化所有个人身份信息(PII)，以便云托管的聊天机器人无法接收私人信息。”
CIO可以做什么：DevSecOps中的安全实践落后于持续集成/持续部署(CI/CD)自动化，而企业正迅速实施公民数据科学，导致许多数据治理实践仍待完成。落后于AI治理实践可能会产生不可接受的风险，尤其是当智能体被部署在企业应用和面向客户的应用中时。
7. 加速业务中断的文化债务
数字化转型最难的部分在于获得早期采用者、推动变革管理以及应对反对者的阻挠。GenAI会增加更多的文化债务，因为主题专家逐渐退出劳动力队伍，而具备AI能力的员工几乎没有继承这些经验，难以承担新的职责。
LaunchDarkly的现场CTO Joe Byrne表示：“文化债务可能会产生多种负面影响，但就AI而言，缺乏适当的工程实践、对创新的抵制、部落知识差距以及未能采用现代实践，都会给成功利用AI造成重大障碍。”
CIO可以做什么：寻求将AI用作生产力驱动力之外，并寻求转型成果的CIO应认识到，减轻员工对失业的恐惧并指导他们如何利用AI来增强(而不仅仅是自动化)自身能力，这一点非常重要。
虽然CIO面临着加速交付AI和其他现代化成果的压力，但留下过多的技术债务会成为创新和转型的阻力。
来源：三少君
