Fonctionnement aléatoire de la connexion d’un système informatique à d’autres systèmes, plantages intempestifs, incapacité de l’infrastructure à passer à l’échelle et non-respect du cahier des charges… Autant de problèmes qui nécessite une remise à plat de l’infrastructure, afin de mettre le doigt sur la source de l’erreur. Ou dit autrement, qui nécessite un état des lieux technique du SI appelé audit d’infrastructure. Benjamin Romeo, expert DevOps et Architecte Cloud, nous explique les bienfaits d’une telle démarche qui peut parfois s’apparenter à de la rétro-ingénierie.
Dans quel contexte faire un audit d’infrastructure ?
Il faut déjà savoir que la plupart des clients ne demandent pas d’audit. C’est en partant d’un autre sujet à traiter pour eux (mon infrastructure rencontre une défaillance, elle ne fait pas ce qu’elle est censée faire, ou ne permet pas de faire ce que je voudrais) que le besoin d’audit se fait jour. Car pour savoir ce qu’il faut faire, il faut d’abord savoir ce qui se passe ! Deux cas de figure se présentent alors. Le premier : le client pense bien connaître son infrastructure et sait où il veut aller. Le second : le client est un peu perdu, connait mal son infrastructure ni les actions à mener pour améliorer celle-ci. Et avec l’expérience, nous nous rendons compte que souvent ces deux contextes n’en font qu’un : l’écart entre ce que pense posséder le client et la réalité technique peut être important. Dans ce cas, nous parlons « d’un audit de delta », qui mesure l’écart entre le déclaratif, l’attendu et l’existant. Il faut se rappeler qu’un audit d’infrastructure est le résultat d’une documentation qui est souvent mal faite, non maintenue, obsolète voire inexistante. De fait, il est parfois plus rapide de faire un audit complet que ciblé, en partant du principe que ce qui est fourni (et manquant) interdit d’établir un état satisfaisant de l’infrastructure. Dans ce contexte, nous ne sommes proches d’un travail de rétro–ingénierie. Car, avant d’attaquer la résolution d’un problème, il est nécessaire de posséder un point de départ fiable.
Comment se déroule un tel audit d’infrastructure IT ?
Basiquement une infrastructure IT tient sur 3 piliers : le réseau, la virtualisation et le stockage. Pour la mise en œuvre de l’audit, tout dépend du problème relevé par le client. S’il s’agit d’un problème réseau, l’audit va logiquement analyser la partie réseau. S’il y a un problème d’application, l’audit va chercher à comprendre comment est hébergé cette dernière, et ce qui l’a fait tourner (une machine virtuelle ou K8S par exemple). S’il y a un problème de benchmarking, la cause vient peut-être de la performance des disques de la partie stockage et de la montée en charge, etc. La bonne démarche est donc d’attaquer par le pilier d’infrastructure qui a le plus de probabilité d’être en cause. Pour autant, l’expérience fait que le pilier qui est incriminé en premier n’est pas forcément le fautif : nous pouvons par exemple partir d’un problème applicatif pour découvrir qu’il s’agit d’un problème réseau. Dans tous les cas, un audit demande de passer par les 3 piliers. Il s’agit simplement d’être le plus efficace possible et de trouver la cause du désordre pour y remédier rapidement. Et pour être complet, en dehors de ces piliers « purement infra », il faut également penser à observer l’écosystème qui gravite autour, avec par exemple le monitoring pour le Cloud, les usines logicielles, etc.
Est-il juste de dire qu’un audit ressemble à une enquête ?
Je pense plutôt qu’un audit s’apparente à tracer une carte de l’infrastructure la plus précise possible, prérequis pour trouver l’emplacement exact du problème. Personnellement, je commence par tout poser à plat, en faisant un listing de tout ce qui est en place. Une fois que j’ai achevé la récolte de toutes les informations qui m’ont servi à faire des diagrammes d’infrastructure, je peux commencer à pointer tout ce qui n’est pas standard, aux normes, dans l’état de l’art... Bref, tout ce qui est « anormal » va m’aider à me faire une première hypothèse et savoir où chercher… Et parfois mettre à jour de nouveaux problèmes non détecté par le client. Comme un problème peut en cacher un autre, s’attacher à résoudre uniquement l’incident pour lequel le client est venu est peu efficace. Le risque : voir un autre problème engendrer un effet similaire. L’audit permet de disposer d’une vision réellement complète de l’infrastructure, pour remédier aux problèmes existants, déjà identifiés ou non, et prédire de prochaines complications. En effet, si un élément d’infrastructure fonctionne à un instant T, mais qu’il a été mal conçu, il peut cesser de fonctionner à plus ou moins court terme. Ce qui est surtout vrai avec le pilier réseau. Un audit propose donc, en plus d’un état des lieux, des préconisations pour faire en sorte que le fonctionnement d’une infrastructure IT soit efficient dans le futur.
As-tu un exemple concret d’audit ou d’étude à nous donner ?
L’audit d’infrastructure que j’ai mené pour une PME œuvrant dans le domaine de l’imagerie médicale est très représentatif de l’utilité d’une telle démarche. Initialement, la société s’est rapprochée d’Inside pour régler une complication réseau. Donc le problème était déjà identifié. J’ai alors découvert dans un premier temps que les spécifications étaient « étranges », avec des termes qui ne correspondaient aucunement à ce qui attendu pour une infrastructure IT. De plus, la documentation comportait beaucoup d’anomalies, et il n’y avait aucune chance qu’elle puisse être à jour. Ainsi, le delta entre ce qui est énoncé par le client, ce qui est en place et ce qui est documenté, s’est avéré tellement grand que la résolution du problème était impossible sans le recours à un audit. Nous nous sommes alors rendu compte de l’étendue des « dégâts », avec des bouts de configurations inachevées, des sections entières non écrites, des trous dans les parties documentées… De fait, l’infrastructure qui fonctionnait déjà mal allait à moyen terme (environ 2 mois) ne plus être en mesure de répondre aux besoins du client. Ainsi, le projet qui ne visait qu’à la résolution d’un simple problème réseau s’est transformé en une refonte complète du SI !
Comment Inside accompagne ses clients sur ces enjeux d’audit d’infrastructure ?
Inside peut proposer des audits techniques d’état dans le cadre de migration ou de fusion, et des audits d’infrastructure sur les 3 piliers : réseau, virtualisation et stockage. Nous pouvons ainsi accompagner nos clients qu’elle que soit la typologie d’infrastructure : Cloud, hybride, bare metal et On Premise. Nous pouvons aussi réaliser des études sur des aspects spécifiques comme l’audit d’industrialisation.
Plus globalement, nos offres de services autour des enjeux d’infrastructure et d’exploitation s’organisent autour de 4 prismes :
- La compréhension et l’analyse au travers des audits
- L’urbanisation pour accompagner nos clients dans la conception d’une architecture ou d’une infrastructure complexe
- Le déploiement et le soutien en termes d’expertises, avec l’appui de nos centres de compétences
- L’évolution de votre SI depuis la définition jusqu’à la réalisation de la trajectoire de transformation
Nous adaptons bien évidemment nos prestations selon le niveau de maturité, l’organisation et l’architecture du système d’information de nos clients.
Echangeons autour de l’audit d’infrastructure !