Vous avez en début de semaine dernière résolu un incident de saturation d’espace disque sur un serveur en archivant des fichiers volumineux, ce qui a libéré de la place sur le serveur. En ce mercredi, un utilisateur vous appelle pour vous dire qu’à nouveau le serveur est plein

Il y a peu de temps, la DSI a piloté un grand projet de virtualisation des bases de données de l’application cœur de métier, qui est utilisée par plus de la moitié des employés. Quelque temps après la livraison en production, plusieurs utilisateurs constatent que les temps de réponse sont moins performants qu’avant la mise en production

Une alerte de supervision vous indique que la bande passante du réseau (WAN) est à la limite de saturation, mais que pour l’instant il n’y a aucun souci de lenteur réseau constaté par les utilisateurs

C’est la première fois qu’il vous indique son souci, vous créez un ticket d’incident dans GLPI, redémarrez son poste de travail et comme  l’utilisateur vous dit que cela va mieux maintenant, vous clôturez le ticket d’incident

C’est un peu la panique du côté de l’utilisateur, vous souhaitez tout de suite résoudre définitivement le problème : vous créez immédiatement un ticket de problème dans GLPI car l’utilisateur est bloqué

C’est la troisième fois que l’utilisateur vous sollicite pour le ralentissement aléatoire (parfois cela fonctionne bien) de l’application, vous le dépannez comme la dernière fois et vous créez un ticket de problème dans GLPI

Plus on résout de problèmes, plus on diminue le risque sur la performance de l’entreprise

Plus on résout de problèmes, plus l’image de la DSI est positive

Plus on résout de problèmes, plus les projets avancent vite

Plus on résout de problèmes, moins il y aura d’incidents