<<Project Name>>

Availability Plan

 

Customer Name

 

 

Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.

 

Some templates have four levels of headings.  They are not indented, but can be differentiated by font type and size:

You may elect to indent sections for readability.

 

 

 

 

 

Author

 

Author Position

 

Date

 

 

 

 

 

Version: 1.0

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ó 2002 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.

 

 

 


 

Revision & Sign-off Sheet

Change Record

Date

Author

Version

Change Reference

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reviewers

Name

Version Approved

Position

Date

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Distribution

Name

Position

 

 

 

 

 

 

 

 

 

Document Properties

Item

Details

Document Title

Availability Plan

Author

 

Creation Date

 

Last Updated

 

 


 


Table of Contents

Summary

Objectives

Current State Assessment

Existing Processes

Existing Maintenance

Existing Inventory

Existing Roles

Redundant Hardware and Software

Hardware

Commodity Hardware

Spares

Standby

Preparation

Checklist

Burn-in

Identification

Recovery Manual

Fault Tolerant Components

Storage Plan

Network Interfaces

Memory

Cooling

Power Supplies

Environmental Concerns

Backup

Software

System Integration Testing

Training

Software Deployment

Software Updates

Cluster Considerations

Load Balancing

Software Support and Monitoring

Application Isolation



 

[Introduction to the Template

 

Description: The Availability Plan describes the plans to ensure that the solution will be highly available. It addresses both the hardware and software sides of the solution. Availability is the amount of time a solution or component performs its specified function and is measured by the percentage of time the solution is in its operational state.

 

Justification: Availability is one of the key elements that organizations look for in a solution. Developing this plan increases confidence that the solution will meet the availability requirements and be stable and trustworthy in its operational environment.

 

{Team Role Primary: Release Management is responsible for this plan. They work with other team members to create the plan’s content. They are also responsible for synchronizing this plan with the solution designs.

 

Team Role Secondary: Program Management works with Release Management in assuring the plan meets the solution vision and requirements. They will also incorporate this plan into the Master Project Plan and Operations Plan.}]

 


 

Summary

[Description: Provide an overall summary of the contents of this document.

 

Justification: Some project participants may need to know only the plan’s highlights, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.]

<<Begin text here>>

 

Objectives

[Description: The Objectives section defines the objectives of the availability management process. This information should be derived from information about the current operational environment as well as business requirements and functional specifications. Objectives may be based upon the relative importance of the business functions supported by the solution and include considerations of cost, such as total cost of ownership and return on investment. Objectives may also be derived from the following considerations:

 

 

Justification: Identifying the objectives signals to the customer that Microsoft has carefully considered the present operational situation, the business requirements, and the solution and created an appropriate availability approach.]

<<Begin text here>>

 

Current State Assessment

[Description: The Current State Assessment section provides an accurate description of the current environment and its corresponding variables in which the solution will reside.

 

Justification: An accurate understanding of the current state identifies what elements are in place to support the solution’s availability processes and what new elements must be planned to ensure a complete approach to availability.]

 

Existing Processes

[Description: The Existing Processes section describes the availability processes currently in place, who performs them, and what equipment and software they use.]

<<Begin text here>>

 

Existing Maintenance

[Description: The Existing Maintenance section identifies who cares for the equipment and software, describes the maintenance processes, and identifies any tools used.]

<<Begin text here>>

 

Existing Inventory

[Description: The Existing Inventory section inventories all existing IT assets, their relationships and status that will fall within the scope of the solution.]

<<Begin text here>>

 

Existing Roles

[Description: The Existing Roles section defines the existing roles and responsibilities for the team(s) who participate in availability management.]

<<Begin text here>>

 

Redundant Hardware and Software

[Description: The Redundant Hardware and Software section describes the redundancy strategy and identifies what will be used for both hardware and software redundancy. Strategies that provide reliable systems include use of redundant hardware and software components, such as redundant arrays of independent disk (RAID) volumes, redundant power supplies, and redundant network interfaces.

 

Justification: Careful use of redundancy allows a data center or network system to tolerate failures of individual components and computers.]

<<Begin text here>>

 

Hardware

[Description: The Hardware section describes how the solution’s hardware dimension will be made available and that availability maintained.]

 

Commodity Hardware

[Description: The Commodity Hardware section describes what commodity hardware will be used for the solution.]

<<Begin text here>>

 

Spares

[Description: The Spares section inventories the spare parts that will be on hand.]

<<Begin text here>>

 

Standby

[Description: The Standby section describes the standby equipment that will be used for the solution.]

<<Begin text here>>

 

Preparation

[Description: The Preparation section describes the procedures for preparing hardware before placing it into production. Sub-sections are listed below; use those applicable and add as required.]

 

Checklist

[Description:  The Checklist section contains the checklist of steps needed to get the server up and running for production. The checklist is a complete list of all activities that need to be performed for the server to become operational.]

<<Begin text here>>

 

Burn-in

[Description: The Burn-in section describes the process of verifying that a computer is functioning properly by starting and running the computer. This is referred to as the burn-in period. Ideally, running programs designed to test and stress the performance of hardware and software components in the computer perform the burn-in.]

<<Begin text here>>

 

Identification

[Description: The Identification section describes the identification methods for the hardware components used within the solution. This should include a description of how deep into the hardware identification will occur (i.e., cards in the computer, both internally and externally).]

<<Begin text here>>

 

Recovery Manual

[Description:  The Recovery Manual section references the recovery manual(s) and describes where it will be located (both print and electronic copy).]

<<Begin text here>>

 

Fault Tolerant Components

[Description: The Fault Tolerant Components section identifies those solution hardware components that must be fault tolerant, describes their key characteristics, and describes the measures that will be taken to ensure those components stay available.]

 

Storage Plan

<<Begin text here>>

Network Interfaces

HUB/Switch, NIC and wiring

<<Begin text here>>

Routers

<<Begin text here>>

DNS/WINS

<<Begin text here>>

Domain Controller

<<Begin text here>>

Memory

<<Begin text here>>

Cooling

<<Begin text here>>

Power Supplies

<<Begin text here>>

Environmental Concerns

Temperature, Humidity, and Cleanliness

<<Begin text here>>

Power

<<Begin text here>>

Cables

<<Begin text here>>

 

Backup

[Description: The Backup section should reference the Backup and Recovery Plan. It may also summarize that plan here.]

 

Software

[Description: The Software section describes how the software dimension of the solution will be made available and how its availability will be maintained.]

 

System Integration Testing

[Description: The System Integration Testing section defines how software components will be integrated into the hardware environment and tested.]

<<Begin text here>>

 

Training

[Description: The Training section describes the training necessary to ensure that the solutions’ software availability can be maintained. This may include training for operations staff, help desk, service technicians, and crisis management teams.]

<<Begin text here>>

 

Software Deployment

[Description: The Software Deployment section describes how software will be deployed within the solution. Several sub-sections are listed below; use those appropriate and add where required.]

Software Updates

<<Begin text here>>

Certification Process

<<Begin text here>>

Cluster Considerations

<<Begin text here>>

Load Balancing

<<Begin text here>>

 

Software Support and Monitoring

[Description: The Software Support and Monitoring section should reference the Support Plan and the Monitoring Plan. You may also include a summary of key elements of those plans in this section.]

<<Begin text here>>

 

Application Isolation

[Description: The Application Isolation section describes the process used to isolation an application.]

<<Begin text here>>