一、业务参数之 “坑”
业务参数的错误可能导致严重后果，以作者的亲身经历为例，一个小小的日利率参数错误，使得利息金额扩大了十倍。这不仅是一个低级错误，也反映出业务参数处理不当的严重性。
在实际的业务场景中，利息的计算通常涉及到年利率、日利率以及计息金额等参数。作者在处理业务需求时，由于日利率的计算出现失误，导致了严重的后果。
例如，在一些借贷纠纷的案例中，计息标准和计息期间的错误可能会对当事人的权益产生重大影响。就像赵 *、吴等与李、谭 * 民间借贷纠纷再审复查与审判监督民事裁定书中，当事人对计息时间及利率问题存在争议，其中日利率小数点位数认定的不同，虽然看似微小，但却可能导致还款金额的差异。
在金融领域，业务参数的准确性至关重要。如泉州汇鑫小额贷款股份有限公司与 S 某某、Z 某某、Z 某某等关于借款合同纠纷的民事案件中，利息的计算涉及到多个参数，包括借款本金、月利率、还款期限等。如果其中的业务参数出现错误，可能会引发一系列的法律纠纷。
此外，八菱科技 2017 年三季报关键业务参数填报错误收深交所监管函的事件也提醒我们，业务参数的错误不仅会影响企业的内部管理，还可能对企业的声誉和股价产生负面影响。
总之，业务参数的错误可能带来严重的后果，开发人员在处理业务参数时应格外谨慎，避免因人为失误而导致不可挽回的损失。
二、错误为何没被发现
1. 代码评审环节缺失
在本次事件中，代码评审环节的缺失是导致问题未被及时发现的重要原因之一。通常情况下，代码评审是软件开发过程中的关键环节，它可以帮助开发人员发现代码中的潜在问题，提高代码质量。然而，在本次开发过程中，作者自己提交并审核代码，没有经过正常的评审流程。这就大大降低了发现问题的几率。
如果有伙伴合作评审，可能有 50% 的几率发现问题。但这次伙伴被调到其他组，导致评审环节缺失。这使得代码中的问题无法得到及时的反馈和修正，为后续的问题埋下了隐患。
2. 测试环节的局限性
测试环节在软件开发中起着至关重要的作用，但本次事件中的测试环节存在一定的局限性。测试主要关注精度变化后的利息是否符合预期，但测试环境没有生产环境配置，无法确保 SQL 中数据的正确性。
尽管测试同事认真检查了值的位数，但由于测试环境与生产环境的差异，无法发现值被扩大了十倍的问题。在实际的软件开发中，测试环境应尽可能地接近生产环境，以确保测试的有效性。
3. 生产验证不严谨
生产验证是确保软件在实际生产环境中正常运行的重要环节。但在本次事件中，生产验证不严谨，导致问题未能被及时发现。
生产验证时，存量配置中有三个 SQL，其中一个算对了，且对应的数据更多。作者随机抽选的两条数据恰好是正确 SQL 对应的数据，导致得出生产验证通过的错误结论。这种不严谨的生产验证方式，使得问题被掩盖，最终导致了严重的后果。
三、开发人员为何不能碰业务参数
1. 容易出现人为失误
开发人员在处理业务参数时，很容易出现人为失误，就像作者在 SQL 中写错日利率那样。这种失误看似是一个小问题，但却可能带来严重的后果。例如，在利息计算中，日利率的错误会导致利息金额的巨大差异，从而影响到用户的利益和企业的声誉。这种人为失误与程序本身无关，但却会给企业带来经济损失和法律风险。
2. 缺乏专业的业务理解
开发人员通常以技术为中心，对业务需求的理解可能不够深入。他们可能更关注代码的实现和技术的应用，而忽视了业务参数背后的复杂业务关系。在处理业务参数时，开发人员容易出现错误，因为他们可能不了解业务参数的具体含义和影响。例如，在金融领域，业务参数的准确性至关重要，但开发人员可能不了解利息计算的具体规则和法律法规，从而导致错误的计算结果。
3. 复杂的业务关系难以处理
不同客户的特点和需求差异很大，这使得业务参数涉及的复杂责任分配和利益关系难以处理。开发人员可能不了解不同客户的业务需求和风险偏好，从而在处理业务参数时出现错误。例如，在借贷纠纷中，计息标准和计息期间的错误可能会对当事人的权益产生重大影响。开发人员需要了解不同客户的业务需求和风险偏好，才能正确处理业务参数，避免法律纠纷。
四、如何避免碰业务参数
1. 严格的代码评审制度
严格的代码评审制度是避免开发人员触碰业务参数的重要保障。确保代码经过多人评审，避免自己提交自己审核的情况，能够极大地提高代码质量。在代码评审过程中，评审人员应保持独立性和客观性，对待被评审代码持有审慎的态度，不偏不倚地进行评审工作。评审人员应当具有专业的知识和经验，能够全面、深入地审查被评审代码，提出详细的反馈和建议。
例如，可以采用交叉评审和会审相结合的方式。交叉评审也就是团队成员互相检查代码，参与者可以是任意两个组员，或开发组长分别与每个组员结对进行。评审时机在下班前半小时，对当天改动的模块进行评审，代码作者讲解如何以及为何进行这样实现，评审者提出问题和建议，每次评审需要做记录并保存到 SourceSafe。会审以项目为单位，召开专门的代码评审会议，参与者包括项目组全体成员，其他组的开发组长也应尽量参加。会审的时机选择在开发进行某一定阶段时，对共性问题进行总结，对好的做法进行提炼和推广。
2. 完善的测试环境
完善的测试环境能够使测试更加准确和全面，从而降低开发人员触碰业务参数的风险。使测试环境尽可能接近生产环境，确保测试的准确性和全面性。测试环境应包含硬件、软件、网络设备和历史数据等，与生产环境相似，包括网络配置、安全性、访问控制和备份 / 恢复策略等。
例如，可以利用云原生的弹性伸缩能力，在新版本升级时快速生成新的副本，在新副本完全就绪前，旧节点不会下线，保证服务不中断。当新副本升级后，同步进行技术验证和业务验证，验证通过后对外暴露服务并将旧版本节点下线，避免质量门禁未达标的版本直接部署到集成环境影响环境的可用性。
3. 严谨的生产验证方案
制定科学的生产验证方案，避免随机抽选数据，确保所有数据都经过严格验证。生产验证方案应明确验证的目的、范围、方法和标准等，确保验证的全面性和准确性。在生产验证过程中，应严格按照方案进行操作，对所有数据进行逐一验证，避免遗漏。
