2013 年个人总结

2013 年就要过去了,我很怀念,这一年有我忘不掉的一些事。

我最好的产品于今年八月九号面世: 女儿出生,起名「苇杭」。这个名字来自《诗经·国风》,「谁谓河广 一苇杭之」,这句话有一种达观的寓意,我很喜欢,其中的「杭」也有在杭州出生的意思。女儿出生前我总没来由的各种担心,直到听到她的哭声我悬着的心才安定下来。感谢我那伟大的老婆大人,感谢家里人对我们的支持和照顾,现在女儿四个多月了,茁壮成长。我对她最大的期望就是将来能健健康康,快快乐乐。

今年有不少时间用来运营微信公众帐号「小道消息」了,在最初的那段时间里,这是一件非常有乐趣的事情。现在回顾一下,这一年在这个事情上还是花了大量业余时间,说不消耗精力是不可能的。因为「小道消息」的缘故,经常被当做「自媒体人」来对待,以至于还接受了一些采访,后来我觉得自己还是应该从这些事情上抽身出来,各种喧嚣的声音其实和我无关,我只需要写东西就可以了,如果实在没时间或是厌倦了,就休息一下。

我在「小道消息」上犯过的最大的错误是不该去弄那个「小道盒子」。初衷其实是好的,希望能帮助一部分人看看墙外的世界,但实际操作起来却事倍功半。几边不讨好,用户用起来问题多,反馈到我这里我也处理不了,然后到技术支持方,也就是我的合作方那里,资源又的确不够,给他们也带去不小的麻烦。最终导致这个产品很失败 – 如果说是一个产品的话。而收益呢? 也算有一点点,最后基本也都补贴到里面去了。现在总结这件事,可以说给了我很大的教训,差点把人品折腾光。有那个精力我完全能做很多更重要的事情。

这一年在微博上打了不少嘴架,可谓树敌无数,新的一年,当戒之慎之。

今年我所负责的技术和产品团队从目标上看,做得还不错,比如我们的移动 App 方面,去年计划的移动产品几乎都做完了, Web 产品改进也不少亮点,我觉得很欣慰,但是,凡事就怕有个但是,过程并不好。而且,技术团队在下半年出现了一定程度的人员流失。虽说部分团队成员的新机会都不错,但我觉得团队还是有问题。如果团队有问题,责任肯定在我。你看,有那么多时间写「小道消息」,哪有精力管理团队? 虽然我还没收到这方面的指责,但我觉得如果有的话,我也无从反驳。对于团队同事的离职反馈,有责改之,无责加冕。毕竟这是个还算开诚布公的团队。很庆幸能把这个氛围保持到现在。

团队方面我最大的失败还是资深人才的引入方面,很悲剧,接二连三的错过了好几次机会,痛心疾首不足为过。或许,投入程度还不够,也或许,引入牛人也需要缘分吧,另外,公司发展也要跟人的能力相匹配才好,继续等机会。我相信我们做的事情的价值。

经济上的收益还算过得去。不过一位老大哥的话还是对我有触动:「钱不是好东西,但有了更多的钱,很多事情也就能解决了」。至少对我来说,他说的对。所以,还是要保持一点赚钱的欲望较好,早日自由。

我的 2013 榜单:

  • 年度致敬:记者们… 接触到了不少媒体记者,了解他们的苦与痛,很多优秀的人正在逃离这个行业,可是这个社会不能没有「扒粪者」;
  • 年度媒体:小道消息 主要是我通过小道消息获取了更多消息;
  • 年度图书:吴军《浪潮之巅》新版,候选:Remote
  • 年度电影:宁浩《无人区》;
  • 年度音乐:张悬《玫瑰色的你》,好吧,我居然小清新了一回.

2014 年的 TO-DO List:

1. 寻觅人才.

丁香园技术团队仍然需要各方面的人才:

  • 数据方面的人才.
  • 搜索工程师.
  • 优秀的 PHP 工程师.
  • 运营方面的人才. 无线互联网运营,社区运营. 有医学背景就更好了.

长期招聘,人数上不受限制。如果你认可丁香园做的事情,想做点对这个社会真正有价值的东西,请考虑加入我们的团队。另外,这个行业的大形势真是一年比一年好。尤其是今年的政策出台,更是绝对的利好消息。

2.产品研发

新的一年的方向,重点是数据以及内容,只能说到这里了。方向在那里,能否把东西做好,并且做出价值,的确有点难度和挑战。

3.生活体验.

多一点时间陪陪孩子和家里人,需要慢下来。锻炼身体,跑步,Plank,都挺适合我的。今年身体已经是最近五年最好的一年,老毛病复发的次数少了很多,还要加大锻炼强度。此外,有必要对生活做一点简化,2013 年浪费时间的烦心事不少。还有,一时发神经「乞讨」了一堆手机和电子产品回来,体验这些东西挺费时间的,而且还欠别人人情。以后应该不做类似的事情了。

我会把我写过的比较有价值的内容整理出一本书,估计内容会很短,先出电子版的吧,这样比较环保。也节约读者的时间 – 如果真有读者的话。

最后,祝愿朋友们在新的一年能不再为空气和食品担心,虽然我知道这有点难,但总要多一点希望不是。能移民的早点走吧,先去打打前站也好。

致谢:感谢各位朋友们在 2013 年给我的帮助,希望我有一天也能帮到你。

感谢那些美好的事情,期待更为美好的事情终将发生。

EOF

此文位于 MyLife on by .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

谈谈去 IOE 运动

这篇文章算是今年年末的一个技术总结。谈谈技术圈一度的热门话题「去 IOE」这件事。

何谓 IOE ?

所谓 IOE 是个简称。是指以 IBM 、Oracle、EMC 为代表的小型机、集中式数据库和高端存储的技术架构。其中 I 指 IBM p 系列小型机,操作系统是 AIX,IBM 专有的 Unix 系统;O 指 Oracle 数据库(RDBMS);E 指 EMC 中高端 SAN 存储,曾经一度是 IT 企业很喜欢采用的技术架构。IOE 这个说法怎么来的? 据我所知应是来自阿里技术团队内部的称谓,然后才在整个业界流传开来。如果你去问国外技术专家什么是 IOE,对方肯定一头雾水。当然,随着国内案例逐渐被介绍到国外,或许某一天这个术语能输出价值观也说不定。

在小型机领域,只有 IBM 这一家,独步武林;HP 当初把宝押在安腾上,算是早早退出这个市场;Sun 日薄西山,SPARC 机器…那就更不必说了。另外,需要说明的是,IBM 也生产存储产品,但 IBM 的存储产品早期其实挺山寨,竞争不过 EMC ,而且有些用户会忌讳把所有的东西困在一家公司身上,尾大不掉。 起码在国内,EMC 的占有率应该更高。中高端存储这个领域,还有一家 HDS,不过曾经一度在阿里也栽过跟头。数据库软件方面,在当初几乎没的选择,只有 Oracle 这一家,IBM 的 DB2 实在是不行,虽然号称市场占有率不错。国内用 Oracle 数据库支撑互联网应用的话,一般是采用 Data Guard 这个架构方案。

为何要「去 IOE」?

说起「去 IOE」,跟阿里的王坚博士有直接关系。我无从得知他当时为什么要做出这个决定。但根据我的推断,当时淘宝、支付宝等公司每家技术体系各有特色,技术团队也各是一套,只有去「去 IOE」,才有可能将淘宝、支付宝等公司的网站核心体系架构迁移到云上,体现阿里云的价值,某些管理者才有可能从集团公司层面对整个技术团队有更好的控制力。否则,阿里云师出无名。注意,这个说法只是我个人臆测,肯定不是事实,只是逻辑上是说得通的。实际上,阿里云当时自己的活儿做的很垃圾,也幸亏这个「去 IOE」运动进行并不那么快。当然这是后话了。

或许有人认为「去 IOE」会节约企业成本,实际上,当时的 Oracle 和 EMC 等软件成本已经足够低,硬件上,硬件上的每年的成本也是可控的,如果考虑迁移后总体成本,新硬件成本、开发人员成本、运维成本、时间成本等等,通通算下来,未必能节约多少。这个不是我拍脑袋给出来的,而是跟不少技术人事后复盘,结论基本一致。

客观的说,当时「去 IOE」有一种公司政治的倾向,或者成为一个一窝蜂的运动,这很令人讨厌,或者说这事情出发点未必如何好,但令人意外的是,最后在阿里诸多优秀技术人才的努力下,却取得了一个令人惊讶的很好的结果,那么,就别管出发点如何了。

为何「去 IOE」是必要的?

从另外一个角度考虑,尤其从运维 DBA 的角度去审视,「去 IOE」 实际上是必须要进行的,或者说去「O」是必须的,因为当时存在的问题是,Oracle 数据库对用户 (DBA) 来说已经不够灵活,常用的 Data Guard 模式无法适应互联网公司快速增长,最基本的一点,读写分离就做不到,只能向上扩展(Scale Up),拼硬件能力,几乎无法做到横向扩展。或许有人说,不是有 RAC 么? 但 Oracle RAC 是无法对付高并发下的 OLTP 应用的 – 一直到现在很多人都认识不到这一点,RAC 跑跑数据仓库什么的倒是不错。

注:有人会说 Orale RDBMS 11g 的 Data Guard 可以读写分离呀,这个所谓的读写分离可靠性其实是不够的,而且出现的时间也太晚了,此外,不够灵活。还会有人争论 Oracle RAC 怎么就不能应付 OLTP 呢? 别争论了,你非要说可以应付,没问题,但是在阿里体系的公司里,还真没人敢这么玩儿,为什么? 是做不到? 还是他们掉进坑过?

如果要动「O」,那么 「I」 和「E」就必须要动 – 相信不会有人在小型机上跑 MySQL 的,而且,只换掉「O」也没有意义,换汤不换药不会有成效。

随着中国电子商务的快速发展,整个阿里系其实已经在面对全世界增长最快最复杂的业务系统之一,这是机遇,也是挑战。旧有的技术架构已经不足以支撑更大的梦想。从这个意义上来说,去「IOE」是相当必要的。或许,这也是王坚博士以及一些人的初衷。

为何「去 IOE」成功了?

阿里几家子公司这么复杂的技术体系,「去 IOE」这事情堪比高速公路上给飞驰的汽车换轮胎,最后成功是相当不容易的。

成功的因素有哪些呢?

1.功不可没的当然是一群出色的技术人才,很了不起。我想这是无需多说的,面对这么复杂的业务环境,这个任务如果没有一批优秀的工程师是绝对做不到的,没有阿里 B2B 技术团队、淘宝团队、支付宝技术团队的先后投入以及合作实践也是绝对做不到的。要强调一下的是,阿里在在分布式事务上的处理能力和解决方案,这应该是独门绝技。在业界各种会议上也经常能看到这一群牛人出来分享,同行应该能感受到。

2.开源软件的快速成熟。举个例子,这两年 MySQL 体系的软件进步相当惊人,各种经验证的解决方案如雨后春笋般涌现出来。这得益于不少知名互联网公司(比如 Facebook、淘宝)在使用 MySQL 的同时也将其技术改进回馈给技术社区,把技术方案分享给业界,业界在吸收这些技术的同时再次回馈给技术社区,形成正向的反馈,极大地提升了开源软件在商业领域的竞争力。

3.硬件革命。硬件的进步给技术体系的变迁做好了铺垫。最主要的关键词:「SSD」。如果没有「SSD」的技术成熟以及在商业应用上被普遍接受,「去 IOE」几乎是不可能做到的。要知道物理机械硬盘存储的性能数十年几乎没得到什么大的改进 – 当然每年提升一点是有的。但 SSD 相比机械硬盘来说,则是质的飞跃。我记忆深刻的是,每年做 I/O 容量规划的时候都会发愁,因为即使已经使用上了很高端的 EMC 存储设备,但实际上只要应用层 I/O 没有命中到存储内存,直接打到后面的磁盘上,几乎没什么抵抗能力。比如当时一个硬盘极限能撑 100 多个 I/O,100 块硬盘也不过是万把个 I/O 就不行了。 但这样的 I/O 「打击」对 SSD 来说,则不是什么大问题。SSD 给解决「IOE」体系最大的瓶颈 – I/O 能力提供了硬件先决条件。

4.摩尔定律。这一点最初我不想提及,但不提及,就会有别人说,所以还是补充一下。提到摩尔定律,重点要说的 X86 芯片的计算能力不断进步,而 IBM 的 Power 芯片虽然也在不断进步,但正式商用的节奏明显在控制。这就给 Intel 体系带来了机会和空间。

国内对「去 IOE」的反应

在出现阿里这个成功案例之后,技术圈很是震动,曾经一度讨论热烈,随后则是国内产业界对此出现了一些跟风的倾向,不少公司则打着「国产」软件的旗号出来蒙人,这是值得警惕的。去掉 Oracle 不意味着就要采用国产的垃圾数据库,因为 MySQL 以及衍生的各种分支数据库才是最佳选择。同样,不用 IBM 的小型机也不意味着国产服务器就迎来新机会,在用户那里,适合的解决方案才是最重要的。「去 IOE」不应该成为一个噱头。任何时候,「国产」都不应该是一个互联网企业选型所要优先考虑的因素。在全球化的今天,我们应该忘掉「国产」,才有可能早点做出来更牛的软件来。

更好笑的,还搞出来一个什么「去 SOA」的组织,我觉得这是不太正常的,实际需求为前提,不能本末倒置,难道是为了「去」而「去」么?

2014 以后会有更多公司「去 IOE」

从目前的种种趋势来看,在今后几年,国内一些互联网公司以及 IT 企业会逐渐的「去 IOE」化。相比几年前,现在的「去 IOE」的主要原因则是:旧的「三件套」已经的确不适合互联网应用了。开源数据库更为可靠成熟,SSD 可靠性也得到验证,技术人才甚至都不需要从头开始进行储备 – 类似「沃趣科技」这样的团队已经能够提供足够好的技术支持服务,新的技术体系毫无疑问会让企业更有竞争力,总体成本更低。

上文提到的「沃趣科技」是由一群前阿里的工程师组成的技术团队,汇集了一群从数据库到存储到网络架构的专家,如果要找「去 IOE」技术顾问,似乎他们是独一份(这里不是广告)。相比之下,IBM、Oracle、EMC 等公司近些年来,实际上对国内那些快速发展的互联网公司已经提供不了有力的技术支持了,IBM 拿苏宁电商练手更成为业内笑柄。或许这也是 IOE 们被抛弃的一个原因,也可能是一些创业团队的新机会。

一个时代过去了。

EOF

关于 IOPS 的数据补充:

机械硬盘现在最高号称能跑到 400 IOPS,但应该 200 左右(走 SAS 接口)也就是极限了; 单块 SSD(走 PCIe 接口)的最高记录是九百多万,用不了多久突破千万 IOPS 是没问题的,相当了不起, 即使百万量级也足够吓人了。(Refer)

此文位于 Arch on by .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

你可能并不需要一个 CTO

有朋友在微信里让我给推荐一个 CTO。说是一家公司在找人,据说「项目不错」,因为之前的业务不是很互联网,现在有一个新的项目要做,要做一个社会化电商的社区,类似一个国外的某某网站,所以他们说需要一个 CTO ,问我是否有人选推荐。

我给的回复是,这可能并不需要一个 CTO 。原因有如下几个:

1.对类似的社区类产品来说,技术可能并不是最重要的,当然我不是说技术完全不重要,只是重要程度没有想象的那样。实际上搭建一个论坛随便一个工程师也能做;

2.针对这个产品来说,要做成需要很强的运营能力,换言之,需要花大力气去找这方面的人才而不是找 CTO;

3.如果运营不够强,或者根本都没意识到这问题,找到 CTO 也没用;

4.如果这家公司只是想尝试一下这个产品,产品是否可行都说不准,一个具备 CTO 能力的人为什么要跟着你玩? 产品做不成的话,CTO 干嘛去?

5.如果有人只对 CTO 这个职位感兴趣,而不考虑上述其他几个原因乃至更多我还没提到的原因,这样的人也没什么判断力;

6.基于如上原因,不能推荐。建议找个能搞定事情的技术经理先做一下。

有人说,你这是跟人家逗哏还是抬杠呢? 别闹,我当然是很严肃的在探讨问题。很多嚷着找 CTO 的公司其实并不需要一个 CTO。以下几个阶段我觉得就不一定需要一个 CTO:

1.业务根本没得到验证的时候,或是在克隆一个国外的一个产品,模式一定可行么?

2.团队很小的时候也不一定需要 CTO 。早早的任命 CTO ,如果他能力不能随着团队壮大而拓展,对团队就是一种损害,所以最好还是用「技术负责人」这样的称呼比较合适;

3.有些初次创业的人觉得自己有个好点子,想找个合伙人,但是自己又找不到(这句话很关键,为什么他自己找不到?),于是到处求爷爷告奶奶拜托朋友帮找技术合伙人或是 CTO ,基本没戏。

以下这种情况我觉得 CTO 最好不要跳入火坑:

1.土鳖老板看着互联网眼热,觉这玩意儿好像好赚钱,想投资几百万试试看,但自己又不懂技术,于是想找个懂技术的来补课;

2.受投资方委托进入创业团队,团队内部本来又矛盾重重。

最后我能给出的建议是:创业团队别总盯着头衔找人,而要找能解决问题的人,把你的事情搞定。当然,前提是你已经识别出自己团队最需要什么样的人,最缺少什么样的资源,最需要解决什么样的问题。如果这些你根本不知道,那么你最好找一个 CEO 吧…

此文位于 Startup on by .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

试错

前几天看公司离职同事反馈的各种意见建议还有抱怨,很有价值。但是反馈中有一点,我是无法赞同的,那就是对待「试错」的态度。有两位同事抱怨说,为什么要不断「试错」? 这样多折腾? 搞得开发人员多累。客户为什么要不停的要我们修改设计稿? 多烦。

首先要说的是,我在工作中看到不少人混淆了「试错」和「错误」这两个事情。有些试错根本就是纠正错误,既然事情无法一次作对就别找别的客观理由了,一个功能,每改动一次,都会出现新的问题,这样产品人员肯定要你不停的去修正,几次三番,作为开发人员自己没意识到自己的责任,反而会把问题怪罪在产品人员头上。但实际上,这样的情况应该先看看自己做的事情是否不够严谨,自己考虑得是否不够周全。

绝大多数人都不喜欢频繁的被动的改动自己的已经「完成」的工作,文案不喜欢改来改去的,设计稿也不喜欢改来改去的,做完的功能不喜欢改来改去的,总而言之,你别来折腾我,别来烦老子,别来惹老娘…有点情绪可以理解,但我们应该认识到的事情是,如果你要把东西做的更好,就是要不停的改动,不停的改进。没有人能一次弄出来一个完美的东西,除非你是神。对了,乔布斯不是神,因为 iPhone 第一代产品现在看起来根本就是个半成品。「改动」和「改进」的差别在什么地方呢? 差别就在于改进是要使产品、项目乃至工作变得更好,能进步。

一看到「进步」两个字,很多人说,我喜欢进步,更想得到成长,但是我讨厌别人来折腾我。听起来你没错,只是因为「反馈」的信息不在你这里,而是被别人掌握,可你又从没想着去了解这些反馈。举个简单的例子,程序员和产品经理搭配工作,产品经理要程序员改动某个功能,程序员觉得你很脑残啊,要改动你怎么不早说,之前你干啥去了? 答案是之前他犯错了 – 因为经验或是能力的问题或是因为概率问题,然后他试图纠正或是校正这个问题。这是他的工作性质决定的。他不可能一次把所有的东西都做对,除非你做一个根本不会有人用的东西,没人反馈问题,因而也就看起来没问题。

不对劲儿,你说的好像哪里有点问题: 产品人员能否提前去做好调研,做好分析,做好各种准备工作,做好决策,然后让工程师一次把东西弄出来不需要频繁改动呢? 当然能啦,在过去的软件开发工作中差不多就是这样的。好吧,跟我们的环境有点远。还有一种呢,是离岸外包,需求分析说明什么的文档写出来一大堆,然后开发人员直接实现就行了,你可以想见,这样的环境下每个人都不过是螺丝钉,然后你一定又会觉得,哎呀,接触的东西太窄了,这样长此以往人都废掉了怎么办啊? 去「试错」。

还有一种不需要试错,其做法就是跟着别人的产品去复制,别人有的东西你也要有,别去问为什么,只是因为「竞争对手做了,我们也要做」。这样的做事思路下,的确不需要试错的,因为这个时候对错已经不重要了。

绝大多数中小公司做事情,就是要不停的试错,创业团队尤其是要如此,这并不丢人,也不是为无能找借口。因为真实世界真实商业环境真实的用户需求就是远比我们认为的还要复杂,只有不断尝试才可能找到可行的解决办法。柳井正写书剖析优衣库的成功之道,「一胜九败」,如果我们「一败」都没有过,就想有「胜」,未免也太自大了一点。如果你只想按部就班的做事情,我建议你还是早点想办法进入大公司进入大的机构去。

如果你没做成什么事情,那是因为你犯过的错误不够多,你试错的次数太少,或是你根本不愿意试错。

试错是正确之母。

Updated: 要知道,试错是有很高的成本的,这个成本,基本上是由公司在承担,公司心在流血啊…当然,个人也会浪费时间。如果能不用试错当然是最好的。问题是,谁能呢? 如果你知道,请一定要告诉我,我请你喝一杯咖啡。

此文位于 Startup on by .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.