Disaster Planning on an SMB Shoestring
Nov 13, 2012 5:00 AM PT
For folks on the East Coast of the United States, the past few weeks have been pretty intense. Between hurricane Sandy and the associated fallout -- flooding, lack of public transportation, power outages, dark cell towers -- many firms in impacted areas have experienced firsthand the value of their BCP -- business continuity planning -- and DR -- disaster recovery -- planning efforts.
Those that didn't have a DR or BCP plan in place before? Well, many have them now -- or at least have started the planning. The point is, an event like this puts the value of disaster preparedness in stark relief.
When it comes to the SMB, sometimes it can be hard for IT professionals to get the kind of focus on disaster and continuity planning as they might like. It can be a bit of a quandary: the perception can sometimes be that planning for disasters is something only the "big guys" do, not something a smaller organization would need.
However, as IT managers who have been through an actual event can tell you, just because a company is small, pressure from management to keep business apps alive and kicking doesn't disappear. Expectations are high no matter the organization's size. It's only the resources to do the work that are limited.
No Such Thing as Too Small to Plan
So, let's dispense with the too-small-to-care myth from the get-go. In point of fact, planning for an emergency situation is every bit as important for a small business as for a large one -- it's arguably more important. Why? There are a few reasons for this.
First, each resource that isn't productive during an outage counts more from the point of view of the smaller organization. This is because each employee -- as a percentage of total personnel -- has higher individual impact. Think about it this way: one person who can't get to work in an organization of 10,000 is .01 percent of the workforce; in a company of five people, that same person is 20 percent of the workforce. This same phenomenon means that each hour spent non-productively by personnel -- for example, due to unavailability of critical resources -- is also correspondingly of higher impact.
Secondly, keep in mind the fact that a large, geographically distributed organization might have multiple facilities -- only some of which will be offline during a particular regional event. For example, in a regional situation like Hurricane Sandy, which strongly impacted only the northeast, a national organization with offices and workers throughout the U.S. can still remain operational and distribute the load across areas that are less impacted by a regional event. A smaller shop may have only a few regional locations, which means that a localized event could impact conceivably all of that organization's facilities. Depending on when it hits -- and for how long -- this could have serious consequences: inability to service customers, inability to make payroll, inability to bill for services, etc.
These facts are the ammunition that you'll want to bring to the table to make a business case for preparedness planning. For example, if you can express to management the soft dollar value of an event like Sandy -- as well as the hard-dollar costs of lost revenue -- you'll find the conversation about keeping resources available much easier to have. Remember that you're fighting an entrenched perception in many cases, so making a strong case and spelling the situation out using hard numbers is the way to go.
Planning in the SMB
So, assuming you can get some traction on preparedness planning, the next question that comes about is what you should do and how you should proceed. It's important to note that the planning that a smaller organization takes will be significantly different from a larger organization. This is particularly true when it comes to data gathering and mitigation. Data gathering -- and thereby planning generally -- is arguably easier the smaller the organization is; however, mitigation is arguably harder.
First, data gathering for BCP and DR in a large enterprise usually starts with canvassing stakeholders to find out what applications are most critical to keeping the organization running -- for example, via formal business impact analysis. This can be a time-consuming process involving potentially weeks of effort meeting with and interviewing (or, depending on methodology, sending questionnaires to) folks all throughout the organization.
In a smaller organization, this process is usually greatly streamlined. In many cases the environment is small enough that the IT folks know intimately the business applications that folks on the business side care about. In other words, much of the guesswork is removed from the process because of the organization's smaller size -- IT resources might even be able to forgo much of the planning because they understand the environment so thoroughly already.
On the other hand, developing availability strategies is more difficult when the organization is small. This is often due to lack of resources. For example, no matter how much the sales team would really like their SharePoint instance to stay available during a sustained power outage, accomplishing that isn't easy on a limited budget. So it's here that you'll really need to get creative.
For example, a dedicated hot site with to-the-second accurate backups of every critical resource might be way too far a stretch -- but what about getting creative and keeping an off-site virtual image of it synced (maybe with a granularity of every few days) to an external location that can get "pushed" in an emergency to a public cloud environment like EC2? That's way more possible. Essentially, what you'll be doing here is thinking through what you can afford to keep the critical items available during an outage.
Even though you might not be the biggest company in the world, understand that being able to stay productive during an outage is possible -- it just takes planning. A situation like Sandy doesn't have to be catastrophic, so long as you take the time to think it through ahead of time.