意识流工作感想

一直在想要把工作的感想给整理一下。看到这篇文章里写的效率低的开发团队的几个特点/分类,我们公司的膝盖已经戳烂了。(看到“保姆式开发”几乎从不说脏话的我嘴里迸出了卧槽二字。)

工作感想还没整理。现在意识流一篇帮助自己整理。。。

我并不是很想做开发。在逻辑思维方面我比较迟钝。做开发的话我的优点是愿意尝试和不assuming(简直paranoid)。只要有文档和尝试的环境,搞各种script我是没有问题的。我另外的长处是对BI数据库比较有经验。我对Application比较没经验。我们公司的BI产品,还有一部分是application的成分(客户使用界面),想想我在现在公司的5年,最大的收获大概是瞥见一眼application开发,我们公司的开发水准很烂,但看到开头提的那篇文章之后我想我也是得到了一些关于烂的思考。

我喜欢捣鼓script,我更喜欢借用我会技术又会沟通的能力,做一些桥梁工作。工作这么多年来,我见过的人里面,除了极少数人,沟通和技术结合没有我比我强的。当然比我会说话的人多了去了,然而我认为实质的沟通的基础是你要懂你沟通的东西。我也和销售打过交道,有的销售是非常有魅力的人,然而他只负责散发魅力,说实质的东西的时候必须站在他的角度才能沟通。懂数据,懂技术的人,能像我一样沟通的人很少。That said,我加入现在公司的初衷是做这样的桥梁。我加入的是operation部门。我们的operation部门不仅给产品上线、monitor它们的运作,还要保证数据的质量并处理各种客户的咨询。由于我擅长看数据和写脚本,我加入不久就写了一系列脚本帮助monitor我们当时几百个instance(如今已经超过一千个了)。这里对我的技术是有提高的,在之前我只写过ETL的SQL和简单的shell script,连个DB store procedure都没见过。但这家公司的ETL是基于SQL Server的DB SP的,我一边理解产品,一边写出了那些脚本。开发中有些愿意讨论问题的,我也有时候找他们请教。Operation部门工作了两年,我意识到我们产品的问题这么多,其实需要的是开发质量提高。中国办公室的开发老大愿意让我去开发部门继续做更深的技术支持,我就答应了。因为在operation做得再好,也是我已经做了两年的事情了,做得好不再值得骄傲。当时在我看来开发部门有很多事情我可以帮助做好的。比如,开发部门的沟通太烂;大部分开发查数据的技能比我差;大部分开发互相之间都在鸡同鸭讲更不要说和别的部门讲了;大部分开发都不知道operation是怎么deploy和monitor我们的产品的,也不知道客户一般都喜欢干什么。

到了开发部门,我的第一件事是理解release流程。我很惊讶地发现,给定一个特定的时间,在产品环境的某个版本发现了问题,给开发开CR去修复的时候,修复哪些版本这个问题是没有定论的。每一次开CR都需要问release manager,而得到的答复也没有确定的准则。在开头引用的那篇文章里,对此有精确的描述:

配置管理上的问题。对于源代码的配置管理,其实并不是一件简单的事情。配置管理和软件和团队的组构的结构非常有关系。我看到过两种非常没有效率的配置管理,一种是以开项目分支的方式来做项目,同时开很多分支,分支开的时间还很长,导致merge回主干要花大量的时间去解决各种冲突,另一种是N多的团队都在一个代码库中做修改,导致出现很多复杂的问题,比如某团队的改动出现了一个bug,要么所有的团队的功能都得等这个bug被修复才能被发布,要么就是把所有的改动回滚到上一个版本,包括其它团队开发的功能。很明显,软件模块的结构,软件的架构,以及团队的组织形式都会严重影响开发效率。

我们的情况是上面说的很多module在一个库,一个bug会导致所有的无法上线。我们情况的区别是,我们的产品环境压根从来没有回滚上一个版本的功能。很长一段时间我不理解release management对QA提供ETA的要求。ETA方便给客户期待,然而我找QA问ETA的时候经常得到的答复是这样的:如果开发下周二之前把修改提交,那么我们的ETA就是周五。然后周五的ETA就被宣布了。根本不给“开发如果没有来得及修改提交”或者“提交后又测出bug”留余地。

当年我们还有一个非常低级的问题:我们的产品有一个版本号,在部署的server上,代码存在这个版本号为名字的路径下。后来bug越来越多我们变成两周更新一次release,但是版本号不变,这就造成如果不具体看代码你无法知道你面前的版本X是不是最新的版本X。对于DEV和QA来说,只要改好了代码,测试通过,他们就任务完成了——我们deliver了一个修改好的版本X。当时出了一系列问题都是宣布release了但实际上并没有更新到deploy server上。因为DEV和运维之间当时几乎一直在鸡同鸭讲。后来终于认识到需要更新到server上之后,还有很多问题。有些bug需要更新代码后重新deploy,有些bug只要更新代码就好,还有些bug重新deploy后还需要跑一些一次性的脚本。谁来跑脚本这件事一直没定下来。理论上让开发去产品环境deploy是很糟的。但OPS的技术能力有限,让他们跑命令行也经常很危险。还有的时候跑了一次性脚本之后代码没更新,下一次deploy问题又回来了。作为战斗在第一线处理产品问题的我,这样的事情见得太多了,我经常跟老板反应,但是总是‘解决问题更重要’,解决了以后大家就舒一口气又去忙各自的了。

那篇文章里的“保姆式”开发和我们的现状最像。

所谓“保姆式”软件开发就是——我只管吃饭,不管做菜洗碗,就像——衣来伸手,饭来张口的“小皇帝”一样,身边有一堆太监或宫女,不然生活不能自理。这种情况经常见于开发和测试,开发和运维间的关系。很多公司,测试和运维都成了开发的保姆。

我就能看到,很多开发快速写完代码后基本上都不怎么测试就交给QA去测试了,QA一测,我草,各种问题,而只会做黑盒的QA并不能马上就能确定是代码的问题还是环境的问题,所以还要花大量时间排除不是环境问题,才给开发报BUG。很多问题,可能只需要做个Code Review,做个单测就可以发现了,硬要交给QA。运维也是一样的,开发出来的软件根本就没有考虑什么运维的东西,因为有运维人员,所以我才不考虑呢。

我们公司的产品deploy一个的代价非常大,有几百个参数,好多机器需要权限。deploy过程中如果遇到错,需要各种技术能力来分析解决:DB的,java的等等。所以我经常看见开发问QA要环境进行开发。产品环境经常遇到的问题是,你改了一个代码解决了你的问题,但是这个代码在deploy别的类型的instance之后会有问题。当年我做开发的时候非常paranoid(当然因为我技术基础差),我一定要把我想到的所有情况都跑一遍才放心。我们的开发经常会说:“这个改好了让QA去跑一下吧。”,或者在你问他“XXX在YYY的情况会不会有问题”的时候经常得到的答复是,让QA去试试吧。

文章中说的watchdog式开发,我们也是很多。

什么是WatchDog?就是说——为了解决某个系统的问题,我要用一个新的系统去看着它

  • 我的系统架构太复杂,出了问题不好查找。咋办?那就搞个专门的特殊的监控系统吧……
  • 我的系统配置太复杂,容易配错了。咋办?那就加一个配置校验系统吧……
  • 我的系统配置和真实的情况有时候可能会不一性。咋办?那就加一个巡检系统吧……
  • 我的系统测试环境和线上环境有时候会搞混了。咋办?那就为线上环境加一个权限控制系统吧……
  • 我的系统有单点,那就加个负载均衡器吧,负载均衡器的单点呢?那就再加个等价路由器吧……

因为我们的系统很难从整体来把握。整个公司大概只有三个开发能从架构角度了解全局。而其中最重要的一个人,是个asshole。整个公司的人,素质好一些的都在尽力和他合作,素质差一些的整天在骂他。所有人都对他多多少少有点无奈。我曾经被他说哭过好几次。其中有时候的确是我的理解有误,如果我被直接告知我哪里错了,一般我会看我的错误并且觉得很羞愧。但是这个人指出错误的时候从来不说清楚,而且带着很挑衅的不客气语气,说着读不通的英语(印度人的英语其实是很好的,但是他一直散发着一种“我不care发表清楚的沟通”的气场)。

所以呢,开头说了,我来公司的第一件事就是写了个monitor系统,也算是watchdog的一部分,不过这是在产品之外的。我觉得很多真的产品开发,也是对他的整体设计不得要领无法写出integrate到整个产品的好东西,而是尽力保护自己开发的部分,即使冗余也不敢信赖已有的东西。我曾经听一个已经离职的开发经理说过,那个架构师的代码,即使他们看到有可以优化的地方,他们一般也不敢提建议。

虽然我并不下决心想做开发,但是看看coolshell博客,简直觉得振奋。也许我对技术的热情也是有点“希望保持业余兴趣”那样。按照引用的这篇文章,我并不是个合格的开发。我会的技术太少。专攻技术的问题在我们公司的开发中也很突出,甚至明明都是ETL的东西,A开发的东西B就觉得自己没必要去了解。更不要说大部分BI开发不懂java的部分,而绝大部分java开发的SQL水平在我看来简直小儿科。在这个工作中,我也试练了我的学习能力。写SP对我很容易(来自SQL和shell背景);查询MDX对我来说有点难:我按照MSDN上的教程自建了一个cube(当时我要就建cube的权限问题问了一个当时我们的cube专家,他都并不知道根本逻辑,只是建议我都用admin账号)、读了MDX Solutions的前几章;另外学会的是powershell。Powershell我不能完全说学会了,没有官方教程和完整的说明书(MSDN的结构太恶心了,PS的manual是和.NET的混合的),我看了powershell.net上的一个非官方教程,对变量、control flow、function、object等等理解了。但是后来看代码的时候还是看到了我本来不知道的东西。微软的环境很封闭,文档很难懂,依赖微软产品的我们公司应该也是直接间接受了影响。不过PS似乎代表了微软的进步(终于有比较成熟的script语言了)。最近又写了一点点python的脚本。

我愿意学习,也希望在厉害的开发环境工作。然而我更大的能力是沟通和英语水平。我这个没有计算机知识基础的人进入这个行业有一定的巧合,也一部分是因为这个行业发展快,还需要人手。看看我能找到什么机会吧。

这两天工作上发生了一件事,让我很难平静

这两天工作上发生了一件事,让我很难平静。

过年前最后一天(我买了五点半的电影票打算早走的,我知道过年前是最后能刷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才造成我从这么正确的起点开始都能走到错误的操作。

工作思考-2012

我觉得自己和去年的时候没有什么进步。离开上一份工作的根本原因是,我不看好他们的营业模式,和所处的行业。现在的工作的行业是所有人都能看出作用的零售行业,比上一份更合我意吧。而营业模式,在面试的时候很向往的Software as a service,真的就是这样的吗?我感到有点失望。

在商业还是技术这个选择上,我还是摇摆不定。我看不出自己有成为技术大牛的潜力,我也绝不可能充当纯商业的角色。介于两者之间,这个世界上应该是可以有我的位置的。

我一向是把工作看得很重要的。为的是什么?我想主要是为了自我发展。如今我很快地适应了新的环境,并取得了一些成果。但是我并不开心,因为似乎看不见自己的发展在哪里。公司里有Role Model的人物,但是离得太远了。我周围的人,似乎没有可以学习的人。理论上,我们公司还处于发展阶段,对个人还是有很多发展机会的;环境也比上一份工作公平。但目前,我还看不出自己在自己的发展这件事上,还有什么可以主动做的事情。

我现在常常会想起自己的第一份工作。DX说过的话,常常出现在脑中。不过我并不后悔当初出来见世面的决定。

又到调整期-跳槽

离职的打算,我是早就定下了。为了顾及大局,也是提前很多时候和上司沟通过。目前的工作,我能做好,但是没有发展空间了。本来,拓展我的内部客户,可以是比较愉快的工作成果,但是后来,任务繁重到了很不健康的地步。辛苦不要紧,对我自己的帮助却不大,我认为这时候,是该跳槽了。

接我的工作的,是两位应届生。交接的事情很早就开始做了,但是四年的数据库经验,是很难一下子传授给别人的。我只重点将文档交接给了他们。今天临走前,还在和他们说文档(第二遍)。我一直相信,经验丰富的一方向新来者传授知识的时候,前者需要更主动,因为能力大,责任也大。因此我本来一直很希望能够把交接的事情做得漂亮。结果呢,由于太忙,知识文档没有写好,值得作罢。

今天是最后一天,而明天立刻又要投入新的工作中去。这个时刻我只感觉忙和累。我觉得为新工作作的准备也不够。

想当初刚来安居客,我自认为起步做得挺漂亮。在入职之前,我就在考虑我需要了解些什么,可能的困难是什么。入职后吸取了多方面的信息,成长还是很快的。我对自己的成绩感到有点骄傲。

我似乎已经得出了对于我这样内向、有点迟钝的人,要做好事情的规则。内向的人也可以勇敢,想清楚的事情,就要勇敢去做。要尊重自己,但不要自尊太强……

……想来想去还是觉得,DNA那样丝毫没有恶意的幽默感,似乎可以给我力量击倒一切普通的困扰。而剩下的,则只有大的困扰了。大的困扰不会拖坏人,只会教人谦虚和懂得珍惜。

最近实在太忙了,在新工作入职前夜,我才挤出了这么点思索。换工作的一个目的也是希望能够把自己的节奏稳定下来。因为我想要的,实在太多太多了……

工作思考

距离第一天正式脱离学校踏入工作,已经四年了。我的感觉是更加久。我对工作、对世界的看法也变了很多。当然并不完全是工作造成的。人并不是在明处学习,更多的是靠自己学习。工作小结一般是领导要求写的。那么这篇日志我想要为自己写一写我最近一年对工作的小结。

我本来的态度是,工作上面的事情,是和同事、上级、客户等达成的约定,只要honor这个约定足矣。9个月前的跳槽,改变了很多我对工作的看法。Honor约定,只是一个基础。在我现在的公司,要做到这些基础竟然还是很难的,然而却还要求一个人有更多。

一个人在这个世界上,就是一只萝卜,除了自己的坑之外,能看到的事物很少。因此,虽然我之前的工作中,我非常重视的一些原则,在这份工作里被打破了很多,但是我仍然不后悔能够看到这么多新的事情。下面就具体讲一讲吧:

1)像DX那样视质量为第一,这样的态度是不是偏颇?我觉得,如果真的要建成一个好的东西的话,质量第一,反复review需求、设计和代码,是非常重要的。但是如果商业上需要不明确,那么开发就需要更加灵活。现在想来,DX商谈项目的原则,造成请他的team来开发是一件比较昂贵的事情。

2)我所处的部门,实际上是个很有利的位置。如果我有能力,我可以学习到各个部门的工作。近几年我都一直有这个愿望,它也隐隐一直在我心里,那就是去理解和我非常不一样的人。我也想知道这个世界是如何运作的。当初让我决定加入现在的公司,就是因为看到了Gary的职业化的风度。理解这个世界,理解各种人,想办法和他们合作。这种态度,不是向世界妥协的态度。我发现包容得越多,一个人的intergrity越强。

3)又能把握细节,又能high level对话,这是一种很强的能力。现在最困扰我的一点,是我似乎需要在上下之间做一个选择。我哪边都不舍得放。

对于我服务的目的,说到底当然是商业。我对商业的态度,已经不是觉得它是个necessary evil了。越看越觉得这个世界上,商业的力量太强了。

我一直都有原地踏步恐惧症。那么和在DX的时期相比,我到底有多大长进呢?我自己看来,已经觉得好恍惚。我很高兴DX时期我打下了比较扎实的基础,现在移植别的环境后,使用数据库方面,还有和开发的交流方面,都比较成功。不过我很害怕这方面我一直在吃老本,以后会老化。

一个进步是,我比原先对数据更加敏感了,因此也比以前更容易查出数据的问题。有时候我很奇怪为什么那些脑筋灵活、对系统更熟悉、逻辑思维比我强的开发同学会没有发现一些问题。后来我想,这是因为如今我站在了更高一些的角度。

现在的工作中,我还能学到、还能得到的,主要是商业思维方面了。对于这一点,我好像不是很有热情。另一方面,我也可以学习如何贯彻商业思维,略微插手一些/学习一些项目规划方面的事情。我想,类似BA的工作,在别的公司也会有需要的。也许我的定位可以是,既有技术sense,又有商业sense的项目管理者。