Augmenter la qualité de service sans ralentir l’innovation : le challenge du CSDO

Temps de lecture estimé : 4 minute(s)

Je suis arrivé chez OVH au printemps 2017 en tant que Chief Service Delivery Officer (CSDO). C’est ainsi tout le Run qui s’est invité au Comex de l’entreprise, pour y porter le sujet de la qualité des services livrés. Un sujet qui, naturellement, figurait déjà au cœur des priorités de la stratégie d’OVH.

Le Run, en informatique, consiste à exécuter une routine ou un programme. Par extension, ce terme désigne chez OVH les équipes en charge d’industrialiser, puis de maintenir en conditions opérationnelles les services livrés par l’entreprise, après qu’ils ont été développés par les équipes de recherche et développement, puis testés en mode 1-10/10-100/100-1 000. Cela signifie qu’ils sont d’abord testés (le plus souvent en interne) par un groupe réduit de personnes, améliorés et ouverts à quelques clients sous la forme d’un bêta-test fermé (les POC), puis dans une version bêta publique sur OVH Labs… Ceci jusqu’à atteindre une masse critique d’utilisateurs, pour démontrer que le produit répond à un réel besoin, et étudier les conditions de son industrialisation.

De gauche à droite : Dominique Michiels, Tammy Ledbetter, Boris Gougeon, Aurélien Daquino et Yaniv Fdida

L’industrialisation, au cœur du modèle OVH

Lorsqu’un service traverse ces différentes étapes sans encombre (sans quoi il repart à la case départ ou est simplement abandonné), les équipes Recherche et Développement passent donc le relai à leurs collègues du Run. Ceux-ci ont la responsabilité de mettre en place l’industrialisation du service, c’est-à-dire de porter son automatisation au plus haut degré possible, pour diminuer la nécessité d’interventions humaines au cours du processus de livraison du service et lors de sa maintenance. Une philosophie qui se trouve au cœur de la spécificité d’OVH, et qui contribue à rendre nos innovations financièrement accessibles. Mais aussi à les fiabiliser.

Toutefois, le travail du Run ne s’arrête pas là. Une fois le service livré, les équipes Run s’assurent de sa qualité, sa stabilité, et de la satisfaction des clients. Le cas échéant, le Run participe à la résolution des incidents, en lien étroit avec le support technique, avec toujours le même objectif : industrialiser. Ainsi, les ingénieurs ont pour objectif de ne pas « fixer » un dysfonctionnement avec un correctif superficiel et unitaire (fix spot), mais de remonter jusqu’à la root cause et de corriger le dysfonctionnement au plus bas niveau. Lorsqu’un problème se produit dans un domaine, il existe une probabilité non négligeable qu’il se reproduise ailleurs, dans un autre domaine. Mieux vaut donc agir ainsi, plutôt que de céder à la tentation de « patcher » rapidement et, à terme, d’aboutir à une infrastructure difficile à maîtriser tant elle comporte de cas particuliers et de correctifs rendant les mises à jour périlleuses, voire impossibles.

De la même façon, nous ne devons plus tolérer aucune « normal error », ces malfaçons bénignes dans le code. Celles-ci ne sont pas critiques, la manière de les contourner finissant par être connue de tous. Mais si elles s’avèrent inoffensives lorsqu’elles sont prises une par une, ces « normal errors » peuvent finir par constituer un facteur de risque. Prises de manière individuelle, ces mesures semblent tomber sous le sens. Le vrai défi est cependant de les appliquer au quotidien, dans un contexte où tout va très vite, où l’innovation technologique impose la cadence.

Livrer plus qu’un service, une qualité de service

Depuis la fin de l’année 2017, l’équipe s’est renforcée et se concentre sur la consolidation de nos fondations. Nous agissons en coopération étroite avec la recherche et le développement, qui fixe les orientations techniques globales, le Customer Care, qui gère le support client et l’industrie qui fournit et maintient les datacenters au sein desquels les services sont opérés.

Si les différents taux de disponibilité de nos services sont de 99,996 % en moyenne sur l’ensemble du parc, nous devons néanmoins nous améliorer sur certains points.

Le premier défi est de parvenir à prendre suffisamment de hauteur dans l’analyse des dysfonctionnements passés, tout en accompagnant la croissance qui est, par définition, peu propice à la prise de recul. Comme le font d’autres industries telles que le secteur automobile, nous devons, par exemple, mieux recouper les incidents et leur origine, sur des périodes longues, et identifier nos faiblesses avec lucidité. Pour cela, nous avons systématisé la création de post-mortems exhaustifs à propos de l’origine des incidents, leur résolution et les améliorations adoptées pour éviter leur reproduction, ces dernières étant le fruit d’une concertation entre les différentes équipes concernées.

En parallèle, sur tous les domaines techniques gérés, nous avons mis en place un système de capture des métriques techniques. Les données ainsi récoltées sont regroupées dans un data lake afin de matérialiser les effets positifs des actions menées par le département CSDO au travers des analyses de tendance. Nous avons notamment adapté des processus opérationnels au sein des datacenters afin de réduire le temps de rétablissement de service (MTTR).

Toutes ces démarches s’inscrivent dans un ensemble plus global qui consiste à déployer une bibliothèque de bonnes pratiques pour la gestion de nos infrastructures, basée sur une modélisation ITIL. Nous verrons d’ailleurs prochainement comment OVH s’est approprié ITIL dans un environnement agile.

Chief Service Delivery Officer