Cuadernos EduBooks®

Elementos de

Diagnóstico y Resolución de Fallos

Versión 1.0

Oscar Antonio Gerometta

 Diagnóstico y resolución de fallos
versión 1.0

Todos los derechos reservados.

Ninguna parte de este libro puede reproducirse o transmitirse bajo ninguna
forma o por ningún medio impreso, electrónico o mecánico, ni por ningún
sistema de almacenamiento y recuperación de información sin permiso por
escrito del autor.

ISBN: 978-987-27966-0-0

Derechos reservados © 2012.

2 / 18
 Diagnóstico y resolución de fallos
versión 1.0

Contenidos

1. Teoría básica del manejo de incidentes ................................................................................ 5

1.1. Mantenimiento y resolución de fallos .............................................................................. 5
1.2. Principios de resolución de fallos .................................................................................... 6
1.3. Principios de diagnóstico ................................................................................................ 7
2. Modelo de metodología de manejo de incidentes ................................................................ 11
2.1. Recepción de un incidente ............................................................................................ 11
2.2. Escalamiento de incidentes .......................................................................................... 12
2.3. La “doble solución” ....................................................................................................... 13
2.4. Tratamiento del incidente .............................................................................................. 14

3 / 18
Diagnóstico y resolución de fallos
versión 1.0

4 / 18
 Diagnóstico y resolución de fallos
versión 1.0

1. Teoría básica del manejo de incidentes

1.1. Mantenimiento y resolución de fallos

Dentro de las responsabilidades propias de un área de Soporte Técnico hay 2 tipos de
tareas claramente diferentes por sus objetivos y la modalidad de trabajo:
○ Tareas de mantenimiento.
Las tareas de mantenimiento tienen por objetivo primario asegurar el
funcionamiento continuo dentro de parámetros estándar y previsibles de
modo de asegurar la operación regular de la organización.
Este tipo de tareas se realiza de modo periódico, utilizando “ventanas” de
tiempo definidas anticipadamente para evitar en lo posible generar
interrupciones en el servicio regular que busca garantizar.
○ Tareas de resolución de fallos.
Las tareas de resolución de fallos tienen como objetivo responder al
requerimiento de los usuarios que experimentan alguna forma de
interrupción o degradación de los servicios.
Se realizan bajo demanda, en respuesta a los incidentes que se reportan, y
pueden suponer reemplazo de equipamiento, reinstalación de software,
restauración de backups, etc.
Se suelen reconocer 2 esquemas básicos de Mantenimiento:
○ Mantenimiento bajo demanda.
Se ejecuta en función de los reportes de problemas o requerimientos que
realizan los usuarios.
Es la forma más básica y menos eficiente de realizar mantenimiento. El
riesgo más importante que entraña es el descuido de las tareas que
permiten la operación a largo plazo de los sistemas.
Suele provocar que los sistemas experimenten tiempos prolongados de
caída debido a la falta de mantenimiento preventivo.
○ Mantenimiento estructurado.
Un modelo de mantenimiento estructurado no apunta a eliminar los
incidentes (lo que es imposible), sino a minimizarlos.
Un modelo de este tipo permite reducir los tiempos de caída de los sistemas,
en el mediano plazo es menos costoso, y permite lograr mayores niveles de
seguridad.

Las tareas de mantenimiento no son objeto de este trabajo, por lo

que a partir de este punto me centraré en la resolución de fallos.

5 / 18
 Diagnóstico y resolución de fallos
versión 1.0

1.2. Principios de resolución de fallos

La resolución de fallos es el proceso que lleva al diagnóstico, y si es posible la resolución,
de un problema, incidente o evento.
Este proceso reconoce 3 etapas o momentos principales:
1. El reporte del problema, incidente o evento.
En el proceso de resolución de fallos el problema no existe hasta que es notificado.
Esto significa, ante todo, que el evento que causó el problema reportado no
necesariamente ocurrió en el momento en que fue reportado. Es posible que el
evento que causó el fallo haya ocurrido tiempo antes y nadie lo haya advertido, o si
lo hizo no lo reportó.
También es importante tener presente que el usuario reporta un incidente desde su
propia perspectiva y con su lenguaje. Esto hace imprescindible que al momento de
analizar el reporte de un incidente el técnico asuma la posición de usuario para
poder comprender claramente el hecho reportado y el grado de urgencia que
reporta para la tarea del usuario.
Es preciso diferenciar y distinguir claramente el problema de los
síntomas, y a estos de las verdaderas causas del problema.
El usuario nos reporta el problema y muchas veces los síntomas.
Muy difícilmente nos indica las causas.

2. A partir del reporte de un problema se inicia el proceso de diagnóstico.

Este es un proceso complejo cuyo objetivo es detectar la verdadera causa del
problema para, si es posible, solucionarla.
Como resultado de este proceso se debe proponer una posible solución.
En algunos casos la solución no será posible implementarla de modo inmediato, por
lo que será necesario definir una tarea preliminar que permita remediar
provisionalmente los síntomas del problema hasta tanto se pueda implementar una
solución definitiva.

3. Se considera que se ha llegado a una verdadera solución cuando es posible

resolver la causa profunda del problema, no simplemente cuando se resuelve el
síntoma al que apunta el reporte inicial del problema que hizo el usuario.

6 / 18
 Diagnóstico y resolución de fallos
versión 1.0

1.3. Principios de diagnóstico

La fase de diagnóstico es claramente el punto central del proceso de resolución de
problemas, la más compleja y la que requiere mayor dedicación y tiempo.
Partes de este proceso son:
○ La recolección de información.
○ El análisis de la información.
○ La eliminación de aquellas causas posibles, pero que se verifica que no impactan
en el problema reportado.
○ La formulación de hipótesis que expliquen la causa del problema.
○ La prueba o test de las hipótesis a fin de confirmarla o rechazarla.
La forma en que se pasa de una etapa a otra, y el tiempo invertido en cada una, es lo que
diferencia a cada técnico en particular en función de sus conocimientos y su experiencia
En una situación de un fallo complejo posible que sea necesario moverse continuamente
entre estos diferentes procesos: recolectar información, analizarla, eliminar algunas
posibilidades, obtener más información, analizarla, formular una hipótesis y probarla; si no
funciona, eliminar esa posibilidad y volver a buscar más información.
Es por esto que hay procesos de resolución de fallos estructurados que hacen más
predecible la posibilidad de lograr resultados y posibilitan el seguimiento de la tarea cuando
se trabaja en equipo.
Entre los diferentes modelos de resolución de fallos estructurada se pueden mencionar:
○ Actuar por aproximación.
○ Bottom up.
○ Dividir y conquistar.
Junto a estos modelos, también debemos considerar algunas técnicas complementarias:
○ Seguir la ruta.
○ Detectar las diferencias.
○ Mover el problema.

A. Actuar por aproximación

Cuando se actúa por aproximación, luego de un corto período de recolección de
información se hace una suposición y en base a ella se realizan algunos cambios rápidos
para verificar si de ese modo se soluciona el problema.
Esta forma de trabajo es habitual en entornos en los que el técnico de soporte tiene mucha
experiencia operando sobre el sistema y ya conoce cuáles son los puntos de fallo más
habituales.
○ Puede resultar muy efectivo cuando se obtiene una solución rápida porque requiere
poco tiempo en la recolección de información y el análisis.
○ El problema es que si no funciona no se está más cerca de una solución.
○ Es aconsejable para personal con mucha experiencia y que conoce los sistemas a
los que da soporte. De esta forma su suposición se hace sobre la base de los
problemas más frecuentes y conocidos que enfrenta el sistema sobre el que opera.
○ En todos los casos es importante que el técnico sepa cuándo detenerse para pasar
a un trabajo más metódico y ordenado.
7 / 18
 Diagnóstico y resolución de fallos
versión 1.0

B. Bottom up
La metodología botton up toma como base el modelo OSI y comienza la verificación desde
la capa física hacia la capa de aplicación, revisando capa por capa que todo esté operando
correctamente.
○ Permite eliminar progresivamente causas potenciales del fallo.
○ Comienza por verificar la infraestructura y luego va hacia los terminales y las
aplicaciones.
○ Permite reducir el alcance del problema y solucionarlo.
○ En el caso de redes grandes puede demandar mucho tiempo.

C. Dividir y conquistar
Soluciona en parte el problema de requerimiento de tiempo que tiene botton up.
Propone comenzar diagnosticando inicialmente la capa de red del modelo OSI
(direccionamiento y enrutamiento IP).
○ Si un test de capa de red (ping) es exitoso, asume que las capas inferiores están
trabajando bien y a partir de este punto comienza a ascender en la prueba hacia las
aplicaciones.
○ Si el test inicial es negativo, entonces hay que comenzar desde capa física hasta la
capa de red.
Esta metodología, en general:
○ Permite una rápida eliminación de problemas potenciales,
○ Esto significa un importante ahorro de tiempo lo que la hace muy efectiva como
estrategia de resolución de fallos en la mayoría de los casos.

D. Seguir la ruta
Es una técnica complementaria de los métodos de “botton up” y “dividir y conquistar”, que
permite verificar la ruta (el enrutamiento) de capa 3 de las sesiones. Es una técnica que
brinda información más completa que el ping.
Permite aislar la región de la red en la que se encuentra el problema inicial, y reduce la
búsqueda de las posibles causas de problemas de infraestructura cuando no hay
conectividad (ping) a nivel de capa 3.
Este método también es útil cuando hay conectividad de capa 3 y aún así las sesiones no
se establecen o sostienen, esto puede deberse a una ruta en la que hay políticas de filtrado
o problemas de asimetría.

E. Detectar las diferencias

Técnica de comparación entre un dispositivo o proceso que funciona y uno defectuoso.
Al encontrar diferencias significativas de versiones de software, configuración, etc. entre
sistemas o dispositivos es posible resolver un problema realizando un cambio que sea
consistente con el que opera sin necesidad de contar con muchos conocimientos respecto
de la tecnología.
○ Permite resolver temporalmente una situación problemática sin llegar a la verdadera
causa del problema.
○ Es útil cuando no se tiene el background necesario para resolver el problema a
partir del análisis de causas posible ya que no requiere mayor conocimiento de la
tecnología.

8 / 18
 Diagnóstico y resolución de fallos
versión 1.0

F. Mover el problema
Una técnica elemental de resolución de fallos que se puede utilizar para aislar el punto de
fallo o dar una respuesta rápida que resuelva temporalmente el síntoma es cambiar
físicamente los componentes y verificar si de esa forma el fallo desaparece.
○ Permite aislar el problema aún cuando la información con la que se cuente sea
mínima.
○ Una dificultad de esta técnica es que asume que el inconveniente radica en un
único componente. Puede no ser efectiva cuando se trata de problemas complejos
que involucran varios elementos diferentes.
○ No se llega a conocer la verdadera causa del problema ya que se trabaja con
información limitada e indirecta. Solo se resuelve el síntoma.

9 / 18
Diagnóstico y resolución de fallos
versión 1.0

10 / 18
 Diagnóstico y resolución de fallos
versión 1.0

2. Modelo de metodología de manejo de incidentes

Denominamos incidente a cualquier suceso que requiera la intervención del Área de
Soporte.
Hay diferentes tipos de incidentes:
○ Incidentes de tipo Administrativo.
○ Incidentes de tipo Técnico.
En este Taller hemos de centrarnos en los incidentes de tipo técnico, exclusivamente.

2.1. Recepción de un incidente

Un incidente o problema existe como tal a partir del momento en el que un usuario (no
importa qué clase de usuario) del sistema notifica una dificultad, falta de performance,
degradación o interrupción de servicio.
El reporte del incidente puede recibirse de múltiples formas diferentes:
○ Por una comunicación verbal directa del usuario.
○ A través de un sistema de reporte de incidentes.
○ Por una llamada telefónica del usuario a Soporte.
○ Por un correo electrónico del usuario a Soporte.
○ Cualquier otra forma de comunicación.
Muchas veces el reporte del incidente puede ser algo más que la noticia de algo que no
funciona correctamente. Puede que junto con la notificación se reciba:
○ Información complementaria.
○ Situación en la que ocurrió el fallo.
○ Intentos de reparación realizados por el usuario.
○ Diagnósticos parciales.
Toda información es útil y se agrega al reporte del incidente.
Sin embargo, el reporte del incidente no es un punto de partida adecuado para dar inicio a
la resolución del fallo. Es preciso convertir ese reporte en una definición técnica precisa de
lo que está ocurriendo: una definición clara del problema.
Para esto:
1. Tenga presente que el usuario está reportando un incidente desde su propia
perspectiva, que no es la del técnico de Soporte.
Por esto es necesario que al analizar el reporte se lo haga desde la perspectiva del
usuario. Esto ayudará a comprender el problema a la vez que orienta respecto del
nivel de criticidad que este tiene para la tarea del usuario.
2. Verifique que el reporte es una descripción precisa del incidente y que la condición
que lo generó aún persiste.
Si es necesario se debe volver a contactar al usuario que generó el incidente a fin
de tener mayores precisiones.

11 / 18
 Diagnóstico y resolución de fallos
versión 1.0

3. Defina en términos precisos el incidente agregando en lo posible la información de

contexto.
Esta debe ser una descripción precisa, NO una interpretación.
4. Determine el grado de severidad del incidente.
Es decir, si el incidente impide un proceso crítico o no. Esto es fundamental para
establecer la metodología a utilizar para su resolución y la mayor o menor
disponibilidad de tiempo para la resolución del incidente.
5. Una vez definido claramente el incidente y su repercusión en la operación regular,
se debe determinar si se procede directamente o si es preciso escalarlo a otro nivel.

2.2. Escalamiento de incidentes

En la atención de incidentes se distinguen diferentes niveles en función de los
conocimientos y experiencias necesarios en el técnico a cargo para buscar las causas del
incidente y resolverlo.
Típicamente se reconocen 3 niveles de atención de incidentes:
○ Soporte Nivel 1
Es el primer nivel de atención y el que tiene trato directo con el usuario.
Su responsabilidad principal es la recepción, verificación, definición y asignación del
grado de criticidad del incidente.
Se ocupa de resolver incidentes de baja complejidad o que por su nivel de
recurrencia ya se encuentran documentados y se cuenta con un procedimiento
estándar para resolverlos.
Cuando no puede resolver el incidente o excede su nivel de conocimientos o
experiencia, escala el incidente con toda su documentación a Soporte de Nivel 2.
En este caso, si el incidente requiere una respuesta inmediata, deberá implementar
una metodología de “doble solución” e incluir esto en la elevación a Nivel 2.

El método de doble resolución será descripto más adelante en un

título aparte.

○ Soporte Nivel 2
Recibe los incidente que le asigna Soporte de Nivel 1, o aquellos que Nivel 1 no ha
logrado resolver.
Soporte de Nivel 2 tiene mayor nivel de conocimientos respecto de la tecnología
sobre la que se trabaja y familiaridad con la implementación sobre la que se intenta
operar.
Cuando no puede resolver el incidente o excede su nivel de conocimientos o
comprensión de la implementación, escala el incidente a Soporte de Nivel 3.
○ Soporte Nivel 3
Recibe los incidentes que le deriva Soporte de Nivel 2 o que le son asignados
directamente por Nivel 1.
Constituye el último recurso interno para la resolución del incidente. Por este motivo
debe poseer un profundo conocimiento de las tecnologías implicadas y acabada
comprensión de la implementación. Debe además contar con herramientas

12 / 18
 Diagnóstico y resolución de fallos
versión 1.0

adicionales de diagnóstico o para la derivación en caso de ser necesario a una

instancia de soporte externa.

2.3. La “doble solución”

En la tarea diaria es habitual que el problema presentado por el usuario requiera una
respuesta inmediata por diferentes motivos: criticidad del sistema, imposición de las
políticas de la organización, requerimiento de atender a un alto nivel de satisfacción de los
usuarios, etc.
En estos casos suele también ocurrir que dar un tratamiento estructurado al incidente para
detectar las verdaderas causas del problema entra en conflicto con los requerimientos de la
organización ya que puede demandar más tiempo del que se espera de nosotros para una
solución.
En estos casos es cuando se debe aplicar una estrategia doble para dar respuesta al
incidente:
○ Una estrategia de corto plazo cuyo objetivo es rápidamente solucionar los
síntomas del problema planteado por el usuario sin detenerse en el análisis de las
causas.
○ Una estrategia de mediano plazo con el propósito de detectar las reales causas del
incidente y resolverlas.
De esta manera se da una solución inmediata al usuario, al mismo tiempo que se mantiene
el objetivo de resolver las causas de modo que no se repita y/o propague el problema.
En este sentido la técnica de “mover el problema” que hemos visto antes es el recurso más
eficaz ya que permite que el usuario esté operativo de modo inmediato y sin mayores
complejidades.
Pero si se va a trabajar de esta manera hay que tener presentes los siguientes puntos:
○ Esta estrategia no es aplicable cuando el punto de fallo es el repositorio físico de
información que es necesario acceder, y no hay copia de resguardo de esa
información.
○ Para poder “mover el problema” es necesario contar con opciones de reposición
que estén en perfectas condiciones, disponibles y claramente documentadas.
Nunca utilice para estos procedimientos elementos de reposición
sobre los que no tenga certeza de su estado.

○ El material de reposición debe estar perfectamente documentado y mantenido. La

esencia de su implementación es permitir una respuesta rápida y eficiente.
Si no hay garantía de contar con una reposición en perfecto estado no debe
utilizarse ya que no sólo el problema persistirá, sino que adicionalmente se
entorpecerá el procedimiento de mediano plazo introduciendo potenciales nuevos
puntos de fallo.
○ Este procedimiento sólo soluciona el problema del usuario (los síntomas) y no
exime de la necesidad de aplicar un procedimiento sistemático para remediar las
causas. De lo contrario la situación se repetirá permanentemente y caerá la calidad
del servicio y nuestra capacidad de dar respuesta por agotamiento del stock para
reposición.

13 / 18
 Diagnóstico y resolución de fallos
versión 1.0

Una vez desarrollada la estrategia de mediano plazo y removida la

causa del problema, se debe analizar la necesidad o conveniencia de
volver al estado inicial el sistema que fue reemplazado inicialmente.
Si no se vuelve al estado inicial se deberá actualizar la información
de inventario y cubrir cualquier otro requerimiento de los
procedimientos de reemplazo de sistemas que tenga la organización.

o Si se aplica una estrategia de doble solución el incidente no se cierra en el

momento en que el usuario ve solucionado su problema, sino que luego de verificar
que el usuario puede seguir operando normalmente se debe proceder al tratamiento
estructurado del incidente hasta solucionar la causa que generó el problema.
○ Concluida la implementación de la estrategia de mediano plazo y vuelto el sistema
al estado inicial (si se hace), se deben realizar las tareas de verificación y
documentación que corresponden a un proceso estructurado estándar.

2.4. Tratamiento del incidente

Una vez asignado el incidente, corresponde entonces el tratamiento del mismo. Para el
tratamiento del incidente hay un proceso básico que se debe respetar:
1. Recolección de información
Una vez que está claramente definido el problema, en primer lugar se selecciona el
método de resolución de fallos (botton up, dividir y conquistar, etc.) a utilizar y se
elabora un plan de recolección de información acorde al mismo.
Para esto es necesario identificar los dispositivos o sistemas sobre los que se va a
trabajar y las herramientas a utilizar para obtener información.
Si no es posible obtener la información que se considera necesaria habrá que
considerar escalar el incidente al nivel competente o reformular la estrategia de
trabajo para centrarse en trabajar con la información con la que se cuenta.
En algunos casos, particularmente cuando escalar el problema
significa una demora importante, puede ser conveniente adoptar una
estrategia dual que denominamos de “doble solución”: derivar el caso
a otro nivel y al mismo tiempo utilizar otra estrategia en paralelo para
procurar alcanzar una respuesta rápida.

2. Análisis de la información
A continuación se debe interpretar la información recogida para buscar los
elementos que apuntan a la raíz del problema.
Durante este proceso de análisis también es posible que se desechen elementos
que evidentemente no pueden ser la causa del problema. La eliminación de estos
elementos contribuye a reducir y acotar la cantidad de elementos que deben ser
examinados y la información que es necesario recolectar y analizar.
Durante el proceso se busca responder básicamente a 2 preguntas:
○ ¿Qué ha sucedido?
○ ¿Qué puede suceder a continuación?

14 / 18
 Diagnóstico y resolución de fallos
versión 1.0

La respuesta a estas preguntas son las que generalmente permiten definir cuál es la
causa del problema o qué información adicional es necesario recolectar.
Una manera alternativa de detectar qué es lo que está ocurriendo es contar con una
buena línea de base del comportamiento de los sistemas que están siendo
analizados. Si se pueden detectar anormalidades en el comportamiento regular de
alguno de los sistemas, entonces se puede inferir que allí es donde se encuentra el
problema.
Por este motivo es sumamente importante contar con una línea de
base del comportamiento de los sistemas para ser luego utilizada en
tareas de resolución de fallos.

Este es el momento de la tarea en el que más destaca la experiencia de un técnico,

ya que el conocimiento previo de situaciones semejantes es el que más ayuda para
reducir el tiempo necesario para procesar la información con la que se cuenta.
3. Elaboración de una hipótesis de trabajo
Como resultado del proceso de análisis se obtiene una lista de las causas probables
del incidente. Esta lista debe recoger unas pocas posibilidades.
Basándose en los conocimientos y la experiencia, se asigna a cada una de esas
causas una cierta probabilidad de estar en el origen del problema que estamos
atendiendo. De esta forma deben quedar unas pocas o mejor aún una sola en
nuestra lista.
Aquella causa que queda como consecuencia de este proceso de decantación se
constituye en la hipótesis para explicar el incidente.
A partir de este momento se asume que ésta es la causa del problema y se planifica
una resolución del incidente basándose en esta suposición.
Dependiendo de la resolución propuesta es necesario analizar si su ejecución está
dentro de los atributos de quien está realizando el análisis o si es preciso escalar
nuevamente el incidente para que lo ejecute quien tiene los permisos o habilidades
necesarios.
4. Prueba de la hipótesis
Llegados a este punto corresponde avanzar con la implementación de la solución
diseñada para corregir la causa del problema reportado.
Usualmente para implementar la solución se requiere realizar cambios en el
sistema, por lo que se deben seguir los procedimientos definidos por la organización
para realizar cambios.
Antes de proceder es fundamental evaluar:
○El impacto que los cambios han de tener en la operación del sistema.
○La urgencia que requiere la situación.
Esto nos permitirá definir el momento adecuado para realizar los cambios:
inmediatamente o durante una ventana de mantenimiento programada.
También hay que planificar un mecanismo para revertir los cambios y restaurar la
situación anterior en caso de que la solución propuesta no de una respuesta
satisfactoria al incidente; o lo que es peor, que genere nuevos incidentes.

15 / 18
 Diagnóstico y resolución de fallos
versión 1.0

Una vez programado el momento de la implementación y previsto un mecanismo de

rollback se procede a implementar la solución respetando los procedimientos
internos establecidos para la realización de cambios.
Pero, independientemente de lo que establezcan los procedimientos internos,
siempre es necesario terminada la implementación verificar que se logró el efecto
que se esperaba y que no se introdujeron nuevos problemas.
No se debe proceder a cerrar el incidente y/o notificar al usuario que
el incidente ha sido resuelto, hasta tanto se haya verificado
claramente no sólo que se ha corregido la causa del incidente, sino
que también ha desaparecido el problema reportado inicialmente por
el usuario.
Hay casos en los que aún cuando las causas han sido removidas es
necesario algún procedimiento adicional para revertir el problema del
usuario.

5. Documentación
Concluido el procedimiento de implementación y verificado que se ha solucionado el
problema reportado (recordar la diferencia entre el problema reportado y la causa
del problema), es necesario realizar un par de pasos finales:
○ Notificar al usuario que generó el reporte del incidente que el mismo ha sido
resuelto y que puede verificarlo ejecutando la operación debida.
○ Documentar:
● El incidente en sí mismo, y catalogarlo como resuelto de acuerdo a lo
que establezcan los procedimientos internos.
● La solución, de modo de generar una base de datos de incidentes y
soluciones que permita ahorrar tiempo de análisis a futuro.
● Los cambios realizados en los sistemas de modo que la
documentación refleje claramente la situación actual de los mismos.
Esto incluye realizar la actualización de los backups del sistema
(configuraciones, imágenes, etc.).

16 / 18
Diagnóstico y resolución de fallos
versión 1.0

17 / 18
Diagnóstico y resolución de fallos
versión 1.0

18 / 18