This article is still a Work in Progress. Please leave comments and suggestions on the discussion tab of this article.
While disaster recovery requires stringent planning, there may be scenarios where planning fails and business continuity is affected. Some of these situations would include oversight on component testing within a process, thus affecting the continuity of an entire business process. Other examples of failure in disaster recovery planning include backup sites that are located too close to primary operations sites. More commonly, inadequate budget and disaster recovery emphasis from top management will also restrict survivability planning to only core functions, and limiting survivability of other functions.
Contents
|
Survivability Capability
Survivability capability is the process of ensuring that all possible disaster scenarios have been considered. Subsequently, adequate counter measures would need to be adopted for these disaster scenarios for business continuity. This would incorporate the analysis of entire processes, interdependency of various components within applications, worse case scenario planning, continuity planning for obsolete software and hardware replacements, geographical factors that may hamper survivability efforts and comprehensive testing efforts to ensure that all possible failure areas have been identified.
Specific operational goals of implementing tiered storage
This section is still Work in Progress. Check back later for updates.
Using the Wikibon model business ($1B revenue), list the FIVE-to-EIGHT seminal operational goals associated with generating the capability. These goals should include:
- Expense to create the capability.
- Time to create the capability.
- Operating attributes of the capability (resources to deliver at what scale)
- Expected range of “Variable 1” business returns.
- Expected range of “Variable N” business returns.
- General impacts on “average” infrastructure.
- Key exit considerations.
Risks of implementing survivability techniques
Implementing disaster recovery survivability is an area of high risk. While this capability reflects and effort to identify loopholes in conventional disaster recovery initiatives, there are still risk areas that may cause these efforts to fail:
- Inability to obtain approval and buy-in from top management to implement efforts to improve survivability. Otherwise, if management approval has been obtained, the amount approved for this initiative is adequate to cover critical survivability areas.
- Disaster scenarios that cannot be tested
- The human variable factor in disaster recovery or key personnel assigned to specific roles that are unable to perform their duties during a disaster.
The Techniques to improve survivability initiative
The disaster survivability improvement initiative needs to be implemented systematically through analyze, design and deploy stages. It is common for the effectiveness of these initiatives to be only realized during a disaster.
Expectations (Out-of-scope) (200 WORDS)
This section is still Work in Progress
Every initiative has a scope. However, every initiative requires that certain out-of-scope expectations be met if the initiative is to succeed. For example, an initiative intended to deploy a “customer profitability reporting” capability presupposes the existence (or commitment to deploy) of function for aggregating customer data in some form. This section highlights, in list form, the three-to-five, out-of-scope conditions or expectations that must be satisfied for the initiative to succeed.
- Prioritization of applications and hardware sustainability based on individual importance to overall business continuity has been established.
- More to be added later
Analyze Phase
Acceptance Test Considerations
A fully detailed blueprint and step-by-step project outline for the analysis phase can be found at Analyzing Techniques to improve survivability.
Key analysis milestones
This phase should take X of weeks and the effort of X number of people:
- Perform a thorough analysis of interdependency between components within a process. This would involve fact-gathering of key business users of each system within each department. Interviews would need to be conducted between the disaster recovery team to draw an overall blueprint of business process systems within an organization.
- Conduct a Business Impact Analysis of all failure points within business processes. Using the blueprint developed, identify the impact of failure points towards critical business operations needed for continuity – e.g. Finance, Operations, Support Services.
- Narrow specific down failure points that would need to be sustained in order for business continuity. Identify systems, applications and humans involved at these points.
- Develop a backup plan for systems within each of these critical points.
- Develop a comprehensive test plan which covers all aspects of redundancy. This would include people systems as well as storage systems.
- Test redundancy systems based on worse case scenarios such as Hurricane Katrina.
- Define human backup roles and outline training for backups. Identify sources for remote support. Specified training frequency to ensure human competency in disaster recovery role.
- Develop a plan for periodic revisions of disaster recovery plans. Define areas that need to be analyzed, and specify evaluation criteria to determine the order of importance of systems to be replaced. Identify key decision makers that would need to be involved in the process.
- Perform an estimation of expenditure required for continuous analysis and upgrades to the system. A percentage of the annual expenditure budget could be set aside for disaster recovery upgrades purposes.
Design phase
Acceptance Test Considerations
The deploy phase will be completed when disaster recovery plan and budgets have been approved by the senior management team. All users involved in the operations of the disaster recovery system has signed off and agreed to the implementation of the backup systems for critical processes.
Key design milestones
The design phase would be successfully completed when:
- Specific applications, data and hardware linked to critical points of redundancy have been identified.
- Quotations from vendors for these specific applications, data and hardware have been obtained.
- Evaluation of these quotations has been conducted and approval from the senior management team has been obtained.
- Test plans and test scenarios have been developed and designed to enable holistic testing of critical points, including worse case scenarios. Various levels of scenarios are identified together with counter measures.
Deploy phase
Acceptance Test Considerations
The deploy phase will be completed when disaster recovery plan and budgets have been approved by the senior management team. All users involved in the operations of the disaster recovery system has signed off and agreed to the implementation of the backup systems for critical processes.
Key deployment milestones
The deploy phase would be successfully completed when:
- Disaster recovery sites fully set up and deployed within specifications listed within the design phase.
- Support services and training implemented for human backups.
- Extensive testing for effectiveness and points of weaknesses identified for improvement.
Initiative summary (150 words)
One paragraph summarizing the time and resources required to realize the capability.