Informasjonsteknologi problemløsning – De 6 prinsippene for vitenskapelig problemløsning

Denne artikkelen vil forklare en vitenskapelig tilnærming til problemløsning. Selv om det er skrevet for å ta opp informasjonsteknologirelaterte problemer, kan konseptene også være anvendelige i andre disipliner. Metodene, konseptene og teknikkene som er beskrevet her er ikke noe nytt, men det er sjokkerende hvor mange “problemløsere” som ikke klarer å bruke dem. I mellom vil jeg inkludere noen eksempler fra det virkelige liv.

Hvorfor gjetter problemløsere i stedet for å følge en vitenskapelig tilnærming til problemløsning? Kanskje fordi det føles raskere? Kanskje mangel på erfaring med effektiv problemløsning? Eller kanskje fordi det føles som hardt arbeid å gjøre det vitenskapelig? Kanskje mens du fortsetter å gjette og egentlig ikke løser, genererer du mer inntekt og legger til litt jobbsikkerhet? Eller kanskje fordi du bryter det første prinsippet for problemløsning: forstå problemet.

Prinsipp #1. Forstå det *virkelige* problemet.

Er det ikke åpenbart at før du kan løse, må du forstå problemet? Kan være. Men mesteparten av tiden vil løseren begynne å løse uten å vite det virkelige problemet. Det klienten eller brukeren beskriver som “Problemet” er normalt bare symptomet! “Min datamaskin vil ikke slå seg på” er symptomet. Det virkelige problemet kan være at hele bygget er uten strøm. “Hver gang jeg prøver å legge til et nytt produkt, får jeg en feilmelding” er symptomet. Her kan det virkelige problemet være “Bare de 2 siste produktene jeg prøvde å legge til ga feilen ‘Produktet finnes allerede'”. Et annet klassisk eksempel: “Ingenting fungerer”…

Du starter etterforskningen med å definere det “virkelige problemet”. Dette vil innebære å stille spørsmål (og noen ganger bekrefte dem), og gjøre noen grunnleggende tester. Still brukeren spørsmål som “når var siste gang det fungerte?”, “Hvor lenge har du brukt systemet?”, “Fungerer det på en annen PC eller en annen bruker?”, “Hva er den nøyaktige feilmeldingen? ” etc. Be om en screen-print av feilen hvis mulig. Din grunnleggende testing vil være å sikre at ende-til-ende-utstyret er oppe og går. Sjekk brukerens PC, nettverket, nettserveren, brannmurer, filserveren, databasebackend, osv. I beste fall vil du peke på problemet allerede. I verste fall kan du eliminere mange områder for årsaken til problemet.

Et eksempel fra det virkelige liv. Symptomet ifølge brukeren: “Systemet legger på på tilfeldige tidspunkter når jeg legger inn bestillinger”. Miljøet: Brukeren legger inn ordredetaljene på et skjema i en stormaskinapplikasjon. Når alle detaljene er fullført, vil brukeren ta av skjemaet. Stormaskinen sender deretter denne detaljen via kommunikasjonsprogramvare til et Oracle Client/Server-system ved anlegget. Oracle-systemet vil gjøre kapasitetsplanlegging og returnerer enten en feil eller en forventet ordredato tilbake til stormaskinsystemet. Dette problemet er ganske alvorlig, fordi du kan miste kunder hvis de prøver å legge inn bestillinger og systemet ikke aksepterer dem! For å forsøke å løse dette problemet begynte folk med å undersøke: 1) Lasten og kapasiteten til stormaskinmaskinvaren 2) Overvåking av nettverksbelastningen mellom stormaskinen og Oracle-systemet 3) Ansette konsulenter for å feilsøke kommunikasjonsprogramvaren 4) Feilsøking av Oracle-kapasiteten planleggingssystem Etter å ha brukt et par måneder klarte de ikke å løse problemet.

“Vitenskapelig problemløser” ble kalt inn. Det tok mindre enn en dag og problemet var løst! Hvordan? Løseren tilbringer dagen hos brukeren for å se hva det “virkelige problemet” var. Det ble funnet at problemet bare oppstår med eksportordrer. Ved å undersøke fangstskjermen og brukerhandlinger, ble det funnet at med eksportordrer er det siste feltet på skjemaet alltid tomt, og brukeren fant ikke dette feltet. Systemet ble ikke hengende, det ventet på at brukeren skulle trykke “tab” en annen gang. Problem løst. Det kan bemerkes at “Scientific Problem Solver” hadde svært begrenset kunnskap om stormaskinen, om ordrefangstsystemet, om kommunikasjonsprogramvaren og Oracles kapasitetsplanleggingssystem. Og dette bringer oss til prinsipp nr. 2.

Prinsipp #2. Ikke vær redd for å starte løsningsprosessen, selv om du ikke forstår systemet.

Hvor mange ganger har du hørt “Jeg kan ikke røre den koden, fordi den er utviklet av noen andre!”, eller “Jeg kan ikke hjelpe fordi jeg er en HR-konsulent og det er et finansproblem”? Hvis vaskemaskinen din ikke vil slå seg på, trenger du ikke være elektroingeniør, spesialist på vaskemaskinreparasjoner, tekniker eller hvilken som helst spesialist for å gjøre noen grunnleggende feilsøking. Kontroller at pluggen fungerer. Sjekk trip-bryteren osv. “Jeg har aldri sett denne feilen før” bør ikke stoppe deg fra å forsøke å løse. Med feilmeldingen og en Internett-søkemotor kan du få mange utgangspunkt.

I hvert komplekst system er det et par grunnleggende arbeidsprinsipper. System A som leser data fra system B kan være fryktelig komplekst (kanskje et laboratoriespektrometer som leser data fra en programmerbar logisk datamaskin via en RS-232-port). Men noen grunnleggende ting å teste for: Har begge systemene strøm? Er det en feilmelding i hendelsesloggen på et av disse systemene? Kan du “pinge” eller spore en nettverkspakke fra det ene systemet til det andre? Prøv en annen kommunikasjonskabel. Søk på internett etter feilmeldingen.

Når du har funnet ut hva problemet er, må du begynne å løse det. Noen ganger vil den første undersøkelsen peke deg direkte til løsningen (slå på strømmen, bytt ut den defekte kabelen osv.). Men noen ganger er det virkelige problemet komplekst i seg selv, så neste prinsipp er å løse det enkelt.

Prinsipp #3. Erobre det enkelt.

La oss starte denne delen med et eksempel fra virkeligheten. Under visse forhold vil en lagret prosedyre henge. Den lagrede prosedyren tar vanligvis omtrent en time å kjøre (når den ikke henger). Så utvikleren prøvde å feilsøke. Gjør noen endringer og vent en time til for å se om problemet er løst. Etter noen dager ga utvikleren opp og “Problem Solver” tok over. “Problemløseren” hadde til rådighet kunnskapen under hekseforhold den lagrede prosedyren ville henge. Så det var en enkel øvelse å lage en kopi av prosedyren, og deretter fjerne all unødvendig kode med denne kopien. Alle parametere ble endret med hardkodede verdier. Kodebiter ble utført om gangen, og resultatsettene ble deretter igjen hardkodet inn i kopien av prosedyren. I løpet av 3 timer var problemet løst. En uendelig løkke ble oppdaget.

Det “Problem Solver” gjorde, var å replikere problemet og samtidig forsøke å isolere koden som forårsaket problemet. Ved å gjøre det ble den komplekse (og tidkrevende) lagrede prosedyren noe raskt og enkelt.

Hvis problemet er inne i en applikasjon, oppretter du en ny applikasjon og prøver å simulere problemet i den nye applikasjonen så enkelt som mulig. Hvis problemet oppstår når en bestemt metode for en bestemt kontroll blir kalt, prøv å bare inkludere denne kontrollen i den tomme applikasjonen og kall den metoden med hardkodede verdier. Hvis problemet er med innebygd SQL i en C#-applikasjon, kan du prøve å simulere SQL inne i et Database Query-verktøy (som SQL*Plus for Oracle, Query Analyzer for SQL Server, eller bruk koden i MS Excel via ODBC til databasen ).

I det øyeblikket du kan replikere problemet på en enkel måte, er du mer enn 80 % på vei til å løse det.

Hvis du ikke vet hvor i programmet problemet er, bruk DEBUG.

Prinsipp #4. Feilsøk.

De fleste applikasjonsutviklingsverktøy kommer som standard med en debugger. Uansett om det er Macromedia Flash, Microsoft Dot Net, Delphi, eller et hvilket som helst utviklingsmiljø, vil det være en slags debugger. Hvis verktøyet ikke kommer som standard med en debugger, kan du simulere en.

Det første du vil gjøre med feilsøkeren er å finne ut hvor problemet er. Dette gjør du ved å legge til bruddpunkter på nøkkelområder. Deretter kjører du programmet i feilsøkingsmodus og du vil vite mellom hvilke bruddpunkter problemet oppsto. Drill ned og du vil finne stedet. Nå som du vet hvor problemet er, kan du “overvinne det enkelt”

En annen fin funksjon ved de fleste debuggere inkluderer muligheten til å se variabler, verdier, parametere osv. mens du går gjennom programmet. Med disse verdiene kjent på visse trinn, kan du hardkode dem inn i din “forenklede versjon” av programmet

Hvis et utviklingsverktøy ikke støtter feilsøking, kan du simulere det. Sett inn trinn i programmet som sender ut variabelverdier og “hei jeg er her”-meldinger enten til skjermen, til en loggfil eller til en databasetabell. Husk å ta dem ut når problemet er løst… du vil ikke at filsystemet skal være rotete eller fylt opp med loggfiler!

Prinsipp #5. Det er et vell av informasjon på databasens backend som vil bidra til å løse et problem.

“Problem Solver” ble kalt for å hjelpe til med å løse et veldig vanskelig problem. Et prosjekt var å migrere system fra en stormaskin til klient-server-teknologi. Alt gikk bra under testingen, men da systemene gikk i drift, var det plutselig ganske mange og ganske tilfeldige “General Protection Faults”. (GPF-feilen var den generelle feilfellen i Windows 95 og 98). Det ble forsøkt å forenkle koden, feilsøking ble forsøkt, men det var umulig å replikere. I LAB-miljøet ville ikke problemet oppstå! Feilsøking av sporingsmeldinger til loggfiler indikerte at problemet oppsto svært tilfeldig. Noen brukere opplevde det mer enn andre, men til slutt vil alle brukere få det! Interessant problem.

“Problem Solver” løste dette etter at han begynte å analysere databasens back-end. Ikke sikker på om det var tilfeldig eller fordi han systematisk beveget seg i riktig retning på grunn av en vitenskapelig tilnærming. Gjennom å spore hva som skjer på back-end-nivå, ble det funnet at alle disse applikasjonene skapte flere og flere forbindelser til databasen. Hver gang en bruker starter en ny transaksjon ble det opprettet en annen tilkobling til databasen. Summen av tilkoblingene ble først frigitt da applikasjonen ble stengt. Etter hvert som brukeren navigerte til nye vinduer inne i samme applikasjon, åpnes flere og flere tilkoblinger, og etter et spesifikt antall tilkoblinger vil applikasjonen få nok og deretter krasjer. Dette var en programmeringsfeil i en mal som ble brukt av alle utviklerne. Løsningen var å først teste om en markør til databasen allerede er åpen, før du åpner den igjen.

Hvordan sporer du på back-end-databasen hva som skjer? De viktigste databaseleverandørene har GUI-verktøy som hjelper deg med å spore eller analysere hvilke spørringer som sendes mot databasen. Den vil også vise deg når folk kobler til, kobler fra eller ikke var i stand til å koble til på grunn av sikkerhetsbrudd. De fleste databaser inkluderer også noen systemordboktabeller som kan spørres for å få denne informasjonen. Disse sporene kan noen ganger fortelle en hel historie om hvorfor noe svikter. Spørringskoden du henter fra sporingen kan være hjelp til å «forenkle søket». Du kan se på sporet om programmet får vellykket kontakt med databasen. Du kan se hvor lang tid det tar før en spørring utføres.

For å legge til prinsipp #2 (ikke vær redd for å starte…); du kan analysere denne sporingsinformasjonen, selv om du kanskje ikke vet noe om detaljene i applikasjonen.

Husk imidlertid at disse back-end-sporene kan legge en belastning på back-end-ressursene. Ikke la dem gå unødvendig lenge.

Prinsipp #6. Bruk friske øyne.

Dette er det siste prinsippet. Ikke bruk for mye tid på problemet før du ber om hjelp. Bistanden trenger ikke være fra noen som er eldre enn deg. Prinsippet er at du trenger et par friske øyne for et friskt perspektiv og noen ganger litt frisk luft ved å ta en pause. Den andre personen vil se og stille et spørsmål eller to. Noen ganger er det noe veldig åpenbart som ble savnet. Noen ganger bare ved å svare på spørsmålet får det deg til å tenke i nye baner. Dessuten, hvis du bruker timer på å se på den samme kodebiten, er det veldig enkelt å begynne å se over en dum feil. Mange økonomiske balanseproblemer løses over en øl. Det kan være en endring av natur, og/eller den avslappede atmosfæren som vil dukke opp løsningen. Kanskje er det det friske oksygenet som gikk til hjernen mens han gikk til puben. Kanskje det er fordi problemet ble diskutert med noen andre.

Konklusjon

Etter å ha lest denne artikkelen håper forfatteren at du vil prøve disse neste gang du støter på et problem å løse. Forhåpentligvis vil du ved å bruke disse seks prinsippene innse fordelene de gir, i stedet for å “gjette” deg frem til en løsning.

Leave a Comment