En informatique, comme pour beaucoup de choses, on finit par être à l’étroit dans l’existant. Peut-être un peu plus vite en informatique que dans les autres domaines. Se pose alors toujours le choix entre mieux gérer l’existant versus investir dans une nouvelle solution / faire une upgrade.
Mieux gérer l’existant
Ce choix est plus courageux que le deuxième, mais aussi plus risqué. Il revient à dire que pensez pouvoir faire mieux que ce qui a été fait depuis le début. Cela se caractérise en général par du temps à passer, avec un gain difficile à estimer à l’avance. Je pense qu’il faut l’essayer en premier car:
- Il va potentiellement générer des économies, même s’il est insuffisant et qu’il faille quand même investir.
- Il permettra de mieux comprendre le besoin en passant en revue les usages, et donc de justifier l’investissement éventuel.
- Il montre qu’on ne se contente pas « d’investir ».
Le principal est de se fixer un objectif en termes de délai et de charge pour produire un résultat. Il ne devrait cependant jamais dépasser un certains % que coûterait la deuxième solution.
La demande en ressource informatique croit inexorablement dans les entreprises. Les projets les plus stratégiques font normalement l’objet d’un « capacity planning » permettant de s’assurer que la solution tiendra les fameux 3 ou 4 ans de son amortissement. Il y a cependant quelques parents pauvres qui bénéficient rarement de ce traitement:
- Le stockage de fichiers bureautiques,
- Le stockage des mails,
- La consommation réseau (inter sites, et Internet).
Demander le ménage dans les fichiers bureautiques revient à ramer dans le désert. Tout le monde estime avoir mieux à faire, mais personne n’a envie de payer le prix que cela coûte (stockage central €MC / N€tApp, sauvegarde…). Face à l’hémorragie, des solutions soit disant « miracle » ont vu le jour (archivage 3 tiers, déduplication, SharePoint…). Ce dernier permet l’indexation, ce qui est presque le pire. Où comment s’y retrouver dans un capharnaüm sans ranger sa chambre. Non seulement les utilisateurs ne veulent plus supprimer les vieux fichiers, mais ils ne veulent plus classer non plus…
Heureusement, on peut transformer le virus en vaccin : chercher les mots salaires et primes. Résultats garantis!
Le réseau fait partie des investissements « lourds » qui fonctionnent par palier. Le stockage et la sauvegarde en font également partis. Des solutions existent depuis pas mal de temps, vu que c’était le premier point de contention dans les entreprises en général:
- QOS : permet de gérer l’intérieur du tuyau : garantir des flux, en restreindre d’autres,
- Compression : Riverbed & co. Espérer que les données sont redondantes et faire l’équivalent d’un « zip » des flux réseaux.
En réponse à tout cela, je propose deux approches en parallèle:
- Vérifier que les bonnes pratiques « minimum » sont appliquées
- Outiller la DSI pour pouvoir faire de la refacturation interne.
Quelques bonnes pratiques ayant fait leurs preuves:
- Les flux http/https sont compressés par les serveurs Web et proxy,
- Les réplications (DFS, SQL…) inter sites sont faites pendant les heures creuses ou avec la gestion de bande passante intégrée,
- Privilégier l’envoi de Delta plutôt que complète,
- Chercher les fichiers les plus volumineux,
- Bloquer dès le départ plutôt qu’a posteriori (fichiers multimédias…),
- Mettre des quotas pour gérer des croissances non prévues. Même si le blocage ne sera pas maintenable.
- Noter toute solution « temporaire », en identifiant le demandeur, la raison, et la date de suppression,
- Mettre des sécurités (alerte/blocage) en dessous des valeurs réellement bloquantes.
- Après une mise en production, revalider le capacity planning initial.
Lors de besoins pour un projet spécifique, il est souvent facile d’identifier le motif des coûts. Cela est plus difficile quand il s’agit de la connexion Internet ou du stockage. Les outils de refacturation permettent d’objectiver la consommation. Même si la refacturation interne ne sera pas faite, elle permet d’identifier clairement les consommateurs, et de ventiler le coût de la prochaine upgrade.
Investir
Cette solution permet d’avoir, de manière presque certaine, une réponse immédiate à un problème ou à un besoin. Sur certains sujets, comme les fichiers bureautiques, il permet de ne pas s’attirer les foudres des utilisateurs, surtout quand ces derniers n’hésitent pas à comparer avec le prix d’un disque de 1To chez le marchand du coin. Cependant il y a des cas où ce choix n’apporte pas les gains escomptés. C’est notamment le cas avec les problèmes de performances, où acheter un deuxième serveur ne veut pas forcément dire deux fois plus vite.
L’investissement est souvent favorisé car il permet également d’avoir des ressources pour mener les actions. Si vous souhaitez optimiser votre infrastructure virtuelle, vous aurez peut-être du mal à obtenir un budget, tout au plus pour un audit. Alors que si vous faites un projet avec de nouveaux serveurs et une montée de version, on vous donnera le budget pour cela, avec les jours hommes qui vont avec. Cela est dû à la difficulté d’afficher des gains avant de faire l’optimisation.
Conclusion
Je recommande les actions suivantes pour le « label » DSI++:
- Avoir les indicateurs clés de saturation. Ceux-ci doivent être suffisants pour avoir le temps de mener une phase d’optimisation. Sinon on se retrouve dos au mur et l’investissement sera systématiquement retenu.
- Demander l’exercice de chiffrer la consommation de ressources dans les projets. Profiter des montées de version pour inclure cet exercice sur l’existant. Vérifier à posteriori la différence entre le prévu et le réel. Les chiffres sont tout aussi intéressants que la prise de conscience des personnes sur l’impact de leur projet.
- Quand une solution à un problème de consommation est identifiée dans un projet (activer la compression http), l’inclure dans des normes et standard, afin qu’elle soit généraliser « par défaut ».
- Implémenter des outils de refacturation sur les éléments partagés et ceux où le consommateur n’est pas clairement identifiable.
- Vérifier que des graphiques de consommation sont bien disponibles sur les éléments clés de l’architecture : stockage, réseau, processeur, mémoire. Ce n’est pas quand il y aura une saturation que ces graphes doivent être mise en place.
- Ramener le prix du stockage central au Go. Cela permet facilement une prise de conscience lors des demandes. Idem pour le réseau.
- Remettre en cause les choix du passé lors des renouvellements d’architecture. On fait certains choix en fonction:
- D’un contexte,
- De l’état des technologies (maturité, coût, connaissance),
- De choix du groupe,
- du budget.
Parfois c’est même d’autres personnes qui ont fait ces choix sur l’architecture actuelle. Il moins engageant de « juste renouveler », mais cela vous enferme indirectement dans des choix limités pour la suite.