Your website will fail

Your corporate website is robust right? Massively over-specified servers, redundancy and clever load balancing technology make it seamless at managing demand several orders above base level. Clever and dedicated geeks monitor its every move, tweaking and adjusting to keep everything humming along nicely.

No matter. It will still fail.

Websites do fail. They fail all the time and the consequences may well be felt in the real world.

In the Queensland floods local authority websites were overwhelmed by demand for the flood inundation maps at precisely the moment when failing to deliver those maps had severe consequences.

Social networks can spike demand on servers in surprisingly short order to extreme effect. These networks are increasing in scale geometrically.

And there is always a risk of malicious actions, someone pouring coffee into a key router or a problem upstream in the DNS ecosystem.

So what can you do?

1. Clearly continue to work hard to make sure the website doesn’t fail. Critical systems are much more reliable these days than even a few years ago. Cloud-based systems have attraction for their resilience (though may give information managers the heebee geebees).

2. Have excellent back-up arrangements. Plan, exercise and refine the process of restoring from a backup. I work with an EU web-based company who lost their server and found that the promised back-up arrangements were nowhere to be seen. This is not something you want to discover when the data has been lost. The fact that you can sue won’t help your customers on that day.

3. Have alternative web procedures: a “dark site” which gets fired up in extremis or mission critical data distributed onto other platforms. You will also need a plan about how to let people know where this data is to be found. An attractive feature of the growth of social networks is that you can communicate with customers online in a range of platforms. So if you fire up dark.marchford.gov.uk you can let your facebook users know at least.

4. You could also look at this critical data in your web architecture. Maybe those flood inundation maps should be stored on an Amazon machine and not in your server at all. Maybe they should be available in a range of file sizes and quality, delivering smaller files at times of high demand.

5. Exercise. Pull the plug: at 3 on a Sunday morning, in the middle of a live multi-agency exercise, at 1030 on a Friday night. Test those procedures, improve them, make them normal practice.

But the key is to start thinking “when this website fails, what will customers do, what will we do?”.

Because your website will fail.

Comments