Tag: Operation Continuity

ITSM Tools Operation Continuity Plan – Part Two

We discussed the first several topics (scope, data considerations, and external dependencies) that should go into an ITSM tools operation continuity plan during a disaster recovery (DR) scenario. In this post, we will conclude the discussion by covering the people, procedures, checklist, and validation sections of the plan.

Recovery Team and Communication

The section spells out the key roles and the staff members who will be responsible for implementing the plan. It will include the typical information such as name, organization affiliation, location, and contact details. This section should also include agreed upon communication protocols for the duration of the recovery process. For example, teleconference bridge information could be something useful to include, if that is your organization’s standard practice. Also, if your organization has a major incident handling practice with standard communication and reporting requirements, you can cover the pertinent details within this section or at least make a reference to it.

Recovery Procedure and Configuration Details

This section outlines the recovery instructions and procedures with as many details as necessary for a successful recovery. This section also provides all configuration details that need to be in place in order for the recovery solution to work as designed. Just how much information do you really need to include in the document? I believe the level of detail will largely depend on whom your organization anticipate will execute the plan or heavily influenced by your organization’s disaster recovery plan.

By default, I would recommend having the level of detail based on the assumption that the people who will execute the plan are NOT the same folks who operate the production environment pre-disaster. This is the safer router in my opinion.

For example, your organization uses ITSM product XYZ, made by company ABC and operated by an off-shore team from vendor OPQ. When a disaster strikes your data center, the network connectivity between your data center and your production personnel from OPQ was cut off. At this time, your OPQ vendor has another team at a different location who can access the recovery site and knows your ITSM product. With a properly documented recovery plan with the right level of details, you can leverage your vendor’s second team quickly to start working on the recovery without any help from the production team.

Checklist of Key Actions or Milestones

To help everyone who needs to understand and execute the plan, I recommend having a section that outlines the key tasks and activities so no important activities will be missed. The checklist can also be used to show the various communication and escalation points.

Testing and Validation Steps

This section outlines the detailed testing strategy and validation activities required to implement the recovery plan. Similar to the recovery procedures section, it is highly recommended that these instructions are comprehensive, so the recovery solution can be fully tested by people who may not be the same team as your production crew. The section should also account for all potential conditions, events, and scenarios. The section should contain information that can be used during the testing such as:

  • What are the success criteria for the test objectives?
  • What are the assumptions defined for this test, if any?
  • When is the testing window?
  • How should the security setup be taken into consideration?
  • Which tool modules will be tested?
  • Who will be conducting the test?
  • What are the steps to validate the application and data integrity?

Return-To-Normal-Operation Procedure

This section describes the instructions/procedures necessary to return to the normal production environment once it has been restored. For this section, I would say probably the most key information to explain is how the data will be synchronized between the production and the DR systems. Again, the key objective is not to lose any data captured by the ITSM tools while it was operating in the DR setup. This section will also include the necessary testing and validation steps to ensure that the production system is back in full operation, so the DR system can be fully shut down and return to the stand-by mode.

An ITSM Tools Operation Continuity Plan Example

I hope this particular discussion on the ITSM tools continuity plan provides something of useful tidbits for your organization to think about and to plan for. Considering the importance of the data and transactions captured by the ITSM tools for many organizations, having a workable continuity plan is really not optional anymore. If you don’t have anything in place now, I recommend start small by drafting a plan and making the scope compact enough to cover just a few high probability and high impact scenarios. Work with someone within your IT organization who is responsible for the overall IT continuity plan, so your plan can integrate well with the overall IT and business objectives.

ITSM Tools Operation Continuity Plan – Part One

If your IT organization is like most others, you rely heavily on your IT service management (ITSM) tools for delivering IT services to your business customers or constituents. Many IT shops also have a comprehensive suite of ITSM tools they use as part of the various aspects of their operation. It is my personal belief that the ITSM tools operate like the ERP systems for many businesses – the ITSM tools are providing a critical service to the IT organizations.

While many ITSM products on the market today are well made and come with industrial strength resiliency, technology failures or other disasters can still cause the tools to become unavailable for use. When the tools unavailability or outage stretches out from merely minutes into hours or days, you need to have a continuity plan to get the tool services restored so your IT organization’s operations can continue normally without further hindrances. The ITSM tools operation continuity plan needs not to be fancy or sophisticated, but it does need to be well thought-out with as many details called out beforehand as possible. This is the part one of a two-part post where we will go over what components should go into such plan.

Introduction
This section provides an overview of the plan. Why the plan exists? Who is the owner accountable for drafting and/or executing plan? How will the plan be maintained and tested for validity or accuracy? Any other high-level, overview information about the plan will be helpful to include in this section.

Invocation
This section includes the comments on what conditions will trigger the actions to invoke this plan. It is important to point out who will be authorized to invoke and to implement this plan. It is also important to outline the availability requirements and targets once the plan is invoked.

Scope
This section describes the ITSM modules, systems, infrastructure, services and facilities that will be part of this plan. A number of ITSM systems do not operate in isolation these days, so identifying all components required for a functional ITSM system could be daunting. That is OK. Just have a boundary in mind and do your best. If possible, include and provide as much information on the infrastructure that hosts the ITSM products as feasible. This could include the actual server names, databases, and other components deemed essential and critical for the operations of the ITSM tools. If you have a CMDB with the relationships documented, those relationships between the system components and your plan should be consistent with each other.

Depending on your operation, not all ITSM modules need to be part of this continuity plan. For example, I surmise tool modules or services such as Incident Management, Change Management, or anything the Service Desk uses could be high on the priority list to get restored ASAP. Problem Management module probably can wait and get restored as part of the normal system recovery cycle.

Data Dependencies and Considerations
This section includes comments about the data requirements that need to be met before the recovery plan can be implemented. What data is needed for the recovery and what preparation activities are required to get the data in place? This is more than just calling out what database servers are needed for recovery, which should have been discussed in the Scope section. I am talking about things such as how current the data need to be before the recovery procedures can be executed. Another consideration is how the data that was captured during the recovery phase will be incorporated back into the main database once the original systems come back online. The key objective here is not to lose data, during recovery and post recovery.

Security and Access Considerations
This section includes the important details about the security and access related matters. For example, what access rights will your systems and personnel require in order to fully execute the plan? Often we have the security and access considerations on the back burners and forget about them. During the recovery phase, things are not working as expected and, after many rounds of discussions and trouble-shooting exercises, we realize the security access might be preventing things from working. Don’t put yourself in the position of being unprepared and wasting time. Figure out those security and access details beforehand and document them in the plan.

External Dependencies and Considerations
This section calls out the systems, infrastructure, service, facility or interfaces that are external to the ITSM system but have inter-system dependencies that should be documented. Essentially, anything that has not been identified in the Scope section but still required for recovery should be mentioned here. That way, all dependent systems and the nature of dependency can be identified and taken into account during the plan execution. For example, we might want to include information about the email system and its key interface points because most ITSM systems have a reliance on the email systems for communication.

That is all for now. On the next post, we will conclude the discussion of the plan and cover the remaining topics:

  • Recovery Team and Communication
  • Recovery Procedure and Configuration Details
  • A Checklist of Key Actions or Milestones
  • Testing and Validation
  • Return-To-Normal-Operation Procedure