[In deze les gaan we het hebben over stap
twee van de CompTIA methodologie voor probleemoplossing.
Dit is stap twee van zes, en in stap twee
willen we een theorie van waarschijnlijke oorzaak vaststellen
en het voor de hand liggende in twijfel trekken.
Als het nodig is, ga je ook extern of intern onderzoek
doen op basis van de symptomen die je waarneemt.
Dus als we het hebben over het vaststellen van een theorie
van waarschijnlijke oorzaak, proberen we te raden wat we denken dat
het probleem is op basis van alle symptomen
die we tot nu toe hebben waargenomen.
Als we goede antwoorden hebben gekregen op onze eerste
vragen van onze eindgebruikers, helpt dit ons bij het
bepalen van de ernst van
het probleem, zoals hoeveel mensen er last van
hebben en hoe erg het is, evenals een ruw idee van wat
we moeten onderzoeken, zoals is dit een
hardwareprobleem?
Is het een softwareprobleem?
Is het een probleem met het besturingssysteem of met de applicatie
of misschien met het stuurprogramma?
Dit zijn allemaal dingen die we moeten
uitzoeken en door al die eerste vragen te
stellen en het probleem te
identificeren, zouden we nu een heleboel gegevens moeten
hebben om onze zaak op te bouwen en uit te zoeken met welke theorie
we verder willen gaan om dingen op te lossen.
Als we het hebben over het vaststellen van een theorie
van waarschijnlijke oorzaak, moeten we het hebben
over wat waarschijnlijke oorzaak is.
Nou, als we het hebben over waarschijnlijke
oorzaak, hebben we het over alle verschillende mogelijke
oorzaken die kunnen zijn gebeurd, maar welke is het meest waarschijnlijk?
Het is bijvoorbeeld mogelijk dat aliens naar beneden kwamen en de bits en
bits op je computer door elkaar gooiden, maar het is waarschijnlijk
niet erg waarschijnlijk.
Dus ik denk niet dat dat mijn waarschijnlijke oorzaak
is, ook al is het misschien een zeer onwaarschijnlijke mogelijke oorzaak.
Houd daar dus rekening mee.
Als je nadenkt over waarschijnlijke oorzaak,
moet je echt bij jezelf te rade gaan:
wat is het meest waarschijnlijke?
Want er zijn waarschijnlijk drie of vier
dingen die het kunnen zijn en je wilt de
meest mogelijke selecteren wanneer we dat eerst gaan proberen,
het uitzoeken en als het het probleem niet oplost,
kunnen we later terugkomen en nummer
twee, nummer drie, nummer vier proberen totdat we
precies weten wat er mis was.
Onthoud dat het idee hier is om het op een systematische manier
te doen, zodat we geen mogelijke problemen over
het hoofd zien en het toch zo efficiënt
en effectief mogelijk doen.
Als ik bijvoorbeeld een gebruiker had die video's aan het
bekijken was op Netflix en die ineens niet meer werkte, dan
kan dat verschillende redenen hebben.
Het kan zijn dat hun tv is uitgezet, misschien hebben ze hun elektriciteitsrekening
niet betaald Het kan zijn dat hun internetservice
is uitgevallen.
Het kan zijn dat Netflix down is, of het kan het feit zijn dat hun
draadloze netwerk dat verbinding
maakt tussen hun tv die Netflix kijkt en hun netwerk
om op het internet te komen niet langer
zendt en dat veroorzaakt
een verbroken verbinding.
Dit is het idee.
Er zijn veel problemen en nu moeten we er een
uitkiezen waarvan we denken dat die het meest waarschijnlijk is
en dat is de waarschijnlijke oorzaak waar we achteraan gaan.
Ook hier wil ik er altijd aan denken om het voor de hand liggende in twijfel te trekken.
Als je denkt aan iets als Netflix,
dan is dat een heel groot bedrijf dat er heel goed in
slaagt om hun servers bijna altijd
in de lucht te houden.
Het is dus waarschijnlijk minder waarschijnlijk dat Netflix
down is dan dat er een probleem is met je systeem
of je internetverbinding.
En dus wil je misschien eerst die dingen controleren
voordat je Netflix en hun servers de schuld gaat geven.
Naast het vaststellen van je theorie en het kiezen
van je waarschijnlijke oorzaak zullen
we ook intern of extern onderzoek doen op basis van de
symptomen die we zien.
Als ik bijvoorbeeld te maken heb met dit Netflix-voorbeeld, is
een van de gemakkelijkste dingen die ik
kan doen om te zien of het mijn probleem is of dat van Netflix,
online gaan naar een site als Downdetector en netflix
intypen. com.
Die website houdt bij en rapporteert over andere gebruikers die zeggen dat
verschillende websites up of down zijn.
En dus als je denkt dat Netflix down is, kun
je gaan kijken op Downdetector en
zien of andere mensen hetzelfde probleem hebben.
Dit helpt ons weer om te controleren of onze
waarschijnlijke oorzaak de echte oorzaak is of dat
we een andere waarschijnlijke oorzaak moeten vinden.
Daarnaast zul je als technicus niet alles weten,
maar je moet op zijn minst in staat zijn om uit
te zoeken hoe je antwoorden kunt vinden.
Ik doe dit bijvoorbeeld al meer dan 20 jaar en ik kan
je vertellen dat ik nog steeds niet
alles over ze weet.
Dat gezegd hebbende, kan ik bijna elk probleem oplossen
dat je me voorlegt, omdat ik weet hoe ik onderzoek moet doen.
Als iemand zegt dat er dit probleem
of dit symptoom of deze foutcode is, kan ik
die dingen opzoeken omdat Google en andere
zoekmachines hier echt je beste vriend zijn.
Je zult merken dat veel van de dingen die je
dagelijks doet beantwoord kunnen worden door Google
en meestal zal het het eerste, tweede of derde
resultaat in Google zijn als je goed zoekt.
Wees dus niet bang om onderzoek te doen op
basis van de symptomen die je waarneemt.
Je wilt die machine ook bekijken en fysiek
inspecteren terwijl je probeert
je theorie vast te stellen en te testen.
Als je bijvoorbeeld naar de machine gaat,
kijk je ernaar en luister je.
Hoor je de ventilator draaien?
Hoor je een klikgeluid of
een knarsend geluid van de harde schijf?
Ruik je iets dat brandt?
Al deze dingen zijn symptomen en aanwijzingen
om je te vertellen wat er mis is met dat systeem.
Als je bijvoorbeeld een brandlucht ruikt, kan het
zijn dat je processor of een van de onderdelen
op je moederbord beschadigd is.
Als je een klikkend of knarsend geluid hoort,
dan weet je dat er iets mis is
met je harde schijf.
Als je een traditionele mechanische harde schijf
gebruikt in dat systeem.
Als je hoort dat er geen ventilator
draait, kan dat een stroomprobleem
zijn of een kapotte ventilator.
Dit zijn allemaal dingen die je kunt
ontdekken door die fysieke inspectie uit te voeren.
Een ander ding om in gedachten
te houden is dat soms wanneer je het systeem gaat repareren
het symptoom dat je oorspronkelijk had er niet meer is en dus wil
je misschien proberen het probleem te reproduceren.
Dit gebeurt vaak in grote organisaties
als je voor hun helpdesk of supportsysteem werkt.
Bij een organisatie waar ik werkte, duurde het bijvoorbeeld
meestal een tot twee dagen voordat ze een
technicus naar je bureau stuurden om
je computer te repareren.
Dus als je vandaag een probleem hebt gehad, zoals een programma dat vastloopt,
dan blijf je daar niet twee dagen zitten zonder te werken.
In plaats daarvan ga je waarschijnlijk je machine opnieuw
opstarten, je gaat een workaround
proberen en je gaat weer aan het werk waar je kunt,
terwijl je wacht tot iemand het probleem dat je
hebt als hoofdoorzaak komt oplossen.
In die tijd doe je andere dingen en kunnen
er andere symptomen optreden waarover
je de supporttechnicus kunt vertellen.
Aan de andere kant van de vergelijking,
als je als supporttechnicus binnenkomt om iemands
probleem op te lossen en ze hebben een dag
of twee dagen geleden een ticket ingediend, dan hebben ze al
andere dingen in dat systeem gedaan.
Je gaat dus proberen om het probleem dat ze aanvankelijk
hadden opnieuw te creëren om te
zien of je opnieuw een foutmelding krijgt of
dat die andere symptomen zich voordoen.
Sommige problemen zullen intermitterend zijn, maar de
meeste problemen kunnen gereproduceerd worden.
Dus als je het kunt reproduceren,
geeft je dat meer informatie en kun je
uitzoeken of je de juiste
waarschijnlijke oorzaak hebt die
je probeert op te lossen.
Iets anders waar je aan moet denken als je onderzoek
doet, is dat je niet alleen online onderzoek kunt
doen, maar ook in het systeem zelf.
Elk systeem heeft zijn eigen systeemdocumentatie.
Het heeft installatie- en gebeurtenislogboeken,
het heeft diagnostische gereedschappen om uit te zoeken
wat werkt en wat niet werkt.
En al die dingen maken deel uit van dat interne onderzoek om meer
te weten te komen over het systeem
en wat de waarschijnlijke oorzaak is van
die specifieke storing of dat probleem.
En tot slot, als iemand anders al aan dat systeem
heeft gewerkt, wil je met hen praten en
uitzoeken wat zij hebben gedaan.
Als je in een klein bedrijf werkt en
je bent de enige technicus, dan ben
je waarschijnlijk de enige die de machines repareert.
Maar als je voor een grote organisatie werkt,
zijn er misschien 20, 30, een paar honderd andere mensen die deze tickets
doen en als iemand anders al
aan dat systeem heeft gewerkt en het niet heeft
kunnen oplossen en het aan
jou doorgeeft, moet je nu uitzoeken
wat ze al hebben gedaan?
Wat hebben ze al aangeraakt?
Of als deze persoon zegt: "Weet
je, ik heb veel problemen gehad met deze computer.
U bent de derde technicus in vier maanden
die het moet komen repareren? Laten we ook met de andere technici
gaan praten en uitzoeken wat zij hebben gedaan. Wat
dachten zij dat het probleem
was en wat hebben ze geprobeerd
om het op te lossen?
Omdat je niet precies hetzelfde wilt doen omdat
het waarschijnlijk niet gaat werken
omdat het de vorige twee of drie keer ook niet werkte
en je de klant alleen maar boos maakt omdat hij
het gevoel heeft dat je tijd verspilt door
hetzelfde te doen als wat de ander vorige week
of vorige maand deed.
Dus onthoud bij stap nummer twee dat je hele doel bij stap nummer twee is
om een theorie van waarschijnlijke oorzaak vast te stellen
en dat je altijd eerst de meest voor de hand liggende dingen
in twijfel wilt trekken.
Als je het antwoord niet weet,
zoek het dan op met behulp van externe
documentatie zoals het internet of intern onderzoek
zoals het systeem zelf, diagnostische tools en de logboeken
van het systeem.