作者文章: Fenng

2009 年个人总结

每年的年终总结是个有趣的事情,没有回顾,也就不会有进步。虽然过去几年制定的计划完成情况都不是百分百完成,但却的确对个人起到一点作用。

看一下 2008 年底制定的 2009 个人计划

2009 年的 TO-DO List 完成情况

  • 翻译一本书 和同事合作翻译 Troubleshooting Oracle Performance,中文版叫做 《Oracle性能诊断艺术》已经面市。这本书的翻译用了不少时间与精力,也有收获,这是最后一次翻译图书。
  • 写一本书. 没有完成,图书翻译让我倒了胃口,一鼓作气,再而衰,三而竭。说的就是这样的情况吧。
  • 提高团队声望. 还算可以。对外团队宣传有了一点影响力,为公司招募了几位技术牛人。当然,这多少也是吃力不讨好的事情,但自己个人感觉很欣慰。
  • 提升技能. 做了一个项目,技术功力恢复了一些,当然,重要的是感觉与理解力。对新技术的追踪还算过得去。
  • 技术交流. 参加的交流有一些,但个人的演讲技巧没什么提升,只能说做的一般般。

计划中的几件事情看起来都是很难体现价值的事儿,”如果你觉得有价值,就去做,不必在意别人怎么看”,公司老大的这句话给我了不小的启发。除此之外,我还做了哪些事情? 方便说的大致有这么几件:

  • 贝塔咖啡. 我还记得是在元宵节的晚上,白鸦给我打电话,说咖啡馆的成立会议就要开始,要我马上赶到。但是运河边人山人海,没办法立刻赶回去,我说算我默认参加就行了。有些事情,一步步做下来就会成,感谢几位靠谱的朋友,没想到贝塔咖啡真让我们几个捣鼓起来了。在咖啡馆,我结识了更多的朋友,开拓了眼界。谢谢白鸦、思践、坏人、小斌。这件事情还要感谢很多朋友,感谢你们的信任与支持。
  • 一次旅行. 10月份,一个人去了一趟美国。无人同行的一路也是很有趣的。第一次发现在一个完全陌生的环境里,从不同的角度看问题,静静的考虑一些事情。在杭州,很少有这样的场景让自己思考。
  • 一个团队. 从下半年开始,受到召唤回到原来的团队,换了一个角色去做事情。有很大的难度。原来自己越不愿意做的事情要去做,越觉得没有价值的事情要做出价值。这是一次磨练。
  • 一次投资. 尝试着做了一次投资,具体细节不好细说,总之帮助别人也是帮助自己。不过这里的投资不是买什么股票之类的事情,那样的事情实在无趣,不是我要的生活。

这一年下来,痛风对我的困扰小了许多。不过,生活上,自己还是个比较懒惰的人。Blog 文章少了一些,但也有100多篇。

我的 2009 榜单:

  • 年度致敬:花剌子模信使。
  • 年度媒体Twitter,140字的智慧、力量与乐趣。
  • 年度图书:《软件随想录》。有些想法可以做到和别人不一样…
  • 年度运动:翻墙。能够促使积极思考,接近真相。
  • 年度技术:Open Source。开源,那些看似神秘的东西不再封闭,去中心化有了进一步的可能。

2010 年的 TO-DO List (越来越不好写了,稍微写点儿):

  • 做好事情. 以前自己越不屑于做的,其实也是越不容易做好的事情,执行力需要提高;
  • 接点地气. 多琢磨一点客户都需要什么东西,能给客户带去什么,对客户有价值才是自己价值的体现;
  • 学习英语. 英语不过关将来能干点什么呢? 起码得能捣鼓几句口语吧?
  • 集中精力. 收敛一点心神,事情要一件一件做;
  • 拥抱变化. 到三月份,我就在杭州五周年了,生命中最有激情的五年已经用在了电子支付这个领域。或许,有点改变会出现…希望…

寄语2010:或许,你和我都需要收起一点抱怨,多一些忍耐,现在还不是我们展示力量的时候。

最后,祝愿朋友们在新的一年有新的收获。

EOF

磁盘的 4K 扇区时代来临

Western Digital 在推进一项技术变革,Advanced Format(PDF),将延续近30年的硬盘传统的512字节扇区变更为4K大小。

传统的格式如下图,绿色部分为 ECC (Error Correcting Code)区域。一般来说,每存储1000位(bit)的数据就会有产生一个物理错误,所以必须要有一个可靠的校验机制。这也是 ECC 必不可少的原因。

Legacy Architecture.jpg

每 512 字节用一个 ECC 区,占用 40 字节做错误矫正代码,这在需要存储大数据量的时候,显而易见是比较大的物理空间开销。而将扇区扩大,使用一个相对比较大的 ECC 区也是同样可以达到安全存储的目的。

Advanced  Format Architecture.jpg

如果使用 4K 的扇区,则大约需要 100 个字节的 ECC 区域就行了。空间收益大约是 7-11% 。对于存储工业来说,这是惊人的。当初设计硬盘规格的时候,估计研发者是无法预见到信息如此迅速膨胀的今天的,512 字节已经不太适应现在一个平均 I/O 的大小。

值得注意的是,这个变更更多是在空间上的收益,在性能上的收益还不确定,当然不会变得更差,至于是否有提高,能提高多少,要看具体的场景。另外,也不会提高硬盘的可靠性,每 12.5TB 的数据依然会有一个不可恢复的读错误。(refer) 。4K 扇区其实在数年前就被提出来,只是最近 Western Digital 才真正的推动,估计是因为磁盘容量要保证每年的增长率带来的压力。

使用该技术对或许企业级服务器用户并不会有什么太大的风险,Western Digital 同时也在固件层提供对传统的 512 byte 扇区的模拟方式。另外,也可以下载这个官方校正工具。对于个人用户来说,多少还是有点影响的,尤其是使用克隆软件安装 Windows XP (Windows 5.x )以及更低版本的操作系统的用户可能要注意一下。

4K 是个有趣的数字,还记得 4K偏移量的问题么?

未完,待补充 …

延伸阅读:

此文作者:, 位于 Review 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

来自淘宝的架构经验

日前参加了一场淘宝网架构师黄裳带来的技术分享,在最后他总计了淘宝这几年来的架构经验,这里和大家分享一下:

  • 1、适当放弃一致性
  • 2、备份和隔离解决稳定性问题
  • 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
  • 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
  • 5、产品化管理

在这里不妨对比一下 eBay 的架构经验:

  • 1、 Partition Everything
  • 2、 Asynchrony Everywhere
  • 3、 Automate Everything
  • 4、 Remember Everything Fails
  • 5、 Embrace Inconsistency
  • 6、 Expect (R)evolution
  • 7、 Dependencies Matter
  • 8、 Be Authoritative
  • 9、 Never Enough Data
  • 10、Custom Infrastructure

关于一致性,可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外,强调了”放弃集中的紧耦合处理”的原则。”备份”这里可以理解为”提供可用的副本”。”分割”是说水平拆分。

架构这东西说起来大致原则,其实都是类似的,但是具体如何在一些通用原则上做到运用自如,是很难的事情。前几天我还感慨,很多架构师对与”异步”与”批量处理”所能带来的益处的理解仍然相去甚远。

EOF

企业员工应遵守的 Twitter / 微博 准则

在 Twitter ( @Fenng )上发布了几条关于 “员工应遵守的Twitter 准则” 的建议。如果你也是 Twitter (或微博) 用户,以下这几条准则或许可以用来参考:

准则一:不要发布不为公众所知的和公司相关的业务数据。如果要引用公司的公开数据,不要加主观的断言。对于关注你的人来说,小道消息并非那么有价值。

准则二:不要匿名攻击公司(包括自己的雇主和竞争对手)。尽管”在互联网上没有人知道你是一条狗”,但是,雇主还是很容易知道你是公司里面的哪一位。

准则三:Twitter 上的信息具有不可修改性,被转发后会引来不同的解读。所以发布消息前要衡量是否会对同事或团队造成负面影响。如果回答为”是”,不要发布。

准则四:倾听用户的声音,收集用户反馈而不要和用户争辩,如果能够解释,进行必要的解释,但是记住不要推脱责任,尤其不要攻击或是嘲讽用户。

准则五:如果你的主管或同事不能理解或者认可Twitter会对公司带来的价值,向他们解释,同时最好能证明使用 Twitter 并非是在浪费工作时间–用 Twitter 或许比用 IM 更节省时间。

准则六:必要的时候尽可能转发对用户的警示信息,比如”系统维护公告”或”费用调整”等信息应更快更及时的传递给用户。

准则七:团队的内部规划,正在进行的项目及相关实施细节,未经相关负责人允许也尽量不要披露,以免带来各种不可预期的不利影响。

很多人在 Twitter 上发消息,不可避免的会提及自己的雇主。新用户或许意识不到 Twitter 对消息传播的便捷性会带来的破坏力,如果没有一个类似指导原则的话,可能不经意间就会对雇主造成负面干扰,也会给自己带来一定的麻烦。这里的准则或许不能覆盖所有的情况,所以更多的时候要依赖于常识来判断。

如果你在鼓励同事或者朋友来用 Twitter 或者其它微博,要向他(她)说明这些。( 感谢 @hutuworm 同学贡献了准则七)。

EOF