Cómo resolver problemas en #it.
En mi opinión hay tres fases claras.
1) Reunir información.
La información que se reúne debe ser fiable, y si hay dudas de la información obtenida o la fuente no es del todo fiable (recordemos el juego del teléfono escacharrado) debemos intentar conseguirla de la forma más directa, hablando con el afectado personalmente o reuniendo aquellas pruebas que nos puedan ser útiles como: test de red, archivos .pcap o syslog.
Además a veces cuando llega un problema no contamos con toda la información o esta es difícil de obtener, o incluso aquellos datos que hemos obtenido no dan suficiente información.
Logs que dan poca información o que no entendemos, protocolos de #telefonía como #SIP que a veces dan respuestas demasiado genéricas. Equipos que tienen el protocolo ICMP bloqueado y no permiten saber si hay un problema a nivel de red…
Es importante tener un listado de preguntas a realizar cuando se dan ciertos problemas, esto ayudará a conseguir información. Recomendado usar método de preguntas #5W2H esto puede ser muy útil para obtener pistas que nos ayudarán a plantear hipótesis.
¿Cuándo dejó de funcionar, día y hora? ¿Qué error recibe? ¿Quién estaba configurando esa opción? ¿Por qué tocó esa opción y no la otra? ¿Dónde pasó? ¿Cómo pasó?...
2) Plantear hipótesis del problema y posible solución
En ocasiones se plantea que un equipo especializado de soporte técnico debe resolver el problema, y en mi opinión esto no es siempre así. Desde mi punto de vista creo que un equipo de #soporte técnico debe intentar tener un diagnóstico del problema en el menor tiempo posible, estar lo más acercado a la resolución del problema y proponer una solución con el menor costo posible. Hablemos de costos como: tiempo, dinero, esfuerzo, recursos, etcétera.
En ocasiones se puede tener un proveedor que ofrece algunos servicios como puede ser #VoIP, un instalador de telecomunicaciones que a su vez es mantenedor del servicio de teléfono y un equipo de soporte informático. Como vemos cualquiera de estos equipos puede plantear hipótesis y posibles soluciones, pero aplicar la solución puede que no dependa de todos ellos.
Seguro que en muchos equipos técnicos estos deben dar soporte a hardware de diferentes fabricantes. Puede que la solución que se dio en el pasado a un fabricante no valga para otro y viceversa. Por no hablar de que muchos equipos llegan desactualizados o en fases tempranas que aún necesitan madurar o que contienen bugs que hacen que algunas funcionalidades no estén operativas. Esto hace que en ocasiones los equipos técnicos trabajemos con un modelo de prueba y error que puede causar desconfianza al afectado. Esto añade un handicap al desarrollar el trabajo.
Entonces ¿Qué hacemos con toda la información que tenemos? Los resultados de red, las capturas .pcap, syslog y las preguntas realizadas al afectado? Con la información que tenemos intentaremos extraer conclusiones, descartar posibles problemas, y realizar conjeturas que tendremos que poner a prueba. Si no llegamos a ninguna conjetura o no lo tenemos del todo claro no hay que dudar en pedir ayuda al soporte, puede ayudarnos y ahorrarnos mucho tiempo.
Si tenemos la suerte de contar con un equipo experto este ayudará a encaminar de la forma más eficiente el caso ahorrando mucho esfuerzo y tiempo. Consultar fuentes de información también será un punto clave. Apoyarse en la #IA en estos tiempos puede ser una fuente de sabiduría muy grande cuando no se cuenta con un equipo técnico al que pedir ayuda.
Algo que personalmente me ha funcionado en muchas ocasiones en caso de quedarse bloqueado en algún punto de la resolución es acudir al modelo #osi de capas y trabajar desde la la capa inferior hasta la superior o al revés.
3) Poner en práctica la solución propuesta
Tenemos un posible diagnóstico, una hipótesis del problema y una posible solución, ¡llegó la hora de ponerlo a prueba!
Encontrar el momento para probar la solución con el cliente, con poco impacto en caso de que falle algo. Que haya una ventana de tiempo para poder volver a reunir información con la que realizar nuevas conjeturas y soluciones que tendremos que volver a poner a prueba.
Pero, ¿y si no falla y va todo bien? Mantener un tiempo de prudencia en el que obtengamos nueva información para ver que todo está bien es conveniente, reunir la información y documentar todo el proceso será clave para resolver futuros casos similares.
¿Qué métodos de resolución de problemas utilizas? ¿son parecidos al que he descrito?
Comentarios
Publicar un comentario