Metodologa de Resolucin de Problemas

Los ingenieros de soporte necesitamos una metodologa para solucionar los problemas de nuestros clientes. Hace algunos aos atrs, miembros del grupo de soporte de escalacin para Latinoamrica se reunieron y crearon una metodologa que usa las mejores prcticas basadas en la experiencia del grupo y en el mtodo cientfico para la solucin de problemas. Este blog, usa el contenido de dicho trabajo realizado por los Support Escalation Engineers Viviane Lopes y Andre Teixeira. Son varios los beneficios que se obtienen al utilizar una metodologa para solucionar los problemas, entre ellos llegar a una solucin lo ms rpido posible. Hemos querido compartir con todos nuestros clientes estas mejores prcticas para que sean aplicadas no solamente en los casos de soporte de Microsoft, sino en general en cualquier escenario de solucin de problemas tcnicos. El mtodo cientfico parte de la definicin de un problema, crea una hiptesis, recolecta los datos necesarios, analiza estos datos, entrega un reporte de lo que en los datos se encontr y valida o rechaza la hiptesis. Estos mismos conceptos los podemos aplicar como metodologa para la solucin de los problemas de soporte tcnico. De esta manera surgieron las cuatro etapas utilizadas por los ingenieros del grupo de soporte de Microsoft de Latinoamrica. Estas cuatro etapas son: Defining. Gathering. Analyzing. Fixing.

Fig. 1. Metodologa de resolucin de problemas

Estas estn representadas en la figura 1. Su representacin es cclica porque el proceso de resolucin se mueve a travs de las cuatro fases en secuencia con el objetivo de que en cada interaccin el problema sea acotado ms y ms hasta llegar a la solucin. La recomendacin es seguir las fases en secuencia y no omitir ninguna. Es muy difcil llegar al lugar a donde queremos ir si no definimos cual es dicho lugar. El proceso de resolucin de problemas debe siempre comenzar con la definicin del problema. A continuacin vamos a hablar de cada una de las etapas en detalle. Fase 1: Defining (Definicin) El primer paso es elaborar una buena definicin del problema. Depende de cmo definamos el problema, va a ser ms fcil o ms difcil solucionarlo exitosamente. La definicin del problema nos ayuda a definir tambin el criterio de solucin del mismo. Esto es lo que llamamos scope del problema. A menos que el problema este correctamente definido, es poco probable que sea encontrada una solucin satisfactoria. Existen varias tcnicas que pueden ser utilizadas durante esta etapa y que ayudan a nuestros ingenieros a definir un problema, entre ellas tenemos: Escuchar activamente. Realizar preguntas precisas. Parafrasear. Para quien ha interactuado anteriormente con nuestro grupo de soporte, seguramente estas tcnicas les son familiares. El objetivo es capturar la mayor cantidad de detalles e informacin que nos ayude a definir el problema de una manera precisa. Con base en la definicin del problema y el conocimiento de cmo el producto debera funcionar, el siguiente paso que realiza el ingeniero es crear una hiptesis acerca de que podra ser la causa del problema. Recordemos que una hiptesis es una declaracin que an no se ha establecido como cierta. En el caso de los ingenieros de soporte, diramos que es una aproximacin educada basada en experiencia, conocimiento, habilidades e intuicin. El crear una hiptesis nos ayuda a darle un enfoque a nuestro pensamiento y continuar con las siguientes fases. La fase de defining o definicin, nos debe dar como resultados: Una definicin clara del problema. El criterio bajo el cual se define la solucin del problema. Una o ms hiptesis.

Fase 2: Gathering (Recoleccin) Con base en la hiptesis creada, ahora s podemos comenzar a recolectar los datos que son necesarios para comprobar o refutar la hiptesis. Muchas veces tendemos a capturar informacin sin antes haber definido el problema y puede ser frustrante invertir tiempo en recolectar informacin que no ser usada. El primer objetivo de esta fase es definir un plan de accin efectivo para la recoleccin de los datos de tal manera que todos los datos necesarios sean recolectados en la primera vez. El segundo objetivo de esta fase es garantizar que la calidad de los datos es ptima antes de pasar al anlisis. Un buen plan de accin debe ser detallado, incluir informacin especfica de lo que se necesita y si es el caso, incluir explicaciones detalladas de como recolectar la informacin. Actualmente existen herramientas de soporte remoto que facilitan esta labor, caso que se necesite de ayuda para recolectar los datos. Despus de definir el plan de accin de cuales datos se necesitan y cmo van a ser recolectados, el siguiente paso es recolectar dicha informacin siguiendo el plan creado. Una buena prctica es tomar una pequea muestra de los datos para estar seguros que se est recolectando correctamente. Un ejemplo de este escenario son los logs del performance monitor. Se puede tomar una muestra por un periodo corto de tiempo para garantizar que los contadores estn trabajando como se espera. Antes que los datos sean analizados deben ser validados. La validacin consiste en responder las siguientes preguntas: Es leble la informacin? Por ejemplo un dump de memoria. El cliente puede revisar que es vlido antes de enviarlo al ingeniero usando herramientas como el dumpchk.exe. Los datos contienen informacin relevante? Por ejemplo en una captura de red. El cliente puede revisar con en Network Monitor que la captura incluye trfico entre las maquinas relevantes al problema. Estas pequeas acciones evitan invertir tiempo innecesario tanto del cliente como del ingeniero. La fase de gathering o recoleccin, nos debe dar como resultados: Un plan de accin detallado para recolectar los datos necesarios. Validacin de los datos recolectados. Fase 3: Analyzing (Analisis) El objetivo de esta fase es analizar la informacin recolectada en la fase anterior. Esta informacin es estudiada para confirmar o rechazar la hiptesis o hiptesis generadas en la primera fase. Analizar el problema implica aprender sobre el mismo lo ms que se pueda. En esta fase la experiencia en el tema es crtica as como tambin las herramientas usadas para el anlisis. Dentro de las acciones que un ingeniero de soporte realiza durante esta fase de anlisis estn:

 Separar los datos que son relevantes para el anlisis basado en la definicin del problema y en el conocimiento y experiencia sobre el tema. Buscar por evidencia obvia primero antes de invertir tiempo en un anlisis ms profundo. Para clarificar este punto, un ejemplo es revisar los logs de Event Viewer antes de tomar un dump completo de la mquina. Buscar por contenido ya existente en las bases de datos de conocimiento. Nuestros clientes podran realizar este paso buscando en el sitio de soporte de Microsoft y tambin revisando sus bases de datos de problemas internos. Realizar un anlisis ms profundo. Esto es, investigar los datos recolectados en detalle, intentar reproducir el problema, comparar los datos recolectados con relacin a un ambiente que est trabajando normalmente. Como resultado de este anlisis, debemos ser capaces de confirmar la hiptesis, hay suficiente evidencia que confirme la hiptesis y soporte un diagnostico; o por el contrario tenemos que rechazar la hiptesis. En caso que la hiptesis sea rechazada, tendremos que comenzar un ciclo, esto es, ir a la fase de definicin nuevamente. En este punto se debe considerar colaboracin o escalacin del problema al siguiente nivel. La fase de analyzing o anlisis, nos debe dar como resultados: Hiptesis confirmada por el anlisis de los datos. Resultado del anlisis de los datos. Posible causa raz identificada. Comunicacin a nivel de las personas involucradas informando el progreso. Fase 4: Fixing ( Solucin) En esta fase con base al anlisis realizado previamente, necesitamos elaborar un plan de accin para solucionar el problema. Este plan de accin de solucin debe considerar el impacto y los riesgos de las acciones sugeridas. De ser necesario se recomienda probar el plan de accin en un ambiente de pruebas y de no ser posible, incluir las medidas necesarias tales como tener un respaldo (backup), planes de contingencia, en caso que el plan de accin deba ser aplicado directamente a produccin. Como mejores prcticas para la solucin de problemas tcnicos, la experiencia nos ensea a: Si hay varias maneras de solucionar el problema o una solucin involucra varios pasos, aplicar un cambio cada vez y observar los resultados. Seguir los pasos de acuerdo a las instrucciones dadas y al orden recomendado. En caso de dudas sobre el plan de accin, preguntar antes de ejecutar.

Aqu podemos tener varias situaciones, que veremos a continuacin. Si despus de aplicar el plan de accin, los sntomas desaparecen, podemos considerar el problema como resuelto. Si el problema original est resuelto pero aparece un problema diferente, esto se debe manejar como un nuevo incidente de soporte e iniciar nuevamente con el ciclo de solucin. Si el problema contina, no hay cambio en los sntomas, debemos retornar a la fase de definicin y comenzar nuevamente. Escalacin al siguiente nivel debe ser considerara en esta situacin. Si el problema empeora (esta condicin es la menos deseada por supuesto!), escalacin al siguiente nivel debe ser considerada a este punto. La fase de fixing o solucin, nos debe dar como resultados la solucin al problema originalmente definido o la decisin de volver a la fase de defining o definicin nuevamente; obviamente considerando la posibilidad de involucrar recursos adicionales que nos ayuden a llegar a una solucin. Esperamos que este contenido les sea de utilidad y les ayude a solucionar los problemas siguiendo esta metodologa que hemos compartido con ustedes y que si de ser necesario tienen la necesidad de interactuar con nuestro grupo de ingenieros de soporte se les facilite el trabajo y puedan llegar a una solucin satisfactoria en conjunto lo ms rpido posible.