8月16日的黑锅

     最近一期交接的事情局方盯得很紧，我心里悬得很，做的事情多是好也是坏，做得太多，生怕哪里没周全就出错了，果然。。。。

      热线报了一个设备页面查不到，查到底层才知道是一个状态标识为空了，到外围系统去查，状态是有的，看接口数据和程序，数据都过拉了没问题，然后在底层数据找到一个时间标识字段，是8月16日的。。。。。。。

       那个时间字段本没标识，是8月16日有人对这个表做了大批量的操作，肯定是这样，我判断。

       找到应用，没人承认，找不到操作的那个人，这个事情肯定要局方帮忙协调才能把数据补回来，但是我给局方什么理由，数据丢了，接口没错，应用没错，大批量操作只有接口才做得了，我找经理，说明了来龙去脉，但是经理问是谁做的，我只能说不知道，可是对局方能说不知道么。。。。。。。。。。

       刚好另一个公司也在，一个挺厉害的大哥哥给我看了程序，说肯定不是接口的问题，但是确实找不到原因，除非查oracle系统操作日志，但是这个权限很大的，需要向上申报才可以，经理肯定不会愿意动这么大的干戈，大哥哥说，要我对这样的敏感字段做稽核，我光说是没用的，只有拿数字说话才行。。。。。。。。。

       8月16号的黑锅，让我摔了一跟头，也长了个心眼，先人工监控这些敏感字段，时间宽裕了再写个程序。。。。。。。。

评论

6 楼 抛出异常的爱 2007-10-25  

一般ZF的项目会有很多这样那样的锅子等你的。
不过一看标题就知道是你写的文章。。。。。
小题大作。

5 楼 ddandyy 2007-10-25  

好像在我们这  还没有不承认的人出现过........

4 楼 lordhong 2007-10-25  

做PM又不想背黑锅... 还是自己做BOSS吧

3 楼 angel_888 2007-10-24  

二楼，我们程序的应用层是不能大批量操作底层数据的

2 楼 bluemeteor 2007-10-24  

这怎么能叫黑锅呢？这怎么会是黑锅呢？

Its your Responsibility

1 楼 chinata 2007-10-24  

angel_888 写道

<p>&nbsp;&nbsp;&nbsp;&nbsp; 最近一期交接的事情局方盯得很紧，我心里悬得很，做的事情多是好也是坏，做得太多，生怕哪里没周全就出错了，果然。。。。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 热线报了一个设备页面查不到，查到底层才知道是一个状态标识为空了，到外围系统去查，状态是有的，看接口数据和程序，数据都过拉了没问题，然后在底层数据找到一个时间标识字段，是8月16日的。。。。。。。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 那个时间字段本没标识，是8月16日有人对这个表做了大批量的操作，肯定是这样，我判断。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 找到应用，没人承认，找不到操作的那个人，这个事情肯定要局方帮忙协调才能把数据补回来，但是我给局方什么理由，数据丢了，接口没错，应用没错，大批量操作只有接口才做得了，我找经理，说明了来龙去脉，但是经理问是谁做的，我只能说不知道，可是对局方能说不知道么。。。。。。。。。。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;刚好另一个公司也在，一个挺厉害的大哥哥给我看了程序，说肯定不是接口的问题，但是确实找不到原因，除非查oracle系统操作日志，但是这个权限很大的，需要向上申报才可以，经理肯定不会愿意动这么大的干戈，大哥哥说，要我对这样的敏感字段做稽核，我光说是没用的，只有拿数字说话才行。。。。。。。。。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8月16号的黑锅，让我摔了一跟头，也长了个心眼，先人工监控这些敏感字段，时间宽裕了再写个程序。。。。。。。。</p>

“除非查oracle系统操作日志”
我不认为操作日志可以看出通过应用接口对数据进行的操作。这个应该还是在应用级进行监控。看看登录日志