Gestion de pannes

Ça commence …

Votre ESN vous propose un poste dans le service de hotline pour répondre aux appels des clients.
Un client, L'Atelier, a déposé une demande d'assistance et des utilisateurs déclarent des incidents.

A consulter

fr : Le helpdesk du moyen âge
en : https://www.youtube.com/watch?v=pQHX-SjgQvQ

Les 3 coûts cachés

Dis donc, t'as vu que ...?

• Beuh, je bosse, moi. Bon alors ... (on répond au problème)
• (plus tard) Ouf, fini. Euh, j'en étais où avant le coup de fil ?

Les interruptions quotidiennes génèrent des délais et du temps de reprise d'activité :

• Interruption : changement de contexte
• Jusqu'à 15' pour reprendre l'activité = temps perdu

Changement de contexte (le plus évident)

À chaque fois qu’un collaborateur est interrompu dans son travail, il perd son contexte de travail, prend le temps de répondre à son interlocuteur puis doit se replonger dans ses tâches.
Or, une fois que notre état d’extrême concentration et de productivité a été interrompu - notion de flow -, il nous faut parfois jusqu’à 15 minutes pour se retrouver dans un état similaire.

Hé! Tu sais pourquoi ?

• (SIO, le tech') Euh, oui ? C'est pour quoi ?
• (Salim, un collègue) ...
• Ah. Alors, tu fais ... Et voilà.
• Pas si vite ! Tu peux répéter ? y a un truc que j'ai pas saisis là.
• Ok, on reprend. ...
• Merci :)
• ...
• (Julie, une collègue) Dis donc, j'ai besoin de tes lumières pour ...
• (SIO) {Et je bosse quand, moi ?} Bon. Alors, ...

Les questions tombent souvent sur la même personne ...

• L'expert est plus souvent interrompu
• Manque de partage de connaissances

La rançon du succès de “celui-qui-sait”

• Dans une équipe, “celui qui sait” est plus souvent interrompu, quel que soit l’objet de la demande.
  Il risque d'être dans l’incapacité de faire avancer ses tâches. Le manque de partage de connaissances génère un coût important pour l’entreprise en ralentissant les experts de leur domaine.
• Ce mode de fonctionnement enferme "l'expert" dans une position de sachant.
  Il est le seul à savoir et aucun autre membre de l’équipe ne pourra ou n'aura envie de le remplacer.

Il faut briser ce cercle vicieux.

• Partager la connaissance au sein d’une équipe, améliorer sans cesse la connaissance individuelle et collective
  pour réduire les risques sur les projets et donner la possibilité à chacun de progresser.
• En cas de problème (indisponibilité du "sachant", si la connaissance est partagée,
  l'équipe sera capable de réagir plus vite avec des idées claires et originales pour aboutir à une solution performante.

Quoi encore ?

• (Un(e) collègue) : Dis, ...
• (SIO) {Grrr! quoi, encore ? je vais demander une augmentation, moi !} ...
• (Boss) Dites, M.SIO, votre projet. Il avance ?
• (SIO) Oui, mais ...
• (Boss) Écoutez, c'est bien gentil de répondre aux demandes à la volée. Le client n'attend pas et le projet devrait être terminé pour ... hier !
  Si ça continue, je vous sucre votre prime de fin d'année.
• ... {Pfff! Et tu trouvera ma dem' sur ton bureau. Na!}

La pression, le manque de reconnaissance augmentent le risque de perte d'expertise.

• Blocage dans la réalisation au travail : je ne progresse pas
• Perte des capacités de réflexion, blocage du projet : comment faire avancer les projet si je suis contamment interrompu ?
• Perte de motivation, agressivité
• Démission ?

Perte de motivation

• Le travail est ralenti voir interrompu, la reprise de contexte crée des pertes dans le processus de conception (perte du fil de réflexion),
• Le regard des collègues et la satisfaction se dégradent,
• Les compétences et l'assiduité est remise en question par la hiérarchie.

Jusqu’au jour où ce collaborateur quitte l’entreprise pour mieux s'accomplir ailleurs.

Allo Houston ? nous avons un problème ...

• Bonjour, je vous appelle à l'aide.
• Ah ? ET c'est quoi, le problème ?
• Ben, voila, le problème vient de .... bla bla bla ....
• Ouuuh làààà ... c'est compliqué. J'ai pas d'info sur ce type d'incident. C'est un problème de spécialistes, ça.
  bon, je vais voir avec eux et je reviens vers vous.
• ok, mais ça devient un peu urgent, il y a déjà des ralentissements dans la prod'.
• oui, en plus l'impact est assez conséquent donc je donne une priorité assez haute à l'incident.
• a +

Escalade dans l'expertise

Et voilà, l'information est transmise à un niveau de compétences supérieur où le problème sera décortiqué, analysé et des spécialistes tenteront d'y donner une solution.
En cas d'incapacité à trouver une solution, les spécialistes transmettront le dossier aux expert, dernier niveau, qui prendront des mesure de l'ordre de la modification du logiciel pour résoudre le problème.

Nous avons donc un processus d'escalade à trois niveaux de compétences et de responsabilités.
Plus d'infos sur l'escalade en finb de document.

La gestion de panne est un des outils pour partager l'information entre les membres d'une organisation.
Elle permet de structurer la connaissance disponible, de planifier les interventions, de réagire rapidement face aux incidents.

Les appels (demandes, déclaration d'incidents) émanent de différentes personnes, situées dans différents locaux, utilisant un matériel varié.

Question : Que doit-on savoir pour mieux gérer le parc ? pour :

• limiter les coûts,
• avoir un processus de gestion des incidents fiable et rapide,
• mémoriser les solutions des situations déjà vues et accélérer la résolution des futurs événements ?

Pour limiter au maximum ces coûts cachés, il est essentiel de mettre en place un processus de gestion d’incidents. Ceci afin de réduire les interruptions et de préserver la concentration sur les tâches à valeur ajoutée.
Ensuite, mettre en place un système, soit par des outils ou des pratiques, qui permet de mémoriser les incidents passés afin d’accélérer la résolution des incidents en cours.

En raison de l'intégration numérique croissante - l'informatique, la numérisation pénètre tous les secteurs de communication mais aussi du traitement et de la synthèse de l'information -, on ne peut plus se passer de l'informatique dans une organisation (à tort ou à raison ?)
Ile donc nécessaire de gérer et connaître son parc et son évolution.

Inventaire matériel, soft, licences, contrats, autant d'éléments à gérer :

• Pour faire vivre le parc :
  Ajouter les données de fin des contrat, les échéances garanties, l'obsolescence de son inventaire, les dates et contraintes d'entretien.
• Pour la gestion des pannes :
  Quel est le coût d'un arrêt ?
  • Dépend de paramètres (durée, coût, rentabilité, criticité)
• La triade CIA : Confidentialité, Intégrité, Disponibilité

Enjeux financiers ==

Les pannes (arrêt, erreurs, ralentissements, …) informatiques ont donc un impact de + en + grand sur l'organisation et sur le coût des traitements. En cas de panne, le traitement des pannes peut être long avant reprise de l'activité, d'où la profondeur de l'analyse, de l'investissement de la réparation modulés en fonction de l'impact et de l'urgence de l'incident pour ne pas dépasser le coût de la panne (optimum). Cet Optimum se comporte comme la théorie de Pareto : 20% du projet, au delà de l'optimum, consomme 80% des ressources.
On arrêtera donc les investigations sur un incident autour de 80% de satisfaction des utilisateurs. Le reste est soit dans le pot des pertes et profits, ou on aura trouvé une solution de contournement du problème.
Selon un Rapport d’IBM (2023), le coût total moyen d’une violation de données a atteint le nouveau record de 4,45 millions de dollars en 2023.
Ce chiffre représente une augmentation de 15,3 % par rapport aux 3,86 millions de dollars évoqués dans le rapport de 2020 (source IBM).

Normalisation & bonnes pratiques

Au début de l'ère industrielle les managers (Taylor, Ford) on fait un énorme effort pour standardiser l'infrastructure, les postes, les pièces.
Cet effort fait partie des bonnes pratiques des systèmes d'information qui utilisent :

• Normaliser les pratiques : ISO, ITIL
• Démarche EBIOS (Expression des besoins et identification des objectifs de sécurité)

Il faut donc prévoir les aléas avec des actions de normalisation du parc et de mise en place de bonnes pratiques.
Des référentiels existes, en particulier :

• ISO : les points à contrôler, les conditions à respecter dans les installations, les traitements, les procédures de contrôle et de gestion
• ITIL : Les bonnes pratiques pour éviter et anticiper les incidents, minimiser leur conséquences.

Objectifs de cet effort

L'objectif est la recherche de la qualité de service pour :

• Réduire le nombre d'incidents, moins d'incidents = utilisateurs contents ;
• Diminuer les temps de résolution, moins de panique, moins d'attente, meilleure satisfaction ;
• Améliorer la disponibilité du service ;
• Mieux gérer les changements, mieux planifiés, mieux adaptés aux besoins ;
• Au final :
  • Maîtrise des coûts : prévisibilité, réduction des aléas;
  • Augmenter la productivité des employés, du service helpdesk

Comment faire ?

La solution tient en quelques mots : prévoir : contrôler, documenter, superviser

Comment prévoir ? en utilisant les outils :

• FAQ (Frequently Asked Questions ou Foire Aux Questions) : permettre la résolution directement par l'utilisateur, avant l'extension des dégâts
• Base de connaissances : mémoriser les incidents précédents, utilisée par les techniciens de terrain,
• Formation des utilisateurs : pour prévenir les pièges les plus faciles à éviter.

En cas de panne, comment trouver la panne ?

• Investigation : du plus probable, facile à réparer au + compliqué
• Faire appel à un spécialiste ?
• Réparer ou remplacer ?

Comment contrôler ? En déployant des processus organisationnels et outils de relevé des incidents, de statistique de cas rencontrés, etc. ...
Comment documenter ? En proposant un outil d'enregistrement des incidents et leur résolution, avec l'objectif de documenter les incidents (alimenter la FAQ) pour les personnes confrontées au mêmes cas.
Comment superviser ? En utilisant un moyen pour détecter les changements imprévus dans le matériel et les logiciels (panne, défaillance temporaire, mise à jour, etc.) : outil d'inventaire automatique.

Autant de questions à se poser et de solutions à appliquer.

Demande (ITIL)

Une demande :

• permet de planifier une tâche ou la réponse
• concerne un matériel, logiciel ou service réseau
• est détectée par l'utilisateur

Conséquences :

• le service est fonctionnel mais risque de s'interrompre à plus ou moins brève/longue échéance.
• les conditions de travail seraient améliorées
• avec la réponse à la demande, on pourrait dégager un gain de productivité ou un gain financier mesurables,
• etc.

Exemples de demande :

• simple : le tooner est bas, il va manquer de papier,
• un logiciel devrait être remplacé, renouvelé, un matériel arrive au bout de sa garantie, il reste 30% d'espace disque disponible,
• le système demande des mises à jour, etc.

Incident (ITIL)

Un incident :

• est non planifié
• concerne le matériel, le logiciel ou l'équipement réseau
  • est détecté par l'utilisateur ou un outil de contrôle du service (supervision).

Conséquences :

• le service est
  • bloqué ou
  • fonctionnel mais partiel ou
  • ralenti de façon sensible
• les conditions de travail sont dégradées : la sécurité des personnes et biens pourrait être mise en danger
• il existe un risque pour l'activité à plus ou moins court terme.

Le statut du service passe de nominal ou normal à dégradé ou interrompu.

• Arrêt, dégradation ou ralentissement du service

Exemples d'incidents :

• souris, clavier en panne, mal configurés
• manque de toner, imprimante bloquée par d'autres docs, bourrage.
• bug logiciel
• non accès à une ressource (quel que soit le mode d'accès : NFS, http, menu déroulant/recherche vide, etc…)
• lenteur du système : poste local, réponse du serveur

Problème (ITIL)

Un problème

• est détecté par une analyse des incidents
  • automatiquement avec un outil de gestion et d'analyse des incidents (supervision, gestionnaire d'incidents) ou
  • manuellement par les techniciens du helpdesk

Conséquences (en plus de celles de l'incident) :

• la résolution demande un approfondissement des causes des incidents ou du problème
  • on effectue l'élimination de la cause des incidents
  • on trouve des stratégies de contournement du problème pour éviter son apparition

Conséquences :

• service bloqué, partiellement fonctionnel, ralenti
• un sur coût est investi pour la résolution du problème avec l'espoir de supprimer les multiples incidents et dégager un gain final.

Si le gain est négatif ou négligeable, il est possible d'employer une stratégie de contournement (renouveler le matériel, chenger de logiciel) ou de supprimer l'élément en cause.

Exemples de problèmes :

• perte de configuration récurrente, d'accès à une ressource impossible mais demandée par différents acteurs du SI
• erreur de configuration du serveur
• etc.

Ticket (ITIL)

• Qui : qui demande, répond ; nbre de personnes concernées ⇒ Impact
• Quoi : identification du matériel concerné
• Où : Lieu pour un éventuel déplacement
• Quand : Dates des événements (demande, analyse, réponse, questions intermédiaires)
• Comment : sur place, à distance, logiciel, matériel, remplacement ?
• Pourquoi : motif = demande, panne ⇒ Urgence

Lors de la déclaration de l'incident, on détermine un degré d'urgence.
Lors de l'affectation de l'incident à une équipe de résolution, on détermine l'impact de l'incident.

Urgence et Impact

L'urgence est déterminée par la victime, éventuellement par une application de supervision paramétrée pour répondre à ce besoin.
L’urgence permet aussi d'influencer la solution : mise en place d'une solution définitive ou de contournement.

Le périmètre est mesuré par le centre de service/helpdesk et calculé en fonction :

• du nombre de personnes/matériels/services concernés,
• de l'importance des personnes/matériels/services touchés dans l'organisation

(Martice de calcul de la priorité dans GLPI.)

Les indicateurs de performance

• Nbre de ticket résolus : Cependant, certains tickets pourraient être clos sans résolution (incident non résolu, obsolète, remplacement du matériel, du logiciel, …)
• délai de prise en compte : Délai entre la date d'ouverture et la date de début de résolution (attribution)
• durée de traitement : Durée entre la date de début de résolution et la clôture du ticket

Les temps critiques

• MTTR (Mean Time To Repair) : Temps moyen de réparation, ne tient pas compte du délai de détection ni du délai de reprise d'activité.
  Le temps total d'arrêt permet de calculer le temps moyen d'indisponibilité (MDT Mean Down Time).
• MTTF (Mean Time To Failure) : Temps moyen avant la (1ère) panne (pour un équipement non réparable et devant être remplacé - la durée de vie, quoi !).
• MTBF (Mean Time Before Fail) : Délai moyen avant la prochaine panne d'un équipement réparable ou fréquence moyenne à laquelle une défaillance se produit dans un système de production
  Calculé à partir du début de la réparation jusqu'à une nouvelle interruption.
  Noter que ce temps ne tient pas compte de celui nécessaire à détecter la panne avant de commencer à la résoudre...
• durée de traitement : Durée entre la date de début de résolution et la clôture du ticket

Des petits liens ?

• Explication plutôt théorique : mttf (wiki)
• Explication orientée management : mttf (pureStorage.com)
• théo : mtbf (wiki)
• mana : mtbf (pureStorage.com)
• Article assez complet, voir surtout le schéma de synthèse en fin d'article : Calculs et définitions (jakadit)

Les règles d'or

PEBCAK (Problem Exist Between Chair And Keyboard) : L'erreur est entre le clavier et … la chaise ? Pas toujours ...

• Observer et écouter les utilisateurs : /!\ une réclamation est toujours légitime !!! la mauvaise foi est assez rare
  • Analyser les tickets d'incidents, discuter à la machine à café
  • Compréhension, adaptation produit ⇔ besoin, manque de fonctionnalité
• S'informer et constater, tester
  • test, supervision, contrôles
  • ralentissement du réseau
  • Bugs, données fausses, incomplètes, indisponibles, etc… Ralentissements, plantage
• veille technologique sur les vulnérabilités (rem : pas du bloc 3)

Viser le plus probable

Clusif : services essentiels (rapport 2010)

• Soft
  • Erreur de saisie, de manipulation (pbm d'interface, de sac)
  • Bug : erreurs de programmation, de traduction
• Infra
  • Erreurs de manipulation (ici aussi)
  • Erreurs de connexion, de configuration
  • Panne matérielles : peu probables, faciles à détecter
  • Câble arrachés, chute, matériel éteint, déconnecté

Petit palmarès des incidents

• 1ère place : les services essentiels
• 2ème place : les erreurs humaines (utilisation ou développement, configuration)
• 5ème place : Virus :
• 10ème : attaque
• 20ème : malveillance, vol

clusif rapport enquête 2024

Il faut lire les messages d'erreur !!!
Et si possible développer de manière qu'ils soient compréhensibles et clairs ...

Exemples

Huggy les bons réflexes regarde toujours ...
Matériel et logiciel :

• Alim, câblage ?
  • Le Câblage d'abord : vers le secteur, les périphériques, interrupteur d'alim ?
• Messages ?
  • Système : messages au boot ?
  • OS : message à la connexion ? (à lire absolument)
  • Applications : messages divers : erreur de version, de lecture de fichiers (droits), etc. …
• Erreur de manip ?
  • Observer l'utilisateur

Réseau :

• Câblage d'abord (voyants, état des câbles)
• Tests, config : adresse, proxy, dns
• Ping, tracert, nslookup
  • Ping vers l'extérieur (un dns public, google)
  • ip => config IP, connectivité, passerelle
  • url => config PC : DNS
  • Ping successifs vers le routeur, firewall, dns, dhcp ; route, nslookup
• Vérifier la config du navigateur (proxy)

Analyser les pannes : Redémarrer dans l'ordre pour éviter tout sur-incident.

Pour diagnostiquer rapidement une panne sur un hôte,

• Écouter les explications de l'utilisateur
• Redémarrer avant dépannage et observer si tout va bien, vérifier les logs et journaux
• Tenter de reproduire la panne, redémarrer les applis
  Voir l'alimentation, les éléments manipulés (câbles) En dernier ressort seulement : Réinitialiser les applications, restaurer un point de restauration, réinstaller l'OS (bof)

Quels sont les éléments fragiles ?

• Pas l'électronique, parfois l'alim, disque dur (HD & SSD)
  Mais attention aux extinctions brutales, coupures de courant, court-circuits (liquides, kusb)
• Matériel non détecté : pilote (rare) => désinstaller/supprimer découverte nouveau matos
• Complexité du système, du code des applis

… Documenter : prévoir et réfléchir

• Alimenter la FAQ

Suleques bonnes idées

• Matos de rechange : disques, cartes, câbles, PC
• Tester sur un autre PC (le matériel, les logiciels, périphériques, câbles)
• KISS : Keep it simple Stupid => Efficience et simplicité
  Chercher le maillon faible (retour du côté de la chaise …), la panne la plus probable.

Il faut suivre une démarche cohérente, ordonnée, systématique et sans aprioris, Sherlock !

Liste incomplète. Le points de vérification de chaque symptôme sont dans l'ordre logique de contrôle

Symptôme	Vérification
PC (téléphone) ne démarre pas (aucune réaction à l'appui du bouton)	220V ? branchement PC, interrupteur à l'arrière de l'alim ?, Etat de l'alimentation, de la batterie. Vérifier l'absence d'odeur suspecte (ozone, bakélite brûlée, chaud, platique fondu), de trace noire (brûlé, suie) ou de composants détériorés (condensateurs bombés, résistance noircie). Vérifier la garantie …
L'alim démarre. Aucun signal	Composants incompatibles ? Enlever toutes les cartes d'extension (même la RAM ou le Proc) et redémarrer la machine en installant successivement les composants : CPU, RAM, carte graphique, carte réseau… Au besoin, tester les composants sur d'autres PC
Signaux d'erreur (beeps, messages, leds, code)	Vérifier la signification de signaux qui sont audio (beeps), lumineux (leds de diagnostics sur la CM) ou visuels (messages, codes POST – Power On Start Tests) "Tant qu'il y a du bruit, il y a de la vie…"
Aucun affichage : a) pas de mire ; b) affichage de la mire puis extinction	a) Vérifier les branchements de l'écran (220V, interr., câble, carte), essayer avec un autre écran. Pour les portables, ça sent mauvais … ; b) Voir si on peut avoir le BIOS, utiliser un disque de diagnostic en mode texte, redémarrer en mode sans échec, vérifier le pilote, la résolution, la fréquence de balayage, …
Couleur d'affichage bizarre (dominante, moirage)	Vérifier le câble, les branchements, éventuellement changer le câble, changer de connexion (VGA/HDMI/DVI), changer l'écran pour vérifier si c'est le même problème, sur l'écran, sur le PC
Bruit continu, frottements, claquement	Pbm de ventilo, de disque ? Selon le type de bruit : Ventilo encrassé, avec des objets (allumettes, trombones, cheveux), axe usé (le huiler, le remplacer) ; Disque HS ou en cours de panne
Freeze au boot	Vérifier le trio CPU-RAM-overclocking ; RAM incompatibles, avec la CM, entre elles, température trop élevée, courant trop fort, trop bas. Vérifier la position de la RAM dans les bancs. Tester chaque RAM séparément, redescendre les paramètres d'overclocking. Rarement, le contact avec le ventirad est incorrect, le ventirad ne démarre pas, etc. … Lire la doc de la CM !
Matériels non détectés	Vérifier le SETUP du BIOS, paramétrage automatique à restaurer, faire un reset si besoin (reset soft, via l'interface, reset hard : voir doc de la CM et les cavaliers sur la CM), Si la RAM n'est pas détectée, augmenter légèrement le voltage pour voir et tester les barrettes séparément. Crossfire : si un GPU n'est pas détecté, la carte graphique est probablement mal branchée ou le port PCI-Xpress est défectueux/mort. Tester chaque carte/port, Pas de périph de stockage ou freeze à ce moment, vérifier les câbles (SATA, IDE : branchement, polarité, sens, état). Pbm de RAID : voir s'il faut flasher le BIOS (dernier recours!).
Le PC rame (cas le plus courant) /!\ L'utilisateur est tjrs impatient …	Origine : le soft => Trop de veilles de mises à jour, vider le dossier prefetch, - Trop de services inutilement démarrés, - Application trop gourmande (pc trop vieux ? Passer sous linux :D), - Trop de barres de menu ouvertes auto exécutées par des téléchargements sans contrôle ou d'onglets (navigateur), - Antivirus ? mal configuré, trop restrictif, en double, - Un virus ou autre malware, - Une appli sature le réseau (virus, logiciel en boucle, téléchargement sauvage). Origine : la configuration matérielle, plus rare, - Pas assez de RAM (moins courant), - Partition système trop petite ou trop encombrée (>90%) ou en cours de crash (gasp!)
Raccourci absent, Fonctionnalité bloquée, Le pgm ne démarre pas	Vérifier les droits de l'utilisateur, Le pgm est corrompu, buggé, mal fait, affiche des messages d'alerte
L'antivirus bloque le pgm ou son installation	Pbm de corruption du soft (téléchargé avec un virus), Pgm non reconnu comme sûr par l'antivirus … vous avez programmé un virus ?

Kit d'assistance : exemples d'outils locaux

Un peu de lecture ?

• safe-hex : "un ordinateur, c'est pas un réfrigérateur: c'est beaucoup plus compliqué". (quoi que ...)
• safe-hex : On en remet une couche, en anglais ?

Trucs et astuces

• PC : faire un point de restauration avant d'agir : retour à ce point pour régler un pbm.
• Explorer les logs

Boîtes à outils

• Pstools (µ$) analyse des ps, svces, fichier, ports, …
  • process explorer, tcpview, cports …
• Commandes : ping, netstat, tracert, etc…
• Ccleaner, et autres, clonezilla, testdisk, etc…

M. Yeoh, intervenant à L'Atelier, appelle le helpdesk via le standard.
La personne du standard vous transmet qu'un poste de présentation montre des défaillances avec les symptômes suivants :

• L'écran est instable, il clignote n'importe quand et le vidéo projecteur perd l'image

Elle vous demande d'aller sur site pour régler le problème d'urgence.

• Quelles sont les précisions à demander pour cerner le problème ?
• Quelles sont les informations à rechercher dans la base d'inventaire ?
• Proposer une série d'actions
• Déterminer la priorité de l'incident
• Quel problème voyez-vous dans la chaîne de transmission de l'information ?
• Quelle différences entre sûreté et sécurité ?

Développement

• Effectuer des tests positifs
  • si oui alors
  • pas de test négatif comme : si non, alors
• Faire tant que plutôt que faire jusqu'à (php, java, C, etc…)
• Mettre en place des détrompeurs (listes déroulantes)
• Documenter les événements : LOG explicites
  • voir le log des erreurs Apache, le log système …

Réseau

Respecter les normes, les conventions

• normes de câblage réseau (voir ci-contre)
• masque réseau de la "classe" même si elles ont disparu

ET VOUS ?

La résolution en 5 à 7 étapes

1. Identification & déclaration de l’incident

• Le ticket d’incident contient tout le suivi des actions techniques tout au long de la vie de l’incident.
• Le déclarant détermine l'urgence de l'incident.

2. Qualification de l'impact, priorisation du traitement

• Déterminer l'impact, tenant compte de la population concernée, des risques,..., de l'incident.
• Ceci permet de calculer sa priorité et de classer les incidents.
• Communication à l’attention des parties prenantes, surtout dans le cadre d’un incident majeur, pour assurer au mieux la sérénité des acteurs de l’incident.
  • gestionnaires de l'incident : équipe de liaison et coordination, de communication sur l'incident. définissent le Plan de communication (cannaux, fréquences de la comm, types d'alerte diffusées, etc.),
  • managers : DSI, CTO, RSSI. Responsabiliser l'entreprise, décider de la conduite à tenir, surtout en cas de conséquences directes et importantes sur l'activité.
  • équipe technique support, ne pas déranger les gens qui travaillent. Ils ont autre chose à faire que se disperser : résoudre l'incident !!!!
  • utilisateurs ou clients : pour calmer le jeu et maîtriser l'impationce et les inquiétudes. cela permet aussi de planifier l'activité locale

3. Mobilisation d’une équipe dédiée à la résolution

• Affectation de l’incident aux membres de l'équipe opérationnelle et gestionnaire de l'incident,
• vérification des compétences internes ou/et faire appel à des compétences externes

4. Résolution de l'incident

• déterminer la solution : temporaire/définitive ou contournement ? L'objectif est la reprise d'activité, même partielle, au plus tôt.
• escalade vers des niveaux de compétences, de technicité supérieurs ?
• déterminer une solution définitive après reprise d'activité.

5. Validation de la solution

• Suivi de l'efficacité de la solution
• Bilan post-correction ("post-mortem") à l'incident :
  • cause(s), récurrence,
  • qualité, réactivité de l'équipe de gestion et de résolution, de la communication
  • processus exploités, amélioration et fiabilité du processus de réponse

6. Clôture de l’incident

• Rapport : cause, impacts, solution, acteurs, délais et statistiques
• Enrichir la base de connaissances (FAQ)

Un petit mot sur l'escalade

• Attend, je m'équipe et j'y vais
• Noon, c'est l'escalade dans les compétences, pas dans la montagne ... (soupir)

Mieux vaut prévenir … Mais avec méthode en utilisant les bons outils. La réponse doit être adaptée en termes de résultats et de coûts

A suivre

Les principes ITIL, les normes ISO, les SLA :

• ITIL (Information Technology Infrastructure Library)
  • référentiel (livres « blancs »)
  • ensemble de processus de gestion de services technologiques
  • démarche pragmatique et bonnes pratiques
• gestion des services liés aux TI,
  • un ensemble des « meilleures pratiques » issues des expériences d’entreprises
• Client->Cycle de vie->maîtrise des ps
• Matériels, Fourniture de services, Supports de services

En TP

GLPI. Puis RAID ?

Références

https://openclassrooms.com/fr/courses/1730486-gerez-vos-incidents-avec-le-referentiel-itil-sur-glpi cours complet GLPI : 6 heures de travail

Crédit images : icons icons8.com, Samurais : Samurai Shamploo, IBM : Mathieux, KISS : fleximedtraining.co.uk, First case of bug : National Geographic, graphics : fk
The end (may be)