Remarques générales
Définitions :
Un incident : C’est une dégradation ou une interruption d’un quelconque service qui n’est pas planifiée
La priorité : C’est la combinaison de l’impact ( ou sévérité) et de l’urgence ( ou criticité) ( on peut ajouter la notion de VIP, puis de rôle au sein de l’organisation)
Attention, lorsque vous évaluez la priorité de l’incident, fiez-vous à votre connaissance des différents critères et à vos collègues, mais pas à l’utilisateur concerné. Celui-ci sera presque toujours persuadé que son incident est le plus prioritaire !
Objectif d’un service de support:
L’objectif peut être résumé par quatre expressions :
=> Rétablir le fonctionnement normal du service
=> Par tous les moyens possibles
=> Aussi vite que possible
=> Avec le minimum d’actions de la part des différents services
Une fois que le technicien est informé de l’existence d’un incident, il va le prendre en charge dans l’objectif de résoudre :
=> Les pannes matérielles
=> Les incidents réseau
=> Les défaillances logicielles
=> Les demandes diverses
Comment bien qualifier un problème :
Avant de faire tout test, il convient de savoir quoi tester !
Il est nécessaire, pour tout premier appel, de passer par une phase de questionnement de notre client.
Il n’est pas anormal que cette phase puisse prendre quelques minutes. Si notre client vous fait part de son agacement sur cette approche, il convient de lui faire comprendre que pour résoudre tout incident dans les meilleurs délais, il est nécessaire de bien le poser. A défaut, le risque de partir dans de mauvaises directions est grand, avec pour conséquence, un temps de résolution allongé au détriment du client.
Les premiers tests techniques effectués par nos soins devront corroborer la problématique qui s’est dégagée de cette première phase.
Les trois questions à toujours ( se) poser sont : Qui ? Quand ? Quoi ?
Ces questions doivent permettre de délimiter le périmètre de l incident
1. QUI ?
Une première distinction doit être réalisée entre le contact qui appelle et la/les personnes impactée(s) par l’incident.
A - Qui contacte notre support technique?
Cette information est importante à plusieurs titres :
=> Savoir qui a appelé : en cas d’escalade, notre N2 doit pouvoir joindre la bonne personne. Noter le nom du contact ainsi qu’un numéro de téléphone est indispensable. La ligne directe ou un numéro de portable est un plus.
=> En cas de site isolé, il faut pouvoir récupérer un numéro de portable d’un contact pouvant redémarrer les routeurs. En effet, la téléphonie sur IP peut être impactée et dès lors, le standard de l’office peut être injoignable.
=> En cas d’appel d’un prestataire : les informations pour le rappeler ou envoyer des mails sont indispensables.
B - Qui est réellement impacté par l’incident ?
Cette question permet de comprendre l’impact de l’incident pour le client. Et permet de vérifier que c’est bien l’utilisateur concerné qui est au téléphone. Par exemple, cela peut être le cas de la secrétaire appelant pour le notaire, le clerc qui appelle pour sa collaboratrice absente… Autrement dit, il est nécessaire d’être vigilant avec les informations remontées par le contact si ce n’est pas celui-ci qui est l’utilisateur concerné.
Il convient donc de savoir si :
- L’incident touche une seule personne
- L’incident touche un groupe de personnes :
- Un service ?
- Une partie de l’office ?
- L’incident touche tout l’office
2. QUAND ?
Cette question doit, elle aussi, être vue sous deux angles différents :
A - Depuis quand a commencé l’incident ?
=> En fonction du retour de client, vérifier l historique existant dans l'outil de tickets. S’il y a plusieurs tickets, il est nécessaire de les consulter afin d’orienter le questionnaire en fonction des actions ou tests déjà réalisés. Cela permet de confirmer que la raison de l’appel est toujours sur la même problématique.
=> Le but de cette question est de permettre de déterminer qu’un dysfonctionnement a commencé à : ( liste non exhaustive)
- une date précise
- après une maintenance d’ADNOV ou d’un prestataire
- après une mise à jour, sur un poste, un serveur..
B - Quelle est la fréquence de l’impact ?
- L’effet est permanent, c’est-à-dire que les effets sont ressentis continuellement.
- L’effet est récurrent :
I. La récurrence est-elle aléatoire ?
II. La fréquence est-elle régulière ? Pouvons nous dégager des causes à cette récurrence régulière ?
3. QUOI ?
L’objectif de cette question est donc de bien comprendre la problématique pour en tirer des pistes de résolution.
Cette partie est la plus compliquée, car il faut traduire les termes utilisés par le client en problématique technique.
Or, le client n’est pas technicien informatique. Les termes utilisés seront toujours approximatifs. Il appartient donc au technicien d’en tirer des enseignements techniques.
=> Une bonne façon de traduire techniquement les termes utilisés par le client est de les reformuler de façon pédagogique
Exemple non exhaustif :
Le client dit : Internet ne marche pas
Le technicien reformule : quand vous utilisez votre navigateur habituel, les pages auxquelles vous souhaitez accéder ne s affichent pas, c’est bien cela ? ou vous avez peut-être un message d’erreur qui s’affiche?
Les réponses données par le client doivent commencer à orienter le technicien vers les premiers tests qui lui serviront à confirmer la problématique et à la qualifier
=> Si le client ne peut répondre au technicien, une prise en main à distance pour constater et confirmer le dysfonctionnement est primordiale
=> Il faut ensuite résumer le dysfonctionnement de la façon la plus claire possible et technique.
Exemple non exhaustif :
- Quand l utilisateur cherche à accéder à tel site internet, il obtient le message suivant [ erreur 504]
- Quand l’utilisateur cherche à naviguer vers les sites internet grand public, il obtient ce résultat [ pages blanches]
Exemples non exhaustifs de problématiques récurrentes chez ADNOV :
Voici une liste de questions non exhaustives qu’il faut se poser( ou tester) afin de vérifier l’ensemble des services qui fonctionnent, et à contrario, ceux qui ne fonctionnent pas.
1- Sur Ballade
- Est on sur un problème de lancement du logiciel Cisco Anyconnect ?
- Est on PMAD sur le poste qui doit faire fonctionner Ballade ?
- Est on sur un problème d accès à la mire d’authentification ?
- Est on sur un problème d’authentification ?
- Est on sur un problème de stabilité de la ligne utilisée sur Ballade ?
- Est on sur un problème de navigation sous Ballade ?
- Est on sur un problème d’accès aux ressources de l’office, si oui, les options DNS mobilité ou nom de domaine mobilité sont elles bien renseignées ?
- Quel est le compte BALLADE utilisé ?
- …
2 - Pour un site isolé
- Peut on naviguer vers les sites internet ?
- Peut on naviguer vers les sites métiers ?
- Les mails sont ils reçus ?
- Une PMAD est elle possible ?
- La téléphonie est elle sur IP ? si oui, fonctionne t elle ?
- La supervision corrobore t elle le ressenti du client ?
- …..
Informations à mettre dans tout ticket réseau :
Cette section porte sur les informations essentielles qui doivent figurer dans les tickets d’incidents, notamment dans ceux qui font l’objet :
=>' d’un traitement de plus de deux jours
=> d’une escalade
Ces informations sont nécessaires dans trois cas de figure :
Pour aider les membres de l’équipe
Pour faire gagner du temps au service N2 ou N3
Pour établir des statistiquess sur l’incidentologie et ainsi permettre plus facilement d’améliorer nos produits
Point de vigilance : il est impératif de vérifier l’existence de ticket d’incident déjà ouvert, et d’alimenter ces tickets si le but de l’appel est sur la même problématique.
1. Le nom du ou des routeurs concernés
Cette information est obligatoire pour toute escalade réseau afin d’être sur de lancer des investigations sur le bon équipement ou le bon site.
2. L’offre réseau
Cette information est obligatoire pour tout traitement d’incident réseau. En effet, la qualification et les tests réalisés dépendent toujours de l’offre réseau de l’office. Autrement dit, on ne traite pas un dysfonctionnement sur l’offre SérénIT comme sur l’offre UnIT par exemple.
De plus, il est très utile de noter les caractéristiques suivantes : la qualité d’office Naté ou Routé :
3. Le/les sites impactés en cas de multisite ou multioffice
Cette information est bien entendue importante pour une bonne qualification, mais aussi en cas de rappel à effectuer.
4. La SSII
Cette information est importante, notamment dans le cas de la qualification des incidents généraux
5. Les réponses aux questions issues de la phase de qualification
Afin de faire gagner du temps aux personnes qui traiteront ultérieurement le dossier, comme pour le client concernés, c’est du bon sens que toutes les informations récoltées doivent être notées dans le ticket d’incident.
6. Les tests effectués
=> Les tests ayant permis de corroborer la qualification
=> Les tests ayant permis de tester telle ou telle solution pour résoudre l’incident
7. La qualification technique dégagée à l’aide des deux points précédents
NB : sur la nomenclature et l’objet du ticket
- celle-ci doit être mise le plus précisément possible, quand l’incident est résolu
- Sur l’objet : celui-ci doit être lisible et compréhensible pour tout le monde. Il convient d’être bref et factuel. Mettre les informations par couche/granularité