Branche IT du fournisseur d’énergie Total, TGITS - Total Global Information Technology Services - s’est équipée de la plateforme Ansible Automation au moment de la mise en place d’un cloud privé. Elle fournit l’informatique à l’ensemble des divisions de Total, le groupe français regroupant 100 000 salariés à travers le monde dans des activités très différentes. En se lançant dans l'automatisation, la division IT a également transformé son organisation, en la rendant plus transversale, explique François Mouraine, responsable des outils d’automatisation au sein de TGITS.

Le Monde Informatique : Dans quel contexte avez-vous mis en place chez Total une plateforme d’automatisation, en l’occurrence Ansible Automation fournie par Red Hat, et quel périmètre couvre-t-elle ?

François Mouraine : Nous avons mis en place cette plateforme dans un contexte où Total avait un fort héritage de serveurs, de services liés aux différentes branches assez complexes et nous avions la volonté de créer un cloud privé pour essayer de simplifier cela. Ce cloud privé que nous avons mis en place était basé sur une solution CloudForms pour permettre de déployer des VM avec leur OS très rapidement, en quelques minutes. Derrière, il restait toute la problématique de la post-installation qui, en général, est très complexe et très chronophage puisqu’il s’agit de créer des entrées DNS, de pouvoir déployer des agents de monitoring, de rattacher à tout un écosystème un environnement qui est propre à l’entreprise. Pour le faire, nous avons tout de suite eu besoin d’un automate et comme nous avions des ressources internes qui connaissaient très bien Ansible, nous avons démarré avec cette plateforme.

Quels sont les principaux déploiements de services IT déjà réalisés ?

La principale brique, c’est donc le déploiement de VM environnées complètes. Avec Ansible, nous avons créé différentes tâches, toute l’interaction avec le logiciel d’ITSM ServiceNow pour la mise à jour en CMDB – Configuration management database – de nos assets, toutes les post-installations d’agents, toutes les entrées que l’on peut faire vis-à-vis de Satellite avec Linux ou vis-à-vis de SCCM pour Windows... Toute cette complexité a été directement écrite en playbook Ansible jusqu’à la validation, l’acceptation de la VM et les accès du serveur aux utilisateurs. Nous livrons donc un serveur clé en main aux utilisateurs qui n’ont plus qu’à y accéder.

Quelles ont été les principales difficultés rencontrées dans la mise en place du projet ? Comment s’est-il déroulé ?

Nous n’avions pas au départ la connaissance d’Ansible Tower et de toutes ses fonctionnalités [NDLR : Tower permet de gérer les déploiements complexes, c’est l’un des trois produits qui composent Ansible Automation avec Engine et Network]. Nous avons donc commencé par mettre en place une petite plateforme Tower dans laquelle on a développé progressivement les playbooks. Au début, le service fourni n’était pas automatisé à 100%. Nous l’avons monté brique par brique pour arriver à obtenir 20, 40, 60… jusqu’à 100% d’automatisation et avons appris en marchant. Aujourd’hui, nous poussons plus loin. Tous les packages Unix sont déployés par Ansible et nous nous posons maintenant la question sur les passifs liés à Windows 2008 avec, dans ce domaine, près de 4 000 serveurs qu’il va falloir bouger. Sans automatisation, nous avons deux ans et demi de travail pour pouvoir le faire avec des coûts qui sont assez astronomiques. Alors qu’avec de l’automatisation, on va pouvoir redéployer de façon très simple ces serveurs et travailler avec les équipes pour automatiser les migrations des applicatifs sur les nouveaux serveurs.

Quels efforts de formation a-t-il fallu réaliser, quels investissements en termes d’équipes et de temps ?

La particularité, c’est qu’au sein de la division, nous avons une réorganisation pour y répondre. Nous sommes organisés un peu comme Spotify avec des squads et des communautés. Moi-même j’anime une communauté qui s’appelle Automate IT autour de l’automatisation et qui permet d’avoir des sachants ou des personnes participant à des salons qui vont venir expliquer, donner de l’information pour partager un langage parce que l’automatisation a vraiment son propre langage. Cela permet aussi de répondre aux interrogations et de partager autour de l’automatisation. Nous avons eu aussi différents challenges au sein de la division pour que les gens puissent y adhérer dans un bon esprit.

Quels ont été les gains de productivité sur le nombre de nœuds automatisés ?

Aujourd’hui, on doit être à un peu plus de 4 000 nœuds automatisés dans Ansible et on ne parle que de la partie on-premise. Sur les gains de temps, quand on n’avait pas du tout d’automatisation pour délivrer un serveur complètement environné avec les accès pour l’utilisateur, nous étions à une semaine et demie, deux semaines. Maintenant, cela se fait en quelques heures et l’utilisateur y accède directement. Et ces quelques heures correspondent à tous les packages de mise à jour sur l’OS, c’est cela qui demande du temps, le reste s’effectue seulement en quelques minutes. Donc, le gain est immédiat. Et c’est pour cela aussi que les équipes changent leur façon de voir et se posent la question d’automatiser ce qu’elles font. Nous avons donc regardé quelles étaient, dans ServiceNow, les RITM - Requests Items – les plus chronophages en nous posant à chaque fois la question. Certaines semblent simples mais lorsqu’elles sont associées à de très nombreuses demandes, les gains sont tout de suite énormes.

Les équipes dont les tâches sont automatisées s’inquiètent-elles de l’évolution de leur rôle ?

Non, puisque ces équipes travaillent en fait sur des tâches à valeur ajoutée. C’est l’objet. Certaines tâches répétitives n’ont absolument aucun intérêt à part celui d’arriver en retard sur la production et d’avoir un client mécontent parce qu’on n’a pas respecté les SLA. Ce qui se passe aujourd’hui, c’est que ces personnes travaillent plutôt à concevoir, à comprendre ce qui se passe, à automatiser et à répondre plus rapidement à l’automatisation des futurs besoins qui arrivent de nos business plutôt qu’à être en retard sur la production. On change juste le paradigme et notre façon de fonctionner.

Quelles sont les fonctionnalités les plus appréciées sur la plateforme et quelles sont les évolutions prévues ?

L’idempotence. C’est l’un des mots que l’on apprend avec Ansible. On peut lancer la même tâche plusieurs fois et elle se déroule toujours de la même façon. C’est vraiment quelque chose de très apprécié. Derrière, nous avons beaucoup de projets qui arrivent, de personnes qui ont apprécié ce qui s’est passé sur la partie déploiement de VM. Nous avons des projets autour du réseau et de la sécurité pour automatiser, confirmer et durcir les configurations des assets.

Quels conseils donneriez-vous à une DSI engagée dans un projet similaire ?

C’est de commencer petit avec une tâche itérative qui prend du temps. De l’automatiser et d’apprendre de cette façon en avançant. A l’inverse, de ne pas partir sur des projets trop gros tout de suite. Procéder bloc par bloc, apprendre et mûrir.

Une réflexion sur l’expérience acquise autour d’Ansible Automation ?

C’est une remise en cause de nos façons de penser. Il y a beaucoup de choses que l’on imaginait impossibles avant. Avec ces automates qui arrivent… Parce que Ansible est une brique importante pour Total mais nous avons également des sujets autour de Terraform qui sont très fortement imbriqués, où l’on voit les équipes de Red Hat et de HashiCorp qui travaillent fortement ensemble. On voit qu’il faut changer nos façons de penser et ne pas dire que les choses sont impossibles mais essayer d’avancer, brique par brique, pour faire que ce ne soit plus impossible.