ING5 SI Management du Système d'information Exploitation et Production ECE 2004-2005
Jean-Marie Gouarné Directeur technique, GENICORP Expert judiciaire en Informatique, Cour d'appel de Rouen jmgprof@online.fr support de cours http://jean.marie.gouarne.online.fr/ece/ece_ep.sxi
Exploitation/Production définition et rôle des "services informatiques" engagements de service organisation et management du SI architecture et urbanisme du SI
Objectif Introduction générale aux problèmes de management d'un système d'information d'entreprise
Enjeux encore un cours "littéraire"? un lien entre technique et stratégie un jargon un avertissement un point de vue sur l'environnement professionnel
Exploitation/Production Exploitation/Production: souvent liés, voire synonymes sens étroit: opérations courantes, procédures répétitives, gestion des incidents sens large: "alignement", optimisation, adaptation au changement
Exploitation/Production sens strict déploiement maintien en condition opérationnelle gestion des incidents gestion des problèmes secours, sauvegarde, restauration administration et sécurité budgets, facturation, personnel
Exploitation/Production sens large «logistique de l'information» gestion de la qualité de service et du niveau de service gestion des risques gestion du changement (procédures et techniques) gestion des partenariats, contrats (fournisseurs, intégrateurs)
Exploitation/Production une définition du périmètre http://www.institut.capgemini.fr/seminaires/exp.html
Exploitation/Production indications bibliographiques Les services informatiques, Stratégie Alignement Transformation Christian Nawrocki, Dunod, 2004 Architectures de systèmes d'information, Modèles, services et protocoles Bertrand Bruller, Vuibert, 2003
Contenu informatique et système d'information définitions et périmètres d'un SI notion de SI "opérationnel" architecture : modèles, services, protocoles, composants administration systèmes, réseaux, stockage organisation des DSI
Contenu engagements de service partenaires: constructeurs, éditeurs, intégrateurs, infogérants progiciel et externalisation les exploitants intégration des SI: middleware, ERP, EAI urbanisation
Informatique, Information les origines traitement de données (EDP) automatisation des tâches traitements planifiés cloisonnement
Informatique, Information la période intermédiaire traitement de l'information système d'information banalisation complexité administration, normes, méthodes
Informatique, Information la tendance complexité++ alignement stratégique "gouvernance" intégration
remises en question "IT doesn't matter" N.G. Carr, Harvard Business débat sur la valeur de l'informatique dans l'organisation Interrogations sur le statut et les responsabilités de l'informaticien
les «catégories» du SI applications opérationnelles vs. applications décisionnelles applications centrales vs. applications périphériques systèmes centraux vs. systèmes départementaux applications vs. infrastructure bureautique et systèmes collaboratifs, toujours en marge
les «catégories» du SI chacun de ces découpages provient d'une époque ces découpages se superposent et compliquent l'exploitation du SI ils influent sur l'organisation des équipes d'exploitation (tout choix technologique a un impact social)
opérationnel / décisionnel l'information opérationnelle est liée au fonctionnement immédiat de l'organisation ; elle évolue en temps réel ; elle est transactionnelle l'information décisionnelle sort du système; elle est instantanée ou historique; elle est livrée à l'utilisateur à des fins de reporting, d'analyse, de prévision
applications centrales applications périphériques application centrale: liée au coeur de métier (core business), aux fonctions considérées comme les plus critiques application périphérique: liée à un développement du métier, jugé annexe ou non critique
applications centrales applications périphériques des normes d'exploitation, des environnements techniques et des cultures divergentes distinction historique et politique, donc susceptible de remise en question interdépendance croissante importance vitale de certaines applications périphériques
applications centrales applications périphériques un exemple tenue de compte bancaire : application centrale banque à distance : application périphérique
systèmes centraux, systèmes départemenaux ne pas confondre avec applications centrales/périphériques vocabulaire conventionnel, un peu périmé mais toujours en vigueur central = «mainframe», système dit «propriétaire» (MVS, GCOS) départemental = plate-forme intermédiaire, système ouvert ou non (Unix, AS/400, VMS,...)
systèmes centraux, systèmes départemenaux longévité inattendue du mainframe propriétaire; consolidation autour de l'offre IBM (de MVS à z-os); intégration du central et du départemental dans des architectures d'administration mutualisées standardisation des protocoles
systèmes centraux, systèmes départemenaux montée du «mainframe» sous Unix super-serveurs spécialisés (ex: NCRTeradata dans la BI, Fujitsu-Siemens dans le multimédia) Linux sur mainframe (IBM zseries)... dilution du découpage traditionnel, mais résistances culturelles
applications, infrastructure application = composant ou ensemble logiciel répondant à un besoin directement lié au métier principal de l'entreprise infrastructure = ensemble des équipements matériels et logiciels destinés à permettre et à contrôler le fonctionnement des applications
applications, infrastructure l'exploitation d'une application intéresse directement un «client» de la production informatique l'infrastructure n'intéresse le «client» qu'à travers son impact sur les applications la gestion de l'infrastructure est de nature «technico-politique» certains éléments du SI sont inclassables
applications, infrastructure zones floues l'application impose souvent l'infrastructure progiciel (ERP, CRM,...) applications «horizontales» bureautique, collaboration,... applications «transversales» EAI,...
bureautique historiquement réputée «non critique» ; intégration tardive et imparfaite dans le SI développement hors des normes classiques d'exploitation/production explosion des coûts DSI en position de faiblesse: pouvoir individuel de l'utilisateur, fournisseur imposé
bureautique considérée (à tort) comme élément de l'infrastructure partie la plus visible du SI produit la majeure partie des flux et des stocks de données renferme une part essentielle des connaissances et des engagements de l'entreprise... mais zone la plus «ingérable» du SI
systèmes collaboratifs immédiatement visibles pour le «client», mais non dédiés à des métiers particuliers impliquent une logique de gestion des utilisateurs et des ressources distincte de celle des applications «classiques» offres concurrentes, pas de standard (Microsoft, IBM, Oracle,...)
modèles d'architecture l'exploitation d'un SI contemporain est caractérisée/compliquée par la cohabitation de plusieurs modèles d'architecture centralisé client-serveur distribué
architecture: définition flux de données moyens d'accès moyens de traitement moyens de stockage moyens d'archivage logiciel d'application logiciel d'exploitation services
architecture et exploitation l'architecture du SI détermine ses conditions d'exploitation la cohabitation de plusieurs modèles d'architecture est le premier facteur de complexité de l'exploitation
architecture : modèle centralisé traitement et accès aux données sur une machine physique liaison point à point entre chaque poste de travail et machine physique capacité de traitement du poste de travail réduite ou figée
architecture : modèle client-serveur initialement conçu pour réduire les coûts; en pratique, principale cause d'explosion des coûts mode «requête-réponse» traitements à l'initiative du client liaison point à point plusieurs sous-modèles
client-serveur de données client réseau serveur requête SGBD application réponse
client-serveur de traitement client réseau serveur requête application application réponse SGBD
architecture : modèle distribué/réparti généralisation du modèle clientserveur mise en oeuvre de plusieurs composants pour une requête implique un service répartiteur central («bus logique») distribution des données et/ou des traitements
données distribuées SGBD local requête SGBD réparti application SGBD local réponse SGBD local
traitements distribués peer to peer application application application application
traitements distribués répartiteur/hub application application application application connecteur connecteur connecteur connecteur bus services communs
traitements distribués : problèmes RPC (remote procedure call) transactions distribuées messages objets distribués services processus
RPC appel de procédure/méthode à distance vu comme un appel local par le client (interface locale) implémenté comme un service (boucle d'attente infinie, écoute sur un port logique)
messages implémentation pratique des RPC ordonnancement et routage assurés par un MOM (message oriented middleware) encodage, décodage, format pivot usage grandissant du XML
transactions distribuées unités logiques de travail entièrement validées ou annulées (COMMIT, ROLLBACK) «two phase commit»
objets distribués technologie objet basée sur les RPC s'appuie sur des serveurs d'application interfaces publiques, services d'annuaire et de routage, implémentation «virtuelle»
objets distribués CORBA (Common Object Request Broker Architecture) Java DCOM (Distributed Component Object Model)
services service = ensemble cohérent de moyens, accessible selon des modalités convenues, assurant une fonction donnée, activé sur requête du client accès par URL et numéro de port objet ou non implémentation à base de RPC
architecture de services client consulte utilise annuaire - chemins - interfaces publie service
services web utilisation du service: SOAP (Simple Object Access Protocol) annuaire: UDDI (Universal Description, Discovery & Integration) description des interfaces: WSDL (Web Service Definition Language) lecture : http://www.w3.org/tr/ws-arch
processus enchaînement d'activités mis en oeuvre par un événement déclencheur et produisant un résultat identifié ensemble cohérent de transactions impliquant une combinaison de services nécessite une «chorégraphie» et une supervision
architecture des services web source : W3C
architecture de stockage stockage # archivage média disque magnétique disque optique (DVD) bande magnétique protocoles d'accès IDE SCSI sûreté : RAID
supports physiques Capacité (Go) Disque magnétique Disque optique Bande magnétique Coût ( /Mo) Temps d'accès (s) 100 0,20 0,002 10 0,10 5,000 100 0,05 10,000 (2003)
interfaces d'accès aux supports IDE (Integrated Device Electronics): connexion directe à la carte mère; autorise le DMA (Direct Memory Access); économique, propre au PC, peu extensible SCSI (Small Computer System Interface): virtualisation des périphériques; requêtes simultanées, extensibilité; encapsulable dans des trames IP (iscsi); standard ancien
stockage à distance SAN (Storage Area Network): unités de stockage attachées par réseaux spécialisés (fibre optique et routeurs) haut débit (100 Mo/s par lien); haute disponibilité NAS (Network Attached Storage): unités de stockage attachées par réseau IP non dédié; formats de fichiers hétérogènes (NFS, CIFS); mise en oeuvre plus simple
administration composant central de l'exploitation pilotage continu de la production supervision suivi des engagements de service audit, facturation
«disciplines» d'administration configurations incidents performances sécurité comptabilité
gestion de configurations inventaire des équipements (noeuds de réseau et moyens de communication) inventaire des licences logicielles paramètres et options d'installation de chaque composant localisation topographique et topologique des composants
gestion de configurations enjeu comptable/fiscal : connaissance du patrimoine (immobilisations), imputation analytique des charges enjeu de qualité de service : maintenance et support standardisation : modèle DMTF (Desktop Management Task Force)
gestion des incidents gestion des procédures de prise en charge d'incidents : ouverture, traitement, fermeture alimentation des bases de connaissances techniques statistiques de niveau de service
gestion des incidents la procédure ouverture : appel entrant (help desk) ou alerte automatique, qualification du problème, renvoi à l'entité compétente (interne ou externe) traitement : «escalade», aide à distance, intervention sur site ou expédition du composant défectueux fermeture : sur compte-rendu validé si appel entrant; archivage
gestion des incidents les difficultés organisationnelles absence ou dysfonctionnement du help desk centralisé (recherche de l'interlocuteur qualifié) multiplicité des intervenants internes (cloisonnement des compétences) intervenants externes
gestion des incidents le cas des logiciels externes absence d'obligation de résultat pour les éditeurs de logiciels nécessité et difficulté de la «reconstitution d'incident» interdépendance de logiciels de fournisseurs différents logiciel libre et «escalade communautaire»
gestion des incidents les 3 niveaux d'impact d'un incident indisponibilité du composant indisponibilité du service conséquences fonctionnelles indirectes
gestion des performances suivi du trafic associé à chaque ressource identification de la ressource critique (goulot d'étranglement) pour chaque type de problème
gestion des performances indicateurs fondamentaux matériel : % CPU, % mémoire centrale, swap, E/S, trafic par segment de réseau, % de collisions réseau, % occupation disques,... logiciel (serveurs) : nombre de sessions, nombre de requêtes, % de rejets, plans d'exécution
gestion des performances objectifs et problèmes respect des engagements de niveau de service (service level agreements) calcul économique (rapport coûts/performances); éviter l'optimisation sans objectif optimisation ou ajout de ressources? négociation avec les équipes de développement (performances applicatives)
gestion de la sécurité rappel des thèmes de sécurité contrôle d'accès, confidentialité, identification/authentification, intégrité, non-répudiation application des procédures de sécurité journalisation et imputation des événements relatifs à la sécurité
comptabilité toute ressource informatique a une valeur économique l'utilisation d'une ressource est éventuellement facturable l'imputation analytique des coûts d'utilisation d'une ressource (par utilisateur, application, service,...) est toujours utile
architecture d'administration un modèle commun : gestionnaire/agent un standard de fait : SNMP
modèle gestionnaire/agent le gestionnaire est une application centralisée un agent est un composant logiciel autonome attaché à chaque objet supervisé chaque agent peut être interrogé (en mode client-serveur) par le gestionnaire un agent peut envoyer un message non sollicité au gestionnaire (alerte)
modèle gestionnaire/agent le modèle est ancien et vient de l'administration des réseaux il s'est généralisé à tous les objects administrables les ressources sont: unités centrales, périphériques (stockage, impression), équipements de communication (routeurs, hubs, PABX,...), logiciels serveurs, logiciels d'application
modèle gestionnaire/agent ressources et agents un agent par noeud de réseau adressables ressources matérielles non adressables : gérées par l'agent attaché au noeud adressable auquel elles appartiennent ressources logicielles : nécessitent des connecteurs, agents moins bien intégrés dans l'architecture
gestionnaire généralement sur station de travail ou réseau de stations infrastructure d'intégration et modules applicatifs généralement, interface graphique de contrôle et d'aide à la décision générateur d'états possibilité de prédéfinir des réponses automatiques
agent contrôle les ressources appartenant à un noeud administré installé sous la forme d'un service présente au gestionnaire une interface de contrôle des variables administrées exécute les requêtes du gestionnaire peut exécuter automatiquement des actions préprogrammées
agent variables sous surveillance paramètres de configuration indicateurs d'état statistiques commentaires descriptifs
SNMP Simple Network Management Protocol modèle gestionnaire-agent origine fin des années 1980; premier standard d'administration de système et réseau; évolution (v2, v3) agents disponibles pour la plupart des ressources adressables dans un réseau IP, développés par les constructeurs choix des offres de gestionnaires (IBM, HP, logiciel libre,...)
architecture SNMP gestionnaire ressource infrastructure agent «framework» UDP UDP IP IP requêtes réponses alertes
échanges SNMP gestionnaire à agent GET-REQUEST : consultation directe de variables identifiées GET-NEXT-REQUEST : consultation séquentielle de variables GET-BULK-REQUEST : consultation en bloc des variables (v2) SET-REQUEST : modification d'une variable de la ressource supervisée (commande)
échanges SNMP agent à gestionnaire GET-RESPONSE : réponse à une requête de consultation TRAP : envoi d'une alerte à l'initiative de l'agent
MIB Management Information Base base de données associée à chaque agent représente une vue standardisée sur les variables de la ressource administrée chaque variable est un «objet» désigné par un identifiant universel (OID = Object IDentifier)
OID construits selon une logique d'arborescence premiers niveaux imposés, origine historique possibilité d'extension des branches les variables de la MIB-2 commencent par «1.3.6.1.2.1»
OID
OID
exemple OID toutes les variables relatives aux «interfaces» sont désignées par «1.3.6.1.2.1.2...» les variables définies de manière privée dans une entreprise sont désignées par «1.3.6.1.4.1...»
types de données adresse IP texte éditable (display string) compteur (counter): entier positif jauge (gauge): entier positif borné temps écoulé depuis une date de référence (time ticks) valeur quelconque (opaque) liste et table
exemple de code (Perl) use Net::SNMP; my $machine = 'une.machine.la.bas.com'; my $oid = '1.3.6.1.2.1.1.3.0'; # API Perl/SNMP # adresse ressource # uptime my $session = Net::SNMP->session ( hostname => $machine, community => 'public', port => 161 ); my $resultat = $session->get_request ( varbindlist => [$oid] ); print "La durée d'activité de $machine est égale à $resultat"; $session->close;
standard utilisés Description des variables: ASN1 (Abstract Standard Notation 1) Encodage des valeurs: BER (Basic Encoding Rules) principaux textes fondateurs: RFC 1157 (SNMP) RFC 1156 (MIB) références: http://www.ietf.org
autres modèles CIM (Common Information Model), extension de DMI (Desktop Management Interface), plus orienté «système» que «réseau» WBEM (Web-Based Enterprise Management): extension de CIM WMI (Windows Management Instrumentation): implémentation Microsoft de WBEM http://www.dmtf.org http://msdn.microsoft.com
organisation d'une DSI rôle et responsabilités production vs. études périmètre et structure sous-traitance
rôles de la DSI ordre des priorités fonctionnement courant des systèmes informatiques développement, évolution du SI stratégie de l'entreprise
fonctionnement courant exploitation-production au sens restreint «maintenance» logicielle maintenance de l'infrastructure préoccupations «informatiques» dominantes consomme la majeure partie du budget faible marge de manoeuvre
développement du SI applications maîtrise d'oeuvre (MOE) principale pour les projets applicatifs sous-traitance de MOE possible volonté d'évolution vers un rôle de «SSII interne» et une relation «fournisseur-client» avec l'utilisateur (difficultés pratiques)
rappel: MOA et MOE le maître d'ouvrage (MOA) est responsable de la spécification et de la réception du produit le maître d'oeuvre (MOE) est responsable de la conduite des travaux et de la livraison du produit conforme aux spécifications et dans les conditions convenues
développement du SI infrastructure maîtrise d'ouvrage des infrastructures maîtrise d'oeuvre principale des infrastructures (sous-traitance possible) confusion MOA-MOE et problèmes certains choix d'infrastructure sont imposés (choix d'un PGI par la direction générale)
DSI et stratégie en théorie, le DSI devrait être l'un des stratèges de l'entreprise (rôle essentiel de l'information dans la conduite des affaires) en pratique, il ne joue ce rôle qu'exceptionnellement signes extérieurs de participation: DSI membre du comité de direction et rapportant directement au DG (situation peu fréquente)
DSI et stratégie les obstacles priorité exploitation-production au sens strict rôle gestionnaire défensif (réduction des coûts) perception inégale de l'importance du SI DSI souvent en position «N-2», subordonné à une autre direction (ex: administration, finance)
études et production les «études» sont chargées du développement et de la maintenance du logiciel d'application la «production» est chargée de l'exploitation/production relations complexes et critiques dans les phases de choix techniques et de mise en production
études et production les «études» ne peuvent pas faire de choix techniques indépendants de la «production» qui devra les gérer la «mise en production» d'une nouvelle version ou d'un nouveau projet implique une procédure de livraison des «études» à la «production»; facteur de sécurité mais aussi de rigidité
subdivisions d'une DSI études et production par domaines fonctionnels ou types d'applications par branche de l'entreprise par environnement technique ces divisions varient et se recoupent différemment selon les entreprises
découpage par domaines s'applique plutôt aux études qu'à la production correspond à une «spécialisation» des équipes de développement par domaine fonctionnel les domaines correspondent souvent aux «métiers» de l'entreprise (ventes, RH, logistique...) domaines transversaux : référentiels, synthèses
découpage par branche certaines organisations ont des branches très fortement cloisonnées (métiers indépendants) ces branches ont des services informatiques plus ou moins autonomes le périmètre des DSI est alors plus complexe
découpage DSI exemple : La Poste un métier bancaire autonome par rapport au courrier : Services Financiers une Direction Informatique des Services Financiers (DISF) la DISF est autonome pour les études la production reste sous le contrôle d'une Direction de la Production Informatique (DPI) commune
découpage DSI exemple : Banque généraliste l'activité dominante est la banque de détail (produits grand public et enterprises, réseau d'agences) certains départements ont aussi des activités financières (salle des marchés, gestion privée,...) possédant une informatique spécialisée (études et/ou production)
découpage DSI exemple : GRT gestionnaire de réseau de transport d'électricité informatique de gestion informatique de conduite du réseau électrique
découpage DSI objectifs les applications «industrielles» (ou directement productives) de l'informatique sont isolées des applications de gestion l'informatique est cloisonnée de manière à ne pas empêcher une éventuelle cession d'activité
découpage DSI groupes et filiales certains groupes ont une politique informatique commune chaque filiale peut avoir une DSI indépendante la DSI du groupe joue un rôle d'orientation les décisions opérationnelles restent en général de la responsabilité des DSI de filiales
groupements de DSI coopération inter-enreprises certaines entreprises peuvent mettre tout ou partie de leur informatique en commun forme juridique : le GIE (Groupement d'intérêt Économique) exemples : caisses régionales de Crédit Agricole, Banques Populaires
sous-traitance études : sous-traitance de MOE et assistance technique production : assistance technique et infogérance
développement «au forfait» délégation complète de la réalisation, voire de la conception d'une application à un prestataire spécifications fonctionnelles à la charge de l'entreprise engagement de résultat (qualité, coût et délai) à la charge du prestataire
assistance technique (études et production) «régie» acquisition de compétences techniques auprès de prestataires extérieurs, en théorie pour appoint en pratique, des postes permanents (y compris non techniques) sont soustraités l'assistance technique est parfois une forme déguisée de délégation de personnel
infogérance sous-traitance de tout ou partie de la production informatique à un prestataire la production peut être hébergée chez le client ou chez l'infogérant l'infogérance peut couvrir jusqu'aux postes bureautiques le personnel de production peut être transféré à l'infogérant
contrats de service contractualisation des rapports entre production informatique et utilisateur nécessité évidente en cas d'infogérance, mais requise aussi pour l'informatique interne élément-clé : les SLA
Service Level Agreements accords entre utilisateurs et production informatique (interne ou sous-traitée) couvrent non seulement le niveau de service, mais aussi la qualité de service les SLA se définissent selon une démarche itérative ; domaine sensible de l'exploitation
ITIL Information Technology Infrastructure Library bibliothèque de «bonnes pratiques» d'origine gouvernementale (UK) modèle de référence pour la conduite des «services informatiques», surtout exploitation/production qualifications et certifications ITIL
ITIL «service support» configuration management incident management problem management change management help desk release management
ITIL «service delivery» service level management capacity management continuity management, disaster recovery availability management financial management http://www.itil-itsm-world.com
Fin au 13/12/2004