« December 2005 | Main | February 2006 »
January 25, 2006
管理是平衡的艺术(转)
转自runliu的Blog，写的非常棒，很少转文章，这次是特殊情况。
管理者不是魔术师，所以不能凭空创造奇迹。在复杂的商务环境中，几乎没有什么决定可以是100%正确的。所有的决定都带有倾向性、个人判断、价值观以及各种实际情况限制。所以说管理是一门艺术，是一门平衡的艺术。
平衡不是平均主义，不是取悦每一个人，而是有原则的取舍、很周到的集中。
1、战略性的思考，和思考的战略性（Strategic Thinking & Think Strategically）
想当元帅的士兵喜欢战略性的思考。通过战略性的思考（Strategic Thinking）制订公司、部门的战略，并且用强大的执行力（Execution）和一致性（Consistency）加以实现，可以有很大的成就感。但是在一个优秀的人聚集的公司，每个人都从事战略性的思考是非常危险的。16种不同MBTI性格的可能会有16个方向，这必将导致公司的方向混乱，资源浪费。所以，有时候我们要甘于思考的战略性（Think Stragegically），考虑问题的时候能顾及公司现有的大战略，把自己的工作往战略上靠，才能万众一心，达成目标。
太多的人在做战略性的思考是大公司的通病。平衡这两点是管理者的一个难题。我很欣赏一位高官说的话：“We cannot do strategic thinking, but we can think strategically.”
2、三个客户：老板、员工、消费者（Three Customers: Boss, Employees and Consumers）
消费者不是你的唯一客户，如果“不惜一切代价”换取客户的满意度，那对公司是非常危险的。因为让消费者满意的最终目的是让老板满意，让股东满意。员工不是你的唯一客户，“皮之不存，毛之焉附”。公司的亏损、消亡将导致更多的员工降薪、失业。裁员对管理者来说永远是一个两难的、痛苦的决定。老板更不是你的唯一客户，否则你就只会PMP（拍马屁）了。
平衡的管理者通过让消费者和员工满意，达到让老板满意的目的。
3、昨天、今天、明天、后天（Yesterday, Today, Tomorrow, The Day After Tomorrow）
服务部门是为昨天的利润工作，给已经购买产品客户提供承诺的价值。销售部门是为今天的利润工作，把产品变成利润，争取更多的客户。开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖。研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先位置。
只看今天的管理者是短视的。眼中有着四天，并且懂得平衡资源的管理者，才能有可预见的成功。
4、40%业绩 + 40%员工 + 20%自己（40% business + 40% people + 20% self-development）
把自己100%的精力仅仅放在实现公司业绩目标上，会有短期成效，但却是一种非常危险的饮鸩止渴的行为，犹如杀鸡取卵。
所幸的是现在犯这种错误的经理已经不多了，因为360度调查，员工满意度调查，员工职业生涯规划这些管理工具已经深入人心。经理们都很清楚员工不仅是资源，更是资本。
现在更容易出现的状况是，繁忙的主管和经理，完全忘了自己能力的提升，因为忙，而放弃很多有用的培训和其他个人成长机会。
管理犹如驾车，业绩是速度，员工是引擎，管理者自己是润滑剂。定期保养绝对不能漏了添加润滑剂。
5、平衡积分表（Balanced Scorecard）
平衡积分表是平衡管理哲学发展到几近极致的产物。一张典型的平衡积分表包括财务（Financial），客户（Customer），学习成长（Learning & Growth），流程（Business Process）几个方面。我至少看到了几个问题的答案：
1）为什么公司市值可以是公司资产的数倍到数十倍？客户、学习成长、流程是其无形资产的形式，股东信心来源。
2）客户不是上帝。就像员工不是上帝，老板不是上帝一样。因为财务、学习成长、流程一样重要。
3）《学习型组织》很畅销。学习也是为了财务、流程、客户服务的。
4）很多优秀的公司讲究规范，不是没有道理的。规范是为了更好的实现财务、学习成长、客户的目标。
流程、客户是对内部、外部的平衡；财务、学习成长是对后置、前置的平衡。
6、时间、范围、费用（Time, Scope and Cost）
PMI认为，项目管理有五大流程，九大知识领域，数十个方法论，和上百个工具，需要至少参加35小时大约5天的培训，才能理解通常认可的（Generally Accepted）管理纲要。
其实项目管理可以很简单。项目管理可以就是对时间、范围、费用的平衡。项目经理不是魔术师。客户要增加工作范围的时候，项目经理就调整一下时间、费用。公司要求减少费用的时候，项目经理只能减少工作范围，或者改变时间。虽然实际环境会很复杂，但原理如此而已。
项目经理最是平衡专家，因为他必须在时间、范围、费用的三角形上寻求到最佳平衡。
Posted by yudunde at 03:06 AM | Comments (0)
January 19, 2006
bind dlz - 分布式系统的请求分发工具
bind dlz全称是bind dynamic loadable zones，是基于bind的提供的一个组件，作用看名字就知道了，支持动态域加载支持。
bind已经有很久的历史，目前是搭建DNS服务器的首选。对于一般网站来说，一个标准的bind已经完全可以完成所有dns解决的工作，但在海量域名数量的情况下，bind也确实存在着一些问题：
1、域名解析信息全部存储在文本文件中，这非常容易导致由于编辑出错导致的域名解析出错。
2、bind运行时将全部的解析信息放在内存里，如果数量巨大将可能出现内存不足的情况，同时解析信息重新加载时所耗费的时间也非常值得考虑，由于加载时间较长，所以基本可以不考虑动态的进行域名的调整。
dlz就是为了解决这个问题而针对bind开发的组件，可以将域名解析信息放在数据库中，从而避免域名信息变动时重新加载的时间，在变动后马上生效。
dlz支持多种数据存储形式，包括文件系统，Berkeley-DB，Postgre-SQL，MySQL，ODBC，LDAP等等。性能的比较在这里。
bind dlz这种提供动态的域名调整，并且仍然可以提供高性能的dns解析服务的特点可以应用于提供二级或三级域名服务的分布式系统的前端，对不同的域名解析到所在服务器组上，从而实现可扩展的系统架构。
Posted by yudunde at 09:12 PM | Comments (1)
从Technorati看博客搜索的发展
互联网经过多年的发展，信息的组成已经不再局限于简单的发布与共享，特别是博客的兴起与RSS的广泛应用。信息的发布源已经由政府，公司，机构逐渐延伸至个人。对于传统信息的发布，往往是以信息的广泛传播，提升知名度，增加访问量，从而直接或间接的创造价值为目的。这就是媒体的特性，作为媒体的角色出现了以新浪为代表的大量的网站。
而个人的信息发布往往是为了个人表达的需要。互联网中的个人数量非常庞大，而这些用户分布在各个博客服务商，也有很多人自己搭建平台，创建博客。在这同时，也带来一个问题：信息无法集中的展示，影响力无法得到充分展现，这时博客搜索的出现可以说是顺其自然的。而且按照目前搜索已经超越任何一家门户网站来看，博客搜索也将超越任何一家博客服务提供商。
博客搜索可以解决以下几个问题：
1、如何将这些博客有机的组织在一起，将好的内容筛选出来，并让有价值的内容更加广泛的传播和引用。这就有点像Qihoo和ChinaBBS，这是最简单的层次。
2、根据博客之间相互的引用，发现博客之间相互的关系，从而绘制出一张博客世界的网络。很多人在博客里面使用大量链接，主要的目的是增加博客的外延，给者更加广阔的阅读空间，提供文章写作背景，或者说明文章引用。这个天然的特性使得对博客之间或者是博客与信息之间天然的产生了一张巨大的信息网。这可以算的上是真正的SNS，是通过软链接实现的，不需要人为的去维护，目前像UUZone，既想实现SNS，又简单的只通过添加好友的方式来实现这样一张网络的方式属于硬链接，非常难以实现。它有两方面的要求非常高：一是需要用户不间断的进行维护，二是要求用户集中在网站上进行注册，这两方面都非常难以发展。
3、对博客内针对第三方信息的引用进行挖掘，产生出新的价值。单个的博客传递的信息比较局限，可能是对一部片子的观后感，可能是对某个餐厅的评价，可能是对某个人物的评论，但把所有博客的内容综合起来，我们可以得到一些很有意思的数据。例如：http://www.technorati.com/pop/books/。这是根据博客文章里对书的链接从而计算出来的书的流行程序排名。同理，我们可以计算出电影的，名星的。但这些有个前提，就是有一个结构化数据的访问中心，大家都对这个中心比较认同，前面就是根据对Amazon这个信息中心内页面的引用，电影则是对IMDB内停息页的链接，国内卓越，当当都可能成为这个信息中心，豆瓣也非常有这个可能，甚至我觉得它的可能性还要大一些。
4、对最新的博客内容进行分词，发现最近的流行词汇。在这方面，Tag还非常初级，目前被广泛使用的Tag大多数是一些像“生活”，“博客”之类的没有什么时效性价值的词，要真正获得当前的热点目前没有什么太好的办法，只能通过分词解决。分词后的计算是一个非常惊人的计算量，如何优化这方面的算法将是一个竞争比较激烈的领域。
5、对结构化内容的综合呈现，例如：http://www.technorati.com/tags/%E5%8D%9A%E5%AE%A2%E7%BD%91，
http://www.booso.com/tag/%B2%A9%BF%CD%CD%F8/，将博客和图片同时呈现在一个界面，有效的节约的用户的时间，随着将来格式化数据的越来越丰富，这个页面会越来越丰富，甚至将来会与门户网站的专题有的一拼，当然肯定没有编辑做出来的专题那么有条理，界面那么漂亮，但在数量上肯定是专题所无法比拟的。
以上几个方式，与用户行为基本无关（当然，写博客本身就是一种用户行为，这也是与网页搜索相比，博客搜索天然具有的优点），在没有用户参与的情况下也可以比较好的实现，当然前提是技术上的实现。当有了用户行为，并加入了用户行为分析后，相信结果还会进一步得到优化。
Posted by yudunde at 05:17 PM | Comments (2)
January 16, 2006
donews也要做博客服务？
这个话题有点奇怪，原来一直以为donews一直是在做博客服务的，想了一下才记起来.text用户不是自动注册的，估计原来的博客用户都是手动开通的。只是手动开通的用户带来的访问量已经排到了现在的名次，想想真是很不简单。
但这并不代表donews做开放的博客服务会获得成功，开放式博客系统大规模的访问不是改一个wordpress出来要吧承受的了的。即使大规模用户的博客系统开发成功，同时维护三套博客系统对于现在的donews来说也绝不会是一件容易的事情。建议donews还是规划好，做好充分的准备再做。
Posted by yudunde at 09:34 PM | Comments (1)
January 13, 2006
使用memcached进行内存缓存
旧文重发
2005.8.9
通常的网页缓存方式有动态缓存和静态缓存等几种，在ASP.NET中已经可以实现对页面局部进行缓存，而使用memcached的缓存比ASP.NET的局部缓存更加灵活，可以缓存任意的对象，不管是否在页面上输出。而memcached最大的优点是可以分布式的部署，这对于大规模应用来说也是必不可少的要求。
LiveJournal.com使用了memcached在前端进行缓存，取得了良好的效果，而像wikipedia,sourceforge等也采用了或即将采用memcached作为缓存工具。memcached可以大规模网站应用发挥巨大的作用。
Memcached是什么?
Memcached是高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。
Memcached由Danga Interactive开发，用于提升LiveJournal.com访问速度的。LJ每秒动态页面访问量几千次，用户700万。Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。
如何使用memcached-Server端?
在服务端运行：
# ./memcached -d -m 2048 -l 10.0.0.40 -p 11211
这将会启动一个占用2G内存的进程，并打开11211端口用于接收请求。由于32位系统只能处理4G内存的寻址，所以在大于4G内存使用PAE的32位服务器上可以运行2-3个进程，并在不同端口进行监听。
如何使用memcached-Client端?
在应用端包含一个用于描述Client的Class后，就可以直接使用，非常简单。
PHP Example:
$options["servers"] = array("192.168.1.41:11211", "192.168.1.42:11212");
$options["debug"] = false;
$memc = new MemCachedClient($options);
$myarr = array("one","two", 3);
$memc->set("key_one", $myarr);
$val = $memc->get("key_one");
print $val[0]."\n"; // prints 'one‘
print $val[1]."\n"; // prints 'two‘
print $val[2]."\n"; // prints 3
为什么不使用数据库做这些？
暂且不考虑使用什么样的数据库(MS-SQL, Oracle, Postgres, MysQL-InnoDB, etc..), 实现事务(ACID，Atomicity, Consistency, Isolation, and Durability )需要大量开销，特别当使用到硬盘的时候，这就意味着查询可能会阻塞。当使用不包含事务的数据库（例如Mysql-MyISAM），上面的开销不存在，但读线程又可能会被写线程阻塞。
Memcached从不阻塞，速度非常快。
为什么不使用共享内存?
最初的缓存做法是在线程内对对象进行缓存，但这样进程间就无法共享缓存，命中率非常低，导致缓存效率极低。后来出现了共享内存的缓存，多个进程或者线程共享同一块缓存，但毕竟还是只能局限在一台机器上，多台机器做相同的缓存同样是一种资源的浪费，而且命中率也比较低。
Memcached Server和Clients共同工作，实现跨服务器分布式的全局的缓存。并且可以与Web Server共同工作，Web Server对CPU要求高，对内存要求低，Memcached Server对CPU要求低，对内存要求高，所以可以搭配使用。
Mysql 4.x的缓存怎么样?
Mysql查询缓存不是很理想，因为以下几点：
当指定的表发生更新后，查询缓存会被清空。在一个大负载的系统上这样的事情发生的非常频繁，导致查询缓存效率非常低，有的情况下甚至还不如不开，因为它对cache的管理还是会有开销。
在32位机器上，Mysql对内存的操作还是被限制在4G以内，但memcached可以分布开，内存规模理论上不受限制。
Mysql上的是查询缓存，而不是对象缓存，如果在查询后还需要大量其它操作，查询缓存就帮不上忙了。
如果要缓存的数据不大，并且查询的不是非常频繁，这样的情况下可以用Mysql 查询缓存，不然的话memcached更好。
数据库同步怎么样？
这里的数据库同步是指的类似Mysql Master-Slave模式的靠日志同步实现数据库同步的机制。
你可以分布读操作，但无法分布写操作，但写操作的同步需要消耗大量的资源，而且这个开销是随着slave服务器的增长而不断增长的。
下一步是要对数据库进行水平切分，从而让不同的数据分布到不同的数据库服务器组上，从而实现分布的读写，这需要在应用中实现根据不同的数据连接不同的数据库。
当这一模式工作后（我们也推荐这样做），更多的数据库导致更多的让人头疼的硬件错误。
Memcached可以有效的降低对数据库的访问，让数据库用主要的精力来做不频繁的写操作，而这是数据库自己控制的，很少会自己阻塞 自己。
Memcached快吗？
非常快，它使用libevent，可以应付任意数量打开的连接（使用epoll，而非poll），使用非阻塞网络IO，分布式散列对象到不同的服务器，查询复杂度是O(1)。
参考资料：
Distributed Caching with Memcached | Linux Journal
http://www.danga.com/
http://www.linuxjournal.com/article/7451
Posted by yudunde at 02:58 AM | Comments (3)
January 09, 2006
互联网结构化数据时代
近期互联网出现了一些有趣的应用：博客，图片博客，贴吧，douban，招贴栏。这些应用的共同点之一就是数据的结构化。
以往互动的形式基本上就是论坛。在那个时期产生了大量的论坛网站，xici，xilu，天漄等等。论坛的发展经画了从开始的单版面到多版面，然后到任意申请版面的过程。论坛上讨论的内容也是五花八门，基本上所有的内容形式都可以通过论坛来进行。
互联网没有停止发展的脚步，论坛使用的通用的数据结构已经不能满足越来越多，越来越细分的市场需求，于是博客，贴吧，招贴栏等等以某种结构化数据为基础的应用大行其道。
从google base也可以看出google对这一发展趋势的理解：从博客到租房信息，从人物信息到产品介绍，针对种种独特的数据结构的应用必将越来越多，而且越来越受人欢迎。
结构化的数据更加容易检索。非结构化的内容难易进行很好的搜索，因为内容杂乱无章，仅能凭语义进进分析，精确度有待提高。搜索领域有一个重要研究方向就是IE(Information Extraction)。而基于结构化数据的应用，可以非常方便的进行信息抽取，进而准确方便的进行检索。
结构化的数据更加容易传递。数据也是一种服务，我一直有个理解就是博客实际上是作者提供给读者的互联网服务，由于有了rss的存在使博客从本质上与个人主页区分开来。而基于结构化的数据的应用都像博客一样，提供了服务。这个服务不仅仅提供给读者，也提供给产业链上的下游环节，用于再加工，再组织，进行附加增值生产。
未来的互联网如何发展尚未可知，但目前的互联网，结构化数据应用的浪潮已经来临。
Posted by yudunde at 11:05 PM | Comments (0)