尽管Twitter的运营团队通过后台的流量图看到了即将到来的奥运会热潮对各项指标的拉升—这种可预期的、能带来大流量的事件，Twitter一般都会提前做准备，然而意外还是发生了。
在Twitter的预案里，如果这里发生了洪水、地震或者其他任何有可能导致服务器停止工作的问题，距离萨克拉门托965公里的另一个数据中心就会开始工作，它位于托管服务商Raging Wire旗下的一处建筑内，当然，情况也可能相反：Raging Wire这边出了问题，萨克拉门托开始工作。
无论哪一种情况，Twitter希望保证的是用户的不间断使用体验，即便是远在大洋彼岸的用户，也可以正常地把自己的消息Tweet出去，而不会感受到服务中断。
对于互联网公司而言，在线就是生命。Facebook早期迅速积累用户并不是由于它来自哈佛大学的好名声，而是它几乎从不宕机。这与当时强劲的竞争对手MySpace形成了鲜明对 照。
但在7月26日这一天，Twitter两个数据中心同时发生故障，全球用户的Twitter服务中止。Twitter提供的解释是由于“基础设施元件中的级联式漏洞”，但没有公布更详细的信息。在Twitter的成长史上几乎每年都会有多次重大宕机事故，宕机时网站就会显示出一幅有趣的：几只小鸟用线艰难地拉起一头搁浅的鲸鱼。
这是Twitter在两个月之内的第二次重大宕机故障。此前一次是6月21日，Twitter停止服务将近两个多小时。
Twitter负责工程技术的副总裁拉瓦德（Mazen Rawashdeh）事后解释说，Twitter在数据中心有两套能互相备份的数据系统同时出现了故障，这是基础设施上的“巧合事件”。通常情况下，如果一个系统出现故障，那么另一个将被紧急启用。而两套系统同时出现问题则比较少见，为避免类似故障重演，Twitter称计划对基础设施大幅投资。
数据中心问题一直困扰着Twitter。截至3月，Twitter已有14亿活跃用户，每天会发出34亿条Tweet。随着用户量和信息读写量的增长，Twitter迫切需要一个能自我完全掌控的数据中心。
Twitter早期租用第三方的数据服务，之后计划转向租用位于犹他州盐湖城的定制化数据中心，然而在去年该数据中心却出现了漏雨、电力不足等问题，于是Twitter不得不改变其计划，另谋他处。
在同一天，悲催的不仅仅是Twitter。谷歌的即时通讯服务Gtalk也在早上6点40分发生故障，并迟迟没有被修复。有用户报告，微软旗下面对企业客户的云服务工具Windows Azure在西欧地区也发生了宕机问题。
在宕机这段时间内，Gtalk用户发现虽然能够登录，但无法像以往一样正常发送信息以及进行语音、视频聊天。他们持续接到谷歌通过网页更新的问题修复状态通知，时间单位大约为半小时，而这一状态持续了近5个小时，算是谷歌史上罕见的长时间故障。习惯线上沟通的用户们不得不转向其他工具，有人说，接连两起宕机事件让他们有一种“全球停电”的感觉。
谷歌的数据中心分布全球且多达20多个，目前无法得知是哪一块数据中心发生了故障以致Gtalk瘫痪，谷歌至今也未解释具体原 因。
世界正在变成一个由数据洪流组成的存在，而整个世界也因几个重要信息节点而相互连接在一起。但即使是像谷歌这样著名的互联网公司也无法保证自己所有的服务全年都不出问题。
据谷歌称，其最受欢迎的服务Gmail电子邮件服务2010年全年宕机时间为7分钟，这已经是业内最短时间。根据Radicati Group的数据，电子邮件系统平均宕机时间为每月38小时。对比起来，Gmail可谓优秀。
一般造成系统不稳定甚至宕机的原因是多样的，开发安卓手机管理工具豌豆荚的豌豆实验室技术总监高磊对《第一财经周刊》介绍，在用户使用网站服务时，从用户输入信息，网络传送信息给网站服务器，网站服务器按照程序对用户要求进行处理，将结果返还用户，整个过程中其中一个环节出现问题就会导致网站的服务受到影响，甚至发生宕机而不可用。
引发问题的潜在因素多种多样，包括网站自身程序、服务器的 *** 作系统、硬件设备、机房与网络运营商等基础设施。
如果网站自身程序有Bug，可能会导致使用变慢，或部分功能失效；服务器的 *** 作系统也会出现漏洞，比如装有Linux部分版本的服务器就在本月因为闰秒问题而宕机；服务器硬件本身损坏，比如硬盘或内存都存在一定物理故障的机率。
而在基础设施上，机房停电或进水、遭到雷击等也会造成设备停止运行。最基础的问题是过热，因此大型数据中心旁边一般都有冷却装置。
6月底，美国一场风暴袭击了弗吉尼亚北部，大面积电力供应中断。而恰巧亚马逊在这里安置了US-East-1数据中心，因为停电，整个数据中心瘫痪。
亚马逊是业界领先的云服务提供商，其提供给网站以数据服务的云服务Amazon Web Services也因此一度中断服务。之后连锁反应便产生，使用其服务的Instagram、Pinterest、Quora、Netflix等知名网站也停止了服务，进而影响到各自的生态系统。
为避免风险，一些网络公司选择不把鸡蛋放在一个篮子里，设置多个数据中心，或者在使用云服务时同时选择多家供应商，当然，这也会增加成本。
据新浪微博技术总监杨卫华对《第一财经周刊》介绍，是否能稳定登录，响应的速度怎样，都会对用户的体验造成直接影响。新浪微博采用了分布式的架构，这意味着它没有把所有的服务器都放在新浪所在的北京，而是在国内多个主要城市都设置了数据中心，在突发事件发生后的流量处理和响应速度等各方面来保证用户体验。
你在宕机时体验到多少焦虑，稳定对于互联网公司就有多重要。
当越来越多的人被接入同一个网络─比如被称为“世界的脉搏”的Twitter，数据中心瘫痪的风险等级也相应增加。这些数据就存储在像加州萨克拉门托的大房子里，一旦宕机，空白也从这里开始。我会说是为了一张翻译的文章么。。。
原文地址： >断网类型一：系统故障
典型事件1：亚马逊AWS平安夜断网
故障原因：d性负载均衡服务故障
2012年12月24日，刚刚过去的圣诞节平安夜，亚马逊并没有让他们的客户过得太平安。亚马逊AWS位于美国东部1区的数据中心发生故障，其d性负载均衡服务(Elastic Load Balancing Service)中断，导致Netflix和Heroku等网站受到影响。其中，Heroku在之前的AWS美国东部区域服务故障中也受到过影响。不过，有些巧合的事情是Netflix的竞争对手，亚马逊自己的业务Amazon Prime Instant Video并未因为这个故障而受到影响。
12月24日，亚马逊AWS中断服务事件不是第一次，当然也绝非最后一次。
2012年10月22日，亚马逊位于北维吉尼亚的网络服务AWS也中断过一次。其原因与上次相似。事故影响了包括Reddit、Pinterest等知名大网站。中断影响了d性魔豆服务，其后是d性魔豆服务的控制台，关系数据库服务，d性缓存，d性计算云EC2，以及云搜索。这次事故让很多人认为，亚马逊是应该升级其北维尼吉亚数据中心的基础设施了。
2011年4月22日，亚马逊云数据中心服务器大面积宕机，这一事件被认为是亚马逊史上最为严重的云计算安全事件。由于亚马逊在北弗吉尼亚州的云计算中心宕机，包括回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。亚马逊官方报告中声称，此次事件是由于其EC2系统设计存在漏洞和设计缺陷，并且在不断修复这些已知的漏洞和缺陷来提高EC2(亚马逊ElasticComputeCloud服务)的竞争力。
2010年1月，几乎6万8千名的Salesforcecom用户经历了至少1个小时的宕机。Salesforcecom由于自身数据中心的"系统性错误"，包括备份在内的全部服务发生了短暂瘫痪的情况。这也露出了Salesforcecom不愿公开的锁定策略：旗下的PaaS平台、Forcecom不能在Salesforcecom之外使用。所以一旦Salesforcecom出现问题，Forcecom同样会出现问题。所以服务发生较长时间中断，问题将变得很棘手。
断网诱因二：自然灾害
典型事件1：亚马逊北爱尔兰柏林数据中心宕机
故障原因：闪电击中柏林数据中心的变压器
2011年8月6日，在北爱尔兰都柏林出现的闪电引起亚马逊和微软在欧洲的云计算网络因为数据中心停电而出现大规模宕机。闪电击中都柏林数据中心附近的变压器，导致其爆炸。爆炸引发火灾，使所有公用服务机构的工作暂时陷入中断，导致整个数据中心出现宕机。
这个数据中心是亚马逊在欧洲唯一的数据存储地，也就是说，EC2云计算平台客户在事故期间没有其他数据中心可供临时使用。宕机事件使得采用亚马逊EC2云服务平台的多家网站长中断达两天时间之久。
典型事件2：卡尔加里数据中心火灾事故
故障原因：数据中心发生火灾
2012年7月11日卡尔加里数据中心火灾事故：加拿大通信服务供应商ShawCommunicationsInc位于卡尔加里阿尔伯塔的数据中心发生了一场火灾，造成当地医院的数百个手术延迟。由于该数据中心提供管理应急服务，此次火灾事件影响了支持关键公共服务主要的备份系统。此次事件为一系列政府机构敲响了警钟，必须确保及时的恢复和拥有故障转移系统，同时结合出台灾害管理计划。
典型事件3：超级飓风桑迪袭击数据中心
故障原因：风暴和洪水导致数据中心停止运行
2012年10月29日，超级飓风桑迪：纽约和新泽西州的数据中心都受到了此次飓风的影响，所带来的恶劣影响包括为曼哈顿下城地区的洪水和一些设施的停机，周围地区数据中心发电机运行失常。飓风桑迪所带来的影响超出了一般单一的中断事故，为受灾地区数据中心产业带来了规模空前的灾难。事实上，柴油已然成为了数据中心恢复工作的生命线，作为备用电源系统接管了整个地区的负荷，促使特别措施，保持发电机的燃料。随着眼前的工作重点逐步转移到灾后重建，我们有必要长期就数据中心的选址、工程和灾难恢复进行探讨，这一话题可能将持续几个月，甚至几年。
断网诱因三：人为因素
典型事件1：Hostingcom服务中断事故
故障原因：服务供应商执行断路器 *** 作顺序不正确造成的UPS关闭
2012年7月28日Hostingcom停运事件：人为错误通常被认为是数据中心停机的主导因素之一。7月Hostingcom中断事件造成 1100名客户服务中断就是一个例子。停机事故的发生是由于该公司位于特拉华州纽瓦克的数据中心正进行UPS系统预防性维护，"服务供应商执行断路器 *** 作顺序不正确造成的UPS关闭是造成数据中心套房内的设施损失的关键因素之一。"Hostingcom首席执行官ArtZeile说。"没有任何重要的电力系统或备用电源系统出现故障，完全是一种人为的错误造成的。"
典型事件2：微软爆发BPOS服务中断事件
故障原因：微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的
2010年9月，微软在美国西部几周时间内出现至少三次托管服务中断事件向用户致歉。这是微软首次爆出重大的云计算事件。
事故当时，用户访问BPOS(Business Productivity Online Suite)服务的时候，如果使用微软北美设施访问服务的客户可能遇到了问题，这个故障持续了两个小时。虽然，后来微软工程师声称解决了这一问题，但是没有解决根本问题，因而又产生了9月3日和9月7日服务再次中断。
微软的Clint Patterson说，这次数据突破事件是由于微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的。BPOS软件中的离线地址簿在"非常特别的情况下"提供给了非授权用户。这个地址簿包含企业的联络人信息。
微软称，这个错误在发现之后两个小时就修复了。微软称，它拥有跟踪设施，使它能够与那些错误地下载这些数据的人取得联系以便清除这些数据。
断网诱因四：系统故障
典型事件1：GoDaddy网站DNS服务器中断
故障原因：系统内一系列路由器的数据表造成的网络中断
2012年9月10日GoDaddy网站DNS服务器中断：域名巨头GoDaddy是一家最重要的DNS服务器供应商，其拥有500万个网站，管理超过5000万的域名。这就是为什么九月10日中断事故会是一个2012年最具破坏性的事件。
一些炒作甚至认为，此次长达6个小时的中断事件是由于拒绝服务攻击的结果，但GoDaddy后来表示，这是路由器表的损坏数据造成的。"服务中断不是由外部影响造成的。"GoDaddy的临时首席执行官史葛瓦格纳说。"这不是黑客攻击也不是一个拒绝服务攻击(DDoS)。我们已经确定了服务中断是由于内部的一系列路由器的数据表造成的网络事件损坏。"
典型事件2：盛大云存储断网
故障原因：数据中心一台物理服务器磁盘损坏
2012年8月6日晚上8：10，盛大云在其官方微博上发布一则因云主机故障致用户数据丢失事件的公开声明。声明说到：8月6日，盛大云在无锡的数据中心因为一台物理服务器磁盘发生损坏，导致"个别用户"数据的丢失。盛大云已经在尽全力协助用户恢复数据。
对于因为一台"物理服务器磁盘发生损坏"，导致"个别用户"数据的丢失的情况，盛大云技术人员给出自己的解释：虚拟机的磁盘有两种生产方式，一种是直接使用宿主机的物理磁盘。这种情况下，如果宿主机的物理磁盘发生故障，云主机不可避免会造成数据丢失，这也是本次事件产生的原因;另外一种是使用远程存储，也就是盛大硬盘产品，这种方式实际上是把用户的数据存到了远程的一个集群里，并同时做了多份备份，即使宿主机出故障也不会影响到云主机的数据。因为物理机的损坏很难避免，为了避免您遇到意外损失，我们建议您在云主机之外，也做好数据备份。
典型事件3：Google App Engine中断服务
故障原因：网络延迟
Google App Engine：GAE是用于开发和托管WEB应用程序的平台，数据中心由google管理，中断时间是10月26日，持续4小时，因为突然变得反应缓慢，而且出错。受此影响，50%的GAE请求均失败。
谷歌表示没有数据丢失，应用程序行为也有备份可以还原。为表歉意，google宣布11月份用户可以google表示他们正在加强其网络服务以应对网络延迟问题，"我们已经增强了流量路由能力，并调整了配置，这些将会有效防止此类问题再次发生"。
断网诱因五：系统Bug
典型事件1：Azure全球中断服务
事故原因：软件Bug导致闰年时间计算不正确
2012年2月28日，由于"闰年bug"导致微软Azure在全球范围内大面积服务中断，中断时间超过24小时。虽然微软表示该软件BUG是由于闰年时间计算不正确导致，但这一事件激起了许多用户的强烈反应，许多人要求微软为此做出更合理详细的解释。
典型事件2：Gmail电子邮箱爆发全球性故障
事故原因：数据中心例行性维护时，新程序代码的副作用
2009年2月24日，谷歌的Gmail电子邮箱爆发全球性故障，服务中断时间长达4小时。谷歌解释事故的原因：在位于欧洲的数据中心例行性维护之时，有些新的程序代码(会试图把地理相近的数据集中于所有人身上)有些副作用，导致欧洲另一个资料中心过载，于是连锁效应就扩及到其它数据中心接口，最终酿成全球性的断线，导致其他数据中心也无法正常工作。
典型事件3：“519断网事件”
事故原因：客户端软件Bug，上网终端频繁发起域名解析请求，引发DNS拥塞
2009年5月19日的21：50，江苏、安徽、广西、海南、甘肃、浙江等六省用户申告访问网站速度变慢或无法访问。经过工信部相关单位调查通报称，此次全国六省网络中断事故，原因是国内某公司推出的客户端软件存在缺陷，在该公司域名授权服务器工作异常的情况下，导致安装该软件的上网终端频繁发起域名解析请求，引发DNS拥塞，造成大量用户访问网站慢或网页打不开。
其中，DN SPod是国内知名的域名解析服务商之一的N SPod公司，服务数家知名网站的域名解析服务。此次攻击导致DN SPod公司所属的6台dns域名解析服务器瘫痪，直接造成包括暴风影音在内的多家网络服务商的域名解析系统瘫痪，由此引发网络拥塞，造成大量用户不能正常上网。 工信部指出，此次事件暴露出域名解析服务成为目前网络安全的薄弱环节，指示各单位要加强对域名解析服务的安全保护。
小结
启用云服务的公司，很大程度是考虑这种服务可以更加编辑，性价比高。但是，这样的考虑如果是以降低安全性作为代价，估计很多公司老大不会同意。层出不穷的云服务断网事件引起了云端安全性的担忧。
目前来看，解决的办法可以从几个角度出发，对于企业级客户来说，务必在采用云服务的同时定期备份云端的数据，拥有第二套解决方案按，以备不时之需。而对于云服务提供商来说，既然各种断网事件是在所难免的，那就必须思考一个对策，将自己用户的损失降到最低，对断网事件的响应效率要提高。
政府部门则具有监督和提醒的职责，云服务相关的法律法律要相继出台和不断完善，并且提醒用户百分之百可靠的云计算服务目前还不存在。
随着不断开放和用户数增长，Quora 将要面临的问题是怎样保证问答质量不下降，以及怎样扩展到IT领域之外更成建制的圈子。Quora 面临的问题也将是知乎面临的问题。从知乎公测来看，像 Quora 早期那样，知乎也引起了 IT 业内一些“大腕”和“意见领袖”的关注，据说腾讯的老大 Pony 也闻讯而来。这两类注册用户占了绝大多数。社区氛围很Geek 。
传统问答网站随着Web 20的浪潮掀起，依靠用户创造内容，但同时也产生了大量低质量甚至虚假的垃圾信息，从而使筛选和辨别信息成为使用者的负担。在社交网络普及了新一代的 News Feed 社区后，引入用户之间的关系来帮助发现、筛选问题和答案成为了新的思路。也在一定程度上能解决用户“看完就走”的实用主义倾向，增加粘性。
当然，Quora 和知乎不能像维基百科那样寄希望于海量用户对内容的自我修正。因为问题不是词条，理论上它会有无数个劣质的变体。Quora 和知乎也没采取严格的实名制比如身份z号认证那样的极端方法来限制用户的恶意，无法从根本上解决上面提到的问题。
因此，这将是一个长久的斗争，在机器尚未足够聪明之前，维护社区氛围和内容质量这些事情需要运营人员来解决。知乎需要走的路还很长，希望它能成功为自己找到答案。
总的来说，知乎面临的问题主要有以下四个方面：
有价值问题占比变小
很多注册完知乎的人，不肯自己探索而是一味的提问。
问答社区宗旨是解决一些较难解决的问题，倘若自己已经可以找到答案，却因为懒惰，不断的提出近乎幼稚的问题，那么这样的问答社区的问题质量无疑会慢慢下降。
早期知乎是由一堆精英人士解答问题，提出问题。现注册用户已经近一万，问题的规模变大，有意义的回答却变得越来越稀缺。很大的原因在于精英人士不再回答问题了。这也许是知乎前期工作的一个默许，早期由这些人回答，出现很多经典的问答，然后散布网络，吸引更多人索求邀请。知乎的营销策略的确是成功的。
知乎已经成为中文问答社区的后起明星，还附带着创新工厂投资的光环，于是前期的宣传变得不再必要。那些曾经制造无数经典问答的人于是归隐。所以能看到的问题和解答早已不如开始时那么让人印象深刻了。
知乎如果无法解决这个问题，留待它的只是沦为又一个百度知道，天涯问答罢了。
相似问题的泛滥
有一个比较经典的相似问题被提问了相当多次数：如何查看自己是知乎的第几号注册者。
这个问题在四个月前已经得到解答，并且归档不再增加新的答案。然而笔者依然时不时可以看到这个问题的重复泛滥。
就像提到的那样，知乎注册用户的质量在不断下降，而且懒惰的人越来越多——他们甚至不愿搜索一下这个问题是否得到解决。
知乎应该有能力解决这种问题。社交问答关键的并不是问题的量，而是质。
服务稳定性
最近几天知乎经常出现这句话：“服务器提了一个问题，我们正在紧张的撰写答案…”
这个报错提示很人性化，但是经常看到却让人感觉不甚舒服。稳定性是对所有网站的要求。频繁出现服务出错这种错误很容易降低用户的体验。
而另一个经常出现的是第一次进入知乎首页，会出现整个页面只有搜索框和按钮，底下都是白屏。需要点击其他地方，或者刷新一下才能变好。这个问题在chrome和火狐里常常看到。知乎上也有人提出了这个问题。但是笔者还没看到解决。
在日后知乎的注册用户规模达到十万百万后，服务的稳定性要求无疑会变得更高。希望知乎能够好好解决这个问题。
激励制度
在知乎上回答问题基本上都是凭借人类本能上喜欢帮助别人，顺便炫耀自己知识储备多丰富的天性。但是我们不可能要求大家天天都有这个心情。
知乎的激励制度需要完善，有些人提出的问题无人解答，这样更加挫伤用户的积极性。
这样的心理活动想必有不少知乎注册者都有。我们看到原来的互联网名人们提出的问题立刻得到一群人的回答，赞成，投票；而自己一名默默无闻的小咖提出的问题，即便充满回答的意义，但是一天两天无数天都无人问津，甚至连邀请别人回答的机会都没有……
一个好的激励制度可以不断唤起用户回答问题的欲望，然后自己的问题又得到很好的解答。这才是真正的良性循环。否则，知乎只会成为一个贵族名人们提问解答的社区。
关于激励制度的看法
在国内，太多的各种网站，太多的各种激励制度，感觉不到有多少的实际效果，最终的效果可能只是把原本平等的人，分成了三六九等，反而越到后面越难以激发新人的积极性，有了等级，有了各种规则，能够体现优越性，就会产生骄傲心理，反而不利于用户踊跃积极的发言。而依靠个人的影响力，个人的声誉，个人的人格魅力，在自己的圈子里，赢得一部分的尊重，就已经足够让人更加积极的去解答更多其他的问题，扩大自己的人格魅力，这不需要表面上的数字+V或者账号的等级来激励。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）