Develop availability plan

Description:

The availability plan describes the plans that ensure high availability for the service. It addresses the hardware, software, people, and processes related to the service.

Key questions:

• What are the key components that make up this service?
• Are there any single points of failure in the application delivery architecture? Can we mitigate these?
• How has this service performed in the past, either in production or in a pilot or lab environment? What have we learned from this, and how will it affect our availability planning?
• What are the specific recoverability targets for this service? Are they achievable, or do we need to evaluate new or alternate technologies such as virtualization or clustering?
• Do we need vendors or suppliers to deliver components of this service? Are they able to commit to OLAs?
• Does trend data highlight inherent resilience problems with this service or its components?

Inputs:

• Service map
• Incident and Problem Management trend data for analysis
• Technical design and architecture documentation
• Component impact failure analysis
• Existing process documentation
• Incident lifecycle targets
• Availability requirements and targets from SLAs, OLAs, and underpinning contracts (UCs)

Outputs:

• Availability plan
• Technical design recommendations or updates for both availability and recoverability
• Updated incident lifecycle targets
• Skills and resourcing recommendations
• Updated OLAs and UCs
• Failover, backup, and configuration recommendations
• Proactive maintenance recommendations

Best practices:

• Design services for high availability. Proactive design is more cost-effective and efficient than retrofitting. Careful use of redundancy allows a service to tolerate failures of individual components.
• Identify, document, and schedule regular preventative maintenance tasks. Manage these tasks to ensure that they are performed to agreed-upon specifications.
• Continually review the availability plan, requirements, and performance. This ensures ongoing alignment between IT and the business and addresses changing technologies and business requirements.
• Proactively investigate technology improvements and developments, such as virtualization, to determine whether they can be used to increase availability or to reduce risk of individual component failure.
• Identify and manage availability risks as a regular activity, use the outcomes of this activity to identify the priorities and business benefits of improvement activities.

Develop data security plan

Description: The data security plan describes how the service will be brought to acceptable levels of security. It details existing security threats and how implementing security standards will mitigate those threats. The information security plan must address the three goals of information security, namely:

• Data confidentiality. No one should be able to view an organization’s data without authorization.
• Data integrity. All authorized users should feel confident that the data presented to them is accurate and not improperly modified.
• Data availability. Authorized users should be able to access the data they need when they need it.

Key questions:

• How does this service use data or facilitate information transfer?
• How critical is this information to the organization, and does it require regulatory oversight?
• Do we have an internal policy that defines the information type and how this information should be handled?
• Who needs access to this information, and where is it stored? Do we need to make arrangements for contingent staff?
• How long should we retain the data, and how do we best dispose of it when we no longer need it?
• What controls and monitoring should we use to ensure that this data is not compromised? If it does get compromised, how will we know?
• What reporting do we need to provide, and to whom? Will we eventually need to make the reports available to internal/external auditors?

Inputs:

• Information classification policy
• Information handling guidelines
• Regulatory or legal requirements related to secure information handling
• Technical and security design documentation

Outputs:

• Information management plan that includes processes for internal staff and external or contract staff
• Recommended security controls to protect the information
• RFC to implement security controls and/or make design changes
• Audit and monitoring recommendations
• User awareness communication plan

Best practices:

• Generate an overall security policy—supported and enforced by the business—that addresses the requirements, handling and escalation procedures, and user responsibilities relating to corporate data and security incidents. This policy should be regularly communicated to staff through an ongoing awareness campaign.
• Implement technical measures to prevent malicious and/or accidental security breaches. The rule of least privilege provides the most control.
• Wherever possible, use tools and automation to help manage the security of the data. There are many technical solutions that provide this capability.
• Perform regular security audits and penetration tests to ensure that any weaknesses are identified. Factor data security considerations into any future service changes, RFCs, and technical support responsibilities.

Develop monitoring plan

Description:

The monitoring plan defines the process by which the service will be monitored, the information required, and the ways in which the results will be reported and used. For more information about monitoring, see the Service Monitoring and Control SMF.

Key questions:

• What do we need to monitor to determine the reliability of this service? What service components need to be monitored to provide an overall framework for measuring service reliability?
• Monitoring requirements have been identified in availability, capacity, information security and service continuity plans; what is the best way for us to implement these in a consolidated and cost-effective manner?
• Which thresholds will tell us a major component failure is imminent, and what are the triggers that will indicate that a failure has occurred?
• Are we able to monitor these components with the existing infrastructure, and does this allow us to correlate events and initiate responses? Does the service have a health model and built-in instrumentation to assist with monitoring requirements?
• If a trigger event occurs, what steps should IT staff take? Do we have documented response plans and have we communicated these to key IT staff?

Inputs:

• Service health model
• Capacity and workforce plans
• Service map
• Technical design documentation
• Business transaction priorities (which transactions are important, and the service levels they need to deliver)
• Service Monitoring and Control function of Service Management

Outputs:

• Thresholds and alerts that allow insight into the end-user experience with this service
• Service health monitoring model
• RFC to implement monitoring changes
• Reporting templates
• Run book for the Service Desk, explaining how to respond to problems that are raised by monitoring activities

Best practices:

• Collaborate on operations requirements early in the service design activities. As with most proactive activities, retroactively adding a monitoring capability that matches infrastructure standards is expensive and rarely accomplished.
• Automate monitoring and alert responses wherever possible. Automation reduces errors, improves response times, and frees staff for other tasks.
• Consider using synthetic transactions (such as a simple, system-generated test e-mail) to holistically measure how the service is behaving. While it is easy to monitor individual components, the really important measurement is that of the end-user experience with the service.