Le tue regole di risoluzione dei problemi, approccio alla risoluzione dei problemi? [chiuso]

Hai delle regole generali su cui ricorrere quando risolvi un problema di rete / hardware / software?

Ad esempio: "Isola la fonte del problema testando una periferica con un secondo computer" o "Rimuovo l'hardware possibile per accendere il dispositivo, quindi aggiungo i componenti uno alla volta fino a quando non riesco a riprodurre il problema" , eccetera.

Solo un elenco di punti che ho scritto per me stesso dopo aver combattuto con un problema per un po ':

1. Qual è il tuo obiettivo principale ? Dovrebbe essere dichiarato in modo chiaro e conciso. L'obiettivo dovrebbe essere molto particolare. Non dovrebbe essere generale. Preferibilmente una frase .
   
2. Qual è il tuo problema ?
   
3. C'è solo uno o più problemi ? Se ce ne sono molti, risolverli uno alla volta.
   
4. Prova a riprodurre il problema con condizioni diverse . Può essere riprodotto in tutte le condizioni possibili oppure no? Dice qualcosa sulla natura del problema?
   
5. Se si tratta di un problema urgente, esiste una soluzione alternativa ? Prova a trovare il maggior numero possibile di soluzioni alternative.
   
6. Prova a fare quante più ipotesi possibili su quale sia la causa del tuo problema.
   
7. Prova a provare le tue ipotesi, sperimenta il sistema.
   
8. Sii coerente con quello che stai cercando di fare. Fai una cosa alla volta.
   
9. Tieni traccia di ciò che stai facendo, di ciò che hai già provato.
   
10. Non deviare dal tuo obiettivo principale. Controlla costantemente se stai ancora risolvendo il tuo problema principale, non diverso.
    
11. Non fissare neanche.

C'era anche un grande elenco di regole di debug, era in un formato PDF con esempi e spiegazioni per ciascuna delle regole. Non sono riuscito a trovare rapidamente il PDF, ma penso che questo sia un poster dell'elenco:

• Se il problema è legato a Internet, è probabilmente il DNS.

• Se il problema è difficile da diagnosticare, probabilmente è la RAM.

• Se il problema riguarda una workstation Windows, è probabilmente più rapido reinventarlo.

• Se il problema è un venerdì, è probabilmente qualcosa di grave.

Mi piace ricorrere al metodo scientifico .

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

1. Definisci la domanda
2. Raccogliere informazioni e risorse (osservare)
3. Forma ipotesi
4. Esegui esperimento e raccogli dati
5. Analizzare i dati
6. Interpretare i dati e trarre conclusioni che fungono da punto di partenza per nuove ipotesi
7. Risultati del documento

Come regola generale, mi piace sempre provare a ricontrollare i miei presupposti di base. Ha corrente, è collegato, il cablaggio è buono? È molto fastidioso passare ore a cercare di esaminare un problema software quando si dispone di un cavo allentato.

Trovo molto importante durante la fase di creazione delle ipotesi trovare effettivamente quante più possibili cause del problema possibile. Quindi provo e scelgo idee da testare prima in base a quanto è facile testare e quanto è probabile l'idea.

È anche importante chiedere aiuto. Consultare i colleghi, il fornitore o chiunque sia il più informato sui sistemi in questione, se possibile. Non perdere molto tempo a girare le ruote su un problema se c'è qualcuno disponibile che può aiutarti a risolvere il problema.

O'Reilly ha un buon libro Strumenti per la risoluzione dei problemi di rete che ha una buona serie di passaggi da seguire che è molto simile al metodo scientifico. Ho trovato il libro molto utile e lo consiglio vivamente. Il libro presenta molti più dettagli e suggerisce molti strumenti utili.

Dagli strumenti per la risoluzione dei problemi di rete

1. Indica il tuo obiettivo
2. Definire il sistema
3. Identificare i possibili risultati
4. Identifica e seleziona ciò che misurerai
5. Se appropriato, identificare parametri e fattori di prova
6. Seleziona strumenti
7. Stabilire vincoli di misurazione
8. Rivedi il design sperimentale
9. Raccogliere dati
10. Analizzare i dati

Guarda anche:

• 3COM ha una guida alla risoluzione dei problemi
• Legge di Murphy - Tutto ciò che può andare storto, lo fa.
• Occam's_razor - A parità di altre condizioni, la soluzione più semplice è la migliore.

(Questi punti salienti sono parafrasati dal capitolo "Debugging" di "The Practice of System and Network Administration" )

Due cose da sapere:

1. Scopri come appare la versione "fissa". Preferibilmente, è possibile eseguire un comando che fornisce un determinato output quando le cose funzionano. Ad esempio: sto cercando di capire perché SSH richiede una password quando ho impostato le chiavi correttamente (o almeno così pensavo). Quindi il mio test è: "ssh servername uptime" e dovrebbe funzionare senza chiedere una password.

2. Descrivi il problema al giusto livello. Un utente che si lamenta di non poter eseguire il ping di un server non deve inviarti per eseguire e riparare il server. Il lavoro della persona non è sedersi e fare il ping di una macchina tutto il giorno. Vogliono eseguire una sorta di attività come utilizzare la macchina come server DNS. Esempio: una volta che un utente si è lamentato di non poter eseguire il ping di una macchina a metà del mondo. Passo la giornata a rintracciare gli amministratori di sistema in quella parte dell'azienda per scoprire cosa non andava in quella macchina. Fu disattivato ed erano in preda al panico perché pensavano che forse avevano spento la macchina sbagliata. Ho contattato l'utente e ho detto "Oltre a dover eseguire il ping di questa macchina, cosa ti piacerebbe farci?". Si è scoperto che voleva eseguire un determinato lavoro su di esso e se avesse seguito la procedura corretta i suoi compiti sarebbero stati reindirizzati automaticamente alla macchina sostitutiva. Avevo sprecato la mia intera giornata e il tempo dei amministratori di sistema locali. Un altro motivo per cui "Non riesco a eseguire il ping" non è la cosa giusta da testare: spesso i firewall sono configurati per eliminare i pacchetti di ping ma consentire ad altri pacchetti di passare. Metti alla prova quello che vuoi passare.

Due strategie:

1. Additivo: continua ad aggiungere componenti fino a quando il problema non si avvia. L'ultima cosa che hai aggiunto è il problema. Esempio: i browser Web non possono comunicare con un server. Tra il server e l'utente c'è un bilanciamento del carico, un firewall, una cache e il proxy Web locale dell'utente. Per prima cosa prova a inviare query direttamente al server, quindi tramite LB al server, quindi attraverso il firewall a LB al server, ecc. Ecc. Ogni volta che aggiungi un componente.

2. Sottrattivo: continuare a rimuovere i componenti fino a quando il problema non scompare. L'ultima cosa che hai rimosso è stato il problema: Esempio: una macchina con dozzine di carte non si avvia. Continuare a rimuovere le carte fino all'avvio della macchina.

Due pezzi di stupida fortuna:

1. Dimentica tutto ciò che ho detto. Il problema è causato dall'ultima modifica apportata al sistema. (funziona il 99% delle volte ... il problema è che il 99% delle volte non sai quale sia stata effettivamente l'ultima modifica)

2. Quando tutto il resto fallisce, cerca cose stupide. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Esempio: un pazzo problema non è stato spiegato. Quindi abbiamo controllato il file di configurazione: un utente lo aveva modificato copiandolo in una finestra di Windows, modificandolo e copiandolo di nuovo. Ora aveva una ^ M alla fine di ogni riga. Non l'abbiamo mai notato perché il nostro editor di testo ha nascosto silenziosamente questo fatto. Purtroppo, il software che legge il file di configurazione ha trasformato quelle ^ M in uno spazio senza interruzioni che ha rovinato tonnellate di altre procedure.

Pratiche generali che ricordo durante l'intero processo:

1. Scrivi tutto ciò che faccio.
2. Apporta una sola modifica alla volta.
3. Se possibile, invertire la modifica prima di provarne un'altra a meno che non vengano compiuti progressi definiti.

Durante la risoluzione dei problemi qui definisce la mia metodologia di base:

• Quando il sistema funziona e funziona bene, prima che ci sia un problema, provo a imparare a vedere cosa sta facendo. Joe Richards spiega perché molto meglio di me in questo breve spazio .
• Comincio con la soluzione più semplice. Ad esempio, nessuna connettività di rete? Controlla il livello fisico. Non posso dirti quante volte i problemi di connessione intermittente non sono stati un problema del server ma un cavo di rete che si trovava a metà o che era andato male.
• Cerco di catturare tutti i sintomi che posso vedere da tutte le fonti probabili prima di iniziare a fare cambiamenti.
• Eseguo test diagnostici preliminari. Ad esempio, quando mi viene detto che un server è inattivo, la prima cosa che faccio è usare ping e nbtstat (Windows) per verificarlo. Il problema potrebbe essere alla fine (prendere in prestito un vecchio detto del controllo tecnico dell'aeronautica).
• Non ho paura di fare la ricerca. Google, support.microsoft.com, eventid.net e siti simili sono tuoi amici.
• Non ho paura di chiedere aiuto alla comunità. Non solo siti come serverfault.com, ma ho un buon assortimento di persone di cui mi fido e rispetto su Twitter con cui tengo in contatto.
• Valuto le risposte che sto trovando con quello che vedo. Non presumo che nessuna soluzione sia quella giusta fino a quando non posso fare abbastanza considerazioni delle prove che sto vedendo con ciò che è riportato nella soluzione.

Atteggiamenti che cerco di tenere:

• La fiducia assoluta che causa ed effetto funziona e nulla è magico. Non sta succedendo nulla di strano, solo cose che non capisco.
• Assoluta fiducia nel fatto che se continuo a spingerlo, lo risolverò (questo può comportare portarlo a qualcuno più competente, imparare, chiedere aiuto, duro lavoro, ecc.).
• Brontolare di come un'installazione, un programma o uno scenario sia mal progettato o davvero stupido non aiuta, quindi non farlo. (Lo trovo difficile, brontolare è divertente).

Sono atteggiamenti che mi sono utili da tenere: mi impediscono di alzare le braccia in aria, dichiarare qualcosa di "bizzarro" e poi rinunciare o infelice perché sembra "irrisolvibile".

Modi in cui penso alla risoluzione dei problemi:

• I sistemi hanno molte parti, se sono collegati insieme o configurati casualmente, non funzioneranno come desiderato. Esistono una o due configurazioni molto specifiche che funzioneranno - di tutti i milioni di modi per impilare mattoni e metallo, solo alcuni sono ponti e solo uno o due sono ponti abbastanza buoni. La causa potrebbe essere un personaggio in un file di testo o un server guasto, ma ogni parte deve essere giusta perché l'intera cosa sia giusta. Devo essere disposto ad essere accurato e meticoloso, se necessario. I sistemi non possono fare "lo spettacolo deve continuare".
• Inizi con un intero sistema come una mappa, immagini una nuvola di probabilità fluttuante sulla mappa che rappresenta "dove si trova il problema" e il tuo lavoro consiste nell'utilizzare l'esperienza e trovare prove per allontanare la probabilità da alcune aree e verso altre e condensarlo fino a punti che sono posizioni problematiche ad alta probabilità, quindi attaccare quelli. Questo ritorna al punto di causa ed effetto: il problema è nel sistema, non è magico. È un problema che esiste quindi deve esistere da qualche parte.
• Tutto può essere impostato in qualsiasi modo si desideri. L'unico modo in cui possiamo definire un comportamento come "OK" e un altro come "un problema" è perché ciò che qualcuno sta ottenendo non è quello che vogliono. Devi capire cosa vogliono, cosa stanno ottenendo in modo chiaro e specifico.

Il processo di risoluzione dei problemi:

• Qual è il problema. Assicurati di vederlo accadere e di riprodurlo da solo in modo che non ci siano errori di comunicazione. Così spesso, quando arrivano a me, nel nostro helpdesk ci sono stati problemi con diverse persone, ma nessuno può spiegarmi quale sia realmente il problema.
• È di nuovo una bisection ricorsiva - dividi e conquista, ricerca binaria - ti viene in mente un test che dimostrerà se il problema è questo lato del test, o quel lato, e fai il test in modo che elimini il più possibile. Ripeti fino alla risoluzione.
• Non sapere se puoi evitarlo: meglio bloccare l'account del database e dimostrare che il problema si verifica ancora quando il database non è coinvolto piuttosto che passare ore a imparare come viene utilizzato il database.
• È fin troppo facile ritrovarmi a pensare "Non so cosa fare dopo". Notare quando ciò accade e tornare a venire con i test che individuano il problema.

Internet non funziona? Controlla il problema, scopri che è un sito Web che non riescono a raggiungere. I test rapidi riguardano la loro connessione Internet (funzionante), si carica per me (no). Test rapidi indicano che si tratta del sito. Vedendo che il problema si presenta per me, ho allontanato rapidamente la probabilità dal loro PC, browser, DNS, firewall dell'account dell'account utente, ecc.

Quindi il sito non si carica, e adesso? Non è ancora risolvibile, quindi cerca i luoghi in cui scolpire il problema in uno più piccolo. Il server è acceso? Fa ping? funziona il DNS? Sì. Il servizio risponde sulla porta 80? No. Il servizio è in esecuzione? No. Comincia? No. Fornisce errori nel registro / nei file di registro degli eventi? Sì! Cosa dicono?

Si tratta di una risoluzione dei problemi efficiente e veloce perché è incessantemente incentrato sul restringere l'ambito del problema. Se avessi accettato la loro relazione secondo cui Internet non funziona, sarei fuorviato nel ritenere che si sia verificato un errore di connessione. Se avessi accettato il mio primo avvistamento che non caricava per loro, avrei perso tempo sul loro computer pensando che fosse colpa loro.

Ritaglia pezzi di "cose ​​che non possono essere" il più grandi possibile.

Comprendi il sistema. Più conoscenza generale ho di un sistema, più diventa facile. Laddove ho una comprensione debole, i problemi sono più intimidatori, più difficili, più lenti e più probabilità di finire con una soluzione alternativa rispetto a una correzione o con una soluzione lenta e stupida (reinstallazione) rispetto a una correzione chirurgica piccola e precisa.

Generalmente chiedo "Cosa è cambiato che potrebbe aver causato questo problema"? La maggior parte dei problemi sono causati da modifiche a configurazioni valide note. Se riesci a isolare chi ha apportato la modifica, di solito ottieni la tua risposta.

Penso che sia un'abilità, non una scienza. Ci sono momenti in cui segui una strada sbagliata ma per la maggior parte:

• Avere una buona conoscenza di base di tutte le tecnologie associate (rete, hardware, sistema operativo, software, sviluppo, ecc.) Ti aiuterà ad eliminare alcuni di quei "percorsi sbagliati"
• pensa di base - non saltare allo scenario più complicato perché è nella tua testa, esegui la risoluzione dei problemi di base e lascia che ti guidi.

Una volta ho avuto il mio capo che mi chiamava con un ingegnere "senior" al telefono - mi stava dicendo che aveva un server che non era in grado di connettersi e aveva provato a cambiare il cavo ma ancora senza gioia. Potevo sentire un bip in sottofondo come un UPS a batterie. Gli ho chiesto se poteva vedere attività sull'interruttore, ha detto di no. Gli ho chiesto se il segnale acustico proveniva dall'UPS, ha detto di sì, gli ho chiesto se poteva vedere qualsiasi luce accesa nel rack ha detto di no ... Guarda oltre il tuo naso - aiuta!

Comincio controllando l'ovvio. C'è un messaggio di errore che spiega qual è il problema? Tutto è collegato correttamente? Non mi piace sprecare diverse ore a risolvere qualcosa che avrebbe potuto essere risolto in pochi minuti. Penso che sia possibile essere troppo metodici. Ho visto persone perdere un'intera giornata a riprodurre un problema, nonostante il fatto che ho detto loro esattamente quale fosse il problema. Non è quello per cui li pago.

Se la risposta non è ovvia, allinea alcuni sospetti e testali prima. Solo dopo aver testato i probabili sospetti è necessario testare i sospetti improbabili. Quindi puoi essere scientifico quanto vuoi.