【正文】 vice to be upgraded accordingly. Define Availability Requirements The availability of an IT service is a plex issue that spans many disciplines. There are many different IT approaches that can be taken to deliver the required levels of availability, each with its own cost implications. In plete contrast to this, however, availability requirements can often be expressed in relatively simplistic terms by the customer and without a full understanding of the implications. This can lead to misunderstandings between the customer and the IT anization, inappropriate levels of investment, and ultimately to customer dissatisfaction through inappropriate expectations being set. One expressed requirement for percent availability can be pletely different from another requirement for percent. One requirement may discuss the availability of the hardware platform alone, and the other may address the availability of the plete endtoend service. Even the definition of plete endtoend service availability can vary greatly, and it is important to understand exactly how any availability requirements are to be measured. For example, consider: ? If all hardware and software on the primary server are functioning correctly and user connections are ready to be accepted by the application, the solution might be considered 100 percent available. ? If there are 100 users but 25 percent are unable to connect due to a local work failure, is the solution still considered 100 percent available? ? If only one user out of the 100 is able to connect and process work, is it only 1 percent available? ? If all 100 users are able to connect but the service is degraded with only two out of three customer transactions being available, or if there is very poor performance, how does this affect availability measurements? The period over which availability is to be measured can also have significant impact on the definition of availability. A requirement for percent availability over a oneyear period allows hours of downtime. A requirement for percent availability over a rolling fourweek window only allows 40 minutes downtime in each period. The customer should define availability in his or her own terms. The availability manager should strive to educate and make sure that he or she fully understands the terminology and that the end result is realistic. Customers take more ownership for the consequences when they have been allowed to determine the measurement criteria. It is also necessary to identify and negotiate periods of downtime for planned maintenance activity, technology upgrades, and the introduction of new business functions. The amount of planned downtime that can be tolerated by the customer again has a significant impact on the definition of availability requirements. 12 A vailability Management Propose Availability Solution Now that the availability objectives for the critical business functions within an IT service have been identified and their relative importance and financial implications clearly understood, the task of designing an overall IT infrastructure that delivers the required levels of availability can begin. This overall design process is not unlike traditional development methodologies. Availability management is part of the MOF Optimizing Quadrant but often overlaps with the duties performed in the Envisioning Phase of MSF. Availability management is responsible for setting appropriate, availabilityrelated requirements and standards so that a formal project, managed through MSF, can ensure that IT services are built as required. The availability design process often involves a number of iterations between the preceding requirements definition phase and the analysis and design phase. The availability goals and budgetary constraints defined during the requirements definition phase may prove to be unachievable and need to be passed back for renegotiation with the customer. The first step in the availability design process is to identify the major IT technology ponents, infrastructure, people, and processes that underpin the plete endtoend delivery of service for each of the critical business functions and transactions to be protected. The plete life cycle of each of these ponents can then be considered in detail with a view to designing a highly available IT infrastructure and support environment. There are then two main design processes to be undertaken: designing for availability and designing for recovery. Designing for availability can be thought of as a proactive task where the focus is on keeping the IT service running and preventing service outages from occurring or reducing the impact of failures on the service being provided. Designing for recovery is predominantly a reactive task that aims to diagnose and recover service as quickly as possible if it actually fails or bees degraded in some manner. Identify Major Information Technology Service Components During the first step in the availability design process, it is useful to break down the endtoend provision of any service into manageable pieces and to examine each of these pieces in turn. MOF breaks down the overall infrastructure that makes up and supports an IT service into the following IT domains: ? Service ? Application ? Middleware ? Operating system ? Hardware ? Network ? Facilities ? Egress Service Management Function 13 Design for Availability The plete life cycle of each IT ponent identified previously can now be considered in detail, with a view to maximizing the availability that is delivered by it. The appropriateness, reliability, maintainability, and serviceability of each IT ponent can be closely examined and considered from two major perspectives: ? Availability risks and countermeasures ? Life cycle management needs Define Availabil