Shell's Home

Aug 4, 2011 - 1 minute read - Comments

估算(一)

出租车价又涨了,贝壳好奇出租车上面水到底多深,就找几个师傅了解了一下行情,大家看看吧。 首先是油价,目前是7块多,不到8块,按照7.5算。出租车都不太新,每百公里油耗不小,按照8-10算不过分。一般出租,只要在市区跑着,平均速度大约是40公里/小时。司机都是24小时轮班制的,做一休一。平均做一天,大概上缴330-380不等的出租车管理费。以上就是大致的原始数据。 一天24小时,大约要跑960公里。乘上油耗,大约是86.4升的油。折合价格,大概是650上下。这是工作一天的油价。 师傅做一休一,一个月只能做15天。按照税前4500的工资算,一天要赚300才能做平。对于老驾驶员,还做一休一来说,这个价格不算太高。去掉三金和税,还剩下3650。 一天管理费350,一个月师傅这里能缴5250的管理费。但是三金就要缴掉2000,还剩下大概2000是真正的管理费。 我们综合来算,一天的成本是1300。 平均里程费用的问题,其实有点复杂。不考虑夜程,大概可以用3.5算。大概原理是这样的。 3公里以内,14元。就算正好3公里,费用还是4元多。不足3公里平均费用更高。 3-10公里,一公里2.4。最低值平均费用4.6,最高值平均费用3.1,最终得到的平均费用都介于两者之间,里程越长,平均费用越低。 10公里以上,一公里3.6元。总平均费用会从3.1逐步上升到3.5左右的样子。 从区间函数变化可以发现,出租车费用最低的区段大约在9-11公里之间。6公里以内的费用最高,12公里以上的费用就平均了。注意,以上计算都是时间-距离折算计算,即时间延误被乘以系数加到距离上了。实际出租车计价表也是采用的这种算法。 中途插播一句,如果是多人短途,例如三四个人2公里多。或者8-10公里的地理距离,价格在28-35上下,都是比较合算的坐法。出租替代公交的成本不高。 1300的成本,除以3.5的公里费用,得到371公里。加上各种余量考虑,出租车司机一天最高驾驶1000公里,实际400公里有客就可以收回成本,即空载率不应低于40%,否则就亏本了。 我们观察成本,发现一半多的大头多来自油价。难怪每次油价变化出租车师傅都一脸郁闷。 对抗油价变化的方法也很简单,就是等车,减少空乘移动。从上面数据可以看出,每公里载客可以赚入2.8元,一天的除油费成本650。如果每次载客结束都是当场熄火等待乘客,只要232公里就可以收回成本。所以我们经常可以看到机场或者各个地方的司机师傅,排长队等车。而且油价越高,师傅移动拉客的成本越高,越趋向于等车。 一个师傅每个月缴2000的管理费,上海大约是5万到10万辆出租,一辆出租两位师傅轮流开。一个月给各个出租公司上缴的管理费大约是2亿到4亿。 出租公司要负责车辆管理,叫车电话服务,人力资源,还有无线电调度,是有一定开销的。车辆管理的费用浮动,不大好算,然而普通人的车辆,一次养护成本大约是1200,一年一次。我们假定出租公司成本翻倍,一辆一个月200,全上海的车辆维护大约是1000-2000万。叫车电话,调度管理按照1:100的管理比例,需要500人持续管理。按照合三金工资4000(对于无技术的接线员来说,会比需要技术,连班转的出租师傅工资低)计算,大约是200W一个月。无线电调度不是很清楚,应该没有特别高的成本——除了牌照一类的问题外。 满打满算,各家公司的总开销,加上正常盈利,一个月5000万已经足够。那么2-4亿中的其余部分到哪里去了呢?是成为了出租公司盈余,还是成为政府管理拍照费用,这就不得而知了。 以上数据,都是2011年5-7月间,和各个出租师傅聊天时提到的。大部分数据都是经过一位以上师傅的口中说出,有一定准确性。然而由于仅听取了同一利益倾向的所有当事人,所以数据可能有一定误差。

Aug 3, 2011 - 1 minute read - Comments

如果你的python项目一定要源码保密,你一定用错语言了

python的特征在于快速编写代码,快速运行得到结果。通常而言,就是高开发速度。 如果你的项目需要源码保密,那通常不会是高速开发的项目。因为能够高速开发的,就能够高速复制。别人在看到你的概念和基本逻辑后,可以非常快的抄一份出来。代码什么的根本是浮云。

Aug 2, 2011 - 1 minute read - Comments

除虫故事(二)

第二个故事,是一次oracle数据库的紧急损坏抢修问题。 当时客户紧急保修,系统无法继续工作,重启后无效。我们就找了DBA赶快飞去客户那里。客户有两台应用服务器和两台数据库,应用服务器组成热备的态势,数据库组成RAC。数据保存在一个SAN盘阵上,LogFile放本地,ArchivedLog使用备份脚本复制到备份服务器后删除。听起来是挺靠谱的方案,没想到就坏了。 去了后,客户说暂时恢复了运作。然而我们还是要出具详细的报告,因此赶快去了机房。贝壳第一眼看的东西,就是/var/log。里面的报告是err9,也就是文件读写错误。oracle一切正常,应用发布服务器一切正常。 这下有点抓瞎了,难不成要出具一份报告说SAN盘阵损坏?可是损坏也得有厂商来维修,说坏得有真凭实据阿。现在SAN一切正常,这个报告怎么写呢? 说来算巧合,贝壳检查磁盘的时候,顺手打了一句df -h进去,看到磁盘空间已经用掉了80%以上,顺口问了句DBA,如果空间耗尽会如何。DBA说会挂起,和目前状况一致。贝壳顿觉狐疑,是不是空间耗尽呢?是的话,为什么会神秘的恢复呢? Oralce的运作非常精巧,也非常复杂。当一条SQL语句执行的时候,先写LOG,然后操作数据,最后再将结果写入LOG。当出现问题需要复原的时候,根据某个时间点的数据备份,和整个运作过程中的所有Log,就可以复原。但是LOG写出的时候量非常大,没有无限的空间给他写阿。所以LogFile的设计是文件循环,当写满一个文件,切换下一个文件。一个文件写满后,就会有一个服务,趁着磁盘空闲,将Log压缩备份为ArchivedLog,然后再将这个文件的状态变为Empty。 我们的设计,是通过脚本备份ArchivedLog,除去最后一个文件外,复制到备份服务器上,然后删除。但是我们对ArchivedLog的量估计不足,一天清理一次,分配空间只有20G出头。系统开始的时候压力不高,因此绰绰有余。后来压力逐渐升高,这天的操作比较多,ArchivedLog量大了点,导致空间写满。当ArchivedLog空间满之后,备份进程就会报告错误,这就是/var/log下面err9的来历,因此LogFile无法备份出来。当所有的LogFile被循环写满后,SQL执行前试图写入LogFile失败,执行就会失败,然后挂起在那里。这导致了所有应用发布服务器的失效。 备份脚本的设计是定时和开机结合的,在客户第一次重启设备的时候,已经执行了备份脚本。然而备份动作需要执行相当久,中间客户又重启了几次,导致备份工作进展缓慢。直到半个小时后,第一份ArchivedLog才备份出去。然后清理文件,开始LogFile的备份,大约执行了一个小时多。此时服务就突然恢复了,因为空间问题已经暂时解决。而后是不断的ArchivedLog备份和LogFile的备份的平衡,直到我们到的时候,LogFile已经全部空了,ArchivedLog还没有完成备份。因此我们才能抓到最后的尾巴。 反过去检查备份脚本的执行记录,基本验证了这个想法,客户也接受了我们的报告,不过还是要责令修改系统——这是后话不提了。 这个故事里面,至少有几个教训。 对于所有编程时无关紧要的假定值,在开发时可以胡给一个差不多就行,但是上线的时候必须重新分配合理的值。因此必须将这些假定值记录出来,否则从程序中找出假定值来本身就是一个非常困难的事情。 确实运作一下,搞清楚运作方方面面的问题,不要想当然,觉得没问题。就算运作了没问题,在时间的考验前都没人敢保证没事。 一套系统,尤其是大型复杂系统,必须有懂得运维的人员接手管理。检查磁盘IO,CPU压力,内存和磁盘用量,数据量,网络响应速度等等问题。 废物Log不要乱出,太多的Log和没有无异。如果早关注备份脚本的执行记录,就能早找到问题。可是由于量太大,我都是过滤掉了看的。

Aug 1, 2011 - 1 minute read - Comments

除虫故事(一)

汽车对冰淇淋过敏的传说都听说过吧,贝壳也说几件故事。寓意什么的就别提了,当个故事听吧。 第一个故事,是一个传奇的问题。贝壳早在02年的时候,就在家里弄了两台电脑。互相用网线一连,组成局域网打游戏。当时流行的游戏还是Diablo II,当然,这东西的III已经叫了10年,还没出来,接近永远的毁灭公爵。两台机器之间的游戏打的很流畅,一点异常都没有。 当年文件共享还是有很多问题的,尤其是连续的几个蠕虫,有志一同的使用了windows的samba系统。所以安全上说,贝壳舍弃了windows文件共享,使用ftp方案。当年还流行用ftp开自己的文件资料共享站,贝壳就用雷电自己开了一个。现在基本看不到了,基本都是用网盘或者p2p。问题就出现在这个文件传输上。 文件传输的速度常常限制在1-3K之间,速度死活上不去。结合Diablo II可以正常工作的事实,贝壳的初步结论是ftp系统问题。然而从外网测试的结果,ftp站点一切正常。那么ftp客户端呢?经过测试,这个客户端软件和配置在外网上访问贝壳自己的站点是正常的。 那么从表象上看,问题就在客户端所在的机器上了。贝壳检查了机器的网卡和系统驱动,又重装了系统,问题仍旧没有消除——似乎有点奇怪吧。而且推理上说,如果机器有问题,Diablo II也不会运行的如此流畅的。 好吧,我们揭晓谜底。问题出在两台机器相连的一根网线上。这根网线质量不好,有一根线时通时断。结果导致ip数据包概率性不一致。ip是不管peyload一致性的,但是tcp管阿,结果导致大量的tcp重传。tcp是一种慢启动协议,因此速度死活上不去。 至于Diablo II可用的问题,则是因为游戏的数据量少,包也小。因此即使慢启动,数据也可以很快重传,导致虽然有问题,却不能很直观的被发现。 这个问题,直到贝壳无意中更换网线才被发现。但是细究推理,却是合情合理。算是一场灯下黑吧。

Jul 27, 2011 - 1 minute read - Comments

给初创小公司的几句话(三)

第三篇故事,是来自于贝壳自己的惨痛经历,在另一位朋友那里也有类似教训,可惜他未及早听我一句。 贝壳原来在一家公司里面做项目经理,公司做企业定制开发,现在仍在,所以具体情况隐去不表。因为某些情况,老板叫贝壳做了项目经理,按照资历和能力来说,其实并未足够。贝壳精通的是C++开发,而项目是使用.net技术做的。因此贝壳对项目的管理能力实际上打了一个折扣,只能负责结构设计和协调。当时对项目管理也不是很精通,可以说是半吊子水平。公司承接了一个企业的业务系统开发,经过前期准备,我们团队就开去了客户那里进驻。客户要求,界面一定要漂亮。因此我们选型下来的结果,使用了.net 3.5的wpf开发。开发过程中其实还是有很多问题,很多都是新手问题,暴露贝壳总体设计和项目把握的缺陷。不过这和今天主题无关,就略过不谈了。主要是.net 3.5开发,到了最后发生了几个严重问题。 首先第一个问题,是客户有很多win2000机器,甚至还有一些win98。这个在当初系统设计的时候完全没有考虑。我们开发的机器一律全是winxp,.net 3.5 wpf可以完全的运行在上面。而对于win2000,wpf是无法安装的。于是,我们就必须要求客户升级到winxp。企业用户,他们还必须使用正版。其次,.net 3.5在进行远程SOAP调用的时候,会出现严重的内存泄漏。其实并不是真的泄漏了,.net 3.5的SOAP系统没有考虑调用接口可能多达数百个的情况,对每个函数都进行了序列化器缓存。这个缓存会耗费100-200M的空间,加上其他开销,我们的系统总开销是200-300M,比大部分游戏还高。这个直接导致客户运行我们系统的时候,必须多加一倍的内存。 更郁闷的问题还在后面,wpf是使用dx渲染的系统,因此如果客户没有独立显卡,系统速度就会慢如龟速。wpf的部署必须使用完整sdk,2.0的runtime安装包只有20M,而3.5的完整sdk高达350M。我们在每台机器上安装的时候都是用U盘完整安装350M的sdk。不过这都不是最郁闷的,最郁闷的是,我们项目最后问题实在太多,有个员工做了一个web版的。界面难看很多,但是方便移植部署,内存消耗小。瞬间得到全企业上下一致支持,他们的老板还问我们,当初为什么不这么设计。贝壳哪里好意思说,您不是要漂亮么? 实话说,要不是老板和客户关系好,我们非要给愤怒的客户踢出大门不可。这一个项目,成功的是老板,失败的是贝壳。 总结下来,两个教训。首先是设计必须实地的调查一线需求,不能光听上面的就得出结论,也不能光看部分典型用户就得出结论。如果有一些关键用户对构架支持不良,业务上又不能放弃,就必须权衡得失,甚至修改构架。如果当时我们知道win2000乃至win98的事情,就压根不会考虑使用wpf来做界面。第二个,就是不能迷信技术,或者激进的使用无法掌控的技术。宁可使用最土的办法,老老实实的把业务做出来。新技术由于刚刚出现,因此很多问题都没有完全暴露,很多领域也没有经验积累。例如这个例子里面的内存占用问题,安装包问题,系统问题,都是到了部署时才发生的问题。使用新技术,就会随时面对无人发现的问题,这和RPG的踩地雷战斗是一样的经历。只是这里不但没有经验值,而且踩多了还会直接挂掉。

Jul 25, 2011 - 1 minute read - Comments

动车追尾事故的几句

扯死多少人追责是没意义的,搞清楚究竟死了多少人,他们都是谁比较有意义。反正我们都知道,中国官场历来有控制死亡人数的习惯,去佐证这个有任何意义么?我对死亡和失踪人员名单更有兴趣点。如果家属觉得感情难以接受,隐去具体姓名并注释即可。至于死亡人数,我估计在不到百人左右。两辆可乘千人的动车相撞,又都基本满载。在对撞的时候,释放的能量是速度的平方。速度增加一倍,破坏力大概增加三倍。加上前面说漏嘴报的是63,估计差不多吧。 新浪的一个图转了一个机车人员对事故的看法,实话说没看懂。但是有一点很有意思,为什么同样被雷劈,前车无动力,后车却高速撞了上去?如果雷击集中在前车,导致车上所有电子设备全部损坏,也是说不过去的。就同一个图所描述的,还有一个装置判断两车距离,方法是使用电阻。实话说这个方法太漂亮了,基本只用到高中知识就能想通,展开说一下。 两个平行铁轨,我们可以看作是一个无限长电阻。不考虑岔道的情况下,两个铁轨间的电阻应当是无穷大。如果有列车在上面驶过,就会接通铁轨,导致电阻下降。利用这个原理,在铁轨上每一段距离就设一个电器设备,计量电阻。如果有列车试过,电阻下降,灯就从正常转入黄色,红色。驶过后电阻恢复,灯又转入正常,后车只要看前面一段距离的铁轨设备就知道是否无障碍了。不仅是火车,上面有卧轨应当也有可能查出来。如果前方铁轨装置损坏,那么后车什么都看不到,一样应当停车。 结论?这必然是切掉设备辅助,人力操控才能发生的故障。 上次落雷停车,有专家出来说是好事。某种意义上说,他是对的。如果不是因为落雷导致停车给铁路部门太大压力,有可能,当然,只是有可能,这次落雷就不会有人要求强行运行。老老实实的停车,也不会死这么多人。 舆论杀人?别逗了,落雷停车一次是正常,一个月连着两次,是设计问题。 埋火车的事,先别着急定论。毕竟这是埋掉,而不是烧掉。现场还在地下,同类火车也有不少,说湮灭罪证不合情理。但是要说恢复通行,更加不合情理。地面上难道放一节车厢的地方都没有么?还是埋车厢比拖走更加省力? 主管官员走了谁又来了谁很重要么?你觉得换上谁才能让我安心坐火车? 飞机票又要涨价了。五年前,我说飞机比火车安全,大家不信。现在出了事情,估计大家要去坐飞机了吧?现在我说飞机比火车危险。国航的老飞行员,原先是属于空军的。飞行时间非常长,经验丰富。后来中国飞行事业蓬勃发展,飞行员供不应求,后面的飞行员都是标准培训出来的了。不是我鄙视培训学员,但是要他们和数万飞行时间的老飞行员比,还不够格。问题是现在只有培训学员。 从北京到上海的最佳方法是什么?火车会被雷劈,飞机会误点,开车交不起高速费,走路不安全。从一个海中城市到一个海边城市,最好的方法当然是坐船。

Jul 21, 2011 - 1 minute read - Comments

给初创小公司的几句话(二)

上面一篇,贝壳说了说老板搞外行指挥内行的问题。这篇反过来,是我一个朋友X的经历。他经历的更加的传奇一些,是一个内行指挥外行的经历。 X是一家外企的程序员,原本这家外企没有IT部,后来为了做市场,于是成立了IT部。他是头一批的老员工,情况和贝壳类似。在他们之后,进来了一个很有水平的程序员Y。Y的水平很高,所以很快的就成了IT部实际的领导人。原本的外企中方经理很是器重,承诺分一定的公司股份,但是要求IT部能够达到一定目标。例如流量多少,来多少IP访问等等。Y很快就带领整个IT部开始行动了,需求分析,计划制定,时间节点分布,系统架构,都很中规中矩。SSH开发网站本身就是一个中规中矩的过程,没有太多的创意可说。半年不到,系统就上线了,基础测试通过,公司上下都很开心。 问题发生在Y拿到公司股份之后,通常按照协议,股份是不能很快变现的。我不知道Y和公司怎么谈的协议,X君作为一个局外人,也只能告诉我一些小道消息。据说Y的股票居然很快就出手了,而后Y君很快的辞职,开了家咨询公司。 而后公司系统陆续发生了一些问题,本来很稳定的流量一下缩水到几分之一,而X君说,他们的营销策略从未有大的改变。更麻烦的是,系统总是出一些莫名其妙的小问题,经常无法访问。公司没办法,只能高价请回Y君来解决。每次都是问题很快解决,但是另一个问题又再出现。几次往返后,公司实在不堪忍受,就再找了一个高手进来看看系统。X君说,人家上午过来,下午走人。说从未看过如此混乱不堪的代码,几乎没有可维护性,建议直接重写。 然后公司就陷入了两难,要不要重写呢?不重写,这个系统显然没有任何继续发展的可能。重写,又如何保证新来的工程师不会搞出这种不可维护的系统。 据说,到X走的时候,中方经理已经被迫辞职了,外方决定找印度阿三来解决这个问题。当然,后面就是一个新的传说了。 整个事情好像是一个职场阴暗面的故事,感觉平平无奇。不过实际上,整个故事还是有几个神奇的地方存在的。首先,公司没有做过Y君的背景调查么?还是说Y君以前一直OK?其次,通常股份都是不可立刻变现的,必须经过三到五年,其目的就是防止这种事情。类似的条件还有无法转让什么的,都跑到哪里去了?最后,公司所有人,包括X君在内,没有发现Y君的系统是不可维护的么?我始终感觉这个故事的背后还有其他故事,只是这已经不是我们讨论的要点了。

Jul 20, 2011 - 1 minute read - Comments

重分区和lvm

上篇btrfs会导致虚拟机慢死的blog都看到了吧?看到了就不多解释。 首先,删除掉cache数据,还有冗余数据,使得数据可备份化。然后执行rsync -av /home /mnt/mdisk/sync,将数据同步到备份的移动硬盘上。之所以用rsync,是因为我在备份的时候还能看看网页什么的。等第一次备份完成,关闭所有X程序,退出shell这个用户的所有进程,然后再次执行rsync,就可以保证同步。同步完成后,注销/etc/fstab下面的/home和swap项目,重启。 系统启动后,先登入root用户,因为此时/home已经恢复到了/下面,所有shell用户的home路径不存在。建立/home/shell目录,并且复制/etc/skel配置,修改owner后,shell就可以登入了。当然,此时是系统默认环境,并没有定制化。没有关系,我们只需要terminal。在terminal中执行gparted,会出现图形的分区管理工具。当然,理论上说,如果你够熟悉,使用fdisk完成全部操作也是可以的,这免除了初始化shell用户和登入图形界面的麻烦。删除原先的/home所在分区和swap所在分区,切割一个ntfs分区用于将来安装windows(回头可以打游戏),剩余的全部切割,而后开启lvm标记。当然,这一步贝壳当时不知道,而是创立了一个未知分区,再用fdisk调整分区类型为8E。而后系统会提示你,不能保证内核数据结构更新,需要执行kpartx /dev/sda。无论如何,此时我们已经有了一个lvm分区。 lvm的结构是pv -> pg -> lv,也就是物理卷->物理组->逻辑卷。物理的各个分区首先被组织成物理组,再被划分为逻辑卷。这样设计是因为可能有多个磁盘上的空间,被划分为多个逻辑卷。在不改变逻辑的情况下,lvm的默认组织构型是raid0的。不过这对我不是个问题,我只有一个磁盘。 首先创建pv,使用命令pvcreate,没什么好多说的。然后是产生vg,使用vgcreate main /dev/sda7,之所以需要main,是因为需要一个vg命名。而后我们需要从这个vg中创建出一个lv来,执行指令lvcreate -L150G -nhome main,设定lv的名字叫做main-home,大小150G。此时在/dev/mapper/main-home,就产生了一个设备文件,大小150G,可以当作/dev/sda1之类的设备一样使用。不过,这个设备没有经过任何格式化过程,所以还需要mkfs.ext3 /dev/mapper/main-home。在这个指令后,我很习惯的跟了一个tune2fs -c 0 /dev/mapper/main-home来关闭重启检测。使用blkid,发现这个设备已经成功创立,并且有了ID。把UUID复制进(这时就知道X的好处了,console下面比较绕路)/etc/fstab,并且修改刚刚被注释掉的/home一行,更改UUID和分区格式。贝壳当时光记得复制,忘记改分区格式,导致系统进不去。不过也不困难,修改/etc/fstab后mount -a一下就可以了。 此时我们已经建立了有效的逻辑卷,并且正确配置。下面要创建一个交换分区,并且挂上去。废话不多说,lvcreate -L6G -nswap main,mkswap /dev/mapper/main-swap。而后一样blkid和vi /etc/fstab。系统就基本配置好了。验证一下看看。 shell-deb:\~\# pvs PV VG Fmt Attr PSize PFree /dev/sda7 main lvm2 a- 229.19g 73.19g shell-deb:\~\# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert home main -wi-ao 150.00g swap main -wi-ao 6.00g 而后就是新系统的启用过程,首先要退出X,注销shell用户的所有进程,然后以root删除/home下的所有数据。如果不删除的话,重启后,这里的数据无法访问,变成垃圾。而后重启,就可以看到正确结果了。不过还不要着急登入shell。首先执行rsync -av /mnt/mdisk/sync/home /home,将备份同步回去。这样我们登入shell的时候就可以看到有效的定制化界面了。另外一点细节是,mdisk使用了ntfs格式,所以导致数据恢复后属性混乱。使用find . -type d -exec chmod 755 {} ;和find .

Jul 19, 2011 - 1 minute read - Comments

btrfs上使用虚拟机效率很差

试图在linux中使用虚拟机的同学请注意,刚刚测试下来的结果,vmware和kvm在btrfs上的IO效率极端的差。 首先是vmware,win2003,512M的实例,开机大约需要40分钟。这种效率已经远远超出了我的预期,于是我改用libvirt管理的kvm。结果依然出乎意料,debian实例的安装需要超过5分钟。由于怀疑是raw格式而非qcow2格式造成的速度差异,因此新建了一个实例,一时偷懒就放在了/下面,这个分区是ext3而非btrfs。结果安装大约在3分钟内结束,这似乎证明了我的猜想。于是我开始使用btrfs下的raw格式进行安装,结果速度依然异常缓慢。由此我怀疑到是btrfs文件系统的问题。 在ext3上创建一个qcow2格式的实例后,证实了我的猜想。问题在于btrfs的某种机制上。在网络上寻找类似问题,并没有发现。因此在blog上提出警告和问题。 有人知道为什么在btrfs上使用虚拟机会导致极端的效率问题么?hdparm和文件读写测试表明btrfs的平均效率并没有问题,磁盘也没有问题。

Jul 18, 2011 - 1 minute read - Comments

一个初学者的问题

今天挺高兴的,因为我看到了一个新手在我的blog上面留言提问。问题摘抄如下,我想他应当不会介意我合理引用吧。 贝壳老师,我是一名大三的学生,下半年马上找工作了。没做过什么项目,编码能力较差但是对技术还算热忱,您觉得在国内做技术40年现实么? 我觉得他的问题比较散,题目也比较大,就专门开了一篇来回答这个问题。 技术40年是个梦想,电脑出现不过60多年的事情,做40年技术的本身就是凤毛麟角,没什么可比性。我认识的做技术的人,最多的是做了将近20年,已经是超级老程序员了。以中国的状况,对做技术的不怎么有利。通常而言,如果你做了五年程序,还是没有什么大的进展,你就会主动的换岗位。因为一般人做了五年程序,却还没有达到一定的程度,周围房子妻子日子会一起压过来,不由得你不担忧你的将来。国外程序员并不背负这么大的压力,而且工资相对平均而言比中国要高一些(当然,国外程序员的工资也在逐渐降低,因为大量的离岸外包)。一般来说,程序员转行最多的是去做管理,也有不少做风投的。出结果的少,多数就默默无闻,只有少数日子过的很惨。 如果你在五年程序生涯后,逐渐确立了自己的风格,并且取得了一定的成就,多数人也不见得继续做程序。大部分人都开了公司,给自己当老板。中国的劳资关系很奇怪,资方比劳方有利的多。混的不错的人,但凡手里有点积蓄的,无不想成为一个资方。我认识的很多老程序员,大都自己开了公司。或者是外包公司,或者是技术公司,但是持续在一线写代码的人却不多了。除去自己开公司的,大部分在大型外企做了技术总监,这些一般是比较有志于技术的。在私企混技术总监的,如果有点年纪,多数都是靠着人脉而非技术坐稳位置的。当然,这不代表我看轻私企的技术总监们的技术。 中国做技术转型快的根本原因,在于不成比例的回报。技术人员要承受长达五年左右的成熟期(http://blog.shell909090.org/blog/archives/139/ ),而且必须全力投入。相反,通常成熟程序员的工资,在写文的时候只有6-8k。加上经验积累,大概在10-12k左右的样子。而做的好的销售可以轻松拿到15k以上的工资,其他途径(大家心照不宣)更多。技术人员还需要忍受技术退火的问题,每五到十年需要重新学习大部分知识。这使得技术人员的投资回报比例低的不像话。 另一个雪上加霜的问题,是中国的盗版问题。中国目前不仅在操作系统领域盗版,而且美剧、动漫、音乐,乃至于创意,皆是盗版,无不山寨。作为用户来说,这给你很廉价的服务。不过对产业而言,这是致命的。目前中国根本没有人真的是做产品的,基本都是抄产品的。产品经理最大的任务,就是根据已有的产品抄一个,然后做一些细节修改,并试图用细节打败对方。在这种思路下面,谁需要用高薪的,有经验的程序员呢?新毕业的学生足以胜任大部分工作,关键是新鲜热辣成本低廉。 上面说了一大通,其实根本没有说到关键问题。你说自己对技术还算热忱,我不知道你热忱的原因。如果你因为技术能赚钱或者很酷,我强烈建议你放弃。和电影里的不同,技术并没有那么大的好处。真正能赚钱的不是技术,而是能用技术解决问题,这个所需要的能力和技术截然不同。也许你会举出Bill Gates和Steve Jobs的例子,我知道你还能举出很多,但这不改变一个事实。他们是用技术解决问题的人,而非仅仅有技术的人。反例你可以看看SGI和SUN这两家公司,都是技术人员的圣地,然而都是悲惨收场。所以如果你打算赚钱,技术不是你要追求的第一要素。也许你会关心,什么才是用技术赚钱的第一要素。这个问题没有标准答案。google用丰富好用的程序赢得用户,apple用良好的设计赢得用户。每个人对这个问题的解答各自不同,知道正确的解答,基本就可以迈入赚大钱的门槛。你觉得我像赚了大钱的样子么? 如果你觉得会技术很酷,我觉得你会落入嬉皮士和脚本小子的范畴。国内能用各种工具扫描网络,破解密码的人非常多,但是能知道各种工具背后工作机理的就相对少。至于能够研究出一种机理,并且写成工具的,可以说屈指可数。实际上,真正酷的是最后一种人。然而大部分人,仅仅是拿着写好的工具,偷盗别人的密码,或者是删除别人的数据,就感到自己似乎拥有力量。这是一种错误而危险的想法。好比你买了一把万用开锁工具,和一把电锯。趁着屋主不在,偷偷溜进人家家里大肆破坏,你觉得有什么成就感呢?这和偷密码,破坏数据是同一类事情,为什么大家会觉得入侵服务器很酷呢?反之,如果你用三年的所有休假,研究了市场上所有的锁,并且一一给出了开锁方法。我想电视台会对这个主题更加有兴趣一点。如果你真的觉得技术很酷,我想你应该仔细研究技术,成为最后一种人。哪怕你最后成为了一个黑帽子(利用技术作恶的黑客),也好过仅仅做一个脚本小子。当然,如果可以的话,白帽子更好。 最后一种可能,是因为你真的喜欢编码。那么,你就必须忍受长时间的编码,旁人怪异的眼光,家人的不解,没有MM,没有休假。在这里要感谢我的老婆,感谢她对我爱好的支持和理解(虽然她不能理解这些技术),否则我得继续打光棍到不知道什么时候。不知道你是否听说过RubyvsPython,我们这帮宅男把编程作为工作,把下了班凑在一起写程序作为一种娱乐。如果你真心喜欢这样,我很欢迎你加入我们这个圈子——当然,多数情况下,这意味着平庸的,和投入不成比例的工资,还有无尽的bug地狱和加班。 如果你没有做过什么项目,我建议你看看我前面写的,如何参与一个开源项目( http://blog.shell909090.org/blog/archives/1848/)( http://shell909090.org/blog/archives/1821/),找一个合适的项目先做起来。你甚至不需要有编码经验,别人也会欢迎你的工作。这对你找工作很有帮助。 另外,如果你打算找一个编码工作,实际的演练一下编码会比较好一点。无论是需要你进行编码的厂商,还是技术上的进步,编码能力都是一种必须的,重要度远远超过英语的能力。当然,比这更重要的能力是阅读代码的能力。当你能够从读者角度考虑,写出适合人类阅读的代码,这就意味着你开始迈向一个新的编码境界。