技术债来自许多软件实践/实践，其中大部分是相当明显的，是深思熟虑选择的结果。然而，在云计算中，有一些隐蔽的、几乎看不见的软件混乱的新来源。甚至云计算也需要大扫除。而且这种清理并不是指你已经知道的重构和数据质量工作。那些“大件”不容易错过，现在我们要注意那些只有在特别突出时才会引起注意的小件。由于云系统易于配置，这些新的小债务很快就会显现出来。添加新字段、编辑公式、修改报告和更改pickle值，一切都在几秒钟内完成。这些小的变化可能会产生重大的后果或影响。除了没有全面的方法来清点所有更改之外，新条目或更改条目的连锁反应也很难评估。因此，撤消更改（以禁用过时的功能或纠正新症状）涉及的工作比最初进行更改所需的工作多得多。随着时间的推移，曾经是小额债务也开始变得令人讨厌。当然，传统主义者会提到将配置控制作为一种方法。我完全同意这一点：云系统比传统系统需要更多的配置控制，仅仅是因为它们更易于使用并且通常以完全分散的方式进行管理。我在四年前写过这篇文章，使用云系统支持的新模型来记录更改。但是，即使您不是行为经济学家也知道，如果将更改记录到配置控制系统的时间比实际进行更改的时间长，人们就不会记录更改。这是人性——每个人都知道使用牙线的好处，但由于每天需要2分钟，所以没有人经常使用牙线。Salesforce.com用户的好消息这里有一些好消息，至少对于Salesforce.com用户而言。自动维护管理更改日志。它不能替代实际记录您所做的一切，但它至少是一个好的开始。此外，EclipseIDE的Force.com插件允许您将几乎整个系统配置的快照放入一组（有时是巨大的）XML文件中。拍摄一个月的快照并使用您常用的XMLdiff工具，您将能够看到发生了什么变化。当然，你不会知道它为什么被改变或被谁改变，但至少你有一个线索。此外，还有其他厂商如DreamFactory、Panaya等提供的一些快照和差异工具。但是，如果您没有执行任何常规清理任务，您可能会发现这些工具毫无用处。在Salesforce.com中，API允许您查询多达10,000个对象；在最近的一次系统审计中，一位客户拥有超过20,000个对象。特别糟糕。采取行动减少技术债务但是工具不能解决这里的问题，最佳实践可以，例如：1.根据变化设定预期。即使你可以在20秒内做出改变，也要明确：改变应该每天只做一次，或者如果可以的话每周一次。2.根据系统管理工作量设定预期。您根本无法一次性还清所有技术债务，预计将15%的管理时间用于慢慢清理技术债务是合理的。3、每季度备份一次系统管理员的变更日志（或根据云系统的日志跨度）。这个小文件应该安全保存。4.使用标准沙盒，每月更新一次。真正了解潜在变化影响的唯一方法是在充满数据的沙箱中；即使那样，也会有一些问题只出现在生产中。5.同时使用开发沙箱（这个是免费的），每天更新一次。6.使用生产系统的系统快照工具，每天更新一次。使用此快照分析它在何处用于支持对设计提出的更改。7.在对生产进行更改之前，在其中一个沙箱中进行测试。如果变更区域是过去30天配置没有太大变化的区域，则在整个沙箱中进行测试。如果有很多配置更改，请在开发沙箱中进行测试。8.将更改放入沙箱后，点击“运行所有测试”按钮（或您的云系统用于运行单元和系统测试的任何机制）并查看是否有任何新的测试错误发生。有时，仅修复选项列表中的拼写错误会导致大量测试错误。9.每月总结一次系统中的所有视图、报告和仪表板。这些东西往往会迅速增加（特别是如果允许大多数用户创建自己的报告），这将对系统可靠性产生致命影响。大胆地精简报告（通过隐藏它们，而不是删除它们）——任何12个月内未运行的报告都不太可能具有保留价值。10.分析哪些项目导致系统管理项目急剧增加，并仔细分析增加复杂性的新来源。每月分析一次。在Salesforce中，主要项目是配置文件、自定义对象和记录类型。定义一个安全系统的布尔表达式超过100,000个并不少见，因此您应该密切注意任何可能导致这个数字呈几何级数增长的方面。11.制定政策：每次向系统添加一些东西时，至少应丢弃一项。至少需要删除一个以前过时的条目（通常每月至少进行一次“清除”）。过时的对象应在条目标签的开头包含特殊的ASCII字符（如▼或?），清楚地表明页面布局中使用该字段或“此处出现问题”的任何报告。弃用还应包括在字段的“开发人员名称”前面加上“zzz”，强制将弃用的字段置于字母列表的底部。弃用和删除必须被视为在发布到生产环境之前在沙箱中记录和彻底测试的更改。结论对此没有简单的解决方案，也没有人愿意偿还债务。但技术债务确实存在，而且会随着时间累积。因此，请授权您的员工在事情失控之前进行一些春季大扫除。原标题：云春季大扫除最佳实践
