\u062f\u0631 \u0627\u06cc\u0646 \u0633\u0631\u06cc \u0645\u0642\u0627\u0644\u0627\u062a \u0628\u0647 \u0628\u0631\u0631\u0633\u06cc \u0627\u0645\u06a9\u0627\u0646 \u0631\u0633\u06cc\u062f\u0646 \u0628\u0647 \u0622\u067e\u062a\u0627\u06cc\u0645 100 \u062f\u0631\u0635\u062f \u0645\u06cc \u067e\u0631\u062f\u0627\u0632\u06cc\u0645 \u06a9\u0647 \u0627\u0632 \u0633\u0637\u062d \u0627\u06cc\u0646\u062a\u0631\u0646\u062a \u062c\u0645\u0639 \u0622\u0648\u0631\u06cc \u0634\u062f\u0647 \u0627\u0633\u062a .<\/p>\n

<\/p>\n

\u201cDo you guys have the most uptime in the industry?\u201d<\/em><\/p>\n

Questions about uptime are some of the most commonly asked when folks evaluate WP Engine\u2019s managed WordPress<\/a> hosting platform, or any hosting solution for that matter. Nobody wants downtime, and customers who are paying for a hosting solution have a right to ask and be informed about a company\u2019s history of downtime.<\/p>\n

In particular, people want to know who has the least uptime, or if there is a company that has achieved 100% uptime. The reality is that 100% uptime, while the goal that every company sets its sights on, is a perfection unattainable.<\/p>\n

In the past 10 days, four well-known WordPress<\/a> hosting providers all had similar amounts of downtime, all for different reasons, all with different datacenters<\/strong>. A rash of downtime across four major WordPress<\/a> hosting providers inside the same 2-week period is uncommon, but it indirectly helps answer the question, \u201cHow does your uptime stack up against [insert other hosting provider]?<\/em><\/p>\n

Here\u2019s what happened:<\/strong><\/p>\n

\n
• On February 12th, ServerBeach San Antonio physically cut a fiber line<\/a> between their datacenter in San Antonio and their Dallas POP. Physically severing this line caused a few hours of downtime for 1% of our customers, as well as brief downtime for millions of Automattic\u2019s WordPress.com<\/a> customers as they gracefully switched over to another datacenter.<\/li>\n
• On February 2nd, Page.ly experienced just under 2 hours of downtime because of a hardware failure<\/a> at Firehost\u2019s Dallas datacenter. The downtime affected all of Page.ly\u2019s customers in the Firehost datacenter.<\/li>\n
• On February 16th, Zippykid had several hours of downtime for hundreds of customers<\/a> because of human error between ZippyKid and Rackspace.<\/li>\n
• WordPress VIP had two bouts of downtime<\/a> in the past week, affecting and referenced by TechCrunch (see link)<\/strong>. The second bit of downtime was due to a code bug that was pushed into production (but swiftly remedied).<\/li>\n<\/ul>\n

  What can we learn from these situations? <\/strong><\/p>\n

  Uptime is never 100%.<\/strong> A world of factors conspire against 100% uptime, and can potentially disrupt the flow of bits from the server to your browser. But despite the number of factors, most hosting companies are at or above 99.9% uptime.<\/p>\n

  There isn\u2019t a single hosting provider with 100% uptime. Amazon AWS, one of the most robust operations, is (famously) not 100%. GMail isn\u2019t. Facebook isn\u2019t. Twitter definitely isn\u2019t<\/a>. Rackspace isn\u2019t. ServerBeach isn\u2019t. FireHost isn\u2019t. We could keep naming folks, but every single hosting provider, including WP Engine, hasn\u2019t achieved 100% uptime in a meaningful time-scale (like years).<\/p>\n

  Are all these companies \u201cstupid?\u201d Are each of these companies unable to hire top system engineering talent? TechCrunch had some choice things to say about this in their post after 15 minutes of downtime (referenced above)<\/strong>. Since none of these (industry-leaders) are 100% uptime, does that mean that they don\u2019t care?<\/p>\n

  Of course not.<\/strong><\/p>\n

  As we mentioned, most of these companies maintain an over-99% uptime rate. They often reach 99.99% uptime, and sometimes a bit more.<\/p>\n

  So what\u2019s the difference, in terms of cost and technical complexity, between 99% and 99.9% uptime? What about the difference between 99.9% and 99.99%?<\/p>\n

  First off, 99.9% uptime sounds like a lot, but it\u2019s nearly nine hours of downtime per year<\/em>.<\/p>\n

  Can you imagine how you\u2019d react if you had nine straight hours of downtime on your site? Not well.<\/p>\n

  99.99% uptime is still a non-trivial 50 minutes of downtime per year.<\/p>\n

  Every \u201c9\u2033 you add to uptime (e.g. 99%, 99.9%, 99.99%) is not only an order of magnitude more uptime, it\u2019s often a multiple more complex and expensive. At some point, trying to eliminate a few minutes of downtime now and then means doubling or tripling the cost of the service.<\/p>\n

  But lets break that cost down for a moment.<\/p>\n

  For example, to avoid hardware and software downtime for a single server, you can have several other servers in a cluster that the first can fall back on. Running multiple servers instead of a single one multiplies the cost by X number of servers. Nearly any hosting company will have some quantity of redundant servers, but some providers have a practice of adding more additional customers than there are secondary servers. When one server goes down, if the remaining servers don\u2019t have enough capacity for 100% of the traffic, the cluster still goes down, despite the precaution.<\/em><\/p>\n

  But almost all the examples above were data center failure<\/em> rather than single-server failure<\/em>. To combat that, you need servers in entirely different data centers, once again with sufficient capacity to handle 100% of the traffic alone, which means another 2x the cost which was already 2-3x<\/em>.<\/p>\n

  To avoid all the issues above is at least 6x more expensive in hardware alone<\/strong>, not to mention significantly more human and administrative effort. Plus, anytime you add more components as a redundant measure to prevent downtime, then ironically enough, each additional component increases the likelihood that one of your system\u2019s components will have trouble at any given time.<\/p>\n

  In order to add redundant measures as a hosting provider, you have to add infrastructure. More infrastructure means more complexity, and adds more potential for trouble, which you then need to take steps to mitigate!<\/p>\n

  So what does all this mean? That we shouldn\u2019t try? That we should just say \u201cit\u2019s hard, too bad\u201d when things fail? That we shouldn\u2019t continue investing in infrastructure and technology and techniques that our customers individually could never afford to pull off by themselves? Of course not, and in fact that\u2019s exactly what WP Engine, and all the members of the hosting industry listed here and elsewhere, do. We\u2019re always shooting for 100% uptime, and we always go into battle mode when there is the slightest blip of downtime.<\/p>\n

  It\u2019s our responsibility to hold ourselves to ever-increasingly high standards.<\/p>\n

  That\u2019s why only 1% of our customers had trouble the other day, not the other 99%. That\u2019s pretty good! But, we immediately began working to bring everyone back online, and then make improvements for the next time. If we don\u2019t continuously improve, that 99%+ could slip. And next time it would be awesome if only 0.1% of our customers had trouble. The bar must always be moved higher.<\/p>\n

  But perfection is unattainable, for WP Engine and everyone else hosting WordPress<\/a>, or anything else on the Internet. We can ask better questions than, \u201cWhich hosting has perfect, 100% uptime?\u201d<\/em><\/p>\n

  Instead, we can ask:<\/strong><\/p>\n

  \n
  • \u201cWhat is the track record of a given host?\u201d<\/em><\/li>\n
  • \u201cHow are incidents handled?\u201d<\/em><\/li>\n
  • \u201cHow often do they happen?\u201d<\/em><\/li>\n
  • \u201cAre they for silly reasons or for understandable reasons?\u201d<\/em><\/li>\n
  • \u201cIs there enough staff to continuously improve and to handle events when they happen?\u201d<\/em><\/li>\n
  • \u201cAre there multiple datacenter options or just one?\u201d<\/em><\/li>\n
  • \u2026And so on.<\/em><\/li>\n<\/ul>\n

    Those are the questions that matter the most when you evaluate a particular hosting platform and compare it to another. Everyone is going to have as little downtime as possible, and each of the previous questions get answers to the question, \u201cWhat are you doing to make sure you can mitigate this issue with zero downtime next time?\u201d<\/em><\/p>\n

    How the company chooses to answer that question goes a long way to let you know that your websites, and therefore your business, are indeed in good hands.<\/p>\n

    For another perspective on this, Uri Budnik<\/a> wrote a detailed post on the RightScale<\/a> Blog titled, \u201cLessons Learned from Recent Cloud Outages.<\/a>\u201c<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

    \u062f\u0631 \u0627\u06cc\u0646 \u0633\u0631\u06cc \u0645\u0642\u0627\u0644\u0627\u062a \u0628\u0647 \u0628\u0631\u0631\u0633\u06cc \u0627\u0645\u06a9\u0627\u0646 \u0631\u0633\u06cc\u062f\u0646 \u0628\u0647 \u0622\u067e\u062a\u0627\u06cc\u0645 100 \u062f\u0631\u0635\u062f \u0645\u06cc \u067e\u0631\u062f\u0627\u0632\u06cc\u0645 \u06a9\u0647 \u0627\u0632 \u0633\u0637\u062d \u0627\u06cc\u0646\u062a\u0631\u0646\u062a \u062c\u0645\u0639 \u0622\u0648\u0631\u06cc \u0634\u062f\u0647 \u0627\u0633\u062a .<\/p>\n","protected":false},"author":1,"featured_media":179,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[45],"class_list":["post-178","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-1","tag----100-"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/posts\/178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/comments?post=178"}],"version-history":[{"count":3,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/posts\/178\/revisions"}],"predecessor-version":[{"id":182,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/posts\/178\/revisions\/182"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/media\/179"}],"wp:attachment":[{"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/media?parent=178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/categories?post=178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pardis.it\/mag\/wp-json\/wp\/v2\/tags?post=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}