Download - Diagnostique et résolution de problèmes

8/2/2019 Diagnostique et rsolution de problmes

1/20

Diagnostique et rsolution de

problmes


2/20

Mthodologie de rsolution de

problmes


3/20

Qu'est-ce qu'une mthodologie de rsolution des problmes ?

Les spcificits des diverses mthodologies de rsolution desproblmes informatiques peuvent varier et les processus impliqusne sont pas prcis.

La plupart des mthodologies partagent des processus et des

procdures communs, quel que soit le domaine : informatique,plomberie ou mcanique automobile.

Tout incident parcourt une srie de processus conus pour rsoudre lesproblmes aussi rapidement et efficacement que possible. Parmi cesprocessus, la classification, le test, la transmission et la cration derapports sont l'pine dorsale de toute mthodologie de rsolution desproblmes.


4/20


Classification :Lorsqu'un utilisateur rencontre un problme informatique et vous lesignale, cela dclenche une srie de processus de classification.

Au cours de ceux-ci, vous collectez des informations auprs de

l'utilisateur pour tenter d'tablir la nature et l'tendue du problme.

La discussion initiale peut rvler des informations permettant unersolution immdiate.

Cependant, dans le cas de problmes plus graves ou plus complexes,vous devez faire appel aux autres processus de rsolution pour parvenir les rsoudre


5/20


Classification :Les problmes qui affectent de nombreux utilisateurs finaux ont unimpact plus sensible sur la productivit de l'organisation et doiventtre rsolus plus rapidement.

La classification vous permet de dterminer l'tendue et l'impact desproblmes en vue d'tablir leur priorit.

Mme si vous tes en mesure de rsoudre le problme tout de suite,vous devez le consigner en vous conformant la mthodologie envigueur. Des procdures de consignation appropries garantissent

qu'aucun rapport d'incident ne se perde.

En ayant la possibilit d'accder aux rapports d'incident dtaills, uneorganisation peut surveiller ses systmes informatiques de manireplus efficace et prendre des dcisions informes.


6/20


Test :Une fois que vous avez tabli la priorit d'un problme et consign l'incident,la phase de test dbute.

Au cours de celle-ci, vous faites appel plusieurs processus pour dterminer lacause probable du problme. Vous pouvez commencer par dresser la liste descauses possibles

Dans le domaine des systmes informatiques, cela peut vouloir dire tablirune distinction entre les problmes de serveur et de station de travail, dematriel et de logiciel, et de systme d'exploitation et d'applications.

Lorsque vous avez rduit la liste des causes possibles un nombre grable,vous pouvez dmarrer le processus de test. Ce processus vise dterminer lacause probable parmi les causes possibles restantes. Vous pouvez essayer dereproduire le problme dans un environnement de test. Si vous pouvez lereproduire facilement, cela signifie que vous avez dtermin la causeprobable. En revanche, si vous prouvez des difficults le reproduire, vous

devez analyser vos rsultats et revenir sur votre cheminement initial.

De cette manire, vous pouvez liminer les causes possibles pour dterminerles causes probables.


7/20


Transmission :Si vous ne pouvez pas trouver de rsolution pendant la phase de testinitiale, vous devez consulter la documentation supplmentaire outransmettre le problme, soit au fabricant du composant suspect, soitau sein de votre organisation si vous disposez de ressources internes.

Un processus de transmission d'incident au personnel de supporttechnique de deuxime niveau devrait tre en place au sein de votreorganisation. Un membre de ce service vous posera des questions pouressayer de classifier l'tendue du problme et de dfinir un niveau

priorit.


8/20


Rapport :Lorsque l'incident a t rsolu, vous devez documenter sa rsolution. Ilest important d'enregistrer les modifications apportes laconfiguration de votre systme informatique.

En outre, les problmes ont tendance se produire plusieurs fois. S'ilsont t documents correctement, vous gagnerez du temps laprochaine fois que vous serez amen rsoudre des occurrencessimilaires du problme


9/20

Utilisateurs d'une mthodologie de rsolution des problmes

Utilisateur final

Signale unincident

Technicien du supporttechnique

1er niveau dusupport technique

Rsolution duproblmeimpossible

Transmettrelincident

IngnieursSupport techniquede 2me niveau

Rsolution duproblmeimpossible

Transmettre

lincident

Ingnieurs SystmesSupport technique

de 3me niveau

Faire appel

Architecte systme,Concepteurs etPlanificateurs

Support techniquede 4me niveau

ont des connaissances

et des comptences plus

spcialises pour

rsoudre les problmes

experts dots de

comptences trs

cibles

pour concevoir et

planifier des

modificationsimportantes apporter

une infrastructure

dues la rsolution

d'un problme

Peut recevoir une

formation sur le

matriel et les logiciels

utiliss.

le personnel du support

technique leur fournit

des documents d'auto-

assistance


10/20

tapes types d'une mthodologie de rsolution des problmes


11/20

Le processus de consignation du problme dans un rapport commence lorsqu'unutilisateur final appelle le support technique pour la premire fois.

ce stade, vous devez enregistrer les dtails du problme et poser des questionspertinentes l'utilisateur en vue de dterminer l'tendue du problme.

Les rponses ces questions peuvent vous aider dterminer la priorit du problme.

Il est important de tenir l'utilisateur final inform de la progression tout au long duprocessus de rsolution des problmes.

En outre, pendant l'tape de cration de rapport, vous pouvez indiquer l'utilisateur cequi va se passer.



12/20

Il est possible que vous puissiez rsoudre le problme signal pendantl'tape initiale de cration de rapport. Ceci est particulirement vrai dans le casde problmes relativement simples.

Si vous ne parvenez pas rsoudre immdiatement le problme, vous devezrassembler le plus d'informations possible propos du problme dans le butd'identifier les causes possibles. Vous pouvez utiliser des outils d'analyse,consulter des journaux des vnements ou simplement poser des questionssupplmentaires l'utilisateur pour recueillir davantage d'informations.



13/20

Vous tentez de dterminer la cause du problme. Il existe deux approchespossibles :

L'approche linaire est une mthodologie qui rvle rapidement la cause

principale d'un problme, car elle implique de suivre une srie logique d'tapes.Prenez pour point de dpart ce que l'utilisateur final a dit et continuez de faonmthodique jusqu' ce que vous dcouvriez la source du problme.

L'approche soustractive est une mthodologie dans laquelle vous vousreprsentez mentalement les composants systme de l'ordinateur.


Sparez les composants en deux le long d'une ligne que vous pouvez tester. Parexemple, le problme est-il d un composant matriel ou un composant rseau ?Effectuez ensuite un test pour voir de quel ct de la ligne le problme se situe, puis

continuez de la mme manire jusqu' ce que vous ayez isol le composant quipose problme


14/20

Quelle que soit l'approche pour laquelle vous optez, l'objectif de cette tape est d'isoler lacause du problme. Lorsque vous pensez l'avoir dtermine, vous devez tester voshypothses. Si les tests s'avrent concluants, continuez jusqu' ce que vous ayezdtermin la cause relle.

Une fois que vos tests ont rvl la cause d'un problme, vous devez planifier les actionssuivantes.

Par exemple, si le problme implique le remplacement d'un disque du serveur, vous devezcommander le nouveau disque, dterminer une heure approprie pour effectuer le

remplacement, sauvegarder les donnes prsentes sur le disque remplacer, arrter le

serveur, installer physiquement le nouveau disque et excuter une restauration desdonnes sur celui-ci.



15/20

Aprs avoir mis au point un plan d'action, vous devez l'implmenter.

Lorsque vous implmentez un plan d'action en vue de rsoudre des problmes graves,vous devez considrer l'impact des modifications que vous prvoyez d'apporter sur ladisponibilit des services. Les grandes organisations ont des procdures de gestion desmodifications auxquelles vous devez vous conformer.

Avant de modifier la configuration, valuez quels aspects de la reconfiguration vouspouvez raliser distance avec des outils d'administration et des utilitaires. Vous pouvezrsoudre beaucoup de problmes avec des techniques de gestion distance pour viter devous rendre sur l'ordinateur de l'utilisateur. Toutefois, certains problmes ne peuvent pas

tre rsolus l'aide de tels outils, et vous devrez vous rendre sur l'ordinateur del'utilisateur final.



16/20

Lorsque vous avez rsolu le problme, vous devez documenter sa rsolution.

Cette tche implique un de nombre processus qui varie en fonction de l'infrastructure dusupport technique.

Au minimum, vous devez informer l'utilisateur final que vous avez rsolu le problme. Siun systme de consignation est en place, vous devez clore l'incident.

Si vous avez procd une reconfiguration pour rsoudre un problme, vous devezmettre jour la documentation de support pour reflter les modifications apportes.

En outre, lors de la phase de collecte des informations, il est souvent utile de consulterles journaux d'incident, qu'un problme similaire ait t signal ou non par quelqu'und'autre. Savoir si un autre technicien a document des problmes similaires n'est possibleque si, la clture de l'incident, vous documentez ce que vous avez fait pour rsoudre leproblme.



17/20

Diagnostic des 7 couches du

modle OSI


18/20

Pour viter la multiplication des solutions d'interconnexion d'architectures htrognes,l'ISO a dvelopp un modle de rfrence appel modle OSI (Open Systems

Interconnection)

Ce modle dcrit les concepts utiliss et la dmarche suivie pour normaliserl'interconnexion de systmes ouverts.

Le modle OSI n'est pas une vritable architecture de rseau, car il ne prcise pasrellement les services et les protocoles utiliser pour chaque couche.

Il dcrit plutt ce que doivent faire les couches. Nanmoins, l'ISO a crit ses propresnormes pour chaque couche, et ceci de manire indpendante au modle.

Diagnostic des 7 couches du modle OSI


19/20

Les principes qui ont conduit ces 7 couches sont les suivants :

chaque couche a des fonctions bien dfinies. les fonctions de chaque couche doivent tre choisies dans l'objectif de la normalisationinternationale des protocoles.

le nombre de couches doit tre tel qu'il n'y ait pas cohabitation de fonctions trsdiffrentes au sein d'une mme couche et que l'architecture ne soit pas trop difficile matriser.

Les couches basses (1, 2, 3 et 4) sont ncessaires l'acheminement des informationsentre les extrmits concernes et dpendent du support physique.

Les couches hautes (5, 6 et 7) sont responsables du traitement de l'information relative la gestion des changes entre systmes informatiques.

Diagnostic des 7 couches du modle OSI


20/20