Publié le 1 septembre 2022, mis à jour le 21 décembre 2023.
Comment juger de la qualité d’une infrastructure, mais surtout, comment la mesurer et dresser un état des lieux des axes d’amélioration ? Un sujet qui renvoie directement à la dette technique, comme l’explique Eric Higgins, qui est parfois relayée au second plan sur certains projets, au profit du delivery.
Les quatre piliers de ROSE
En 2020, Aurore Malherbes, CTO de Padok, se penche sur la question et s’entoure d’une petite équipe de SRE Padok pour se lancer sur la conception d’un premier prisme d’analyse sur le sujet : quels sont les principaux piliers d’une infrastructure de qualité ? Comment définir des critères universels et faire abstraction des cas particuliers ? Est-il possible de mettre en place un système de notation ?
C’est la naissance du framework ROSE, doté d’une notation sur 100 points, que les équipes Padok continuent de faire évoluer et utilisent sur l’ensemble de nos projets.
Mais au fait, pourquoi “ROSE” ? Cet acronyme renvoie aux quatre piliers d’une infrastructure de qualité selon Padok : Resilient, Operable, Secure, Empowering. Chacun d’eux est noté sur 25, pour une note totale sur 100. Explorons ce qui se cache derrière chacun de ces termes.
Axe #1 : la résilience
La résilience d’une infrastructure informatique renvoie à sa capacité à minimiser l’impact ou la durée d’un évènement perturbateur, comme un incident ou une panne par exemple.
Côté Padok, notre objectif est d’assurer un uptime de 95,5% avec une latence inférieure à quelques ms, à définir plus précisément avec nos clients en fonction de leurs enjeux business.
Plusieurs critères sont à prendre en compte, comme la haute disponibilité, la scalabilité, le service management ou encore la présence/qualité des backups mis en place sur l’infrastructure. Par exemple : mes données critiques sont-elles sauvegardées quotidiennement et restaurables sur une autre instance ? Ai-je une procédure précise et l’ai-je testée il y a moins de 6 mois ?
Plusieurs évènements extérieurs peuvent avoir lieu et rendent ces backups indispensables : compromission des données, problème de migration, perte d’une instance.
Axe #2 : l’opérabilité
L’opérabilité est la capacité à maintenir un système ou une infrastructure dans un état de fonctionnement sûr et fiable sur le long terme. Dan Mitchell résume bien l’importance et la valeur d’une bonne opérabilité informatique.
De la même manière que pour la résilience, nos équipes Padok se donnent un objectif concernant l’opérabilité sur l’ensemble de nos projets : respecter un certain MTTR (Mean Time to Restore) à définir ensemble avec nos clients.
Les sujets que l’on va regarder ici sont entre autres le monitoring et l’alerting, le patch management ou encore le sujet de l’IaC (Infra as Code). Sur ce dernier point, nous allons par exemple faire en sorte qu’au moins 80% de nos infrastructures soient définies et gérées en IaC (via Terraform par exemple).
Pourquoi ? Cela permet de centraliser la configuration et simplifier les opérations. Certains éléments ne sont pas définissables en IaC, il faut cependant appliquer ce principe au maximum.
Axe #3 : la sécurité
Nul besoin d’en donner une définition, la sécurité parle d’elle-même. Plusieurs articles de notre blog adressent ce sujet, comme celui sur les grands principes du DevSecOps écrit par Lucas, notre Head of Operations Cybersécurité chez Padok. Notre objectif est de maintenir à 0 le nombre de failles exploitées sur nos infrastructures.
Plus précisément, nous nous focalisons ici sur les outils de sécurité à mettre en place, la détection d’intrusion, la sécurité réseau ou encore les droits utilisateurs. Sur ce dernier point, nous nous attellerons par exemple à mettre en place un système de double authentification sur les infrastructures de nos clients afin d’éviter que la fuite d’identifiants de connexion, ou la compromission d’un PC ne permette à un attaquant d’accéder à l’infrastructure.
Nous ferons également en sorte que les comptes utilisateurs/techniques ne puissent pas élever leurs privilèges (les attaques par élévation de privilèges étant parmi les plus fréquentes).
Axe #4 : l’empowerment
La notion d’empowerment renvoie, au sens Padok, à l’importance de responsabiliser et rendre plus autonomes les équipes de développeurs sur leur infrastructure. La mesure que nous suivons est la fréquence des déploiements réalisés par ces mêmes équipes.
Nous mettons l’accent ici sur le DevX, la qualité de la CI/CD ou encore la facilité des déploiements en production : les développeurs sont-ils autonomes dans leurs déploiements ? Leur workflow de déploiement est-il documenté ? Le rollback d’un déploiement est-il également documenté et possible en 1 action ?
Quelle valeur ajoutée pour nos clients ?
Comme énoncé plus haut, l’utilisation de ce framework ROSE s’applique aussi bien sur des audits que sur des projets d’implémentation (migration, build from scratch). ROSE permet également à notre équipe de run de suivre l’évolution de la qualité des infrastructures cloud en infogérance.
Audit d’infrastructure
Certains clients viennent à nous pour réaliser un audit de leur infrastructure. Les raisons sont variées : pas ou peu de visibilité/compréhension de leur infrastructure, nécessité de montrer patte blanche vis-à-vis de leurs clients/investisseurs, besoin d’une roadmap d’implémentation précise pour moderniser/migrer leur infrastructure, etc.
Quel que soit le motif de l’audit, nos équipes utilisent ROSE comme prisme d’analyse. Elles s’appuient sur ce modèle pour “scanner” l’infrastructure du client afin d’en sortir des observations et recommandations.
Ce framework comptant ~ 100 critères, il est cependant très facile d’axer et d’adapter tous nos audits en fonction des priorités et enjeux business de chacun de nos clients.
Projet d’implémentation (migration, build from scratch)
Tout projet de build Padok, que ce soit une migration (vers le cloud ou vers une nouvelle technologie) ou la construction d’une infrastructure from scratch, commence par un challenge technique nous permettant de préparer au mieux l’implémentation.
C’est au cours de ce challenge technique qu’est mis en place ROSE : l’objectif n’est pas d’atteindre 100/100 en fin de projet, mais plutôt d’identifier les principaux critères sur lesquels se focaliser pendant l’implémentation, de concert avec le client.
La pression sur le delivery étant parfois forte, notamment en fin de projet, ROSE sert ainsi de garde-fou permettant aux équipes de ne pas délaisser la qualité et toujours garder un œil dessus.
Infogérance
Dernier cas d’usage : l’infogérance Padok. De la même manière que nos SRE utilisent ROSE comme matrice d’analyse lors d’audits, notre équipe d’infogérance scanne également toute nouvelle infrastructure grâce à ROSE avant de commencer à l’infogérer (le score requis est de 36/100).
La raison est simple : dès lors que nous nous engageons à maintenir une infrastructure en condition opérationnelle et à réagir en cas d’incident, nous devons vérifier en amont que cette même infrastructure respecte un certain nombre de prérequis; c’est de la gestion de risque.
En fonction de l’offre souscrite par nos clients, notre équipe de run est également amenée à réaliser des “Health checks” trimestriels, lors desquels des recommandations d’évolutions d’infrastructure sont exprimées sur la base de cette matrice, ceci afin de faire passer son score ROSE d’une note de 45/100 à 49/100 par exemple.
Conclusion
Rappelons que le framework ROSE reflète notre propre interprétation d’une infrastructure de qualité, mais évolue de manière empirique au fil des projets que nous réalisons et des difficultés que nous rencontrons. C’est ce qui rend cet outil vivant et très facilement activable sur l’ensemble du cycle de vie d’une infrastructure. N’hésitez pas à ajouter votre pierre au framework ROSE en nous partageant vos propres critères de qualité !