* Reader makes a good point about disaster preparedness
The second of last week’s newsletter http://www.networkworld.com/newsletters/stor/2006/0904stor2.html – which admittedly was only incidentally about disaster planning and was much more about market planning – got some interesting responses from the readers.
The second of last week’s newsletters – which admittedly was only incidentally about disaster planning and was much more about market planning – got some interesting responses from the readers.
This one, from Yannick, made an especially good point: “I really think that companies are not prepared to face disaster. If you imagine a pandemic flu, most of the companies would not be able to have their employees working remotely. This is not just about recovering the data on their laptop or desktops, as you accurately mentioned, but simultaneously to keep the operational cycle running.”
Well, this certainly hits one very deserving the nail right on the head, and suggests what may be a good analogy: data recovery is to disaster planning as backups are to data recovery. Here’s what I mean.
These days everyone understands that the only purpose for doing backups is to support future recoveries. Backups are a hedge against the future that, like insurance, we all hope never to have to use. But of course, eventually we all use insurance and eventually we all try to recover data from backup media.
Backups, then, are the “sine qua non” of recoveries (go ahead, you non-Latinists, you can get it).
In a similar sense, pervasively available data is the fundamental deliverable of any disaster plan, but it is certainly not the only one. Consider the following:
When a disaster hits, a major part of the challenge is to put into action an as seamless a failover as circumstances allow. At more sophisticated IT shops – those that have had the money to invest – they frequently have automated the process to the point where a failover may not be particularly impactful to running processes (although when the remote disaster site has less powerful machines running there certainly would be some degradation in service levels). But does this really address reader Yannick’s point about keeping operations running? In most cases, the answer is no.
Most, if not all, disaster planning these days is tasked with keeping IT processes up and ready to continue servicing whatever demands the business may make. But what if there are no demands? What if, after the failover is effected, the data is ready but the users are not?
This is not like asking the question “what if you gave a party and nobody came?”
One of the things we surely should have learned in the aftermath of hurricane Katrina is that even if services – rescue, data, whatever – are provided, that doesn’t necessarily mean they will find their way to users in a timely fashion. Having available data in no way assures that operational business processes continue.
It seems to me that disaster planning must begin to consider a set of responsibilities lying well beyond the ones traditionally covered by the data center staff. I admit I’m not quite sure what all those might be – likely as not they will vary from company to company, but surely if the business processes are not up and running soon after a disaster, corporate disaster planning is flawed.
Probably this complete corporate disaster plan needs to be based on the question “does the business continue?”
How might you go about this sort of exercise? A two-pronged approach might be appropriate. First, check up on the health and welfare of corporate citizens who might have suffered from the disaster- Are they all right? Are their families all right? Is their anything that the company can do to help? This is the altruistic prong.
Second, make sure there is a functioning plan for at least key users to work remotely if something untoward happens to the main corporate site. This is the business prong.
An optimized IT installation looks at all aspects of IT as being parts of a system. An optimal disaster plan looks to take a similar approach.
