There are several techniques available to provide reliable Disaster Recovery and Business Continuance for companies, but before you can chart a path you must recognize that it is the nature of your business that will dictate your DR/BC requirements. Typically the business will tell you that your application or service can never go offline. That is, until you are presented with the cost of a 100% uptime scenario. Enterprise environments should be armed with a cheat sheet for business units to understand what they are asking for and how much it will impact the budget. If your IT department is in a chargeback model, the argument becomes simpler. Companies whose business requests and requirements become IT problems and budget busters need to be better armed with information.

Most companies do not start planning DR/BC initiatives early enough. It is far easier to implement a plan early (and then build upon that original plan) than it is to implement a new plan after you have hundreds of servers over multiple geographic locations. There are several techniques to determine which applications and services require special attention, and most are dictated by the business. However, since IT provides the core services that enable access to these business essentials, there’s a cascade of dependencies which also need to be accounted for. For example, it really wouldn’t matter if the ERP system was up and running if the end users couldn’t authenticate or locate the ERP system on the network. When mapping out the business-critical applications and services, make sure to design a highly resilient supporting infrastructure that is easy to maintain and keep in alignment with business and DR/BC goals.

Notice I’ve been writing about ‘applications’ and ‘services’ and not servers. This is because businesses care very little about a server, but instead care very much if an application or service is available. The server culture is under constant attack from clustering, virtualization and cloud computing deployments. As long as applications and services are available, the business will not care if half of the servers supporting this functionality crashed. Appliances are a different story. In the last decade, the trend was to deploy appliances to lessen the burden on IT departments for deployments. Today, most vendors are moving toward virtual appliances and you should take advantage of this trend. 

Tier your applications and services in a list broken down into:  

Uninterruptible Goal of 99.999% or better uptime (roughly 5 minutes of downtime per year)
Essential Goal of  99.995% or better uptime (roughly 30 minutes of downtime per year) 
Critical Goal of 99.99% or better uptime (roughly 1 hour of downtime per year)
Important Goal of 99.95% or better uptime (roughly 4 1/2 hours of downtime per year)
Enhanced Goal of 99.9% or better uptime (roughly 9 hours of downtime per year)
Standard Goal of 99% or better uptime (roughly 3 1/2 days of downtime per year)
Other – Can be down for multiple concurrent days

Companies that use a chargeback model should include DR/BC costs against this chart or a modified version of this chart. Calculate the overall cost and amortize for the life cycle of the implementation.

You may find you don’t want all of these levels of uptime and would be better suited to only offer a couple of levels. It is important to differentiate between Disaster Recovery and Business Continuity. You can argue the definitions for years, but to make it simple, I’ll break it down this way: Disaster means that your datacenter or facility is completely offline for an unacceptable amount of time where people/applications/services need to be relocated to continue normal operation of the business. Everything else falls under Continuity. It is far easier to recover from an issue without moving people/applications/services. The Business Continuity is mostly a site-specific action plan with a couple of modest exceptions relating mostly to infrastructure. 

Your typical SunGard type facility works with tape restoration. This can take several days to get fully back on line before people can work and your core business is functioning again. Unless your facility is completely unusable for a period of time, this option is perfect for a pinpoint Disaster like a fire, but fails the local community when multiple businesses are in need of the same facility. 

Only the business can determine the criticality of each deployment. Infrastructure will need to respond by making the core services available at the same service level or better. For example, if infrastructure is responsible for ensuring a database-driven application deployment needs to be available at 99.999% uptime, this requires every dependency to have even better availability. Consider the database, network, servers and connectivity to the system all have 99.999% uptime; if each of these dependencies has a 5-minute outage, the overall deployment has a 99.995% uptime. The business should understand the cost of requiring multiple 9’s right of the decimal point. The cost incline isn’t as steep as it was a couple years ago, but the cost can be significant and multiplied if the business and IT organization doesn’t take a holistic view of DR/BC.

For help developing a disaster recovery and business continuance plan, contact MUSA Technology Partners, experts at DR/BC solutions.

Digg This!

Subscribe to the MUSA Blog RSS Feed

Domestic Outsourcing | Planning | Business Continuance | Disaster Recovery | Technology Consulting | Life Sciences IT