Tema
Sistemas de Gestión de Incidencias, Identificación y análisis
de las distintas fases del proceso de resolución de incidencias en una red de comunicación.
1.
Identificación y análisis de las
distintas fases del proceso de resolución de incidencias.
Cuando se notifica una
incidencia, se deben seguir una serie de pasos para tener una buena resolución.
Al recibir una incidencia en redes se deben realizar una serie de pasos.
Todos los pasos que se describen
a continuación se deben documentar, siguiendo la metodología de la gestión de
incidencias. Se debe usar la base de datos que se esté utilizando y se deben
añadir estos datos nuevos, Si ya hay datos parecidos, se podrá hacer uso de
ellos para una más rápida solución y, si no es necesario, no se escala la
incidencia.
Fases del Proceso:
1.1 Definición del
problema: La
notificación de la incidencia se puede realizar por distintas vías, por mail,
por teléfono, etc., y puede proceder de distintas personas: cliente,
administrador de red, etc. Una vez la notificación esta en el departamento
adecuado, se debe tratar de definir el problema en un principio. Así, para
acotarlo, se deben definir esencialmente dentro de la red los siguientes
aspectos:
- Servicios
afectados.
- Tiempo de falta o merma de servicio.
- Repercusión dentro de la empresa que
trabaja con la red.
- Coste económico a esta empresa.
- Cumplimiento de SLA.
Una vez conocido esto, se debe
hacer una descripción exhaustiva del problema.
1.2 Descripción del
problema: Cuando
ya se conoce a qué ha afectado la incidencia y se clasifica según el SLA que se
tenga acordado con el cliente, se debe realizar la descripción del problema.
Para esto, es posible que se deba hablar con la persona que ha detectado la
incidencia, ya que es muy probable que pueda aportar muchos más datos. La
descripción del problema depende mucho de cada caso, porque cada uno es
diferente y aquí entra en juego el buen hacer del administrador o gestor de
redes. Así, si el problema ya se ha dado en alguna ocasión anterior y está
documentado, se resolverá inmediatamente, pero, si no, se deberá realizar y
documentar qué ocurre exactamente y cómo afecta.
Así se hace la descripción del
problema:
- Cómo ha sido
detectado.
- Qué lo ha
causado.
- Qué servicios
están afectados y qué servicios no.
- Cuándo ha
ocurrido.
Estos son los datos principales,
pero, dependiendo de la causa de cada red, se deberán concretar ciertas cosas
más o menos.
1.3 Establecimiento
de las posibles causas: Para poder empezar con la resolución del problema,
se deben establecer las posibles causas. En este caso, puede haber muchas o
quizá sea necesario investigar para poder llegar a la causa principal, porque
sea una causa no conocida o nueva. Se realizan una serie de pruebas y estudios para
llegar a las causas más probables.
Respecto al nivel físico, de
cobre, fibra o inalámbrico:
- Cableado o terminaciones dañadas o sucias.
- Atenuación
excesiva de la señal.
- Insuficiente
ancho de banda para el cableado.
- Interferencia
inalámbrica.
Respecto a la configuración software
del nivel de red, Ethernet e IP:
- Dispositivos de
red dañados.
- Configuraciones
de dispositivo incorrectas o no óptimas.
- Problemas de
autenticación y asociación.
- Ancho de banda
de red insuficiente.
Respecto a los sistemas switches,
routers y VLAN:
- Uso excesivo.
- Demasiados
errores.
- Inscripción de VLAN asignada incorrectamente.
- Problemas de
prioridad del tráfico (cos/qos).
1.4 Prueba de las causas más
probables: Una vez que se consiguen aislar las causas que se consideran más
probables de todas las posibles, utilizando los diagramas causa/efecto, es
necesario realizar las pruebas o los estudios correspondientes para poder
averiguar la causa real de lo que está ocurriendo, porque si no sería imposible
llegar a una resolución del problema. Para esto, se tomará un listado de las
causas más probables y, haciendo uso de las herramientas hardware y software
de las que se dispone para la administración y la gestión de incidencias,
se llegará a la causa del problema.
1.5 Verificación de
la causa real: Una
vez concretada la causa que provoca la incidencia, después de haber hallado las
causas más probables por el diagrama de causa/efecto y habiendo hecho las
pruebas con las herramientas que se tienen para ello. Una vez que se considera
que una causa es la responsable de la incidencia, se ha de verificar que es
así, ya que puede haber errores en las mediciones, en las herramientas de
diagnósticos y en los juicios de las personas responsables de la red y que
manejan estas herramientas. Para ello, se realizan una serie de pruebas.
Puede ocurrir
que vuelva a haber servicio en la red porque la causa que provoca la falta o la
merma de servicio en la red sea temporal y las condiciones vuelvan a ser
propicias para que la red vuelva a su funcionamiento normal.
1.6
Planificación de las intervenciones: Cuando ya se ha cerrado cuál es la causa
del problema y se ha hecho un estudio de cuál puede ser la posible reparación y
cómo debe ser esta, se debe realizar una planificación. En este caso, se deben
tener muy en cuenta los acuerdos llegados según el SLA. Para esto, se debe
tener esta documentación accesible y disponible, porque es muy importante para
la planificación. Esto repercute sobre todo en los tiempos de contratación de
servicio. No es lo mismo un servicio en el que se tiene contratada una
asistencia técnica de 24 h con una actuación dentro de un plazo mínimo, que si
se tiene acordado un servicio en horario laboral solamente. Según esto, se
planificaran las actuaciones de una manera u otra.
Independientemente de esto, lo
que siempre se tiene que intentar es reactivar los servicios que ofrece la red
en el mínimo tiempo posible y con la menor repercusión negativa para la
empresa.
También se debe planificar la
actuación técnica para estar seguro de que lo que se está haciendo no va a
repercutir negativamente en otros servicios.
Por lo tanto, se debe realizar, y
por supuesto documentar, una planificación exhaustiva de todas las tareas que
se van a realizar para resolver la incidencia, teniendo en cuenta los tiempos y
también la repercusión. Son datos importantes a tener en cuenta a la hora de la
planificación:
- Tiempo que se
permite que esté el servicio en concreto caído o mermado.
- Importancia de
esa falta de servicio.
- Estudio de la
repercusión de esa falta de servicio en la empresa a la que da servicio la red.
- Estudio de la
repercusión de la posible resolución a los demás servicios que da la misma red.
- Tiempos en los
que es mejor realizar la intervención, según el acuerdo del SLA.
- Planificación
técnica de cómo realizar la intervención según los sistemas implicados.
1.7
Comprobación de la reparación: Según la documentación que se va
teniendo, se va realizando un seguimiento del problema. Es muy importante
realizar un posterior seguimiento de la incidencia. Esto está contemplado en
todas las metodologías y manuales de buenas prácticas, ya que es importante,
pues pueden ocurrir una serie de cosas no previstas en la resolución, como por
ejemplo:
- Que no se hayan contemplado todas las posibles
causas y problemas que hayan ocurrido.
- Que la solución
no sea suficiente porque necesite de alguna reparación más.
- Que la solución
sea temporal.
- Que no se
restauren correctamente todos los servicios.
- Que no se cumpla el acuerdo SLA.
Además, se debe hacer un
seguimiento posterior a la resolución de la incidencia, porque es importante
para la documentación que se debe llevar sobre todo el proceso. En la
documentación debe aparecer también, cuando se realiza la resolución, cómo
evoluciona en el tiempo la restauración o renovación del servicio dado.
1.8
Documentación: Como
se especifica en la gestión de incidentes, es muy importante llevar una
documentación sobre todo el proceso. Todos los manuales de buenas prácticas y
metodologías reflejan la importancia de esta documentación, para que se
facilite la resolución de otros posibles problemas posteriores y para que todas
las personas implicadas en el proceso de la resolución de incidencias puedan
tener acceso a cada paso que se da para resolver esta incidencia, desde la
recepción del problema hasta la solución definitiva.
Para manejar esta documentación,
se suelen llevar una o varias bases de datos, donde habrá una serie de campos
para rellenar ya prefijados. Habrá campos que se repitan en cualquier tipo de
incidencias, campos de datos que se repitan en incidencias de redes, y campos
personalizados para ciertas redes concretas. Seguidamente, se ofrece un ejemplo
de los campos que se pueden poner en la base de datos. Aunque estos son
genéricos y deben estar en todas las bases de datos, normalmente se les
añadirán más, según cada casuística:
- Hora del
incidente.
- Hora de la detección.
- Falta o
reducción del nivel de servicio causado.
- Tiempo total desde la caída del servicio a la
restauración parcial.
- Tiempo total
desde la caída del servicio a la restauración completa (a veces coincide con la
anterior).
- Recursos
utilizados.
- Posibles causas.
- Descripción
completa de la solución parcial.
- Descripción
completa de la solución total.
2.
Sistemas de Gestión de Incidencias
Ø Funcionalidad y
criterios de utilización de herramientas hardware de diagnóstico de
incidencias.
Cuando
ocurre una incidencia, se puede decir que es por muy distintas causas. Hay que
saber por lo que es y de dónde viene la incidencia. Pero también es muy
importante saber distinguir si es posible que sea una incidencia hardware o
software.
Se debe
realizar un diagnóstico y para ello se deben hacer las comprobaciones de ambos
tipos de herramientas (hardware y software). Por lo tanto, estas herramientas
son utilizadas tanto para el diagnóstico inicial como para el análisis
posterior de la incidencia a tratar.
-
Polímetro
El
polímetro es un aparato de medida que puede medir distintas magnitudes.
También
se le puede llamar tester o multímetro. Mide magnitudes eléctricas o
electrónicas. En principio, está diseñado para medir el voltaje, la intensidad
o la resistencia eléctrica, pero puede medir también las capacidades de los
condensadores, la continuidad o alternancia de la corriente eléctrica, etc. El
cometido principal del polímetro es comprobar que un circuito eléctrico
funciona correctamente.
-
Comprobador de cableado
El
comprobador de cables de red, del cual en ocasiones se utiliza su nombre inglés
LAN tester, se utiliza para estudiar la continuidad de estos cables, por los
que se realizan las comunicaciones de Internet. Actualmente, las redes, en su
mayor parte, usan los cables de par trenzado, que son los cables UTP o STP. Por
eso los comprobadores de red o de cable más usados son los que comprueban estos
tipos de cable.
-
Generador y localizador de tonos
El
generador de tonos es una herramienta que permite localizar los cables.
Con
esta herramienta y sin tener que pinchar en el cable físicamente, se puede localizar
por dónde van los cables. También consigue localizar un par de cables en una
manguera de pares de cable. Se usa en todo tipo de cables, como cables de red
Ethernet, cables de telefonía, etc. De hecho, en el terminal generador del tono
se encuentra todo tipo de conectores para las diferentes redes que pueda haber.
-
Reflectómetro de dominio temporal
Los
reflectómetros de dominio temporal o TDR, que son sus siglas en inglés,
Time
Domain Reflectometry, son dispositivos muy utilizados en redes extensas, ya que
permiten localizar fallos en el cableado y en las redes en sitios muy
distantes. Son capaces de distinguir y localizar el fallo.
Se usan
especialmente en cables de fibra óptica, que son los cables que se suelen
emplear más en las redes extensas.
También
se usan en el mantenimiento de las redes en general, no solo para detectar
fallos, sino para poder saber dónde se produce un deterioro que puede provocar
un fallo más general o que decremente la calidad, en cierta manera, de la
señal.
-
Certificador de cableado
Un
certificador de cableado es un instrumento que realiza un testeo completo de la
red en su totalidad. De esta manera, determina si la infraestructura de la red,
así como cada una de sus partes, funciona correctamente y si las dimensiones y
el conjunto están correctamente conectados y funcionando.
Ø Funcionalidad,
criterios de utilización y ejemplificación de herramientas software de
diagnóstico de incidencias.
Puede
ser que no haya absolutamente ningún error físico, pero que sí haya un problema
en las configuraciones de la red, en el dimensionamiento previo, etc. Para el
estudio de estas circunstancias, se usan otro tipo de herramientas, software,
que se instalan y se utilizan desde el PC del administrador o administradores
de la red. Estas herramientas son muy interesantes, porque indican cómo va la
red y además la mayoría de las veces se puede hacer un diagnóstico desde el
puesto del administrador, en remoto. Es software que testea la red y se dedica
a controlar todo lo que pasa por esta. En el mundo de la informática, estos
programas se llaman sniffers, ya que se dedican a oler todo lo que pasa por la
red.
-
Monitor de red
Un
monitor de red o network monitor es aquel que es capaz de tomar los paquetes de
la red y sacarlos a un interfaz visible por el usuario o a otro software para
su posterior análisis de estos paquetes. Es a lo que se le llama en
terminología de administradores de redes un sniffer, ya que se dedica a oler los
paquetes y a volcarlos a la interfaz del usuario o en otro sistema que analice el
protocolo.
En el
mercado hay varios monitores de redes. Son sistemas que no solo son monitores
de red, sino que analizan los protocolos o gestionan la red. Así, están Microsoft
Network Monitor, WireShark, Tcpdump, Snoop, Nagios, etc. Los monitorizadores
también se usan dentro de sistemas como IDS o IPS (Intrussion
Detection/Prevention Systems) o sistemas detectores de intrusos.
-
Analizador de protocolos
Un
analizador de protocolos es aquel sistema capaz de recoger los paquetes que van
por la red y analizar el tipo de protocolo, estudiando el paquete y
decodificándolo, para poder hacer filtrados de los paquetes y otro tipo de
estudios.
Es algo
más sofisticado que un monitor de red, pero hace uso de este tipo de sistemas.
El
analizador de protocolos se usa junto al monitor de red. El analizador utiliza
las trazas que son devueltas por un sistema que lee los paquetes y según unos
criterios predefinidos los clasifica. Se utiliza
colocándolo dentro de la red en la que se encuentra la incidencia y se
configura de manera que huela o sniffe los paquetes y luego los analiza, descartando
los que son buenos y los que no. El sistema que sniffa los paquetes es el
monitor de red.
Estos son
sistemas que a su vez integran varias funcionalidades, no los hay que solamente
realicen una función. Así, están Microsoft Network Monitor, WireShark, Tcpdump,
Snoop,
Nagios, etc.
Herramientas de
Software
Microsoft
Network Monitor
Es la
herramienta que usa Microsoft como monitorizador de red desde un principio. Es
solo para Windows. Devuelve trazas a un nivel muy detallado, tanto a nivel de
red como a nivel de la capa de enlace. Es para usuarios avanzados que conozcan
los paquetes que se envían por las redes. Es utilizado ampliamente por usuarios
de Windows.
Tcpdump
Es una
herramienta que se utiliza en sistemas Linux y Unix. También expone trazas y
logs sobre los paquetes que pasan por la red y de la misma manera son trazas
difíciles de tratar, por lo que suele ser gente muy conocedora del tipo de
paquetes que viajan por una red la que puede leer y dar un diagnóstico sobre
estas trazas.
Snoop
Herramienta
muy parecida a Tcpdump, pero usada en Solaris. Se usa en modo consola también
y, al igual que en Tcpdump, las trazas que se extraen deben ser leídas por
personas conocedoras de la materia.
Wireshark
Es una
de las herramientas más utilizadas actualmente por los administradores de red.
Igual que las demás, de esta se obtienen unas trazas que deben de ser leídas
por personas conocedoras de la materia.
Es una
herramienta de software libre y tiene una interfaz gráfica bastante amigable
para el usuario. Se puede instalar en todos los sistemas operativos,
Linux,
Windows, Solaris, Mac OS, etc. Esto es lo que lo hace tan popular, además de su
interfaz gráfica amigable para el usuario.
Nagios
Es otro
de los sistemas más usados actualmente. Realiza la monitorización de la red,
además de analizar los protocolos para alertar o dar información de todo lo que
ocurre en la infraestructura de la red. Lo que lo hace tan popular Nagios es
el hecho de que Nagios va más allá de un simple analizador y
monitorizador, ya que hace funciones de gestor de redes.
Estas
herramientas son más sofisticadas y van más allá de las pretensiones de este
capítulo, pero no está de más nombrarlas, ya que pueden llegar a ser muy útiles
para un administrador de redes.
- Gestor de redes
-
IPS o IDS (Intrusion Prevention System o Intrusion Detection System)
-
Utilidades TCP/IP: ping, traceroute, ARP, netstat
No hay comentarios:
Publicar un comentario