Business Capacity Management

The business capacity management subprocess is concerned with understanding the business plans and the implications of these on the IT infrastructure. This enables the necessary changes such as storage upgrades to be planned and implemented in time for the required capacity to be available when the business requires it. Capacity management will use existing utilization data for the current services and resources and extrapolate trends to predict future requirements. In addition, capacity management will plan the required capacity for new services due to come on-stream through the service strategy and service portfolio processes.

The capacity requirements are subject to change as the business changes. Business changes may require new services or changes to existing services or generate increased demand for those services. Some services will no longer be required, and this will free up spare capacity. These new requirements are identified by demand management, which analyzes patterns of business activity to understand how these patterns generate demand patterns for IT service. This information enables proactive capacity management to predict and satisfy future requirements.

Capacity management needs to be included in all strategic, planning, and design activities as early as possible if the services are going to be able to meet the level of demand and the performance targets set in the service level agreements. The process will model the capacity requirements for a number of different scenarios in order to understand the impact on capacity requirements. For example, such scenarios might include the impact of fewer or greater numbers of concurrent users than the original prediction.

Once the capacity requirements are understood, capacity management will recommend procurement of new capacity, if required, or other measures taken as necessary. It will also ensure that the actions taken are implemented through the change management process. It will also advise service level management what SLA performance targets are achievable.

Service Capacity Management

The service capacity management subprocess focuses on the management, control, and prediction of the end-to-end performance and capacity of the live, operational IT services usage and workloads. It ensures that the performance of all services, as detailed in service targets within SLAs and SLRs, is monitored and measured, and that the collected data is recorded, analyzed, and reported. Wherever necessary, proactive and reactive action should be instigated to ensure that the performance of all services meets their agreed-on business targets. Wherever possible, automated thresholds should be used to manage all operational services to ensure that situations where service targets are breached or threatened are rapidly identified. Service capacity management will monitor the workload to ensure that they do not exceed any specified limitations.

Service capacity management monitors changes in performance levels and assesses the impact of changes so that most issues can be predicted and acted on before the service is impacted.

Component Capacity Management

The component capacity management subprocess focuses on the management, control, and prediction of the performance, utilization, and capacity of individual IT technology components such as processors, memory, disks, network bandwidth, and network connections. It ensures that all components within the IT infrastructure that have finite resources are monitored and measured, and that the collected data is recorded, analyzed, and reported. Wherever possible, automated thresholds should be implemented to manage all components through the event management process to ensure that situations where service targets are breached or threatened by component usage or performance are rapidly identified, and cost-effective actions, such as load-balancing, are implemented to reduce or avoid their potential impact.

Capacity Management Tools

It is important to ensure that the tools used by capacity management conform to the organization’s management architecture as well as integrate with other tools used for the management of IT systems and automation of IT processes.

Service operation monitoring and control activities provide a basis for the tools to support capacity management. The IT operations management function and the technical management departments (such as network management and server management) may carry out the bulk of the day-to-day operational duties. They will participate in the capacity management process by providing it with performance information.

Reactive and Proactive Activities

Capacity management has both reactive and proactive activities (as has availability management, which we will examine later in this chapter). In Figure 8.2, you can see the activities relating to both reactive and proactive capacity management and the interaction between the subprocesses.

Capacity management should include the following proactive activities:

• Preempting performance issues by taking the necessary actions before the issues occur
• Producing trends of the current component utilization and using them to estimate the future requirements and for planning upgrades and enhancements
• Modeling and trending the predicted changes in IT services (including service retirements)
• Ensuring that upgrades are budgeted, planned, and implemented before SLAs and service targets are breached or performance issues occur
• Actively seeking to improve service performance wherever the cost is justifiable
• Producing and maintaining a capacity plan addressing future requirements and plans for meeting them
• Tuning (also known as optimizing) the performance of services and components

Capacity management should include the following reactive activities:

• Monitoring, measuring, reporting, and reviewing the current performance of both services and components
• Responding to all capacity-related “threshold” events and instigating corrective action
• Reacting to and assisting with specific performance issues

Ongoing Activities

A number of ongoing activities form part of the capacity management process. These activities provide the basic historical information and triggers necessary for all the other activities and processes within capacity management (see Figure 8.3).

Each service, and all of its components, should be monitored, and compared against defined thresholds, to spot trends and identify potential issues. This enables the necessary action to be taken. Recommendations can also be made for the purchase of new capacity or the adoption of new technology.

Typical monitored data includes the following:

• Processor utilization
• Memory utilization
• I/O rates (physical and buffer) and device utilization
• Queue lengths
• Disk utilization
• Transaction rates
• Response times
• Batch duration
• Database usage
• Index usage
• Hit rates
• Concurrent user numbers
• Network traffic rates

Thresholds should be based on historical analysis of normal activity and set below the level at which the service is impacted to allow time for corrective action. If the thresholds are exceeded, alarms should be raised and exception reports produced.

The ongoing activities may include balancing services, balancing workloads, changing concurrency levels, and adding or removing resources. The monitoring reports and information about the actions recommended and taken are stored in the capacity management information system (CMIS).

Triggers

Many triggers will initiate capacity management activities:

• New and changed services requiring additional capacity
• Service breaches, capacity or performance events, and alerts, including threshold events
• Exception reports
• Periodic revision of current capacity and performance and the review of forecasts, reports, and plans
• Periodic trending and modeling
• Review and revision of business and IT plans and strategies
• Review and revision of designs and strategies
• Review and revision of SLAs, operational level agreements, contracts, or any other agreements
• Requests from service level management for assistance with capacity and/or performance targets and explanation of achievements

Inputs

A number of sources of information are relevant to the capacity management process:

• Business information
• Service and IT information
• Component performance and capacity information
• Service performance issue information
• Service information
• Financial information
• Change information
• Performance information
• CMS
• Workload information

Outputs

The outputs of capacity management are used within the process itself as well as by many other processes and other parts of the organization. The information is often reproduced in an electronic format as visual real-time displays of performance. The outputs are as follows:

• The capacity management information system
• The capacity plan
• Service performance information and reports
• Workload analysis and reports
• Ad hoc capacity and performance reports
• Forecasts and predictive reports
• Thresholds, alerts, and events
• Improvement actions

Interfaces

As we have already explained, capacity management has strong connections across the service lifecycle with a number of other processes. For example, all changes to service and resource capacity must follow all IT processes such as change, release, configuration, and project management.

The key interfaces are as follows:

• Availability management works with capacity management to determine the resources needed to ensure the required availability of services and components.
• Service level management provides assistance with determining capacity targets and the investigation and resolution of breaches related to service and component capacity.
• IT service continuity management is supported by capacity management through the assessment of business impact and risk, determining the capacity needed to support risk reduction measures and recovery options.
• Capacity management provides assistance with incident and problem management for the resolution and correction of capacity-related incidents and problems.
• By anticipating the demand for services based on user profiles and patterns of business activity, and by identifying the means to influence that demand, demand management provides strategic decision making and critical related data on which capacity management can act.

Component-Based Reports

There is likely to be a team of technical staff responsible for each component, and they should be in charge of their control and management. Reports must be produced to illustrate how components are performing and how much of their maximum capacity is being used.

Service-Based Reports

Service-based reports will provide the basis of SLM and customer service reports. Reports and information must be produced to illustrate how the service and its constituent components are performing with respect to their overall service targets and constraints.

Exception Reports

Exception reports can be used to show management and technical staff when the capacity and performance of a particular component or service becomes unacceptable. Thresholds can be set for any component, service, or measurement within the CMIS. An example threshold may be that processor utilization for a particular server has breached 70 percent for three consecutive hours or that the concurrent number of logged-in users exceeds the specified limit.

In particular, exception reports are of interest to the SLM process in determining whether the targets in SLAs have been breached. Also, the incident and problem management processes may be able to use the exception reports in the resolution of incidents and problems; for example, slow response may be traced to lack of capacity. Excess capacity should also be identified. Unused capacity may represent an opportunity for cost savings.

Predictive and Forecast Reports

Part of the capacity management process is to predict future workloads and growth. To do this, future component and service capacity and performance must be forecast. This can be done in a variety of ways, depending on the techniques and the technology used. A simple example of a capacity forecast is a correlation between a business driver and component utilization. If the forecasts on future capacity requirements identify a requirement for increased resource, this requirement needs to be input into the capacity plan and included within the IT budget cycle.

Capacity Management Process Owner

The capacity management process owner’s responsibilities typically include the following:

• Carrying out the generic process owner role for the capacity management process (see Chapter 1 for more detail)
• Working with managers of all functions to ensure acceptance of the capacity management process as the single point of coordination for all capacity- and performance-related issues, regardless of the specific technology involved
• Working with other process owners to ensure an integrated approach to the design and implementation of capacity management, availability management, IT service continuity management, and information security management

Capacity Management Process Manager

The capacity management process manager’s responsibilities typically include the following:

• Carrying out the generic process manager role for the capacity management process (see Chapter 1 for more detail)
• Coordinating interfaces between capacity management and other processes, especially service level management, availability management, IT service continuity management, and information security management
• Ensuring adequate IT capacity to meet required levels of service
• Providing advice on matching capacity and demand and on optimizing the use of existing capacity
• Working with SLM to ascertain capacity requirements from the business
• Understanding the current usage and the maximum capacity of each component
• Modeling and sizing all proposed new services and systems
• Forecasting future capacity requirements
• Producing, reviewing, and revising the capacity plan, in line with the organization’s business planning cycle
• Setting appropriate levels of monitoring of resources and systems
• Analyzing usage and performance data, and reporting on performance against targets contained in SLAs
• Raising incidents and problems when breaches of capacity or performance thresholds are detected, and assisting with the investigation and diagnosis of capacity-related incidents and problems
• Performing tuning to optimize and improve capacity or performance
• Implementing initiatives to improve resource usage—for example, demand management techniques
• Assessing new technology to improve performance and new techniques and products that could be used to improve the process
• Assessing all changes for their impact on capacity and performance and attending CAB meetings when appropriate
• Reporting on current usage of resources, trends and forecasts, and performance against targets contained in SLAs
• Testing performance of new services and systems
• Predicting the effects of future demand on performance service levels
• Determining achievable performance service levels that are cost-justified
• Acting as a focal point for all capacity and performance issues

Availability Concepts

Availability management comprises both reactive and proactive activities, as shown in Figure 8.4. The reactive activities include regular monitoring of service provisions involving extensive data gathering and reporting of the performance of individual components and processes and the availability delivered by them. Event management is often used to monitor components because this speeds up the identification of any issues through the setting of alert thresholds. It may even be possible to restart the failing service automatically, possibly before the break has been noticed by the customers. Instances of downtime are investigated, and remedial actions are taken to prevent a recurrence. The proactive activities include identifying and managing risks to the availability of the service and implementing measures to protect against such an occurrence. Where protective measures have been put in place to provide resilience in the event of component failure, the measures require regular testing to ensure that they work as designed to protect the service availability. All new or changed services should be subject to continual service improvement; countermeasures should be implemented wherever they can be cost justified. This cost justification requires an understanding of the vital business functions and the cost to the business of any downtime. It is ultimately a business decision, not a technical decision. Figure 8.4 also shows the availability management information system (AMIS); this is the repository for all availability management reports, plans, risk registers, and so on, and it forms part of the service knowledge management system (SKMS).

Reliability

The first availability concept we cover is reliability. This is defined by ITIL as “a measure of how long a service, component, or CI can perform its agreed function without interruption.” We normally describe how reliable an item is by stating how frequently it can be expected to break down within a given time: “My car is very reliable. It has broken down only twice in five years.” We measure reliability by calculating the mean (or average) time between failures (MTBF) or the mean (or average) time between service incidents (MTBSI).

Reliability of a service can be improved first by ensuring that the components specified in the design are of good quality and from a supplier with a good reputation. Even the best components will fail eventually; however, the reliability of the service can be improved by designing the service so that a component failure does not result in downtime. This is another availability concept called resilience. By ensuring that the design includes alternate network routes, for example, a network component failure will not lead to service downtime because the traffic will reroute. Carrying out planned maintenance to ensure that all the components are kept in good working order will also help improve reliability.

Maintainability

However reliable the equipment and resilient the design, not all downtime can be prevented. When a fault occurs and there is insufficient resilience in the design to prevent it from affecting the service, the length of the downtime that results can be affected by how quickly the fault can be overcome. This is called maintainability and is measured as the mean time to restore service (MTRS). It may be more cost-effective to concentrate on resilience measures for those items that have a long service restoration time. To calculate MTRS, divide the total downtime by the total number of failures.

Simple measures can be taken to reduce MTRS, such as having common spares available on site, and these measures can have a significant impact on availability.

ITIL recommends the use of MTRS rather than mean time to repair (MTTR) because repair may or may not include the restoration of the service following the repair. From the customer perspective, downtime includes all the time between the fault occurring and the service being fully usable again. MTRS measures this complete time and is therefore a more meaningful measurement.

These concepts are illustrated in Figure 8.5, which shows what ITIL calls the expanded incident lifecycle. This illustrates periods of uptime with incidents causing periods of downtime. MTRS is shown as the average of the downtime for the incident. MTBF is shown as the average of the uptime for the incident.

Each incident needs to be detected, diagnosed, and repaired, and the data needs to be recovered and the service restored. Any method of shortening any of these steps—speeding up detection through event management or speeding up diagnosis by the use of a knowledge base, for example—will shorten the downtime and improve availability. The figure also shows another concept: MTBSI, which calculates the average time from the start of one incident to the start of the next and is used as a measure of reliability.

Serviceability

Serviceability is defined as the ability of a third-party supplier to meet the terms of its contract. This contract will include agreed levels of availability, reliability, and/or maintainability for a supporting service or component.

In Figure 8.6, you can see the terms and measures used in availability management, which are combined when applied to suppliers providing serviceability.

Measurement of Availability

The term vital business function (VBF) is used to reflect the part of a business process that is critical to the success of the business. The more vital the business function generally, the greater the level of resilience and availability that needs to be incorporated into the design of the supporting IT services. The availability requirements for all services, vital or not, should be determined by the business and not by IT.

Certain vital business functions may need special designs. These commonly include the following functions:

High Availability A characteristic of the IT service that minimizes or masks the effects of IT component failure to the users of a service.

Fault Tolerance The ability of an IT service, component, or configuration item to continue to operate correctly after failure of a component part.

Continuous Operation An approach or design to eliminate planned downtime of an IT service. Individual components or configuration items may be down even though the IT service remains available.

Continuous Availability An approach or design to achieve 100 percent availability. A continuously available IT service has no planned or unplanned downtime.

Within the IT industry, many suppliers commit to high availability or continuous availability solutions but only if specific environmental standards and resilient processes are used. They often agree to such contracts only after additional, sometimes costly, improvements have been made.

The availability management process depends heavily on the measurement of service and component achievements with regard to availability.

The decision on what to measure and how to report it depends on which activity is being supported, who the recipients are, and how the information is to be used. It is important to recognize the differing perspectives of availability from the business, users, and service providers to ensure that measurement and reporting satisfies these varied needs.

The business perspective considers IT service availability in terms of its contribution or impact on the vital business functions that drive the business operation.

The user perspective considers IT service availability as a combination of three factors. These are the frequency, the duration, and the scope of impact. For many applications, poor response times for the user are considered at the same level as failures of technology.

The IT service provider perspective considers IT service and component availability with regard to availability, reliability, and maintainability.

It is important to consider the full scope of measures needed to report the same level of availability in different ways to satisfy the differing perspectives of availability. Measurements need to be meaningful and add value. This is influenced strongly by the combination of “what you measure” and “how you report it.”

Expanded Incident Lifecycle

We looked at the expanded incident lifecycle briefly earlier, in Figure 8.5, when considering availability concepts. This technique requires the analysis of the lifecycle of an incident from start to finish and the period between an incident and the next outage. Outages may not always be preventable; the availability management process seeks not only to avoid downtime, but also to minimize its duration and impact when it does occur. The duration of the downtime can be reduced by analyzing how long each step in the process takes, and then exploiting any opportunities to shorten that stage. Let’s look at each of the incident stages in turn:

Incident Detection This is time that elapses between the incident occurring and the IT service provider becoming aware of the failure. Event management tools can be very helpful in this regard, sending notification of failure, possibly before the users have become aware themselves. This enables the fault to be addressed quickly, thus reducing downtime and improving availability. Tools may have the capability to diagnose the fault and to automatically recover the service. Further information about event management is covered in Chapter 3, “Event Management, Request Fulfillment, and Access Management.”

Incident Diagnosis This is the time by which the cause of the fault has been identified. Faster diagnosis will reduce downtime and increase availability. Again, some monitoring tools can assist in gathering the necessary diagnostic data to help in problem resolution. This may occasionally delay the resolution of service, but it will enable the root cause of repeated failures to be identified and removed, thus reducing the overall downtime.

Incident Repair This is the time at which the repair has been implemented. This may be impacted by the design of the component, so care should be taken in the service design stage to choose components that can be repaired quickly. It may also be impacted by the performance of internal teams or suppliers responsible for carrying out the repair actions. The relevant operational level agreements and underpinning contracts should be monitored by service level management and supplier management for breaches and service improvement plans put in place to prevent such breaches in the future.

Incident Recovery This is the time at which component recovery has been completed. The backup and recovery requirements for the hardware, software, and data components should be identified as early as possible within the design cycle to enable appropriate recovery plans to be drawn up and tested. Wherever possible, recovery actions should be automated. Availability requirements should also contribute to determining what spare parts are kept within the definitive spares area. We discuss the storage of definitive spares in Chapter 12, “Change Management and Service Asset and Configuration Management,” which describes a storage area set aside for the secure storage of spare components and assemblies that are maintained at the same revision level as the systems within the controlled test or live environment; these are used for testing new services in the transition stage and to replace faulty equipment in the operation stage.

Incident Restoration This is the time at which normal business service is resumed. It is important that the ability to work normally is verified before the incident is closed. This may be verified by the service desk by talking to the service users. If the service is one used by the public, such as an ATM or web commerce site, visual checks of transaction throughput or user simulation scripts that validate the end-to-end service may be necessary.

By looking at each stage of the expanded incident lifecycle, we can identify delays and take action to reduce them in the future. For example, a downtime of an hour but with a repair action time of 5 minutes will identify delays such as time wasted before the fault was identified due to poorly configured event management tools, overlong diagnosis time, lack of skills, lack of documentation, and so forth. Availability management needs to work in close association with incident and problem management to ensure that repeat occurrences are eliminated.

Fault Tree Analysis

This approach uses Boolean logic, using AND and OR statements, to analyze the sequence of events that lead to a failure. These events may be characterized as basic, resulting, conditional, or trigger events. The AND statement means all the input events must occur simultaneously for the resultant event to take place (for example, when both the primary and fail-over lines must be down for the network to be down). OR is when the event occurs if any of the input events occurs. There is also an INHIBIT statement when the resulting event occurs only when the input condition is not met. Figure 8.7 gives an example of a fault tree and these statements.

In Figure 8.7, the service is down if the network or the server or the application is down (an example of the OR statement). The network is down if both the primary and failover lines are down (an example of the AND statement). Finally the service would not be considered down if the fault(s) occurred outside service hours (an example of the INHIBIT statement).

Component Failure Impact Analysis

Component failure impact analysis (CFIA) is a technique that considers the importance of an individual component to the provision of service. It enables the impact on services of a failing component to be predicted, in particular any single points of failure (SPOFs). This, in turn, will indicate where resilience or risk reduction measures are required to protect availability. Combined with other techniques, this approach can provide useful information for the design of future services.

CFIA is a relatively simple technique that can be used to analyze all aspects of the IT infrastructure and applications, such as hardware, network, software, applications, data centers, and support staff. Additionally, it can identify impact and dependencies on IT support organization skills and staff competencies.

The technique involves identifying which elements of the IT infrastructure configuration are to be assessed, and then creating a grid with CIs on one axis and the IT services that have a dependency on the CI on the other, as shown in Figure 8.8.

The next step is to perform the CFIA and populate the grid for each component with a blank where the failure of the CI does not impact the service, an “X” when the failure of the CI would bring down the service, an “A” when there is an alternative CI to provide the service, and an “M” when there is an alternative CI but it requires manual intervention to recover the service.

The completed grid will highlight the critical CIs. Actions can then be taken to provide resilience and protect availability.

Service Failure Analysis

Service failure analysis is used as a structured approach to the analysis of an interruption. Each time an interruption takes place, full analysis is undertaken as an assignment or project to identify a preventive action. It takes a holistic view looking for improvements in technology, the IT support organization, processes, procedures, and tools. Many of its activities are closely aligned with those of problem management. Both processes aim to identify root causes and encourage cross-functional teamwork, lateral thinking, and innovative, and often inexpensive, solutions.

SFIA should use a structured approach, as shown in Figure 8.9.

The report should categorize the recommendations under the following headings:

Detection Actions to enable better event reporting to ensure that underlying IT service issues are detected early to enable a proactive response

Reduction Actions to minimize the user impact from IT service interruption, possibly by reducing the duration of the impact

Avoidance Actions to eliminate this particular cause of IT service interruption

Risk Analysis and Management

Risk analysis and management provides an analysis of the likelihood of business impact relating to availability risks (the likelihood of something happening). Business impact analysis and the identification of the potential impact of the business are vital parts of risk management. Identification of mitigation against risk is a key component of the design of services. Further information regarding techniques for risk management can be found in the relevant ISO standards, and other best practice frameworks such as the management of risk framework. One common approach to risk assessment is one described in ISO standard 31000. This assessment approach consists of three steps:

• Risk identification creates a comprehensive list of risks that could impact the service.
• Risk analysis involves developing a full understanding of the risks.
• Risk evaluation decides which risks require action and the relative priorities among them.

Possible actions to address the risks may include the following:

• Avoiding the risk by deciding not to start or continue with the risky activity
• Deciding to take the risk in order to benefit from an opportunity
• Removing the risk
• Taking action to make the risk less likely to occur
• Lessening the impact of failure

Triggers

Many events may trigger availability management activity, including the following:

• New or changed business needs or new or changed services
• New or changed targets within agreements, such as service level requirements, service level agreements, operational level agreements, and contracts
• Service or component breaches, availability events, and alerts, including threshold events and exception reports
• Periodic activities such as reviewing, revising, or reporting against services
• Review of availability management forecasts, reports, and plans
• Review and revision of business and IT plans and strategies
• Review and revision of designs and strategies
• Recognition or notification of a change of risk or impact of a business process, a vital business function, an IT service, or a component
• Request from service level management for assistance with availability targets and explanation of achievements

Inputs

A number of sources of information are relevant as inputs to the availability management process. Some of these are as follows:

• Business information from the organization’s business strategy, plans, and financial plans and information on its current and future requirements, including the availability requirements for new or enhanced IT services
• Service information from the service level management process, with details of the services from the service portfolio and the service catalog; from service level targets within service level agreements and service level requirements; and possibly from the monitoring of SLAs, service reviews, and breaches of the SLAs
• Financial information from financial management for IT services, the cost of service provision, and the cost of resources and components
• Change and release information from the change management process with a change schedule, the release schedule from release and deployment management, and an assessment of all changes for their impact on service availability
• Service asset and configuration management containing information on the relationships between the business, the services, the supporting services, and the technology
• Component information on the availability, reliability, and maintainability requirements for the technology components that underpin IT service(s)
• Technology information from the configuration management system
• Past performance from previous measurements, achievements, reports, and the availability management information system (AMIS)
• Unavailability and failure information from incidents and problems

Outputs

Availability management produces the following outputs:

• The availability management information system (AMIS)
• The availability plan for the proactive improvement of IT services and technology
• Availability and recovery design criteria and proposed service targets for new or changed services
• Service availability, reliability, and maintainability reports of achievements against targets, including input for all service reports
• Component availability, reliability, and maintainability reports of achievements against targets
• Revised risk assessment reviews and reports and an updated risk register
• Monitoring, management, and reporting requirements for IT services and components
• An availability management test schedule for testing all availability, resilience, and recovery mechanisms
• The planned and preventive maintenance schedules
• Contributions for the projected service outage (PSO) document to be created by change management in collaboration with release and deployment management
• Details of the proactive availability techniques and measures that will be deployed
• Improvement actions for inclusion within the service improvement plan

Availability Management Interfaces

As you would expect for this process, there are a number of interfaces across the lifecycle. In fact, availability management can be linked to the majority of the service management processes. However, the key interfaces that availability management has with other processes are as follows:

Service Level Management This process relies on availability management to determine and validate availability targets and to investigate and resolve service and component breaches. It links to both the reactive and proactive elements of availability management.

Incident and Problem Management As you have seen from the techniques used in availability measurement and management, these processes are assisted by availability management in the resolution of incidents and problems.

Capacity Management This provides appropriate capacity to support resilience and overall service availability. Strong connections exist between the availability of a service and the capacity of the service. Patterns of business activity and user profiles are used to understand business demand for IT for business-aligned availability planning.

Change Management As a result of investigations into outages, or improvements required by the business, change management supports the management of changes. This in turn is used in the creation of the projected service outage (PSO) document to project the availability-related issues during a change, with contributions from availability management.

IT Service Continuity Management Availability management works collaboratively with this process on the assessment of business impact and risk and the provision of resilience, fail-over, and recovery mechanisms. A continuity invocation is the result of an availability management issue that cannot be resolved within the agreed time frames without additional resources as described in the recovery plan.

Information Security Management Put simply, if the data becomes unavailable, the service becomes unavailable. Information security management defines the security measures and policies that must be included in the service design for availability and the design for recovery.

Access Management Availability management provides the methods for appropriately granting and revoking access to services as needed. This should be carefully monitored because unauthorized or uncontrolled access can be a significant risk to service availability.

Availability Management Process Owner

The availability management process owner’s responsibilities typically include the following:

• Carrying out the generic process owner role for the availability management process (see Chapter 1 for more detail)
• Working with other managers to ensure acceptance of the availability management process as the single point of coordination for all availability-related issues, regardless of the specific technology involved
• Working with other process owners to ensure an integrated approach to the design and implementation of availability management, service level management, capacity management, IT service continuity management, and information security management

Availability Management Process Manager

The availability management process manager’s responsibilities typically include the following:

• Carrying out the generic process manager role for the capacity management process (see Chapter 1 for more detail)
• Coordinating interfaces between availability management and other processes, especially service level management, capacity management, IT service continuity management, and information security management
• Ensuring that all existing and new services deliver the levels of availability agreed to by the business in SLAs
• Validating that the final design meets the minimum specified levels of availability
• Assisting with the investigation and diagnosis of all incidents and problems that cause availability issues or unavailability of services or components
• Participating in the IT infrastructure design, including specifying the availability requirements for hardware and software
• Specifying the requirements for new or enhanced event management systems for automatic monitoring of availability of IT components
• Specifying the reliability, maintainability, and serviceability requirements for components supplied by internal and external suppliers
• Monitoring and reporting actual IT availability achieved against SLA targets to ensure that agreed levels of availability, reliability, and maintainability are measured and monitored on an ongoing basis
• Proactively improving service availability wherever possible, and optimizing the availability of the IT infrastructure to deliver cost-effective improvements that deliver tangible benefits to the business
• Creating, maintaining, and regularly reviewing an availability management information system and a forward-looking availability plan aimed at improving the overall availability of IT services and infrastructure components, to ensure that existing and future business availability requirements can be met
• Ensuring that the availability management process, as well as its associated techniques and methods, are regularly reviewed and audited, and that all of these are subject to continual improvement and remain fit for purpose
• Creating availability and recovery design criteria to be applied to new or enhanced infrastructure design
• Working with financial management for IT services, ensuring that the levels of IT availability required are cost-justified
• Maintaining and completing an availability testing schedule for all availability mechanisms, ensuring that all availability tests and plans are tested after every major business change
• Assisting security and IT service continuity management with the assessment and management of risk
• Assessing changes for their impact on all aspects of availability, including overall service availability and the availability plan (this includes attending CAB meetings when appropriate)

Challenges

The main challenge is to meet and manage the expectations of the customers and the business. The service levels should be publicized to all customers and areas of the business so that when services do fail, the expectation for their recovery is at the right level. It also means that availability management must have access to the right level of quality information on the current business need for IT services and its plans for the future.

Another challenge facing availability management is the integration of all of the availability data into an integrated set of information (AMIS). This can be analyzed in a consistent manner to provide details on the availability of all services and components. This is particularly challenging when the information from the different technologies is provided by different tools in different formats, which often happens.

Yet another challenge facing availability management is the investment needed in proactive availability measures. Availability management should work closely with ITSCM, information security management, and capacity management in producing the justifications necessary to secure the appropriate investment.

Risks

The following major risks are among those associated with availability management:

• A lack of commitment from the business to the availability management process
• A lack of appropriate information on future plans and strategies from the business
• A lack of senior management commitment to or a lack of resources and/or budget for the availability management process
• Labor-intensive reporting processes
• Processes that focus too much on the technology and not enough on the services and the needs of the business

Another risk is evident when the availability management information system is maintained in isolation and is not shared or consistent with other process areas, especially ITSCM, information security management, and capacity management. This interaction is particularly important when considering the necessary service and component backup and recovery tools, technology, and processes to meet the specified needs.

Process Activities

A key activity within the information security management process is the production and maintenance of an overall information security policy and a set of supporting specific policies. The process is also responsible for the communication, implementation, and enforcement of the security policies, including the provision of advice and guidance to all other areas of the business and IT on all issues related to information security.

Information security management is also responsible for the assessment and classification of all information assets and documentation. The process covers the implementation, review, revision, and improvement of a set of security controls as well as risk assessment and responses, including assessment of the impact of all changes on information security policies, controls, and measures. Where possible, if it is in the business’s interest and the cost is justifiable, the process should implement proactive measures to improve information security.

Monitoring and management of all security breaches and major security incidents is a key part of the information security management process. This includes the analysis, reporting, and reduction of the volume and impact of security breaches and incidents.

The process is also responsible for scheduling and completing security reviews, audits, and penetration tests. The outputs from the process will be captured and recorded in the security management information system.

Security Strategy

The information security management process, together with the procedures, methods, tools and techniques, constitute the security strategy. It is the responsibility of the security manager to ensure that technologies, products, and services are in place, together with the published security policy. The security manager is also responsible for security architecture, authentication, authorization, administration, and recovery.

A key challenge for information security is to embed good security practices into every area of the business. Ensuring secure behavior depends on training and awareness. Security practices need to be easy to follow, if they are to be accepted. As technology changes, whether it is the trend toward bring your own device (BYOD) or computing in the cloud, new security challenges emerge. Information security management must understand these challenges and prepare to meet them.

Security Controls

Information security must be considered as an integral part of all services and systems. It needs to be continuously managed using a set of security controls that enforce the policy and minimize threats. These controls should be considered during the design of new services or changes to existing services; this is much easier and more cost effective than trying to apply them later when the service is live. Once the controls are in place, the day-to-day activities required will usually be carried out by access management. This process is covered in Chapter 3.

Security measures can be used at a specific stage in the prevention and handling of security incidents, as illustrated in Figure 8.12. The majority of such incidents are not technical threats, such as deliberate denial-of-service attacks or attempts to hack into the systems. Most breaches are the result of human errors and may even be accidental; they may involve other threats such as safety, legal, or health.

A threat can be anything that disrupts business processes or has negative impact on the business. First there is a risk of a threat actually occurring. Should this happen, it is termed a security incident. This may result in damage (to information or to assets) that has to be repaired or otherwise corrected. Each of these stages requires the appropriate measures to be taken. The choice of measures will depend on the importance attached to the information. These measures should all be documented in the information security management system. They include the following types:

Preventive These security measures aim to prevent a security incident from occurring. An example of this type of measure is restricting access rights to a limited group of authorized people. This requires procedures to control access rights (granting, maintenance, and withdrawal of rights), authorization (identifying who is allowed access to which information and using which tools), identification and authentication (confirming who is seeking access), and access control (ensuring that only authorized personnel can gain access).

Reductive These measures reduce the potential damage of a security breach. One example is ensuring that regular backups are taken in case of any data loss. Ensuring that tested contingency plans are in place is another reductive measure.

Detective It is essential that any security breach is detected quickly; detective measures are concerned with discovering breaches as soon as possible. One example is the use of monitoring tools, linked to an alert procedure. Another example is virus-checking software, which will detect and virus infection.

Repressive These security measures counteract any continuation or repetition of the security incident. One example is when an account or network address is temporarily blocked after numerous failed attempts to log on or when a card is retained when multiple attempts are made with a wrong PIN.

Corrective These measures seek to repair any damage caused. Examples include restoring the backup, or backing out/rolling back to a previous stable situation.

Management of Security Breaches and Incidents

Whenever a serious security breach or incident occurs, it must be handled at the time, but also reviewed afterward to determine what went wrong, what caused it, and how it can be prevented in the future. This evaluation should not be restricted to serious security incidents, however; all breaches of security and security incidents need to be studied to understand the effectiveness or otherwise of the security measures as a whole. Every security incident must be logged as such to enable reporting and analysis. This analysis will also require other evidence, such as log files and audit files, in addition to the security incident record. Information security management should work with problem management to identify the root cause of these incidents and to take the required improvement actions to overcome weaknesses and prevent such incidents from recurring.

Triggers

Information security management activity can be triggered by many events, including these:

• Changes in statutory or regulatory requirements
• New or changed corporate governance guidelines
• New or changed business security policy
• New or changed corporate risk management processes and guidelines
• New or changed business needs and new or changed services
• New or changed requirements within agreements, such as service level requirements, service level agreements, operational level agreements, and contracts
• Review and revision of business and IT plans and strategies
• Review and revision of designs and strategies
• Service or component security breaches or warnings, events, and alerts, including threshold events and exception reports
• Periodic activities such as reviewing, revising, and reporting, including reviewing and revising information security management policies, reports, and plans
• Recognition or notification of a change of risk or impact of a business process or vital business functions, an IT service, or a component
• Requests from other areas, particularly service level management, for assistance with security issues

Inputs

Information security management will need to obtain input from many areas:

• Business information from the organization’s business strategy, plans and financial plans, and information on its current and future requirements
• Governance and security from corporate governance and business security policies and guidelines, security plans, and risk assessment and responses
• IT information from the IT strategy, plans, and current budgets
• Service information from the SLM process with details of the services from the service portfolio
• Risk assessment processes and reports from ISM, availability management, and ITSCM
• Details of all security events and breaches—from all areas of IT and IT service management, especially incident management and problem management
• Change information from the change management process
• The configuration management system containing information on the relationships between the business, the services, supporting services, and the technology
• Details of partner and supplier external access to services and systems from supplier management and availability management

Outputs

The following outputs are produced by the information security management process and used in all areas:

• An overall information security management policy, together with a set of specific security policies
• A security management information system (SMIS) containing all the information related to information security management
• Revised security risk assessment processes and reports
• A set of security controls with details of their operation and maintenance and their associated risks
• Security audits and audit reports
• Security test schedules and plans, including security penetration tests and other security tests and reports
• A set of security classifications and a set of classified information assets
• Reviews and reports of security breaches and major incidents
• Policies, processes, and procedures for managing partners and suppliers and their access to services and information

Information Security Management Process Owner

The information security management process owner’s responsibilities typically include the following:

• Carrying out the generic process owner role for the information security management process
• Working with the business to ensure proper coordination and communication between organizational (business) security management and information security management
• Working with managers of all functions to ensure acceptance of the information security management process as the single point of coordination for all information security–related issues, regardless of the specific technology involved
• Working with other process owners to ensure an integrated approach to the design and implementation of information security management, availability management, IT service continuity management, and organizational security management

Information Security Management Process Manager

The information security management process manager’s responsibilities typically include the following:

• Carrying out the generic process manager role for the information security management process
• Coordinating interfaces between information security management and other processes, especially service level management, availability management, IT service continuity management, and organizational security management
• Developing and maintaining the information security policy and supporting specific policies, ensuring appropriate authorization, commitment, and endorsement from senior IT and business management
• Communicating and publicizing the information security policy to all appropriate parties
• Ensuring that the information security policy is enforced and adhered to
• Identifying and classifying IT and information assets (configuration items) and the level of control and protection required
• Assisting with business impact analyses
• Performing security risk assessment and risk management in conjunction with availability and IT service continuity management
• Designing security controls and developing security plans
• Developing and documenting procedures for operating and maintaining security controls
• Monitoring and managing all security breaches and handling security incidents, taking remedial action to prevent recurrence wherever possible
• Reporting, analyzing, and reducing the impact and volumes of all security incidents in conjunction with problem management
• Promoting education and awareness of security
• Maintaining a set of security controls and documentation, and regularly reviewing and auditing all security controls and procedures
• Ensuring that all changes are assessed for impact on all security aspects, including the information security policy and security controls, and attending CAB meetings when appropriate
• Ensuring that security tests are performed as required
• Participating in any security reviews arising from security breaches and instigating remedial actions
• Ensuring that the confidentiality, integrity, and availability of the services are maintained at the levels agreed to in the SLAs and that they conform to all relevant statutory requirements
• Ensuring that all access to services by external partners and suppliers is subject to contractual agreements and responsibilities
• Acting as a focal point for all security issues