PRAKTIKAT MË TË MIRA, BAZAT E RRJETIT
Troubleshooting me Gjashtë Hapa.
Procedura e troubleshooting (zgjidhja e problemit që ka ndodhur) bazuar te marina e SHBA-së me gjashtë hapa është kthyer në pjesë të kurseve akademike dhe profesionale, si edhe e certifikimeve nëpër botë. Prezanton një qasje logjike hap pas hapi për troubleshooting e problemeve të sistemit. Ne mund ta aplikojmë këtë qasje në rrjetet kompjuterike, qarqet elektrike dhe elektronike, ose proceset e biznesit. Kur ne e përdorim si duhet metodën me gjashtë hapa, troubleshooting që bëjmë mund të jetë më i shpejtë, më efikas sesa metoda “të futesh menjëherë në veprim”.
Qëllimet e Troubleshooting
Qëllimi kryesor i troubleshooting është shumë i thjeshtë, ndreqja e problemeve. Por ai qëllim është më larmishëm sesa duket në fillim. Ndërkohë që duam të ndreqim problemet, duhet të kemi si objektiv për ta bërë sa më efikas dhe sa më të shpejtë që të jetë e mundur. Ndërkohë që personi i cili ka raportuar për këtë problem vazhdon që të mos kryejë dot asnjë punë, që është përpjekur të bëjë.
Gjashtë Hapat
Së pari, do të prezantojmë gjashtë hapat. Së dyti, do të eksplorojmë se çfarë paraqet secili hap. Së treti, do të aplikojmë gjashtë hapat në një skenar rrjeti me probleme në botën reale. Gjashtë hapat e mëposhtëm përbëjnë procesin formal të troubleshooting:
- Identifikimi i Simptomave
- Saktësimi i Simptomave
- Renditja e Funksioneve të Mundshme Problematike
- Lokalizimi i Funksionit Problematik
- Lokalizimi i Komponentit Problematik
- Analizimi i Mosfunksionimit
Me hapat që janë krijuar fillimisht për troubleshooting të sistemeve elektrike dhe elektronike, disa nga fjalët janë ndryshuar me kalimin e kohës. Për shembull, hapi 5 është krijuar fillimisht si “Lokalizimi i Qarkut Problematik”. Fjalët janë përpunuar, por rezultati është sërish i njëjtë, gjetja e shkakut kryesor.
Identifikimi i Simptomave
Hapi i parë nis gjithë procesin e troubleshooting. Shpesh për profesionistët e Teknologjisë së Informacionit kjo ndodh kur dikush i telefonon helpdeskut ose dërgon një “ticket”. Stafi i IT-së mund të sinjalizohet nga një program monitorimi se një sistem nuk është aktiv. Në këtë pikë e dimë se diçka nuk shkon, por s’ka asnjë tregues se çfarë është. Nisni procesin e troubleshooting dhe përgjigjuni me urgjencë.
Saktësimi i Simptomave
Tani që e dimë se diçka nuk shkon, është koha që të nisim me pyetjet. Këtu keni një listë me pyetje që pëlqej t’i pyes përdoruesit e mi kur më thonë për një problem:
- Çfarë nuk arrin të bësh?
- E bëje dot më parë?
- Të ndodh vetëm ty, apo u ndodh edhe të tjerëve?
- Ka funksionuar ndonjëherë?
- Ka ndryshuar ndonjë gjë që së fundmi?
Kur përballeni me përdoruesit jo-teknikë është me rëndësi që të kuptoni se ata mund të mos arrijnë të artikulojnë plotësisht atë që përjetojnë kur na japin përgjigje. Për shembull, një raportim i zakonshëm kur bëni troubleshoot për shkëputje rrjeti është “është shkëputur interneti”. Kjo s’është e vërtetë, pasi pjesa më e madhe e përdoruesve s’kanë trajnimin për të kuptuar ndryshimin mes LAN, WAN dhe internet. S’është detyra e tyre për të kuptuar që LAN-i s’funksionon dhe që interneti është ende aty duke i pritur. Është e nevojshme për një farë interpretimi dhe aftësia për ta bërë këtë shoqërohet me kohën dhe përvojën.
Gjatë këtyre hapave gjithashtu po kërkoj për pamje, tinguj dhe erëra. Shkëputja e energjisë është e lehtë të kuptohet, sepse s’do të ketë drita të ndezura, si edhe heshtja e dyshimtë aty ku duhej të kishte ventilatorë ftohës të zhurmshëm. Era e plastikës që digjet dhe e komponentëve elektronikë është tepër e veçantë.
Renditja e Funksioneve të Mundshme Problematike
Hapi i parë nisi procesin e troubleshooting dhe hapi i dytë hetoi natyrën përgjithësuese të problemit. Tani do të diskutojmë se cili mund të jetë shkaku i përgjithshëm i problemit. Së pari kemi nevojë të përcaktojmë se çfarë është “funksioni”. Për qëllimin e troubleshooting të sistemeve IT, një funksion është një zonë e përgjithshme e punës. Disa profesionistë të IT-së u referohen si “silo” ose “domain”. Shembujt e mëposhtëm janë të gjithë funksione ose silo, që mund të ketë probleme për një ose arsye tjetër:
- Energjia
- Kontrolle Mjedisore
- Rrjete
- Serverë
- Siguri
Këto janë të gjitha shumë të gjera dhe ky është qëllimi i këtij hapi. Ne do të diskutojmë cili funksion mund të jetë shkaku i problemit tonë dhe do të përjashtojmë gjithashtu se cili s’mund të jetë. Kjo na çon në drejtimin e duhur të përgjithshëm.
Është me rëndësi të përcaktoni se cili mund të mos jetë shkaku i problemit, pasi na parandalon të mos humbasim kohë me një sistem që s’ka lidhje. Kur një teknik dërgohet në drejtimin e gabuar dhe i bën troubleshoot një funksioni që s’ka lidhje me problemin ndonjëherë njihet si “futje në vrimën e lepurit”.
Ndërkohë që dritat janë ndezur në dhomën e serverëve dhe dritat LED të pajisjeve në panelet ballore pulsojnë ndërkohë që ventilatorët janë në punë, domain-i e energjisë ndoshta mund të përjashtohet. Nëse një nga këta serverë me drita pulsuese s’mund të pengohet ose aksesohet në distancë, mund të hamendësohet se domain-i i rrjetit mund të jetë problemi. Ka gjithashtu mundësi se një defekt pajisje ka ndodhur në server, duke e shkëputur nga rrjeti. Në varësi të qëndrueshmërisë së shkuar të serverëve, mund të përfshini ose jo domain-in server në renditjen e funksioneve problematike të mundshme.
Lokalizimi i Funksionit Problematik
Në këtë fazë ne nisim të kërkojmë në mënyrë aktive brenda këtyre domain-eve që diskutohen për probleme. Ne duam të kufizojmë shkakun në një domain të caktuar dhe të fokusojmë përpjekjet tona më tej. Duke u kthyer te shembulli i serverit, mendohet se rrjeti mund të jetë problem, ose ndoshta vetë pajisja. Serveri është i ndezur, dritat LED pulsojnë dhe ventilatorët janë në punë. Duke parë lidhjen e rrjetit në pjesën e pasme të serverit, dritat e kartës së rrjetit NIC tregojnë një dritë LED lidhje dhe një dritë LED pulsues aktiviteti. Kjo na tregon se kabulli është i lidhur dhe karta e rrjetit NIC është aktive, kështu që domain-i i serverit duket më pak problematik.
Duke përdorur një traceroute në drejtim të IP adresës së serverit tregon hope të suksesshme deri te switch-i ku është lidhur serveri. Switch-i është hop-i i fundit pas së cilës paketat humbasin. Duke u bazuar te rezultati, duket se domain-i i rrjetit është keqbërësi.
Lokalizimi i Komponentit Problematik
Tani që e dimë se domain-i i rrjetit është problematik, fokusohemi te shkaku aktual. Duke parë dritat e kartës së rrjetit NIC, del që është e ndezur dhe e lidhur. Lidhja me anën tjetër të kabullit duhet të jetë në rregull, përndryshe s’do të kishte dritë lidhje. Një traceroute drejt serverit ndalon te switch-i, kështu që do të futemi në pajisjen switch dhe të hetojmë më tej. Një listë e portave të switch-it tregon se porta e serverit është aktive, me shpejtësinë dhe dupleksin të konfiguruar si “autonegotiate”.
Ne e dimë se rrjeti ynë është i segmentuar duke përdorur VLAN-e, kështu që renditim të gjitha VLAN-et e konfiguruara në switch dhe portat e caktuara. Porta që lidhet me serverin është e përfshirë në VLAN 1, që është VLAN default, jo në VLAN server. Kjo shpjegon pse kemi një lidhje të mirë fizike me dritat lidhëse, por s’ka trafik rrjeti.
Analizimi i Mosfunksionimit
Në këtë hap përfundimtar ne zgjidhim problemin dhe dokumentojmë procesin. Në rastin e serverit tonë, duke caktuar portën në VLAN-in e duhur rikthyem lidhjen e internetit dhe përdoruesit tanë mund të aksesojnë sërish serverin. Sapo problemi zgjidhet, ne duhet të verifikojmë se funksionet janë rikthyer në normalitet. Është me rëndësoi që të flasim me këdo që e raportoi problemin dhe të sigurohemi se është zgjidhur plotësisht. Kjo na çon në pikën ku ne bëjmë pyetje dhe dokumentojmë procesin. Duke dokumentuar problemin ne e bëjmë të mundur për teknikët e ardhshëm që të zgjidhin të njëjtin problem më shpejt nëse e përjetojnë atë sërish.
Këtu janë pyetjet që më pëlqen të pyes kur dokumentoj një problem:
- Çfarë nuk shkonte?
- Çfarë simptomash pamë?
- Cili ishte shkaku?
- Si e parandalojmë që të mos ndodhë sërish?
Dokumentacioni i problemit mund të jetë i tillë:
Porta e rrjetit e lidhur me serverin ABC123 ishte e vendosur në VLAN-in e gabuar, duke shkëputur lidhjen e rrjetit. Serveri ishte i ndezur dhe kishte aktive dritat e lidhjes, por s’mund të arrihej përmes rrjetit. Statusi “switchport”-it ishte “up”, por caktimi i portës në VLAN nuk përkonte me dokumentacionin tonë. Një teknik ka ngatërruar portën kur ka ndryshuar VLAN-in për një host tjetër, duke nxjerrë aksidentalisht serverin nga linja. Duke caktuar “switchport”-in në VLAN-in server riktheu lidhjen.
Parandalimi i problemit që të mos ndodhë sërish mund të jetë i marifetshëm. Një përzierje trajnimi, këshillimi, dokumentacion i duhur dhe ndryshim të procesit të menaxhimit mund të ndalojë përsëritjen. Edhe ndarja informale e njohurive brenda skuadrës IT mund të jetë më mirë se hiçgjë. Gjatë një takimi javor është mirë të përmblidhni problemet shpejt me pikat e mëposhtme:
- Kjo gjë ka ndodhur
- Këtë gjë kemi parë kur bëmë troubleshooting
- E kemi zgjidhur në këtë mënyrë
Duke e bërë këtë javë pas jave shtohet baza e njohurive brenda skuadrës së IT-së dhe ndihmon për të zhvilluar ekspertë të mirë troubleshoot.
