Los pasos estructurados para solucionar problemas

Las correcciones al azar hacen perder tiempo y, a veces, empeoran las cosas. Una metodología estructurada de resolución de problemas le proporciona un camino lógico y repetible desde el síntoma hasta la solución. CompTIA evalúa un proceso específico de siete pasos porque mantiene organizados a los técnicos, evita pasar por alto pistas y produce resultados que se pueden documentar y repetir. Seguir los pasos es más rápido que adivinar, incluso cuando una respuesta parece obvia.

El modelo de CompTIA consta de siete pasos:

• 1. Identificar el problema.
• 2. Establecer una teoría sobre la causa probable.
• 3. Poner a prueba la teoría.
• 4. Establecer un plan de acción.
• 5. Implementar la solución.
• 6. Verificar la funcionalidad completa.
• 7. Documentar los hallazgos, las acciones y los resultados.

Memorice este orden; el examen pregunta directamente sobre él.

Identifique el problema recopilando información de los usuarios, los registros y sus propias pruebas. Pregunte qué cambió, cuándo comenzó y a quién afecta. Cuestione lo obvio y reproduzca el problema si puede. Una descripción del problema clara y específica, como "no hay Internet desde la red inalámbrica del segundo piso", orienta todo lo que sigue. Una descripción vaga conduce a una solución vaga.

Establezca una teoría sobre la causa probable. Basándose en los síntomas, formule una hipótesis fundamentada sobre lo que está fallando. Comience por las causas más probables y sencillas, los llamados "frutos al alcance de la mano", antes de considerar causas poco habituales. Si un solo PC no tiene red, es más probable que haya un cable defectuoso que un error en un protocolo de enrutamiento. Puede tener varias teorías candidatas.

Ponga a prueba la teoría para determinar la causa. Realice una comprobación que confirme o descarte su hipótesis. Si se confirma, continúe. Si no, formule una teoría nueva y vuelva a probarla, o escale el problema a alguien con más conocimientos o acceso. Nunca empiece a corregir el problema antes de haber confirmado realmente la causa, ya que podría averiar componentes que funcionan.

Establezca un plan de acción e identifique los posibles efectos. Decida exactamente qué hará, en qué orden y qué podría salir mal. Considere el tiempo de inactividad, los usuarios afectados y un procedimiento de reversión por si la solución falla. La planificación evita que una corrección rápida en un dispositivo interrumpa accidentalmente un sitio entero. Los cambios más importantes requieren planes más amplios y cuidadosos.

Implemente la solución siguiendo su plan, o escale el problema si supera su autoridad o sus conocimientos. Cuando sea posible, haga un cambio cada vez para poder saber qué solucionó realmente el problema. Durante la implementación, respete las reglas de control de cambios y las ventanas de mantenimiento para interrumpir lo menos posible el tráfico de producción.

Verifique la funcionalidad completa del sistema y, si corresponde, implemente medidas preventivas. Confirme no solo que el síntoma original ha desaparecido, sino también que no se haya averiado nada más. Pida al usuario que realice una prueba y vuelva a comprobar los servicios relacionados. Si un cable defectuoso causó la interrupción, también podría etiquetar el tendido o sustituir el cable desgastado adyacente para evitar que vuelva a ocurrir.

Documente los hallazgos, las acciones y los resultados. Registre el síntoma, la causa, lo que hizo y el resultado. Una buena documentación agiliza la resolución del siguiente incidente similar, facilita el intercambio de conocimientos y crea un registro de auditoría. Este último paso se omite fácilmente bajo presión, pero es el que convierte una corrección puntual en conocimiento duradero para la organización.

Dentro del método, los técnicos suelen elegir una dirección utilizando el modelo OSI. Bottom-up comienza en la capa física (cables y enlaces) y avanza hacia arriba, por lo que resulta útil cuando se sospecha de un fallo grave. Top-down comienza en la aplicación y desciende, por lo que resulta útil cuando una aplicación se comporta mal pero la conectividad parece correcta. El enfoque de divide-and-conquer comienza en el centro para dividir el espacio del problema.

Evite los hábitos que rompen el método: cambiar varias cosas a la vez sin poder saber qué funcionó, omitir la verificación u olvidar documentar. También debe resistirse al sesgo de confirmación, es decir, al impulso de seguir creyendo en una teoría después de que las pruebas la contradicen. La disciplina de seguir cada paso, en orden, es lo que hace fiable la metodología bajo presión.

Compruebe sus conocimientos sobre el proceso.

Ha aprendido el método estructurado. Puntos clave:

• Siete pasos: identificar, elaborar una teoría, probar, planificar, implementar, verificar y documentar.
• Comience primero por las causas probables más sencillas.
• Confirme la causa antes de corregirla; escale el problema cuando sea necesario.
• Enfoques: bottom-up, top-down y divide-and-conquer.
• Verifique y documente siempre, incluso bajo presión.