完美和新浪到底有多么不同?

今天听一些人讲了一些东西,收获很多。本来想写完美和我现在的公司有多不同,但是不敢,因为前几天我收到一封邮件,要求我别乱说话,并提醒我注意自己的人身安全,所以还是说sina吧。

老黄举了一个例子,msn网站 作为微软release周期最短的一个产品,平均2-3个月release一次。并且最关键的是,它是一个产品,采用一个版本号,整体发布。而不是产品线。老黄说,这是在做软件,而不是做服务。对于互联网的网站,应该是在做服务。

长久以来,我一直把完美和文思这样的公司统一归为软件企业。软件企业在做什么呢?我花2-3年的时间,做一个特别优秀的软件,然后卖出去。完了吗?没完。拿了钱就想跑?哪有那么容易。用户拿去用之后,不断会有新需求提上来,于是在产品卖出去之后,把绝大多数人慢慢砍掉去做新项目,然后留1-2个技术人员继续满足客户无休止的新需求、改BUG。

今天我在想,我这种观点是错的。魔兽多久发布一次补丁? 3个月,还是半年?而国产网游呢,几乎一直是在靠不断的出资料片,出新的节日活动拉拢用户。你说中国人每年要过多少个节日啊!!!下周就是圣诞了,管你信不信耶稣,不做个圣诞节活动,你好意思吗?一定要做,而且不能跟去年一样! 策划每天都想发新版本,不是往外面的正式服发,就是往外面的测试服发。一周发3-4个版本是很正常的。所以,魔兽世界,和完美的游戏,绝对是两种产品。我在完美后来过的很苦逼,名为主程序,实际不过是个发版本的,管理svn分支、build、release。

更惊讶的是,听老黄说,豆瓣是一个神奇的网站,持续集成做的特别好。发布一个新东西上线,从自动测试到部署完毕,也就4分钟的时间。我的第一个反应是,哇塞,完美你赶紧学学人家吧!我们可以少加多少班啊!可是后来一想,又不对。这事儿我都不用给panpan说,不等他开口,我自己就把我自己推倒了。因为问题不在这,游戏每次更新的时候,停机时间长不是因为程序造成的。

这个核心在于:完美注重结果,你的ACU,你的月充值,所有的中高层都能看的见。这就是你的KPI,在它的强大压力下,中间的一切流程化的东西都被弱化以至于消失了。以至于很长很长的几年里,游戏做线上更新一直跟QA部门没有什么关系。你对你的结果负责就好了,你不求我帮你测,我干嘛帮你测?

直到有一天,我们项目竖立了一个典型,怎么因为一个非常小的程序BUG,流失了很多很多用户,然后大幅度影响当季度的利润,以至于CEO必须在财报和投资者会议上解释这件事情。Ok,开始注重过程了。

然后呢?确实发现了一些共同之处,不论是互联网公司的产品,还是完美的游戏,自动化测试,要么没有,要么形同虚设。总之它在产品发布过程中的影响微乎其微。不同点?在我现在的公司也好,在sina也好,一问这些,对方就会给你讲Jira,讲hudson,讲puppet/cfengine等等。而在完美,只能笑而不语,把你拉进发版本的RTX群里去,你慢慢琢磨去吧。因为这些东西真是完美的最高机密啊,核心武器啊。完美做了这么多年的游戏,最大的积累是什么?不是引擎代码,而是编辑器,以及流程!普通员工顶多能看见大象的一只腿,慢慢爬吧。

Sina更依赖于jira这样的软件,反复的在强调jira怎么用,而完美更强调的是人,因为做管理的是人。回到上线那个问题。完美有它的缺点,自动化工具做的不够完善。但是这是小问题,因为反正咱们都得做测试,也都没有自动化测试,所以,测试的时间和4分钟的部署时间相比,后者简直是浮云。再比如版本回退、服务可用率等等,完美有很多可改进可提高的地方,但是,总之,这不是核心问题。在我看来,更为核心的问题是,如何把一个庞大的线上服务拆解成一小块一小块的,分别改进,各自升级。这是新浪也好,土豆也好,完美也好,都很值得去做的事情。

因为,我们是互联网行业。无论是计算机硬件的处理能力,还是我们所面临的市场环境,每年都在发生变化。3年一小变,5年一大变。一个互联网企业想屹立不倒,必须持续的进行产品创新、技术革新,不断的对线上服务进行升级。无论是做游戏还是做网站,都是如此。可是有时候你发现你根本动不了,不敢动。祈祷着它只要别坏,能正常跑着能赚钱就行。

在这个问题上,完美有两个优势。首先,完美有统一的技术架构,网络协议格式啊,数据库啊,大家都一样。关键是我按我自己的规范来定义协议,而不是今天google protocol buffer,明天apache avro。其次,完美可以不断的重做,出新产品,而把老的几乎放弃。互联网公司可不行了。拿sina来说,发布系统跑了好多年了,假如要做一个全新的,实现现有的所有功能,不仅因投入巨大而很难获批,而且,总有些需求会被遗漏掉,因为需求太零碎了。于是你就会被困住。

在网上看PPT的时候,架构师总是在忙于炫耀自己承担了多大并发,以多么低的成本,灾备做的多么好。但是就我自己而言,只能高山仰止。从来没有任何一个公司是请我去解决他们解决不了的技术问题。我所面临的所有性能问题都可以通过加机器、加内存、加带宽来解决。地震把机房震垮了的事情我也从来没遇到过,相比于地震来说,更可怕的是,需求变更!一个非常频繁,又次次欲致人于死地的东西。

所以,如果某一天我的名片上写上架构师的title,我希望是因为我把庖丁解牛神功练到第六重了。

顺便说一个具体的技术问题。Google于某年某月某一天,把它的自动化测试框架开源了。于是就有人把它做成package包,塞到操作系统的各种发布版里面去了。但这样做是不对的,因为“环境不一样”。这也是我所要警惕的,千万不要把一个公司的成品,带到另一个公司去。保留思考的过程,到新公司重新想一遍,也许结果是不一样的。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥