Documente Academic
Documente Profesional
Documente Cultură
Sommaire
1.
2.
3.
4.
5.
6.
Introduction.........................................................................................2
Dmarche de qualit de service du helpdesk.............................................3
Prise en compte de la dmarche qualit...................................................3
Vrification de la classification des natures dincidents................................5
Vrification de la fiche complte............................................................6
Exemple Fiche Intervention....................................................................7
OFPP
T@
Document
319479686
Millsime
janvier 09
Page
1 - 99
1.
Introduction
Socit
X
Nom client :
FICHE
DINTERVENTION
CLIENT
Date de lintervention :
Intervenant :
Enonc de la situation :
Nature de lincident
Matriel
Logiciel
Classement de lincident
(Catgories)
Traitement central
Rseau
Poste de travail
ROYAUME DU MAROC
Conclusion :
Dure de lintervention :
Visa de lintervenant :
ROYAUME DU MAROC
Sommaire
1.
2.
3.
4.
OFPP
T@
Document
319479686
Millsime
janvier 09
Page
1 - 99
ROYAUME DU MAROC
ROYAUME DU MAROC
10.
Outils disponibles
Il existe des outils mthodologiques tels que les normes Afnor ISO 8400-2 qui
prconisent un processus itratif damlioration ou les procdures de lassurance
qualit. On trouvera aussi un rfrentiel des meilleures pratiques en matire de
services autour du systme dinformation. Du ct des diteurs de logiciels de
help-desk, tous permettent de grer des contrats dengagement de service, mais l
offre est plthorique sur ce secteur extrmement concurrentiel. On peut citer, sans
tre exhaustif, Peregrine Systems, PS Soft, Remedy (absorb rcemment par
Peregrine), StaffandLine , Magic, Kimoce ou Supporter. Dans tous les cas, le critre
de choix sera ladaptabilit de loutil aux processus de lentreprise. Mais, pour
rsumer grossirement, plus le logiciel est paramtrable, plus il est cher.
ROYAUME DU MAROC
Sommaire
1.
2.
Introduction.........................................................................................2
Technique danalyse de la demande.........................................................2
2.1. Classification.....................................................................................2
2.2. Test..................................................................................................2
2.3. Transmission.....................................................................................3
2.4. Rapport............................................................................................3
OFPP
T@
Document
Millsime
Page
319479686
novembre
08
1 - 99
ROYAUME DU MAROC
11. Introduction
Dans le mtier Assistance technique, la communication entre le technicien et la
personne appelante pour un incident sur son poste de travail joue un rle trs
important pour rsoudre rapidement cet incident et aboutir un rsultat positif.
Classification
12.2.
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 la cause probable du problme. Vous pouvez commencer par
dresser la liste des causes possibles, gnralement, en les divisant et en les
isolants. Dans le domaine des systmes informatiques, cela peut vouloir dire tablir
une distinction entre les problmes de serveur et de station de travail, de matriel
et de logiciel, et de systme d'exploitation et d'applications. De cette manire, vous
pouvez liminer les causes possibles pour dterminer les causes probables.
Lorsque vous avez rduit la liste des causes possibles un nombre grable, vous
pouvez dmarrer le processus de test. Ce processus vise dterminer la cause
probable parmi les causes possibles restantes. Vous pouvez essayer de reproduire le
problme dans un environnement de test. Si vous pouvez le reproduire facilement,
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC
ROYAUME DU MAROC
12.3.
Transmission
Si vous ne pouvez pas trouver de rsolution pendant la phase de test initiale, vous
devez consulter la documentation supplmentaire ou transmettre le problme, soit
au fabricant du composant suspect, soit au sein de votre organisation si vous
disposez de ressources internes. Un processus de transmission d'incident au
personnel de support technique de deuxime niveau devrait tre en place au sein
de votre organisation. Un membre de ce service vous posera des questions pour
essayer de classifier l'tendue du problme et de dfinir un niveau priorit.
12.4.
Rapport
Diagnostic de lincident.
ROYAUME DU MAROC
Diagnostic de lincident
Sommaire
1.
2.
Introduction.........................................................................................2
Diagnostic de pannes matrielles.............................................................3
2.1. Les pannes Post.................................................................................4
2.2. Les pannes CMOS/BIOS......................................................................4
2.3. Les pannes CARTES MERES.................................................................6
2.4. Les pannes CPU.................................................................................7
2.5. Les pannes RAM.................................................................................8
2.6. Les pannes dalimentation.................................................................10
2.7. Les pannes des disques durs..............................................................11
2.8. Pannes de priphriques....................................................................11
3.
Diagnostic de pannes logicielles.............................................................14
3.1. Panne bureautique............................................................................14
3.2. Panne de base de donnes.................................................................15
3.3. Panne dapplications.........................................................................15
4.
Diagnostic de pannes du SE..................................................................16
4.1. Noyau.............................................................................................16
4.2. Bibliothques...................................................................................17
4.3. Outils systme.................................................................................18
4.4. Programmes applicatifs de base.........................................................18
5.
Renseignement de la fiche diagnostic ou de la partie diagnostic de la fiche
dinterventions.............................................................................................19
OFPP
T@
Document
Millsime
Diagnostic de lincident
janvier 09
Page
1 - 99
ROYAUME DU MAROC
13. Introduction
Un bon diagnostic utilise des techniques prouves pour rparer les
problmes informatiques. La dcoupe logique du processus de diagnostic en
tapes le rend plus efficace.
Le processus de diagnostic dmarre avec l'identification du problme. Des
informations doivent ensuite tre rassembles pour dfinir les causes.
Ensuite, une solution est dveloppe et mise en place. Enfin, on vrifie que
la solution a fonctionn. Si le problme est rsolu, le processus de
diagnostic se termine avec la documentation de la solution. Si le problme
n'est pas rsolu, le processus redmarre jusqu' ce qu'une solution soit
trouve. Chaque tape est dtaille dans les chapitres suivants.
Dans cette tape, le problme est identifi. Pour cela, il faut analyser les
symptmes, de faon dterminer les causes possibles. Le rsultat est un bilan
dtaill qui dcrit clairement le problme. Sans une bonne comprhension du
problme, le technicien ne peut pas rassembler les bonnes informations pour
dvelopper une solution adquate.
Une fois que le problme a t identifi, la prochaine tape est de collecter
les informations pour qu'une solution puisse tre dveloppe. Un diagnostic
rapide et efficace implique la collecte d'informations fiables afin de trouver
une solution adquate. Les problmes informatiques peuvent varier du
simple au trs complexe. Le problme peut devenir trs compliqu si le
technicien n'a pas la bonne information.
ROYAUME DU MAROC
ROYAUME DU MAROC
Aprs avoir rpondu aux questions et vrifi les rponses, le problme devra
tre caractris comme logiciel ou matriel. Le problme pourra tre
circonscrit un lment spcifique ou une partie du systme. Une fois le
problme caractris et circonscrit, le technicien peut ensuite dvelopper
une solution qui se base sur l'exprience, la logique, le raisonnement et le
bon sens du technicien.
ROYAUME DU MAROC
Moniteurs
Clavier / souris
Microprocesseurs
Alimentation
Carte mre
14.1.
ROYAUME DU MAROC
14.2.
ROYAUME DU MAROC
1. Eteindre l'ordinateur
2. Enlever la batterie du CMOS de la carte mre
3. Court-circuiter les connexions ngatives et positives de l'emplacement de la
batterie sur la carte mre, en utilisant tout matriau conducteur (fil, tte de
tournevis, etc.).
4. Replacer la batterie CMOS dans sa position initiale sur la carte mre
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC
ROYAUME DU MAROC
Mise jour du BIOS : Une mise jour du BIOS peut inclure des correctifs,
des fonctionnalits supplmentaires et le support des derniers
priphriques, afin de rsoudre tous les problmes. Il n'est pas recommand
de mettre jour le BIOS en l'absence de problmes. Si le systme est
oprationnel, la mise jour du BIOS est risque et doit tre vite. Si le
BIOS est mis jour de faon incorrecte, cela peut endommager la carte
mre et les priphriques.
Une attention particulire devra tre porte avant la mise jour du BIOS. La
carte mre doit avoir un BIOS en mmoire flash et supporter la nouvelle
version. Le composant BIOS a aussi besoin de supporter le nouveau numro
de version. Le BIOS ne pourra tre mis jour que si ces critres sont
respects.
14.3.
ROYAUME DU MAROC
ROYAUME DU MAROC
14.4.
14.5.
ROYAUME DU MAROC
RAM EDO - La RAM EDO est plus rapide que la DRAM. EDO RAM a aussi t
remplac par SDRAM. EDO RAM tait une amlioration de la DRAM, parce
qu'elle avait des caractristiques volues de synchronisation. EDO augmente
la dure de stockage des donnes et possde une frquence de
rafrachissement rduite. Ceci soulage le CPU et la RAM en terme de
synchronisation et amliore la performance.
DDR SDRAM La DDR SDRAM est une nouvelle forme de SDRAM qui peut
thoriquement augmenter la vitesse d'horloge mmoire jusqu' 200
mgahertz (Mhz) ou plus.
ROYAUME DU MAROC
ROYAUME DU MAROC
Une DRAM plus rapide peut tre installe sur un bus systme plus lent et n'affectera
pas les performances. Le systme agira la vitesse du bus, mme si de la mmoire
plus rapide est installe. Cependant, un module DRAM plus lent ou diffrent, ne
peut pas tre install sur un systme avec des exigences DRAM plus leves ou des
DRAM vitesse d'horloge diffrente.
14.6.
ROYAUME DU MAROC
ROYAUME DU MAROC
14.7.
14.8.
Pannes de priphriques
Les priphriques d'entre tels qu'un clavier, une souris, des scanners, et les
appareils numriques transfrent des donnes dans un ordinateur. La
plupart des priphriques d'entre sont dtects au dmarrage.
Quand on diagnostique des priphriques d'entre, vrifiez que le
priphrique est correctement connect. Vrifier que le cble est dans de
bonnes conditions de fonctionnement et qu'il n'est pas us. Comme avec
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC
ROYAUME DU MAROC
ROYAUME DU MAROC
Mauvais cblage
Matriel dfectueux
Conflits de ressources
SpinRite http://grc.com/default.htm
Check it http://www.hallogram.com/
PC Technician http://www.windsortech.com/
ROYAUME DU MAROC
d'un disque dur dfaillant. SpinRite est un programme indpendant qui est
capable de se lancer sans le DOS. C'est un logiciel reconnu pour sa capacit
rgler des problmes difficiles. SpinRite peut aussi empcher les pannes
de disque dur. S'il est charg avant une panne, il peut prvenir les
utilisateurs d'un problme potentiel, et peut empcher une dfaillance en
isolant les zones problmes. Les mauvaises zones sont repres comme
dfaillantes. Si une zone est dfaillante, elle ne peut pas tre utilise pour
lire ou crire des donnes.
AMI Diags : AMI Diags effectue des tests approfondis du systme. AMI Diags
peut fournir des rapports sur la mmoire, les ports srie, les ports
parallles, les modems, les disques durs, le clavier, le BIOS, et les
adaptateurs vido.
ROYAUME DU MAROC
est un programme libre qui fournit un ensemble d'outils diagnostic, qui peut aider
au dpannage et la mesure de performance. Sandra peut tester la performance
des CPU, du modem, de la carte vido, de la mmoire, du BIOS et des disques durs.
15.1.
Panne bureautique
ROYAUME DU MAROC
15.2.
ROYAUME DU MAROC
15.3.
Panne dapplications
Une application est un outil qui permet de raliser une ou plusieurs tches ou
fonctions. Un amalgame est courant avec le terme logiciel.
Un logiciel est un ensemble de programmes qui permet un ordinateur ou
un systme informatique d'assurer une tche ou une fonction en particulier
(exemple : logiciel de gestion de la relation client, logiciel de production,
logiciel de comptabilit, logiciel de gestion des prts).
On distingue en gnral, dans un systme informatique, la partie matrielle
(l'ordinateur et ses priphriques) et la partie logicielle, immatrielle (les
programmes crits sur le disque dur).
Le logiciel est un bien immatriel, mais surtout c'est un bien non-rival, cest-dire qu'il ne s'use pas ; c'est un bien dont la consommation par un
individu donn n'empche pas d'autres consommateurs d'en jouir
simultanment.
ROYAUME DU MAROC
dun noyau ;
de bibliothques ;
16.1.
Noyau
ROYAUME DU MAROC
16.2.
Bibliothques
Les bibliothques servent regrouper les oprations les plus utilises dans
les programmes informatiques, afin dviter la redondance de la rcriture
de ces oprations dans tous les programmes.
On distingue gnralement deux types de bibliothques: les bibliothques
systme, et les bibliothques utilitaires. Les bibliothques systme sont
constitues de fonctions permettant lutilisation agrable des fonctionnalits
systmes (gnralement des points dentre vers des fonctions du noyau,
mais pas seulement). Les bibliothques utilitaires contiennent des fonctions
dusage courant et pratique (fonctions mathmatiques, fonctions de tri,
etc.).
Du point de vue du systme, les bibliothques ont diffrentes
caractristiques. Il y a le caractre statique ou dynamique, et le caractre
partag ou non.
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC
ROYAUME DU MAROC
16.3.
Outils systme
16.4.
ROYAUME DU MAROC
ROYAUME DU MAROC
Sources de rfrence
ROYAUME DU MAROC
Diagnostiquer un problme
Sommaire
1.
2.
Introduction.....................................................................................2
Diagnostic matriel...........................................................................2
2.1. Diffrentes Mthodes de Recherche des Pannes sur Micro-Ordinateurs. .2
2.1.1.
2.1.2.
2.1.3.
La mthode des mesures et les tests manuels des composants......4
Mthodologie de rsolution des problmes............................................6
3.1. Classification.................................................................................6
3.2. Test.............................................................................................7
3.3. Transmission.................................................................................7
3.4. Rapport........................................................................................8
4.
Utilisateurs d'une mthodologie de rsolution des problmes..................8
4.1. Utilisateurs finaux..........................................................................8
4.2. Spcialistes du support technique....................................................9
4.3. Ingnieurs du support technique......................................................9
4.4. Responsables et planificateurs.......................................................10
5.
tapes types d'une mthodologie de rsolution des problmes..............10
5.1. Consignation du problme.............................................................10
3.
5.1.1.
Processus de consignation des problmes..................................10
5.2. Collecte des informations..............................................................13
5.2.1.
Processus de collecte initiale des donnes..................................14
5.3. Dveloppement d'un plan d'action..................................................15
5.3.1.
Mthodes conseilles de dveloppement d'un plan d'action..........16
5.4. Implmentation du plan d'action....................................................17
5.4.1.
Processus d'implmentation d'un plan d'action...........................18
5.5. Documentation de la rsolution......................................................20
5.5.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
1 - 99
Diagnostiquer un problme
18. Introduction
En tant que technicien du support technique pour la rsolution des problmes lis
au poste de travail (ou technicien DST), une partie de votre travail consiste
prendre en charge les utilisateurs finaux et rsoudre divers types de tches.
Toutefois, les responsabilits dun technicien DST impliquent beaucoup plus que
la simple rsolution dun problme. Un technicien DST doit tre capable dcouter
un utilisateur, de recueillir des informations auprs de celui-ci, de diagnostiquer
et de rsoudre le problme (ou de remonter le problme un technicien senior
ou un administrateur systme) et de documenter correctement la rsolution du
problme de la faon indique par la stratgie de lentreprise.
19.1.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
2 - 99
Diagnostiquer un problme
l'ordinateur met une srie de signaux sonores (bips ) identifiant le problme. Ce
code sonore est le profil des signaux.
Ainsi, un bip suivi d'un second et d'une rafale de trois bips (code 1-1-3) signifie
que l'ordinateur n'a pas pu lire les donnes dans la mmoire non volatile (NVRAM
). Les codes sonores tant varis, nous allons lister dans un tableau ceux qui
sont les plus souvent rencontrs sur les micro-ordinateurs (voir le tableau de
l'annexe 2).
19.1.2.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
3 - 99
Diagnostiquer un problme
Si un problme est dtect avant l'initialisation du sous-systme vido,
l'ordinateur peut mettre une srie de codes sonores identifiant le problme. Ces
codes tant varis nous allons lister les plus courants dans un tableau (annexe3)
Test des diagnostics intgrs
Dans les diagnostics intgrs, les tests sont organiss en groupe de tests et en
sous-groupes de tests l'intrieur de chaque groupe. Les tests effectus sur
chaque systme varient en fonction de l'quipement existant dans le systme.
Les tests de diagnostics sont conus pour dtecter avec prcision un composant
du systme en dfaillance.
19.1.3.
La mthode des mesures et les tests manuels des
composants
C'est la mthode au cours de laquelle on recherche les pannes d'une manire
manuelle. Ici, la recherche des pannes se fait par approche descendante, en
allant du gnral au particulier, du plus simple vers le plus compliqu. Tout
d'abord, on songera aux erreurs logicielles, aux mauvaises dclarations du setup,
aux connexions, aux cbles d'alimentation, aux interrupteurs. En suite on
songera aux priphriques, puis l'unit centrale.
Enfin, on procdera certains tests et mesures pour mieux cerner l'origine des
problmes.
Les tests comparatifs
Dans cette mthode aussi appele de substitution, un appareil ou une carte est
compare un appareil ou une carte identique et fonctionnant normalement. Il
s'agit d'une mthode matrielle et l'avantage de cette mthode vient du fait
qu'elle permet d'isoler rapidement le groupe en panne et de pouvoir le tester.
Mais la prsence d'un systme similaire est indispensable.
Cas des mesures
Dans cette mthode on aura besoins d'un ensemble d'outils (appareils) qui
permettra de faire les mesures, d'interprter et de vrifier les observations.
Comme appareils on aura besoin d'un multimtre, d'un oscilloscope, d'une sonde
logique, d'un analyseur logique et d'un testeur de composants.
Le multimtre
Les courts-circuits ou les circuits ouverts, les tensions errones sont les
problmes les plus connus. N'importe quel ohm-mtre peut tester les conditions
d'ouverture ou de court-circuit. Un multimtre digital ou un volt-ohm- milli
ampremtre suffisent pour tester les tensions et les courants.
Si les composants et le schma sont connus, il s'agit d'une opration simple mais
longue qui permet de s'assurer que chaque connexion est sa place et que les
bons courants sont obtenus avec des tensions correctes. Dans notre cas de
dpannage des micro-ordinateurs, il est mieux d'utiliser un multimtre digital
pour des raisons de confort de lecture.
Avec cet appareil, on pourra alors contrler les rsistances, les condensateurs,
les diodes et les transistors pour dterminer s'ils sont fonctionnels ou non. Voir
schmas ci-dessous.
La sonde logique
Elle permet de vrifier rapidement les niveaux logiques, de faon isoler toute
anomalie. La sonde logique nous est utile dans le diagnostic des problmes poss
par les circuits logiques. Un signal tant reprsent par : soit un niveau haut (+
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
4 - 99
Diagnostiquer un problme
5 volts ) et un niveau bas (0 volt ), seule la sonde logique grce son indicateur
diode lectroluminescente ou d'une ampoule lectrique, le testeur indiquera
que le signal est 0 ou 1 ou indtermin. C'est l'instrument de mesure
qui permet de dterminer ou non et confirmer le bon fonctionnement d'un signal
sur un point de mesure (voir schmas ci-dessous )
L'oscilloscope.
Instrument de valeur, il trouve sa place dans un atelier de dpannage. A la
diffrence du multimtre, l'oscilloscope permet de mesurer l'amplitude et la
dure des signaux. on peut suivre alors les diffrents cycles d'une opration.
Avec les nouveaux microprocesseurs dont la vitesse varie entre 33 Mhz et 266
Mhz, pour visualiser les vnements, il faudra avoir un oscilloscope d'au moins
50 Mhz. Il existe deux grandes familles d'oscilloscopes dont :
- Les oscilloscopes analogiques qui sont plus adapts aux dpannages
des crans.
- Les oscilloscopes digitaux appropris aux dpannages des cartes
logiques (voir schmas ci-dessous.
- L'analyseur logique
C'est un appareil complexe qui permet d'afficher sur son cran simultanment
plusieurs signaux un instant prcis. L'analyseur logique se classe en deux
grandes catgories :
- Ceux qui mettent l'accent sur les informations de type timing qui sont
en fait des oscilloscopes multicanaux et qu'on utilise pour dtecter des
erreurs logiques, du bruit ou des problmes de niveaux logiques.
- Ceux qui donnent des informations d'tat et nous permettent de
visualiser le flux des informations dans le systme en examinant tous les
points importants du circuit sous forme binaire.
Ces analyseurs permettent de dtecter les erreurs de logiciels ou les erreurs
dues une interaction logiciel-matriel (voir schmas ci-dessous).
20.1.
Classification
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
5 - 99
Diagnostiquer un problme
l'tendue du problme. La discussion initiale peut rvler des informations
permettant une rsolution 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.
Les problmes qui affectent de nombreux utilisateurs finaux ont un impact plus
sensible sur la productivit de l'organisation et doivent tre rsolus plus
rapidement.
La classification vous permet de dterminer l'tendue et l'impact des problmes
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 en vigueur. 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, une
organisation peut surveiller ses systmes informatiques de manire plus efficace
et prendre des dcisions informes.
20.2.
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 la cause probable du problme. Vous pouvez
commencer par dresser la liste des causes possibles, gnralement, en les
divisant et en les isolants. Dans le domaine des systmes informatiques, cela
peut vouloir dire tablir une distinction entre les problmes de serveur et de
station de travail, de matriel et de logiciel, et de systme d'exploitation et
d'applications. De cette manire, vous pouvez liminer les causes possibles pour
dterminer les causes probables.
Lorsque vous avez rduit la liste des causes possibles un nombre grable, vous
pouvez dmarrer le processus de test. Ce processus vise dterminer la cause
probable parmi les causes possibles restantes. Vous pouvez essayer de
reproduire le problme dans un environnement de test. Si vous pouvez le
reproduire facilement, cela signifie que vous avez dtermin la cause probable.
En revanche, si vous prouvez des difficults le reproduire, vous devez
analyser vos rsultats et revenir sur votre cheminement initial.
20.3.
Transmission
20.4.
Rapport
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
6 - 99
Diagnostiquer un problme
En outre, les problmes ont tendance se produire plusieurs fois. S'ils ont t
documents correctement, vous gagnerez du temps la prochaine fois que vous
serez amen rsoudre des occurrences similaires du problme.
21.1.
Utilisateurs finaux
21.2.
Diagnostiquer un problme
finaux, ils travaillent dans le cadre de la mthodologie de rsolution des
problmes pour dfinir la nature du problme qui leur est signal. Les
spcialistes du service de support technique ont en gnral plus de comptences
en matire de support technique que les ingnieurs du support technique.
Lorsque les spcialistes de service de support technique ne peuvent pas rsoudre
un problme dans le laps de temps dfini par l'utilisateur, c'est eux qu'il
incombe de transmettre le problme au support technique de deuxime niveau
ou aux fournisseurs externes. La mthodologie de rsolution des problmes
profite aux spcialistes du support technique dans la mesure o elle dfinit
clairement les processus qu'ils doivent utiliser pour dfinir les problmes, tablir
leur priorit, les transmettre et les rsoudre.
21.3.
21.4.
Responsables et planificateurs
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
8 - 99
Diagnostiquer un problme
22.1.
Consignation du problme
22.1.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
9 - 99
Diagnostiquer un problme
informations relatives l'activit que vous, ou d'autres, avez effectue par
rapport au problme signal.
Classification et support initial
Aprs que l'utilisateur a contact le support technique, essayez de classifier le
problme et d'en dterminer l'importance et l'urgence. Pour ce faire, vous pouvez
poser des questions trs spcifiques l'utilisateur. Il peut s'agir de questions
comme celles-ci :
Qui d'autre a le mme problme ? Si le problme est rpandu, cela indique
un problme plus gnral moins susceptible d'tre propre l'ordinateur de
l'utilisateur. En outre, les problmes qui affectent beaucoup d'utilisateurs
sont plus urgents que ce touchant un seul utilisateur.
Quand avez-vous remarqu le problme pour la premire fois ? Il se peut
que l'ordinateur n'ait jamais fonctionn correctement. Il est trs utile de
savoir si l'ordinateur n'a jamais fonctionn correctement, car cela peut
indiquer un problme li au dploiement plutt qu' l'utilisation.
Est-ce que quelque chose a chang peu prs au mme moment o vous
avez remarqu le problme ? Si l'utilisateur a rcemment install de
nouvelles applications ou mis jour des pilotes et si le problme est
survenu aprs ces modifications, il est possible que les modifications aient
contribu au problme que l'utilisateur signale.
Au cours de cette phase, vous pouvez dterminer une cause probable du
problme signal, mais ne tirez pas de conclusions trop htives. Vous risquez
autrement de gaspiller beaucoup de temps et de ressources. Votre objectif
pendant cette phase est de dfinir le problme correctement.
Transmission
Lorsqu'un problme doit tre transmis un service de support technique de
niveau suprieur ou des fournisseurs externes, veillez consigner
suffisamment de dtails en vue de les transmettre. Il est trs utile qu'une
procdure de transmission soit clairement dfinie pour un maximum d'efficacit.
La procdure peut stipuler d'inclure les informations suivantes :
une description prcise du problme signal ;
un enregistrement de tous les messages d'erreur associs au problme ;
un enregistrement des tentatives de rsolution faites par les membres du
support technique ainsi que le rsultat de chaque tentative ;
un enregistrement concernant tous les outils de diagnostic utiliss par les
membres du support technique ;
la dure pouvant s'couler avant qu'il y ait obligation de transmettre un
problme.
Vous pouvez considrer de transmettre le problme aux fournisseurs externes
dans les cas suivants :
vous ne pouvez rsoudre le problme ;
vous ne disposez pas de suffisamment de ressources internes pour rsoudre le
problme ;
votre organisation n'a pas les comptences requises pour rsoudre le problme
;
vous avez identifi la cause probable du problme et elle provient d'un
composant tiers spcifique.
Document
Millsime
Page
OFPPT
janvier 09
319479686
10 - 99
@
Diagnostiquer un problme
Chaque fois que vous remontez un problme, restez-en toujours le propritaire
et utilisez l'enregistrement de base de donnes pour suivre la progression vers
une rsolution.
Assurez-vous galement que vous fournissez toute l'assistance ncessaire aux
autres niveaux d'assistance et aux fournisseurs externes.
Rsolution
Une fois que vous avez dtermin la cause probable d'un problme et avez
dvelopp un plan d'action, vous devez valuer ce plan. Cette valuation doit
inclure les tapes suivantes :
faire la liaison avec les spcialistes du support technique impliqus dans
l'implmentation du plan ;
mener bien toutes les demandes dcoulant des procdures de gestion
des modifications ;
analyser l'impact possible des modifications l'infrastructure informatique
proposes ;
dtailler les tapes de test du plan propos ;
dtailler le plan de restauration des modifications au cas o celles-ci ne
produisent pas le rsultat escompt.
Aprs avoir valu le plan d'action propos, vous pouvez le mettre en oeuvre. Au
cas o le plan d'action ne rsout pas le problme, envisagez de restaurer les
modifications apportes suite l'valuation du plan d'action. Vous devez
galement repenser la phase de classification, car il est possible que le diagnostic
et la classification initiaux taient errons.
Problme clos
Aprs avoir rsolu le problme, vous devez le fermer. Pour cela, mettez jour
l'enregistrement de base de donnes en rapport avec le problme pour indiquer
que vous avez rsolu le problme de manire permanente, puis fermez
l'enregistrement.
22.2.
Il est possible que vous puissiez rsoudre le problme signal pendant l'tape
initiale de cration de rapport. Ceci est particulirement vrai dans le cas de
problmes relativement simples. Si vous ne parvenez pas rsoudre
immdiatement le problme, vous devez rassembler le plus d'informations
possible propos du problme dans le but d'identifier les causes possibles. Vous
pouvez utiliser des outils d'analyse, consulter des journaux des vnements ou
simplement poser des questions supplmentaires l'utilisateur pour recueillir
davantage d'informations.
22.2.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
11 - 99
Diagnostiquer un problme
22.3.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
12 - 99
Diagnostiquer un problme
continuez de faon mthodique jusqu' ce que vous dcouvriez la source
du problme.
L'approche soustractive est une mthodologie dans laquelle vous vous
reprsentez mentalement les composants systme de l'ordinateur.
Sparez les composants en deux le long d'une ligne que vous pouvez
tester. Par exemple, 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
qui pose problme.
Quelle que soit l'approche pour laquelle vous optez, l'objectif de cette tape est
d'isoler la cause du problme. Lorsque vous pensez l'avoir dtermine, vous
devez tester vos hypothses. Si les tests s'avrent concluants, continuez jusqu'
ce que vous ayez dtermin la cause relle.
Une fois que vos tests ont rvl la cause d'un problme, vous devez planifier les
actions suivantes. Par exemple, si le problme implique le remplacement d'un
disque du serveur, vous devez commander 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 des donnes sur celui-ci.
22.3.1.
Mthodes conseilles de dveloppement d'un plan
d'action
Les problmes simples sont faciles rsoudre rapidement et leur plan d'action
peut ne pas demander beaucoup de rflexion. Par exemple, si un utilisateur final
signale qu'il a oubli son mot de passe, votre plan d'action consiste ouvrir
Utilisateurs et ordinateurs Active
Directory et rinitialiser le mot de passe. Toutefois, les problmes plus graves
ou plus complexes exigent une certaine rflexion.
Analyser les donnes disponibles
Avant de commencer modifier la configuration, analysez les donnes
disponibles pour vous assurer que vous avez dtermin la cause probable du
problme signal.
Consulter la documentation
Consultez toute la documentation relative au correctif que vous envisagez de
mettre en uvre. Par exemple, si celui-ci requiert l'installation d'un Service Pack,
examinez la documentation relative au Service Pack.
Crer un environnement de test
Si le correctif envisag ou la solution de contournement implique une
reconfiguration significative ou si des problmes surviennent pendant la mise en
uvre du correctif, la productivit des utilisateurs pourrait s'en trouver affecte.
Il est important que vous criez un environnement de test qui ressemble
troitement au systme de production et l'utilisiez pour tester votre plan
d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
13 - 99
Diagnostiquer un problme
un moyen pratique de crer des environnements de test sans requrir
d'investissements majeurs dans du matriel ou des logiciels supplmentaires.
Considrer l'impact des modifications
Vous pouvez tre amen effectuer un important travail de reconfiguration pour
rsoudre des problmes complexes. Les modifications que vous envisagez
peuvent avoir une incidence sur de nombreux lments de votre organisation.
Par exemple, si le correctif que vous projetez d'implmenter ncessite le
redmarrage d'un serveur auquel les utilisateurs sont connects, tel qu'un
serveur de messagerie ou un serveur de base de donnes, vous devez prvoir
l'implmentation du correctif en dehors des heures ouvres.
En outre, vous devez vrifier que les modifications proposes ne nuiront pas aux
autres applications ou services.
Prvoir une restauration
Si vous implmentez un correctif ou solution de contournement qui ne rsout pas
le problme, vous pouvez envisager de revenir en arrire. L'excution d'une
restauration n'est pas ncessaire, mais peut tre souhaitable dans des
circonstances particulires.
Par exemple, si le correctif implique l'application d'une mise jour, la
suppression de la mise jour peut tre acceptable. Toutefois, si le correctif
implique la mise niveau d'applications pour inclure de nouvelles fonctionnalits
qui peuvent tre utiles aux utilisateurs finaux, il peut tre souhaitable de laisser
les nouvelles applications installes plutt que de rtablir l'application plus
ancienne. Vous pouvez utiliser l'environnement de test pour vous entraner
annuler un correctif ou une solution de contournement propos.
22.4.
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 la disponibilit des services. Les grandes organisations ont des procdures de
gestion des modifications auxquelles vous devez vous conformer.
Avant de modifier la configuration, valuez quels aspects de la reconfiguration
vous pouvez raliser distance avec des outils d'administration et des utilitaires.
Vous pouvez rsoudre beaucoup de problmes avec des techniques de gestion
distance pour viter de vous 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 de l'utilisateur final.
22.4.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
14 - 99
Diagnostiquer un problme
Avant de tenter de mettre en uvre un correctif sur le systme de production,
implmentez votre plan d'action dans un environnement de test. Gardez l'esprit
que le processus de modification de quelques aspects de la configuration d'un
ordinateur peut rsoudre un problme spcifique, mais peut introduire d'autres
problmes. Ainsi, si vous appliquez une mise jour de scurit au systme
d'exploitation pour rsoudre un problme de scurit, celle-ci peut modifier le
comportement de certaines applications.
Lorsque vous tes satisfait que le correctif ou la solution de contournement
puisse tre implment sans provoquer de problmes supplmentaires et qu'il
rsout le problme signal, passez l'tape suivante. Les problmes simples
peuvent ne pas requrir cette tape de test.
Analyser l'impact possible
Vous devez vous assurer que toutes les modifications que vous envisagez
d'implmenter ne nuiront pas au reste de l'infrastructure informatique. Par
exemple, il est possible que sur un ordinateur spcifique, un nouveau pilote de
priphrique pour un composant matriel suspect soit l'origine de conflits entre
priphriques qui provoquent des problmes de dmarrage de l'ordinateur. Au
niveau de l'organisation, l'installation d'un Service Pack sur un serveur de
messagerie peut changer la faon dont les serveurs grent certains types de
messages et provoquer la non-remise des messages.
Ces problmes potentiels seront visibles lorsque vous implmenterez votre plan
d'action dans l'environnement de test. Vous pourrez alors corriger votre plan
d'action afin d'viter que ces problmes ne se produisent dans l'environnement
de production.
Se reporter la gestion des modifications
Les grandes organisations implmentent des procdures de gestion des
modifications pour garantir que le personnel de support technique apporte des
modifications l'infrastructure informatique conformment aux instructions et
qu'il les documente suffisamment une fois effectues. Si votre organisation utilise
une telle procdure, vous devez dterminer ce qui est requis de vous lors de
l'implmentation du correctif ou de la solution de contournement. Consultez la
documentation adquate, et lorsque cela est ncessaire, discutez des
modifications proposes avec les personnes appropries.
Rsoudre le problme
Les spcialistes du support technique peuvent souvent rsoudre rapidement les
problmes les plus courants, sans faire appel aux spcialistes des produits. Les
problmes moins courants ou plus complexes requirent souvent l'intervention
de spcialistes de support technique ou de fournisseurs externes, et parfois la
cration d'une quipe spcialise regroupant les comptences ncessaires la
rsolution d'un problme particulier. Lorsque cela est possible, considrez
l'utilisation des outils et des utilitaires d'administration distance, car ceux-ci
permettent souvent de trouver des solutions plus rapidement.
Surveiller et valuer
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
15 - 99
Diagnostiquer un problme
Si un correctif ou une solution de contournement est susceptible de prendre
plusieurs heures et d'impliquer plusieurs tapes, vous devez surveiller la
progression du processus de rsolution du problme. Il est important que vous
valuiez les donnes collectes lors de ce processus pour dterminer si vous tes
sur le point de trouver une solution. Si les donnes ne vous permettent pas de
l'affirmer, envisagez de revoir votre plan d'action.
Rendre compte et documenter
Qu'un problme soit compltement rsolu ou non, vous devez documenter toutes
les tapes que vous avez effectues pour le rsoudre ou tenter de le rsoudre. Si
vous avez consign l'incident dans une base de donnes pour suivre son tat,
vous devez mettre jour l'enregistrement pour indiquer que le problme a t
rsolu ou non et si l'incident est clos ou non. La rubrique suivante traite plus
particulirement du processus de consignation d'une rsolution d'un problme.
22.5.
Documentation de la rsolution
22.5.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
16 - 99
Diagnostiquer un problme
informations se rapportant ce problme ainsi que la procdure d'installation du
Service Pack dans la documentation relative l'infrastructure.
Crer une nouvelle documentation
Les problmes graves et complexes entranent souvent des modifications
d'infrastructure majeures. Vous devez crer la documentation ncessaire pour
prendre en charge ces modifications. Par exemple, si vous installez une nouvelle
version d'une application pour rsoudre un problme, mettre jour la
documentation existante ne suffit pas. La nouvelle version de l'application peut
comporter de nouvelles fonctionnalits et peut fonctionner diffremment de
l'ancienne version. Vous devez communiquer aux utilisateurs et aux
administrateurs qu'ils doivent dsormais travailler sur la nouvelle version.
Consigner la rsolution
Vous devez mettre jour tous les enregistrements de base de donnes associs
un incident. La mise jour doit inclure la rsolution et toute autre information
pertinente relative au correctif ou la solution de contournement utilis pour
rsoudre le problme.
Vous ne devez pas considrer un problme comme rsolu tant que la rsolution
n'a pas t documente de faon tre utile pour la rsolution d'incidents
ultrieurs. Enfin, vous devez clore l'enregistrement d'incident.
Communiquer avec l'utilisateur final
Vous devez permettre l'utilisateur final qui a signal le problme de savoir que
vous avez rsolu le problme. Si l'utilisateur doit prendre des mesures spciales
ou doit contourner le problme, vous devez l'en informer. Si vous avez apport
des modifications significatives l'infrastructure, les utilisateurs peuvent avoir
besoin de recevoir une formation.
Consigner des mesures prventives
Un problme ayant tendance se rpter, il est essentiel que vous le
documentiez ainsi que sa cause et les tapes qui ont permis de le rsoudre. Une
documentation adquate garantit que les ingnieurs de support technique qui
seront confronts au mme problme puissent dcouvrir une cause probable et
une solution recommande tt dans le processus de rsolution.
Mettre laccent sur un point particulier
Note dattention particulire.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
17 - 99
Diagnostiquer un problme
Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du support
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
18 - 99
Diagnostiquer un problme
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
19 - 99
Sommaire
1.
2.
Introduction.....................................................................................2
Mthodologie de rsolution des problmes............................................2
2.1. Classification.................................................................................2
2.2. Test.............................................................................................2
2.3. Transmission.................................................................................3
2.4. Rapport........................................................................................3
3.
Utilisateurs d'une mthodologie de rsolution des problmes..................3
3.1. Utilisateurs finaux..........................................................................4
3.2. Spcialistes du support technique....................................................4
3.3. Ingnieurs du support technique......................................................4
3.4. Responsables et planificateurs.........................................................5
4.
tapes types d'une mthodologie de rsolution des problmes................5
4.1. Consignation du problme...............................................................5
4.1.1.
Processus de consignation des problmes....................................5
4.2. Collecte des informations................................................................8
4.2.1.
Processus de collecte initiale des donnes...................................8
4.3. Dveloppement d'un plan d'action....................................................9
4.3.1.
Mthodes conseilles de dveloppement d'un plan d'action............9
4.4. Implmentation du plan d'action....................................................11
4.4.1.
Processus d'implmentation d'un plan d'action...........................11
4.5. Documentation de la rsolution......................................................12
4.5.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
1 - 99
23.
Introduction
24.1.
Classification
24.2.
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
Document
Millsime
Page
OFPPT
janvier 09
319479686
2 - 99
@
24.3.
Transmission
24.4.
Rapport
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
3 - 99
25.1.
Utilisateurs finaux
25.2.
25.3.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
4 - 99
25.4.
Responsables et planificateurs
26.1.
Consignation du problme
26.1.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
5 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
7 - 99
26.2.
Il est possible que vous puissiez rsoudre le problme signal pendant l'tape
initiale de cration de rapport. Ceci est particulirement vrai dans le cas de
problmes relativement simples. Si vous ne parvenez pas rsoudre
immdiatement le problme, vous devez rassembler le plus d'informations
possible propos du problme dans le but d'identifier les causes possibles. Vous
pouvez utiliser des outils d'analyse, consulter des journaux des vnements ou
simplement poser des questions supplmentaires l'utilisateur pour recueillir
davantage d'informations.
26.2.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
8 - 99
26.3.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
9 - 99
26.3.1.
Mthodes conseilles de dveloppement d'un plan
d'action
Les problmes simples sont faciles rsoudre rapidement et leur plan d'action
peut ne pas demander beaucoup de rflexion. Par exemple, si un utilisateur final
signale qu'il a oubli son mot de passe, votre plan d'action consiste ouvrir
Utilisateurs et ordinateurs Active
Directory et rinitialiser le mot de passe. Toutefois, les problmes plus graves
ou plus complexes exigent une certaine rflexion.
Analyser les donnes disponibles
Avant de commencer modifier la configuration, analysez les donnes
disponibles pour vous assurer que vous avez dtermin la cause probable du
problme signal.
Consulter la documentation
Consultez toute la documentation relative au correctif que vous envisagez de
mettre en uvre. Par exemple, si celui-ci requiert l'installation d'un Service Pack,
examinez la documentation relative au Service Pack.
Crer un environnement de test
Si le correctif envisag ou la solution de contournement implique une
reconfiguration significative ou si des problmes surviennent pendant la mise en
uvre du correctif, la productivit des utilisateurs pourrait s'en trouver affecte.
Il est important que vous criez un environnement de test qui ressemble
troitement au systme de production et l'utilisiez pour tester votre plan
d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent
un moyen pratique de crer des environnements de test sans requrir
d'investissements majeurs dans du matriel ou des logiciels supplmentaires.
Considrer l'impact des modifications
Vous pouvez tre amen effectuer un important travail de reconfiguration pour
rsoudre des problmes complexes. Les modifications que vous envisagez
peuvent avoir une incidence sur de nombreux lments de votre organisation.
Par exemple, si le correctif que vous projetez d'implmenter ncessite le
redmarrage d'un serveur auquel les utilisateurs sont connects, tel qu'un
serveur de messagerie ou un serveur de base de donnes, vous devez prvoir
l'implmentation du correctif en dehors des heures ouvres.
En outre, vous devez vrifier que les modifications proposes ne nuiront pas aux
autres applications ou services.
Prvoir une restauration
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
10 - 99
26.4.
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 la disponibilit des services. Les grandes organisations ont des procdures de
gestion des modifications auxquelles vous devez vous conformer.
Avant de modifier la configuration, valuez quels aspects de la reconfiguration
vous pouvez raliser distance avec des outils d'administration et des utilitaires.
Vous pouvez rsoudre beaucoup de problmes avec des techniques de gestion
distance pour viter de vous 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 de l'utilisateur final.
26.4.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
11 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
12 - 99
26.5.
Documentation de la rsolution
26.5.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
13 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
14 - 99
Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du support
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
15 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
16 - 99
Sommaire
1.
2.
Introduction.....................................................................................2
Mthodologie de rsolution des problmes............................................2
2.1. Classification.................................................................................2
2.2. Test.............................................................................................2
2.3. Transmission.................................................................................3
2.4. Rapport........................................................................................3
3.
Utilisateurs d'une mthodologie de rsolution des problmes..................3
3.1. Utilisateurs finaux..........................................................................4
3.2. Spcialistes du support technique....................................................4
3.3. Ingnieurs du support technique......................................................4
3.4. Responsables et planificateurs.........................................................5
4.
tapes types d'une mthodologie de rsolution des problmes................5
4.1. Consignation du problme...............................................................5
4.1.1.
Processus de consignation des problmes....................................5
4.2. Collecte des informations................................................................8
4.2.1.
Processus de collecte initiale des donnes...................................8
4.3. Dveloppement d'un plan d'action....................................................9
4.3.1.
Mthodes conseilles de dveloppement d'un plan d'action............9
4.4. Implmentation du plan d'action....................................................11
4.4.1.
Processus d'implmentation d'un plan d'action...........................11
4.5. Documentation de la rsolution......................................................12
4.5.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
1 - 99
27.
Introduction
28.1.
Classification
28.2.
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
Document
Millsime
Page
OFPPT
janvier 09
319479686
2 - 99
@
28.3.
Transmission
28.4.
Rapport
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
3 - 99
29.1.
Utilisateurs finaux
29.2.
29.3.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
4 - 99
29.4.
Responsables et planificateurs
30.1.
Consignation du problme
30.1.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
5 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
7 - 99
30.2.
Il est possible que vous puissiez rsoudre le problme signal pendant l'tape
initiale de cration de rapport. Ceci est particulirement vrai dans le cas de
problmes relativement simples. Si vous ne parvenez pas rsoudre
immdiatement le problme, vous devez rassembler le plus d'informations
possible propos du problme dans le but d'identifier les causes possibles. Vous
pouvez utiliser des outils d'analyse, consulter des journaux des vnements ou
simplement poser des questions supplmentaires l'utilisateur pour recueillir
davantage d'informations.
30.2.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
8 - 99
30.3.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
9 - 99
30.3.1.
Mthodes conseilles de dveloppement d'un plan
d'action
Les problmes simples sont faciles rsoudre rapidement et leur plan d'action
peut ne pas demander beaucoup de rflexion. Par exemple, si un utilisateur final
signale qu'il a oubli son mot de passe, votre plan d'action consiste ouvrir
Utilisateurs et ordinateurs Active
Directory et rinitialiser le mot de passe. Toutefois, les problmes plus graves
ou plus complexes exigent une certaine rflexion.
Analyser les donnes disponibles
Avant de commencer modifier la configuration, analysez les donnes
disponibles pour vous assurer que vous avez dtermin la cause probable du
problme signal.
Consulter la documentation
Consultez toute la documentation relative au correctif que vous envisagez de
mettre en uvre. Par exemple, si celui-ci requiert l'installation d'un Service Pack,
examinez la documentation relative au Service Pack.
Crer un environnement de test
Si le correctif envisag ou la solution de contournement implique une
reconfiguration significative ou si des problmes surviennent pendant la mise en
uvre du correctif, la productivit des utilisateurs pourrait s'en trouver affecte.
Il est important que vous criez un environnement de test qui ressemble
troitement au systme de production et l'utilisiez pour tester votre plan
d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent
un moyen pratique de crer des environnements de test sans requrir
d'investissements majeurs dans du matriel ou des logiciels supplmentaires.
Considrer l'impact des modifications
Vous pouvez tre amen effectuer un important travail de reconfiguration pour
rsoudre des problmes complexes. Les modifications que vous envisagez
peuvent avoir une incidence sur de nombreux lments de votre organisation.
Par exemple, si le correctif que vous projetez d'implmenter ncessite le
redmarrage d'un serveur auquel les utilisateurs sont connects, tel qu'un
serveur de messagerie ou un serveur de base de donnes, vous devez prvoir
l'implmentation du correctif en dehors des heures ouvres.
En outre, vous devez vrifier que les modifications proposes ne nuiront pas aux
autres applications ou services.
Prvoir une restauration
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
10 - 99
30.4.
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 la disponibilit des services. Les grandes organisations ont des procdures de
gestion des modifications auxquelles vous devez vous conformer.
Avant de modifier la configuration, valuez quels aspects de la reconfiguration
vous pouvez raliser distance avec des outils d'administration et des utilitaires.
Vous pouvez rsoudre beaucoup de problmes avec des techniques de gestion
distance pour viter de vous 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 de l'utilisateur final.
30.4.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
11 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
12 - 99
30.5.
Documentation de la rsolution
30.5.1.
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
13 - 99
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
14 - 99
Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du support
OFPPT
@
Document
319479686
Millsime
janvier 09
Page
15 - 99