Le 26/10/06, Mehdi LAGHROUR<mehdi_laghrour@???> a écrit :
> Merci pour cette leçon de sémentique :-))
> je continue avec ma vision de prédilection l'idiotie .
> Un reseau lan est souvent trés hétéroclyte des hubs en monitoring,
> des serveurs proxy, Base de donnée, et serveur de documents
> un serveur tombe j'ai donc un ticket d'incident que ce passe til ?
> le logiciel et du genre nagios ou cacti ?
> c'est automatique ? faut il le mettre sur un serveur indépendant
> j'essai de conceptualiser le principe !
Tu n'y es pas : c'est beaucoup plus simple.
Il y a un serveur dédié au ticket généralement. Tu te connectes
dessus, tu ouvres un incident, tu décris ton problème et ensuite le
ticket est récupéré par l'équipe en charge de ce problème à des fins
de gestion.
Les avantages :
- tous demandes de résolution des problèmes sont centralisées
- le format est plus ou moins génériques (tout le monde fait la même
chose, même si cela peut varier d'un ticket à l'autre pour des raisons
évidentes)
- on a un historique
- on a un suivi
- c'est le client qui CLOT la requête donc l'incident est considéré
comme terminé quand le client est content
C'est le genre d'outil qui relativiserait tout à fait les sondages
d'opinions et autres enquêtes de satisfaction de certaines entreprises
:)
Les inconvénients :
- c'est lourd
- ce n'est pas forcément très souple (cela dépend des outils)
- cela peut être galère si cela tombe dans les mains d'un obsédé des
processus (on passe alors plus de temps à entrer des indicateurs et
suivre un processus que de s'occuper de la raison de l'ouverture du
ticket).
- il faut souvent une personne ou plus pour s'occuper du système
Après, tu en fais ce que tu veux : tu peux coupler les choses
automatiquement. Un serveur qui ne répond peut déclencher une action
qui ouvre automatiquement un ticket, etc.
PK
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:p.karatchentzeff@free.fr
|,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr
'---''(_/--' `-'\_)
