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 ».