分类归档: Review

苹果往事

春节前已经看了一遍这本《苹果往事》，假期又看了一遍。对于这段苹果公司并不鲜为人知的历史来说，这本书从一个亲历者的视角给 Mac 的诞生加了一大段注解。这也是苹果拥趸者最喜欢看的内容。

彼时的乔布斯，恰似刚受封齐天大圣，自信无所不能，被排挤到 Lisa 项目之外意味着他将来没有权利说这是他设计的产品，所以最想做的事情就是找个项目来证明自己。他对于 “自己参与设计” 的项目无疑是寄予厚望的，也给予了足够的支持，否则这个从概念项目起步的团队也不可能发展起来。对于这个团队的多数人，他们要研发的这个产品，不为名不为利(实际上也只有少数几个人得到了名利)，更多的是创造性工作给自己带来的成就感，什么是激情，或许这就是。

对于 1984 年苹果推出的 Macintosh ，现在来看，或许是那个寓意深刻的广告更为令人津津乐道。当时的 Macintosh 只能算是杰出的电子艺术品，是否是成功的产品很难定论。毕竟从市场表现来看，没有给苹果带来像 Apple II 那样的辉煌。这个产品的推出从某种程度上也间接促成了乔布斯被赶出苹果。是苹果公司发展历史上的一道分水岭。如果没有当初，或许也不会成就现在的乔布斯。现在的 Mac，其实无法让人等同于 1984 年的 Macintosh…我相信只是有些精神会延续下来…或许这样就已经足够了。

在这本书的最后，作者 Andy Hertzfeld 感伤 “我所渴望的理想麦金托什团队模式已经消失了，融入了那种我们以前常常取笑的大型组织当中，内部充满官僚障碍及人际摩擦”。曲终人散，这个团队的大多数人都将不再服务于苹果公司。这也是那些非凡团队成员的普遍命运。

阅读这样一本书，对我们更有价值的事情从中学习那些经验和教训，关于人，关于事。让人欣喜，让人心酸。

–EOF–

民生银行的系统事故

虽说年底是 IT 事故多发的期间，不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号，从上午11:00到下午15:30，故障持续四个多小时，全行系统瘫痪。对外称是”核心系统维护”。

个人之所以比较关注这个事故，是因为新闻标题中的”数据库维护失误”。据说是”由于数据系统进行维护时出现了失误，造成宕机”。开始的时候，大家把关注的焦点放到灾备切换与否的问题上，据说是”没敢切换”。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关，我错过了讨论现场。

也有朋友在 Twitter 上说：民生银行上周的系统宕机事故，源于IT部门某应用系统数据库（应该是 ~~DB2~~ Informix，数据库版本老旧，且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本 EOS (End of Service) ，无厂商实验室的工具支持无奈之下，要求重启相关系统，结果造成业务停止。事件的(后续)处理还在进行中。(via)

上述说法看起来比较可信，也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心，实施方是埃森哲(refer)。不过，”民生银行打造的新核心系统已经开发完毕，目前处于内部运用的阶段，今年上半年将会在全公司上线”，估计到时候能稳定点?

另外看到有网友说，2008 年初，民生银行的的小额支付系统也出过严重问题，由于操作失误或是程序内部控制原因，造成了几百万的重帐。

涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看，事故发生后，更多的时间都会花在决策上，而一旦选择错误或者不是做出最优的决定，灾难才刚刚开始。

–EOF–

有朋友后续补充到：2010 年 2 月 12 日上午 10:25，民生银行的信用卡网银不可用，返回 HTTP 500 服务器内部错误，网站上并没有相关的维护计划，咨询客服，说是系统维护升级。整个民生的 eBank.cmbc.com.cn 都是无法登陆的状态，看来”维护升级”的不只是信用卡网银，自2月3日以来，不到10天又发生状况。

编程语言的选择并非无关紧要

且说前一段时间听淘宝的黄裳讲解淘宝网站架构发展的时候，说起 2004 年底淘宝为何从 PHP 向 Java 转移的事情。为何转换，他阐述了几个理由，其中一个是非常有趣的：当时的 PHP 缺少一个 IDE。而合适的 IDE 能够有效提升规模化软件开发的效率。

我们知道 eBay 在 2002 年的时候也在 Sun 技术团队的帮助下，将整个应用架构从 C++ 迁移到 J2EE 。也就是 eBay 内部所说的 V3 版本(refer)。

最近一件有趣的事情是，据说腾讯的财付通在招聘 Java 方面的高手，”参与系统架构选型”，要把底层架构从 C/C++ 迁移到 Java 架构上来。另外，百付宝的后台技术据说也是基于 C++ 的(最开始的时候只是一两个人写核心代码）。我相信，现在百付宝或许规模还比较小，总有一天，也要面临向 Java 的迁移。这和阿姆达尔定律有点类似，要得到更大的计算能力，就要尽量减少整个系统中的非并行的环节。只是一两个人能搞定的地方，再加入更多的开发人员也是无济于事的，除非，改变协作的模式。

去年接触到的一些国内的电子商务公司，有些已经在进行技术架构上的变迁，当然，多数是从 Windows 平台迁移到 LAMP 平台，究其原因，也无非是成本与效率，而后者，更为大家所看重。当然，也有一些顽固派，比如京东，仍然固守原来的手工作坊技术模式。

如果单兵作战的话，很多程序高手会说，”用什么语言都是无所谓的”。但是如果是团队协作开发的话，用什么语言，影响则是不一样的。对于电子商务网站来说，语言的选择意味着不同的架构路线、不同的开发框架、不同的测试框架、不同的部署流程，最后更为主要的是不同的开发效率，意味着可以把更多的开发资源并入到当前的环节中。

事实上，对于一个高速发展中的网站，每隔18 或 36 个月，几乎总要有一次架构上变革的阵痛。没有这种变革的勇气，意味着以后也不会有人敢做这个尝试。没有这种阵痛，就不会有成长。

变化的节奏最后影响一切。编程语言的选择并非无关紧要，短期看来似乎影响不大，从长期来看，决定最终的竞争结果。这就是我要说的。

–EOF–

大象跳舞

最近看了不少以前不愿意看的书，《谁说大象不能跳舞?》是其中之一。这是一本教科书，讲述的是如何挽救一家走向衰败的大公司。

所处的位置不同，不同的人阅读这本书会有不一样的体会。给我印象最深的是郭士纳初入 IBM 所采取的策略，”我们只有很少的时间用来找出问题，大部分时间、精力和关注点都将用于解决问题和采取行动上。”

问题本质

新的 CEO 上任之前从众多人的建议中就已经抓住了问题的本质(收到众多建议的时候如何过滤重点?)：IBM 不缺乏能人和天才，公司也不缺致胜战略，新领导人要从”战略”和”文化”等方面推行改革入手。这个改革，体现在具体行动上，是后面的”热烈拥抱”计划，说白了，也就是”拥抱用户”，倾听用户的声音，解决用户的问题，赢取客户信任。然后才是财务方面的止血，最后才涉及到远景规划。能从千万重关系中抓住这些关键点，这是核心能力的提现。

对待人才的策略，也就是如何对待现有管理层，郭士纳也是自有一套。在第一次会晤管理人员的时候就主动传递了这样的信号： “IBM 历来是个人才济济的地方…只有如果有必要的时候，才会从外部引入人才”。但是我相信，这样的策略恐怕只有针对 IBM 等少数公司才会有效。多数公司不能照搬–如果问题的本质抓不住的话。(实际上，郭士纳后来还是招聘了不少曾经和他合作过的管理人员进来。)

对于这只管理团队，也不是真的没有问题，当时的 IBM 比较严重的官僚气是存在更多关心公司内部部门之间利益争夺而不是关注竞争对手的情况。任何一家大公司都会有既得利益者，这一点大家都会有共鸣吧。

“大象跳舞”

这本书的书名有多重隐喻。其命名或许和 TIME 杂志的这篇 Can This Elephant Dance? 有关。”大象跳舞”是什么意思? 对于 IBM 这样的庞然大物来说，跳舞意味着优雅、协调，意味着摆脱笨拙。而一旦大象能够做到以这一点，那么竞争对手自然不足为惧，因为问题来自自身而不是外界。

“Elephant Dance” 应该是个证券行业常用语，大致是”大盘股活跃，反复上涨”之意，从这个角度上来说，郭士纳也做到了，IBM 股价在他的任内也是一路上涨。

–EOF–

乱翻书，不求速进，但求有所得。