Welcome!

Continuous Integration, Continuous Delivery & Continuous Testing

Tim Hinds

Subscribe to Tim Hinds: eMailAlertsEmail Alerts
Get Tim Hinds via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Security Journal

Blog Post

How the Aftermath of a Website Crash Helps Prevent the Next One By @Neotys

Be prepared for when disaster strikes

Imagine this nightmarish scenario:

A sizeable crash has just happened, and your company website has stopped functioning. It's a big deal, and you're certainly feeling anxious due to the loss of both revenue and reputation, but more surprises may lie in the aftermath. Any company that has experienced a catastrophic crash knows that it's like an earthquake. The same problems can strike more than once, just like aftershocks, shaking you off your feet just when you're beginning to regain confidence.

At Neotys, we know how important it is to figure out what went wrong and plan so it doesn't happen again. In this post, we'll look at some common causes of major website crashes, along with preventive measures you can take to avoid them in the future. With this extra knowledge under your belt, you'll be prepared when disaster strikes.

Why Getting to the Root of the Problem Matters
After a crash, you've likely taken a number of emergency precautions. For the purposes of this discussion, we're going to assume you've rectified the immediate situation and things are mostly back up to speed. Maybe you noticed one of these common performance problems and made an appropriate short-term fix. This certainly takes the burden off, but now you're faced with a tough question: How do I prevent it from happening again?

A cursory glance at the problem is simply not enough. Some people may be content once traffic has subsided. After all, if it was a spike in traffic that took your website down, once it goes away you'll find your site up and running again. Things may look okay, but you essentially did nothing. You aren't prepared for another spike, and you've learned nothing from the experience.

Best practices suggest you conduct a thorough post-mortem and identify the root cause of the issue. Let's go deeper into what exactly should happen in a post-web crash world - and what better way to learn than from the mistakes of others?

Remember Best Buy's Black Friday Crash?
The high profile example of Best Buy's crash on Black Friday is the perfect place to start. On one of the most profitable shopping days of the year, Best Buy's website went down for a reported two to three hours. The company reported a revenue loss of a few hundred thousand dollars. I don't know about you, but that's a lot of money to lose for something that could have been easily prevented by modern performance testing methods.

Best Buy placed the blame on an unexpected spike in mobile traffic. Seeing as the shopping holiday occurs every year, you would think that the company would understand and analyze the implications of this expected influx. However, Best Buy is just one in a string of companies that ran into trouble this past year. Netflix, HP, Foot Locker, Cabelas and a number of UK outlets (Currys, Argos, Tesco) all faced outages. The UK companies get a mulligan in our eyes (as Black Friday is a new phenomenon there), but maybe not in the eyes of their investors. Hopefully, they have all started preparing for next year. Here's what they should be doing.

Let's Be Honest About the Problem
There are several repeat offenders that cause web crashes. These troublemakers may include:

  • Software configuration issues for web servers, databases, or load balancers
  • Poor network configuration
  • Poorly optimized software code, for example, code that does not allow for concurrent access.
  • Insufficient hardware resources or lack of auto-scaling elastic computing.

Cloud server migration is another up-and-coming problem. HP found itself in hot water with this one, which is a bit ironic seeing as how the company is trying to position itself as a provider of cloud solutions. Its content delivery was served correctly, so that wasn't the issue in this case. It was on the back-end, and most likely due to failure under load.

Making Crashes aThing of the Past
Whatever the issue, you've got to assume that if it happened once, it will happen again. Just because your site is up and running again, doesn't mean you can ignore that root cause. Identify it, and plan for next time.

Once you think you understand the core issue, don't stop at the initial, immediate solution. If the problem was disk space, first determine why you ran out. Of course you'll want to install more storage. However, you still must discover why you incorrectly estimated how much you needed. Going through these steps will help you realize the precise solution and improve your data modeling.

Your solution may include fixes to the hardware environment or the software code; it may also include new procedures and automated reports for monitoring status. Don't just put a band-aid on the situation - heal the real problem.

Next, look for ways to recreate the issue in a controlled way. For example, simulate a large number of users stressing the system through a variety of realistic load testing scenarios. Focus on scenarios that:

  • Have been known to cause problems in the past
  • Are new and untested
  • Are likely to produce bottlenecks
  • Involve complex transactions
  • Are critical paths for users

These scenarios are crucial for discovering how your website reacts with abnormal amounts of load. By simulating user performance, you'll be able to review how tasks and transactions will function for your real users. Keep repeating these tasks and changing certain variables to ensure application reliability. Gather information throughout the year, and tweak your scenarios as much as possible.

Expect the Unexpected
If there's anything we can learn from online disasters like Best Buy's crash, it's to expect the unexpected. Much like a natural disaster, a web crash often catches us off guard when we least expect it. However, being prepared starts by acknowledging the possibility of a crash. Next, build your safety kit by analyzing the root causes of past problems and developing realistic load testing scenarios. Finally, continue to test, retest and configure variables. That way, when you feel the first wave of a potential disaster, you'll know what to do and hopefully prevent a crash.

More Stories By Tim Hinds

Tim Hinds is the Product Marketing Manager for NeoLoad at Neotys. He has a background in Agile software development, Scrum, Kanban, Continuous Integration, Continuous Delivery, and Continuous Testing practices.

Previously, Tim was Product Marketing Manager at AccuRev, a company acquired by Micro Focus, where he worked with software configuration management, issue tracking, Agile project management, continuous integration, workflow automation, and distributed version control systems.