技术债务来自许多软件实践/做法，而其中大多数实践/做法相当明显，是故意选择的结果。不过在云计算领域，有一些隐伏的、几乎看不见的新来源导致了软件无序。

连云计算也需要春季大清理。而这种大清理不是指你已经有所了解的重构和数据质量工作。那些“重大项目”不容易漏掉，现在我们需要注意只有在变得特别突出时才会注意到的那些细小问题。

由于云系统易于配置，这些新的小债务很快就会显露出来。添加新的字段，编辑公式，修改报表，更改参数选用表值，这每一项操作都只需要短短几秒钟。而 这些小更改会带来重大的后果或影响。抛开没有全面的方法可以清点所有更改这一点不说，新添或更改的条目引起的连锁反应很难评估。

所以，撤销更改(为了停用过时功能或纠正新症状)涉及的工作量比当初进行更改所需的工作量要大得多。由于日积月累，原先的小债务也开始变得令人讨厌。

当然了，传统派会提到采用配置控制这一方法。对此我深表赞同：云系统比传统系统更加需要配置控制，就因为它们更容易使用，而且通常以一种完全分散的方式来加以管理。

为此我曾在四年前撰文过，使用云系统支持的新模式将更改记入文档。但如果将更改记入到配置控制系统所花的时间比实际更改所花的时间还要长，你没必要 是行为经济学家就知道人们不会记入更改。这是人性使然――谁都知道，用牙线清洁牙齿受益无穷，可是由于每天要花2分钟，于是没人经常用牙齿清洁牙齿。

Salesforce.com用户们的好消息

这里有几则好消息，至少对Salesforce.com用户们来说是这样。系统会自动保持一份管理更改日志。它并不能代替真正将你的每个操作记入文 档，但这至少开了个好头。另外，面向Eclipse IDE的Force.com插件让你可以对几乎整个系统配置进行快照处理，处理成一组(有时是一组庞大的)XML文件。拿来当月快照后使用你常用的XML 差分工具，你就能看到什么地方发生了更改。当然了，你不会知道为何更改或者由谁更改，但至少有了点头绪。

另外，还有DreamFactory、Panaya等其他厂商提供的一些快照和差分工具。但如果你并没有一直在做任何定期的清理任务，可能会发现这 些工具不顶用。在Salesforce.com中，API让你可以询问最多10000个对象;而在最近的系统审计中，一个客户有20000多个对象。真糟 糕。

采取行动以减少技术债务

但是工具在这里解决不了问题，而最佳实践解决得了问题，比如下面这些：

1.设定更改方面的预期目标。即便你可以在20秒内进行更改，也要明确：更改只能每天进行一次，如果可以的话，每周进行一次。

2.设定系统管理工作负载方面的预期目标。你根本无法一下子还清技术债务，预计15%的管理时间专门用于慢慢清理债务是合理的。

3.每季度(或者按云系统的日志跨度)备份一次系统管理员的更改日志。这个小文件要永久保存。

4.使用标准的沙盒，每月更新一次。想真正看到潜在更改的影响，唯一的办法就是在装满数据的沙盒里面;即便如此，还是会有一些问题只在生产环境中才会体现出来。

5.另外使用开发沙盒(这是免费的)，每天更新一次。

6.对生产系统使用系统快照工具，每天更新一次。使用该快照分析哪里在使用，以支持设计提拟的更改。

7.在生产环境中进行更改之前，先在其中一个沙盒里面进行测试。要是更改区域是配置在过去30天没有发生太大变化的区域，就在整个沙盒里面进行测试。要是出现了许多配置更改，就在开发沙盒里面进行测试。

8.一旦你将更改的内容放入到沙盒，就按一下“运行所有测试”按钮(或者是你的云系统用来运行单元测试和系统测试的任何机制)，看看有没有任何新的测试错误出现。有时候，仅仅修复参数选用表中的拼写错误就会引起好多的测试错误。

9.合计系统中的所有视图、报表和仪表板，每月合计一次。这些东西往往会迅速增多(如果大多数用户被允许可以创建自己的报表，更是如此)，会给系统 可靠性带来致命影响。大胆精简报表(通过隐藏报表，而不是删除报表)――12个月里面没有运行过的任何报表都不太可能有保留价值。

10.分析什么条目引起系统管理项急剧增多，严密分析增添复杂性的新来源，每月分析一次。在Salesforce中，主要条目有配置文件、自定义对 象和记录类型。有100000多个布尔表达式定义安全系统，这种情况并不罕见，所以你应该密切关注会导致这个数呈几何增长的任何方面。

11.制定一项政策：每当你给系统添加内容，至少要废弃一个条目。至少需要删除之前被废弃的一个条目(通常每月至少应该进行一次“清除”工作。)

结束语

这方面没有什么简易的解决办法，没人喜欢还债。但是技术债务确确实实存在，而且会日积月累。所以，不妨授权员工来一番春季大清理，免得到时局面失控。