从法庭到代码:谁主张谁举证的工程实践
另类软件工程

2023年,与开发商打了不少官司。学习了不少庭审知识。发现有些实践或者原则放到软件工程中也是有效的。就比如谁主张谁举证这一基本原则。

谁主张谁举证就是当事人对自己提出的主张提供证据并加以证明。

举例来说,张三说隔壁老王侵占了自己的宅基地。张三必须自己拿证据来证明自己说的事实。而不是让老王拿证据出来证明自己没有侵占。

在软件工程中,服务A调用服务B,出问题了。服务A认为是服务B的问题,这时,根据谁主张谁举证原则,服务A的开发应该自己找出证据来证明自己的观点是正确的,而不应该让服务B来提供证据证明自己没有问题。

因为如果让服务B证明自己没有问题,怎么证明自己没有问题呢?怎么证明,证据都不够充分。而且会浪费服务B的团队人力。

所以,在团队中,让大家达成“谁主张谁举证”的共识会带来以下好处:

  1. 节约团队的人力。如果服务A能提供有效证据,那么就不需要服务B去证明自己没有问题了。
  2. 倒逼团队形成故障现场保留的习惯,比如打印良好的日志等

不过,我们需要注意的是,“谁主张谁举证”并不意味着,服务B团队不配合服务A一起排查问题。在一个公司里,基本的团队协作原则与底线是要有的。

那是不是所有的场景都是谁主张谁举证?

也有特殊情况。有些场景,是需要进行举证责任倒置的。开发商要拿证据来证明自己的转供电是合法的,而不应该让业主拿证据来证明开发商转供电不合法。 也就是证据只能是“被告方”能提供的情况下,我们就不是谁主张谁举证了。

以上只是我个人的思维实验。

在工作中,作为DevOps工程师,我经常遇到开发者质疑云厂商的Redis或者RDS出了问题。

根据我过往的经验,只是质疑,没有证据的情况,大多是开发者自己代码的问题。通常我会自己看看监控的同时,会要求他们加日志,然后想办法复现问题。

最后,一个公司一个团队里,如何低成本的达成谁主张谁举证这个共识?

我目前还没有答案。


Last modified on 2025-09-13