vWhat was the first symptom of the problem? Have you noticed other symptoms occurring simultaneously?

vDoes the problem affect only one system or multiple systems?

vDid you receive an error message indicating what the problem is?

vIf the problem can be reproduced, what are the steps that you need to perform to recreate it?

Identifying the cause of the problem

The information you gathered during the previous phase helped you to correctly identify the problem and describe the context that triggered it. To be able to identify and locate the cause of the problem, it is very important that you understand the Tivoli Intelligent Orchestrator architecture and the interaction between its components. This will help you to determine the specific component that is involved with the problem:

vData center model

vPolicy engine

vDeployment engine

vAutomation packages

vDiscovery technologies

vManagement interface

Problems limited to a single product component have causes that are easier to identify. Other problems might affect various components and their causes might be subtle and more difficult to identify. Furthermore, different problems may have the same symptoms, but different causes. Ideally, you should be able to approach the problem in such a way so that you can isolate it to a single component.

If you cannot identify the cause of a problem, you might want to seek the assistance of the Tivoli Support team, who will be able to pinpoint the cause of the problem and recommend ways to recover from specific situations. For more information on how to contact the IBM Tivoli Software Support, refer to Chapter 9, “Contacting IBM Tivoli Software Support,” on page 91.

As Tivoli Intelligent Orchestrator integrates many different products, some of the problem determination issues that might be considered difficult at times are:

Determining where the problem lies and what it is

The first challenge would be to determine if the problem is a customer error, triggered by an incorrect use of the product, or an error of the product itself, that is, a defective piece of software or hardware. Errors encountered at startup are often missed, resulting in symptoms that are encountered down the road. It is always worthwhile verifying whether problems or exceptions are encountered at startup, before debugging a symptom found down the road. Any problem found in a startup trace should be addressed first.

Verifying whether the problem can be replicated

You need a non-production environment on which to replicate the problem and do all tracing and analysis. Having a non-production environment available would also allow you to test the problem on different platforms.

Checking whether the problem has occurred before

If the same problem or a similar problem have been dealt with before, it is very likely that extensive support documentation is provided. Begin by

8Tivoli Intelligent Orchestrator Problem Determination and Troubleshooting Guide

Page 20
Image 20
IBM 51 manual Identifying the cause of the problem, Determining where the problem lies and what it is