|
Scripts are defined according
to the ISP (Internet Service Provider, i.e., the access
network, whether it be Infovía Plus, UOCNet,
Internet or UOC's Local Network). Different verifications
are made for all of them and each verification tests
one service (URL*
test). For each verification, a number of parameters
are associated to it, thus defining the way in which
the corresponding verification will work. An example
of a parameter would be the time of connection by means
of a page to which a "mark" is given (a text
which will always be featured on the page). When the
system detects that this mark is written, the page has
been downloaded. These verifications are carried out
by the robot, which generates the scripts with the information
of the verification in the database.
In the event of error, this is shown
to the technician on a screen, so it can be solved.
This technician (level 1) validates manually that the
error indicated by the robot is actually occurring.
If it is, a number of guided procedures are then followed
in order to solve it.
If the error is located on the network
database, the technician of the 7x24 service could,
from his or her workpoint, monitor the robot's process,
which would work with the local database instead of
the network one. Thus continuity of services is guaranteed
until the problems with the network database are solved.
An example of verification:
A verification to test the Educational
Intranet could be this: access the Intranet, open the
personal mailbox and send a message. For this reason,
a number of attempts are also associated to this, and
in the event that the robot
cannot carry out the action, it generates the corresponding
script to warn of the error on the database.
There are four levels of detection
and solution of possible errors:
|
|  |
Monitoring:
its aim is to monitor servers remotely in order
to detect any incident in the sphere of services.
Its function is to control that no incidents occur
within the services. In the event of there being
incidents, they are transferred to Level 1 or
2 support, and these incidents are registered
with the corresponding application.
|
|
| |
Level 1: if
the monitoring level transfers an incident into
one of the services, the latter should attempt
to solve it by means of the guided procedures
provided by the UOC. Following the replies to
a set of sequentially-made questions, the solution
to the error detected is looked for. In addition,
it should register the application of incidents
to its state. If it is unable to solve it, it
must be handed over to Level 2 support.
|
|
| |
Level 2: a
technician very knowledgeable in working environments
(UNIX/ORACLE) . He or she is in charge of finding
the cause of the error in order to solve it if
Level 1 was not able to do so. His or her function
is to solve the incident off-site. If he or she
is unable to do so, the technician will then have
to come to the UOC's central facilities in order
to solve it in situ.
|
|
| |
Level 3: they
are technicians from the University, although
recourse to this level only happens in very exceptional
occasions, as for example when the need arises
to stop a specific service for a long period of
time.
|
There is also an incident application
in which the technician who has solved the error must
introduce the data relative to the resolution so that
the University may hold the control.
|
