¡Dame una mano, estoy desesperado porque esta aplicación no funciona!
-¡Y encima es domingo por la noche, y mañana tenemos que trabajar!
Cuantas veces te habrá sucedido esto! La Ley de Murphy se aplica siempre, cuando tenes que terminar un proyecto, cuando estas haciendo una migración, o simplemente cuando estas instalando una aplicación a última hora y despues te deberías poner los “Cortos” e ir al fulbito del jueves por la noche… A veces ocurren problemas con las funciones más tontas de las aplicaciones, a veces el sistema operativo no levanta, o un servicio deja de operar…
En este Post, y otros sucesivos, trataré de plasmar mis métodos de troubleshooting. Si bien no encontrarás métodos infalibles de resolución, son los que me dan de comer todavía. 😀 😀 Demás está decir que quedan excluidas las razones económicas por las que no realizarías estos procesos (a veces es más barato llamar a un experto para resolver el asunto, o por, vaya uno a saber que razón, es más fácil empezar todo de vuelta :s)
Introducción – El problema del conocimiento…
En cuestiones de IT, se tiende a pensar que la acumulación de conocimientos implica un mejor desempeño y resolución de tareas. Por este motivo me enfrento cotidianamente a estos escenarios:
Usuario: – Estoy teniendo problemas con la aplicación xyz, tira un error yxyyyyyyyz – ¿Podrás averiguar que está sucediendo?
Técnico: – uhh… nunca trabajé con la aplicación xyz (Y en este punto bifurca hacia varios lados siendo las siguientes, posibles respuestas:)
- -Despues lo veo… (y queda así de por vida)
- -Tenés que llamar a otro que conozca esta aplicación (Quizás sos el único!!!)
- -Mañana te formateo la máquina (Winners don’t use Format C: Command !!!)
Si ya pensas que no lo podes resolver, porque nunca trabajaste con esa aplicación, tenés la batalla perdida. Pensar que, por el hecho de haber trabajado con esa aplicación/servidor/tecnología tantos años, uno se convierte en un experto “resolvedor” de los problemas que puedan acontecer, dista mucho de la realidad…
A veces tener un enfoque diferente, universal y métodico, evita tener que ser un especialista de todas las aplicaciones o servidores con las que uno se pelea día a día.
…Prerequisitos…
Al momento de realizar Troubleshooting, se deberá utilizar una batería de herramientas que te ayudarán a resolver el problema. Muchas son fáciles de disponer, otras dependerán de las ganas!
- Una conexión a Internet: ¡Y sí! Google es la mejor herramienta con la que cuenta un soporte en estos días. Salvo que seas el rey del las versiones de evaluación, probablemente a otro le haya ocurrido lo que a vos!:D
- Tener espíritu detectivesco: ¡O ser como yo, un chusma total! Hacer las preguntas correctas a las personas indicadas pueden llevarte hacia el punto ideal para resolver el problema
- Tratar de descubrir como funcionan las cosas: Este prerequisito es el más difícil. Te tiene que interesar descubrir el porqué de las cosas, probarlas, ir más allá de lo que el “paso a paso” propone… Por ej:
-
- Tener una noción de como funciona una red de ordenadores (Direccionamiento Físico y Lógico, Métodos de Conexión, Resolución de nombres, Modelo OSI!, etc
- Tener una idea de la arquitectura del Sistema Operativo. Con esto hago referencia al módo con el que el sistema operativo nos permite interactuar con los dispositivos. No es lo mismo Windows 98 que Windows NT. Muchas versiones se asemejan entre sí y si se observa a lo largo de la historia de ese OS, pocos o menores cambios se introducen en dicha arquitectura.
- Tener una idea general de la interacción de las aplicaciones con el usuario y el sistema operativo. ¿Donde se puede llegar a guardar su configuración? ¿Cómo se comunican entre sí? Que componentes pueden interactuar (un servicio, un exe, una DLL u OCX, un daemon service, etc)
- Tener un enfoque metódico de la situación a resolver: Plantear una lista (mental, escrita) de los posibles problemas que pueden causar esta situación, permite establecer claramente cuales son los pasos a seguir.
¿Y ahora que hago?
Primero diferenciaré lo que es obtener conocimiento genuino y lo que es obtener una experiencia:
Obtener Conocimiento Genuino implica adquirir una serie de datos o información que son inherentes a un proceso o funcionamiento de “algo”. Generalmente este conocimiento es reutilizable en diferentes escenarios. El acumulamiento de conocimiento permite derivar en lo que se llama “Salto Creativo”. Salto Creativo es el motor que permite innovar.
Obtener Experiencia implica, al momento de sentir una situación única o estímulo, reaccionar ante ese estímulo de una manera y si la reacción fué la correcto, aprender que ante ese estímulo siempre se puede reaccionar así. Si bien las experiencias son acumulables, solo podrán ser utilizadas en mismos o parecidos escenarios con las mismas o parecidas variables presentes.
Luego se puede enfocar el método de troubleshooting basandolo en los siguientes tres métodos.
- El Viejo y Conocido Método de Prueba y Error
- Aislar el Problema para determinar su origén
- Un híbrido que aplica ambas formas
Prueba y Error
Este método tiene como característica intentar de a una solución a la vez. Cuando es efectivo, suele ser muy rápido a la hora de realizar troubleshooting pero para que sea efectivo requiere una experiencia previa. Al no encontrar la solución, las subsiguientes pruebas van adquiriendo complejidad, y la limitante es que, uno prueba hasta que se le agota el conocimiento, pudiendo quedar el problema sin resolver, o aún, pudiendo haber generado más problemas. Resolver el problema generará una experiencia.
Ejemplo: cuando una aplicación no se inicia. pruebo esa aplicación con privilegios de Administrador, si eso no funciona, pruebo reinstalar la aplicación. Y si eso no dio resultados… Formateo el Disco rígido! :S
Aislar el problema y determinar el origen
Este método, en principio es mucho más largo en tiempo y costos, pero tiene el beneficio de ser altamente efectivo y de generar conocimiento genuino que puede ser reaplicado en otros procesos de troubleshooting con una considerable disminución del tiempo de resolución. Este sistema ataca directamente a las raíces del inconveniente y generalmente no afecta a otros componentes.
Ejemplo: Una Servicio deja de funcionar y el error que muestra no nos permite determinar el problema. Una investigación acerca de lo que realiza ese servicio nos permite determinar carpetas y archivos que utiliza, que pueden estar dañados, luego se repara la instalación.
Un Mix de ambos
Ante ciertas situaciones, uno decide comenzar con el camino de prueba y error y probar con la experiencia, para luego volcarse método de aislamiento. Si los primeros intentos son exitosos, se está maximizando la experiencia propia. Si el proceso no es exitoso, hay que saltar hacia el método de resolución aislando el problema y determinando su origen.
Ejemplo: Un usuario tiene problemas para abrir una aplicación XYZ, mi experiencia me dice que esa aplicación pudo haber quedado colgada en memoria. Para evitar indicarle al usuario que abra el task manager, se le solicita que reinicie el sistema, o que cierre sesion y vuelva a loguearse. Si el procedimiento no es exitoso, se investiga la causa de porque la aplicación no se ejecuta.
Conclusiones
Si bien siempre es conveniente generar y obtener conocimiento genuino, no quiere decir que la experiencia sea menos relevante. El problema reside en que la “experiencia” te acotará el poder de acción ya que podrás limitar tu campo a aquellas “experiencias” que recuerdes. El generar conocimiento te permitirá poder trabajar con diferentes visiones y diferentes enfoques, inclusive con varios a la vez. Este último tambien te permite comenzar ya a trabajar con cualquier “ladrillo” que te arrojen, sin tener que esperar a tener la experiencia suficiente para resolverlo.
En otros posts avanzaré con el método de aislamiento y plasmaré algunas experiencias y conocimientos para que puedas empezar a resolver los problemas. Sentite libre de añadir un comentario para corregir o mejorar lo que estoy expresando en estas líneas