La plupart des entreprises sont en train de transformer leurs opérations informatiques, du sur site au cloud, du physique au virtuel. Et avec l’apparition de la COVID-19, presque toutes les entreprises accélèrent leur parcours de modernisation.
C’est le cas de CSG, un fournisseur de services d’engagement client pour l’industrie des télécommunications et du câble, vieux de 35 ans. L'entreprise équipe les plus grands fournisseurs de câbles d'Amérique du Nord avec des solutions numériques pour gérer plus efficacement les relations clients, la facturation et les opérations.
Il y a quelques années, CSG était confronté à des contraintes liées au vieillissement des processus, aggravées par un manque d’engagement de la part des nouveaux propriétaires d’applications. Tout comme CSG aide ses clients à se moderniser, il était temps de faire évoluer ses propres opérations.
Erica Morrison, vice-présidente de l’ingénierie logicielle de CSG, a été chargée d’aider l’équipe d’ingénierie opérationnelle de CSG à établir une organisation et une culture DevOps, même si elle n’avait auparavant travaillé que sur le côté logiciel de l’entreprise.
« C’est un choc pour le système pour un développeur d’être soudainement parachuté dans le monde des opérations, de voir au premier plan les défis auxquels il est confronté », dit-elle. « Cela m’a définitivement permis d’apprécier davantage ce que font toutes nos équipes opérationnelles. »
En apportant les meilleures pratiques de développement à une équipe historiquement exclusivement opérationnelle, CSG a pu relever une multitude de défis : exploiter les capacités de F5 qu'elle n'avait pas utilisées auparavant, ajouter de nouveaux outils et adopter un accord de licence d'entreprise offrant la flexibilité nécessaire.
Erin Garrigan était le scrum master de l'équipe à l'époque. Aujourd’hui superviseure, elle raconte plusieurs initiatives qui ont contribué à ce que le CSG envisageait comme un plan sur cinq ou même dix ans en 2016.
« D’un point de vue technique, nous avions trop de processus manuels autour des changements et pas assez de visibilité sur qui faisait quoi », dit-elle. « De nombreuses équipes différentes avaient accès à nos appareils, et nous n’avions pas les contrôles robustes dont nous avions besoin à cet égard. »
Ce n’étaient pas les seuls problèmes. L'infrastructure était instable et le manque de surveillance générale de l'état de santé et d'alerte signifiait que l'équipe n'était souvent pas au courant du mauvais état des appareils jusqu'à ce qu'elle soit informée des problèmes par les clients. La modernisation du matériel était une autre préoccupation importante.
Le premier et plus grand projet de l’équipe consistait à intégrer tout le code source à l’aide des iApps F5. Les processus de CSG étant manuels, ils ont commencé par instaurer une exportation nocturne des configurations des appareils, ce qui a permis à l'équipe d'obtenir une visibilité sur les configurations. Ils ont finalement évolué vers un nouveau paradigme où le code source détermine désormais ce qui se trouve sur les appareils.
« En un an, nous avons créé plus de 100 iApps à partir de modifications manuelles et du concept d'infrastructure en tant que code », explique Garrigan. « Le volume d’efforts nécessaire pour codifier chaque configuration manuelle dans les iApps était considérable, mais nous avons créé des outils et nous y sommes parvenus au fil du temps. »
L’infrastructure étant désormais définie sous forme de code, l’équipe a pu décomposer les fonctions de ses applications. L'ingénierie opérationnelle prend en charge des dizaines d'équipes d'application, dans un environnement de serveur dynamique qui reçoit plusieurs demandes de changement par jour. La mise en œuvre d’un processus en libre-service a permis aux consommateurs internes des équipes d’application de CSG d’utiliser un périphérique BIG-IP sandbox pour configurer les modifications, les vérifier et les transmettre via un pipeline pour validation et révision du code. Ils ont également créé un autre outil qui permet à ces utilisateurs de pousser eux-mêmes les modifications en production.
« À ce moment-là, nous proposions en réalité un équilibrage de charge et une livraison d’applications en tant que service », 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. Et nous avons écrit une partie de notre propre code C# pour implémenter cette fonctionnalité en coulisses. »
Améliorer la visibilité sur ces changements était un autre besoin essentiel dans l’ensemble vaste et diversifié des applications de CSG. Dans leur monde auparavant manuel, les équipes d’application pouvaient se marcher sur les pieds en apportant des modifications qui se chevauchaient. Trouver du mauvais code était un casse-tête plus complexe qu’il n’aurait dû l’être.
« Il y aurait quelque chose de bizarre dans l’environnement », explique Garrigan. « Nous ne saurions pas pourquoi c’était bancal, seulement que quelqu’un a dû faire quelque chose. »
Les processus manuels signifiaient également qu’une fois un problème identifié, l’équipe devait souvent retrouver la personne qui avait effectué le changement pour bien le comprendre.
Pour résoudre le problème, l’équipe a mis en œuvre F5 BIG-IQ et a commencé à instaurer des changements autour du processus de changement lui-même, en introduisant des rapports automatisés sur la santé du système et les impacts globaux des changements. Ils ont également créé un tableau de bord Grafana pour surveiller plus d'un millier de points finaux afin de soutenir la validation des modifications. Avec leur configuration désormais sous forme de code, ainsi que l'automatisation construite autour des déploiements, CSG pouvait obtenir une réelle visibilité sur tous les changements qui avaient été apportés.
Selon Todd, cela a conduit à l’une des plus grandes différences entre l’environnement actuel de CSG et les processus manuels qu’ils avaient dans le passé : si un changement casse quelque chose, le temps moyen de réparation peut désormais être de quelques minutes, alors qu’avant il pouvait être de plusieurs heures pendant que l’équipe enquêtait et résolvait le problème.
« La connexion à Kibana enregistre toutes les modifications : la version déployée et la version précédente », explique-t-il. « Ainsi, sans nous asseoir et nous demander pourquoi cela ne fonctionne pas, nous déployons simplement la version précédente du code en appuyant simplement sur le bouton dans Jenkins. »
L’évolution suivante a consisté à aborder l’évolutivité, la flexibilité et la stabilité de l’infrastructure. Bien qu'ils utilisaient des dizaines de périphériques matériels physiques, dont des F5 VIPRIONS, la majorité des applications circulaient via seulement deux d'entre eux : un pour le trafic externe provenant d'Internet et un autre pour le trafic interne.
Cela a donné lieu à des groupes de grande taille, ce qui représentait un risque plus important pour l’organisation en cas de défaillance. « Si l’un de ces appareils tombait en panne, cela avait un impact sur 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 avait une capacité limitée en termes d’expansion dans ces environnements et ne permettait pas la migration vers AWS.
La virtualisation a également joué un rôle déterminant dans la résolution de ces problèmes. Le fait d'avoir une infrastructure en tant que code dans les iApps a fourni la flexibilité nécessaire pour réduire la taille globale du groupe de défaillance et ainsi établir un équilibrage de charge plus spécifique à l'application. Cela a également ouvert la porte à une évolution ultérieure vers le cloud public lorsque cela était nécessaire.
« Nous avons eu une panne récemment et cela a eu un impact sur un produit », explique Morrison. « Il y a un peu plus d’un an, cela aurait affecté tous les produits. Avec davantage d'instances divisées en groupes plus petits, nous avons également la possibilité de basculer si nécessaire, et ce rayon d'explosion est très petit. « L’investissement dans la stabilité a déjà apporté de bonnes nouvelles à nos clients internes et externes. »
CSG a gagné en flexibilité opérationnelle et en économies de coûts en passant des éditions virtuelles F5 BIG-IP à un nouvel accord de licence d'entreprise F5 (ELA). Auparavant, le groupe fonctionnait principalement dans un centre de données au siège social de la société à Omaha. Leur solution de reprise après sinistre consistait simplement à installer ses services dans un centre de données tiers si les événements l'exigeaient.
Lorsque l’équipe a construit un deuxième centre de données il y a quelques années, elle était en mesure d’explorer la haute disponibilité dans ces centres de données, mais leur ancien accord de licence et leur matériel physique limitaient leurs options. Avec du matériel fixe, l'entreprise a été confrontée à des défis d'évolutivité, de disponibilité et de capacité à s'étendre dans le cloud public.
« Le passage à un contrat de licence d'entreprise F5 et à la solution virtuelle nous a donné la liberté de mettre en place ce que nous voulons, quand nous le voulons et d'ajouter ce deuxième centre de données », explique Todd. « Et cela nous a donné la liberté d’explorer et d’être très réactifs aux besoins de nos clients internes. »
Aujourd’hui, l’équipe dispose de plus de flexibilité pour évoluer et atteindre une haute disponibilité pour divers services.
Après avoir modernisé son environnement, l’équipe d’ingénierie opérationnelle de CSG dispose désormais de la marge de manœuvre nécessaire pour planifier l’avenir. L'équipe souhaite exploiter davantage les capacités de F5 en matière de sécurité, mettre en place 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. Et grâce à un ELA, l'entreprise a pu réorienter le budget existant vers de nouvelles architectures et de nouveaux ensembles de fonctionnalités.
Morrison travaille également avec les propriétaires de produits de CSG sur une nouvelle feuille de route pour s'appuyer sur ce qu'ils ont accompli jusqu'à présent, en améliorant la surveillance et les alertes du système, en ajoutant de nouveaux moniteurs et en développant un modèle de centre d'excellence pour la livraison d'applications.
D’un point de vue global, dit-elle, c’est un endroit agréable où vivre. À ce stade, l’équipe a réalisé presque tous les projets issus de sa vision initiale sur cinq ans. Grâce aux partenariats, aux fonctionnalités de libre-service et aux configurations qu’ils ont créées, il ne reste plus qu’à transférer davantage de responsabilités sur les applications aux équipes d’applications elles-mêmes.
« Pour la première fois, nous nous demandons : que faisons-nous ensuite ? », dit-elle. « Nous avons fait tellement de progrès que nous n’avons plus besoin de nous en sortir. Il s’agit désormais d’être proactif et de bâtir sur les bases solides que nous avons établies. »