Si j’étais DSI…
3 septembre 2016
Du haut de mes 27 années d’expérience dans l’informatique professionnelle, je voudrais aux jeunes DSI – qui pourraient être amenés à me lire – prodiguer ces quelques conseils. L’illusion de leurs aînés est de croire qu’ils continueront d’exister au travers de leurs budgets et de la gabegie financière à laquelle ils continuent de se livrer aujourd’hui tout en assurant une piètre qualité de service.
Le choix d’architectures matérielles non propriétaires
Compte tenu des prix et d’un changement profond des infrastructures de stockage gérées au travers de baies SAN, je ne vois pas l’intérêt d’architectures matérielles propriétaires telles que les IBM Power Systems exécutant un système AIX. Leur intérêt résidait sur la vitesse du traitement des IO disque du fait de la présence de processeurs dédiés. Ce type de matériels coûte cher à l’achat et en termes de maintenance pour un gain de performances très incertain du fait que ces matériels sont souvent sur-utilisés en vue de les rentabiliser.
Stockage
Là-encore, compte tenu des différences de prix et ce malgré des performances en sa faveur, le Fiber Channel représente un coût exorbitant en rapport aux gains qu’il apporte vis à vis de l’iSCSI. L’émergence de l’IEEE 802.3ba 40 et 100 Gbits finira d’enterrer cette technologie !
Par les économies réalisées du fait du choix de l’iSCSI, je dédierais les baies :
- une baie pour la sauvegarde,
- une baie pour le partage de fichiers,
- une baie pour les machines virtuelles exécutant les applications,
- une baie pour les données des bases de données.
Il faut aussi penser à libérer des moyens pour le PRA.
Un choix délibéré pour l’Open Source et l’internalisation
Je ne comprends pas le choix excessivement coûteux en faveur d’infrastructures Vsphere ESXi alors qu’il existe Proxmox, une solution de para-virtualisation Open Source à base de KVM et de QEMU. Pour les serveurs Windows, les économies de licence m’amèneraient à aller vers Hyper-V. Pour les serveurs d’applications sous Linux, je regarderais vers Docker !
En ce qui concerne la supervision SNMP des switchs et des routeurs, j’opterais pour Zabbix, dont le potentiel et la simplicité me semblent bien supérieurs à Nagios / Centreon. Concernant la gestion de parc et le ticketing, je ferais sans hésiter le choix de GLPI / FusionInventory ! Pour le SIEM, je choisirais Beats / Kibana / Logtash / Elastic Search.
Je tâcherais de mettre en œuvre Samba en lieu et place d’Active Directory. L’accès aux applications métiers s’exécutant sur des serveurs RDP se ferait à partir de Raspberry Linux disposant de rdesktop. Le déploiement des stations de travail sur les ordinateurs portables et les Desktops serait assuré par CloneZilla ! Pour la messagerie, je retiendrais, côté serveur, Postfix pour le serveur d’envoi et Dovecot pour le POP/IMAP. Côté client, c’est Thunderbird avec l’extension Lightning qui serait utilisé pour le partage d’agendas. Dans un souci de protection des données personnelles, Google Chrome serait strictement interdit ! LibreOffice serait préféré à la suite Microsoft.
Squid couplé à SquidGuard prendrait en charge l’activité proxy. Les sauvegardes se feraient exclusivement à partir de scripts réalisés par les équipes DBA et Système. Donc pas de solution de sauvegarde de type BackupExec, Time Navigator ou Calypso. Quant à la gestion des fichiers de configuration (Puppet, Ansible), je n’en vois pas l’intérêt !
Organisation des services
La DSI sera organisée en trois pôles :
- un pôle métier regroupant les DBA, la BI, les développeurs, les équipes « projets », chargés d’établir les pré-requis nécessaires au fonctionnement des applications et les procédures de sauvegarde des données (DBA) dont ils auraient l’exploitation,
- un service support (1er niveau), chargé par ailleurs du déploiement du parc (Desktops, portables, mobiles),
- un pôle système et réseau, incluant le stockage, la téléphonie et la sécurité, chargé du déploiement, de l’exploitation et de la supervision, dont l’objet est d’être avant tout au service des deux autres pôles et de l’utilisateur.
Le choix de la transversalité et de la transparence
Afin de faciliter la transparence, les bases de connaissances et la CMDB seraient pris en charge au travers des notes, des bases de connaissances et de la FAQ partagé entre les trois pôles dans GLPI. Elles devront être à jour par rapport à la réalité de l’exploitation quotidienne.
Dans un souci de transparence, tous les techniciens de la DSI auraient un accès aux informations issues du SIEM et de la supervision. L’objectif, très clairement, est de décloisonner.
Des groupes agiles seront créés sur tous les sujets transversaux comme la sauvegarde, le système documentaire, la gestion des droits et des mots de passe.
Je reste à votre disposition pour toute aide à la MOA ou à la MOE sur ce type de projet.