ENGIE IT, centre de service partagé pour l’infrastructure et les applicatifs du groupe ENGIE, a fait le choix d’un double modèle de gestion pour ses infrastructures Cloud, dont une partie est infogérée et l’autre est effectuée en interne.

Dans cet article, nous vous proposons de confronter deux points de vue sur le run des infrastructures Cloud AWS : celui de William Liévin, Head of Cloud Center of Excellence chez ENGIE IT, et mon point de vue de consultant Devoteam Revolve, et ce que j’ai retiré de cette expérience de production.

Partie 1 : Interview de William Liévin

Peux-tu présenter le périmètre sur lequel tu interviens ?

ENGIE IT est le centre de service partagé du groupe ENGIE pour tout ce qui concerne l’infrastructure et les applicatifs. J’interviens au sein de CCOE pour designer, builder et piloter le run des infrastructures Cloud mutualisées.

Nous avons tous types de workloads, du IaaS traditionnel avec des applicatifs issus de migrations en lift and shift, jusqu’aux applications complètement Cloud native, sans VM, sans conteneurs, uniquement basées sur des fonctions et de la data. Nous avons aussi beaucoup de workloads SAP, sur lesquels l’enjeu est d’apporter de l’innovation sur nos infrastructures IaaS, comme le détaille Hamilton dans la partie suivante.

Comment gérez-vous le run de vos infrastructures ?

Une partie du run est gérée en interne, et l’autre est en infogérance. Nous avons donc deux modèles de gestion, pour nous adapter au mieux aux besoins des clients : il y a d’une part le besoin de proximité, avec des attentes spécifiques, qui est adressé en interne, et d’autre part le besoin d’industrialisation, qui est adressé avec des partenaires externes.

Quels sont les avantages du run en interne ?

Le run en interne nous permet de projeter des ressources en mode DevOps chez nos clients. Nous apportons nos compétences Ops au sein des squads chez le client, avec de l’innovation en continu. A l’inverse, dans notre modèle actuel, les workloads que nous confions à nos partenaires infogérants sont ceux sur lesquels nous priorisons l’industrialisation et l’excellence opérationnelle. 

Comment cette approche se traduit sur les workloads SAP ?

L’objectif est de bénéficier du meilleur des deux mondes, c’est-à-dire pour les clients qui en ont besoin, nous appuyer sur un partenaire externe avec une expertise sur les couches hautes de SAP, et en interne suivre le rythme d’innovation des Cloud providers. Lors du dernier re:Invent, AWS a ainsi proposé plus d’une dizaine d’innovations majeures sur le périmètre SAP. En tant que service partagé, il est important que nous puissions ensuite proposer aux équipes telle ou telle innovation, car elle permet de réduire l’empreinte carbone, réduire les coûts, améliorer la performance ou la résilience. Il est plus simple de suivre ces sujets en interne.

Dans ce contexte, quelle est la plus-value de l’accompagnement de Devoteam Revolve ?

Nous sommes sur un partenariat d’expertise avec Devoteam Revolve, qui nous apporte des compétences sur le run, et sur le Cloud AWS : Devoteam Revolve nous permet de travailler avec des profils qui sont au fait des dernières innovations sur le Cloud. Nous travaillons avec Devoteam Revolve depuis de nombreuses années, et il y a chez ses consultants une vraie culture de l’excellence technique, une expertise dont ils savent faire bénéficier leurs clients.

Pour finir, quelle a été l’évolution des besoins en compétences sur le run ces dernières années ?

Avec la montée en puissance du Cloud dans les infrastructures, les profils intervenant sur les infrastructures ont évolué, et vont continuer de le faire. Aujourd’hui, avec le Cloud, l’infra as code, le DevOps, et des Cloud providers de plus en plus présents dans la gestion du service, les barrières sont plus floues. Nous attendons des profils qui soient polyvalents, et les métiers Ops traditionnels se rapprochent de plus en plus du code.

Partie 2 : Le run, pourquoi c’est fun ?

Le métier de consultant offre des possibilités de missions sur des sujets variés : on peut se voir proposer de l’audit, de la mise en place d’architecture, du développement souvent appelé build ou encore de la gestion de maintenance d’un projet appelé run. Les missions de run ont cependant parfois mauvaise presse auprès des consultants débutants, pour qui ces projets semblent offrir peu de challenge et une faible marge d’apprentissage.

Qu’en est-il réellement ? Loin de ces a priori, j’aimerais vous présenter mon expérience de consultant Cloud au sein des équipes ENGIE IT sur des projets en phase de run, et ce que j’en ai retiré.

Au cours de ma mission j’ai pu monter en compétences sur de nombreux sujets mais ne pouvant pas donner une liste exhaustive ici, je les présenterai en trois grandes parties.

La posture consultant

Lorsque j’ai été recruté au sein des équipes ENGIE IT, on attendait de moi d’être force de proposition, d’appliquer mon devoir de conseil, et de pouvoir anticiper et participer à l’amélioration du travail de toutes les équipes. En tant que consultant, nous nous appuyons sur nos expériences passées pour guider au mieux les équipes dans leurs choix techniques et organisationnels.

Le consultant doit par exemple être capable d’orienter son conseil en fonction des besoins des équipes : préconiser l’usage d’un service qui faciliterait le quotidien de l’équipe, recommander des optimisations de coût, ou encore automatiser certaines tâches récurrentes.

La technique

Mes premières expériences dans le Cloud étant orientées Serverless, appréhender les environnements SAP chez ENGIE IT représentait un challenge pour moi. J’ai pu durant cette mission acquérir un certain niveau d’expertise OS et réseau, et rapidement monter en compétence sur l’usage avancé de services comme VPC, EC2, Route53, AWS Backup, System Manager, Inspector, etc. La mission m’a permis de me réadapter aux services liés au réseau et aux machines virtuelles, mais également d’approfondir mes compétences en scripting.

Au quotidien, j’ai eu l’opportunité de participer à différentes sessions collaboratives organisées au sein des équipes. J’ai par exemple participé aux Well Architected Review (WAR), qui visent à challenger les choix d’infrastructure dans une optique d’amélioration continue. J’ai également eu l’occasion de travailler sur les Disaster Recovery Plan (DRP – Plan de Reprise après Sinistre). Le DRP est un ensemble structuré et détaillé d’instructions destinées à récupérer le système et les réseaux en cas de panne ou d’attaque, afin de rendre l’organisation à nouveau opérationnelle le plus rapidement possible.

Dans ce cadre, j’ai contribué à la mise en place du plan de bascule des serveurs sur une autre zone de disponibilité (AZ) en cas de panne sur la zone de départ, et sur la réalisation de snapshots pour les instances EC2 avant le lancement du test DRP en cas de problèmes. Les snapshots nous permettent de revenir à l’état d’avant panne.

J’étais également en support des équipes applicatives en cas de besoin de restauration.

La documentation étant un prérequis essentiel au sein des équipes ENGIE IT, j’ai pris la bonne habitude de documenter tout mon travail afin de permettre à toute l’équipe d’apprendre à utiliser mes projets. La documentation est un élément essentiel pour faire monter en compétence les équipes sur de nouveaux projets, mais également faire vivre et maintenir ces projets. 

Enfin, dans le cadre de cette mission, j’ai pu développer de nouvelles compétences dans les domaines de la sécurité informatique et du FinOps, grâce à ma participation à différents projets.

L’expérience d’un projet en production 

A quoi ressemble une journée type avec les équipes cloud ? On commence de façon assez classique par un daily meeting, pour présenter les différents sujets en cours, les points de blocages et les sujets à venir. Une revue des backups de la veille est également nécessaire, nous vérifions les mails de reporting mis en place sur les comptes, avec si besoin des vérifications sur la console AWS. Commencent alors les tâches courantes : automatisation, dépannage, audit, resizing, etc.   

Un projet en phase de run est un projet en production. Il a donc des exigences de réactivité assez élevées et demande une coordination des équipes avant toute action. Il faut pouvoir assurer des astreintes, des montées de versions et des patchs. En décembre 2021, nous avons eu à faire face à la faille Log4j, et j’en retiens un bon exemple de gestion de situation de crise au sein d’un grand groupe, et une expérience très formatrice. Une stratégie de contre-mesure a vite été mise en place pour l’ensemble du groupe et les équipes ont su se synchroniser assez rapidement.

Globalement, un environnement de production met face à des réalités qu’on ne rencontre pas sur d’autres phases du projet ; la disponibilité du produit pour les utilisateurs et son amélioration continue sont des challenges qui m’ont donné une autre vision des projets qui impactera ma manière de développer mes applications à l’avenir.

Conclusion

Si les tâches quotidiennes proposées m’ont permis d’approfondir mes connaissances techniques, notamment en OS Linux/Windows, scripting, cloud, j’ai aussi beaucoup appris sur le plan humain. Une mission, quel que soit son contexte, est en grande partie animée par le consultant lui-même : en y mettant du sien et en étant force de proposition, on peut en retirer une grande expérience technique et humaine.