I have been watching as a spate of recent high profile website launches have turned into full blown PR disasters, I can only guess what actually led to the disastrous launches but some important lessons can be learned. This is not to say that we have not had some … err … challenges with site launches but no real disasters as yet.
Recent Launch Disasters.
The most recent disaster obviously has been 2Degrees Mobile – and they have messed it up pretty good (and even more incredibly). Firstly the developers must have under-estimated the amount of traffic that was going to be received on launch day. This meant that the site was unavailable for most of the morning of the most important day in the companies short history.
Well meaning PR companies create so much hype (and the hype for 2Degrees was extreme, the TV ad’s probably started earlier than thay needed to so at launch day the frothy masses were always going to inundate the site).
A large increase in traffic was predictable as they would have had a large amount of traffic in the days leading up to the launch.
I tweeted (http://twitter.com/federationmedia) about the sites unavailability and how it did not reflect well on the company recently and someone replied saying ‘you can’t do much about a DDoS attack’ – this most likely was not a DDoS (def.) attack – I believe it was a predictable spike in traffic (I have since seen Tweets suggesting the ‘Evil Twins’ were responsible = very unlikely).
Any high traffic (or potentially high traffic site) site should be stress tested before launch. This is the most simple method of checking if a website is going to stand up to this increased traffic, Microsoft (and any number of other companies) provide tools to do just this.
Scale up – quick time
The difficulty developers face is that in traditional hosting environments it is not always easy or cost effective to upscale resources to handle large short term spikes in traffic, this can mean adding more RAM or CPU cycles to webserver – not always that easy. Virtualised server environments make this much easier and generally CPU, RAM, and disk space can generally be added and removed easily and often without a restart.
The relatively new and much heralded “cloud computing” model has also come to website hosting and if a site is expecting very large spikes in traffic this may be a good way of just paying for what you use and scaling up really really quickly if you need it. The large US based hosting company Rackspace (
http://www.rackspacecloud.com/ have recently started offering this service. I do not know of any NZ based web hosting companies yet offering this but it is (possibly?) only a matter of time.
Other sites that have suffered from spikes in traffic bringing their sites down are Mintshot (down for most of launch day), http://www.blogger.com/www.freddo.com.au – I saw an advertisement on the TV for this virtual world type game – the TV ad (which as I remember it was on a Sunday evening) made the game look amazing – I diligently went to the site first thing Monday morning only to find the site not taking any registrations due to high demand – oops.
The Warehouse ecommerce site – this was down for the good part of a whole weekend the first weekend after launch – I am not too sure why this was.
Various Airline sites have over the years sufferred from this problem due to a scramble for flights (the most recent is Jetstar), but Freedom had major issues several years ago.
Security Issues
Well poor old 2degrees had a double wammy of disastrous launches – soon after the site actually started responding Twitter was atweet with reports of users getting to the checkout and seeing other users (assumed to be on the site at the same time) details appearing, including phone numbers, email addresses, postal addresses etc.
These parts of the 2Degrees site were smartly disabled – rendering the most important parts of the site – buying stuff and transferring to 2degrees – buggered. At the time of writing (some 10 days after launch) the site is still only partially opperational.
The key here is test, test and retest. The Kiwi quaint (and I find somewhat culturally cringy) message that was put in in place of the business end of the website was that it was due to high traffic. I doubt that this was actually the case – I just think that it had not been tested properly. Sure, the ability to test for every possible senario is very difficult from a development point of view but the problems that they faced suggested something fundamentally wrong with the development architecture.
Bad planning.
Another recent launch that turned into a PR nightmare was the much vaunted Northern Gateway toll road north or Orewa. The company encouraged people that would be regularly using the tollway to register on the website and enter their credit card details. Only trouble was someone had forgotten (?) to purchase the SSL certificate for the site – this meant that people that were entering their credit details were so in a very insecure way. The site had to be taken down and almost a thousand people told that their credit card details were taken in a insecure way. Sloppy and bad planning.
As it happened the site went on to suffer a lot of other issues including wrong amounts being charged to the wrong people.
Just Bad.
The lesson here is one about testing but also about using tried and tested ways to engage your users rather than rely on ‘bleeding edge’ (def.) proprietary technologies.
Who can forget Jetstar’s recent launch in NZ – I tried to buy a cheap fight and the website (and whether due to traffic or just a bad website) I couldn’t. Reading forums and other sources I was certainly not alone, many many people had problems with the site and those who could get past the search could not find any cheap flights.
When things go wrong
Things do go wrong, and have for our dev team from time to time – the grim reality is that every high volume site has security issues to deal with (even giants like Twitter or Facebook). The key thing to remember that if things do go wrong, particularly if security is the issue, you will be judged by what you do after the breach/launch and how you handle the situation.
Take a look at this blog post from a large email marketing company for an example of what to do when things go wrong: Campaign Monitor hacking Blog Post (read the comments – they are (increddibly) mostly positive)
The key is to be honest, up front and fix any problems quickly – more often than not your clients will respect your honesty.
How to avoid the Launch Day blues
- Get your web development production partner involved in the project early – preferably early in the planning phas
- Spend more time and, if necessary, money in the planning phase of the development
- Estimate potential traffic and ensure that this is conveyed to the developer – plan as such
- Soft launch the site before launch day if possible
- Stagger your launch activities, if you have TV ad’s screening launch the site a few days prior to try to spread traffic spikes, be careful about creating too much hype
- Take some responsibility for User Acceptance Testing of the website/application
- Stress test your website/application, identify potential bottlenecks and consider caching static data (even just for launch day)
- Choose a web partner that you trust and understands the risks of launch day
- Choose a web partner with a proven track record – you get what you pay for, be careful about outsourcing