Monthly Archives: January 2011

众声喧哗下的新媒体——进化版采集站?

前言:其实这篇文章本来的标题是《2010 – 2011,沉淀,成长,与新的困惑》(再之前还有个标题叫做《博主和评论者们的困惑》)。几个月前,我在某个讨论采集站的博客一游的时候,自嘲的说了句:“半个采集站的编辑路过”。而留言之后,却感到深深的困扰:我在51CTO,或者说,51CTO系统频道所做的,究竟是不是采集站? 在2011年1月1日,我本来想用上面那个标题将自己的困惑和思考记录下来,但感觉思维混乱,难以组织清楚,所以就搁置了。直到前两天有机会跟文子哥单独聊起了这个话题。文子哥问我:“你想过新媒体方面的事情吗?”讨论了半天,我问他:“你觉得我们到底是不是采集站?” 于是,就有了现在这篇文章的标题,以及下面的这篇文章—— —————————我是正文的分割线——————————— 自从Web 2.0技术诞生以来,互联网就进入了一个众声喧哗的时代。以前,所有的人类只有少数几个喇叭,这几个喇叭的持有者名叫媒体;而在众声喧哗的时代,每个人手中都捏着一只喇叭。 ——北京大学新闻与传播学院副教授胡泳(懒菜理解版,非原话) 在这个时代,互联网内容的创造者是群众。关于这一点,我在前两年的很多文章中都提到了(比如创新在别处,有关51CTO家园的上线,等等),在本文中就不必多说。本文要讨论的,是媒体在这个众声喧哗时代中的价值,以及在我的理解中,新媒体未来可能存在的形式。 互联网用户 Web 2.0是一种革命,其最大的革命性质之一就在于它将读者(内容受众)与作者(内容贡献者)之间的界限彻底模糊化了。在Web 2.0时代,不再有纯粹意义上的读者与作者之分,而是一个广义的“互联网用户”的概念。从内容的角度而言,互联网用户至少有五种身份: 读者 反馈者 参与者 内容制造者 传播者 每一个互联网用户,在不同的时间和场景下,会扮演一个或多个角色;而互联网的发展结果之一,就是互联网用户在这五个角色当中可以进行快速的转变。事实上,几乎所有的Web 2.0产品,都在尝试引导用户完成从读者到另外四个角色的转变。 应该说,Web 2.0产品这个词有点狭隘了。如今这个时代,互联网上的一切都是产品。论坛是产品,博客是产品,应用程序是产品,网站是产品,专题是产品,沙龙是产品,甚至我lazycai这个ID也是个产品。媒体本身也是产品。51CTO和CSDN是两个不同的产品,51CTO系统频道和51CTO开发频道也是两个不同的产品。 而编辑,就是媒体这个产品的产品经理。 媒体即服务:MaaS(这算不算滥用热词?) 身为产品经理,首要任务是实现产品对用户的价值,比如是游戏就要好玩,是阅读器就要提供好的阅读体验,是写字板就要提供好的手感和视觉效果,等等。PV、用户数量神马的固然重要,但重要性绝对不在第一位,因为如果产品是垃圾,其他的一切都是浮云。 媒体是一个怎样的产品?传统的媒体不用说,制造内容,传播内容。仅仅在五年前,读者获取资源的渠道还十分有限,所以媒体提供的内容就物以稀为贵了。而现在,无论是获取内容、制造内容还是传播内容的门槛都几乎没有了,内容不稀反滥,所以媒体提供的内容自然价值就大大的少了(当然,这个“滥”也只是相对的。无论哪个时代都仍然会有内容是稀缺的,就好像无论哪个时代都有无法医治的病症一样)。但是,媒体并没有因此失去价值,因为互联网用户仍然有未解决的问题,并有新服务的需求: 身为读者,如何只获取我感兴趣的内容(比如不用再从上千条Google Reader更新中挑选出十条自己真正喜爱的)?能不能在我工作忙的时候只获取最精华的内容?如何剔除掉重复的内容?如何将我阅读过的内容归档或分类? 我能否简单的表达我对一篇文章的喜爱(或讨厌)? 我能否方便的对一篇文章表达我自己的看法?作者能看到我的评论并回复我么?作者的回复和我的评论能显示在我个人的空间里么? 我也想写文章,是写博客还是发论坛,还是投稿呢?别人写给我的评论,我都能看到么?别人觉得我的文章好还是不好呢?有人推荐我的文章么? 我想推广我刚写完的文章,是去论坛发个帖子,去QQ群,或是找编辑帮我推广下?我推荐过的优秀文章,能不能生成一个列表跟大家分享? 互联网用户们新的需求当然远不止这些,但对于“新媒体”这个产品,我认为这些需求都是要优先考虑的。有人可能发现了,有一些产品已经解决了这个列表中的部分问题,比如Google Reader就一直在进行这方面的尝试,包括51CTO家园也在尝试解决一些问题。但是,对于Google Reader而言,即使Google的算法再精明,Reader的使用者也在足够活跃的提供反馈数据,但Reader的性质毕竟只是一个内容中转站,而没有提供一个内容托管的平台,所以很多需求注定难以满足;长远来看,反而是家园这种SNS平台更有可能成为“新媒体”这个产品。 基于SNS的新媒体 下面就简单聊聊我个人对新媒体这个产品的实现思路吧。当然,新媒体肯定不止一种设计思路,我只是把自己的思路分享出来做个参考。 首先,新媒体的底层仍然需要是一个采集站。很多媒体同行一提到采集站就容易联想到垃圾站,但其实采集站跟垃圾站完全是俩概念,这俩概念的混淆纯粹是因为很多采集站都在采集垃圾(或者把采集过来的内容当做垃圾)。 为什么说新媒体仍然需要是个采集站?其实这个问题我已经不用回答了,因为你哪怕有100个编辑和100个专家作者每天写文章,这样的内容产量相对整个互联网而言也只是九牛一毛;更重要的是,你写的未必比人家好,因为术业有专攻,再牛B的专家也不可能样样精通——最好的创新永远在别处。这倒并不是说媒体就不该做原创了,新媒体在互联网上仍然需要保持“内容制造者”这一身份——你的原创代表了你的风格,这是你被人们记住的原因——只是这一身份已经不再有什么特别之处了,给用户带来的价值和一个博主并没有什么区别。 … Continue reading

Posted in editor | Tagged | Leave a comment

系统运维秘诀:变化,监控,扩展(技术篇)

这篇文章感觉真的不错,忍不住搬运到自己博客这边来: 编者按:本文是SixApart的MySQL DBA,Dormando在2008年总结的一套运维秘诀。编者前日看到Google系统管理员Tom Limoncelli在Everything Sysadmin上推荐这篇文章,并表示这篇文章的内容在今天仍然适用。阅读之下,发现的确是篇难得的好文章,有大量的经验分享总结。现在51CTO系统频道特将本文全文翻译过来,当作给各位运维读者们的2011新年礼物。 完全理解本文内容需要一定的运维经验。您可能对这些文章也会感兴趣: 系统管理员必须了解的六大铁律 系统管理员都应该知道的系统常识 漫谈运维:半神半仙亦民工 以下为正文。 在运维管理的过程中,我发现了很多有价值的秘诀,本文是这些秘诀的一个总结。虽然这些秘诀可能比较“唯心”,但是我还是把它们总结出来了,相信它们会对你有帮助的。 Dormando的运维秘诀分成以下三大篇: 技术篇 交流篇 实践篇 下面先从技术篇开始。交流篇和实践篇会陆续整理放出。 技术篇 为变化而设计 ◆Google的秘诀是正确的——“为变化而设计”。“变化”就是不得不部署新的软件,升级现有的软件,进行扩展,设备损坏,以及人员流动等。 ◆每一件事情都是在寻找平衡点。你也许会认为把你的系统和某个操作系统或某个Linux发行版牢牢地绑定在一起是一个好主意,但事实上这跟把它们完全隔离一样糟。如果实在有必要,你可以进行分层,并使用一点间接性。 ◆这并不意味着你的系统必须是平台无关的。其实我们的目的很简单:一变二,二变二十,一个系统必须可以应对各种突发事件。也就是说,如果一个系统管理员被公共汽车撞了,你有应对的方案!如果挂载的硬盘出现故障了,你有应对的方案!如果某些人运行了rm -rf /,你也有应对的方案!增量的进行变更。记得安全更新,以及保持内容更新。 使用自动的,可重复的构建过程 ◆不要手动构建任何东西。如果你一定需要手动构建,那么就做两遍,在做第二遍的时候把用到所有的命令都提取出来。 ◆下面这一点十分重要:将新硬件上线到生产环境的过程不应该超过15分钟,而且这个过程必须足够简单。否则,当一个服务器出现故障,而没有人知道如何更换它的时候,你就该倒霉了。 ◆下面这一条是普世真理:这个世界上不存在“一次性”的服务器构建。即使你的服务器只需要构建一次,但只要你构建过一次,就一定会有第二次。比如,当它损坏的时候,或者你必须进行一次重大的升级才能让它在在接下来的两年时间里更加稳定的时候。 ◆测试,检查新构建好的服务器。这应该是比较容易的,因为你的构建过程都是自动化的,对吧! ◆脚本化的构建,意味着从某个Linux发行版的V3升级到V4应该是很快的。安装 V4,对脚本进行测试。如果有问题,参考文档并修复它,直到它可以再次正常工作。这最多应该是一个星期的工作,而不是一个长达一年的浩大工程(因为那时,刚刚完成的V5已经发布了!) 使用冗余 ◆容易重新构建,并不意味着你可以忽视冗余。跳转盒,邮件服务器,计费网关,等等。如果其中的一半挂掉了却并不造成客户的宕机,生活将会变得更加简单。 ◆按照以上方针来做的话,当某个设备在凌晨3点出现故障的时候,你可以“以后再处理那个出现故障的设备!”,把冗余的机器先替换上去。 ◆下面这一条是个聊胜于无的解决方案:Rsync。DRBD也许也不是一个完美的解决方案,但是它可以提供令人称奇的服务。(参考阅读:DRBD笔记,DRBD实例1,DRBD实例2) 使用备份 ◆备份是个严肃的话题。使用硬盘,烧录磁带。压缩它们,移动它们,并行地运行。对每一样东西进行备份! ◆如果你的构建过程是自动的,整个过程都可以被备份。如果到目前为止的几条你都做到了,那么一个真正的“灾难恢复”计划也许并不是那么遥不可及的。 监控正确的东西 ◆监控你能监控的所有东西,而且要用正确的方法来进行监控。如果你的NFS服务器挂掉了,不要让你的监控工具发送1000条警报。如果对你的系统来说,超时的警报没有什么实际意义,那就别让它发。要针对各种具体的情况进行成功性测试:是的,这个服务可以进行一个新的TCP连接,它甚至可以响应,但是它还记得它要做什么工作吗? ◆如果你有500个Web服务器,其中一个挂掉了,你可能不必马上知道这个情况。但是,如果负载均衡器没有把这台机子踢出去,导致错误报告出现在了用户的屏幕上,那么你必须知道这个情况! … Continue reading

Posted in IT | Tagged | Leave a comment