Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici
  1. Livres et vidéos
  2. Le département informatique au service des organisations
  3. Fiches outils
Extrait - Le département informatique au service des organisations Stratégie, gouvernance et pilotage
Extraits du livre
Le département informatique au service des organisations Stratégie, gouvernance et pilotage Revenir à la page d'achat du livre

Fiches outils - Gérer opérationnellement les services

Le contenu d’un plan de maintenance

Un plan de maintenance est la combinaison d’un ensemble d’opérations qui doivent être effectuées sur une plateforme et des événements associés. Après chaque réalisation des opérations, l’approbation correspondante pour l’incident ou pour le changement devrait être traitée et des rapports nécessaires devraient être préparés, contenant des informations sur les opérations effectuées pendant la période de maintenance. Le rapport est défini comme la combinaison de tous les tests effectués pour une opération spécifique.

Le plan décrit le périmètre des vérifications et les résultats attendus pour ce périmètre, par exemple :

Périmètre

Résultats attendus

Logs serveurs web

Les journaux IIS doivent être générés en fonction des requêtes à travers chaque serveur réel implémenté à partir de l’équilibreur de charge réseau (NLB).

Disponibilité des serveurs

Les deux serveurs réels doivent être en ligne pour assurer une haute disponibilité et des performances optimales.

Équilibrage de la charge

Les requêtes doivent être équilibrées de manière égale par l’équilibreur de charge pour une meilleure performance.

Une fois les résultats définis, il s’agit de clarifier la fréquence de ces vérifications :

Vérification

Jour

Sem.

Mois

Trim.

Année

À la demande

Analyse des serveurs

Journaux Windows...

Le contenu d’un plan de support

Un plan de support est un document qui définit la manière dont une organisation ou une entreprise fournit du support à ses clients, utilisateurs ou partenaires. Ce plan doit décrire ce qui peut être attendu par les utilisateurs et les consommateurs de service et clarifier comment cela va fonctionner. De ce fait, on y retrouve les informations sur les outils utilisés, les points d’entrée, les temps de réponse mais aussi la catégorisation des tickets eux-mêmes.

Un plan de support pourra dès lors être conçu sous la forme suivante :

  • Objectif

  • Portée du support

  • Groupes de support

  • Support de niveau 0

  • Support de niveau 1

  • Support de niveau 2

  • Support de niveau 3

  • SLA et OLA

  • Introduction

  • Définitions

  • SLA (incidents, demandes de service, demandes de changement)

  • OLA Support de niveau 2 (incidents, demandes de service, demandes de changement)

  • OLA Support de niveau 3 (incidents, demandes de service, demandes de changement)

  • Définition de la priorité

  • Introduction

  • Gravité de l’impact

  • Urgence

  • Matrice de priorité

  • Horaires de support

  • Escalade fonctionnelle et hiérarchique

  • Base de connaissances

  • Outils de dépannage

  • Outil de gestion des tickets

  • Rôles et contacts

  • Support de niveau 1

  • Support de niveau 2

  • Support de niveau 3

  • Réunions d’état...

La procédure opérationnelle standard

La procédure opérationnelle standard a pour but de présenter comment une série d’actions doit être effectuée afin d’obtenir un résultat constant.

Identification

Procédure standard : <Titre de la procédure>

Propriétaire de la procédure

<Nom de la personne en charge de maintenir la procédure>

Dernière mise à jour et validité

<Date de mise à jour>, validé jusqu’au <date de validité>

Objectif

<Objectif de la procédure>

Actions

<Action 1>

<Action 2>

<Action 3>

Audience

<Groupe de personnes à qui est destinée la procédure>

Durée d’exécution attendue

<Durée estimée>

Cas d’usage

<Liste des situations dans lesquelles cette procédure est utile>

Prérequis

<Permissions nécessaires>, <Outils nécessaires> et <Prérequis>

Commentaires

<Texte libre>

Interruption de service

<Oui / Non> [si oui des détails]

Documents référencés

<Nom et Référence>

<Nom et Référence>

[Pour chacune des actions] <Titre de l’action>

Points d’attention

<Texte libre>

Paramètres d’entrée

Name

Description

Valeur

<Paramètre 1>

<Description 1>

[Valeur par défaut]

<Paramètre 2>...

La matrice des rôles et des permissions

La matrice des rôles et des permissions a pour but principal de définir et de gérer les droits d’accès des utilisateurs ou des groupes d’utilisateurs à diverses ressources ou fonctionnalités dans un système informatique, une application ou une plateforme en ligne. Elle peut se représenter de la manière suivante :

Rôle

Permission 1

Permission 2

Permission 3

Rôle A

X

X

X

Rôle B

 

X

 

Rôle C

 

 

X

Cette matrice sera très utile pour « Gérer les accès et les privilèges » mais aussi « La conformité règlementaire » présentée au chapitre «  Gérer les risques et la conformité » mais aussi « Accompagner les utilisateurs ».

La matrice des utilisateurs et des rôles

En complément de la matrice ci-dessus qui définit comment les privilèges sont octroyés, il s’agit désormais de clarifier qui peut jouer quel rôle. Une matrice simple permet alors d’y répondre :

Utilisateur ou groupe d’utilisateurs

Rôle A

Rôle B

Rôle C

Utilisateur 1

X

X

 

Utilisateur 2

 

X

 

Groupe I

X

 

 

Cette matrice est le complément de la matrice des rôles et des permissions. Notons qu’il est fréquent de voir omise la notion de rôle. Pourtant il s’agit de faire la différence entre les types de rôles et de comptes tels que présentés au chapitre « Gérer les accès et les privilèges ».