PET and Prod

今天发生件有意思的事情

 

我的客户adri在做财务报表的时候跳出来很不高兴的说：“冠军，上周三你说这个数据已经没有问题了，现在这个周一怎么问题还是出现，我感到有点不爽”。其实我也感到有点不爽，上周三我是校验过数据的，都是没有问题才发邮件告诉他现在没问题了。况且，我发信告诉他数据应该好了，他也应当作出适当的测试验证，可是他没有，这就导致最后出财务报表的时候大家都不爽。

 

我不是想规避责任，在仔细校验了程序后也发现了另外一个bug，虽然和他说的那个问题没有多少关系。根本原因应该是程序调度的问题，财务数据的刷新应该在上游表完成后再做，可能没有同步好而造成difference。

 

我这里想说的是，任何生产系统上运行的正规报表必须运行在生产系统上，原因如下：

 

1. 生产系统对用户而言是只读的，用户不可能有意或无意地破坏生产数据。

 

2. 生产数据的恢复或重运行是有严格标准的，不是自己定制的程序随便改个参数就能够搞定的。至少，在目前的uc4系统上是需要oncall介入，操作过程虽然冗长，但是每一步都得以仔细review。减少出错的概率

 

3. 生产系统上的job是一份标准的流程，与自定义的流程不同，标准流程易于维护。自定义的流程绝大多数情况下只有开发者最清楚，而标准流程可以让绝大多数人在不了解细节程序的逻辑的情况下进行data recovery。

 

4. pet空间毕竟是原型系统，其流程控制没有标准的uc4强大与稳定以及具有日志功能，很多时候查错变得很困难。

 

5. 成熟的原型系统应当尽早移交到生产系统，不然随着时间增长，其维护成本变得尤为庞大。

 

 

回到上面这个故事，它告诉我们，两套系统间应该明确划分职责，不然不利于开发和维护。

 

还有PET不是DW。