分类归档: Review

3PAR 争夺战

这两天看到消息，Dell 在对 3PAR 争夺战中退出，HP 宣布获胜。当然，代价也是不菲，总收购价格大约 20 亿美元。

3PAR 这家公司刚进入国内我就有所接触，因为该公司在美国有很多证券、金融行业的客户，加之我上一家雇主就是做这个方面的，所以我非常想了解并引入 3PAR 的一些成功的经验，并且研究了一下高端的几款产品特性（refer: 3PAR 存储架构解析 )，最后还吃了一下螃蟹，在 3PAR 上实现了一套 Oracle 11g RAC 集群。所以，我算得上国内少数真正用过 3PAR 的了吧。考虑到以后再也不会接触这些所谓高端存储，还是有必要写点东西做个纪念。

应该说，3PAR 这产品的确有独到之处。首先是性能上看，通过特定硬件架构，充分利用了机械硬盘的特点，进而保证 I/O 响应时间，这是硬指标，真是非常贴近金融类的用户需求。 Thin Provisioning 技术也是实实在在的可在产品环境使用的，不像个别存储厂商只是一些功能的包装，跟风炒作概念，忽悠客户。让人感慨的是，3PAR 最近有有些生不逢时或是走向末路，上市时也恰好是金融危机来临之际，核心业务一下子受到非常大的影响，这是商业层面上的；另一方面，3PAR 的技术在机械硬盘时代几乎独步存储武林，但到了 SSD 的时代，则有武功被废的可能。尽管也宣称支持 SSD，但毕竟在机械硬盘时代的优势将不复存在了。追求高 IOPS ，更小 I/O 响应时间的用户用 PC 服务器＋ SSD 就能很好的满足要求了。

HP 收购 3PAR 的意图其实比较明显，那就是弥补自己在高端产品上的缺陷。最近几年，IBM 在推收购来的 XIV ，HP 也有 EVA 系列的存储，和 3PAR 的一些设计理念都是很相近的，不过都只能算是中端存储，算不得高端产品。据我所知，EVA 似乎市场表现一般。收购 3PAR 后，估计 EVA 产品线将最终消亡。业内其实都知道，HP 自己一直没有高端存储产品，一直是 OEM Hitachi Data Systems(HDS) 的高端产品，后来和 Oracle 合作 Exadata ，Oracle 收购 Sun 之后也不再和 HP 合作，对 HP 来说，如果在未来几年，要在存储领域有所作为，收购是最为便捷的办法–也是高层最不用动脑筋就能使用的办法。

尽管 HP 有收购 3PAR 的足够理由，但我觉得这笔收购未必能对 HP 带来多大价值。如果给 Dell 可能会更好一些，Dell 可能将 3PAR 用来主打中高端存储市场。

据说 3PAR 的 CEO 获益比三位联合创始人的都要高，这就是商业运作的力量。3PAR 发展到现在，历史已经有 10 年了，在看到一些有创造力的公司成功之前，也要想到创业的艰辛，成功只是少数，失败是多数。（3PAR 的命名是这样的：3 表示三个人，P 代表Jeffrey Price；A 代表Ashok Singhal；R 则为 Robert Rogers，已于 2001 年离开. 所以，这家公司的名字应该都用大写字母才是）

从技术发展和业界的需求来看，这些 SAN 中高端存储已经临近黄昏。也不可能在云存储方面有什么进一步的想象力，有的话，也是空想。当然，这是另外的话题了。

–EOF–

Web 产品的改进

这一段时间来，一直在考虑快速改进产品的事情。Web 产品的改进是个麻烦事情。远不是收集一大推需求列表，然后三下五除二修改上线那么简单。

产品的改进，也是个不停作选择的过程，不要被用户牵着走，尤其注意那些专家型用户的意见，是很好的参考，要尊重他们，尽快给他们反馈，但未必要全盘采纳。如果真的存在易用性问题，用户会从更广范的角度不停的反馈给你。不能看竞争对手的，因为他们可能在跟你学呢。

改进的前后，数据收集的丰富性将影响最后改进的结果。但不能完全跟着数据走，因为你收集的数据可能不是准确的。此外要记住，不要事先定一些数据上的指标，比如注册增长多少啦，流失率减少多少啦，没有意义。有些改进，内部数据上未必会好看，但用户会叫好。要知道，越大的公司，数据越是用来唬人的。反正决策层没几个人懂数据。

针对产品改进，要想做出正确的决定，只有对产品本身的熟悉程度是不够的。其实越了解自己的产品，越容易做出有失偏颇的决定。而如果能对用户加深了解，会有助于做正确的事情。但必须承认，了解用户可不那么容易。

既然是改进，就不是翻新，就不要做大项目，”大山临盆”的事情常有，只是失败过后没有人好意思说。快速上线，快速反馈，不但用户容易接受，团队也会从中受益。

好的技术人，能让产品变得更好。而团队越大，产品会变得越糟。三个和尚没水喝的故事永远都适用。

说到底，都是可意会不可言传的废话。如人饮水，冷暖自知。

–EOF–

灾难究竟要多么惨痛，才能不让它再次发生？我的朋友们阿，答案在风中飘扬。

在 Sedo 交易域名应谨慎

最近在 Sedo 上尝试购买一个域名，折腾了一笔不算成功的交易，算是交了一次不菲的学费。

或许是因为技术因素的限制，Sedo 的交易过程没办法像国内域名交易商(比如 4.cn)那样很严格的确定交易中的每一步的状态，而是完全靠代理人(也就是客服人员)对交易状态进行驱动，用户容易被误导。让人不能理解的是，Sedo 会在卖家将域名 Push 到 Sedo 后就给卖家付款（这个过程居然是不通知买家的，或许国外的担保交易都这样？），这个时候如果卖家申请取消交易是不可能的事情，我就是在失误在了这里。因为信息的不透明，新手的确不知道发生了什么，比如我。

事后搜索了一下，用户对 Sedo 的抱怨还是挺多的。虽说 Sedo 已号称进军中国，但实际上只是汉化了几个页面而已，客户支持方面的力度弱也可想而知，据说 Sedo 负责亚太区的只有一个人，也就是张谦先生，尽管反复的沟通后被告知结果不可改变，但还是感谢他的耐心吧，沟通中还是了解了不少东西的。

教训或许有点惨重，但是自己疏忽在先。吃一堑长一智。以后购买域名的时候建议朋友们优先考虑国内的平台交易吧，毕竟沟通起来更方便一些。

–EOF–

更新：我在后续要求 Invoice from Seller ，Sedo 给我的明显不是卖家的信息。只是他们自己简单做的一个 Invoice。

架构师应该知道的那些事儿

在新的团队有点忙，刚好这本《软件架构师应该知道的97件事》适合断断续续的阅读，然后慢慢”琢磨”。每个人偏重的技术角度不同，所以有些事情读罢可能未必能引发什么进一步的想法，但读到有些以前没关注过的话题则可能触发进一步思考。

印象最深的一句话是”确保简单的问题有简单的解”，这本书里面很多话题都提到了”简单”这个词，我更喜欢用”简朴”，不把简单的事情复杂化，和我一直坚持的理念有点不谋而合。其实，有些资深开发者很难抗拒”炫技”的诱惑，时常想用最新最酷的技术来做他认为”最有挑战最有难度”的事情，殊不知用更小的时间、人力、技术成本解决问题也是真正有技术含量的事情。

究竟什么才是称职的架构师，我想很难界定，很多公司对架构师有不一样的期待，但有一条，作为技术人总要不断的思考，持续学习，不断进步才能迎接更大挑战，才会称为别人眼中称职的架构师。

我的一个疑惑是：不知道有多少架构师现在还在公司之外保持阅读技术书籍的习惯呢？

–EOF–