Si j’étais DSI…

Si j'étais DSI...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 :

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 :

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.

Infrastructure  / DSI Elastic Search GLPI ITIL Kvm Lightning QEMU Thunderbird Zabbix 

Commentaires

Totalement en accord avec cette article.
Mais l’évolution de l’informatique en entreprise change la donne.

Le DSI ne fait que gérer les appels d’offres, les contrats, le renouvellement du parc, son budget annuel.
Il ne connait plus l’informatique car il ne la pratique plus, faute de temps. Perte de temps en réunions stériles, comme partout.
Il n’a une vue que sur ce que les publicités proposent, les modes proposent, et aussi… ce que le commercial propose.
Et le commercial vendra tout et n’importe quoi, mais surtout ce qui lui permettra de faire de la marge, ou qui lui offrira le dernier PC/Tablette/Téléphone à la mode, ou le voyage d’une semaine à Las Vegas pour le Kick Off Partner Dinner d’une marque.
Et derrière, les ingénieurs du prestataire feront leur possible avec ce qui a été vendu, même si une autre solution aurait été plus simple, moins coûteuse et surtout plus appropriée.
Il en est de même avec le DSI et le commercial qu’avec Lucas et son port //.
C’est quoi Promox? C’est quoi PfSense? C’est quoi GLPI? …
On vend du VMWare, du Fortigate, du ISIlog,…
En contre partie, on liquide les informaticiens de la boite, on garde le DSI et tout le reste est sous traité par un prestataire.

La faute ne revient pas aux DSI, mais essentiellement à l’organisation des entreprises qui sous estiment l’importance du personnel informatique en son sein, et de l’outil informatique.
Un commercial ne répondra pas aux attentes d’un DSI. Le DSI doit venir avec ce qu’il veut, pas attendre la proposition du commercial.

Pour modifier ou imposer ces solutions dans une entreprise, il faut être là à l’origine de sa mise en place, et avoir les ressources en interne pour les gérer.
Car peu de SSII iront dans ce sens, privilégiant la marge du commercial à court terme, face à l’apport (financier et technique) que représente à moyen terme les outils ‘libres’.

@Cedric

Il y a beaucoup de DSI qui sont devenus des mercenaires et dont le seul objectif est de réussir leur plan de carrière. Ils existent au travers des budgets qu’ils consomment… euhhh qu’ils consument. On ne peut pas balayer d’un revers de la main leur responsabilité personnelle.

Entièrement d’accord avec ton analyse, Cédric.

Bonjour Denis,

Merci pour cet article, mais je pense que le choix de certaines solutions s’effectue aussi selon les fonctionnalités offertes, et il y a des produits payants plus évolués bien des produits OpenSource. Tout dépend des besoins et de ce que l’on veut en faire.

Je pense qu’il faut trouver un compromis entre l’utilisation des produits libres et des produits qui ne le sont pas. D’ailleurs ce n’est pas mentionné mais j’imagine que les postes dépende secure travail doivent tourner sous Linux ? Quelle distribution ?

Pour revenir sur Ansible & Co, ce sont des produits très utile dans l’automatisation des tâches et pour simplifier la gestion des configurations. Si on a besoin de déployer 5 nouveaux serveurs Web, et qu’on peut automatiser ce déploiement en déployant une configuration pré-etabli c’est quand même agréable non ? Et ça fait gagner du temps et de l’efficacité :-)

Bon dimanche
Florian

Bonjour,

J’aimerai bien entendre vos arguments pour l’absence d’un Ansible/Salt/Chief. (Si je ne met pas Puppet, c’est surtout parce que c’est une grosse machine à gaz). Je trouve que vous êtes vite passé sur ces outils qui sont simples et permettent d’automatiser une bonne partie de la production, que ca soit en déploiement applicatif ou préparation système.

Kat

@Florian

Aujourd’hui, Linux – depuis l’abandon du filtrage par process depuis le noyau 2.6.14 – ne permet pas d’assurer une sécurité suffisante ! Pour des postes de travail exigeant sur le plan de la sécurité, ça ne peut être que Windows ou Mac OS X. Je ne suis pas un ayatollah du libre, sachant qu’à l’image du commentaire de Cédric, je pense qu’il faut privilégier l’emploi à l’achat de licences à des sociétés américaines qui creusent nos déficits ! ;+)

@Katyucha

Je ne connais pas particulièrement Salt et Chief. Pour le reste, des scripts peuvent très bien faire l’affaire !

Bonjour, votre article est intéressant. Quelques remarques/questions :
– sauf erreur samba n’est pas un annuaire comme AD
– combien de personnes dans la DSI pour combien de serveurs/utilisateurs ? (Vu l’utilisation de scripts etc ça va prendre du temps)

@Matthieu

La version Samba 4 permet de gérer les GPO : http://linuxfr.org/news/samba-se-met-enfin-en-4-0-et-prend-en-charge-les-ad

J’étais resté sur un ratio de 1 tech pour 300 users dans la partie réseau-système-dba. Ensuite, ça dépend beaucoup du choix – ou non – du développement interne. Et puis, il y a la sous-traitance pour ajuster !

Justement des « scripts », j’ai toujours remarqué que c’était TOUT et n’importe quoi. La plupart des scripts sont illisibles 6 mois plus tard. Avec Ansible ou Salk (les deux que je connais le mieux), c’est lisible sur le long terme. Franchement, je trouve ça indispensable maintenant

Laisser un commentaire

(requis)

(requis)