这两天工作上发生了一件事，让我很难平静。
过年前最后一天（我买了五点半的电影票打算早走的，我知道过年前是最后能刷R1的时候）。下午三点的时候发现来了一个High priority的ticket，是一个中国cube的ETL挂在cube process上了，是比较基本的问题。我就先开了profiler看process的错误。很快发现是process measure group P的时候报了个numeric overflow bigint的错。然后我就想办法在那个partition找哪个数据的值超长了。看了一下P的view的定义，只看到一个column是bigint，再仔细一看这个column的定义，我记起来别的cube的这个column曾经也出过一样的错。这个column的设计本来就有点奇怪，把store_key, item_key和一个measure X的值concat起来（当中有2个0间隔）再转bigint。按照我们系统目前的store_key, item_key的位数来看，measure X只要超过两位数就会overflow。然而当时PM说，这个measure只能是0到5六个值。估计是开发看了这个需求，也没想过可能需要处理超长的效果。（去年11月的时候我第一次遇到这个问题时，我的第一反应是把这个问题给DEV，因为这样危险的设计在我看来很可怕。在和QA确认的时候才得知还有限制0到5这回事。）
当时我急着赶电影，我就回复了一下：“这和ticket XXX是一样的问题。X数据只能是0到5。可是现在我们有42002这么大的数据。请检查一下是不是又重复load了文件。我已经关闭了这个silo的ETL。”这一句重复的文件的猜测，是因为去年我检查这个问题的时候，时间比较充裕，就顺便检查了一下数据源的历史记录，发现了重复的文件。实际上，这一次不一定是同样的原因造成数据过大。然而我想，是个operation（他们天天看数据，天天set up文件load）都会明白，接下来就该是他们去修复数据了。
春节值班的时候，我特意留意了一下这个ticket，我惊讶地发现他们没有更新。我猜是因为没人看见我说我关了ETL，所以它没有继续报错，所以没人注意到这件事。于是我把ETL又开了。（我们的产品环境就是这么混乱。）
隔了几天我又值班，发现operation看到了这个ticket，然而第一个回复是（一个脑子比较僵硬的中国男operation）：“我没有看到有重复文件，所以根XXX应该不是一样的问题，请再看看为什么cube process挂。”在我之前值班的开发同学M回复说：“为了跑过去，我已经从DB里删了数据，并且把删的数据存在了table_name_bak里。”这里的table_name是我们基本的measure group A。接下来，是operation老大吩咐美国的operation把坏的数据用正确的方法unload掉。
年后上班这个ticket仍没有解决，并且变成了urgent回到我头上，而问题还是原来那一个。不过加上了最近有过attribute变动，变成如果要process，是把所有partition都要process才能过去。这个cube属于之前中国特殊数据load，为了缩短上线时间，他们把这个retailer的数据全都做了redundant load，实际客户看到的数据只有我们load的数据的十分之一都不到，所以full process很慢。负责monitor新数据load的operation女生不知道这些，因为是周一ETL总体很忙，她无法在数据源unload数据。于是她一个劲催我也删一下数据嘛。
我的各种本能都告诉我不该在产品环境删数据。以前我的经理是BI开发的经理，如果他在我会跟他聊几句，肯定会避免发生接下来的事情。现在我的经理是APP开发经理，他的BI经验其实不多，我就没想跟他聊（实际上他虽然看所有的urgent ticket，但也并没有明白我实际上后来犯了个错）。
事实就是，我知道这是numeric overflow；我知道>5的数据都不对（进了cube也会因为dimension没有而不显示），虽然如果是8这样的值还不会造成overflow报错；operation一直在跟我强调过年值班的开发M同学删了数据后面就process进去了。“你看他那时回复的呀！”我有一种如果我不删数据，我就没有M同学有能力的压力。（实际上，M也是有技术但没有产品sense的人，在BI的方面，经验也是比我差一截。然而他是开发我是产品技术支持，而且他是男生，男生的无知自信对技术和产品sense差一些的人来说，就等于强大，不幸的是我们公司都是这样的人。）我还有一半的思绪在想如果要对这么大的表删数据，性能会不会很可怕。
结果我就按照M说的，把measure group A的不合法数据删了。
接下来是7小时的full process。
昨天早上上班的时候，我看到晚上的process挂了。我幡然醒悟：造成overflow的数据是measure group P的。P是从A算出来的。等于我删数据并没有帮助数据process成功，反而耽误了一天的时间。
我把这一点告诉了operation的女生，她还疑问：为什么M删了以后就process成功了呢？要么是M其实删了P的数据。如果要删P数据，鉴于它的计算逻辑非常复杂，如果暴力删数据会造成什么情况我说不清。我当时是觉得M一定是删了P的数据，因为他对P的逻辑肯定没有我熟悉，所以因为无知无畏而删是有可能的。后来仔细看超级长的ticket，我才发现更合理的解释是美国的opertaion当时unload掉了错误的数据（P会在ETL中重新计算一遍），只不过新的错误数据又来了。请operation按照正常的手法unload数据才是正确的做法，是我一开始的建议，但是在催促和担心自己看起来没有男开发一样的本事，再加上没有人来管我，我做了一个错误的操作。
现在，在我的坚持下，operation终于退回去修了数据，现在cube process终于跑过去了。
这个错误并没有引起任何关注。这件事的后果只是，本来delay了7天的数据多delay了一天。我的经理没发现我做错了，operation还没有来责怪我，我估计也不会。因为在我们其他的产品支持工程师里，比我这个错厉害很多的错多了去了。我一直在配合大家工作的同时，默默尽力坚持我的标准。这个错已经不是第一个让我觉得“啊，我现在怎么标准降低这么多啊？”的事件了。
一方面没受到指责，也更说明管理的混乱。另一方面，我自己也很难原谅自己犯了一个可以避免的错误。我从一开始对问题的鉴别，和对解决问题的建议都是正确的。我们公司的管理太fucked up才造成我从这么正确的起点开始都能走到错误的操作。