Sus reglas de solución de problemas, enfoque para la solución de problemas? [cerrado]

¿Tiene alguna regla general a la que recurra cuando soluciona un problema de red / hardware / software difícil?

Por ejemplo: "Aíslo la fuente del problema probando un periférico con una segunda computadora" o "Elimino la mayor cantidad de hardware posible para encender el dispositivo, y luego vuelvo a agregar componentes uno por uno hasta que pueda reproducir el problema" etc.

Solo una lista de puntos que escribí para mí después de luchar con un problema por un tiempo:

1. ¿Cuál es tu objetivo principal ? Debería establecerse de manera clara y concisa. El objetivo debe ser muy particular. No debe ser general. Preferiblemente una oración .
   
2. Cual es tu problema ?
   
3. ¿Hay solo un problema o muchos ? Si hay muchos, resuélvalos uno a la vez.
   
4. Intenta reproducir el problema con diferentes condiciones . ¿Se puede reproducir en todas las condiciones posibles o no? ¿Dice algo sobre la naturaleza del problema?
   
5. Si es un problema urgente, ¿hay alguna solución ? Intenta encontrar la mayor cantidad de soluciones posibles.
   
6. Intente hacer tantas suposiciones como sea posible sobre cuál es la causa de su problema.
   
7. Intenta demostrar tus conjeturas, experimenta con el sistema.
   
8. Sea consciente de lo que está tratando de hacer. Haz una cosa a la vez.
   
9. Mantenga un registro de lo que está haciendo, lo que ya ha intentado.
   
10. No te desvíes de tu objetivo principal. Compruebe constantemente si todavía está resolviendo su problema principal, no uno diferente.
    
11. No te fijes tampoco.

También había una gran lista de reglas de depuración, estaba en formato PDF con ejemplos y explicaciones para cada una de las reglas. No pude encontrar rápidamente el PDF, pero creo que este es un póster de la lista:

• Si el problema está relacionado con Internet, probablemente sea el DNS.

• Si el problema es difícil de diagnosticar, probablemente sea la RAM.

• Si el problema es con una estación de trabajo de Windows, probablemente sea más rápido volver a crearla.

• Si el problema es un viernes, probablemente sea algo serio.

Me gusta recurrir al método científico .

De ( http://en.wikipedia.org/wiki/Scientific_method )

1. Define la pregunta
2. Recopilar información y recursos (observar)
3. Formular hipótesis
4. Realizar experimentos y recopilar datos
5. Analizar datos
6. Interpretar datos y sacar conclusiones que sirvan como punto de partida para nuevas hipótesis.
7. Resultados de documentos

Como regla general, siempre me gusta probar y verificar mis suposiciones básicas. ¿Tiene energía, está enchufado, el cableado es bueno? Es muy molesto pasar horas tratando de ver un problema de software cuando tienes un cable suelto.

Encuentro muy importante durante la fase de creación de hipótesis que realmente se me ocurran tantas causas posibles del problema como pueda. Luego trato de elegir ideas para probar primero en función de lo fácil que es probar y cuán probable es la idea.

También es importante obtener ayuda. Si puede, consulte a sus compañeros de trabajo, proveedor o al que tenga más conocimientos sobre los sistemas en cuestión. No pierdas mucho tiempo haciendo girar tus ruedas sobre un problema si hay alguien disponible que pueda ayudarte a resolver el problema.

O'Reilly tiene un buen libro Herramientas de solución de problemas de red que tiene un buen conjunto de pasos a seguir que es muy similar al método científico. El libro me pareció muy útil y lo recomiendo encarecidamente. El libro entra en muchos más detalles y sugiere muchas herramientas útiles.

Desde las herramientas de solución de problemas de red

1. Indica tu objetivo
2. Definir el sistema.
3. Identificar posibles resultados
4. Identifique y seleccione lo que medirá
5. Si es apropiado, identifique los parámetros y factores de la prueba
6. Seleccionar herramientas
7. Establecer restricciones de medición
8. Revisar diseño experimental
9. Recolectar datos
10. Analizar datos

Ver también:

• 3COM tiene una guía de solución de problemas
• La ley de Murphy : cualquier cosa que pueda salir mal, lo hace.
• Occam's_razor : en igualdad de condiciones, la solución más simple es la mejor.

(Estos aspectos destacados se parafrasean del capítulo "Depuración" de "La práctica de la administración de sistemas y redes" )

Dos cosas para saber:

1. Sepa cómo se ve la versión "fija". Preferiblemente, un comando que puede ejecutar que proporciona una cierta salida cuando las cosas funcionan. Por ejemplo: estoy tratando de averiguar por qué SSH solicita una contraseña cuando configuré las claves correctamente (o eso pensé). Entonces mi prueba es: "ssh servername uptime" y debería funcionar sin pedir una contraseña.

2. Describa el problema en el nivel correcto. Un usuario que se queja de que no puede hacer ping a un servidor no debe enviarlo a ejecutar y reparar el servidor. El trabajo de la persona no es sentarse y hacer ping a una máquina todo el día. Quieren realizar algún tipo de tarea, como usar la máquina como su servidor DNS. Ejemplo: una vez que un usuario se quejó de que no podía hacer ping a una máquina en la mitad del mundo. Me paso el día rastreando administradores de sistemas en esa parte de la compañía para averiguar qué estaba mal con esa máquina. Fue dado de baja y estaban en pánico porque pensaron que tal vez habían apagado la máquina incorrecta. Me puse en contacto con el usuario y le dije "además de tener que hacer ping a esta máquina, ¿qué le gustaría hacer con ella?". Resultó que quería ejecutar un determinado trabajo y si hubiera seguido el procedimiento adecuado, sus tareas se habrían redirigido automáticamente a la máquina de reemplazo. Había malgastado todo mi día y el tiempo de los administradores de sistemas locales. Otra razón por la que "No puedo hacer ping" no es lo correcto para probar: a menudo los cortafuegos están configurados para descartar paquetes de ping pero permiten el paso de otros paquetes. Prueba por lo que quieres pasar.

Dos estrategias:

1. Aditivo: siga agregando componentes hasta que comience el problema. Lo último que agregó es el problema. Ejemplo: los navegadores web no pueden hablar con un servidor. Entre el servidor y el usuario hay un equilibrador de carga, un firewall, un caché y el proxy web local del usuario. Primero intente enviar consultas directamente al servidor, luego a través del LB al servidor, luego a través del firewall al LB al servidor, etc., cada vez que agregue un componente.

2. Sustractivo: siga quitando componentes hasta que el problema desaparezca. Lo último que eliminó fue el problema: Ejemplo: una máquina con docenas de tarjetas no arrancará. Siga quitando las tarjetas hasta que la máquina arranque.

Dos trozos de tonta suerte:

1. Olvida todo lo que dije. El problema se debe al último cambio realizado en el sistema. (esto funciona el 99% del tiempo ... el problema es que el 99% del tiempo no sabes cuál fue el último cambio)

2. Cuando todo lo demás falla, busca cosas estúpidas. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Ejemplo: un problema loco simplemente no podía explicarse. Luego verificamos el archivo de configuración: un usuario lo editó copiándolo en un cuadro de Windows, editándolo y luego volviéndolo a copiar. Ahora tenía una ^ M al final de cada línea. Nunca nos dimos cuenta porque nuestro editor de texto silenciosamente ocultó este hecho. Lamentablemente, el software que leyó el archivo de configuración convirtió esos ^ Ms en un espacio sin interrupciones que arruinó toneladas de otros procedimientos.

Prácticas generales que recuerdo durante todo el proceso:

1. Escribe todo lo que hago.
2. Haga solo un cambio a la vez.
3. Si es posible, revierta el cambio antes de intentar otro a menos que se esté haciendo un progreso definitivo.

Durante la resolución de problemas aquí define mi metodología básica:

• Cuando el sistema está funcionando correctamente, antes de que haya un problema, trato de aprender a ver qué está haciendo. Joe Richards explica por qué mucho mejor de lo que podría en este corto espacio .
• Comienzo con la solución más simple. Por ejemplo, ¿no hay conectividad de red? Comprueba la capa física. No puedo decirte cuántas veces los problemas de conexión intermitente no fueron un problema del servidor, sino un cable de red que estaba medio conectado o que había salido mal.
• Intento capturar todos los síntomas que puedo ver de todas las fuentes probables antes de comenzar a hacer cambios.
• Realizo pruebas de diagnóstico preliminares. Por ejemplo, cuando me dicen que un servidor está inactivo, lo primero que hago es usar ping y nbtstat (Windows) para verificar eso. El problema podría estar en el extremo distante (tomar prestado un viejo dicho de control técnico de la Fuerza Aérea).
• No tengo miedo de hacer la investigación. Google, support.microsoft.com, eventid.net y sitios como ese son tus amigos.
• No tengo miedo de pedir ayuda a la comunidad. No solo sitios como serverfault.com, sino que tengo una buena variedad de personas en las que confío y respeto en Twitter con las que me mantengo en contacto.
• Evalúo las respuestas que estoy encontrando con lo que estoy viendo. No supongo que ninguna solución sea la correcta hasta que pueda hacer suficientes consideraciones sobre la evidencia que estoy viendo con lo que se informa en la solución.

Actitudes que intento mantener:

• La absoluta confianza de que causa y efecto funciona y nada es mágico. No pasa nada que sea realmente extraño, solo cosas que no entiendo.
• Confianza absoluta de que si sigo presionándolo, lo resolveré (esto puede implicar llevarlo a alguien más conocedor, aprender, pedir ayuda, trabajo duro, etc.).
• Quejarse de cómo una configuración, programa o escenario está mal diseñado o es realmente estúpido simplemente no ayuda, así que no lo hagas. (Me parece difícil, quejarse es divertido).

Estas son actitudes que son útiles para mí: me impiden lanzar mis brazos en el aire, declarar algo "extraño" y luego rendirme o sentirme infeliz porque se siente "irresoluble".

Formas en que pienso sobre la resolución de problemas:

• Los sistemas tienen muchas partes, si están conectados entre sí o configurados al azar, entonces no funcionarán como se desea. Hay una o dos configuraciones muy específicas que funcionarán: de todas las millones de formas de apilar ladrillos y metal, solo unas pocas son puentes y solo una o dos son puentes suficientemente buenos. La causa podría ser un carácter en un archivo de texto o un servidor fallido, pero cada parte debe ser correcta para que todo sea correcto. Necesito estar dispuesto a ser minucioso y meticuloso si es necesario. Los sistemas no pueden hacer "el show debe continuar".
• Comienzas con un sistema completo como un mapa, imaginas una nube de probabilidad flotando sobre el mapa que representa "dónde está el problema" y tu trabajo es usar la experiencia y encontrar pruebas para alejar la probabilidad de algunas áreas y hacia otras y para condensarlo en puntos que son ubicaciones de problemas de alta probabilidad, luego atacarlos. Esto vuelve al punto de causa y efecto: el problema está en el sistema, no es mágico. Es un problema que existe, por lo que debe existir en alguna parte.
• Cualquier cosa se puede configurar de la manera que cualquiera quiera. La única forma en que podemos definir un comportamiento como "OK" y otro como "un problema" es porque lo que alguien está obteniendo no es lo que quiere. Debes entender lo que quieren, lo que obtienen de manera clara y específica.

El proceso de resolución de problemas:

• Cuál es el problema. Asegúrese de ver que sucede y puede reproducirlo usted mismo para que no haya errores de comunicación. Muy a menudo, los problemas han pasado por varias personas en nuestro servicio de asistencia para cuando llegan a mí, pero nadie puede explicarme cuál es realmente el problema.
• Es una bisección recursiva de nuevo: divide y vencerás, búsqueda binaria. Se te ocurre una prueba que demostrará si el problema está en este lado de la prueba, o en ese lado, y haces la prueba para que elimine lo más posible. Repita hasta que se resuelva.
• No aprenda si puede evitarlo: es mejor bloquear la cuenta de la base de datos y demostrar que el problema aún ocurre cuando la base de datos no está involucrada que pasar horas aprendiendo cómo se usa la base de datos.
• Es demasiado fácil encontrarse pensando "No sé qué hacer a continuación". Observe cuándo sucede eso y vuelva a encontrar pruebas que ubiquen el problema.

¿Internet no funciona? Comprueba el problema, encuentra que es un sitio web al que no pueden acceder. Las pruebas rápidas implican su conexión a Internet (en funcionamiento), ¿me carga (no)? Las pruebas rápidas apuntan a que es el sitio. Al ver que el problema me sucede, he alejado rápidamente la probabilidad de su PC, navegador, DNS, firewall de la oficina de cuentas de usuario, etc.

Entonces el sitio no se carga, ¿y ahora qué? Eso aún no se puede arreglar, así que busque lugares para dividir el problema en uno más pequeño. ¿Está encendido el servidor? ¿Hace ping? funciona DNS? Sí. ¿Responde el servicio en el puerto 80? No. ¿Se está ejecutando el servicio? No. ¿Comienza? No. ¿Da errores en el registro de eventos / archivos de registro? ¡Sí! ¿Qué dicen ellos?

Esta es una solución de problemas eficiente y rápida porque se enfoca implacablemente en reducir el alcance del problema. Si aceptara su informe de que Internet no funciona, me equivocaría al pensar que es un fallo de conexión. Si aceptara mi primer avistamiento de que no se carga para ellos, perdería el tiempo en su computadora pensando que es la culpa.

Forme trozos de "cosas que no pueden ser" lo más grande posible.

Comprende el sistema. Cuanto más conocimiento general tengo sobre un sistema, más fácil se vuelve. Donde tengo una comprensión débil, los problemas son más intimidantes, más difíciles, más lentos y más propensos a terminar con una solución alternativa que una solución, o con una gran solución lenta tonta (reinstalar) que una solución quirúrgica pequeña y precisa.

En general, pregunto "¿Qué ha cambiado que podría haber causado este problema"? La mayoría de los problemas son causados ​​por cambios en las configuraciones buenas conocidas. Si puede aislar quién hizo el cambio, generalmente obtiene su respuesta.

Creo que es una habilidad, no una ciencia. Hay momentos en los que va por el camino equivocado, pero en su mayor parte:

• Tener una buena comprensión básica de todas las tecnologías asociadas (red, hardware, sistema operativo, software, desarrollo, etc.) lo ayudará a eliminar algunas de esas "rutas equivocadas"
• piense básico: no salte al escenario más complicado porque está en su cabeza, realice su solución de problemas básicos y deje que lo guíe.

Una vez hice que mi jefe me llamara con un ingeniero "senior" en el teléfono; me decía que tenía un servidor que no podía conectarse y que había intentado cambiar el cable pero todavía no era divertido. Podía escuchar un pitido en el fondo como un UPS con baterías. Le pregunté si podía ver actividad en el interruptor, dijo que no. Le pregunté si el pitido provenía del UPS, dijo que sí, le pregunté si podía ver alguna luz encendida en el estante y dijo que no ... Mira más allá de tu nariz, ¡ayuda!

Comienzo comprobando lo obvio. ¿Hay un mensaje de error que explique cuál es el problema? ¿Está todo conectado correctamente? No me gusta perder varias horas resolviendo problemas que podrían haberse resuelto en unos minutos. Creo que es posible ser demasiado metódico. He visto a personas desperdiciar un día entero reproduciendo un problema a pesar de que les dije exactamente cuál era el problema. Eso no es lo que les pago.

Si la respuesta no es obvia, alinee a algunos sospechosos y pruébelos primero. Solo después de evaluar a los sospechosos probables, debe evaluar a los sospechosos poco probables. Entonces puedes ser tan científico como quieras.