dossier d`initialisation de projet

Transcription

CONSOLIDATION DU SYSTEME
D’INFORMATION
Projet de fin d’étude : Consolidation du système d’information
Vincent BACHMAN – RARE2010.2
Région Méditerranée
Je tiens à remercier les principaux acteurs de ma formation.
Tout d’abord INGEROP qui m’a accueilli dans ses effectifs et m’a permis de m’épanouir tant
professionnellement que personnellement. Plus particulièrement Joël AFONSO, mon tuteur,
pour son accueil, sa joie de vivre et toutes les connaissances qu’il m’a et continue de
m’apporter.
Je remercie bien sur le CESI d’Aix-en-Provence pour la qualité de sa formation, Michel
RIGGENBACH qui la gère à merveille, ses formateurs et tout particulièrement Jean-Pierre
HAUGOMAT et Laurent HOSTEN pour la qualité de leur enseignement.
Je veux remercier également mes camarades de formation pour ces bons moments et les
échanges de connaissances.
Pour finir je remercie mon entourage pour leur soutient durant cette formation.
Sommaire
DOSSIER D’INITIALISATION DE PROJET ........................................................................................... 9
DOSSIER D’EXECUTION ..................................................................................................................... 35
RETOUR D’EXPERIENCE.................................................................................................................... 85
ANNEXES ............................................................................................................................................. 91
L’activité de la société INGEROP, spécialiste en ingénierie de BTP, est en croissance. Les
effectifs sont en croissance faible et constante. Le carnet de commande permet de penser
que cette tendance va s’accentuer.
Nos missions, principalement de maitrise d’œuvre nous poussent à une forte délocalisation
des effectifs sur les chantiers qui passent en phase de travaux.
Nous reviendrons plus en détails sur les activités et l’historique de la société à la fin de ce
document d’initialisation de projet.
Le projet doit mettre en œuvre un système permettant d’optimiser l’administration et la
réactivité d’intervention sur l’infrastructure réseau et serveur dans l’ensemble de nos
agences ainsi que les chantiers.
Le système devra permettre la supervision de nos équipements avec des mécaniques
d’alertes et de statistiques pour en évaluer la disponibilité et la capacité.
Nous suivrons les bonnes pratiques ITIL afin de développer le management du système
d’information.
Ce projet devra être réalisé sur une période de 6 mois, entre mars et aout 2012.
Agence Marseille
1 bd de l'Océan – Parc VALAD Bât. C1 – 13009
MARSEILLE
DOSSIER D’INITIALISATION DE PROJET
Nom – Visa
Rédaction
Rév.
Date
0
17/09/2012 Vincent BACHMAN
Nom – Visa
Vérification
Nom –Visa
Approbation
Joël AFONSO
A
B
C
SOMMAIRE
1
2
3
DEFINITION DU PROJET ............................................................................................................ 12
1.1
OBJECTIFS DU PROJET ET RESULTATS SOUHAITES .................................................................... 12
1.2
EXCLUSION ET PORTEE DU PROJET .......................................................................................... 13
1.3
CONTRAINTES ET HYPOTHESES ............................................................................................... 14
1.4
UTILISATEURS ET AUTRES PARTIES PRENANTES CONNUES ........................................................ 14
1.5
PROTAGONISTES .................................................................................................................... 14
STRUCTURE DE L’EQUIPE DE GESTION DE PROJET ........................................................... 15
2.1
ORGANIGRAMME .................................................................................................................... 15
2.2
DESCRIPTION DES ROLES ........................................................................................................ 15
APPROCHE DE PROJET ............................................................................................................ 16
3.1
4
5
ARCHITECTURE, SERVICES ET DEPENDANCES .......................................................................... 16
3.1.1
Marseille ........................................................................................................................... 17
3.1.2
Nice .................................................................................................................................. 18
3.1.3
Aix .................................................................................................................................... 19
3.1.4
Montpellier ....................................................................................................................... 20
3.1.5
Plateau A9 ....................................................................................................................... 21
3.2
BILAN DES SERVICES CRITIQUES .............................................................................................. 22
3.3
DESCRIPTION DE LA SOLUTION ................................................................................................ 22
3.3.1
Architecture et fonctionnalité de EON ............................................................................. 22
3.3.2
Les outils EON en correspondance avec les processus ITIL .......................................... 23
ANALYSE DE RENTABILISATION ............................................................................................. 24
4.1
COUT DE L’IMMOBILISME ......................................................................................................... 24
4.2
COUT DU PROJET ................................................................................................................... 24
4.3
BENEFICES ATTENDUS ............................................................................................................ 24
4.4
GAINS MESURABLES ............................................................................................................... 25
4.5
GRAPHIQUE DES RAPPORTS COUTS/GAINS ATTENDUS............................................................... 25
STRATEGIE DE GESTION DE LA CONFIGURATION ............................................................... 26
5.1
PRINCIPE DE CODIFICATION ..................................................................................................... 26
5.2
ARCHITECTURE DOCUMENTAIRE .............................................................................................. 26
5.3
STRATEGIE DE GESTION DE COMMUNICATION ........................................................................... 26
6
STRATEGIE DE GESTION DES RISQUES ................................................................................ 27
7
PLAN DE PROJET ....................................................................................................................... 28
8
CONTROLES DE PROJET .......................................................................................................... 29
9
LA SOCIETE INGEROP ............................................................................................................... 30
Page(s) 10/97
Dossier d’initialisation de projet
9.1
HISTORIQUE ........................................................................................................................... 30
9.2
ORGANISATION DE L’ENTREPRISE ............................................................................................ 30
9.3
LOCALISATION DES AGENCES ET DES FILIALES FRANÇAISES ET SUISSES .................................... 30
9.4
DIRECTION ............................................................................................................................. 31
9.5
CERTIFICATIONS ..................................................................................................................... 31
9.6
LES SECTEURS D’ACTIVITE ET LES METIERS D’INGEROP ............................................................ 31
9.7
ORGANISATION DE LA REGION MED ........................................................................................ 33
9.8
ORGANISATION DU SERVICE INFORMATIQUE ............................................................................ 34
Page(s)11/97
DEFINITION DU PROJET
1
1.1
Objectifs du projet et résultats souhaités
Nos objectifs principaux sont les suivants :
-
Superviser l’ensemble de notre système d’information
-
Réduire les temps d’intervention et les coûts associés
-
Optimiser le management du système d’information et des utilisateurs
Pour la réussite du projet et valider sa qualité nous définissons une liste de critères qualités
et résultats attendus :
-
Interface unifiée et claire permettant d’avoir une vision globale de notre système
d’information
-
Les informations de disponibilité des éléments du réseau et des services métiers
répertoriés et journalisés
-
Un accroissement de la disponibilité mesurée
-
Des rapports réguliers sur les équipements et services
-
Une hausse de la satisfaction des utilisateurs
-
Des graphes de capacité exploitables et pertinents
-
Des seuils de notification adaptés à l’exploitation actuelle
-
Une base (Configuration Management DataBase) regroupant matériels et logiciels avec
leur contrats associés
-
Des niveaux de services basés sur notre infrastructure
Nous pouvons schématiser notre démarche projet avec le triangle suivant :
- Superviser l’ensemble de notre système d’information
- Réduire les temps d’intervention et les coûts associés
- Optimiser le management du système d’information et des utilisateurs
Objectifs
- Méthode Prince2/ITIL
- Ressources financières
- Ressources humaines
- Ressources matérielles
- Compétences
- Prestataires
Moyens
Page(s) 12/97
Résultats
Efficience
- Interface permettant une vision globale du système
d’information
- Les informations de disponibilité des éléments du
réseau et des services métiers répertoriés et
journalisés
- Un accroissement de la disponibilité mesuré
- Des rapports réguliers sur les équipements et
services
- Une hausse de la satisfaction des utilisateurs
- Des graphes de capacité exploitables et pertinents
- Des seuils de notification adaptés à l’exploitation
actuelle
- Des niveaux de services basés sur notre
infrastructure
1.2
Exclusion et portée du projet
Le périmètre d’action se limite aux infrastructures de la région Méditerranée et les chantiers
sous sa responsabilité.
Ceci comprend les agences de Marseille, Nice, Montpellier et Aix. Egalement en
collaboration avec le système informatique du siège, le plateau chantier de l’A9 dans des
locaux d’ASF à Montpellier où sont basés 10 collaborateurs d’INGEROP.
Nous avons d’autres utilisateurs déportés sur chantier comme par exemple le Vieux Port
mais l’infrastructure est mise à disposition par l’entreprise de construction.
Nous sommes propriétaire de toute notre architecture à l’exception des routeurs, mis à
disposition pour notre fournisseur Orange. Leur administration est à la charge de ce dernier.
Portée du projet
Exclusion du projet
Sites :
Sites :
 Agences MED
 Autres régions
 Chantier A9
 Infrastructure centrale du siège
Composants en jeu :
Composants exclus :
 Eléments actifs du réseau
 Postes clients
 Serveurs et services associés
 Copieurs
 Autocom
 Téléphones
 Routeurs
Services :
 Supervision
 Notification
 Visualisation de logs
 Déploiement
d’outils
serveurs et les clients
sur
les
Méthodes :
 Niveaux de services
 Organisation
l’infrastructure
du
suivi
de
 Prévision des évolutions
Page(s)13/97
1.3
Contraintes et hypothèses
Ce projet se réalise en parallèle des opérations de maintenance et du support utilisateur. Le
service fourni aux utilisateurs ne doit pas être impacté par la réalisation du projet.
Nous fixons un délai de 6 mois pour obtenir des résultats exploitables durant l’étude de ce
projet, dans le cas contraire une réunion sera organisée pour étudier la suite du projet.
La planification doit prendre en compte les périodes de formation au CESI.
Nous partons de l’hypothèse qu’aucun moyen ne sera débloqué pour l’étude, nous
utiliserons des ressources existantes.
1.4
Utilisateurs et autres parties prenantes connues
Les utilisateurs du système seront les membres du Service Informatique de MED ainsi que
l’équipe infrastructure réseau du siège à Courbevoie.
Ce projet sera dépendant de la direction et de la direction financière régionale, ils seront en
charge de la définition des niveaux de services et du budget.
Les utilisateurs et les représentants du personnel seront également partie prenante du
projet.
1.5
Protagonistes
Vincent BACHMAN : Chef du projet et administrateur réseau
Joël AFONSO : Responsable informatique MED
Cyril BROUSSARD : Administrateur réseaux et système CBV
Nicolas MELAY : Administrateur réseaux et système CBV
Olivier POULET : Responsable de la région MED
André SARRAT : Responsable administratif et financier MED
Page(s) 14/97
2
2.1
STRUCTURE DE L’EQUIPE DE GESTION DE PROJET
Organigramme
L’équipe de projet se compose de la manière suivante :
Comité de pilotage
Olivier POULET
(Directeur régional)
André SARRAT
(RAF)
Joël AFONSO
(RIR)
Nicolas MELAY
(Admin réseau)
Support
Vincent BACHMAN
(Admin réseau)
Cyril BROUSSARD
(Admin réseau)
L’équipe du siège servira de support pour la réalisation du projet et de consultant pour le
comité de pilotage.
2.2
Description des rôles
Nom
Vincent BACHMAN
Joel AFONSO
André SARRAT
Olivier POULET
Nicolas MELAY
Cyril BROUSSARD
Fonction
Admin Réseau MED
RIR MED
RAF MED
DR MED
Admin Réseau CBV
Admin Réseau CBV
Rôle dans le projet
Chef de projet - maitre d'oeuvre
Valideur technique - interface avec la direction
Valideur financier - valideur des niveaux de services
Valideur des niveaux de services
Support technique
Support technique
Page(s)15/97
3
3.1
APPROCHE DE PROJET
Architecture, services et dépendances
Le but de cette partie est de permettre une cartographie et un inventaire de nos équipements
et services afin d’identifier les services métier critiques en production dans nos agences.
Pour ce faire, nous identifions les services d’exploitation et leurs dépendances internes et
externes (équipements du siège, prestation,…) dans un tableau. Nous différencions les
services métier et administratifs qui peuvent être invisibles pour l’utilisateur et définissons
une priorité.
Chaque agence possède des services spécifiques ainsi cette étude se fait sur chacun des
sites.
De plus nous identifions les types de matériels de notre architecture, nous vérifierons que la
solution choisie soit compatible.
La proportion d’utilisateurs itinérants nous impose la mise en réseau des services métier
comme les licences.
Site
Marseille
Nice
Montpellier
Aix
Plateua A9
Total
Utilisateurs
70
35
25
30
10
Page(s) 16/97
Itinérants
30
15
15
10
6
3.1.1
Marseille
Architecture réseau
MRS
Symbole
Total
Services métier
Services d'administration
MRS02002
2
Poste client
3
Switch HP Procurve
1
MRS02001
1
LAN
1
XPS-XEROX
1
SRV-WINKHAUS
2
Routeur Livebox fibre
1
WAN
1
MRS-P1181
1
SRV-NOD32
1
Riverbed Steelhead
1
MRS02003
Services
Affaires
Administratif
Lotus
Autocad
Licence metier Mensura
Covadis
Navigation internet
Copieur
Impression
Traceur
Gestion financière
Fichiers
AD
Services centraux DNS
DHCP
WDS
WSUS
NOD32
WINKHAUS
XDA Xerox
VISIO
LAN
Description
1
MPLS
MPLS
Primaire
Primaire
Dépendances de service
Services centraux, LAN
LAN
Composants internes en jeu
ML350 G6, HP Procurve, Server 2003 R2
ML350 G5, HP Procurve, Server 2003
ML350 G5, HP Procurve, Server 2003, Domino Svc
ML350 G6, HP Procurve, FlexLM, Server 2003 R2
ML350 G4, HP Procurve, Itheasvc, Server 2003
ML350 G6, HP Procurve, SentinelLM, Server 2003 R2
HP Procurve
ML350 G4, HP Procurve, Spooleur, copieur Xerox, Server 2003
ML350 G4, HP Procurve, Spooleur, traceur Océ, Server 2003
LAN
LAN, AD
LAN, AD, DNS
LAN
ML350 G6, HP Procurve, Server 2003 R2, Ntfrs, Kcc, RPC
ML350 G6, HP Procurve, Server 2003 R2, AD, RPC
ML350 G6, HP Procurve, Server 2003 R2, RPC
ML350 G6, HP Procurve, Server 2003 R2, DHCP, WDS Svc
ML350 G4, HP Procurve, Server 2003, IIS, WSUS Svc, Microsoft SEEE
HP Elite 8200, HP Procurve, VMWare Workstation
HP Procurve, Polycom 7000A
HP Procurve
Secondaire
Secondaire
Composants externes en jeu
Redondance
non
non
Routeur FAI, Pivot Lotus, Firewall
non
oui, autres agences
non
non
Routeur FAI, Pivot Lotus, Firewall, Proxy oui sur site
Support Xerox
non
Support Océ
non
non
Support WINKHAUS
Support BI Networks
Routeur FAI, Firewall
ML350 G6 : MRS02003
ML350 G5 : MRS02001
ML350 G4 : MRS02002
HP Procurve : Procurve 4104 GL, Procurve 4208 VL et Procurve 2810
HP Elite 8200 : MRS-P1181
Criticité
5
5
5
5
5
4
3
3
4
4
oui sur site
oui sur site
non
non
non
non
non
non
non
non
5
5
5
1
2
3
4
1
3
5
Non indispensable
Priorité faible
Priorité moyenne
Priorité forte
Indispensable
1
2
3
4
5
Page(s)17/97
3.1.2
Nice
MPLS
MPLS
Primaire
Primaire
Secondaire
Secondaire
NCE
Symbole
Total
Description
2
Poste client
2
Switch HP Procurve
1
NCE02001
1
LAN
1
XPS-XEROX-NCE
2
Routeur
1
WAN
1
NCE-P1075
1
SRV-NOD32-NCE
1
Riverbed Steelhead
1
NCE02003
Services
Affaires
Administratif
Lotus
Autocad
Licence metier Adfer
Mensura
Navigation internet
Copieur
Impression
Traceur
Services métier
Fichiers
AD
DHCP
WDS
WSUS
NOD32
XDA Xerox
VISIO
LAN
LAN
ML350 G6, HP Procurve, Server 2003 R2, Domino Svc
ML350 G6, HP Procurve, Service de licence Adfer, Server 2003 R2
HP Procurve
LAN
LAN, AD
LAN, AD, DNS
LAN
ML350 G6, ML350 G4, HP Procurve, Server 2003 R2, Ntfrs, Kcc, RPC
ML350 G6, ML350 G4, HP Procurve, Server 2003 R2, AD, RPC
ML350 G4, HP Procurve, Server 2003, DHCP, WDS Svc
Support BI Networks
HP Procurve
oui sur site
oui sur site
non
non
non
non
non
non
non
5
5
5
1
2
3
1
3
5
ML350 G6 : NCE02001
ML350 G4 : NCE02003
HP Procurve : Procurve 4204 VL et Procurve 4208 VL
HP Elite 8200 : NCE-P1075
Non indispensable
Priorité faible
Priorité moyenne
Priorité forte
Indispensable
1
2
3
4
5
Page(s) 18/97
Redondance
non
non
Routeur FAI, Pivot Lotus, Firewall non
oui, autres agences
non
non
Routeur FAI, Firewall, Proxy
oui sur site
Support Xerox
non
Support Océ
non
Criticité
5
5
5
5
4
5
3
3
4
3.1.3
Aix
MPLS
MPLS
Primaire
Primaire
AIX
Symbole
Services métier
Description
2
Poste client
1
Switch HP Procurve
1
AIX02004
1
LAN
1
XPS-XEROX-AIX
2
Routeur
1
WAN
1
AIX-P0068
1
SRV-NOD32-AIX
1
Riverbed Steelhead
1
AIX02005
Services
Affaires
Administratif
Lotus
Mapinfo
Licence métier
MIKE
Navigation internet
Copieur
Impression
Traceur
Fichiers
Total
AD
DHCP
WDS
WSUS
NOD32
XDA Xerox
VISIO
LAN
Secondaire
Secondaire
LAN
ML350 G6, HP Procurve, Server 2003 R2, Domino Svc
HP Procurve
LAN
LAN, AD
LAN, AD, DNS
LAN
ML350 G6, HP Procurve, Server 2003 R2, Ntfrs, Kcc, RPC
ML350 G6, HP Procurve, Server 2003 R2, AD, RPC
ML350 G4, HP Procurve, Server 2003 R2, DHCP, WDS Svc
HP Procurve, Polycom 7000HD
HP Procurve
ML350 G6 : AIX02004
ML350 G4 : AIX02005
HP Procurve : Procurve 2650
HP Elite 8200 : AIX-P0068
Redondance
non
non
non
non
non
Routeur FAI, Pivot Lotus, Firewall, Proxy oui sur site
Support Xerox
non
Support Océ
non
Support BI Networks
Criticité
5
5
5
4
5
3
3
4
oui sur site
oui sur site
non
non
non
non
non
non
non
5
5
5
1
2
3
1
3
5
Non indispensable
Priorité faible
Priorité moyenne
Priorité forte
Indispensable
1
2
3
4
5
Page(s)19/97
3.1.4
Montpellier
MPLS
MPLS
Primaire
Primaire
Secondaire
Secondaire
MPL
Symbole
Services métier
Description
2
Poste client
2
Switch HP Procurve
1
MPL02001
1
LAN
1
XPS-XEROX-MPL
2
Routeur Livebox Fibre
1
WAN
1
MPL-P1064
1
SRV-NOD32-MPL
1
Riverbed Steelhead
1
MPL02002
Services
Affaires
Administratif
Lotus
Autocad
Licence metier
Mensura
Navigation internet
Copieur
Impression
Traceur
Fichiers
Total
AD
DHCP
WDS
WSUS
NOD32
XDA Xerox
VISIO
LAN
LAN
ML350 G5, HP Procurve, Server 2003, Domino Svc
ML350 G5, HP Procurve, FlexLM, Server 2003
HP Procurve
LAN
LAN, AD
LAN, AD, DNS
LAN
ML350 G5, DL110 G2, HP Procurve, Server 2003, Ntfrs, Kcc, RPC
ML350 G5, DL110 G2, HP Procurve, Server 2003, AD, RPC
ML350 G5, HP Procurve, Server 2003, RPC
DL110 G2, HP Procurve, Server 2003, DHCP, WDS Svc
DL110 G2, HP Procurve, Server 2003, IIS, WSUS Svc, Microsoft SEEE
Support BI Networks
HP Procurve
oui sur site
oui sur site
non
non
non
non
non
non
non
5
5
5
1
2
3
1
3
5
ML350 G5 : MPL02001
DL110 G2 : MPL02002
HP Procurve : Procurve 4204 VL et HP1800 24G
HP Elite 8200 : MPL-P1064
Non indispensable
Priorité faible
Priorité moyenne
Priorité forte
Indispensable
1
2
3
4
5
Page(s) 20/97
Redondance
non
non
Routeur FAI, Pivot Lotus, Firewall non
oui, autres agences
non
oui sur site
Support Xerox
non
Support Océ
non
Priorité
5
5
5
5
5
3
3
4
3.1.5
Plateau A9
A9
Internet
Internet
Symbole
Total
Description
2
Poste client
1
Switch HP Procurve
1
LAN
2
Routeur
Routeur
Routeur FAI
FAI
1
WAN
1
MRS-P1107
1
SRV-A9
Fortigate
Fortigate 50B
50B (VPN)
(VPN)
Services
Affaires
Administratif
Lotus
Autocad
Licence metier
Mensura
Navigation internet
Copieur
Impression
Traceur
Services d'admin
Services métier
Fichiers
AD
DHCP
WSUS
NOD32
LAN
LAN
XW4400, VMWare Workstation, Server 2008 R2, HP Procurve
HP Procurve, Frotigate 50B
HP Procurve, Frotigate 50B
LAN
LAN, AD
LAN, AD, DNS
HP Procurve, Fortigate 50B
XW4400, VMWare Workstation, Server 2008 R2, AD, RPC, HP Procurve, Fortigate 50B
XW4400, VMWare Workstation, Server 2008 R2, RPC, HP Provurve
HP Procurve
XW4400, VMWare Workstation, Server 2008 R2, HP Procurve, Spooleur, copieur Xerox, Server 2003
XW4400, VMWare Workstation, Server 2008 R2, HP Procurve, Spooleur, traceur Océ, Server 2003
XW4400 : MRS-P1107
HP Procurve : Procurve 2524
Redondance
Priorité
non
5
Routeur FAI, Partage administratifs du site de MPL
non
5
Serveur Lotus du site de MPL, Routeur FAI, Pivot Lotus, Firewall non
5
Routeur FAI, Licence du site de MPL
oui, autres agences
5
Routeur FAI, Licence du site de MPL
non
5
non
3
Support Xerox
non
3
Support Océ
non
4
AD du site de MPL
DNS du site de MPL
Routeur FAI, WSUS du site de MPL
Routeur FAI, NOD32 du site de MPL
oui
non
non
non
non
non
5
5
5
2
3
5
Non indispensable
Priorité faible
Priorité moyenne
Priorité forte
Indispensable
1
2
3
4
5
Page(s)21/97
3.2
Bilan des services critiques
Avec cette approche, nous pouvons identifier les services et leurs composants en jeu, ceci
servira de base sur les services à superviser. Nous allons prioriser les services métier
critiques (priorité = 5), ces composants seront supervisés en priorité.
Services
Affaires
Fichiers
Administratif
Lotus
Autocad
Licence metier Mensura
MIKE
AD
DHCP
LAN
LAN
LAN, AD
LAN, AD, DNS
Serveurs, HP Procurve
Serveurs, HP Procurve
Serveurs, HP Procurve, Domino Svc
Serveurs, HP Procurve, FlexLM
Serveurs, HP Procurve, Itheasvc
Serveurs, HP Procurve, FlexLM
Serveurs, HP Procurve, Ntfrs, Kcc, RPC
Serveurs, HP Procurve, AD, RPC
Serveurs, HP Procurve, RPC
HP Procurve
Redondance
non
non
non
oui, autres agences
non
non
oui sur site
oui sur site
non
non
Nous superviserons donc en priorité l’état de santé des serveurs hébergeant les services
critiques et des éléments actifs afin d’obtenir une disponibilité maximale. De plus certains
services systèmes peuvent être mis en évidence afin d’affiner la supervision.
3.3
Description de la solution
Eyes Of Network, la solution utilisée, est une suite logicielle développée par APX qui
comprend de nombreux outils destinés à la supervision.
3.3.1
Architecture et fonctionnalité de EON
L’architecture de la solution repose sur CENTOS 6.2 avec les démons LAMP pour héberger
les interfaces et les bases des applications et POSTFIX pour la distribution des mails.
La couche logicielle NAGIOS permet la gestion de la disponibilité, le module NAGVIS peut
être utilisé à des fin de cartographie.
La couche CACTI, elle est utile pour la gestion de la capacité notamment avec son module
RRDTOOLS qui permet la génération de graphes.
La particularité d’EON est son interface EONWEB qui permet une gestion unifiée des
couches logicielles et intègre une solution de sauvegarde.
Toutes les remontées se font vers un gestionnaire d’évènement qui les rend accessible via
l’interface EONWEB, il gère également les notifications.
De manière plus indépendante mais liés à la base de donnée du serveur les outils GLPI et
OCS sont compris dans la solution.
Page(s) 22/97
LILAC
GLPI
EONWEB
BACKUP MANAGER
OCSNG
RRDTOOL
CACTI
WEATHERMAP
Generic Event
Dispatcher
NAGVIS
OCS
NAGIOS
THRUK
LAMP
CENTOS
POSTFIX
3.3.2
Les outils EON en correspondance avec les processus ITIL
Nous désirons nous inscrire dans une démarche ITIL, chaque composant peut s’inscrire
dans le processus de vie de produit.
Cette solution s’inscrit essentiellement dans la démarche opérationnelle avec la surveillance
de la production.
Les statistiques et les évènements peuvent permettre la conception d’un nouveau projet ou
de l’amélioration de l’architecture existante donnant des signes de défaillances.
Gestion des graphes de performance
OCS-GLPI
Nagios
Nagvis
Inventaire et gestion de parc
Gestion des remontées d’évènements
CACTI
Rsyslog
Gestion des incidents et problèmes
Cartographie de la disponibilité
BACKUP MANAGER
Sauvegarde de la solution
Page(s)23/97
ANALYSE DE RENTABILISATION
4
4.1
Coût de l’immobilisme
L’immobilisme conserverait les temps de rétablissement actuel dépendant principalement du
temps de détection par un utilisateur puis de la disponibilité de l’équipe du service
informatique.
De plus les vérifications préventives doivent se faire sur chaque équipement rendant la tâche
plus longue.
4.2
Coût du projet
La suite logicielle choisie est sous licence GPL2 donc libre d’utilisation.
Le matériel utilisé est du matériel déjà amorti, la machine utilisée a plus de 3 ans de vie.
Nous ne tiendrons donc pas compte du coup matériel en cout initial. Nous prévoyons un
changement matériel du poste hébergeant le système d’ici 3 ans. Cout estimé à 500€.
Seule la main d’œuvre nécessaire à la réalisation du projet peut être comptabilisée dans le
cout réel, de plus nous prévoyons 1 journée par semestre de maintenance du serveur tel que
l’application de correctifs de la suite logicielle.
Cette main d’œuvre est calculée sur une estimation du coût réel du salarié.
Tache Taux horaire(€) Charge de travail durée (j) année 1 année 2 année 3 année 4 année 5
Réalisation du projet
30
50%
50 10500 10500
10500
10500 10500
Maintenance
30
100%
2
420
420
420
420
Matériel
500
TOTAL
10500 10920
11840
12260 12680
4.3
Bénéfices attendus
Nous pouvons prévoir des gains non mesurables à la mise en place de ce système :
-
Eviter pénalités de retard de remise de dossier en restaurant rapidement un service
-
Optimiser le temps de travail du SI avec la prévision de défaillances
-
Satisfaction client sur le temps de rétablissement (enquêtes satisfaction)
Page(s) 24/97
4.4
Gains mesurables
Nous ne pouvons pas mesurer les bénéfices éventuels sur les projets métiers en cours.
Nous estimons grâce à ce système pouvoir éviter 3 coupures d’une heure par agence et par
an. Nous estimons à 30% la perte de productivité des salariés pour une coupure de courte
durée.
Marseille
Aix
Nice
Montpellier
Total
4.5
Masse salariale 2010 jours ouvrés MS/jour MS/h
pertes/h (30%) gains (3 fois 1h/an)
2 382 029,00
220,00 10 827,40 1 445,58
433,67
1 301,02
863 901,00
220,00 3 926,82 524,28
157,28
471,85
1 426 040,00
220,00 6 482,00 865,42
259,63
778,88
902 817,00
220,00 4 103,71 547,89
164,37
493,10
5 574 787,00
25 339,94 3 383,17
1 014,95
3 044,85
Graphique des rapports coûts/gains attendus
A partir des données précédentes nous pouvons dégager un graphique des couts et des
gains :
€18 000
€16 000
€14 000
€12 000
€10 000
Coûts du projet
€8 000
Gains du projet
€6 000
€4 000
€2 000
€0
1
2
3
4
5
En comptant le cout réel de la main d’œuvre le projet permet un retour sur investissement
sur 4 ans et même dégager du profit sur la 5eme année.
Cette main d’œuvre peut ne pas être comptabilisée car ce projet est réalisé sur le temps de
travail sans pour autant réduire le service proposé.
Page(s)25/97
5
5.1
STRATEGIE DE GESTION DE LA CONFIGURATION
Principe de codification
Chaque tâche d’exécution ou procédure suivra une codification :
Taches : TXYY
X = Numéro de phase
Procédures : PYY
YY = Code unique
5.2
Architecture documentaire
Utilisation d’une arborescence dédiée et hébergée sur le serveur administratif :
R:\8-SI\2012\10-Divers\2012\11-Consolidation_SI\
11-Consolidation_SI\
Projet (pièces écrites)
Doc étude (tableaux, schémas,…)
Procédures
Doc de ref (charte, lettre de mission,..)
Les documents d’études sont des documents centralisés par type dans un fichier, par
exemple un seul fichier Excel sera utilisé pour l’intégralité des tableaux du projet.
L’accès est restreint aux membres du SI.
Pour des raisons de disponibilité des informations en formation, une copie est hébergée sur
FTP : http://bachman.vincent.free.fr
5.3
Stratégie de gestion de communication
La communication entre protagonistes se fera essentiellement par mail ou via des réunions
de travail.
Chaque contact est accessible via l’annuaire général de notre intranet.
Page(s) 26/97
6
STRATEGIE DE GESTION DES RISQUES
Catégorie
id
Description
Gravite
Probabilité
d'apparition
Détectabilité
Niveau total
Nous identifions et priorisons les principaux risques projets :
ORG
1
Prise de retard sur le planning
4
2
1
8
ORG
2
Perte de document de gestion de projet
3
1
2
6
HUM
3
Des absences lors des réunions d'avancement
3
2
3
18
HUM
4
Désaccord entre les acteurs du projet
2
4
2
16
TEC
5
Anomalies détectées lors des contrôles de séquences
4
3
3
36
TEC
6
Matériel non conforme
3
3
2
18
ORG
7
Changement imprévu du planning
4
2
1
8
TEC
8
Coupure de courant électrique
3
1
4
12
prévoir une autre source de secours
HUM
ENV
9
10
Malveillance
Catastrophe majeure (naturelle, incendie,…)
4
4
1
1
3
4
12
16
TEC
11
Evolution des normes ou technologies
2
2
2
8
FIN
TEC
ORG
ORG
TEC
12
13
14
15
16
Changement budgétaire
Manque de compétence
Augmentation de la charge de travail
Absentéisme
Compatibilité entre éléments
4
3
3
4
4
2
3
4
3
2
3
2
3
3
3
24
18
36
36
24
Sécuriser le matériel et les accès à la maquette
Externaliser les données sensibles
Veille technologique, prévoir des technologies de
dernière génération
Avoir des garanties avec le comité de pilotage
Etablir un tableau de compétence
Prévoir un plan de charge
Demander un planning des absences de tous les protagonistes
Etude de la conformité, controles de séquences intermédiaires
ORG
FIN
HUM
TEC
ENV
Gravité
Probabilité
Détectabilité
Prévention
Prévoir un planning prévisionnel assez large
Les documents sont centralisés sur un serveur de fichiers à partir
duquel des sauvegardes sont réalisés.
Les réunions seront prévues assez longtemps à
l'avance pour que chacun puissent s'organiser
Informer les acteurs que le choix final est fait
par le comité de pilotage
L'étude doit prendre en compte l'intégralité des paramètres.
Les réunions d'avancement au cours de la mise en oeuvre doivent
permettre de détecter au plus vite une anomalie.
faire un suivi du planning
Correctif
Demander un délai supplémentaire ou augmenter les ressources
Le document sera reprit depuis sa création
Les absents seront informés des décisions par un
compte rendu de réunion
Se référer à la lettre de mission
Définir un plan d'action pour retrouver la trajectoire cible.
Le prestataire sera contacté pour un remplacement
conformément au cahier des charges
changement de planning avec l'accord de directeur projet
Voir avec le responsable projet et/ou responsable technique des
locaux
augmenter la sécurité des accès
Décision sur la suite du projet avec le comité de pilotage
Modification de la solution apportée
Demander de l'aide au support de CBV
Modifier la planification du projet
Transférer la tache à une autre ressource
Risque organisationnel
Risque financier
Risque humain
Risque technique
Risque environnemental
1 à 4 faible à forte gravité
1 à 4 faible à forte probabilité
1 à 4 forte à faible détectabilité
Page(s)27/97
7
PLAN DE PROJET
Découpage du projet en 4 séquences :
-
Techniques de supervision
-
Outils de déploiement
-
Inventaire des équipements
-
Définition des niveaux de services
Management
consolidé
Utilisateurs
Niveaux de
service
respectés
Composants
inventoriés
Télédéploiement
fonctionnel
Système
supervisé
Nous estimons que le chargé de la mise en œuvre pourra allouer 50% de sa charge de
travail sur le projet, cette charge peut varier selon les incidents en cours ou les requêtes
utilisateurs.
Nous prévoyons le planning suivant :
Page(s) 28/97
8
CONTROLES DE PROJET
Nous identifions les principales étapes de validation du projet, ces validations se feront grâce
aux différents critères qualités :
-
Intégration des équipements
-
Remontée d’informations
-
Notification fonctionnelle
-
Graphes lisibles
-
Sauvegarde fonctionnelle
-
Test de télédéploiement concluant
-
Niveaux de services cohérents
Page(s)29/97
9
9.1
LA SOCIETE INGEROP
Historique
Ingérop Conseil et Ingénierie est né en 1992 par le regroupement de deux sociétés
d’ingénierie technique complémentaires : INTER G et SEEE.
Créée en 1945 et reprise en 1984 par le groupe GTM (Grands Travaux de Marseille),
l’entreprise INTERG était spécialisée dans le domaine des centrales thermoélectriques, des
hôtels, des hôpitaux, et des tramways. La société SEEE (Société d’Étude et Entreprise
d’Équipement), fondée en 1962 par GTM pour être son département d’études techniques en
ouvrages d’art et structures complexes, s’est développée dans les domaines de la maîtrise
d’œuvre de grandes infrastructures linéaires, du bâtiment et de l’installation industrielle.
Fin 2000, alors que son actionnaire GTM est absorbé par Vinci, les cadres dirigeants
d’Ingérop prennent l’initiative de racheter leur société. Cinq ans plus tard, Ingérop devient
une entreprise complètement indépendante.
9.2
Organisation de l’entreprise
En France et en Suisse, 26 agences et filiales d’Ingérop sont implantées et réparties dans
huit régions.
D’autre filiales et établissements sont implantés dans le reste du monde comme en Afrique
du Sud, à l’île Maurice, en Algérie, en Espagne…
9.3
Localisation des agences et des filiales françaises et suisses
Localisation des agences et des filiales à l’étranger
Page(s) 30/97
Lors de son rachat fin 2000, Ingérop rassemblait 1100 collaborateurs. Aujourd’hui, la société
compte 1583 cadres et salariés, en France et dans le monde.
9.4
Direction
L’entreprise, aujourd’hui entièrement détenue par ses cadres (91,5 % des actions) et
employés (8,5 % des actions), est organisée en Société par Actions Simplifiées à Conseil de
Surveillance Directoire. Elle est gérée par un Directoire, présidée par M. Yves METZ, qui,
avec l’aide des cinq directeurs de métiers, prend les décisions avec l’aval du Conseil de
Surveillance présidé par M. Jean-Claude Nougué-Cazenave.
9.5
Certifications
La certification selon la norme internationale ISO 9001 (International Standards
Organization), délivrée par l’Association Française d'Assurance Qualité (A.F.A.Q.), témoigne
de la performance des méthodes du système de management utilisé et de l'efficacité des
processus.
Ingérop est certifié ISO 9001 depuis le 15/02/05 pour ses activités de conception et
réalisation de missions d'ingénierie dans les domaines de l'aménagement, des
infrastructures, du bâtiment et des services à l'industrie.
Nous sommes également certifiés ISO 14001 gage du souci de l’impact environnemental de
son activité et son organisation.
Un projet en cours a pour but d’obtenir la certification de la norme internationale ISO 27001
qui spécifie un système de gestion de la sécurité des systèmes d’information (SGSSI).
9.6
Les secteurs d’activité et les métiers d’Ingérop
Les métiers d’Ingérop s’articulent autour de cinq pôles pesant différemment dans l’activité du
groupe. Les métiers d’ «Infrastructures » et de « Bâtiment et Équipement » sont les deux
principaux pôles avec respectivement 32 % et 30 % de l’activité, contre 15 % pour
«l’Industrie », 13 % pour les « Transports en commun » et 10 % pour l’« Eau et
Page(s)31/97
Environnement », pôle dans lequel se situe Ipseau (agence Aix) racheté il y a maintenant 6
ans.
Ingérop est une entreprise de maîtrise d’œuvre assurant les différentes missions prévues par
la loi du 12/07/85 relative à la maîtrise d’ouvrage publique et à ses rapports avec la maîtrise
d’œuvre privée, dite loi « MOP », et également des missions d’études plus générales.
Les réalisations peuvent aller de la réhabilitation d’habitation à la conception de tunnel ou de
building. Voici quelques exemples de chantiers sur Marseille :
-
Tunnel Prado Carénage
-
Trauma Center (Extension de l’hôpital Nord)
-
Parking République
-
Terrasses du Port (Futur grand centre commercial sur le port)
-
MUCEM
-
Piétonisation du Vieux port
Page(s) 32/97
9.7
Organisation de la région MED
Page(s)33/97
9.8
Organisation du Service Informatique
Le service informatique de la région MED se compose de deux personnes que sont Joël
AFONSO et moi-même. Chaque agence possède un Responsable Informatique Local qui a
pour but de faire les relais entre les utilisateurs et le SI. Il s’occupe également du
changement quotidien des bandes de sauvegarde.
Nous dépendons du service informatique de notre siège de Courbevoie qui s’occupe
essentiellement de notre WAN, de l’administration de Lotus et les ERP.
Page(s) 34/97
Agence Marseille
1 bd de l'Océan – Parc GVIO Bât. C1 – 13009
MARSEILLE
DOSSIER D’EXECUTION
Nom – Visa
Rédaction
Rév.
Date
0
23/10/2012 Vincent BACHMAN
Nom – Visa
Vérification
Nom –Visa
Approbation
Joël AFONSO
A
B
C
Page(s)35/97
Dossier d’exécution
Sommaire
1
METHODOLOGIE ..................................................................................................................... 38
2
SEQUENCE « SUPERVISION » ............................................................................................... 39
2.1
2.1.1
Description du plan ....................................................................................................... 39
2.1.2
Préalables ..................................................................................................................... 39
2.1.3
Dépendances externes ................................................................................................. 39
2.1.4
Contrôles et surveillance .............................................................................................. 39
2.1.5
Budget et délai .............................................................................................................. 40
2.1.6
Tolérances .................................................................................................................... 40
2.1.7
Descriptif du produit ...................................................................................................... 41
2.1.8
Planification .................................................................................................................. 45
2.2
3
DOCUMENTATION TECHNIQUE .............................................................................................. 46
2.2.1
Configuration SNMP ..................................................................................................... 46
2.2.2
Création d’une commande en NRPE ........................................................................... 47
2.2.3
Configuration de NSClient++ ........................................................................................ 49
2.2.4
Création d’un modèle Nagios ....................................................................................... 51
2.2.5
Visualisation des services ............................................................................................ 54
2.2.6
Etude de la capacité ..................................................................................................... 56
2.2.7
Configuration SYSLOG ................................................................................................ 58
SEQUENCE « DEPLOIEMENT » ............................................................................................. 60
3.1
PLAN DE SEQUENCE ............................................................................................................ 60
3.1.1
3.1.2
Préalables ..................................................................................................................... 60
3.1.3
3.1.4
Hypothèses de planification .......................................................................................... 60
3.1.5
3.1.6
Budget et délai .............................................................................................................. 61
3.1.7
Tolérances .................................................................................................................... 61
3.1.8
3.1.9
Planification .................................................................................................................. 63
3.2
4
PLAN DE SEQUENCE ............................................................................................................ 39
DOCUMENTATION TECHNIQUE « DEPLOIEMENT »................................................................... 64
3.2.1
Déployer l’agent OCS ................................................................................................... 64
3.2.2
Déployer un paquet par OCS ....................................................................................... 65
SEQUENCE « INVENTAIRE ».................................................................................................. 68
4.1
PLAN DE SEQUENCE ............................................................................................................ 68
Page(s) 36/97
4.1.1
4.1.2
Préalables ..................................................................................................................... 68
4.1.3
4.1.4
4.1.5
4.1.6
Budget et délai .............................................................................................................. 69
4.1.7
Tolérances .................................................................................................................... 69
4.1.8
4.1.9
Planification .................................................................................................................. 71
4.2
5
DOCUMENTATION TECHNIQUE « INVENTAIRE » ...................................................................... 72
4.2.1
Principe ......................................................................................................................... 72
4.2.2
Application .................................................................................................................... 72
SEQUENCE « NIVEAUX DE SERVICES » .............................................................................. 76
5.1
PLAN DE SEQUENCE ............................................................................................................ 76
5.1.1
5.1.2
Préalables ..................................................................................................................... 76
5.1.3
5.1.4
5.1.5
5.1.6
Budget et délai .............................................................................................................. 77
5.1.7
Tolérances .................................................................................................................... 77
5.1.8
5.1.9
Planification .................................................................................................................. 79
5.2
SERVICE LEVEL AGREEMENT ............................................................................................... 80
5.2.1
Calcul ............................................................................................................................ 80
5.2.2
Tableau ......................................................................................................................... 81
6
DECOMPOSITION DE FLUX DE PRODUITS GENERALE ..................................................... 82
7
RACI .......................................................................................................................................... 83
8
PLANIFICATION GENERALE .................................................................................................. 84
Page(s)37/97
Méthodologie
METHODOLOGIE
1
Pour réaliser ce projet nous allons définir des plans de séquences à chaque produit
principal.
Ces plans de séquence comprennent les informations nécessaires à la mise en œuvre du
projet :
-
Préalables
-
Dépendances
-
Contrôles
-
Budget
-
Composants
-
Planification
Nous décrivons le produit principal en plusieurs composants qui sont des tâches
nécessaires à la réalisation du produit.
Des critères qualités sont identifiés sur les composants qui permettent la validation de ces
derniers. Ces critères sont des normes à respecter, des consignes à respecter ou des
marqueurs de mesure. De plus ils contiennent un délai de réalisation de la tâche donnée.
Le composant est attribué à une ou un groupe de ressources ce qui permet de commencer
à établir le RACI.
Les composants sont séquencés en un schéma de flux de produit.
Ce séquençage associé au RACI nous permet de dégager un planning d’exécution et
dégager le cout de main d’œuvre.
Moyens et spécifications projet
Liste des
composants avec
leur critères
qualités
Séquençage des composants
Planification de
la séquence
Mise à jour du RACI
Page(s) 38/97
Séquence « Supervision »
SEQUENCE « SUPERVISION »
2
2.1
2.1.1
Plan de séquence
Description du plan
Notification
2.1.2
Préalables
La suite logicielle Eyes of Network doit être utilisée pour la mise en œuvre des composants
de la séquence.
Du matériel doit être disponible pour installer le serveur.
2.1.3
Dépendances externes
Cette séquence ne dépend d’aucun autre projet.
2.1.4
Contrôles et surveillance
Chaque tâche est contrôlée et validée par Joël AFONSO.
La validation de la séquence se fera par la même personne.
La validation des contrôles suivant permettra la validation de la séquence :
-
Serveur sécurisé
-
Disponibilité supervisée
-
Logs supervisés
-
Notification opérationnelle et ciblée
-
Sauvegarde configurée et fonctionnelle
Page(s)39/97
2.1.5
Budget et délai
Nous estimons à 7 800€ le cout de la main d’ouvre dédiée à la réalisation du produit.
Le délai de mise en œuvre est estimé à 48 jours.
2.1.6
Tolérances
Nous estimons que la supervision de la capacité n’est pas essentielle et peut ne pas être
opérationnelle ou avoir une mise en œuvre retardée.
La sécurisation du serveur peut avoir des écarts, le serveur restera en interne, réseau déjà
de confiance grâce au filtrage fait en amont par le siège.
Nous pouvons prévoir un retard raisonnable de 24 jours sur cette séquence.
Page(s) 40/97
Réseau, DVD installation, PC
EONWeb, Apache
Base Parc, Outil Nagios
SNMPd, EONWeb, Cacti
Nagios
Nagios
Installer les composants
nécessaires
Limiter les accès au serveur
Avoir la liste des équipements
à superviser
Définir une communauté
unique pour la région
Permettre aux équipements
l'envoi de traps SNMP
Définir les services à
superviser
Définir des horaires de check
pertinents
T102 Serveur installé
T103 Serveur sécurisé
T104 Equipements inventoriés
T105 Communauté SNMP définie
T106 Service SNMP configuré
T107 Services identifiés
T108 Plages horaires définies
Application de la conf
Templates de services et
d'hotes
Application de la conf et
fiche procédurale
fiche procédurale
VB
VB
VB
VB
VB
VB
fiche procédurale
Intégration des résultats
et liste des équipements
VB
VB
Alloué à
Critères :
- DD : 100Go min.
- RAM : 4Go
- Ethernet Gbit.
Durée = 2H
Critères :
- Nagios, Cacti, OCS, GLPI installés
- IP statique hors baux DHCP
- FQDN du système : SRV-EON.marseille.ingerop.com
Durée = 3H
Critères :
- HTTPS requis
- Pass admin personnalisé
- Cookies activés et authentification unifée entre éléments
Durée = 5H
Critères :
- Liste exhaustive des équipements
- Utilisation de l'Autodiscover et intégration des résultats
Durée = 1J
Critères :
- Communauté définie = INGEROP_MED
- Application de la communauté dans la conf de SNMPd
- Application de la communauté dans Cacti
- Port 161
Durée = 3H
Critères :
- Service installé sur les serveurs et activé sur les équipements
- SNMP V2c
- Communauté en lecture : INGEROP_MED
- Destination des traps : SRV-EON.marseille.ingerop.com
Durée = 2J
Critères :
- Liste non exhaustive de services à vérifier (AD, CPU, RAM, DD,
Tâches, Services, DNS, Uptime, Status,…)
- Répartition pertinente par type d'équipement
Durée = 2J
Critères :
- Définition plage "horaire de travail" (7H - 20H du lundi au vendredi)
- Application de la plage horaire de travail sur les services secondaires
- Application de la plage 24/24 - 7/7 aux services principaux
Durée = 1J
Critère qualité
aucune
Peut évoluer en
fonction des besoins
+1J
aucune
JA
JA
JA
JA
JA
JA; CB; NM
La personnalisation
unique du pass peut
valider la tâche
+1J
+1J
JA
JA
Personnes requises
pour le contrôle
qualité
aucune
aucune
Tolérance qualité
2.1.7.1
Serveur installé
PC opérationnel
Format attendu
2.1.7
Equipements réseau, Serveurs,
Service SNMP
Poste de travail non attribué
Héberger le serveur
T101 Matériel selectionné
Composition
Objectif
Code Nom de la tache
Descriptif du produit
Tâches
Page(s)41/97
Page(s) 42/97
Fréquences de requêtes
définies
Définir une fréquences
pertinente des requêtes
Objectif
Nagios
Composition
Eléments supervisés
configurés
Cacti
Cacti, plugin Rsyslog
Permettre la réception
d'évènement syslog par le
réseau TCP/IP
T115 Rsyslog configuré
Cacti
Identifier les composants à
quantifier
Avoir des graphes lisibles et
pertinent des composants
Serveurs
Nagios
Permettre aux équipements
de répondre aux requêtes
Appliquer des modèles de
supervision aux équipements
T114 Graphes générés
T113 Composants identifiés
T112
T111 Modèles appliqués
Défiinir une méthode
Nagios, NSClient++, Communauté
T110 Méthode de requete définie compatible et à faible charge
Nagios
pour les équipements
T109
fiche procédurale
Application de la conf
Application des modèles
et fiche procédurale
fiche procédurale
VB
VB
VB
VB
VB
VB
Liste des scripts intégrés,
Fichier de conf
Nsclient++ et fiche
procédurale
fiche procédurale
VB
Alloué à
Application sur les
modèles
Format attendu
Critères :
- Fréquence de status d'état : 10 min
- Fréquence de status de service critique : 10 min
- Fréquence de status de service secondaire : 30 min
- Intégration des fréquences dans les modèles
Durée = 1J
Critères :
- Scripts personnalisés provenant de la communauté ou développés en
interne (/SRV/Eyes of network/nagios/plugins/)
- Commandes et Alias définis en mode NRPE sur Nagios
- Intégration des Alias et scripts dans la conf de Nsclient++
Durée = 5J
Critères :
- Modèle par type d'équipement
- Intégration des services personnalisés au modèles
- Description détaillée par modèle et services
- Application des dépendances Hotes/Machine virtuelle
Durée = 2J
Critères :
- Déploiement de NSClient++ sur les serveurs avec intégration des alias
de commande et scripts personnalisés
- Script de déploiement des config sur le parc
- Service SNMP actif
Durée : 1J
Critères :
- Equipements importés de Nagios
- Utilisation du modèle de méthode de graphs WINDOWS
- Visualisation Eth, DD, RAM, CPU sur les serveurs par SNMP
Durée = 4H
Critères :
- Graphes crées
- Arborescence par site dans le "Tree"
- Rétention des graphes = 3 mois
Durée = 3H
Critères :
- Accepter réception TCP et UDP (/etc/rsyslog.conf)
- Port 514
Durée = 1H
Critère qualité
aucune
La rétention peut
etre réduite.
aucune
+1J
+1J
+3J
aucune
Tolérance qualité
JA
JA
JA
JA
JA
JA; CB; NM
JA
Personnes requises
pour le contrôle
qualité
Backup-Manager, Samba
Implémenter un cycle de
sauvegarde et permettre une
restauration
intégrer le serveur dans
l'infrastructure
T119 Sauvegarde configurée
T120 Serveur mis en production
Serveur DHCP et DNS, Nagios
Postfix, Nagios, Cacti
Permttre la notification par
mail d'un évènement matériel
ou système
Snare
Serveurs, Snare
Composition
T118 Notifications configurées
Envoyer des informations
hierarchisées
T116 Outil d'évènement déployé
Remontées d'évènement
configurées
Déployer un outil permettant
la compatibilité des journaux
windows avec Syslog
T117
Objectif
fiche procédurale
fiche procédurale
VB
VB
VB
VB
Application de la conf,
fichier .reg de conf et
fiche procédurale
fiche procédurale
VB
Alloué à
fichier .reg de conf et
fiche procédurale
Format attendu
Critères :
- Utilisation outil Snare for Windows
- Destination syslog = SRV-EON.marseille.ingerop.com
- Port 514
- Syslog priority en mode DYNAMIC
- Fichier .reg de conf
Durée = 2J
Critères :
- Niveaux Notice, Warning et Error
- Evènements application, système, AD, DNS
- Fichier .reg de conf
- Règles de suppression des évènements inutiles dans Rsyslog
Durée = 2J
Critères :
- Configuration Postfix (/etc/postfix/main.cf)
- SMTP = smtp.ingerop.com
- Notification Nagios ERROR-WARN en plage horaire de travail
- Notification Nagios UP-DOWN en plage continue
- Notification du Rsyslog (WARNING-ERROR) en continue
Durée = 2J
Critères :
- Complète à 4H tous les jours, rétention 5 jours
- Installation SMB et création user et partage sécurisé (/var/archives)
- Script de copie des archives vers espace serveur Admin (R:\SI\EON)
Durée = 1J
Critères :
- Ondulation de la machine
- Enregistrement DNS et réservation DHCP
- Mise à zéro des données BDD
- Application configuration Nagios
Durée = 1J
Critère qualité
JA
JA
La base peut etre
conservée
+1J
JA
+1J
+1J
JA; CB; NM
JA
L'outil peut etre
différent de celui
préconisé en cas
d'incompatibilité
+1J
+1J
Personnes requises
pour le contrôle
qualité
Tolérance qualité
Page(s)43/97
Page(s) 44/97
Services identifiés
Fréquence des
requêtes définie
Plage horaire des
requêtes définie
Equipements
répertoriés
Communauté SNMP
définie
Service SNMP
configuré sur les
composants
Composants
identifiés
Graphes générés
Configuration
appliquée sur les
éléments supervisés
Modèles appliqués
Capacité
supervisée
Disponibilité
supervisée
Rsyslog configuré
Outil d’évènements
déployé
Remontées
d’évènements
configurées
Logs
supervisés
Sauvegarde
configurée
Serveur installé
Serveur sécurisé
Matériel
sélectionné
2.1.7.2
Méthode de
requête définie
Notification
opérationnelle et
ciblée
Serveur mis en
production
Système
supervisé
Schéma de flux de composants
2.1.8
Planification
Page(s)45/97
2.2
Documentation technique
2.2.1
2.2.1.1
Configuration SNMP
Principe
Sur chaque équipement on trouve un agent Snmp. Cet agent gère les informations
relatives à l’équipement et sont stockées dans une base de données propre : la MIB
(Management Information Base).
Pour faire simple, chaque équipement contient des OID, ce sont une liste de numéro
servant à identifier des ressources. Une MIB sert à faire la translation d’un OID en un nom
compréhensible.
Le serveur de supervision va interroger l’agent Snmp d’un équipement. Cette interrogation
est réalisée avec le protocole UDP sur les ports 161 et 162.
Il est indispensable de définir une communauté SNMP identique à l’ensemble de nos
équipements, ainsi nous configurons INGEROP_MED sur le serveur et les équipements.
2.2.1.2
Application
Nous rentrons notre communauté tout d’abord dans les ressources Nagios :
Puis dans la configuration du Démon SNMP :
Page(s) 46/97
Le service SNMP doit être installé et activé sur les hôtes Windows, nous pouvons y définir
les communautés et le serveur de destination des traps :
2.2.2
2.2.2.1
Création d’une commande en NRPE
Principe
Ce mode permet une économie de la bande passante, les scripts et méthodes de checks
sont stocké sur le poste client, seul une commande contenant un alias ainsi que la réponse
sont envoyés par le réseau.
Cet outil requiert NSClient++ pour les machines Windows. (Cf. 2.2.3 Configuration de
NSClient++)
Page(s)47/97
2.2.2.2
Application
Nous allons créer une commande dans la configuration de Nagios.
Le plugin check_nrpe doit être auparavant mis sur le serveur dans le dossier
/srv/eyesofnetworks/nagios/plugins/
Lacréation se fait à partir de la vue Nagios Command :
Cette commande prend en compte l’adresse de l’hôte à superviser ainsi qu’un argument
qui sera l’alias du service.
Voici un exemple d’utilisation de la commande dans la création d’un service :
Page(s) 48/97
L’alias se rentre dans les paramètres de la commande du service :
2.2.3
Configuration de NSClient++
2.2.3.1
Principe
Cet outil est un agent dédié à la supervision Windows, il permet de récupérer les
informations système en plus des informations matérielles récupérées en SNMP.
Il permet également l’utilisation du mode NRPE vu précédemment et le mode NSCA qui
effectue des checks passifs.
Une bibliothèque de DLL offre plusieurs commandes et permet d’intégrer des scripts
personnalisés.
2.2.3.2
Configuration du client
NSclient++ s’installe sur les hôtes Windows, la configuration est stockée dans un fichier
nsclient.ini, c’est dans ce dernier que nous définissons les alias de commande.
Des commandes prédéfinies sont intégrées dans le client mais des commandes
personnalisées peuvent être définies et placées dans le dossier script du dossier
d’installation Nsclient.
Toutes les transactions client/serveur se font en SSL.
; ALLOWED HOSTS - A comaseparated list of allowed hosts. You can use netmasks (/
syntax) or * to create ranges.
allowed hosts = 10.22.8.101
; Section for NRPE (NRPEListener.dll) (check_nrpe) protocol options.
[/settings/NRPE/server]
use_ssl=1
allow_nasty_meta_chars=1
; Section for external scripts configuration options (CheckExternalScripts).
[/settings/external scripts]
script_dir=.\scripts\
; A list of aliases available. An alias is an internal command that has been "wrapped" (to
add arguments). Be careful so you don't create loops (ie check_loop=check_a,
check_a=check_loop)
Page(s)49/97
[/settings/external scripts/alias]
alias_service=CheckServiceState CheckAll exclude=HidServ
alias_mem=CheckMEM ShowAll MaxWarn=90% MaxCrit=95% type=physical type=page
type=virtual
alias_drive=CheckDriveSize ShowAll MaxWarn=90% MaxCrit=95% CheckAll=volumes
alias_cpu=CheckCPU ShowAll warn=60 crit=80 time=5m time=1m time=30s
alias_uptime=CheckUpTime ShowAll MinWarn=30m
;alias_task=CheckTaskSched filter=title='Defrag_c' syntax=%title%:%exit_code%
alias_adfer=CheckProcState
v3.5f.exe=started
match=regexp
ShowAll
Progiscad_Licence_server\
alias_disk=CheckCounter \\Disque\ physique(_Total)\\%\ Temps\ du\ disque ShowAll
MaxWarn=60 MaxCrit=90
alias_vmw=CheckProcState match=regexp ShowAll vmware-vmx.exe=started
; A list of scripts available to run from the CheckExternalScripts module. Syntax is:
<command>=<script> <arguments>
[/settings/external scripts/scripts]
alias_dc=scripts\check_ad.exe --dc
alias_membre=scripts\check_ad.exe --member
;alias_task=scripts\SchedulerCheck.bat
alias_task=scripts\Nagios_Plugin_Collection\check_taskscheduler.exe $ARG1$
2.2.3.3
Mise à jour de la configuration des clients
Pour automatiser les mises à jour des configurations ou intégrer des nouvelles
commandes, un script a été créé pour mettre à jours tous les hôtes, voici un exemple :
M:\admin\supervision\nagios\config\psexec.exe \\srv-nod32.marseille.ingerop.com net stop
nscp
COPY /Y M:\admin\supervision\nagios\config\nsclient.ini "\\SRVNOD32.marseille.ingerop.com\c$\Program Files\NSClient++\"
del "\\srv-nod32.marseille.ingerop.com\c$\Program
Files\NSClient++\scripts\Nagios_Plugin_Collection"
mkdir "\\srv-nod32.marseille.ingerop.com\c$\Program
Files\NSClient++\scripts\Nagios_Plugin_Collection\"
COPY /Y M:\Admin\Supervision\Nagios\plugin\Nagios_Plugin_Collection\* "\\srvnod32.marseille.ingerop.com\c$\Program
Files\NSClient++\scripts\Nagios_Plugin_Collection\"
M:\admin\supervision\nagios\config\psexec.exe \\srv-nod32.marseille.ingerop.com net start
nscp
Page(s) 50/97
2.2.4
2.2.4.1
Création d’un modèle Nagios
Principe
La création de modèles par type de matériel et de système permet une administration
aisée de la supervision.
Nous partons d’un modèle générique sur lequel nous modifions les fréquences et
effectuant les check de status (check_host_alive) d’un hôte. La fréquence des checks est à
l’échelle de la minute.
Chaque modèle crée aura comme parent le modèle GENERIC_HOST.
Des services à supervisés sont implémentés sur les modèles :
Les checks de services se font majoritairement toutes les 10 minutes à l’exception de
services moins « dynamiques » comme les taches planifiées par exemple qui se font
toutes les 30 minutes.
2.2.4.2
Application
Une tâche d’auto découverte du réseau est possible dans les Tools Nagios.
Page(s)51/97
Une fois les hôtes triés et renommés nous pouvons appliquer en masse les modèles dans
la partie Network de Nagios.
Pour valider la configuration il faut « appliquer la configuration », une tâche par défaut le
permet.
Page(s) 52/97
Ci-dessous la liste complète des hôtes et leur modèle associé :
name
Autocom_MPL
Autocom_MRS
Autocom_NCE
MRS-P1107
Routeur_A9
Routeur_AIX1
Routeur_AIX2
Routeur_MPL1
Routeur_MPL2
Routeur_MRS1
Routeur_MRS2
Routeur_NCE1
Routeur_NCE2
SRV-A9
aix-p0068.aix.ingerop.com
mpl-p1064.montpellier.ingerop.com
mrs-p1181.marseille.ingerop.com
nce-p1075.nice.ingerop.com
srv-eon.marseille.ingerop.com
Switch_AIX1
Switch_MPL1
Switch_MRS1
Switch_MRS2
Switch_MRS3
Switch_NCE1
Switch_NCE2
Switch_MPL2
Riverbed_AIX
Riverbed_MPL
Riverbed_MRS
Riverbed_NCE
mrs02001.marseille.ingerop.com
aix02004.aix.ingerop.com
mpl02001.montpellier.ingerop.com
nce02001.nice.ingerop.com
srv-nod32-aix.aix.ingerop.com
srv-nod32-mpl.montpellier.ingerop.com
srv-nod32-nce.nice.ingerop.com
srv-nod32.marseille.ingerop.com
srv-winkhaus.marseille.ingerop.com
xps-xerox-aix.aix.ingerop.com
xps-xerox-mpl.montpellier.ingerop.com
xps-xerox-nce.nice.ingerop.com
xps-xerox.marseille.ingerop.com
alias
Autocom_MPL
Autocom_MRS
Autocom_NCE
Hote SRV-A9
Routeur_A9
Routeur_AIX1
Routeur_AIX2
Routeur_MPL1
Routeur_MPL2
Routeur_MRS1
Routeur_MRS2
Routeur_NCE1
Routeur_NCE2
Serveur A9
aix-p0068.aix.ingerop.com
mpl-p1064.montpellier.ingerop.com
mrs-p1181.marseille.ingerop.com
nce-p1075.nice.ingerop.com
srv-eon.marseille.ingerop.com
Procurve 2650 (AIX)
Procurve 4204 VL (MPL)
Procurve 4208 VL (MRS)
Procurve 4104 GL (MRS)
Procurve 2810 (MRS)
Procurve 4208 VL (NCE)
Procurve 4204 VL (NCE)
HP1800-24G
Riverbed_AIX
Riverbed_MPL
Riverbed_MRS
Riverbed_NCE
srv-nod32-aix.aix.ingerop.com
srv-nod32-mpl.montpellier.ingerop.com
srv-nod32-nce.nice.ingerop.com
srv-nod32.marseille.ingerop.com
srv-winkhaus.marseille.ingerop.com
xps-xerox-aix.aix.ingerop.com
xps-xerox-mpl.montpellier.ingerop.com
xps-xerox-nce.nice.ingerop.com
xps-xerox.marseille.ingerop.com
address
10.22.9.15
10.22.8.15
10.22.17.15
10.22.98.3
10.22.98.1
10.22.34.252
10.22.34.253
10.22.9.252
10.22.9.253
10.22.8.252
10.22.8.253
10.22.17.252
10.22.17.253
10.22.98.2
10.22.34.138
10.22.9.113
10.22.8.214
10.22.17.55
10.22.8.101
10.22.34.20
10.22.9.4
10.22.8.25
10.22.8.20
10.22.8.24
10.22.17.22
10.22.17.20
10.22.9.5
10.22.34.250
10.22.9.250
10.22.8.250
10.22.17.250
10.22.8.2
10.22.34.2
10.22.34.5
10.22.9.2
10.22.8.3
10.22.8.6
10.22.17.2
10.22.17.5
10.22.9.3
10.22.34.142
10.22.9.135
10.22.17.57
10.22.8.218
10.22.8.217
10.22.34.132
10.22.9.136
10.22.17.76
10.22.8.216
template
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
GENERIC_HOST
Hotes VM
Hotes VM
Hotes VM
Hotes VM
LINUX
PROCURVE
PROCURVE
PROCURVE
PROCURVE
PROCURVE
PROCURVE
PROCURVE
PROCURVE-HP1800
Riverbed
Riverbed
Riverbed
Riverbed
Serveur Windows
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DCbis
Serveur Windows-virtuel
Serveur Windows-virtuel(XP)
Page(s)53/97
2.2.5
Visualisation des services
L’interface tableau de bord permet une vision générale de l’état des services et des hôtes :
La « vue service » permet de voir l’état détaillé de l’intégralité du parc supervisé :
Page(s) 54/97
Voici la liste des services associés aux modèles :
name
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Hotes VM
LINUX
LINUX
LINUX
LINUX
LINUX
PROCURVE
PROCURVE
PROCURVE
PROCURVE
PROCURVE
PROCURVE-HP1800
Riverbed
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
Serveur Windows-DC
description
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Hotes VM
Template Linux
Template Linux
Template Linux
Template Linux
Template Linux
Template Procurve
Template Procurve
Template Procurve
Template Procurve
Template Procurve
Template Procurve HP1800-24G (uptime uniquement)
Riverbed
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows
Serveur Windows controleur de domaine
Serveur Windows controleur de domaine ne gérant pas le système de management HP
Serveur Windows virtualisé
Serveur Windows virtualisé sous XP (CPU et UPTIME out en NRPE)
service
CPU
DISQUE
MEMOIRE
SERVICES
TACHES
UPTIME
VMWorkstation
memory
partitions
processor
systime
uptime
CPU
FAN
MEMOIRE
Power
uptime
uptime
STATUS
AD_MEMBRE
CPU
DISQUE
HP MANAGEMENT
MEMOIRE
SERVICES
TACHES
UPTIME
AD
CPU
DISQUE
DNS Status
HP MANAGEMENT
MEMOIRE
SERVICES
TACHES
UPTIME
AD
CPU
DISQUE
DNS Status
MEMOIRE
SERVICES
TACHES
UPTIME
CPU
DISQUE
MEMOIRE
SERVICES
UPTIME
CPU
DISQUE
MEMOIRE
SERVICES
UPTIME
command
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
linux_memory
partition-fs_snmp
linux_cpu
systime
uptime
check_hpcpu
check_hpfan
check_hpmemoryfree
check_hppower
uptime_public
uptime_public
check_riverbed
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_hp
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
dns_status
check_hp
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
dns_status
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
snmp_cpu
check_nrpe_svc
check_nrpe_svc
check_nrpe_svc
uptime
Page(s)55/97
2.2.6
Etude de la capacité
2.2.6.1
Principe
Nous voulons évaluer les performances de nos équipements et définir des pics
d’utilisations. Nous allons étudier principalement les ressources suivantes :

CPU

RAM

Espace disque

Réseau
2.2.6.2
Application
L’import des hôtes Nagios est possible :
La communauté ainsi que la version du protocole SNMP est à définir :
Page(s) 56/97
Sur chaque hôte nous ajoutons des graphes et utilisons le modèle générique SNMP pour
effectuer les demandes de données, la banque de MIB intégrée à l’outil permet la lecture
des données.
Un arbre de graphes peut être mis en place pour plus de visibilité
Page(s)57/97
2.2.7
2.2.7.1
Configuration SYSLOG
Principe
Le but est de pouvoir regrouper les journaux d’évènements des différents serveurs
Windows, en natif les évènements ne sont pas compatible syslog, nous devons donc les
transformer pour permettre leur envoie vers le plugin Rsyslog de CACTI.
2.2.7.2
Application
Nous devons tout d’abord permettre la réception des paquets par le plugin Rsyslog, les
lignes suivantes doivent être ajoutées au fichier de conf (ajoutez sous la ligne « $ModLoad
imuxsock ») :
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
L’outil Snare for Windows permet la transformation des évènements en format compatible
syslog. Nous définissons notre serveur comme destination des logs ainsi que le port 514
qui est écouté par le serveur. Nous mettons les priorités en gestion dynamique. (Installer
tout d’abord la V4 du logiciel, le paramétrer puis mettre à jour vers la dernière version, la
gestion dynamique ne fonctionne pas sans ce mode opératoire)
Nous définissons par la suite les évènements à auditer (ces audits remplacent les audits
Microsoft), nous priorisons les évènements systèmes et applicatifs. Une clé de registre
permet l’intégration rapide de cette configuration. (M:\admin\supervision\snare)
Page(s) 58/97
Les remontées sont toutes centralisées sur la console syslog. L’affichage peut être filtré
par hôte et par priorité.
Un filtrage de certains évènements récurrents et mineur peut être effectué en cliquant sur
les icones à côté de l’évènement par exemple :
(Certains problèmes avec les caractères spéciaux sont à noter)
Des notifications par type de priorité sont mise en place :
Page(s)59/97
séquence « Déploiement »
SEQUENCE « DEPLOIEMENT »
3
3.1
Plan de séquence
3.1.1
Description du plan
3.1.2
Préalables
Le serveur doit au préalable être installé et sécurisé.
Nous utilisons l’outil OCSInventory compris dans la suite logicielle choisie pour réaliser
cette séquence.
3.1.3
Cette séquence peut s’intégrer dans le déploiement d’Agora, notre GED (gestion
électronique des documents) interne qui requiert des mises à niveau régulières du Runtime
de JAVA.
3.1.4
Hypothèses de planification
La planification de cette séquence dépend de la validation de la sécurisation du serveur.
3.1.5
-
Déploiement du package d’installation de l’agent
-
Test du télédéploiement concluant
Page(s) 60/97
3.1.6
Budget et délai
Le cout de la main d’ouvre de cette séquence est estimé à 1 200€.
Le délai initial de mise en œuvre est évalué à 36 jours après sécurisation du serveur.
3.1.7
Tolérances
Nous tolérons jusqu’à 4 jours supplémentaire de mise en œuvre.
De plus la classification automatique des informations est facultative, des recherches
multicritères poussées peuvent être réalisées.
Page(s)61/97
Objectif
Page(s) 62/97
OCS, PC client
Paquet de télédéploiement
testés
Permettre le télédeploiement
d'un paquet d'installation ou
un script
T205
OCS
Créer des groupes par type de
machine et par site
T204 Informations classées
Paquet d'installation et
fiche procédurale
Application des groupes
Déploiement et fiche
procédurale
OCS, PC client, Contrôleur de
domaine
Package d'installation et
fiche procédurale
Agent OCS, OCSPackager, PC
client
Déployer l'agent sur les clients
Package d’installation client Permettre une installation
crée
silencieuse et préconfigurée
T203 Package déployé
T202
Certificat et fiche
procédurale
Format attendu
VB
VB
VB
VB
VB
Alloué à
Critères :
- Clé privée OpenSSL 1024bits déployée sur Apache (Server.key)
- Certificat autosigné valide pour 5 ans (cacert.pem)
- Fréquence de PROLOG = 24H
- Activation DEPLOY et MAJ des URL de télédéploiement
Durée = 5H
Critères :
- Utilisation OCSLogon pour le déploiement
- Utilisation d'OCSPackager pour création du paquet
- HTTPS requis (intégration du certificat)
- Force l'installation du dernièr client
- Intsllation silencieuse
Durée = 2J
Critères :
- Champ TAG différent par site
- Intégration d'Ocslogon (10.22.8.101.exe) dans une GPO
- Logs d'installation clients visibles
Durée = 1J
Critères :
- Groupes dynamiques par TAG
- Filtres de recherches par logiciels
- Export de la liste de logiciels
Durée = 3H
Critères :
- Package d'installation Java 7.04x86
- Installation silencieuse
- Paquet activé pour le déploiement
- Application à un groupe de machine
- Logs visibles
Durée = 1J
Critère qualité
JA
JA
Groupes facultatifs,
recherche
multicritère efficace
+1J
JA
JA
JA
Personnes requises
pour le contrôle
qualité
+1J
+1J
Le PROLOG peut
etre augmenté pour
éviter les surcharges
réseaux.
+1J
Tolérance qualité
3.1.8.1
Apache, OCS
Composition
3.1.8
Sécuriser par certificat
Certificat d’accès généré et
T201
l'inventaire d'une machine et
serveur configuré
configurer le serveur
Composants
3.1.8.2
Schéma de flux de composants
Télédéploiement
fonctionnel
Paquet de
télédéploiement
testés
Informations
classées
Déploiement du
package
Package
d’installation client
crée
Certificat d’accès
généré et serveur
configuré
Serveur sécurisé
Serveur installé
3.1.9
Matériel
sélectionné
Planification
Page(s)63/97
3.2
Documentation technique « déploiement »
3.2.1
3.2.1.1
Déployer l’agent OCS
Principe
Afin de récupérer les informations matérielle, logicielles et d’offrir la possibilité de déployer
des paquets, un agent est nécessaire sur les postes clients et les serveurs.
Nous définissons un paquet par agence qui sera déployé par GPO.
3.2.1.2
Application
L’outil OCS Packager permet la création du package d’installation, il intègre le certificat de
sécurité pour accéder au serveur, le client ainsi que les paramètres d’installation :
Page(s) 64/97
Le déploiement par GPO se fait par un exécutable OCSlogon, léger pour ne pas
encombrer le réseau.
Nous devons renommer l’exécutable afin qu’il prenne l’adresse IP du serveur comme nom.
Le package associé est à mettre dans le même dossier de la GPO. Ainsi un client se
mettra à jour automatiquement si besoin à l’ouverture de session.
3.2.2
Déployer un paquet par OCS
3.2.2.1
Principe
A chaque communication client/serveur, dans notre cas au maximum toute les 24H, le
serveur notifie le client d’une éventuelle demande de déploiement de paquet.
Cette méthode permet de ne pas surcharger les contrôleurs de domaines lors des
déploiements qui ne sont pas à effectuer d’urgence.
De plus l’agent récupère les informations systèmes (logiciel, registre,…) et matérielle de la
machine, si une modification est effectué sur la machine les informations mises à jour sont
envoyées au serveur.
3.2.2.2
Application
Nous allons créer un paquet à partir de la console d’administration :
Il existe 3 types de déploiement :



Stocker (Dépose des fichiers dans un répertoire défini)
Exécuter (Exécute une commande)
Lancer (Lance un fichier ou un script)
Page(s)65/97
Dans notre cas nous allons Lancer l’installation de Java7, pour ce faire nous compressons
l’exécutable puis explicitons le fichier et les paramètres à lancer :
Une fois crée, le paquet doit être activé sur le serveur :
La méthode de recherche multicritères permet de trouver facilement des machines non à
jour ou n’ayant pas un logiciel requis, dans ce cas nous cherchons toute les machines
n’ayant pas la version 1.0.3 de Classifio :
En bas de la liste de résultats plusieurs options comme grouper les résultats, modifier la
configuration de la sélection s’offre à nous, nous allons choisir déployer :
Page(s) 66/97
Il ne reste plus qu’à affecter les paquets voulus aux clients :
L’état des paquets déployés est visible sur la vue d’activation des paquets. Il peut être
dans 3 états :

NOTIFIED : le client a été notifié qu’un paquet est en attente de téléchargement

SUCCESS : le paquet a correctement été déployé

ERROR : une erreur est survenue
Page(s)67/97
Séquence « inventaire »
SEQUENCE « INVENTAIRE »
4
4.1
4.1.1
Plan de séquence
Description du plan
Matériel – Logiciels - Contrats
4.1.2
Préalables
Le serveur doit au préalable être installé et sécurisé.
Nous utilisons l’outil GLPI compris dans la suite logicielle choisie pour réaliser cette
séquence.
4.1.3
Cette séquence ne dépend d’aucun autre projet.
4.1.4
La planification de cette séquence dépend de la validation de la sécurisation du serveur.
De plus pour les informations matérielles et logicielle, il est préférable d’avoir validé le tri
des informations de la séquence « Déploiement » afin d’automatiser la saisie.
4.1.5
-
Contrats inventoriés
-
Equipements inventoriés
-
Logiciels inventoriés
Page(s) 68/97
4.1.6
Budget et délai
La main d’œuvre est estimée à 2 900€ pour un délai de 38 jours après sécurisation du
serveur.
4.1.7
Tolérances
Nous estimons à 6 jours de tolérance raisonnable sur le délai initial.
L’utilisation des outils d’import directement intégrés à GLPI par le biais du plugin OCSImport n’est pas obligatoire mais conseillée, elle permet l’intégration automatique d’un
grand nombre de champs.
Page(s)69/97
Page(s) 70/97
Licences logicielles
inventoriées
Lister les logiciels
Lister le matériel de notre
infrastructure
T303 Matériel répertorié
T304
Lister tous les contrats
T302 Contrats répertoriés
identifier les champs
pertinents
GLPI
GLPI, OCS
GLPI, Classeur de contrats
GLPI
Composition
Base de licences remplie
VB; JA
VB
VB; JA
Base de contrats
remplie
Base du matériel
remplie
VB
Alloué à
Tables SQL remplies
Format attendu
Crtitères :
- Gabarits par type d'équipement, contrats, logiciels crées
- Table constructeur remplie
- Table modèle remplie
- Table fournisseur remplie
- Table développeur remplie
Durée = 4J
Critères :
- Liste exhaustive des contrats intégrée
Durée = 2J
Critères :
- Import serveurs depuis OCS
- Liste exhaustive des équipements intégrée
Durée = 1J
Critères :
- Liste exhaustive des logiciels intégrée
- Utilisation du dictionnaire OCS et épuration des données
- Filtre des MAJ lors de l'import
- Utilisation du plugin d'import des logiciels OCS
Durée = 5J
Critère qualité
JA
JA
JA
+2J
L'utilisation de
l'import d'OCS n'est
pas obligatoire
+2J
JA
Personnes requises
pour le contrôle
qualité
L'utilisation de
l'import OCS n'est
pas obligatoire
+1J
+1J
Tolérance qualité
4.1.8.1
Champs nécessaires
identifiés
Objectif
4.1.8
T301
Composants
4.1.8.2
Schéma de flux des composants
Composants
inventoriés
inventoriées
Matériel répertorié
Contrats répertoriés
Champs nécessaires
identifiés
Serveur sécurisé
Serveur installé
4.1.9
Matériel
sélectionné
Planification
Page(s)71/97
4.2
Documentation technique « Inventaire »
4.2.1
Principe
Nous désirons avoir une base de gestion dynamique de notre parc matériel, logiciel et
contractuel. GLPI offre cette possibilité, de plus le couplage avec la solution OCS et les
plugins import-OCS permettent de récupérer automatiquement les informations logicielles
et matérielles.
4.2.2
4.2.2.1
Application
Contractuel
Dans la partie gestion, nous pouvons implémenter une base de contrats, nous reprenons
les différents contrats de maintenances logiciels, matériels et des prestataires. Nous y
intégrons les heures d’interventions, la durée et demandons une alerte à la fin du contrat.
Page(s) 72/97
4.2.2.2
Logiciel
Nous importons les logiciels installés grâce au module d’import, nous pouvons effectuer un
tri des logiciels inutiles à partir d’OCS et avec les dictionnaires GLPI qui permettent de
créer des règles d’import.
Nous remplissons la partie Licence du logiciel afin de définir des informations
administratives ainsi que le nombre de licences disponibles.
Nous pouvons également associer des contrats de maintenances logiciels précédemment
rentrés pour obtenir une fiche détaillée complète.
Page(s)73/97
4.2.2.3
Matériel
De même que pour les logiciels les postes sont importés directement d’OCS, nous trions
afin de ne garder que les serveurs :
Nous pouvons intégrer les données administratives et financières et y associer un contrat
de maintenance par exemple les Carepack HP pour les serveurs.
Page(s) 74/97
Les éléments actifs doivent par contre se rentrer à la main car la détection SNMP n’est pas
encore opérationnelle avec la version en cours.
Page(s)75/97
Séquence « niveaux de services »
5
5.1
SEQUENCE « NIVEAUX DE SERVICES »
Plan de séquence
5.1.1
Description du plan
5.1.2
Préalables
Nous devons avoir au moins un mois de données de disponibilité et capacité pour pouvoir
les analyser. La séquence de supervision doit être achevée pour pouvoir par la suite établir
des niveaux de service.
5.1.3
Le groupe INGEROP rentre dans une logique de certification ISO 27001 démontrant la
maitrise des risques de son système d’information.
La définition, avec la direction régionale, de contrats de niveaux de services avec ses
composants associés rentre dans le référentiel de la norme.
5.1.4
Cette séquence ne débutera qu’avec des données exploitables provenant de la séquence
« supervision », nous estimons à au moins un mois de données récoltées pour pouvoir
évaluer des tendances.
5.1.5
La validation générale de la séquence dépendra de l’acceptation des niveaux de services
par la direction.
Page(s) 76/97
5.1.6
Budget et délai
La main d’œuvre s’élève approximativement à 1 200€.
Un délai de 9 jours doit permettre la validation de cette séquence. Ce délai prend effet
après mise en production du serveur et récolte des données.
5.1.7
Tolérances
Un délai supplémentaire de 5 jours peut être acceptable.
La définition d’une charte spécifique ainsi que la répartition des rôles peuvent être reportés
et sont facultatives à ce niveau du projet. L’élaboration de niveaux de services reste la
priorité de la séquence.
Page(s)77/97
Page(s) 78/97
Fréquence de rapport
validée
Définir une fréquence de
présentation de rapports
Définir les niveaux de services
actuellement respectables
T406 Niveaux de service définis
T407
Définir les responsabilités
Charte de rapport
Composants du système
d'information
Equipe informatique régionnale
Nagios
Permettre la génération de
rapports compréhensibles
T405 Rôles définis
T404 Charte de rapport définie
Nagios
Grouper les services
nécessaire à un service métier
Calendrier
Tableau
Organigramme
Charte graphique des
SLA
Groupes de services
Relevés statistiques
Critère qualité
VB
Critères :
- Identification des pics d'utilisation
- Utilisation moyenne de ressource en production
Durée = 3h
Critères :
- Identification des éléments critiques
VB
- Tendances de disponiilité
Durée = 3h
Critères :
- Liste des services métiers critiques
VB
- Association des composants liés aux services
Durée = 1h
Critères :
- Utilisation de la charte INGEROP
VB
- Informations du rapport modifiables
Durée = 3h
Critères :
- Association d'un responsable service
VB; JA
- Processus d'escalades
Durée = 3h
Critères :
- Définition d'une disponibilté opérationnelle
VB; JA - Définition d'un temps d'intervention par service et criticité
- Validation par la direction
Durée = 3J
Critères :
- Fréquence régulière
VB; JA; AS - Liste des membres des réunions
Durée = 2H
Alloué à
+1J
+2J
JA;AS
JA; AS
JA
JA
Composant
facultatif
+2J
+1J
JA
JA
JA
Personnes requises
pour le contrôle
qualité
+1J
+1J
+1J
Tolérance qualité
5.1.8.1
Groupes de services métier
définis
Nagios
Analyser les statistiques de
disponibilité
T402 Disponibilité évaluée
Relevés statistiques
Format attendu
5.1.8
T403
Cacti
Analyser les statistiques de
capacité
T401 Capacité évaluée
Composition
Objectif
Composants
5.1.8.2
Schéma de flux des composants
Niveaux de
service
respectés
Fréquence de
rapport validée
Direction
Niveaux de service
définis
Rôles définis
Charte de rapport
définie
Groupes de services
métier définis
5.1.9
Capacité évaluée
Disponibilité
évaluée
Planification
Page(s)79/97
5.2
5.2.1
Service Level Agreement
Calcul
Formule de la disponibilité = MTTF / (MTBF + MTTR)
MTBF: Temps moyens de bon fonctionnement
MTTR: Temps total de réparation
MTTF: Temps moyen avant la prochaine défaillance
Nous prenons comme valeur de référence les horaires de disponibilité quotidienne de 7h à
20h pour 220 jours ouvrés.
Nous prenons en considération 2 types de pannes :

récurrentes qui nécessitent un redémarrage de serveur et bloquant l’activité durant
10 minutes une fois par mois

exceptionnelle qui nécessitent une réinstallation du serveur et une restauration des
données et l’utilisation du Carepack qui peut se produire une fois par an
Pour les services non redondés (messagerie, fichiers, DHCP,…) la disponibilité est la
suivante
(13*220) / (2860+2+26) = 99.03%
Pour le calcul des composants redondants nous utiliserons la formule suivante :
Composants a, b, ...n connectés en parallèle: Disponibilité = 1 - (1 - Da) x ... (1 - Dn)
Dans notre cas les serveurs de licences Autocad et les services d’administrations
redondés (AD et DNS) se calculent sur cette formule.
1-(1-0.9903)*(1-0.9903) = 99.99%
La disponibilité opérationnelle comprend l’intégration de la disponibilité du LAN qui est un
composant de tous les services métiers.
Disponibilité opérationnelle :
98.92%
Service : 99.03%
LAN : 99.89%
Ce calcul prend en compte les services non redondés : 99.03% * 99.89% = 98.92%
Ce calcul prend en compte les services redondés : 99.99% * 99.89% = 99.88%
Page(s) 80/97
5.2.2
Tableau
Nous établissons un tableau contenant les services critiques et reprenant les niveaux de
services calculés précédemment.
Nous incluons des temps de réponse aux requêtes faites par un utilisateur selon deux
niveaux, bloquante et non bloquante.
Nous indiquons également un marqueur de certification de récupération de donnée. Ainsi
par exemple pour les données de la messagerie, en cas de sinistre nous certifions une
perte des données des 24 dernières heures au plus.
Services
Messagerie
Fichiers
Logiciel métier
Autocad
Logiciel métier
Mensura
Logiciel métier
MIKE
Authentification
DNS
DHCP
LAN
Composants
Disponibilité métier
Disponibilité Disponibilité
individuelle operationnelle
Serveur Lotus et DNS
Eléments actifs
Câblage
Routeurs
Liaison WAN
Serveur HP
GTR opérateur
Pivot Lotus CBV
Cœur de réseau CBV
Carepack HP
99.03%
Serveur de fichiers
AD et DNS
Eléments actifs
Câblage
Serveur HP
Carepack HP
99.03%
Serveur de licence
Eléments actifs
Câblage
Routeurs
Liaison WAN
Serveurs
GTR opérateur
Serveur de licence CBV
Cœur de réseau CBV
Carepack HP
99.99%
Serveur de licence
Eléments actifs
Câblage
Routeurs
Liaison WAN
Serveurs
GTR opérateur
Carepack HP
99.03%
Serveur de licence
Eléments actifs
Câblage
Serveur
Carepack HP
Serveurs AD
Eléments actifs
Serveurs
Carepack HP
Serveurs DNS
Eléments actifs
Routeurs
Liaison WAN
Serveurs
Carepack HP
Serveur DHCP
Eléments actifs
Serveur
Carepack HP
Eléments actifs
Câblage
SAV HP
99.03%
99.99%
99.99%
99.03%
99.89%
Accord de niveau de service
Prestation de service
Traitement de requêtes Résolution de la requête
(heures ouvrées)
(heures ouvrées)
Non bloquante : J+1
J+3
H+24
Bloquante : H+3h
H+7h
H+24
Non bloquante : J+1
J+3
H+48
Bloquante : H+3h
H+10h
H+48
Non bloquante : J+1
J+3
aucune perte
Bloquante : H+3h
H+10h
aucune perte
Non bloquante : J+1
J+3
aucune perte
Bloquante : H+3h
H+10h
aucune perte
Non bloquante : J+1
J+3
aucune perte
Bloquante : H+3h
H+10h
aucune perte
Non bloquante : J+1
J+3
H+24
Bloquante : H+2h
H+5h
H+24
Non bloquante : J+1
J+3
H+24
Bloquante : H+3h
H+7h
H+24
Non bloquante : J+1
J+3
aucune perte
Bloquante : H+3h
H+10h
aucune perte
Non bloquante : J+1
J+3
aucune perte
Bloquante : H+2h
H+5h
aucune perte
98.92%
98.92%
99.88%
98.92%
98.92%
99.88%
99.88%
98.92%
99.89%
Récupération de données
Page(s)81/97
Page(s) 82/97
Méthode de
requête définie
Notification
opérationnelle et
ciblée
Services identifiés
Fréquence des
requêtes définie
Modèles appliqués
Plage horaire des
requêtes définie
Equipements
répertoriés
Communauté SNMP
définie
Service SNMP
configuré sur les
composants
Graphes générés
Configuration
appliquée sur les
éléments supervisés
Composants
identifiés
Capacité
supervisée
Disponibilité
supervisée
Rsyslog configuré
Outil d’évènements
déployé
Remontées
d’évènements
configurées
Logs
supervisés
Sauvegarde
configurée
Serveur installé
Serveur sécurisé
Certificat d’accès
généré et serveur
configuré
Package
d’installation client
crée
Déploiement du
package
Informations
classées
Paquet de
télédéploiement
testés
Télédéploiement
fonctionnel
Matériel
sélectionné
inventoriées
Champs nécessaires
identifiés
Matériel répertorié
Composants
inventoriés
Groupes de services
métier définis
Contrats répertoriés
Direction
Capacité évaluée
Disponibilité
évaluée
Charte de rapport
définie
Rôles définis
Niveaux de service
définis
Fréquence de
rapport validée
Niveaux de
service
respectés
6
Serveur mis en
production
Système
supervisé
Utilisateurs
Management
consolidé
Décomposition de flux de produits générale
DECOMPOSITION DE FLUX DE PRODUITS GENERALE
Etat
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
Validé
En cours
Validé
En cours
Validé
Validé
Validé
En cours
En cours
Validé
En cours
Validé
Validé
Validé
Validé
Vincent BACHMAN Joël AFONSO Support CBV CODIR
I
A-R
I
A-R
C
I
A-R
I
I
A-R
I
I
A-R
C
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
C
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
A-R
I
I
C
A-R
I
I
A-R
I
I
I
A-R
I
A-R
I
A-R
I
A-R
C
I
I
A-R
I
I
A-R
I
I
I
I
Représentants du personnel
7
Page(s)83/97
R = Responsable
A = Acteur
C = Consulté
I = Informé
Action
Lettre de mission
Initialisation du projet
Etude de rentabilisation
Macro planning
T101 - Matériel selectionné
T102 - Serveur installé
T103 - Serveur sécurisé
T104 - Equipements inventoriés
T105 - Communauté SNMP définie
T106 - Service SNMP configuré
T107 - Services identifiés
T108 - Plages horaires définies
T109 - Fréquences de requêtes définies
T110 - Méthode de requete définie
T111 - Modèles appliqués
T112 - Eléments supervisés configurés
T113 - Composants identifiés
T114 - Graphes générés
T115 - Rsyslog configuré
T116 - Outil d'évènement déployé
T117 - Remontées d'évènement configurées
T118 - Notifications configurées
T119 - Sauvegarde configurée
T120 - Serveur mis en production
T201 - Certificat d’accès généré et serveur configuré
T202 - Package d’installation client crée
T203 - Package déployé
T204 - Informations classées
T205 - Paquet de télédéploiement testés
T301 - Champs nécessaires identifiés
T302 - Contrats répertoriés
T303 - Matériel répertorié
T304 - Licences logicielles inventoriées
T401 - Capacité évaluée
T402 - Disponibilité évaluée
T403 - Groupes de services métier définis
T404 - Charte de rapport définie
T405 - Rôles définis
T406 - Niveaux de service définis
T407 - Fréquence de rapport validée
Schématisation des flux produits
Planification générale
Dossier de retour d'expérience
Assemblage du document final
RACI
RACI
Planification générale
8
PLANIFICATION GENERALE
Page(s) 84/97
RETOUR D’EXPERIENCE
1
MESURE DES ECARTS .............................................................................................................. 86
2
PROBLEMES RENCONTRES ....................................................................................................... 87
3
BILAN DU PROJET .................................................................................................................... 88
3.1
Technique ..................................................................................................................... 88
3.2
Organisationnel ............................................................................................................ 88
3.3
Personnel...................................................................................................................... 88
4
ELEMENTS REUTILISABLES ....................................................................................................... 89
5
AXES D’AMELIORATION ............................................................................................................. 90
Page(s)85/97
Retour d’expérience
Mesure des écarts
MESURE DES ECARTS
1
Nous reprenons le tableau des composants pour vérifier les écarts qualités constatés, ainsi
voici ci-dessous les composants comportant des écarts :
Objectif
T102 Serveur installé
Installer les composants
nécessaires
T103 Serveur sécurisé
Limiter les accès au serveur
T111 Modèles appliqués
Appliquer des modèles de
supervision aux équipements
T302 Contrats répertoriés
Lister tous les contrats
T304
inventoriées
Lister les logiciels
T404 Charte de rapport définie
Permettre la génération de
rapports compréhensibles
T405 Rôles définis
Définir les responsabilités
T407
Fréquence de rapport
validée
Définir une fréquence de
présentation de rapports
Critère qualité
Critères :
- Nagios, Cacti, OCS, GLPI installés
- IP statique hors baux DHCP
- FQDN du système : SRV-EON.marseille.ingerop.com
Durée = 3H
Critères :
- HTTPS requis
- Pass admin personnalisé
- Cookies activés et authentification unifée entre éléments
Durée = 5H
Critères :
- Modèle par type d'équipement
- Intégration des services personnalisés au modèles
- Description détaillée par modèle et services
- Application des dépendances Hotes/Machine virtuelle
Durée = 2J
Critères :
- Liste exhaustive des contrats intégrée
Durée = 2J
Critères :
- Liste exhaustive des logiciels intégrée
- Utilisation du dictionnaire OCS et épuration des données
- Filtre des MAJ lors de l'import
- Utilisation du plugin d'import des logiciels OCS
Durée = 5J
Critères :
- Utilisation de la charte INGEROP
- Informations du rapport modifiables
Durée = 3h
Critères :
- Association d'un responsable service
- Processus d'escalades
Durée = 3h
Critères :
- Fréquence régulière
- Liste des membres des réunions
Durée = 2H
Ecarts
IP dans le baux
DHCP mais réservée
Possibilité d'utiliser
des connexions
HTTP
Aucun, certains
modèles ont été
créer
particulièrement
pour des
équipements
A réaliser
Filtrage effectué,
utilisation du
dictionnaire d'OCS
mais les
informations n'ont
pas été intégrée à
GLPI
A réaliser
A réaliser
A réaliser
Nous pouvons tirer les conclusions suivantes sur les écarts :

La séquence « supervision » a été intégralement réalisée et validée, les écarts
étant mineurs. Ces écarts sont principalement techniques.

La séquence « Déploiement » a également été réalisé avec succès, les différents
tests ont été concluants avec les différents types de clients.

La séquence « Inventaire » n’a pas totalement été réalisée, il reste à inventorier les
contrats et les logiciels, ces derniers étant tenus à jour sur un fichier Excel. Ces
écarts sont dus à l’organisation, le plan de charge n’a pas permis la réalisation des
taches.

La dernière séquence « niveaux de services » comprend également des
composants non réalisés mais secondaires. Le tableau des SLA étant réalisé et
présenté à la direction la séquence est considérée comme validée.
A part pour certaines tâches secondaires non encore réalisées, le planning a été tenu, les
délais conséquents ont permis une mise en production du serveur mi-juin et une définition
des niveaux de services fin août.
Page(s) 86/97
Problèmes rencontrés
2
PROBLEMES RENCONTRES
Nous revenons sur les problèmes rencontrés durant la mise en œuvre ou durant
l’exploitation de la solution et y apportons une mesure corrective si possible.
Ces problèmes ont été techniques, organisationnels et environnementaux.
Type Problème
Problème d'accès avec OCS à la base de
TECH donnée MySQL
Panne matérielle du poste hebergeant la
solution suite à une coupure de courant avant
ENV la mise en production
Problème de caractères dans le Rsyslog,
impossibilité de mettre en œuvre certaines
TECH règles de flitrage
Découverte du réseau par SNMP par OCS
TECH incompatible avec les agent Windows
Déploiement de paquets impossible, plantage
de l'executable download.exe sur les clients,
TECH erreur de librairie VBC++
Remontées faussées durant les pics de
ORG charges des sauvegardes
Impossibilité de mettre les évènements en
TECH priorité dynamique
Mesure corrective
Unification des configurations pour des requetes SQL
vers 127.0.0.1
Déplacement du disque vers un poste de même type,
mise en place d'un onduleur, prévision de virtualisation
de la solution pour la migration en version 3.1
Passage de la base de données en mode UTF8 sans
effet, filtrage effectué sur des petites chaines de
caractères
Attente d'une future version de l'agent, intégration
manuelle des équipements dans GLPI
Non corrigé, attente d'une nouvelle version de l'agent,
veille sur les forum
Modification de la plage horaire des notifications
Installation de la version 4.0 de Snare, la configurer en
dynamique et ensuite faire les mises à jours en version
supérieure
Page(s)87/97
Bilan du projet
3
BILAN DU PROJET
Pour conclure nous vérifions l’atteinte de nos résultats attendus en début de projet.
3.1
Technique
Ce projet nous permet d’obtenir des informations de capacité et disponibilité de nos
équipements. Ces informations sont visibles sous forme de graphiques et sont exploitables
via une interface web.
Les services administratifs et métiers sont identifiés et supervisés.
Les évènements systèmes sont centralisés et lisibles.
Des seuils d’alertes permettent des notifications par mails lors de problèmes avérés.
La base de donnée ainsi que les fichiers de configurations du serveur (/srv/eyes of
network/*) sont sauvegardés chaque nuit à 4h et permettent une récupération de la
solution.
Au niveau de la sécurité des données, l’utilisation du SNMP v2c ne garantit pas la sécurité
des informations récupérées en SNMP, seule la version 3 de ce protocole permet la
sécurisation mais elle n’est pas utilisée pour des raisons de compatibilité. Le reste des
requêtes du serveur se font de manières chiffrées et sécurisées. De même l’accès au
serveur se fait en HTTPS et réside dans notre LAN donc ne risque aucune attaque
extérieure.
3.2
Organisationnel
Le gain de temps de maintenance et de réactivité est perceptible ce qui offre un temps
accru pour le service apporté aux utilisateurs.
La visualisation des états se fait sur une interface simplifiée et centralisée (https://srveon.marseille.ingerop.com) ce qui évite de se connecter à l’ensemble des serveurs du parc
pour vérifier l’état des serveurs et les évènements.
Un processus arrêté peut être relancé dans les 10 minutes après défaillance, ceci sans
que l’utilisateur s’en rende compte dans la majorité des cas.
Le système d’information est entièrement répertorié, ceci constitue la CMDB de notre
région, la recherche d’information se fait dorénavant plus rapidement.
Nous prévoyons une future augmentation de la satisfaction client lors de la prochaine
enquête satisfaction du groupe en début d’année prochaine.
3.3
Personnel
La mise en place de ce projet m’a permis d’approfondir mes connaissances en Linux
notamment, avec les configurations de HTTPd, Postfix et Samba.
Cet apport a pu se faire par le support de l’équipe du siège, les différentes discutions ont
mis en évidence les manques en matière de supervision au niveau de l’architecture
centrale. Un projet similaire pourrait voir le jour à l’échelle nationale.
J’ai pu mettre en application mes connaissances en ITIL dans le cadre de mon entreprise.
Page(s) 88/97
Elements réutilisables
4
ELEMENTS REUTILISABLES
Les documentations techniques ont été rédigées pour être utilisées comme documentation
de référence pour l’administration de base du serveur et de ses entrées. Ceci doit
permettre la modification de modèles ou l’ajout de machines par une personne tierce ou ne
maitrisant pas la solution.
Eventuellement ces documents doivent permettre de réinstaller le serveur en couplant les
procédures avec la documentation de la solution disponible sur le site officiel du produit.
Le tableau de SLA, pour suivre les préconisations ITIL, doit permettre la conception du
budget informatique selon les demandes de niveaux de la direction.
La base de données centralisée (CMDB) permet une meilleure gestion du matériel en
activité et des licences. Tenue à jour elle doit permettre une meilleure gestion du système
d’information.
Page(s)89/97
Axes d’amélioration
AXES D’AMELIORATION
5
Dans le cadre d’une amélioration continue du produit nous pouvons définir les axes
d’améliorations suivants :

Mise en place de la gestion des tickets par GLPI afin de centraliser toutes les
demandes et d’assurer un suivi des interventions et des incidents rencontrés.

Ce projet s’est réalisé à l’échelle régionale, la structure du projet peut être utilisée
pour une implantation nationale au niveau du siège. Ceci permettrait une
supervision des équipements du groupe.

Les services supervisés peuvent être affinés et mieux ciblés

De même les scripts ou méthodes de requêtes peuvent être améliorés avec
notamment les checks passifs (mode NSCA) ou l’utilisation de scripts plus légers et
plus documentés

Création d’une cartographie réseau avec Nagvis ou WeatherMap

Mettre en place une sonde réseau avec l’outil Ntop pour évaluer la quantité et le
type de flux transitant par le réseau
Page(s) 90/97
ANNEXES
1
LETTRE DE MISSION .............................................................................................................. 92
2
BILAN PERSONNEL ................................................................................................................ 93
3
REFERENCES .......................................................................................................................... 96
4
LEXIQUE ................................................................................................................................... 97
Page(s)91/97
Annexes
Lettre de mission
1
LETTRE DE MISSION
Page(s) 92/97
Annexes
Bilan personnel
2
2.1
BILAN PERSONNEL
Mon parcours
Titulaire d’un baccalauréat scientifique mon choix s’est d’abord orienté vers une faculté de
Math et Informatique. Mes résultats peu concluant en math et malgré la validation des
modules informatiques ne m’ont pas permis d’obtenir un diplôme, de plus la formation
s’orientait exclusivement vers le développement.
En cherchant une réorientation plus basé sur les systèmes et le réseau, un ami, ancien
étudiant du CESI m’a conseillé cette école. J’ai pu intégrer la formation de Gestionnaire en
Maintenance et Support Informatique en contrat de professionnalisation dans la société
Ingérop. La qualité des formateurs et de la formation m’ont encouragé à poursuivre le
cursus et à effectuer la formation de Responsable d’Administration de Réseaux
d’Entreprise. J’ai pu intégrer la formation tout en restant dans la même société en signant
mon contrat avec une filiale, Ipseau, aujourd’hui partie intégrante de la région
Méditerranée.
2.2
Ma formation au CESI
Issu de la formation GMSI, j’étais familier avec les méthodes de travail, le parcours RARE
a permis d’approfondir mes connaissances techniques en Linux, en virtualisation et en
réseau principalement. Mais l’apport principal de cette formation est l’aspect
organisationnel.
Les cours sur la méthode de gestion de projet Prince2 ainsi que la certification ITIL
Foudation m’ont grandement apporté dans ma capacité à m’organiser ainsi qu’à concevoir
l’organisation d’un service informatique d’envergure.
Le socle de la formation est le projet fil rouge Mégas qui nous a permis de mener à bien un
projet d’envergure. Ce projet abordait les principaux thèmes techniques et nous offrait la
possibilité de mettre en applications les outils de gestion de projet. De plus ce projet s’étant
réalisé en groupe de 3, cela m’a permis de mettre en place des outils collaboratifs et
m’aguerrir au travail en équipe.
2.3
2.3.1
Mes missions entreprise
Utilisateurs et postes clients
Ma mission a bien évoluée au cours des 4 années passées dans mon entreprise
formatrice. A mes débuts j’assurais principalement l’assistance téléphonique sur le site de
Marseille puis petit à petit les autres agences de la région. On m’a laissé l’autonomie
d’effectuer des déplacements réguliers sur tous nos sites pour effectuer les taches de
maintenance et le renouvèlement des postes utilisateurs, autre mission principale de ma
fonction.
Notre parc comprend environ 200 postes clients de 3 types, les postes bureautiques pour
l’administratif et certains ingénieurs, les stations de travail pour les dessinateurs et les
ingénieurs effectuant des calculs ou des modélisations et les postes portables pour la
direction, chefs de services et les personnes itinérantes.
Le processus de renouvellement de poste a été grandement modifié, avant mon arrivée le
matériel était envoyé dans chaque agence pour une installation sur site. Nous avons
centralisés les commandes et mis en place des systèmes de déploiement avec l’outil WDS
Page(s)93/97
Annexes
Bilan personnel
et la création d’images personnalisées pour accélérer et automatiser les installations. De
plus cela nous a permis une migration progressive vers Windows 7.
2.3.2
Parc serveur
Nous gérons également un parc de 9 serveurs dispatchés entre les différentes agences,
comprenant les contrôleurs de domaines, les serveurs de licence, les données, les
services de mise à jour des clients et la messagerie Lotus Domino.
J’ai pu effectuer les migrations de l’intégralité de nos contrôleurs de domaine pour effectuer
un renouvellement du matériel et passer de Server 2003 à Server 2003 R2.
Durant mes deux dernières années le service informatique a vu une nouvelle répartition
des tâches, mon tuteur se consacrant à 90% au développement et au suivi de notre
nouvelle GED interne. J’ai eu donc la pleine gestion des serveurs sous ma responsabilité.
Avec tout ce que cela comprend, la sauvegarde, l’optimisation, la gestion des
redondances, etc…
2.3.3
Affaires
Grâce à mes connaissances en développement et la formation VBScript du CESI j’ai pu
créer des scripts d’automatisation de la création de dossiers d’affaires avec notre
arborescence qualité.
Par la suite j’ai ajouté un autre script prenant en compte les droits de sécurité dans
l’arborescence. Pour cela une refonte complète des droits utilisateurs a été effectuée et
appliquée à l’ensemble de nos données de travail.
2.3.4
Archives
Le service informatique est responsable de l’archivage informatique, nous stockons
sécurisons et suivons les supports qui sont empruntés régulièrement.
J’ai également été nommé responsable du déménagement de nos archives papier pour
cause de la libération du local qui les hébergeait. Je les ai répertoriées, classées et
externalisées, un nouveau processus d’archivage a du coup été mis en place.
2.3.5
Virtualisation
Plusieurs services sont ont dû être intégrés à notre infrastructure tel que la base de donnée
gérant la contrôle d’accès à nos locaux, la base de donnée centrale de gestion de notre
anti-virus et un outil de maintenance automatique de nos copieurs.
J’ai motivé mon tuteur à se sensibiliser à la virtualisation, la décision a été prise de
virtualiser ces services à moindre cout, avec l’utilisation d’un poste de travail correctement
dimensionné et le logiciel VMWare Workstation8. J’ai pu effectuer l’intégration de ces
services et permettre leur sauvegarde.
2.3.6
Equipements réseaux
La partie réseau est à la charge de notre FAI et notre service informatique central du siège,
nous ne gérons que les switchs sur lesquels j’ai pu mettre en place le spanning tree et
effectuer des redondances de liens entre équipements.
Page(s) 94/97
Annexes
Bilan personnel
2.3.7
Supervision
J’ai eu la liberté de mettre en place un système de supervision (sujet de mon PFE)
composé principalement de Nagios, Cacti et OCSinventory (bundle Eyes Of Network).
Chaque équipement est ainsi supervisé à partir d’une console centrale, des tests de
disponibilité de service et du matériel sont effectués.
De plus la capacité de chaque équipement est répertoriée avec des graphes de
performances.
Les journaux d’évènements sont également centralisés sur le démon Rsyslog, un outil
permettant de les rendre compatible au format syslog a été déployé sur les serveurs.
Chaque problème est notifié par mail à mon tuteur et moi-même afin d’améliorer la
réactivité du service informatique.
De plus des agents OCSinventory ont été déployés sur les clients afin d’offrir une base
dynamique du parc et l’état des logiciels installés. L’outil de télédéploiement a également
été configuré et utilisé pour le déploiement non brutal et silencieux d’applications.
Page(s)95/97
Annexes
Références
3
REFERENCES
http://www.eyesofnetwork.com
Documentation et forum d’entraide du développeur de la suite logicielle.
http://nagios.org
Site officiel du développeur qui regroupe de la documentation
http://exchange.nagios.org
Communauté Nagios permettant la recherche de scripts personnalisés
http://www.ocsinventory-ng.org/fr/
Site officiel du développeur
http://wiki.monitoring-fr.org
Site regroupant des procédures et des aides à la supervision
http://www.nsclient.org/nscp/wiki/WikiStart
Documentation sur la configuration du client NSClient++ ainsi que les commandes
reconnues par l’agent
Page(s) 96/97
Annexes
Lexique
4
LEXIQUE
DNS : Domain Name System : le DNS est un service permettant d'établir une
correspondance entre une adresse IP et un nom de domaine
AD (Active Directory) : Annuaires des comptes d’un domaine Windows
DHCP : Dynamic Host Configuration Protocol est un protocole réseau dont le rôle est
d’assurer la configuration automatique des paramètres IP
UDP/TCP : Protocoles de communication réseau
GPO (Group Ploicy Object) : Politique de sécurité appliquée sur des postesou des
utilisateurs
SSH : Secure Shell est un protocole de communication sécurisé
SNMP : Simple Network Management Protocol, est un protocole de communication qui
permet aux administrateurs réseau de superviser les équipements du réseau
MIB (Management Information Base) : Sert à faire la translation d’un OID en un nom
compréhensible.
OID : pour Object Identifier sont des identifiants universels, représentés sous la forme
d'une suite de numéro. Ces identifiants vont nous permettre d’obtenir une information sur
l’état d’un élément supervisé.
ITIL (Information Technology Infrastructure Library) : Bonnes pratiques préconisées pour le
management d’un système d’information
SLA (Service Level Agreement) : Accord de qualité de service entre un prestataire et un
client
CMDB (Configuration Management DataBase) : Base regroupant les informations d’un
système informatique
GTR (Garantie de temps de rétablissement) : délai dans lequel un service accidentellement
interrompu doit être rétabli
Page(s)97/97
Annexes

dossier d`initialisation de projet

Transcription

Documents pareils

cable RS232

HP Wireless LAN Remote Assessment and Design Service

Il y a des instants dans l`existence qui ne s - UNI

Accompagner la transformation du client entreprise

LYON / Le Carré Saint Vincent

Vic Vogel, Cubamanos, Ian Kelly et Randy Bachman www

La solution ProCurve de Metafore a placé la barre plus haut

RÈGLEMENT DE LA LAN-PARTY DU 6 juin 2009 À BELMONT DE

Les 17 et 18 février 2007, dans la salle des fêtes de - GGG`lan

Hommage aux migrants naufragés en Méditerranée A Gruissan