Identifying the cause of the problem, Identifying, Cause – IBM 51 User Manual
Page 20: Problem
v
What
was
the
first
symptom
of
the
problem?
Have
you
noticed
other
symptoms
occurring
simultaneously?
v
Does
the
problem
affect
only
one
system
or
multiple
systems?
v
Did
you
receive
an
error
message
indicating
what
the
problem
is?
v
If
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:
v
Data
center
model
v
Policy
engine
v
Deployment
engine
v
Automation
packages
v
Discovery
technologies
v
Management
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
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
8
Tivoli
Intelligent
Orchestrator
Problem
Determination
and
Troubleshooting
Guide