Part 2. Information Technology

Chapter 145. Availability Management

Section 2. Availability Management Process Description

2.145.2 Availability Management Process Description

Manual Transmittal

October 01, 2019

Purpose

(1) This transmittal revised IRM 2.145.2, Availability Management, Availability Management Process Description. This transmittal revised IRM Part 2 Chapter 146 Availability Management ,Section 1 Availability Management Policy with updated Process Description and Procedure Templates adding Internal Control Section.

Material Changes

(1) Revised the entire document with updated IPM Process Description Templates adding Internal Control Section.

Effect on Other Documents

IRM 2.145.2 dated September 29, 2014, is superseded.

Audience

The Availability Management Process is applicable to all ACIO areas with responsibility for Availability Management.

Effective Date

(10-01-2019)


Chief Information Officer

2.145.2.1 (10-01-2019)

Program Scope and Objectives

  1. Overview - This IRM is the resource guide for Availability Management which aims to define, analyze, plan, measure and improve all aspects of the availability of IT services. It is responsible for ensuring that all IT infrastructure, processes, tools, roles etc. are appropriate for the agreed availability targets.

  2. Purpose - This IRM establishes the organizational process for planning and performing the Availability Management Process to ensure that all current and future availability aspects of the IT infrastructure are provided to meet business requirements at acceptable cost. The Availability Management Process optimizes the capability of the IT Infrastructure, services, and supporting organizations to deliver a cost effective and sustained level of service availability that meets business requirements

  3. Audience - This Process is applicable to all IT organizations with responsibilities for Availability Management activities.

  4. Policy Owner - Associate Chief Information Officer (ACIO)

  5. Program Owner - Solution Engineering is responsible for the development, implementation, and maintenance, of this process. All updates are accomplished through the Director, Solution Engineering (SE). All proposed changes to this policy must be submitted to the Chief, SE Process Maturity Practice Group.

  6. Primary Stakeholders - Stakeholders include:

    • Enterprise Operations (EOPS)

    • Cyber Security (CS)

    • User and Network Services (UNS)

    • Enterprise Services (ES)

  7. Program Goals - All IT organizations responsible for Availability Management activities shall follow the Availability Management Process to ensure all activities are accomplished and all work products are produced.

2.145.2.1.1 (10-01-2019)

Background

  1. A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

2.145.2.1.1.1 (10-01-2019)
Process Description

  1. The Availability Management process translates business needs and plans into requirements for service and IT infrastructure, ensuring that the future business requirements for IT services are quantified, designed, planned, and implemented in a timely fashion.

2.145.2.1.1.2 (10-01-2019)
Goal

  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.
    This IRM provides the fundamental knowledge and procedural guidance for employees who request the Availability Management Services from Enterprise Operations or Network Services.

2.145.2.1.1.3 (10-01-2019)
Objectives

  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • Provide a standardized and institutionalized Availability Management guidelines within IRS.

2.145.2.1.2 (10-01-2019)

Authority

  1. All proposed changes to this document should be directed to the Chief, Solution Engineering Process Maturity Practice Group, owner of this Process Description (PD), and be pursued via the Availability Management process to clearly define interfaces, roles, responsibilities, and coordinate participation and collaboration between stakeholders.

2.145.2.1.3 (10-01-2019)

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Name Description
    Availability Manager

    • Primary source of management information on the Availability Management process

    • Overall responsibility for enhancing availability within dictates of sound return on availability investment decisions

    • Manages relationships between customers and Service Level Management (SLM)

    • Provision and operation of tools to support performance reporting on an ongoing basis

    • Ensure customer satisfaction with process

    • Ensure that business and stakeholders are involved in collecting availability requirements
    Service Owner

    • Deliver a particular service within the agreed service levels

    • Act as the counterpart of the Service Level Manager when negotiating Operational Level Agreements (OLAs)

    • Lead technical specialists and internal support units
    Availability Management Team Member

    • Provide technical expertise on availability of specific classes of Configuration Items (CIs)

    • Keep aware of availability characteristics of new products

    • Provide Tier III support as required in restoration of services following Major Incidents

    • On request of Problem Manager, participate as Availability Expert in Major Incident Reviews and Root Cause Analyses

    • Perform System Outage Analyses

    • Setting appropriate availability related requirements
    Business Owner

    • Negotiate availability targets and sign-off on targets in Operational and/or Service Level Agreements

    • Review availability performance against target and participate in preparation and recommendation of any remedial actions

    • Participate in Availability Improvement initiatives

    • Provide information on availability - particularly faults and outages
    IT Operations Manager

    • Provide ongoing maintenance of CIs which affects their availability

    • Assist in describing the service chains associated with service provisioning

    • Participate in discussions of availability and recoverability

    • Meet Operational objectives and explain variances from targets.
    Higher Authority

    • Approve resources to meet availability requirements

    • Review and recommend availability improvement recommendations

    • Review balanced scorecard information describing availability

    • Act as the final point of escalation for availability issues
2.145.2.1.4 (10-01-2019)

Program Management and Review

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management  
    Statement: The Availability Management process will have a single Process Owner and a separate Process Manager responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.
    People:  
    Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Availability Management will not be successful.
    Process:  
    Statement: Modifications to the Availability Management process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.
    Technology and Tools:  
    Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention.

    The tools used by this process are the following:
    None
    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.
2.145.2.1.5 (10-01-2019)

Program Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

2.145.2.1.5.1 (10-01-2019)
Controls

  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    The Availability Management Process has the following Controls:

    Name Description
    Audits The frequency of Availability management audits
    Availability Management Policy Availability Management Policy to follow to ensure all Availability Management activities are accomplished and all work products are produced.
    Scope of Availability Management Process The scope of the Availability Management process. Includes identification of what is included in and what is excluded from the Configuration Management process.
    SLA Service Level Agreement (SLA) containing the agreed Availability Management service levels.
    KISAM Knowledge Incident/Problem Service Asset Management (KISAM)
2.145.2.1.5.2 (10-01-2019)
Metrics

  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Availability Management process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

2.145.2.1.5.3 (10-01-2019)
Tailoring Guidelines

  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the Availability Management owner.
    This process may not be tailored to meet specific project requirements. If tailoring is permitted, refer to the tailored approach according to what has been documented in the Availability Management process owner’s Tailoring Plan. All tailoring requests, with supporting rationale, should be submitted in writing to and approved by Solution Engineering.

2.145.2.1.6 (10-01-2019)

Terms/Definitions/Acronyms

  1. Terms/Definitions/Acronyms

2.145.2.1.6.1 (10-01-2019)
Terms and Definitions

  1. Terms and Definitions
     

    Term Definition
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are: R Responsible for the action (may do the task) A Accountable for the action (including approval) C Required to be Consulted on the action I Required to be Informed of the action If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.
    Availability The ability of a service, component or CI to perform its agreed function when required. It is often measured and reported as a percentage.
    Availability Management Availability management addresses the ability of an IT component or service to perform at an agreed level over a period of time and support the business at a justifiable cost. The high-level activities realize availability requirements, compile an availability plan, monitor availability, and monitor maintenance obligations.
    Availability Management Information System A version controlled public repository containing all Availability Management artifacts.
    Availability Plan The Availability Plan contains detailed information about initiatives aimed at improving service and/ or component availability.
    Countermeasures Actions taken to remedy problems or incidents
    Maintainability A measure of how quickly and effectively a service, component or CI can be restored to normal working after a failure. It is measured and reported as the mean time to restore service (MTRS)
    Proactive Availability Management Involves the work necessary to ensure that new or changed services can and will deliver the agreed levels of availability and that appropriate measurements are in place to support this work. Proactive activities include planning, design and improvement of availability. These activities are principally performed as part of the design and planning roles.
    Reactive Availability Management Involves the work necessary to monitor, measure, analyze and report service and component availability. Reactive activities include the monitoring, measuring, analysis and management of all events, incidents and problems involving unavailability. These activities are principally performed as part of the operational roles.
    Reliability A measure of how long a service, component or CI can perform its agreed function without interruption. The reliability of the service can be improved by increasing the reliability of individual components or by increasing the resilience of the service to individual component failure (i.e. increasing the component redundancy, for example by using load-balancing techniques). It is often measured and reported as the mean time between service incidents (MTBSI) or mean time between failures (MTBF)
2.145.2.1.6.2 (10-01-2019)
Acronyms

  1. Acronyms

    [Identify and list the acronyms and definitions identified in this document. See example below].

    Acronyms Description
    RACI Responsible, Accountable, Consulted and Informed
    AMIS Availability Management Information System
    AM Availability Management
    CI Configuration Management
    CMMI Capability Maturity Model Integration
    CTO Chief Technology Officer
    ELC Enterprise Life Cycle
    ES Enterprise Services
    IPM Integrated Process Management
    IT Information Technology
    ITIL Information Technology Infrastructure Library
    ITSM Information Technology Service Management
    IRM Internal Revenue Manual
    ITSCM Information Technology Service Continuity Management
    OLA Operational Level Agreement
    PAL Process Asset Library
    PD Process Description
    PMI Project Management Institute
    RFC Request for Change
    SE Solution Engineering
    SLA Service Level Agreement
    SLM Service Level Management
2.145.2.1.7 (10-01-2019)

Related Resources

  1. The following resources are either referenced in this document or were used to create it:

    • ITIL V3

    • IRM (Enterprise Life Cycle Guide)

    • IRM Engineering Chapter, Availability Management Section

    • Availability Management Policy

    • IPM Process Description template

2.145.2.1.8 (10-01-2019)

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:

    • Availability Management Process

2.145.2.2 (10-01-2019)

Process Workflow

  1. A process workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

2.145.2.2.1 (10-01-2019)

Work Products Used By This Process (Inputs)

  1. The following work products are used to assist in the implementation of the Availability Management process:

    • Business Availability Requirements

    • Business Impact Analysis

    • Identified Vital Business Functions

    • Availability, Reliability & Serviceability/Maintainability Requirements

    • Incident and Problem Data

    • Configuration and Monitoring Data

    • Agreed targets for Availability, Reliability and Maintainability

2.145.2.2.2 (10-01-2019)

Work Products Produced by This Process (Outputs)

  1. The following work products (artifacts) are produced by the Availability Management process and may be used as inputs to other processes, such as:

    • IT Infrastructure Resilience and Risk Assessment

    • Measures of availability and agreed on availability targets

    • Monitoring & Reporting of Availability, Reliability and Maintainability

    • Availability Plan Updated

    • Availability Improvement Plans

    • System Recovery Strategies

    • Unavailability Analysis reports

    • Recommendations for changes to the Availability Plan

2.145.2.2.3 (10-01-2019)

Availability Management Process Flow Diagram

  1. Availability Management Process Flow Diagram

    Figure 2.145.2-1

    This is an Image: 61943001.gif
     

    Please click here for the text description of the image.

2.145.2.2.4 (10-01-2019)

Availability Management Process

  1. Process steps:

2.145.2.2.4.1 (10-01-2019)
Step 1: Plan and Design New and Changed Services

  1. Plan and Design New and Changed Services

2.145.2.2.4.1.1 (10-01-2019)
Purpose

  1. The availability management process ensures that new or changed services are designed appropriately to meet the customer’s availability related requirements, defined in service level targets. The design must be developed not only to ensure that the new or changed service will meet its availability specifications, but also to ensure that performance of existing services is not negatively impacted. The work involves producing recommendations, plans and documents on design guidelines and criteria for new and changed services. The availability requirements of the business must be clearly defined and understood so that appropriate availability and recovery design criteria can be developed.

2.145.2.2.4.1.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

2.145.2.2.4.1.3 (10-01-2019)
Entry Criteria

  1. A Request for Change for availability requirements has been received.

  2. A scheduled Availability Plan review is required.

  3. A condition has been reported requiring review of the Availability Plan.

  4. A related Service Level Agreement (SLA) review has been scheduled.

2.145.2.2.4.1.4 (10-01-2019)
Input

  1. Business Information

  2. Business Impact Information

  3. Reports and Registers

  4. Service Information

  5. Financial Information

  6. Change and Release Information

  7. Service Asset and Configuration Management

  8. Service Targets

  9. Component Information

  10. Technology Information

  11. Past Performance Information

  12. Unavailability and Failure Information

  13. Planning Information

2.145.2.2.4.1.5 (10-01-2019)
Process Activity

  1. Determine the Vital Business Information, in conjunction with the business and ITSM.

  2. Determine the availability requirements from the business for a new or enhanced IT service and formulating the availability and recovery design criteria for the supporting IT components.

  3. Define the targets for availability, reliability and maintainability for the IT infrastructure components that underpin the IT service to enable these to be documented and agreed tp by Service Level Management.

  4. Perform risk assessment and management activities to ensure the prevention and/or recovery from service and component unavailability.

  5. Design the IT services to meet the availability and recovery design criteria and associated agreed service levels.

  6. Establish measures and reporting of availability, reliability and maintainability that reflect the business, user and IT support organization perspectives.

  7. Determine the impact arising from IT service and component failure in conjunction with Information Technology Service Continuity Management (ITSCM) and, where appropriate, review the availability design criteria to provide additional resilience to prevent or minimize impact to the business.

  8. Implement cost-justifiable countermeasures, including risk reduction and recovery mechanisms.

  9. Review all new and changed services and testing all availability and resilience mechanisms.

  10. Produce and maintaining an availability plan that prioritizes and plans IT availability improvements.

  11. Review with stakeholders.

  12. Attend all related SLA reviews.

2.145.2.2.4.1.6 (10-01-2019)
Output

  1. New or changed Availability Plan

  2. Availability Design recommendations

2.145.2.2.4.1.7 (10-01-2019)
Exit Criteria

  1. Availability plan has been stored in the AMIS.

  2. Availability Design recommendations have been stored in the AMIS.

2.145.2.2.4.2 (10-01-2019)
Step 2: Risk Assessment and Management

  1. Risk Assessment and Management

2.145.2.2.4.2.1 (10-01-2019)
Purpose

  1. The purpose of the Risk Assessment and Management step is to ensure cost-justified reduction of risk and recovery from service and component availability. Risk assessment and management determines the impact arising from IT service and component failure in conjunction with ITSCM, and where appropriate, reviewing the availability design recommendations to provide additional resilience to prevent or minimize impact to the business.

2.145.2.2.4.2.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

2.145.2.2.4.2.3 (10-01-2019)
Entry Criteria

  1. Availability plan has become available.

  2. New Availability Design recommendations have become available.

  3. Recognition or notification of a change of risk or impact of a business process, IT service, or component.

2.145.2.2.4.2.4 (10-01-2019)
Input

  1. Previous risk assessment reports

  2. Availability plan

  3. Availability Design recommendations

  4. Notifications of change of risk or impact of a business process, IT service, or component

  5. Availability, Reliability & Serviceability/Maintainability Requirements

  6. Configuration and Monitoring Data

2.145.2.2.4.2.5 (10-01-2019)
Process Activity

  1. Determine the impact arising from IT service and component failure in conjunction with ITSCM.

  2. Review the availability design recommendations to provide additional resilience and prevent or minimize impact to the business.

  3. Complete the Availability Design.

2.145.2.2.4.2.6 (10-01-2019)
Output

  1. Revised risk assessment reviews and reports

  2. New or changed Availability Design

2.145.2.2.4.2.7 (10-01-2019)
Exit Criteria

  1. Revised risk assessment reviews and reports have been stored in the AMIS.

  2. New or changed Availability Design has been stored in the AMIS.

2.145.2.2.4.3 (10-01-2019)
Step 3: Implement Cost-Justifiable Countermeasures

  1. Implement Cost-Justifiable Countermeasures

2.145.2.2.4.3.1 (10-01-2019)
Purpose

  1. The purpose of the Implement Cost-Justified Countermeasures step is to produce risk reduction measures and develop effective recovery mechanisms that address the risks identified by the risk assessment review. Countermeasures are implemented as part of the overall design of the new or changed service, as well as through the implementation of maintenance and continual review and improvement.

2.145.2.2.4.3.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

2.145.2.2.4.3.3 (10-01-2019)
Entry Criteria

  1. Revised risk assessment reviews and reports have become available.

  2. New or changed Availability Design has become available.

2.145.2.2.4.3.4 (10-01-2019)
Input

  1. New or changed risk assessment reviews and reports

  2. New or changed Availability Design

  3. Planned and Preventive Maintenance Plan

  4. Unavailability Analyses

  5. Service Failure Analyses

  6. Component information

  7. Service information

  8. Technology information

2.145.2.2.4.3.5 (10-01-2019)
Process Activity

  1. Review all relevant inputs.

  2. Identify targets for countermeasures

  3. Develop cost-justifiable countermeasures, including risk reduction and recovery mechanisms.

  4. Implement cost-justifiable countermeasures, including risk reduction and recovery mechanisms.

  5. Create or change the Planned and Preventive Maintenance Plan as necessary to include new or changed countermeasures.

2.145.2.2.4.3.6 (10-01-2019)
Output

  1. Implemented countermeasures, including risk reduction and recovery mechanisms

  2. New or changed Planned and Preventive Maintenance Plan

2.145.2.2.4.3.7 (10-01-2019)
Exit Criteria

  1. Countermeasures have been implemented.

  2. New or changed Planned and Preventive Maintenance Plan has been stored in the AMIS.

2.145.2.2.4.4 (10-01-2019)
Step 4: Review All New and Changed Services and Test all Availability and Resilience Mechanisms

  1. Review All New and Changed Services and Test all Availability and Resilience Mechanisms

2.145.2.2.4.4.1 (10-01-2019)
Purpose

  1. The purpose of this step is to complete a review of all new and changed services and test all availability and resilience mechanisms. During the service transition stage all the elements designed to contribute to service and component availability needs to be reviewed and tested. Availability review and testing procedures and policies should be embedded into overall transition methods, processes and practices to ensure that the promised levels of availability will be delivered.

2.145.2.2.4.4.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

2.145.2.2.4.4.3 (10-01-2019)
Entry Criteria

  1. Notification of a new or changed service.

  2. New or changed Planned and Preventive Maintenance Plan has become available.

  3. Countermeasures have been implemented.

2.145.2.2.4.4.4 (10-01-2019)
Input

  1. Service information

  2. Planned and Preventive Maintenance Plan

2.145.2.2.4.4.5 (10-01-2019)
Process Activity

  1. Review all new and changed services.

  2. Develop a test plan to test all availability and resilience mechanisms.

  3. Develop a testing schedule for testing availability, resilience, and recovery mechanisms.

2.145.2.2.4.4.6 (10-01-2019)
Output

  1. New or changed Availability Test Plan

2.145.2.2.4.4.7 (10-01-2019)
Exit Criteria

  1. The new or changed Availability Test Plan has been stored in the AMIS and made available to the service transition team.

2.145.2.2.4.5 (10-01-2019)
Step 5: Continual Review and Improvement

  1. Continual Review and Improvement

2.145.2.2.4.5.1 (10-01-2019)
Purpose

  1. The purpose of the Continual Review and Improvement step is to continually pursue discovery of opportunities to optimize the availability of the IT infrastructure. The benefits of this regular review approach are that, sometimes, enhanced levels of availability may be achievable, but with much lower costs. The optimization approach is a sensible first step to delivering better value for money. A number of availability management techniques can be applied to identify optimization opportunities. It is recommended that the scope should not be restricted to the technology, but also include a review of both the business process and other end-to-end business owned responsibilities. To help achieve these aims, availability management needs to be recognized as a leading influence over the IT service provider organization to ensure continued focus on availability and stability of the technology.

2.145.2.2.4.5.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

  6. Higher Authority

2.145.2.2.4.5.3 (10-01-2019)
Entry Criteria

  1. Scheduled Availability Testing has been performed.

  2. New Availability Test results are available.

2.145.2.2.4.5.4 (10-01-2019)
Input

  1. New Availability Test results

  2. Availability Plan

  3. Configuration Item information

  4. Information on available technology

  5. Availability Management Reports

  6. Availability Requirements

  7. Availability Design Criteria

  8. Availability Design

  9. Availability Test Plan

  10. Planned and Preventive Maintenance Plan

2.145.2.2.4.5.5 (10-01-2019)
Process Activity

  1. Review all relevant inputs.

  2. Identify opportunities to improve availability.

  3. Update the Availability Plan to prioritize and plan improvements.

2.145.2.2.4.5.6 (10-01-2019)
Output

  1. New or updated Availability Plan

2.145.2.2.4.5.7 (10-01-2019)
Exit Criteria

  1. The new or changed Availability Plan has been stored in the AMIS.

2.145.2.2.4.6 (10-01-2019)
Step 6: Monitor and Measure Component Availability

  1. Monitor and Measure Component Availability

2.145.2.2.4.6.1 (10-01-2019)
Purpose

  1. The purpose of the Monitor and Measure Component Availability step is to detect unavailability events and SLA/OLA violations and to deliver appropriate notifications upon detection.

2.145.2.2.4.6.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

2.145.2.2.4.6.3 (10-01-2019)
Entry Criteria

  1. Availability monitoring infrastructure is operational.

  2. Monitoring of agreed availability targets against actual availability are in place.

2.145.2.2.4.6.4 (10-01-2019)
Input

  1. Availability monitoring data

  2. Current availability metrics

  3. Past performance from previous measurements, service achievements and reports

  4. Unavailability and failure information from incident and problem reports

2.145.2.2.4.6.5 (10-01-2019)
Process Activity

  1. Detect unavailability events.

  2. Store collected data in AMIS.

  3. Establish measures of availability and agree on availability targets with the business.

  4. Identify unacceptable levels of availability that impact the business and users.

  5. Monitor the actual availability delivered versus agreed targets.

2.145.2.2.4.6.6 (10-01-2019)
Output

  1. Notifications of unavailability events

  2. Monitoring data reports

  3. Monitoring, management and reporting requirements for IT services and components to ensure that deviations in availability, reliability and maintainability are detected, acted on, recorded and reported

  4. Service availability, component availability, reliability, frequency of unavailability and maintainability reports

2.145.2.2.4.6.7 (10-01-2019)
Exit Criteria

  1. Monitoring and measuring are an ongoing activity.

  2. Measures of availability and agreed on availability targets with the business have been established and stored in the AMIS.

  3. Monitoring, management and reporting requirements for IT services and components have been stored in the AMIS.

  4. Service availability, component availability, reliability, frequency of unavailability, and maintainability reports have been stored in the AMIS.

2.145.2.2.4.7 (10-01-2019)
Step 7: Investigate Service and Component Unavailability and Instigate Remedial Action

  1. Investigate Service and Component Unavailability and Instigate Remedial Action

2.145.2.2.4.7.1 (10-01-2019)
Purpose

  1. The purpose of the Investigate Service and Component Unavailability and Instigate Remedial Action step is to investigate and undertake appropriate corrective actions when services or components become unavailable based on agreed terms.

2.145.2.2.4.7.2 (10-01-2019)
Roles and Responsibilities

  1. Availability Manager

  2. Service Owner

  3. Availability Team Member

  4. Business Owner

  5. IT Operations Manager

  6. Higher Authority

2.145.2.2.4.7.3 (10-01-2019)
Entry Criteria

  1. Notification that a service or component has become unavailable.

2.145.2.2.4.7.4 (10-01-2019)
Input

  1. Unavailability and failure information

2.145.2.2.4.7.5 (10-01-2019)
Process Activity

  1. Investigate unavailability events.

  2. Implement remedial actions.

  3. Recommend changes to the Availability Plan if appropriate.

  4. Document actions taken in the AMIS.

2.145.2.2.4.7.6 (10-01-2019)
Output

  1. Unavailability Analysis and Remedial Actions report

  2. Recommendations for changes to the Availability Plan if appropriate

2.145.2.2.4.7.7 (10-01-2019)
Exit Criteria

  1. Remedial actions have been implemented.

  2. The Unavailability Analysis and Remedial Actions report has been stored in the AMIS.

  3. Recommendations for changes to the Availability Plan have been stored in the AMIS.