话说我们这里,一个客户,一群服务商,服务商之间互相都恨不得对方出问题,自己好取而代之,于是各种下绊子的招层出不穷。客户对此很清楚,不过本着以夷制夷的原则,乐得看笑话,于是服务商之间就要比谁笑得到最后了。* {0 F1 b' X- z4 q2 r9 F# s% y
4 ]# X; [1 J# V* s7 X" M; t- o我们的一个项目终于上生产机了,这生产机的support team是由另一家服务商的团队构成的,而用户的官方政策是development team的人不得对生产机有任何访问,更不要说修改,任何访问以及修改都必须通过support team来完成。于是双方就很有玩的空间,好戏就不得不开场了。至于这好戏的成本,那是客户的事情,我们按照时间拿钱,失败者付额外的部分。 2 D, Q# |" k+ b, A h- B# {* a( V% Y. D
好了,废话少说,言归正传。; K/ l5 ~2 Z0 k3 Q: s( Z) u
0 V1 R: o5 f. |1 Z2 M我们的这个项目,使用到了JNI,也就是我们的Java程序通过使用第三方提供的本机代码来实现所需要的功能。这程序在测试服务器上工作得很正常,于是就得到批准上生产机了。等到了生产机,出问题了,错误信息是所需要使用的本机方法找不到。很明显,生产机上使用的本机代码库有问题,问题在于怎么出的问题,只有知道了怎么出的问题,你才会知道如何解决,对吧。很对,对方也明白这一点,于是游戏就可以开玩了。按照规定,我们不能对生产机有任何访问,一切所需要的东西都要使用remedy开ticket,对方据此访问生产机,获得所需要的信息,反馈给我们。听起来很合理的制度,做起来就很有猫腻的机会了,为什么,因为这个过程需要不断地往返电子公文,和通过具体的人去做,于是就有了设法拖延的机会,只要把拖延做到一定程度,开发人员的技术能力不足、交付延误罪名就是免不了的,于是就有失败者为额外的成本付出代价。我们当然明白这点,于是就设法做个坑,明着我们延误,实际上对方最后倒霉。根据是什么呢,底牌,就像周润发黑社会电影赌神里面那样,谁有了最后的底牌优势,谁就能赢,之前不过是涮傻瓜而已。到底谁是傻瓜,底牌揭开的时候大家才会明白,不过玩家之一用不着等那么久,这就叫做倒过来玩。 # b2 h- t* M0 o' k. O S1 M7 S2 }8 e+ f我们的底牌,就是我们实际上有生产机的访问账号,这是一个公共账号,这意味着用它是无法查出谁在使用它,该账号可以正常运行我们的程序,这个就够了。当然我们不能让对方知道这一点,尤其重要的是,我们不能给对方留下我们犯规的证据,否则倒霉的就是我们自己了。那么怎么做呢,肯定不能把正常的程序拿来在生产机上面运行,因为那是肯定会留下证据的。好办,做个特殊的版本,它既能达到我们的目的,又不会留下任何痕迹,更奇妙的是,它运行完会把自身销毁,只在终端屏幕上留下我们所需要的数据。1 H' t% C y$ o2 E" d! m
% c U! k1 A# C+ e利用这个账号,我们可以找出来生产机上我们所需要使用的本机代码库有多少个同名文件,和它们都在哪个路径上,自然也就可以下载到windows机器上去作分析,然后再用我们的特殊程序来验证对应的特定版本是否适合我们的需要。靠着这样的方法,我们用了不到一天就找到了问题所在。答案有了,下一步就该整人了。有人会问,你们就不能不整人嘛,回答是不整人就等着被人整,这样的环境下你只能抢先开火干掉对方。那么怎么整呢,很简单,告诉客户我们需要做的事情和步骤,一切都是合理、合法的,听上去很合情合理,但是具体要求对方去做的工作却大大超过他们能够完成的限度,用工作量把他们压死,造成他们延误完成,以此把工期延误的屎盆子扣到他们头上去。有人可能会问,那你们就不怕因此延误自己的进度吗?回答是当然不会,因为我们已经知道答案了,随时可以公布答案,剩下的只是按照自己的需要涮对手而已,谁让他们是对手来着。