3月2日，新浪公司对外公布财报，其微博用户总数已突破一亿，四个月内数量翻倍。腾讯微博此前也宣布用户数过亿。加上搜狐、网易等门户微博和饭否等其他独立微博，中国的微博用户数已经达到2亿以上，占总人口数近六分之一。

面对蓬勃发展的微博现状，目前大家最关注的是其商业模式，即通过什么方式来盈利。在美国，Twitter已经有一些尝试，而中国目前仍处于探索过程中。但我们如果认为微博很难获得盈利（或者说是获取可观的收入），是因为我们的思考陷入了思维定势，认为Twitter现在的盈利是怎样的，中国的微博客也是如此。
中国微博网站要实现盈利，就要有创新的勇气，不能简单的“C2C”Twitter，更不能把Twitter的全盘做法都是“C2C”到中国，一定要有自己的创新模式。

这种创新模式就是走微改革和微商务之路。

如果微博客是在一个微商业的环境，一个大型微博客网站要实现商业收入是很容易的事情。
分析微博的商业模式应该先从微博的用户规模、情况及用户行为来对其商业价值进行分析，本文将就微博的盈利模式做详细探讨。

何玺通过研究和对比一些监测机构对微博的研究报告，微博的商业价值主要表现在以几点：

一、于微博平台：积累了庞大的用户群数据，用户就是平台的一切，用户无价。

二、于个人微博：积累众多粉丝，特别是用心经营的微博，将积累庞大的粉丝群，不管是@李开服 @蔡文胜 @姚晨 这样的名人，还是一些草根粉丝，只要用心经营的，目前粉丝有过千万的，最少的也上百万。以上数据还显示，65%的粉丝追随过品牌，74%风水因为喜欢而追随，相比其它社会化媒体而言，微博由于彼此交流的及时性，话题的共同性等，让微博的信任度最高。对个人微博来说，粉丝是无价的。

三、于企业微博（参考北京海纳互联网研究中心资深分析师贺海峰的专栏，中美微博发展现状与商业模型分析）：

1、是企业信息发布平台。 戴尔从2007年3月开始使用 Twitter平台，即Twitter订阅戴尔的信息服务。据统计，戴尔在 Twitter通过打折信息提醒等服务，获取了100万美元营收。据悉，捷蓝（JetBlue）航空、Comcast、戴尔、通用汽车、柯达等多家美国企 业在采用Twitter平台同普通消费者交流，然后再出售相应产品。相关的案例表明，Twitter类的微型博客是一种更快、更有效、更经济接触客户的企 业信息的发布平台。

2、是企业的快速客服通道。 用户在对您的企业产品或服务发出了 质疑、请求帮助等信息时，对微博用户实时跟踪的企业便可以快速地了解到， 并通过微博或邮件或电话等方法回复，避免用户因为不满而大规模地在网上传播，快速解决用户的问题，能够较为有效地提高客户的满意度。

3、是企业深度了解消费者的平台。 微博是企业较好地聆听、 学习以及了解客户的有效平台。微博用户在微型博客上记录了自己日常的真实 想法、爱好、需求、计划、感想等，真实地表露了自己的消费需求、偏好、生活形态、品牌态度等，尤其是一定程度上能够了解消费者对产品的态度、需求和期望、 购买渠道、购买考虑因素，有助于企业深度了解消费者，从而制定或者优化产品策略、营销策略。

4、是企业口碑监测的平台。 对于企业的市场公关人员来说，互联 网上的“公关危机”就如洪水猛兽般袭来，令人胆战心惊。互联网特有的病毒式传 播，使得用户对某些产品或企业服务的负面言论、品牌的负面评价都有可能导致企业的公关危机。因而，广告主对微博用户的品牌口碑实时监测尤为重要。而微博平台具有的搜索功能，以及相关的实时监测功能，使企业能实时监测品牌的口碑成为可能。

基于微博快速增长和庞大用户群，以及其巨大的商业价值，我认为微博就是为web3.0时代的电子商务而生的，其商业模式可以往以下几大方面进行尝试：

一、打造粉丝电子商务平台：

团购+个人网店：2010年的团购有多火？不用我说了吧。目前团购网站基本成为了各个平台的标配。各平台为什么要搞团购？因为他们有流量！人们说，榜样的力量是无限的。新浪粉丝过百万的账户有多少个？十万的有多少个？我个人统计了一下，@姚晨每条微博的转发数，最少的几百，最多的几万。同样的，新浪微博排名第一的草根名微博@veggieg，每条微博的转发数，最少的几百，最多的几万。粉丝十万左右的微博，微博的转发数，最少的几十，最多的几千。这再次说明了微博强大的粘性（活跃度、关注度非常高）。

1、微团购：给每个ID的专门的团购页面，方便其开展团购活动。谁不想赚钱？谁没有点兴趣爱好？谁没有一些资源？如果有一个渠道和通路能帮助我们赚钱，而且操作简便，谁会不愿意呢?目前正火爆的团购模式，页面简单，团购平台只需要制作一个团购模板，然后由用户自行开展团购业务，效果肯定很好。
2、微网店：借助团购模式，发展移动网店。微博的另外一个特点就是移动性强，用户粘性高，当团购业务帮助人们赚到第一桶金的时候，微博平台可以拓展其商务特性，发展移动网店，帮助用户赚钱。当粉丝电子商务平台成长成熟以后，微博的盈利也就不是问题了，至于如何盈利，可参照淘宝目前的盈利模式。对于微博平台来说，促进了用户维护、创造博客的特性，微博将不再是一种新鲜应用，而成为一种商务应用，其粘性将大大增加（一个能帮助自己赚钱的工具，谁愿意丢掉呢？）。同时，也能促进其他用户的积极性，积极维护博客，积极与粉丝互动，积极开展有价值的商业活动或者主题，形成良性循环。但是商务活动也面临一个信用体系的监督与维护问题，可参照淘宝信用体系。

二、打造WEB3.0时代的社交网络平台：

LBS+SNS：当下欧美流行的互联网应用加上社交网络的粘性，能够让微博平台具有更大的延展性。
1、LBS：粉丝的忠诚度是需要维护的，维护可以通过互动活动，也可以通过更为直接的利益来进行驱动。开发类似Foursquare的签到应用，并把签到服务与用户互动联系起来，通过签到，给予粉丝相应的荣誉，同时，荣誉能够换取相应的特权，比如团购能打折，定期免费领取礼物，高等级会员的专享标志等。
2、SNS：可以拷贝开心网等SNS网站的模式，开发属于自己的应用插件，以增加用户粘性。
以上应用成功的情况下，可根据平台用户的盈利情况，收取平台管理费，或者交易佣金来盈利。

三、打造WEB3.0时代的自媒体展示平台

微博自发性、原创性、病毒传播的特性，决定了其作为新闻源，话题中心的角色。所以可以通过开发、丰富其表现形式，让每个微博用户都可以通过自己擅长的方式来把个人微博打造成为一个自媒体平台。

比如语音微博，其作为新浪微博推出的特色业务，所有用户在手机号码绑定新浪微博账号后，均可通过拨打语音微博号码注册、录制、发布语音微博，同时还可收听自己已经发布的语音微博，每条录制时间限定在一分钟之内。语音微博发布成功后，将会同时在新浪微博发布该条语音链接，点击播放按钮即可收听该语音微博。王菲通过语音微博方式，先后上传了三个自己录制的语音作品。截至2月20日早间的统计数据，她发送的这三条语音微博转发量超过5万条，评论近3万条。创新工场CEO李开复则在其语音微博上演示了让人惊奇的口技绝活，影视新星王珞丹在微博上俏皮献唱，都赢得网友阵阵喝彩。李开复在微博中表示，语音微博的受欢迎程度要超越文字，原因在于：1、非语音：唱歌、音乐、可爱动物。2、适合耍嘴皮：相声、笑话、口技、朗诵。3、特殊内容：名人说错话。资深IT分析人士陈永东表示，语音微博的兴起，有可能出现越来越多的“微博广播电台”，着迷者会长时间地进行个人兴趣话题的广播。也可以为草根提供走红的舞台。而且还能促进普通话的普及。

平台为用户提供一个广告展示页面，网络商店，根据用户的盈利情况，收取平台管理费或者交易佣金实现盈利。

四、通过为企业开展监测服务收费

微博通过技术手段对不同品牌、不同产品的消费者需求进行记录与统计，对品牌或产品的评价进行分类记录与统计，形成相关的监测服务，为企业实时了解用户需求与品牌口碑提供动态工具。 通过卖“具有真实价值”的报告来盈利。

五、品牌广告收入

微博通过建立大平台，依靠较多的用户量带来较多的点击率，可以吸引品牌广告的投放。据尼尔森公司数据显示，09年 4月份，twitter 美国用户达 1700 万，全球用户达 2400 万，与去年相比增长了 10 倍，而到 10 月份，其用户已经达到了 5000 万，在短短的 4 个月内又增长了一倍多。四月份，twitter 发布日语版本，在网站首页右上角推出了面向所有日本用户的大横幅广告，未来将会逐步在其它国家推广。此外，据戴尔公司表示，截至到 2009 年 6月份，twitter 服务为戴尔带来了超过 300万美元的收入，消费者通过 twitter进入戴尔网站进行购买。尤其是在过去的半年内，戴尔公司通过 twitter获得的销售收入达100 万美元。但是由于社交网站有低广告响应率的特点，因此广告客户也会慎重考虑在像微博这样的社交网站新开的论坛上打广告。

六、通过APP等形式，和其它网站进行收入分成

微博可以利用自身庞大的用户群，建立类似于搜索等方面的工具，把大量的用户群转移到其它网站上，进而和其它网站进行广告分成。

七、用户数据库盈利模式

在微博中，众多的用户公开隐私观点，而这些用户数据和信息数据都值得深层次挖掘，因此，可以对想利用微博进行营销公司提供有价值的数据和信息，让营销者可以批量 follow 这些用户。例如，戴尔就通过网络监控公司 Visible Technologies 在 twitter上监控以掌握其用户对公司产品的反馈。

八、对企业用户进行收费。

建立品牌ID商城，通过认证，入场费以及收取交易佣金来获取盈利。

九、营商分成

随着 3G 的正式商用，移动媒体将迎来快速发展期，而微博天生就具有完全和移动介质良好融合的特点，这样就可以和移动运营商进行流量和短信分成。例如，twitter 的大部分流量来自手机——手机互联网和短信。

以上9种盈利模式，何玺最看好粉丝电子商务，何玺认为其将成为WEB3.0时代的经典商务模式。

来源：http://bbs.paidai.com/topic/42673

标签: weibo, 微博, 盈利模式, 电子商务

转载自 http://hi.baidu.com/01234567891011121314151617181920/home

标签: digg, 推荐, 算法, 引擎, 排序

云存储网站Dropbox宣布，用​户总数达到了2500万。这个数字令人印象​深刻，因为一年半前，它的用户总数已经是3​00万了。短短18个月，在一个这样大的基​数上，继续扩张八倍多，真可谓势头惊人。惊叹之余，许多人很好奇，Dropbox到​底花了多少钱，才能够服务这么多用户？因为​除了付费用户以外，它没有其他收入来源。相​反地，每新增一个注册用户，它就必须向他免​费提供存储空间。只有当用户占用的空间超过​2GB时，才需要付费：每月9.99美元（​50GB）或者19.99美元（100GB​）。
两周前，云存储网站Dropbox宣布，用户总数达到了2500万。
这个数字令人印象深刻，因为一年半前，它的用户总数已经是300万了。短短18个月，在一个这样大的基数上，继续扩张八倍多，真可谓势头惊人。

惊叹之余，许多人很好奇，Dropbox到底花了多少钱，才能够服务这么多用户？因为除了付费用户以外，它没有其他收入来源。相反地，每新增一个注册用户，它就必须向他免费提供存储空间。只有当用户占用的空间超过2GB时，才需要付费：每月9.99美元（50GB）或者19.99美元（100GB）。

那么，为了支撑2500万使用者，它到底要发展多少付费用户才够啊？
加拿大程序员Michael Woloszynowicz，就为Dropbox算了一笔账，估计了一下它每个月的总支出。

一、存储费
Dropbox没有自己的存储设备，所有文件都放在租来的Amazon S3服务上面。
这里计算的困难在于，每个用户不一定把2GB的免费空间都用光，而S3是根据实际使用的空间收费的。此外，Dropbox还部署了"防止文件重复上传"的机制，如果确认不同用户上传的是同一个文件，则只保存一个样本，这可以大大减少影音文件占用的空间。最后，用户之间分享的文件，也只保留一个样本。
我们假定重复文件的影响因子是20%，那么平均每个用户最多占用的空间就是1.6GB。2500万用户占用的空间总和，就是40000TB。我们把这个数字，当做Dropbox存储空间的上限。
另据资料透露，2009年底，Dropbox的用户总数达到300万时，占用的存储空间总和是1300TB，平均每个用户占用433.73MB的空间。假定这个水平保持不变，那么2500万用户就要占用10579TB。我们把这个数字当做Dropbox存储空间的下限。
根据S3的价目表进行计算，

40000TB存储空间，每个月的费用接近240万美元；10579TB存储空间，每个月的费用接近75万美元。
因此，Dropbox的存储费，每个月估计在75万--240万美元之间。

二、请求费
S3除了对存储空间收费，还对HTTP请求收费。PUT/COPY/POST/LIST请求，每1000次收费0.01美元；GET请求，每10000次收费0.01美元。
假设每个用户每天发出10次PUT/COPY/POST/LIST请求和10次GET请求，2500万个用户就是每天各2.5亿次，费用分别为2500美元和250美元，合计2750美元。以一个月30天计算，每月的请求费就是8.25万美元。

三、流量费
Dropbox声称，每天要接受2亿次上传。根据一个小范围的调查，Dropbox上面的文件的平均大小是1.6MB。那么，2亿次上传相当于305TB，考虑到重复文件的影响因子是20%，也就是说实际只需要上传244TB。S3的上传流量费是0.1美元/GB，则每天的费用是2.5万美元，相当于每月75万美元。
Dropbox没有公布下载次数。假定每天的下载次数与上传次数相同，即下载305TB的数据，S3的下载流量费是0.08美元/GB，相当于每月75万美元。
两者相加，每月流量费总和为150万美元。
四、运算费
Dropbox还需要大量运算。以它现在的规模，至少需要200台服务器（或者服务器的实例）完成相关运算。假定每台服务器的成本是0.3美元/小时，就相当于每月4.3万美元。

五、人工费
Dropbox目前有44名员工，假定人均工资为10万美元/年（硅谷平均工资），就相当于每月36.7万美元。

六、总费用
将上面五项费用加总，就得到了用户规模2500万时，Dropbox的月度成本在274万美元--439万美元之间。

七、一些推论
（1）Dropbox每个用户的平均成本，在0.11美元--0.18美元之间。
（2）Dropbox的收费标准是9.99美元（50GB），所以每个付费用户的毛利在9.81美元--9.88美元之间。
（3）付费用户的数量达到27.7万--44.8万时，可以实现收支平衡。
（4）这占总用户的比例为1.1%--1.8%。也就是说，当用户转化率（customer conversion rate）不低于2%时，dropbox才不会亏损。
（5）收费网络服务的用户转化率，一般在0.5%--5%之间，Dropbox正好在这个区间内。
（6）考虑到已知的Dropbox的外部融资，仅仅为1000万美元，而它的月支出是百万美元级别的，所以可以断定它已经有几十万付费用户了。

标签: dropbox, 成本, 云计算, S3

Digg个性化推荐引擎

发布: 2009-10-30 19:41 | 作者: baifendian | 来源: 百分点推荐技术研究中心

标签: digg, 推荐, 引擎, 算法

转载自：http://www.thoughtrails.com/episodes/103-oauth

OAuth有什么用？为什么要使用OAuth？

用户希望在第三网站和应用上使用他在SNS网站上的用户信息，这些第三方网站联系SNS网站，但是由于没有用户认证信息，这时这些用户信息是不允许访问的。

举个我们身边国内的例子吧：比如 团购网站 你需要把一条团购信息发到你的新浪微博上并通知你的好友，以前的方法是你需要在团购网站输入你的新浪微博账号，密码才能调用，虽然网站上可能都自谓“不保留新浪微博用户名密码”，但是大家信吗？

OAuth就是为了解决这个问题而诞生的，用户访问第三方资源，不再需要网站提交你的用户名，密码。这样好处自己是安全，而且不会泄露你的隐私给不信任的一方。

在认证和授权的过程中涉及的三方包括：

服务提供方：用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。（上述所说的 新浪微博） 用户：存放在服务提供方的受保护的资源的拥有者。（你） 客户端：要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。（上述所说的团购网站，也叫第三方网站）

使用OAuth进行认证和授权的过程如下所示:

1第三方网站向SNS网站授权服务发出获取request token的请求。SNS授权服务响应请求，返回一个尚未认证的request token.

2第三方网站获取响应中包含的request token，按照协议规范，附带这个request token，将其重定向到SNS提供的授权页面(User Authorization URL)。如果用户没有登录，用户向普通登录一样，输入用户名和密码完成登录。如果用户已经登录（使用记录Cookie的方式），会出现一个页面，问用户 是否允授权共享他的SNS信息给第三方网站。

3一旦用户选择授权第三方网站，SNS网站将把Web浏览器重定向到第三方网站，同时把SNS的用户信息传递过去。 用户决定允许或拒绝授权给第三方网站，如果用户拒绝授权给此第三方应用，则被重定向到SNS的页面，而不会再回到第三方应用的页面上。 如果用户授权给第三方网站，那么，SNS授权服务接收此请求，将用户重定向到第三方网站提供的页面上，并传递被认证了的request token。这样第三方网站就可以访问SNS网站的用户信息了。

4第三方网站接收到认证的request token后，再次向SNS账号服务发起一次HTTP请求，以换取access token。 SNS 账户授权服务接收请求，验证是否合法。如果合法，则返回一个access token。

OAuth安全机制是如何实现的？

OAuth 使用的签名加密方法有 HMAC-SHA1,RSA-SHA1 （可以自定义）。拿 HMAC-SHA1 来说吧，HMAC-SHA1这种加密码方法，可以使用 私钥 来加密 要在网络上传输的数据，而这个私钥只有 Consumer及服务提供商知道，试图攻击的人即使得到传输在网络上的字符串，没有 私钥 也是白搭。

私钥是：consumer secret&token secret （哈两个密码加一起）

要加密的字符串是：除 oauth_signature 外的其它要传输的数据。按参数名字符排列，如果一样，则按 内容排。如：domain=kejibo.com&oauth_consumer_key=XYZ& word=welcome………………….

前面提的加密里面都是固定的字符串，那么攻击者岂不是直接可以偷取使用吗？

不，oauth_timestamp，oauth_nonce。这两个是变化的。而且服务器会验证一个 nonce（混淆码）是否已经被使用。

那么这样攻击者就无法自已生成 签名，或者偷你的签名来使用了。

标签: OAuth, 认证, 加密, 权限

    2008年9月15日上午10点，拥有158年历史的美国第四大投资银行—雷曼兄弟公司向法院申请破产保护，消息转瞬间传遍地球的各个角落。令人匪夷所思的是，在如此明朗的情况下，德国国家发展银行10点10分，居然按照外汇掉期协议的交易，通过计算机自动付款系统，向雷曼兄弟公司即将冻结的银行账户转入了3亿欧元。毫无疑问，3亿欧元将是肉包子打狗有去无回。

    德国经济评论家哈恩说，在这家银行，上到董事长，下到操作员，没有一个人是愚蠢的。可悲的是，几乎在同一时间，每个人都开了点小差，加在一起就创造出了“德国最愚蠢的银行”。实际上，只要当中有一个人认真负责一点，那么这场悲剧就不会发生。演绎一场悲剧，短短十分钟就已足够。

故事中淋漓尽致的体现了一种想当然做事的风格，的确值得我们深思。相信我们一定不会如此糊涂的丢失自己的“3亿欧元”。

<              &lt;
>              &gt;
"               &quot;
'               &apos;
\n            &#10;

用echo输出
<echo msg="${symlink_cmd}" />

则显示为：
[echo]              ln -s file1 fileA
             ln -s file2 fileB
             ln -s file3 fileC

标签: 转义, ant, phing, 持续集成, ci, build.xml

最近一直在折腾SCM/CI的相关东西，无奈相关资料虽然到处都有，却都比较零散，只能自己拼凑组织。无意中看到这本书的信息，不由眼前一亮，必须入手的一本书。

"ThoughtWorks Studio 的发布管理工具GO (原名为Cruise) 的产品经理 Jez Humble , 与David Farley一起，历经三年完成了《持续交付：通过自动化构建、测试、部署流水线实现可靠的软件发布》(Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation) 一书。原书的网站地址是：http://continuousdelivery.com/ ，同时建有GoogleGroup，名为continuousdelivery@googlegroups.com。"

中文版将由图灵出版，以下为第一章中的部分译稿 ：

我们将专注于构建、部署、 测试和发布过程 ， 因为相对于软件生产全过程的其他环节来说，这部分内容的论著相对较少。我们并不认为软件开发方法不重要，恰恰相反，如果没有对软件生命周期中其他方面 [H1] 的关注 ，而只把这些方面作为问题的次要因素草草对待， [H2]   就不可能实现可靠、迅速且低 风险的软件发布，以高效的方式将我们的劳动转化成劳动成果，并交到我们的用户手中。

当今有很多种软件开发方法，但它们主要关注于需求管理及其对开发工作的影响。也有很多优秀的书籍，详细讨论在软件设计、开发和测试方面各种各样的方法，但它们也只仅仅覆盖了将软件交付给客户或组织这一完整价值流的一部分。

一旦完成了需求定义、方案设计、开发和测试，我们接下来做什么？我们如何协调这些活动，使我们的交付过程更加可靠有效呢？我们如何让开发人员、测试人员，构建和运维人员[H3]在一起高效地工作呢？

这本书描述了从开发到发布这一过程的有效模式。书中讲述的技术和最佳实践将帮助大家实施这种模式，并展示它与软件交付中其他活动的交互协作方式。

本书的中心模式就是部署流水线（deploymentpipeline[H4]）。从本质上讲，部署流水线就是指一个应用程序从构建、部署、测试到发布这整个过程的自动化实现。部署流水线的实现对于每个组织都将是不同的，这取决于他们对软件发布的价值流（valuestream）的定义，但大家的实现原则是相同的。

某个部署流水线的实例如图1.1所示。
图1-1[H5]部署流水线
部署流水线的工作方式如下。对于某个应用程序的配置、源代码、环境或数据来说，任何变化都会触发一个新的流水线实例的创建。流水线的第一个步骤就是创建二进制文件和安装包。而其余部分都是基于第一步的产物所做的一系列的测试，用于证明第一步的产物达到了发布质量。每通过一步测试，都会使我们对“这些二进制产物与配置信息、环境和数据可以正常工作”更有信心。如果这个产品代码通过所有的测试环节，那么它就可以发布了。

尽管在持续集成这一流程中，部署流水线有其自身的基础，但本质上来说，它也是采纳持续集成原则后的自然而然的结果[H6]。部署流水线的目标有三个。首先，它让软件构建、部署、测试和发布过程对所有人变得可视，促进了协作。其次，它加速了反馈，以便在整个过程中，我们能够更早地发现问题并解决它。最后，它通过一个完全自动化的过程，使团队可以在任意环境上部署和发布软件的任意版本。

一些常见的发布反模式
软件发布的当天是最紧张的一天。为什么会这样呢？对于大多数项目来说，整个过程中发布时的风险是比较大的。

在许多软件项目中，软件发布是一个需要很多手工操作的过程。首先，由运维团队独自负责安装好该应用软件所需的操作系统环境，再把应用软件所依赖的第三方软件安装好。其次，将应用程序的软件成品[H7]复制到生产主机环境，然后将配置信息通过Web服务器、应用服务器或其他第三方系统的管理控制台复制到环境中，再把相关的数据复制[H8]一份到环境中，最后启动应用程序。假如这是个分布式的或面向服务的应用程序的话，可能需要一部分一部分地完成。

如上所述，发布当天紧张的原因应该比较清楚了：在这个过程中有很多步骤有可能出错。假如其中有一步没有完美地执行的话，应用程序就无法正确地运行。一旦这种情况发生，我们很难一下子说清楚到底是哪一步出了错。

本书将讨论如何避免这些风险，减少发布当天的压力，以及如何确保每次发布的可靠性都是可预见的。在此之前，让我们先澄清一下我们到底要避免哪类失败。下面列出了与可靠的发布过程相对应的几种反模式,虽然这些情况在我们这个行业中屡见不鲜。

反模式 ：手工部署软件

对于现在的应用程序来说，无论规模大小，其部署过程都比较复杂，而且包含很多非常灵活的部分。许多组织都使用手工方式来发布软件。也就是说部署应用程序所需的这些步骤是独立的原子操作，且由某个人或某个小组来分别执行。每个步骤里都有一些需要人为判断的事情，因此很容易发生人为错误。即便不是这样，这些步骤的执行顺序和时机的不同也会导致结果的差异性。而这种差异性很可能给我们带来不良结果。

这种反模式的特征是：

• 有一份非常详尽的文档，该文档描述了执行步骤及每个步骤中易出错的地方。
• 以手工测试的方式来确认该应用程序是否正确运行了。
• 经常发生这样的情形：在发布当天开发团队会接到电话，被通知部署出错了，以及出错的现象是怎样的。
• 在发布时，常常会修正一些在执行过程中发现的问题。
• 如果是集群环境部署，常常发现在集群中各环境的配置都不相同，比如应用服务器的连接池设置不同，文件系统有不同目录结构等。
• 整个发布过程需要较长的时间。
• 发布结果不可预测，常常不得不回滚或遇到不可预见的问题。
• 发布之后凌晨两点还睡眼惺忪地坐在显示器前，绞尽脑汁想让刚刚部署的应用程序正常工作。
• 相反，随着时间的推移，部署应该走向完全自动化。即对于那些负责将应用程序部署到开发环境、测试环境或生产环境的人来说，应该只需要做两件事：（1）挑选版本及需要部署的环境，（2）按一下“部署”按钮。对于套装软件的发布来说，还应该有一个创建安装程序的自动化过程。

我们将在本书中讨论很多自动化问题。当然，并不是所有的人都能接受这个想法。那么，我们先来解释一下，我们为什么把自动化部署看作是一个必不可少的目标。

• 如果部署过程没有完全自动化，每次部署时都会发生错误。唯一的问题就是“该问题严重与否”而已。即使通过了良好的部署测试，有些错误也很难追查。
• 如果部署过程不是自动化的，那么它就是不可重复的或不可靠的，就会在调试部署错误的过程中浪费很多时间。
• 手动部署进程不得不记录在案。文档维护是一个复杂而费时的任务。它涉及多人之间的协作，因此该文档基本上要么是不完整的，要么是未及时更新的。而把一个自动化部署脚本作为文档，它就永远是最新的和完整的，否则就无法进行部署工作了。
• 自动部署本质上也是鼓励协作的，因为所有的内容都在这个脚本里，一览无遗。而文档是建立在一种假设的基础之上的，即读者的知识水平与作者的水平相当。可事实上，这个文档通常只是执行部署者所写的备忘录，他人并不清楚当时写作的上下文。

根据以上几点，我们可以得到这样的结论：手工部署过程需要部署专家。如果专家去度假或离职了，那你就有麻烦了。

• 尽管手工部署是枯燥且重复性的劳动，但仍需要有相当程度的专业知识。一方面，专家要做这些无聊且重复性的工作，而另一方面，技术要求高的任务仍需要他们来完成。结果，我们只有通过“剥夺睡眠”这样的方式来解决时间不足等问题啦。而自动化部署可以解放那些昂贵的高技能人员，让他们投身于更高价值的工作活动当中。
• 对手工部署过程本身进行测试的唯一方法就是原封不动地做一次（或者几次）。这往往费时又昂贵。而自动化的部署过程却是既便宜又容易测试。
• 另外，还有一种说法：“自动化过程不如手工过程的可审计性好”。我们不同意这个观点。对于一个手工过程来说，没人能确保其执行者会非常严格地遵照文档中所记述的内容。只有自动化过程是完全可审核的。有什么东西会比一个可工作的部署脚本更能够被审核的呢？每个人都应该使用自动化部署过程，而且它应该是软件部署的唯一方式。这个纪律可以确保：在需要部署时，部署脚本一定会很好地完成工作。在本书中我们会提到多个原则，而其中之一就是“使用相同的脚本将软件部署到各种环境”。如果您使用相同的脚本将软件部署到各类环境中，那么在发布当天需要向生产环境进行部署时，这个脚本已经被验证过成百上千次了。如果此时出现任何问题的话，你可以百分百地确定是该环境的具体配置问题，而不是这个脚本的问题。

当然，手工密集操作的发布工作有时也会非常顺利。但不幸的是，我们经常看到的却是糟糕的情况。假如在整个软件生产过程中它不算是一个易出错的步骤，那为什么还总是出错呢？为什么需要这些流程和文档呢？为什么团队在周末还要加班呢？为什么还要求大家原地待命，以防意外发生呢？

反模式：只有在开发完成之后，才能向类生产环境上部署

当软件开发完成后第一次被部署到类生产环境（比如试运行环境）时，开发团队认为“该软件开发完成了”。

这种模式中，经常看到下面这些情况：

• 测试人员部署之前就已参与开发流程，但只在开发环境中对软件应用进行了测试。
• 只有在向试运行环境部署时，运维人员才第一次接触到这个应用程序。在某些组织中，通常是由独立的运维团队负责将应用程序部署到试运行环境和生产环境。在这种工作方式下，运维人员只有在产品发布到生产环境时才第一次见到这个软件。
• 有可能由于类生产环境非常昂贵，权限控制严格，操作人员自己无权对该环境进行操作，也有可能环境没有按时准备好，甚至根本没人去准备环境。
• 开发团队将正确的安装程序、配置文件、数据库迁移脚本和部署文档一同交给那些真正执行部署任务的人员——而所有这些产物都没有在生产环境或试运行环境中进行过测试。
• 开发团队和真正执行部署任务的人员之间的协作非常少。

当需要将软件部署到试运行环境时，只是临时地组成一个团队来完成这项任务。有时候这个团队可能是一个全功能团队，然而在一个大型组织中，这种部署责任通常落在多个分立的团队肩上。DBA、中间件团队、Web团队，以及其他团队都会染指应用程序最后版本的部署工作。因为部署工作中的很多步骤根本没有在试运行环境上测试过，所以常常遇到问题。文档中也漏掉了一些重要的步骤。这些文档都基于一个基本假设，即软件版本或目标环境的配置都是正确的。然则情况常常恰恰相反，而引起部署失败。部署团队不得不猜测开发团队到底是怎么做的。

这种因缺乏合作而导致部署问题的情况最终会通过临时打电话、发邮件给开发人员，让他们做一些快速修复来解决。一个严格自律的团队会将所有可能性写到部署计划中，但却很少真正让这个过程变得更有效。随着部署压力的增大，为了能够在规定的时间内完成部署，开发团队与部署团队之间这种严格定义的协作过程被证明是失败的。

在执行部署过程中，我们常常发现在我们的系统设计中，存在对生产环境的假设，而这些假设很多是不正确。例如，当部署的某个应用软件是用文件系统做数据缓存的。这在开发环境是没有什么问题的，但在集群环境中可能就不行了。解决这类问题要花很长时间，而且在问题解决之前，应用程序是无法部署的。

一旦应用程序部署到试运行环境之后，我们常常会发现新的缺陷。不幸的是，我们常常没有时间去修复它们，因为最后期限马上就到了。项目进行到这个阶段时，推迟发布日期常常是无法被接受的。所以，大多数严重缺陷被勿忙修复。为了安全起见，项目经理会保存一份已知缺陷列表，可当下一个Release开始时，这些缺陷的优先级还是常常被排得很低。

有的时候，情况会比这还糟。 以下这些事情会使问题恶化。

• 当一个应用程序是全新开发的，当第一次将它部署到试运行环境时，可能会比较棘手。
• 发布周期越长，开发团队在错误的假设下开发的时间就越长，修复这些问题的时间就越长。
• 在那些划分有开发、DBA、运维、测试等部门的大型组织中，这些独立部门之间的协作成本可能会非常高，有时甚至会将发布过程拖上地狱列车。此时为了完成某个部署过程，开发人员、测试人员和运维人员之间总是是高举着问题单（不断地互发EMail）。更糟糕的是，这些Email都是为了解决部署过程中发现的问题。
• 开发环境与生产环境差异性越大，开发过程中所做的那些假设与现实差距就越大。虽然很难度量，但我敢说，如果你在Windows系统上开发软件，却最终需要部署到Solaris集群上，那么你会遇到很多意想不到的事情。
• 如果你的应用程序是由客户自行安装的（你可能没有权限操作客户的环境），或者其中的某些组件不在企业控制范围之内。此时可能需要很多额外的测试工作。

那么，良药就是将测试、部署和发布活动也纳入到开发过程中，让它们成为正常开发流程的一部分。
当需要进行系统发布时就不会有什么风险了，因为你已经在很多种环境，甚至类生产环境中已经做过很多次，相当于测试过很多次了。而且要确保每个人都成为这个软件交付流程的一份子，无论是构建发布团队、还是开发测试人员，都应该从项目开始就在一起工作。

我们是测试的狂热者，并将持续集成和持续部署的使用范围扩大了，即不但要对应用程序进行测试，还要对部署过程进行测试，这正是我们所推荐的方法的基石。

反模式：生产环境的手工配置管理

很多组织通过专门的运维团队来管理生产环境的配置。如果需要修改一些东西，比如修改数据库的连接配置或者增加应用服务器线程池的线程数，就由这个团队登录到服务器上手工修改一下。如果每次都将这样的修改记录下来，那么这就相当于变更管理数据库的一条记录。

这种反模式的特征是：

• 多次部署到试运行环境都非常成功，但当部署到生产环境时就失败。
• 集群中各节点的行为有所不同。例如，与其它节点相比，某个节点所承担的负载少一些，或者处理请求的时间花得多一些。
• 运维团队需要较长时间为每次发布来准备环境。
• 系统无法回滚到之前部署的某个配置上，这些配置包括操作系统、应用服务器、关系数据库、Web服务器或其它基础设施。
• 不知道从什么时候起，集群中的某些服务器所依赖的操作系统和第三方库的版本就不同了，或者更新了错误的补丁。
• 直接修改生产环境上的信息来改变配置。

相反，应该让测试环境、试运行环境和生产环境的所有方面，尤其是系统中的第三方软件配置，通过一个自动化的过程从版本控制系统中取出并应用到该环境中。

本书描述的关键实践之一就是：配置管理，其责任之一就是让你能够可重复地创建那些你所开发的应用程序所依赖的基础设施。这意味着操作系统及其补丁、操作系统配置、你的应用程序所依赖的其它软件及其配置、基础设施的配置等等都应该处于受控状态。你应该具有重建生产环境的能力，最好是能通过自动化的方式重建生产环境。虚拟化技术在这一点上可能对你有所帮助。

你应该完全掌握关于生产环境中的任何信息。这意味着生产环境中的每次变更都应该被记录下来，而且做到今后可以查阅。部署失败经常是因为某个人在上次部署时为生产环境打了补丁，但却没有将这个修改记录下来。实际上，应该不允许手工改变测试环境、试运行环境和生产环境。只能通过自动化过程来改变这些环境。

应用软件之间通常会有一些依赖关系。 我们应该很容易知道该软件当前发布的是哪个版本。如果是该软件是由多个组件构成，就应该知道每个组件的版本。发布可能是一件令人兴奋的事儿，也可能变成一件累人而又沉闷的工作。几乎在每次发布的最后都会有一些变更，比如修改了数据库的登录帐户或者更新了所用外部服务的URL。我们应该使用某种方法来引入此类变更，以便这些变更可以被记录并测试。这里我们再次强调一下，自动化是关键。变更首先应该被提交到版本控制系统中，

然后通过某个自动化过程对生产环境进行更新，我们也应该有能力在部署出错时，通过一个自动化过程将系统回滚到之前的版本上。

我们能做得更好吗？

当然可以，本书就是来讲如何做好这件事的。我们所说的这些原则、实践和技术的目标都是即使是在一个非常复杂的企业环境中，也能将软件发布工作变成一个没有任何突发事件的索然无味的事情。软件发布可以也应该成为一个低风险、较频繁、廉价、迅速且可预见的过程。这些实践在过去的几年中已经被使用，并且我们发现它们让很多项目变得非比寻常。本书所提到的所有实践都已经在大型企业项目、分布式的团队中测试过，小团队就更不用说了。我们确信它们是有效的，而且可以应用在大项目中。
 

曾经有个客户，他们在过去每次发布时都会组建一个较大的专职团队。大家在一起工作七天（包括周末的两天）才能把应用程序部署到生产环境中。他们的发布成功率很低，要么是发现了错误，要么是在发布当天需要高层来协调。常常要在接下来的几天里修复在发布过程中发现的新问题或者是由于配置时手工误操作导致的问题。

我们帮助客户实现了一个完善的自动构建、部署、测试和发布系统。为了让这个系统能够良好运行下去，我们还引入了一些必要的开发实践和技术。我们离开之前的一次发布只花了七秒钟就将应用程序部署到了生产环境中。根本没有人意识到发生了什么，只是感觉突然间多了一些新功能。假如部署失败了，无论是什么原因，我们都可以在同样短的时间里回滚。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tony1130/archive/2010/11/08/5996420.aspx

标签: scm, 持续集成, 持续交付, ci

作者 Michael Prokop 译者 张永利

概要 - 为什么需要监控文件系统？

在日常工作中，人们往往需要知道在某些文件(夹)上都有那些变化，比如：

• 通知配置文件的改变
• 跟踪某些关键的系统文件的变化
• 监控某个分区磁盘的整体使用情况
• 系统崩溃时进行自动清理
• 自动触发备份进程
• 向服务器上传文件结束时发出通知

通常使用文件轮询的通知机制，但是这种机制只适用于经常改变的文件(因为它可以确保每过x秒就可以得到i/o)，其他情况下都非常低效，并且有时候会丢失某些类型的变化，例如文件的修改时间没有改变。像Tripwire这样的数据完整性系统，它们基于时间调度来跟踪文件变化，但是如果想实时监控文件的变化的话，那么时间调度就束手无策了。Inotify就这样应运而生了。本文将简要介绍inotify，告诉我们如何监控文件夹，如何一有变化就报告相关消息事件，并介绍了一些相关工具， 我们可以把它们添加到自己的工具箱中。

Inotify到底是什么？

Inotify是一种文件变化通知机制，Linux内核从2.6.13开始引入。在BSD和Mac OS系统中比较有名的是kqueue，它可以高效地实时跟踪Linux文件系统的变化。近些年来，以fsnotify作为后端，几乎所有的主流Linux发行版都支持Inotify机制。如何知道你的Linux内核是否支持Inotify机制呢？很简单，执行下面这条命令：

% grep INOTIFY_USER /boot/config-$(uname -r)
CONFIG_INOTIFY_USER=y

如果输出('CONFIG_INOTIFY_USER=y')，那么你可以马上享受Inotify之旅了。

简单的文件变化通知样例：

好的开始是成功的一半，对于了解Inotify机制来说，让我们从使用inotifywait程序开始，它包含在inotify-tools工具包中。假如我们打算监控/srv/test文件夹上的操作，只需执行：

% inotifywait -rme modify,attrib,move,close_write,create,delete,delete_self /srv/test
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.

上述任务运行的同时，我们在另一个shell里依次执行以下操作：创建文件夹，然后在新文件夹下创建文件，接着删除新创建的文件：

% mkdir /srv/test/infoq
% echo TODO > /srv/test/infoq/article.txt
% rm /srv/test/infoq/article.txt

在运行inotifywait的shell中将会打印以下信息：

/srv/test/ CREATE,ISDIR infoq
/srv/test/infoq/ CREATE article.txt
/srv/test/infoq/ MODIFY article.txt
/srv/test/infoq/ CLOSE_WRITE,CLOSE article.txt
/srv/test/infoq/ DELETE article.txt

显而易见，只要有变化我们就会收到相关的通知。如果想了解关于Inotify提供的事件(如modify, atrrib等)的详细信息，请参考inotifywatch的manpage。实际使用时，如果并不想监控某个大文件夹，那么就可以使用inotifywait的exclude选项。例如：我们要忽略文件夹/srv/test/large，那么就可以这样来建立监控:

% inotifywait --exclude '^/srv/test/(large|ignore)/' -rme modify,attrib,move,close_write,create,delete,delete_self /srv/test
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.

上面的例子中，在exclude选项的匹配串中我们使用了正则表达式，因为我们不想将名称中含有large或ignore的文件也排除掉。我们可以测试一下：

% echo test > /srv/test/action.txt
% echo test > /srv/test/large/no_action.txt
% echo test > /srv/test/ignore/no_action.txt
% echo test > /srv/test/large-name-but-action.txt

这里inotifywait应该只会报告'action.txt'和'large-name-but-action.txt'两个文件的变化，而忽略子文件夹'large'和'ignore'下的文件，结果也确实如此；

/srv/test/ CREATE action.txt
/srv/test/ MODIFY action.txt
/srv/test/ CLOSE_WRITE,CLOSE action.txt
/srv/test/ CREATE large-name-but-action.txt
/srv/test/ MODIFY large-name-but-action.txt
/srv/test/ CLOSE_WRITE,CLOSE large-name-but-action.txt

另外，通过使用-t选项我们还可以定义inotifywait的监控时间，既可以让它执行一段时间，也可以让它一直运行。util-linux-ng的logger命令也可以实现此功能，不过得先把相关的消息事件发送到syslog，然后从syslog服务器再分析整合。

Inotifywatch - 使用inotify来统计文件系统访问信息

Inotify-tools中还有一个工具叫inotifywatch，它会先监听文件系统的消息事件，然后统计每个被监听文件或文件夹的消息事件，之后输出统计信息。比如我们想知道某个文件夹上有那些操作：

% inotifywatch -v -e access -e modify -t 120 -r ~/InfoQ
Establishing watches...
Setting up watch(es) on /home/mika/InfoQ
OK, /home/mika/InfoQ is now being watched.
Total of 58 watches.
Finished establishing watches, now collecting statistics.
Will listen for events for 120 seconds.
total  modify  filename
2      2       /home/mika/InfoQ/inotify/

很显然，这里我们监控的是~/InfoQ文件夹，并且可以看到/home/mika/InfoQ/inotify上发生了两个事件。方法虽简单，但却很有效。

Inotify的配置选项

使用Inotify时，要特别注意内核中关于它的两个配置。首先/proc/sys/fs/inotify/max_user_instances 规定了每个用户所能创建的Inotify实例的上限；其次/proc/sys/fs/inotify/max_user_watches规定了每个Inotify实例最多能关联几个监控(watch)。你可以很容易地试验在运行过程中达到上限，如：

% inotifywait -r /
Setting up watches.  Beware: since -r was given, this may take a while!
Failed to watch /; upper limit on inotify watches reached!
Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'.

如果要改变这些配置，只要向相应的文件写入新值即可，如下所示：

# cat /proc/sys/fs/inotify/max_user_watches
8192
# echo 16000 > /proc/sys/fs/inotify/max_user_watches
# cat /proc/sys/fs/inotify/max_user_watches
16000

使用Inotify的一些工具

近一段时间出现了很多基于Inotify的超炫的工具，如incron， 它是一个类似于cron的守护进程(daemon)，传统的cron守护进程都是在规定的某个时间段内执行，而incron由于使用了Inotify，可 以由事件触发执行。同时incron的安装简单而直观，比如在debian上，首先在/etc/incron.allow中添加使用incron的用户 (debian默认不允许用户使用incron，因为如果incron使用不慎的话，例如形成死循环，则会导致系统宕机)： 

# echo username > /etc/incron.allow

然后调用”incrontab -e“, 在弹出的编辑器中插入我们自己的规则，例如下面的这条简单的规则，文件一变化incron就会发邮件通知我们：

/srv/test/ IN_CLOSE_WRITE mail -s "$@/$#\n" root

从现在开始，一旦/src/test文件夹中的文件被修改，就会发送一封邮件。但是注意不要让incron监控整个子目录树，因为Inotify只关注inodes，而不在乎是文件还是文件夹，所以基于Inotify的软件都需要自己来处理/预防递归问题。关于incontab详细使用，请参考incrontab的manpage。

如果你还要处理incoming文件夹，那么你可能需要inoticoming。 当有文件进入incoming文件夹时Inoticoming就会执行某些动作，从而可以用inoticoming来管理debian的软件仓库(例如软 件仓库中一旦有上传源码包或是新添加的二进制包就立刻自动进行编译)，另外，还可以用它来监控系统是否有新上传文件，如果有就发送通知。类似的工具还有 (它们都各有专长)：inosync(基于消息通知机制的文件夹同步服务)，iwatch(基于Inotify的程序，对文件系统进行实时监控)，以及lsyncd(一个守护进程(daemon)，使用rsync同步本地文件夹)。

Inotify甚至对传统的Unix工具也进行了改进，例如tail。使用inotail，同时加上-f选项，就可以取代每秒轮询文件的做法。此外，GNU 的coreutils从版本7.5开始也支持Inotify了，我们可以运行下面的命令来确认：

# strace -e inotify_init,inotify_add_watch tail -f ~log/syslog
[...]
inotify_init()                          = 4
inotify_add_watch(4, "/var/log/syslog", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1

从现在开始，通过轮询来确实文件是否需要重新读取的方法应该作为古董了。

在脚本中使用Inotify

Inotify机制并不局限于工具，在脚本语言中也完全可以享受Inotify的乐趣，如Python中可以使用pyinotify和inotifyx，Perl中有Filesys-Notify-Simple和Linux-Inotify2，Inotify的Ruby版有ruby-inotifyrb-inoty和fssm。

总结

综上所述，Inotify为Linux提供了一套高效监控和跟踪文件变化的机制，它可以实时地处理、调试以及监控文件变化，而轮询是一种延迟机制。 对于系统管理员，关于实现事件驱动的服务如系统备份，构建服务以及基于文件操作的程序调试等，Inotify无疑提供了强大的支持。