Imaginez un grand établissement bancaire français, avec des milliers d’utilisateurs et près de 900 applications différentes. Imaginez maintenant le volume de transferts de fichiers générés au quotidien, en interne comme en externe, et la plate-forme gérant l’ensemble, un peu comme La Poste.

Dans cet article, nous verrons comment cette plateforme de transfert de fichiers a évolué depuis 4 ans, pour répondre à des problématiques croissantes d’infrastructure et de support.

Mutualisée et centralisée, la plateforme permet à chaque utilisateur, partenaire ou application d’envoyer un fichier vers une “boîte aux lettres” dédiée. Cette boîte aux lettres transfère ensuite automatiquement le fichier à destination, sur un serveur. Ce routage et sa configuration serveur sont configurés de manière statique par les administrateurs.

Les besoins d’industrialisation de la plateforme

L’état des lieux de cette plateforme il y a 4 ans révèle plusieurs problématiques d’infrastructure. La plateforme est peu industrialisée (peu de scripts), manque d’outils pour faciliter l’intégration et la livraison continue. Elle ne permet pas de monitorer les problèmes d’infrastructure, de suivre le capacity planning, et surtout, ne communique pas. Imaginez le service Colissimo sans avis de passage du facteur, par exemple…que se passe-t-il quand le fichier n’a pas été livré ?

Ces problématiques d’infrastructures ne sont pas sans conséquences côté support. Les délais de traitement et de résolution d’incidents sont longs, les utilisateurs s’impatientent devant l’absence de réponse et la plupart des incidents sont escaladés. De fait, l’équipe support est en croissance constante, et son efficacité en perte de vitesse. Dans ces conditions, l’astreinte est très souvent sollicitée, et les tâches récurrentes systématiquement offshorées. Et l’infrastructure est complètement figée.

En attendant une refonte complète du service et de l’infrastructure, notre objectif était donc de commencer à améliorer la situation.

Instaurer un échange régulier avec les utilisateurs

Première étape, la prise de contact avec les utilisateurs et métiers du service : l’objectif était de comprendre leurs enjeux, leurs contraintes, et de recueillir leurs besoins. Cette communication avec les métiers s’est établie de façon régulière dans le cadre de rendez-vous hebdomadaires “Lunch&Share”. Ils permettent d’instaurer une communication ouverte et régulière, une formation aux services de transfert de fichiers, et améliorer l’image que chaque partie a de l’autre. Dans la même optique, nous avons mis en place un outil de feature request.

Vinrent ensuite les améliorations techniques du service :

• Amélioration des outils d’administration (fiabilisation, simplification)
• Amélioration du monitoring et de l’alerting infra
• Traitement automatique des alertes applicatives
• Versionning des scripts (GIT)
• Mise à disposition d’outils web
• Délégation des taches les plus récurrentes liées au support des flux
• Utilisateurs autonomes pour le diagnostic et le dépannage des flux

D’un point de vue organisationnel, le processus de demandes a complètement été refondu. Une documentation a été fournie sous forme de Wiki aux utilisateurs et aux administrateurs, et les utilisateurs ont été formés aux nouveaux services, au process, aux outils.

Pour résumer, il aura fallu :

• De l’échange régulier avec les métiers
• De la compréhension des besoins et contraintes de chacun
• De la formation
• De l’automatisation
• De la délégation via des outils simples à exploiter et documentés
• Une simplification des process

Les bénéfices quantitatifs et qualitatifs de cette première amélioration du service ont été nombreux :

• Division par 9 du nombre de demandes non traitables
• Passage de 3 mois de délais à 1 semaine
• Délégation de taches (logs, inventaire, test des flux, diagnostic, etc…)
• Gain en autonomie et réactivité des utilisateurs
• Diminution des astreintes
• Meilleur réactivité en cas d’incident (infra et flux)

La refonte de l’infrastructure

Cette première étape nous aura permis de libérer un temps non négligeable pour lancer une vraie refonte du service et de son infrastructure. Voici les axes majeurs de cette refonte :

• Augmenter la résilience et la capacité de l’infrastructure
• Standardiser et simplifier l’offre, tout en répondant aux besoins des métiers
• Automatiser et industrialiser au maximum la gestion et la maintenance du service
• Déléguer toutes les taches de gestion des flux aux supports métier via des outils Web et une API
• Fiabiliser et automatiser les releases sur l’infrastructure

L’automatisation et la délégation ont rapidement porté leurs fruits et rassuré management et administrateurs. Entre l’infrastructure et les métiers, un rapport de confiance mutuelle a commencé à s’établir. En orchestrant leur déploiements et la gestion de leurs flux, les métiers sont non seulement devenus acteurs de la refonte, mais ils ont également amélioré leur Time to Market.

Afin de répondre aux enjeux majeurs de cette réforme, nous avons constitué une équipe alliant des compétences de développement, d’infrastructure et de middleware. Nous avons mis en place une architecture clusterisée et scalable horizontalement : tous les composants sont choisis et développés dans cette optique. Les scénarios d’utilisation ont été revus afin de mieux coller aux besoins des métiers, des contraintes de la solution logicielle choisie, et de pouvoir fournir une délégation complète de la gestion des flux.

En nous inspirant des bonnes pratiques et de la vision Docker, nous avons créé des pseudo conteneurs applicatifs, indépendants de la machine hôte, et capables d’être migrés d’un serveur à l’autre lors des opération de DR / backup sans adaptation de l’hôte cible. Cela permet aussi de parfaitement gérer les dépendances. Par ailleurs nous avons mis en place :

• Une API REST Json interne capable de répondre à tous les outils (API publique, portail Web, scripts Python)
• Un portail Web et d’une API REST publique afin d’exposer le service aux métiers et utilisateurs
• Une gestion de rôles RBAC gérée par les métiers

Intégration et livraison continue pour l’infrastructure

En mettant en œuvre une infrastructure en intégration et livraison continue, l’infrastructure devient une sorte de composant applicatif, gérée comme une application :

• Git pour le versionning du code
• Jenkins pour les tests d’intégration
• Salt pour la gestion de configuration applicative, et la gestion des déploiements

La livraison des outils Web et de l’API publique s’est faite en plusieurs étapes. En effet, dans un contexte de migration globale des 4000 flux déclarés, nous avons jugé important de tester l’API interne nous-mêmes, avec l’équipe de support niveau 1 et 2.

Cela nous a permis de peaufiner les services rendus, de les adapter, de les sécuriser, et de s’assurer que tout a été correctement automatisé. Nous avons également dû étaler la période de transition vers l’automatisation et la délégation totales : cela impliquait également d’importants changements en termes d’organisation et un impact sur les individus.

Ce sont les outils web qui ont été livrés en premier : ils permettent en effet au plus grand nombre de gérer les flux, récupérer les statuts de chaque fichier ayant transité via la plate-forme, visualiser les inventaires de flux, et de tester les flux suite aux migrations. Ces outils sont vitaux pour les métiers.

La première version de l’API publique a ensuite été livrée. Elle permet uniquement de requêter des informations sur les flux (inventaire, logs, statuts).

La deuxième version de l’API avec les fonctions de création, mise à jour, suppression de flux, sera livrée à moyen terme. En effet, à l’heure où j’écris ces lignes, l’organisation liée à la délégation via API est en train de se définir. Les mentalités et visions évoluent également.

Objectif : Autonomie du métier

Malgré cette livraison décalée de l’API publique, l’impact bénéfique de la refonte de l’infrastructure est évident. La qualité des livraisons s’est améliorée, ainsi que les délais de traitement des demandes et incidents.

Plus globalement, cette lourde migration a permis de rendre autonomes les métiers, qui peuvent maintenant orchestrer les créations de flux, monitorer automatiquement le routage des fichiers pour chaque flux, automatiser la reprise sur incident de livraison…et au final, améliorer le Time to Market.

Côté administration et exploitation de l’infrastructure de transfert de fichiers, la migration a permis une véritable montée en compétences : il y a de moins en moins de taches niveau 0, 1 et 2. Les efforts sont maintenant consacrés à la création de valeur ajoutée, à l’amélioration de la fiabilité et de la performance, et à l’évolution du service pour mieux satisfaire le business. A terme, l’objectif est de pouvoir se séparer des supports de niveau 0,1,2 et de se consacrer à l’engineering, le conseil et l’accompagnement du business.

Cette démarche d’automatisation et de délégation n’a ici concerné que la gestion des flux de transfert de fichiers ; elle prendra toute sa valeur lorsqu’elle sera accompagnée d’une démarche similaire côté système, stockage, réseau, middleware, et applicatif.