La virtualisation et des licences flexibles contribuent à la modernisation spectaculaire de CSG

La plupart des entreprises sont en train de transformer leurs opérations informatiques, en passant des infrastructures sur site au cloud et des environnements physiques aux environnements virtuels. Avec l’apparition de la COVID-19, presque toutes les entreprises accélèrent leur processus de modernisation.

C’est le cas de CSG, un fournisseur de services d’engagement client qui accompagne depuis 35 ans les secteurs des télécommunications et du câble. L’entreprise fournit aux plus grands câblo-opérateurs d’Amérique du Nord des solutions numériques leur permettant de gérer plus efficacement les relations clients, la facturation et les opérations.

Il y a quelques années, CSG subissait les contraintes de processus vieillissants, aggravées par le manque d’implication des nouveaux responsables d’applications. Tout comme CSG aide ses clients à se moderniser, l’entreprise devait à son tour faire évoluer ses propres opérations.

Erica Morrison, vice-présidente de l’ingénierie logicielle chez CSG, a été chargée d’aider l’équipe d’ingénierie opérationnelle de CSG à mettre en place une organisation et une culture DevOps, alors même qu’elle n’avait jusque-là travaillé que dans le domaine du logiciel.

« Pour un développeur, se retrouver soudainement plongé dans le monde des opérations et découvrir de près les difficultés auxquelles les équipes sont confrontées est un véritable choc », explique-t-elle. « Cela m’a vraiment permis de mieux apprécier tout le travail accompli par nos équipes opérationnelles. »

L’intégration des bonnes pratiques de développement au sein d’une équipe jusque-là exclusivement dédiée aux opérations a permis à CSG de relever de nombreux défis : exploiter des fonctionnalités de F5 qu’elle n’utilisait pas auparavant, ajouter de nouveaux outils et adopter un contrat de licence d’entreprise offrant la flexibilité nécessaire.

Une multitude de défis

À l’époque, Erin Garrigan était la Scrum Master de l’équipe. Aujourd’hui superviseuse, elle revient sur plusieurs initiatives qui, ensemble, constituaient ce que CSG envisageait en 2016 comme un plan sur cinq, voire dix ans.

« D’un point de vue technique, la gestion des changements reposait sur un trop grand nombre de processus manuels, et nous ne disposions pas d’une visibilité suffisante sur les actions de chacun », explique-t-elle. « De nombreuses équipes différentes avaient accès à nos appareils, et nous ne disposions pas des contrôles rigoureux nécessaires pour encadrer ces accès. »

Ce n’étaient pas les seuls problèmes. L’infrastructure était instable et, faute de dispositifs globaux de surveillance de l’état de santé et d’alerte, l’équipe ignorait souvent que certains équipements étaient défaillants jusqu’à ce que des clients lui signalent des problèmes. La modernisation du matériel constituait une autre préoccupation majeure.

Se transformer grâce à l’infrastructure en tant que code

Le premier projet de l’équipe, et le plus important, consistait à tout convertir en code source à l’aide de F5 iApps. Les processus de CSG étant jusque-là manuels, l’équipe a commencé par mettre en place une exportation nocturne des configurations des appareils, ce qui lui a permis de mieux les visualiser. Elle a ensuite progressivement adopté un nouveau paradigme dans lequel le code source détermine désormais la configuration des appareils.

« En l’espace d’un an, nous avons créé plus de 100 iApps à partir des modifications manuelles et du concept d’infrastructure en tant que code », explique Garrigan. « La quantité de travail nécessaire pour transposer chaque configuration manuelle dans des iApps était considérable, mais nous avons créé des outils et nous nous sommes attelés progressivement à cette tâche. »

L’infrastructure étant désormais définie sous forme de code, l’équipe pouvait dissocier les différentes fonctions de ses applications. L’équipe d’ingénierie opérationnelle prend en charge des dizaines d’équipes applicatives dans un environnement de serveurs dynamique qui reçoit plusieurs demandes de modification par jour. La mise en œuvre d’un processus en libre-service a permis aux utilisateurs internes des équipes applicatives de CSG d’utiliser un dispositif BIG-IP dans un environnement sandbox pour configurer les modifications, les vérifier et les soumettre à un pipeline de validation et de revue du code. L’équipe a également créé un autre outil permettant à ces utilisateurs de déployer eux-mêmes les modifications en production.

« À ce stade, nous proposions véritablement l’équilibrage de charge et la fourniture d’applications en tant que services », explique Phil Todd, directeur du développement logiciel chez CSG. « Nous utilisons Jenkins pour piloter la plupart de nos fonctions d’automatisation en libre-service, ainsi que nos fonctions de reporting. Nous avons également développé notre propre code C# pour mettre en œuvre ces fonctionnalités en arrière-plan. »

Visibilité et gestion des changements avec BIG-IQ

Il était également essentiel d’assurer la visibilité de ces changements dans le vaste portefeuille d’applications variées de CSG. Lorsque les processus étaient encore manuels, les équipes applicatives risquaient de se gêner mutuellement en apportant des modifications qui se chevauchaient. Repérer le code défectueux relevait alors d’un casse-tête inutilement complexe.

« Il y avait simplement quelque chose de bizarre dans l’environnement », explique Garrigan. « Nous ne savions pas pourquoi il y avait un problème, seulement que quelqu’un avait forcément fait quelque chose. »

En raison de ces processus manuels, une fois un problème identifié, l’équipe devait souvent retrouver la personne à l’origine de la modification afin de bien comprendre la situation.

Pour résoudre le problème, l’équipe a déployé F5 BIG-IQ et commencé à faire évoluer le processus de gestion des changements lui-même, en mettant en place des rapports automatisés sur l’état des systèmes et l’impact global des changements. Elle a également créé un tableau de bord Grafana afin de surveiller plus d’un millier de points de terminaison et de faciliter la validation des changements. Grâce à la gestion de sa configuration sous forme de code et à l’automatisation des déploiements, CSG pouvait désormais bénéficier d’une réelle visibilité sur l’ensemble des changements effectués.

Selon Todd, cela a entraîné l’une des différences les plus importantes entre l’environnement actuel de CSG et les processus manuels utilisés auparavant : si une modification provoque un dysfonctionnement, le délai moyen de réparation peut désormais se compter en minutes, alors qu’il pouvait auparavant atteindre plusieurs heures, le temps que l’équipe analyse et résolve le problème.

« La connexion à Kibana permet de consigner toutes les modifications, notamment la version déployée et la version précédente », explique-t-il. « Ainsi, au lieu de rester là à nous demander pourquoi cela ne fonctionne pas, il nous suffit d'appuyer sur un bouton dans Jenkins pour déployer la version précédente du code. »

La virtualisation est essentielle

L’étape suivante de cette évolution consistait à améliorer l’évolutivité, la flexibilité et la stabilité de l’infrastructure. Bien que des dizaines d’équipements matériels physiques, dont des F5 VIPRION, soient en service, la majorité des applications ne transitaient que par deux d’entre eux : l’un pour le trafic externe provenant d’Internet et l’autre pour le trafic interne.

Cela a entraîné la création de groupes de grande taille, ce qui représentait un risque accru pour l’organisation en cas de panne. « Si l’un de ces équipements tombait en panne, cela affectait pratiquement tous les produits et tous les clients », explique Todd.

Dans le même temps, les applications de CSG commençaient à migrer vers le cloud privé de l’entreprise ainsi que vers les clouds publics, mais le système offrait des possibilités limitées d’extension à ces environnements et ne permettait pas de migrer vers AWS.

La virtualisation a également joué un rôle déterminant dans la résolution de ces problèmes. L’infrastructure en tant que code dans iApps a offert la flexibilité nécessaire pour réduire la taille globale des groupes de défaillance et ainsi mettre en place un équilibrage de charge plus spécifique à chaque application. Elle a également ouvert la voie à une évolution vers le cloud public lorsque cela s’avérerait nécessaire.

« Nous avons récemment subi une panne qui a touché un seul produit, explique Morrison. Il y a un peu plus d’un an, elle aurait affecté tous les produits. En répartissant davantage d’instances en groupes plus petits, nous avons également la possibilité de basculer vers un système de secours si nécessaire, et le périmètre d’impact reste très limité. Notre investissement dans la stabilité a donc déjà porté ses fruits pour nos clients internes comme externes. »

Les licences d’entreprise offrent la flexibilité nécessaire

CSG a gagné en flexibilité opérationnelle et réalisé des économies supplémentaires en passant de F5 BIG-IP Virtual Editions à un nouveau contrat de licence d’entreprise F5 (ELA). Auparavant, le groupe opérait principalement au sein d’un seul centre de données situé au siège de l’entreprise à Omaha. Sa solution de reprise après sinistre consistait simplement à déployer ses services dans un centre de données tiers si les circonstances l’exigeaient.

Lorsque l’équipe a mis en place un deuxième centre de données il y a quelques années, elle a pu envisager une haute disponibilité entre ces centres de données, mais son ancien contrat de licence et son matériel physique limitaient ses possibilités. Avec du matériel fixe, l’entreprise rencontrait des difficultés en matière d’évolutivité, de disponibilité et de capacité à se développer dans le cloud public.

« Le passage à un contrat de licence d’entreprise F5 et à la solution virtuelle nous a donné la liberté de déployer ce que nous voulons, quand nous le voulons, et d’ajouter ce deuxième centre de données », explique Todd. « Cela nous a également donné la liberté d’explorer de nouvelles possibilités et de répondre avec une grande réactivité aux besoins de nos clients internes. »

Aujourd’hui, l’équipe dispose d’une plus grande flexibilité pour évoluer et assurer la haute disponibilité de différents services.

Perspectives d’avenir : la livraison d’applications dans le cloud

Après avoir modernisé son environnement, l’équipe d’ingénierie des opérations de CSG dispose désormais de la marge de manœuvre nécessaire pour préparer l’avenir. Elle souhaite exploiter davantage les fonctionnalités de sécurité de F5, élaborer des architectures de référence pour l’utilisation de BIG-IP et d’Amazon Web Services (AWS), et intégrer de nouvelles fonctionnalités avec NGINX. Grâce à un ELA, l’entreprise a également pu réaffecter le budget existant à de nouvelles architectures et à de nouveaux ensembles de fonctionnalités.

Morrison travaille également avec les responsables produit de CSG à l’élaboration d’une nouvelle feuille de route visant à tirer parti des réalisations accomplies jusqu’à présent, à améliorer la surveillance des systèmes et les alertes, à ajouter de nouveaux outils de surveillance et à développer un modèle de centre d’excellence pour la fourniture d’applications.

D’un point de vue global, explique-t-elle, la situation est plutôt enviable. À ce stade, l’équipe a concrétisé la quasi-totalité des projets prévus dans sa vision initiale sur cinq ans. Grâce aux partenariats, aux fonctionnalités en libre-service et aux configurations qu’elle a mis en place, il ne reste plus qu’à confier davantage la gestion des applications aux équipes applicatives elles-mêmes.

« Pour la première fois, nous nous demandons : quelle est la prochaine étape ? », explique-t-elle. « Nous avons tellement progressé que nous ne sommes plus en train de chercher à sortir la tête de l’eau. Il s’agit désormais d’anticiper et de nous appuyer sur les bases solides que nous avons établies. »