cpu 烧毁
Yesterday, Amazon’s S3 cloud storage service went down for the second time this year, bringing a swathe of web 2.0 sites down with it. Sites and apps like SmugMug, Twhirl, Twitter, SlideShare, and even SitePoint were all affected by the downtime. As WebWorkerDaily notes, Amazon’s SLA guarantees 99.9% uptime — or about no more than 45 minutes downtime per month. So it’s a safe bet that Amazon will owe a bunch of sites refunds for this most recent hours-long outage.
昨天，亚马逊的S3云存储服务今年第二次关闭 ，使大量的Web 2.0网站随之关闭。 SmugMug，Twhirl，Twitter，SlideShare 甚至SitePoint等网站和应用程序都受到停机时间的影响。 正如WebWorkerDaily所指出的那样 ，亚马逊的SLA保证了99.9％的正常运行时间-每月大约不超过45分钟的停机时间。 因此，可以肯定的是，由于最近几个小时的停机，亚马逊将欠很多网站退款。
For many users of Amazon’s or other cloud storage services, however, downtime is unacceptable and can cost the business more than just the price of that missed hosting. Travel guide startup Planaroo, which was also negatively affected by the S3 outage, penned a post on their company blog today outlining what they learned from the issues with Amazon. Here are their takeaways:
但是，对于许多使用Amazon或其他云存储服务的用户来说，宕机是不可接受的，不仅给企业造成的损失，还给企业造成了更大的损失。 受到S3中断的负面影响的旅游指南初创公司Planaroo今天在其公司博客上发表了一篇文章，概述了他们从亚马逊问题中学到的东西 。 这是他们的外卖：
Backups are a good thing. Having a Plan B is a necessity. Spend the extra dough to have backups of your mission critical files. Planaroo had backups of all the photos they host on S3, so when Amazon’s service went down, they could easily switch to the backups by just replacing a URL in their photo database.
备份是一件好事。 制定计划B是必要的。 花额外的钱来备份关键任务文件。 Planaroo拥有他们在S3上托管的所有照片的备份，因此当Amazon的服务出现故障时，只需替换其照片数据库中的URL，他们就可以轻松切换到备份。
Fix it. Don’t hope for the best. One thing Planaroo did wrong, however, was assume Amazon would right the ship quickly. It was 2 hours before they decided to give up waiting on Amazon and switch to their backups. Lesson: when things start going wrong, don’t assume your host will have them fixed quickly. Your contingency plan is there for a reason, so use it.
修理它。 不要期望最好的。 但是，Planaroo做错的一件事是假设亚马逊会Swift纠正这艘船。 他们决定放弃在亚马逊上等待并切换到备份的时间只有两个小时。 教训：当事情开始出错时，不要以为您的主机会很快修复它们。 您的应急计划之所以存在是有原因的，请使用它。
Keep backups up-to-date and ready-to-go. When your main host goes down and you need to switch on the backup, make sure it is up-to-date. If you have to waste time uploading files to your backup server, well, then you’re just wasting time.
使备份保持最新状态并随时可用。 当主主机出现故障并需要打开备份时，请确保它是最新的。 如果您不得不浪费时间将文件上传到备份服务器，那您就是在浪费时间。
Other services could go down too. It’s not just your host. In the world of APIs and hosted libraries, many startups depend on multiple third-party services to keep things running. Planaroo, for example, uses Google’s AJAX Libraries. Google could have a similar problem as Amazon (Google’s App Engine had some extended downtime a month ago, in fact), so it pays to have a contingency plan for every service you rely on.
其他服务也可能下降。 不只是您的主人。 在API和托管库的世界中，许多创业公司都依赖多个第三方服务来保持运行。 例如，Planaroo使用Google的AJAX库 。 Google可能会遇到与Amazon类似的问题(实际上，Google的App Engine一个月前就有较长的停机时间 )，因此为您依赖的每项服务制定应急计划是有必要的。
That last point highlights something important about this list: It doesn’t just apply to S3 or cloud storage services. These are good lessons that can be applied to ANY hosting environment.
最后一点强调了此列表中的一些重要内容：它不仅适用于S3或云存储服务。 这些都是可以应用于任何托管环境的好课程。
For the full list of lessons that Planaroo laid out, check out their blog post.
有关Planaroo安排的所有课程的完整列表，请查看其博客文章 。
翻译自: https://www.sitepoint.com/dont-get-burned-when-the-cloud-goes-down/
cpu 烧毁
相关资源：jdk-8u281-windows-x64.exe