Superstorm Sandy has left more than a trail of devastation in neighborhoods; she continues to wreak havoc on businesses throughout the area. A friend of mine is relegated to indefinite telecommuter status because salt-water flooding compromised infrastructure at her company’s Manhattan headquarters.
Like many of the businesses in the strike zone, IT teams’ disaster recovery scenarios are under the microscope. Are there enough software licenses to cover everyone who needs to access applications remotely? Can the servers handle a maximum load of remote users all day, every day? Are employees equipped with appropriate hardware, software, and connectivity to carry out their jobs?
Businesses in New York, New Jersey, and nearby regions are finding this out the hard way right now. All others should study the responses closely, analyze their own disaster recovery and business continuity plans, perform drills in the near future, and watch for postmortems from their industry peers.
Before you can assess your ability to handle a full-time, remote workforce, you first have to analyze your workflow. Chart each person’s role, and the exact applications and centralized data he or she would need access to in a scenario. For instance, if the employee is responsible for customer service, he will not need access to the financials database. Being this specific becomes essential as your network resources are constrained. You don’t want users consuming bandwidth, server CPU, and licenses for non-related tasks.
Next, use asset management tools to gather an inventory of the software, hardware, and platforms in use across the enterprise. Check versions, security patches, and overall configurations to ensure they are able to handle the rigors of remote access. If not, budget for an upgrade as soon as possible. Users will not suffer a spinning hourglass when chaos is erupting around them.
Have all your workers telecommute for a day. This might sound crazy, but you’ll never really know how the ecosystem (human and technology) will respond until it is under that type of duress. Take note of every aspect:
- What kind of support do users need? Can you offer that training upfront or pre-distribute how-tos? Will you need an emergency help desk to get users up and running?
- Did the servers hit maximum utilization, and at what point? Did virtualization help balance the load, or do certain applications need to be reconfigured? Do you need to implement better prioritization so that mission-critical applications always have the CPU power they require? Performance management tools, both onboard servers and third-party, measure and analyze this data for you.
- How did your bandwidth hold up? Network monitoring and traffic analysis tools illustrate capacity issues during peak times as well as usage patterns. While an actual disaster would skew these results, it gets you closer to providing a stable network for access. Again, you might have to set priorities so that voice over IP, video, and other communications get through with low latency.
- Do you have enough licenses to support a remote workforce? If users ultimately have to rely on applications such as Web-based mail that they might not otherwise use, then you’ll need enough seats to accommodate everyone. Executives and HR use email in a disaster to gather and disseminate status updates and other important information.
- How will you get data re-centralized? Users will be forced to work offline because of spotty connectivity and other issues. You’ll have to ensure that whatever documents pile up on their laptops gets back to the datacenter without overwriting other versions.
- What is the state of your security? In a disaster, IT can be tempted/pressured to compromise on its tough remote and mobile security stance just to get people up and running. However, doing so can have long-term, destructive consequences.
A lot of people will use their own devices, so make sure they are educated and trained to safely access applications and data. Also, while it might seem a slam on productivity, if working at public hotspots is considered too risky and against compliance outside of a disaster, the same holds true during a disaster. For instance, employees cannot work with sensitive user or corporate data at a coffee shop just because it has Wi-Fi and power. Those employees might require a pre-assigned temporary office with full network security.
Most companies prepare for short-term inconveniences, such as a Nor’Easter taking out power at headquarters. Superstorm Sandy has taught us that serious geographic, operational, and infrastructure damage can take a company offline indefinitely if IT, workers, their devices, and the datacenter, aren’t properly prepared.
Will Superstorm Sandy change how you conduct disaster recovery analysis? Share on the comment board below.