Lancements de produits fiables à grande échelle

Les entreprises de l'Internet, comme Google, lancent de nouveaux produits et de nouvelles fonctionnalités à un rythme bien supérieur à celui des sociétés traditionnelles. Le rôle du SRE dans ce processus consiste à rendre possible un rythme de changement élevé sans compromettre la stabilité du site. Pour y parvenir, Google a constitué une équipe dédiée, les ingénieurs de coordination de lancement (Launch Coordination Engineers, LCE), chargés de conseiller les équipes de développement sur les aspects techniques d'un lancement réussi. Cette équipe a aussi entretenu une « checklist de lancement » de questions récurrentes et de recettes pour résoudre les problèmes les plus fréquents — un outil qui s'est révélé déterminant pour obtenir des lancements fiables et reproductibles.

Le moment de vérité : lancer à l'échelle de Google

Pour saisir l'enjeu, prenons un service Google ordinaire : Keyhole, qui sert l'imagerie satellite de Google Maps et Google Earth. Un jour normal, Keyhole délivre jusqu'à quelques milliers d'images par seconde. Mais la veille de Noël 2011, il a reçu vingt-cinq fois son pic de trafic habituel — plus d'un million de requêtes par seconde. La cause de cette déferlante ? Le Père Noël arrivait. Google avait collaboré avec le NORAD (le commandement de défense aérospatiale de l'Amérique du Nord) pour héberger un site de Noël qui suivait la progression du Père Noël autour du monde en temps réel, dont un « survol virtuel » (virtual fly-over) qui s'appuyait sur l'imagerie satellite pour suivre sa progression au-dessus d'un monde simulé (over a simulated world).

Aussi fantaisiste qu'il paraisse, le projet « NORAD Tracks Santa » réunissait toutes les caractéristiques d'un lancement difficile et risqué : une échéance ferme (on ne peut pas demander au Père Noël de repasser une semaine plus tard), une forte exposition médiatique, une audience de millions de personnes, et une montée en charge très abrupte. Le SRE a travaillé dur pour préparer l'infrastructure, en bâtissant divers commutateurs d'arrêt d'urgence (kill switches) pour protéger les services — affectueusement surnommés les « interrupteurs anti-larmes d'enfants » (make-children-cry switches). Anticiper toutes les façons dont un tel lancement peut mal tourner, et coordonner les différents groupes d'ingénierie impliqués, est précisément la mission des LCE.

Google définit un lancement (launch) comme tout nouveau code introduisant un changement visible de l'extérieur dans une application. Selon les caractéristiques du lancement — la combinaison d'attributs, le calendrier, le nombre d'étapes, la complexité — le processus peut varier considérablement. Avec cette définition large, Google réalise parfois jusqu'à soixante-dix lancements par semaine. Ce rythme rapide fournit à la fois la justification et l'occasion de bâtir un processus de lancement rationalisé : une entreprise qui ne lance un produit que tous les trois ans n'a pas besoin d'un tel processus — et n'accumulerait de toute façon jamais assez d'expérience pour en concevoir un qui soit robuste et mature.

L'équipe Launch Coordination Engineering (LCE)

Les bons ingénieurs logiciels maîtrisent à fond le code, la conception et la technologie de leurs propres produits. Mais ces mêmes ingénieurs peuvent ignorer les écueils du lancement d'un produit auprès de millions d'utilisateurs, tout en minimisant les pannes et en maximisant les performances. Google a répondu à ces défis en créant, au sein du SRE, une équipe de conseil dédiée au volet technique du lancement. Composée d'ingénieurs logiciels et système — certains issus d'autres équipes SRE —, l'équipe Launch Coordination Engineering accompagne les développeurs vers des produits fiables et rapides, conformes aux standards de robustesse, de passage à l'échelle et de fiabilité de Google. Elle facilite le lancement de plusieurs manières :

• auditer les produits et services pour vérifier leur conformité aux standards de fiabilité et aux bonnes pratiques, en fournissant des actions concrètes d'amélioration ;
• jouer le rôle d'agent de liaison (liaison) entre les multiples équipes impliquées dans un lancement ;
• piloter les aspects techniques en veillant à ce que les tâches conservent leur élan (momentum) ;
• agir comme gardiens (gatekeepers) et valider les lancements jugés « sûrs » ;
• former les développeurs aux bonnes pratiques et à l'intégration avec les services internes de Google, en les outillant de documentation et de ressources.

La plupart des audits sont menés avant le lancement. Si une équipe produit lance sans support SRE, les LCE apportent le savoir-faire nécessaire à un déroulé sans accroc. Mais même les produits déjà solidement soutenus par une équipe SRE font souvent appel aux LCE lors des lancements critiques : les défis d'un lancement diffèrent substantiellement de l'exploitation quotidienne d'un service fiable, et l'équipe LCE peut s'appuyer sur l'expérience de centaines de lancements.

Le rôle de l'ingénieur de coordination de lancement

Les LCE sont soit recrutés directement dans ce rôle, soit des SRE forts d'une expérience opérationnelle des services Google. Ils sont tenus aux mêmes exigences techniques que tout autre SRE, mais on attend aussi d'eux de solides compétences de communication et de leadership : un LCE rassemble des parties disparates autour d'un objectif commun, arbitre les conflits occasionnels, et guide, coache et forme ses pairs. Une équipe dédiée à la coordination des lancements offre trois avantages distinctifs.

Atout	Ce qu'il apporte
Étendue de l'expérience (breadth)	Équipe transverse, active sur presque tous les domaines produits de Google ; un excellent véhicule de transfert de connaissances
Perspective transverse (cross-functional)	Vue holistique du lancement, permettant de coordonner SRE, développement et gestion produit — crucial pour les lancements couvrant une demi-douzaine d'équipes sur plusieurs fuseaux horaires
Objectivité (objectivity)	Conseiller non partisan, le LCE équilibre et arbitre entre parties prenantes : SRE, développeurs, chefs de produit, marketing

Mettre en place un processus de lancement

Google a affiné son processus de lancement sur plus de dix ans. Avec le temps, l'équipe a dégagé les critères qui caractérisent un bon processus de lancement : il doit être léger (facile pour les développeurs), robuste (il attrape les erreurs évidentes), complet (il traite les détails importants de façon cohérente et reproductible), capable de passer à l'échelle (il accommode un grand nombre de lancements simples comme un petit nombre de lancements complexes) et adaptable (il fonctionne pour les types courants — ajouter une nouvelle langue d'interface — comme pour les types inédits, tel le lancement initial du navigateur Chrome ou de Google Fiber).

Certaines de ces exigences sont en conflit manifeste : il est difficile de concevoir un processus à la fois léger et complet. Équilibrer ces critères les uns contre les autres demande un travail continu. Google y parvient grâce à trois tactiques : la simplicité (« maîtriser les fondamentaux, ne pas planifier pour chaque éventualité »), une approche sur mesure (high touch) où des ingénieurs expérimentés ajustent le processus à chaque lancement, et des chemins rapides (fast common paths) qui identifient des classes de lancements suivant toujours le même schéma — par exemple le lancement d'un produit dans un nouveau pays — pour leur offrir un processus simplifié.

La checklist de lancement

Les checklists réduisent les défaillances et garantissent cohérence et exhaustivité dans de nombreuses disciplines : la check-list avant vol en aviation ou la checklist chirurgicale en sont des exemples classiques. De la même façon, le LCE emploie une checklist de lancement (launch checklist) pour qualifier un lancement. Elle aide le LCE à évaluer le lancement et fournit à l'équipe des actions concrètes et des liens vers plus d'information. Quelques exemples d'entrées :

Question  : Avez-vous besoin d'un nouveau nom de domaine ?
  Action  : Coordonner avec le marketing, demander l'enregistrement
            du domaine (formulaire fourni).

Question  : Stockez-vous des données persistantes ?
  Action  : Mettre en place des sauvegardes (instructions fournies).

Question  : Un utilisateur pourrait-il abuser de votre service ?
  Action  : Implémenter rate limiting et quotas (service partagé X).

En pratique, le nombre de questions que l'on peut poser sur un système est quasi infini, et la checklist tend facilement à enfler jusqu'à devenir ingérable. Maintenir une charge raisonnable pour les développeurs exige donc une curation soigneuse. Pour freiner sa croissance, l'ajout d'une nouvelle question a même, à un moment, requis l'approbation d'un vice-président. Le LCE applique aujourd'hui deux règles :

• l'importance de chaque question doit être étayée, idéalement par un désastre de lancement passé ;
• chaque instruction doit être concrète, pratique et raisonnablement réalisable par les développeurs.

La checklist demande une attention continue pour rester pertinente : les recommandations évoluent, des systèmes internes en remplacent d'autres, et certaines préoccupations deviennent obsolètes sous l'effet de nouvelles politiques. Les LCE la curent en continu et y apportent de petites mises à jour ; une à deux fois par an, un membre de l'équipe relit la checklist entière pour repérer les items périmés, puis travaille avec les propriétaires de services et les experts pour moderniser les sections concernées.

Favoriser la convergence et la simplification

Dans une grande organisation, les ingénieurs ignorent souvent l'infrastructure déjà disponible pour des tâches courantes (le rate limiting, par exemple) et risquent de réimplémenter des solutions existantes. Converger vers un ensemble de bibliothèques d'infrastructure communes évite ce gâchis : moins d'efforts dupliqués, un savoir plus aisément transférable entre services, et une qualité d'ingénierie supérieure grâce à l'attention concentrée portée à cette infrastructure. Comme presque tous les groupes de Google participent à un processus de lancement commun, la checklist devient un véhicule pour conduire cette convergence.

Plutôt que d'implémenter une solution ad hoc, le LCE peut recommander une infrastructure existante comme brique de construction — durcie par des années d'usage, et propre à atténuer les risques de capacité, de performance ou de passage à l'échelle. Cette standardisation a radicalement simplifié la checklist elle-même : de longues sections sur les exigences de rate limiting ont pu être remplacées par une seule ligne — « implémentez le rate limiting avec le système X ». Grâce à leur vue panoramique sur tous les produits, les LCE sont aussi idéalement placés pour repérer les opportunités de simplification : ils observent de première main quels pans d'un lancement font le plus trébucher, quelles étapes prennent un temps disproportionné, et quels problèmes sont résolus de manière indépendante encore et encore.

Lancer l'inattendu

Quand un projet entre dans un nouvel espace produit, le LCE doit parfois créer une checklist depuis zéro, en synthétisant l'expérience d'experts du domaine. Il est alors utile de la structurer autour de thèmes larges : fiabilité, modes de défaillance, processus. Avant le lancement d'Android, par exemple, Google avait rarement géré des appareils grand public dotés d'une logique côté client qu'il ne contrôlait pas directement. On peut corriger un bogue de Gmail en quelques heures en poussant du nouveau JavaScript vers les navigateurs ; ce n'est pas une option sur les appareils mobiles. Les LCE ont donc mobilisé des experts du mobile pour déterminer quelles sections des checklists existantes s'appliquaient et où de nouvelles questions s'imposaient. Face à un lancement inhabituel, le LCE doit revenir aux premiers principes d'un lancement sûr, puis se respécialiser pour rendre la checklist concrète et utile.

Les thèmes d'une checklist de lancement

Une checklist est l'instrument d'un lancement à la fiabilité reproductible. Les détails varient d'une entreprise à l'autre, car ils doivent épouser ses services et son infrastructure internes. Voici les grands thèmes extraits des checklists de Google.

Thème	Question type	Action / contre-mesure
Architecture et dépendances	Quel est le flux de requête de l'utilisateur au frontend puis au backend ?	Isoler les requêtes face-utilisateur des autres ; valider les hypothèses de volume (une vue de page = plusieurs requêtes)
Intégration	—	Créer un nom DNS, configurer les répartiteurs de charge, mettre en place le monitoring du nouveau service
Planification de capacité	Le lancement est-il lié à un communiqué de presse ou une promotion ? Quel trafic attendez-vous ?	Obtenir les ressources de calcul à l'avance (délais longs en datacenter) ; certains pics ont atteint 15× l'estimation initiale
Modes de défaillance	Avez-vous des points uniques de défaillance (SPOF) ? Comment atténuer l'indisponibilité d'une dépendance ?	Implémenter des échéances de requête (deadlines) ; délester la charge (load shedding) tôt en surcharge
Comportement du client	Avez-vous de l'auto-save, de l'auto-complétion, des heartbeats ?	Backoff exponentiel sur échec ; ajouter du jitter aux requêtes automatiques
Processus et automatisation	Des processus manuels sont-ils requis pour faire tourner le service ?	Documenter tout processus manuel ; automatiser build et release
Processus de développement	—	Tout le code et la configuration en gestion de version ; couper chaque release sur une branche dédiée
Dépendances externes	De quel code, données, services ou événements tiers dépendez-vous ?	Atténuer via proxys filtrants, pipelines de transcodage, caches ; prévoir le cas où l'échéance ferme n'est pas tenue
Planification du déploiement	—	Établir un plan identifiant chaque action et son responsable ; prévoir des mesures de contingence par étape

Quelques nuances méritent d'être soulignées. En planification de capacité, le profil de charge d'un pic de lancement peut différer fortement de l'état stationnaire, faussant les tests de charge ; lancer d'abord par région ou par pays bâtit la confiance pour des lancements plus larges. La capacité interagit avec la redondance : s'il faut trois déploiements répliqués pour servir 100 % du trafic au pic, il faut en maintenir quatre ou cinq afin d'absorber maintenance et pannes imprévues. Côté comportement du client, l'axiome traditionnel (« doubler la charge exige de doubler les utilisateurs ») ne tient plus dès qu'un client initie des actions sans intervention humaine — une application qui synchronise toutes les soixante secondes plutôt que toutes les six cents impose dix fois la charge. Enfin, en processus, on cherche à minimiser les points uniques de défaillance, y compris les humains : les processus manuels restants doivent être documentés avant le lancement, pendant qu'ils sont frais, de sorte que n'importe quel membre de l'équipe puisse les exécuter en urgence.

Techniques pour des lancements fiables

Google a développé au fil des ans des techniques particulièrement adaptées à un lancement sûr. Elles servent aussi en exploitation courante, mais il est crucial de les maîtriser durant la phase de lancement.

Déploiements progressifs et par étapes

Un adage de l'administration système dit : « ne jamais modifier un système qui tourne ». Tout changement représente un risque, et le risque doit être minimisé — ce qui est doublement vrai pour les systèmes hautement répliqués et mondialement distribués de Google. Très peu de lancements y sont du type « bouton-poussoir », où l'on ouvre un produit au monde entier à un instant précis. Presque toutes les mises à jour progressent graduellement (gradual / staged rollouts), selon un processus défini, ponctué d'étapes de vérification.

Déploiement progressif d'un nouveau serveur

  quelques machines        toutes les machines       toutes les machines
  d'un datacenter   ──►     d'un datacenter    ──►       du monde
   (« canary »)              (observation)            (déploiement global)
        │                         │                         │
   observer N min            observer N min            surveiller
        │                         │
   échec ? rollback          échec ? rollback
   automatique               automatique

Les premières étapes s'appellent les « canaris » (canaries) — allusion aux canaris que les mineurs descendaient au fond pour détecter les gaz dangereux. Les serveurs canaris détectent les effets dangereux du nouveau logiciel sous trafic réel d'utilisateurs. Ce test canari est intégré à de nombreux outils internes : ceux qui gèrent l'installation de logiciels observent le serveur fraîchement démarré pendant un temps, et si le changement échoue à la période de validation, il est automatiquement annulé (rolled back). Le concept s'applique même hors des serveurs Google : une nouvelle version d'une application Android peut être proposée à un sous-ensemble d'installations, le pourcentage augmentant graduellement jusqu'à 100 %. Le système d'invitations (invite system) est une autre forme de déploiement progressif : plutôt que des inscriptions libres, on n'autorise qu'un nombre limité d'utilisateurs par jour, souvent couplé à des invitations qu'un utilisateur peut envoyer à ses amis.

Frameworks de feature flags

Google complète souvent les tests pré-lancement par des stratégies atténuant le risque de panne. Un mécanisme de déploiement lent, autorisant l'observation du comportement global du système sous charge réelle, rentabilise son investissement en fiabilité, en vélocité d'ingénierie et en time to market. Il s'avère précieux quand des environnements de test réalistes sont impraticables, ou pour des lancements complexes aux effets durs à prédire. Tous les changements ne se valent d'ailleurs pas : un simple ajustement d'interface ne devrait pas mobiliser des milliers de lignes de code ni un processus de lancement lourd — on veut parfois tester des centaines de petits changements en parallèle, ou vérifier qu'un petit échantillon d'utilisateurs aime un prototype avant d'investir des mois à durcir une fonctionnalité qui pourrait faire un flop.

Pour ces scénarios, plusieurs produits Google ont conçu des frameworks de feature flags (feature flag frameworks). Le framework lui-même est durci au maximum, de sorte que la plupart de ses applications ne requièrent aucune intervention LCE. Ces frameworks satisfont généralement les exigences suivantes :

• déployer de nombreux changements en parallèle, chacun vers quelques serveurs, utilisateurs ou datacenters ;
• monter graduellement vers un groupe plus large mais limité, généralement entre 1 et 10 % des utilisateurs ;
• router le trafic vers différents serveurs selon l'utilisateur, la session, l'objet ou la localisation ;
• gérer par conception l'échec des nouveaux chemins de code, sans affecter les utilisateurs ;
• annuler indépendamment et immédiatement chaque changement en cas de bogue sérieux ;
• mesurer dans quelle mesure chaque changement améliore l'expérience.

Ces frameworks se rangent en deux classes : ceux qui facilitent surtout les améliorations d'interface, et ceux qui supportent des changements arbitraires de logique métier côté serveur. Le framework le plus simple, pour un service sans état, est un réécriveur de charge HTTP au niveau des serveurs frontaux, limité à un sous-ensemble de cookies. Les services avec état (stateful), eux, limitent plutôt les flags à un sous-ensemble d'identifiants d'utilisateurs connectés ou d'entités produit (l'identifiant d'un document, d'une feuille de calcul) et réacheminent les requêtes vers différents serveurs selon le changement.

Contrôler le client depuis le serveur

La capacité à contrôler le comportement du client depuis le serveur s'est révélée un outil majeur. Pour une application sur un appareil, cela signifie l'instruire de venir périodiquement chercher un fichier de configuration auprès du serveur — fichier qui peut activer ou désactiver des fonctionnalités, ou régler des paramètres comme la fréquence de synchronisation ou de retry. La configuration peut même activer une fonctionnalité entièrement nouvelle : en hébergeant le code dans l'application avant d'activer la fonctionnalité (du code « dormant »), on réduit fortement le risque du lancement, et l'on évite de maintenir des pistes de release parallèles — sans cette technique, un ensemble de fonctionnalités indépendantes livrées sur des calendriers différents imposerait une explosion combinatoire de versions. Surtout, ce code dormant rend l'abandon d'un lancement trivial : si des effets indésirables apparaissent, on coupe simplement la fonctionnalité, on itère, et l'on publie une version corrigée — au lieu de devoir pousser une nouvelle application sur tous les téléphones.

Comportements clients abusifs et tests de charge

L'exemple le plus simple de comportement client abusif est une mauvaise estimation des cadences. Au-delà, les retries (nouvelles tentatives) recèlent de nombreux pièges : un service surchargé qui échoue voit ses clients réessayer, ce qui ajoute de la charge à un service déjà saturé, provoquant encore plus de retries — une spirale. Les clients doivent donc espacer leurs tentatives par un délai croissant exponentiellement (backoff exponentiel) et ne réessayer que pour les erreurs qui le justifient : une erreur réseau, oui ; une erreur HTTP 4xx (erreur côté client), généralement non. La synchronisation, volontaire ou non, de requêtes automatisées en « troupeau tonitruant » (thundering herd) est un autre fléau : un développeur qui décide que 2 h du matin est un bon moment pour télécharger les mises à jour déclenche une rafale de requêtes à 2 h chaque nuit, et quasi aucune le reste du temps. Chaque client devrait au contraire choisir l'instant aléatoirement, et chaque délai de retry être jitteré (ajusté d'une quantité aléatoire) pour lisser ces événements synchronisés.

L'évolution du LCE, et ses limites

Dans les premières années de Google, l'effectif d'ingénierie doublait chaque année, fragmentant l'organisation en petites équipes travaillant sur quantité de produits expérimentaux. Pour éviter que les ingénieurs novices ne répètent les erreurs de leurs prédécesseurs, un petit groupe d'ingénieurs aguerris — les « Launch Engineers » — s'est porté volontaire comme équipe de conseil et a développé les premières checklists (quand consulter le service juridique, comment enregistrer un domaine sans mal configurer le DNS, etc.). Ces « revues de lancement » sont devenues monnaie courante. En 2004, le SRE a doté une équipe permanente de LCE, chargée d'accélérer les lancements tout en garantissant fiabilité, haute disponibilité et faible latence — et d'informer les parties prenantes sur la nature et la probabilité des défaillances chaque fois que des raccourcis étaient pris pour gagner du temps.

L'ampleur du travail a explosé : en trois ans et demi, un seul LCE a fait passer 350 lancements dans la checklist ; avec une équipe d'environ cinq ingénieurs, cela représente plus de 1 500 lancements sur la période. La formation d'un nouvel LCE requiert environ six mois, tant la complexité se cache derrière chaque question apparemment simple. Pour suivre le rythme, les LCE ont identifié des catégories de lancements à faible risque — par exemple une fonctionnalité sans nouveau binaire et avec une hausse de trafic < 10 % — soumises à une checklist quasi triviale, quand les lancements à risque élevé subissaient le parcours complet. En 2008, 30 % des revues étaient considérées à faible risque.

À retenir

• Google définit un lancement comme tout code introduisant un changement visible de l'extérieur, et en réalise jusqu'à 70 par semaine ; ce rythme justifie et permet un processus de lancement rationalisé qu'une entreprise lente n'aurait ni le besoin ni l'expérience de bâtir.
• L'équipe Launch Coordination Engineering (LCE) est une équipe de conseil interne au SRE qui audite, fait la liaison, pilote, valide (gatekeeper) et forme — apportant étendue d'expérience, perspective transverse et objectivité, et toujours incitée à prioriser la fiabilité.
• Un bon processus de lancement est à la fois léger, robuste, complet, scalable et adaptable — critères en tension, équilibrés par la simplicité, l'approche sur mesure et des chemins rapides ; un processus trop lourd sera contourné.
• La checklist de lancement garantit des lancements reproductibles ; chaque question doit être étayée par un désastre passé et chaque action concrète, sous peine de voir la liste enfler — elle sert aussi à faire converger les équipes vers une infrastructure commune.
• Les déploiements progressifs (canaris avec rollback automatique), les feature flags (déploiement de 0 à 100 %, annulation indépendante) et le contrôle du client depuis le serveur (code dormant) permettent de lancer en minimisant le risque.
• Contrôler le client depuis le serveur — via un fichier de configuration récupéré périodiquement — permet d'activer, de désactiver ou d'ajuster des fonctionnalités à distance, et de bâtir des commutateurs d'arrêt d'urgence (kill switches) comme les « interrupteurs anti-larmes d'enfants » de NORAD Tracks Santa ; couplé au code dormant embarqué à l'avance, il rend l'abandon d'un lancement trivial.
• Anticiper les comportements clients abusifs (backoff exponentiel, jitter contre le thundering herd) et la surcharge non linéaire est vital ; comme on prédit mal la réaction à la saturation, les tests de charge sont requis pour la plupart des lancements.