The current flooding in Houston caused by Hurricane Harvey points out the need for technology architecture that is designed to keep the business operating during a disaster. But that is not the whole story.
We conducted an in-depth interview with long term tech leader and CIO Mark Bates, along with Joe Kipp and Brandon Stephenson of KiZAN’s Modern Data Center and Infrastructure teams, to discuss possible learnings from our country's most recent disaster.
The following are some brief takeaways.
- What’s the difference between disaster recovery and business continuity?
- Are data backups enough?
- Are disasters only “natural” events?
- What should my plan include?
- What you should do right now!
|Mark Bates||Joe Kipp||Brandon Stephenson|
Disaster recovery, in the classic sense, is what I.T. refers to as being able to keep technology up. It’s I.T.-centric and pretty traditional.
Business continuity is keeping the business going, and the goal in the broader sense is to give the business as many options as you can.
You can’t plan for every scenario, but you want to give the C-Level and operating leaders the flexibility to mold the business around the problem that’s occurring.
Backups are absolutely not enough as a disaster recovery solution. Backups are just a way to restore data. Backups keep the data alive, but they’re typically not appropriate as a disaster recovery plan because you have to have a place to restore that data; you have to have a plan for how and when you’re going to turn it on.
Additionally, how and where are your employees going to work? What happens if you’re not there leading the efforts? In the case of Houston, a lot of those CIO’s and IT staff are a part of the disaster; their homes are under water or may be gone. First and foremost in their minds may not be keeping the business going, it may be keeping their family alive.
Absolutely not. A disaster can be as simple as a fire in a building that holds your data center. Typically, in the case of our customers, the facility where the data is processed is not necessarily where their productivity comes from; it’s a separate building. A set of sprinklers going off a floor above your data center can prevent your team from working even if they’re all in the office and ready to work.
It’s very important to understand that it doesn’t have to be a big environmental disaster,
it can sabotage, or an odd chance that something goes wrong in your part of the country or neighborhood,
or inside your building that can cause an issue.
You can also think about technical disasters. We’ve had customers who have had their entire environment taken down because of a technology change, and it was severe enough that they activated their disaster recovery just to get back to something that was more stable.
There are more common issues, like fire, that will affect you directly in your business continuity. At another company we experienced an evacuation because a company two floors up had a disgruntled employee situation; utilities may be shut down because of a crisis near the building; an HVAC failure or a sewer backup in a part of the building can cause your employees to have to evacuate.
The problem with even these simple outages is that you never know,
initially, how long they’re going to last.
Scenario planning, which is the most important part of what you do, has to take into account the time dimension as well as other factors. You have to think of things like your communication plan to employees and customers. How and what are you going to communicate as the minutes become hours and hours become days?
Have you thought about backup facilities not just for your technology, but for your people and operations? How are you going to get ahold of vendors in an emergency? How are you going to get ahold of clients initially to tell them what’s going on, and potentially thereafter if you’ve had to make critical decisions.
Your disaster recovery plan may be foremost and up to date, but your technology inventory may not be; you need to know where all your hardware is, particularly if you have to send it home with people.
The scenarios you have to plan for aren’t necessarily category four hurricanes hitting the Midwest.
The scenarios are much more common than that, and they occur, really, very frequently,
and if you’re in the chair long enough, they’ll occur to you on multiple occasions as an IT leader.
When you’re considering scenarios, you can go hog wild, but you should focus on your operations, not the nature of the disaster.
- What if we lose power?
- What if we lose connectivity?
- What if we lose staff?
- What if we lose a facility and the ability to work from a location?
One of the things that are important to keep in mind is how expensive these outages can be if you’re not planning for them. As such you should right-size your plan:
- Who are the essential staff?
- What are the essential systems?
- How much performance degradation are you OK with to save $500, $1000, or $5000 a month maintaining your disaster recovery systems.
Having these plans in place do have a cost, and I think that’s why we’ve seen a lot of leaning to Azure-based disaster recovery and the Office 365-based productivity options. A lot of the “facility” disaster recovery is taken out of your hands and put into Microsoft’s hands, and that’s reassuring in a lot of ways.
Having the right cloud architecture to make sure that your DR is going to be far enough away
from the point of impact can be a viable consideration for even the common scenarios,
and is more affordable than the alternatives.
- First off, understand that Disaster Recovery and Business Continuity planning do not have to be lengthy, and do not have to be expensive, but it does have to be something every company does…not just big companies. Extend your traditional (I.T. focused) DR planning) to business continuity and reach outside of the I.T. organization and bring your partners from the operations area into a planning exercise.
- Create 5-7 planning scenarios, because those 5-7 scenarios will flesh out the capabilities and tools you need to have available to give the business the ability to run.
- Then, you’ll possibly need to add or change some of your technologies to match the needs your planning has revealed.
KiZAN can help you through all or part of that exercise, but it is important that you do every element.
For those that have a plan, when was the last time you tested it and was it successful? If you haven’t tested it or it wasn’t successful, you need to circle back and start planning again.
Even if you have a plan, there have been a lot of changes in what options you have. BYOD policies and procedures allow you to remove parts of your disaster recovery plan or might have a whole other level of business continuity. Same thing for cloud computing; using infrastructure as code and other DevOps methodologies that are doing continuous deployment can have a huge impact on what it actually means to failover and are important things to consider.
Every business needs a Disaster Recovery Plan
KiZAN can help.
Check out all our Disaster Recovery resources
Schedule a Free Disaster Recovery Discovery Session today!
Posted by Brad Watson
As KiZAN’s B2B Ambassador, my job is to cut through the buzzword clutter. With a background in broadcasting, writing, advertising, software development, and business ownership, I’m uniquely positioned to help you deflate the “marketing fluff” and identify solutions for the “true” needs of your organization.