Troubleshooting Mistakes (Finnish Translatuon by Jukka Paulin of http://www.jukkasoft.fi/wordpress)

Ongelmanratkaisu lähtee liikkeelle ydinongelman tunnistamisesta, mikä ei aina ole helppoa edes alan ammattilaisille. Ydinongelman tunnistaminen ei taatusti ole helppoa peruskäyttäjälle, joten kun saat käyttäjältä apupyynnön puhelimitse (oletamme, että olet ammatiksesi tietokoneongelmia ratkova), puhelimessa kuulemasi kuvaus ei välttämättä vastaa todellisuutta. Emme tarkoita, että käyttäjä olisi tyhmä, itsepäinen tai huolimaton (rehellisyyden nimissä on sanottava, että jotkut ovat juuri sellaisia), vaan yksinkertaisesti hän on saattanut tulkita ongelman näkyvät oireet väärin, eikä ole nähnyt asian ytimeen - todellista ongelman aiheuttajaa.

Ammattilaiset voivat mennä vipuun aivan samalla tavalla. Urani aikana olen saanut useita soittoja, joissa soittaja kuvailee itsensä ammattitaitoiseksi Windows-ylläpitäjäksi, mutta samaan hengenvetoon pahoittelee ettei ymmärrä Unixista mitään. Joskus keskustelu etenee helposti, ja ongelma tulee ratkaistuksi, kun soittaja saa lyhyen opastuksen Unix-maailmasta. Toisinaan taas soittaja on todellakin törmännyt kovaan ongelmaan, jonka ratkaisemiseksi vaadittaisiin vuosien kokemus.

Näiden lisäksi on aivan erityyppisiä tukitilanteita: esimerkiksi tietokone, joka on kerta kaikkiaan täysin mykkä - se ei käynnisty, käyttöjärjestelmän latautumisesta puhumattakaan. Etupaneelin ja näppäimistön valot ovat pimeinä. BIOS ei vilauta tekstejään, kovalevy ei käynnisty ja kotoisat piippausäänetkin loistavat poissaolollaan. Kyseessä ei siis ole Linuxin tai Unixin buuttausongelma, ainakaan vielä. Ja tässä sitä ollaan -- langan toisessä päässä itseään osaavaksi kutsuva Windows-tukihenkilö, joka ihmettelee mitä pitäisi tehdä. Parempi kysymys olisi itse asiassa, että miten asia minuun liittyy? Voihan toki olla, etta kyseessä on sittenkin Unix-asia. Ehkä tässä tilanteessa tarvitaan tiedon palauttamiseen erikoistunutta ammattilaista, ja tarkemmin ottaen sellaista joka tuntee nimenomaan Unixin ja Linuxin tiedostojärjestelmät. Vaikka ongelman ytimessä olisi vain puuttuva buuttisektori, sen korjaaminen vaatii eri toimenpiteet riippuen koneen käyttöjärjestelmästä. Mutta palatakseni kysymykseen, mistä tässä vaiheessa on kyse? Vastaus: matalan tason laitteisto-ongelmasta! Kenties rikkoutunut emolevy, virtalähde tai viallinen/puuttuva kaapeli. Joka tapauksessa asialla ei ole mitään tekemistä Linuxin tai Unixin kanssa.

Jos asiakkaasi ei ole erityisen taitava tietotekniikassa, muista aina että itsestäänselviä asioita ei ole olemassa. Esimerkiksi vaikka asiakas tietäisi, että tietokoneen kovalevy tallentaa sekä käyttöjärjestelmän tiedostot että käyttäjän omat työtiedostot, hän ei välttämättä tiedä että BIOSin ruudulla näkyvät viestit tulevat ROM-muistipiireiltä, eikä kovalevyltä. Sinulle on kaksi aivan eri asiaa a) tietokone joka näyttää BIOS-tekstit mutta ei suostu jatkamaan siitä eteenpäin, kuin
b) tietokone joka ei edes näytä BIOS-tekstejä
, mutta huomaa että asiakkaasi silmissä nämä tapaukset saattavat näyttää samoilta. Oleellista on siis ymmärtää asiakkaasi tietoteknisen osaamisen taso, ja sen perusteella tulkita eri tavalla ongelman kuvauksia.

Mutta tiedät toki tuon. Ja tiedät myös sen, että inhimillisistä syistä johtuen asiakas ei aina välttämättä myönnä tekemiään virheitä. Erehtyminen on normaalia, mutta sen myöntäminen voi joskus olla kiusallista. Siis suhtaudu kuulemaasi aina pienellä varauksella, ja päättele itse mikä todellinen ongelma on. Muista: sinä olet ammattilainen. ammattilainen.

Totuuden nimissä on sanottava, että myös ammattilaiset tekevät virheitä. Joskus se, mitä luulet tietäväsi, voi haitata ongelmanratkaisua enemmän kuin se mitä et tiedä. Vai oletanko vain liikaa oman kokemukseni perusteella? Jos kuulut niihin harvinaisiin yksilöihin, jotka eivät koskaan tee virheitä, sinulla on kaksi vaihtoehtoa: voit lopettaa lukemisen, tai lukea artikkelin loppuun rinta rottingilla, tietäen ettet itse sortuisi moiseen.

Muistan ensimmäisen tekemäni ison arviointivirheen. Sen johdosta menetin hyvän asiakkaan - en siksi, että he olisivat suuttuneet minulle, vaan siksi että suosittelin asiakkaan vaihtamaan sellaiseen softaan ja laitteistoon jota en itse tue työssäni. Syy tähän oli se, että luulin käytössä olevan käyttöjärjestelmän ja softan tulleen suorituskyvynsä rajoille. Asiakas ajoi Glovia-nimistä tuotannonohjausjärjestelmää (ERP) 80386-pohjaisella SCO Unixilla. Käyttäjiä oli vain noin 20, mutta ohjelmakoodi taustalla oli paisunut vuosien saatoessa monimutkaiseksi, ja sen johdosta järjestelmä hidastui merkittävästi. Yritin lisätä swap-levyä, keskusmuistia, ja kokeilin kaikkea mahdollista mieleeni juolahtavaa - mutta ei, homma meni vain huonompaan suuntaan. Koska asiakkaan oma Glovia-ohjelmoija lisäsi jatkuvasti koodiin uusia toiminnallisuuksia, oletin että nimenomaan nämä hidastivat koko järjestelmää. Sitä paitsi näin omin silmin systeemin suorituskykyä mittaavasta SAR-työkalusta, että prosessorin suorituskyky ja kovalevyn I/O -luvut olivat kriittisellä tasolla. Rehellisesti sanoen päätin luovuttaa, ja hyväksyin sen mitä Glovia-ohjelmistojen valmistajakin sanoi: päivittäkää laitteistoympäristö suorituskykyisempään HP/UX järjestelmään. Ja niin asiakas teki, ja suorituskykykin palasi hyväksyttävälle tasolle. Mutta koska en tuntenut HP/UX:ää kovin hyvin, toinen konsultti astui tilalleni jatkamaan. Olin tyytyväinen tilanteeseen loppujen lopuksi - olin tehnyt oikean ratkaisun, ja asiakkaita oli yhden menettämisestä huolimatta aivan riittävästi. Kaikki osapuolet tyytyväisiä, joten nostetaan kytkintä, ajattelin.

Mutta kuinka väärässä olinkaan! Koska oletin, että uusien ominaisuuksien lisääminen laskee suorituskykyä, en tutkinut ongelmaa tarpeeksi tarkkaan. Olin ajanut joitakin kertoja 'ps':llä prosessien suoritusten tiedot näkyville, mutten huomannut erästä erittäin tärkeää kohtaa. Gloviaan liittyvien prosessien lista oli niin valtaisa, etten nähnyt todellista elefanttia posliinikaupassa. En nimittäin huomannut MMDF-postijärjestelmän prosessia nimeltään 'deliver'. Yritin vain jäljittää sellaisia prosesseja, joiden saama suoritinaika nousee juuri nyt. Otin kaksi 'ps' tilannekuvaa, ja tuotin 'diff':llä niiden erotuksen (kts. lisätietoa täältä, englanniksi). Erotuslistaan sain todellakin ne prosessit, jotka olivat aktiivisesti käynnissä (lisäten niiden saamaa suoritinajan lukua), mutta listan luomisen ajoitus oli epäonnistunut. Puhtaasti sattuman sanelemana nyt kävi niin, että 'deliver' -prosessi ei ollut ajossa sinä välisenä aikana, kun aloitin ja lopetin prosessien syynäämisen. Vaikka deliver kulutti kaiken kaikkiaan tuhottomasti suoritinaikaa, se ei tehnyt niin juuri nyt! Niinpä en myöskään osannut kiinnittää huomiota tähän todelliseen ongelman aiheuttajaan.

Tiedän tämän nyt jälkeenpäin, koska vahingossa säilytin muutamia järjestelmän tuloksia kuvaavia tulosteita. Jostain syystä olin tunkenut ne salkkuuni ja unohdin tulosteet tyystin. Muutaman vuoden jälkeen löysin tulosteet sattumalta, ja heti ensivilaukselta tajusin jotain joka sai vatsanpohjani vääntämään: näin tulosteessa deliver -prosessin, ja sille osoitetun valtavan määrän prosessoriaikaa. Olin nimittäin nähnyt vuosien kuluessa tämän deliver-syöpön monessa eri tilanteessa, ratkoessani SCO Unix -ongelmatilanteita. Tiesin heti mitä tuo rivi prosessilistauksessa tarkoitti: tuhansia, kenties kymmeniätuhansia email-viestejä odotti toimittamistaan, ollen tällä hetkellä jumissa. Deliver yritti jatkuvasti, huonolla menestyksellä, toimittaa viestejä perille ja söi siksi koko ajan prosessoriaikaa järjestelmältä. Tämän lisäksi deliver teki paljon raskaita levyn I/O toimintoja. Kun se ei kyennyt toimittamaan viestejä perille, deliver vetäytyi jälleen odottamaan kutsuaan ajovuoroon. Lopulta viestejä kertyi niin paljon, että deliver oli melkein koko ajan ajossa - lukuunottamatta silloin, kun tein omat tutkimukseni! Perinteistä hyvää tuuriani... Toisaalta en ilmeisesti ajanut prosessilistaa riittävän montaa kertaa, vaan tyydyin yhteen tilannevedokseen - koska olin niin varma siitä mitä näin: Glovian tuhlaamassa resursseja.

Mutta miksi asiakas itse ei nähnyt näitä jumissa olevia viestejä? Siksi, että ne sattuivat olemaan pääkäyttäjälle (root) osoitettuja - eikä kukaan muu käyttäjä ollut kiinnostunut niistä. Perilletoimitus ei onnistunut, koska pääkäyttäjällä oli lukkotiedosto hakemistossaan. Siksi muille käyttäjille osoitetut viestit hidastuivat hidastumistaan, mutta tulkitsin tämän oireena - en ongelman syynä. Virheeni: näin sen mitä odotin näkeväni, tosiasioiden sijaan - ja menetin hyvän asiakkaan vuosia liian varhain.

-FeedBurner RSS Feed-

-Digg This-

-Add to del.icio.us-

/Unixart/trouble_shooting.html copyright August 2006 Anthony Lawrence All Rights Reserved

Related Articles

Have you tried Searching this site?

Please read this disclaimer

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Click here to add your comments


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Why no "Digg this!" etc.?

Take Control of Maintaining Your Mac

Take Control of Syncing Data in Leopard

Take Control of Upgrading to Snow Leopard

Take Control of Buying a Mac

Take Control of Easy Backups in Leopard

Take Control of Fonts in Leopard

Take Control of Screen Sharing in Leopard

Take Control of Permissions in Leopard

/Unixart/trouble_shooting_finn.html copyright All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here