DevOps et ingénierie SRE

Ingénierie de plateforme : tirez parti de l’expérience Google

Fri, 24 Oct 2025 05:00:00 +0000

Comment abordez-vous le développement logiciel ? Chez Google, nous nous efforçons constamment de créer de meilleurs services, plus rapidement. Pour y parvenir, notre équipe Developer Platform et Google Cloud ont noué un partenariat stratégique et se mobilisent autour d’une vision commune : capitaliser sur nos solutions internes et nos outils d’ingénierie pour les mettre à disposition des clients Google Cloud.

Le premier défi du développement logiciel consiste à bien comprendre comment les équipes, petites ou grandes, peuvent trouver le juste équilibre entre efficacité, qualité et coûts, tout en créant de la valeur. À l’occasion de notre récente intervention lors de PlatformCon 2025, nous avons présenté les éléments clés de notre approche de l’ingénierie de plateforme, une approche que nous avons baptisée « shift down ».

Le shift down consiste à intégrer les décisions et les responsabilités directement au sein des plateformes internes de développement (IDP), afin de réduire la charge opérationnelle qui pèse sur les développeurs. Elle se distingue de la tendance DevOps du shift left, qui vise à déplacer davantage d’efforts en amont du cycle de développement, une méthode qui montre ses limites à grande échelle face à l’ampleur et au rythme des évolutions des besoins.
Là où le shift left tend à alourdir la charge des équipes lorsqu’il est appliqué à grande échelle, le shift down cherche au contraire à tirer le maximum de valeur des ressources existantes. Cette approche permet aux entreprises d’innover rapidement tout en maintenant un niveau de qualité, de risque et de coûts soutenables, quels que soient leurs modèles économiques.

Lors de notre intervention, nous avons partagé plusieurs enseignements qui se sont révélés particulièrement utiles dans notre démarche en matière de développement logiciel et d’ingénierie de plateforme :

Partir du modèle économique. En prenant le modèle économique comme point de départ, les organisations peuvent orienter l’évolution de leur plateforme et de leurs investissements en fonction de leurs objectifs de marge, de leur tolérance au risque et de leurs exigences de qualité. Chez Google, notre plateforme centrale doit répondre à une grande diversité de modèles économiques, ce qui impose un travail constant de raffinement stratégique et d’adaptation..
Se concentrer sur les critères de qualité pour un pilotage centralisé. Les critères de qualité — fiabilité, sécurité, efficacité et performance — sont des caractéristiques transverses émergentes (ou emergent properties) des systèmes logiciels. Elles jouent un rôle essentiel pour créer de la valeur métier et maîtriser les risques. On les qualifie souvent « d’exigences non fonctionnelles » car ils décrivent la manière dont le logiciel se comporte, et non ce qu’il fait fonctionnellement. Avec une stratégie shift down, la responsabilité de ces critères de qualité peut être intégrée directement au sein des systèmes et de l’infrastructure de la plateforme, réduisant ainsi considérablement la charge opérationnelle qui pèse sur chaque développeur.
Abstractions et couplage, deux leviers essentiels pour maîtriser les critères de qualité. Notre approche de la conception de plateformes repose sur deux leviers techniques essentiels pour maîtriser les critères de qualité : les abstractions et le couplage. Dans une stratégie shift down, les abstractions permettent de rendre les systèmes plus compréhensibles, de mieux gérer les risques, de clarifier les responsabilités et de contrôler les coûts en encapsulant la complexité. Le couplage, quant à lui, indique le degré d’interconnexion et d’interdépendance entre les composants d’un système ou d’un écosystème de développement. Pour réussir une stratégie shift down, le bon niveau de couplage est déterminant, car il permet à la plateforme et à l’écosystème de développement d’intégrer et d’influencer directement les critères de qualité. Concrètement, c’est grâce au couplage que nous pouvons proposer des solutions complètes d’infrastructure et de plateforme sous forme de services cohérents, comme Google Kubernetes Engine (GKE).
Responsabilités partagées, formation et règles communes sont des leviers « sociaux » essentiels. À grande échelle, la responsabilité partagée constitue un levier organisationnel déterminant. Elle repose d’abord sur la formation, par exemple en sensibilisant les ingénieurs à l’usage des plateformes et de l’IA. Elle s’appuie aussi sur la promotion d’une culture one team (« une seule équipe ») afin d’encourager les profils centrés sur un livrable ou un composant donné à s’ouvrir à la mission globale et à l’engagement envers les clients. Par ailleurs, des règles explicites, comme des guides de style appliqués de manière centralisée ou des API conçues dès l’origine pour être sécurisées (secure by design), permettent d’intégrer des garanties de qualité directement dans la plateforme et l’infrastructure, réduisant ainsi considérablement la charge opérationnelle des développeurs tout en assurant la cohérence et l’automatisation des contrôles à grande échelle.
Utiliser une cartographie. Gérer les besoins de nombreuses entités métiers avec une seule plateforme est un problème vaste et complexe : il vous faut donc une cartographie. Chez Google, nous utilisons ce que nous appelons le modèle d’écosystème, un framework conceptuel qui fait office de cartographie et qui permet de classer les différents environnements de développement logiciel, allant de systèmes très flexibles, sous contrôle direct des développeurs, à des environnements fortement intégrés et normés, où c’est l’écosystème lui-même qui garantit les critères de qualité. Le rôle essentiel de ce framework est de fournir un outil visuel et conceptuel permettant d’évaluer dans quelle mesure les mécanismes de contrôle de l’écosystème sont alignés avec les risques métier. Autrement dit, il sert à vérifier que le niveau de supervision et de garantie des critères de qualité est proportionné au coût potentiel des erreurs. L’objectif est de rester dans la « zone d’efficacité de l’écosystème » : un équilibre où les contrôles suffisent à limiter les risques majeurs liés aux erreurs humaines, sans pour autant imposer de contraintes excessives qui ralentiraient l’innovation et démotiveraient les développeurs.

6. Segmenter le problème en identifiant les différents types de plateformes et d’écosystèmes. L’expérience développeur et l’infrastructure de la plateforme évoluent en fonction de l’échelle et du degré de shift down. Il ne suffit donc pas de savoir où se situe la « zone d’efficacité de l’écosystème » : il faut aussi identifier le type d’écosystème auquel on a affaire. Nous distinguons les écosystèmes en fonction du niveau de supervision et de garantie appliqué aux critères de qualité. Plus un écosystème devient intégré verticalement — comme l’écosystème fortement optimisé « Assured » de Google (Type 4) — plus la plateforme prend nativement en charge des critères de qualité essentiels. Cela permet aux spécialistes, tels que les site reliability engineers (SRE) ou les équipes de sécurité, d’assumer pleinement leur rôle grâce à une observabilité à grande échelle et à des capacités intégrées. À l’inverse, dans des écosystèmes moins homogènes comme « YOLO », « AdHoc » ou « Guided » (Types 0 à 2), les développeurs gèrent une part plus importante de la responsabilité en matière de qualité, tandis que les équipes spécialisées disposent de moins de leviers de contrôle direct et de mécanismes d’application moins étendus. Précisons toutefois : les modèles précités (Assured, YOLO, AdHoc et Guided) ne sont pas des indicateurs de maturité. Le meilleur type d’écosystème et de plateforme est simplement celui qui correspond le mieux aux besoins de votre entreprise (cf. point n°1 ci-dessus !).

Faire les bons choix en matière d’ingénierie de plateforme

En résumé, la leçon la plus importante à retenir, c’est qu’il faut bien peser ses choix et prendre des décisions éclairées. L’ingénierie de plateforme doit être adaptée à chaque entité métier et à chaque application afin d’obtenir les meilleurs résultats. Elle doit avant tout s’attacher à repérer les problèmes récurrents, qui reviennent systématiquement dans différents domaines métier, pour les résoudre une bonne fois pour toutes avec des solutions robustes et réutilisables. Cette approche est au cœur de notre stratégie de shift down. Elle vise à aller vers des plateformes composables, capables d’intégrer directement dans l’infrastructure les décisions et les responsabilités liées à la qualité logicielle. Concrètement, cela signifie que la plateforme prend en charge directement les choix et les responsabilités liés à la qualité logicielle (sécurité, fiabilité, performance, etc.), au lieu de les laisser reposer uniquement sur les développeurs. Dit autrement, avec l’approche shift down, vous renforcez votre capacité à maximiser la valeur métier en mobilisant les bonnes ressources, au niveau de qualité requis, et avec des coûts maîtrisés dans la durée.

Pour aller plus loin, n’hésitez pas à consulter l’intégralité de notre intervention à PlatformCon 2025 sur le sujet.

Pour vos besoins de modernisation, oubliez le "Shift Left" ! Visez le "Shift Down" !

Tue, 04 Mar 2025 08:00:00 +0000

Bienvenue sur notre toute première publication de « The Modernization Imperative », également connu sous le nom de "TMI", un acronyme qui capture parfaitement notre mission : partager avec enthousiasme tout ce qui concerne la Tech.

Cette chronique portée par les leaders de Google Cloud veut, au fil des épisodes, explorer l'univers du développement logiciel, des systèmes distribués, du serverless, des microservices, du DevOps & SRE, des opérations de plateforme... bref, tous les buzz words qui font vibrer nos experts !

Aujourd'hui, c'est Richard Seroter qui prend la plume. Directeur de la Stratégie et de l'Engagement pour l'équipe Infrastructure Moderne de Google Cloud, il cogite sur ces sujets depuis près de 20 ans.

Alors, chers lecteurs, accrochez-vous : après tout, quand on parle d'infrastructure moderne, il n’y a jamais trop d'infos !

Seul au volant d'une voiture glaciale, le petit Richard alors âgé de 10 ans se prenait pour un roi. « Vroom, vroom… Regarde-moi, je conduis ! » lançais-je fièrement à mon passager imaginaire. Ce n'est que des années plus tard que j'ai compris le stratagème de ma mère. Elle me "laissait" démarrer notre voiture. J'étais tellement ébloui par mes talents de pilote hors pair que je ne réalisais pas que je faisais une tâche dont elle voulait se débarrasser : faire chauffer le moteur et monter la température interne du véhicule avant notre trajet matinal.

Aujourd'hui ? Rien n'a vraiment changé, sauf ma lucidité. À quarante et quelques années, me voilà en train de marteler frénétiquement l'écran tactile d'une caisse automatique, cherchant désespérément le code des « raisins sans pépins » tout en savourant le « privilège » de scanner moi-même et d'emballer mes propres courses.

De ma mère à mon supermarché local en passant par le développement logiciel, redistribuer les tâches d'un groupe à un autre est une étape cruciale pour optimiser les ressources. Aujourd'hui, nous demandons à nos développeurs de pratiquer du "Shift Left" et de s'adapter à des méthodologies en constante évolution.

Mais c'est un fardeau lourd à porter. Plutôt que de surcharger nos développeurs, pourquoi ne pas maximiser leurs talents en exploitant pleinement l'éventail des outils et services à leur disposition ?

Certes, le « Shift Left » - cette pratique qui consiste à intégrer les contrôles de sécurité et de qualité plus tôt dans le processus de développement - est une idée tout à fait sensée. Mais au fil des ans, de plus en plus de tâches, traditionnellement hors du périmètre des développeurs, ont « glissé vers la gauche » au nom de la sacro-sainte polyvalence et autonomisation des « ingénieurs full stack ». Il est temps que cela cesse.

[Mini coup de gueule, mais justifié : Il y a genre neuf vrais « ingénieurs full stack » sur Terre. Pratiquement personne ne code un frontend en React, ne configure Kubernetes, ne paramètre une instance RabbitMQ, ne provisionne de l'espace sur un SAN et n'allume un switch top-of-rack, tout ça dans une même journée. Aujourd'hui, on demande aux développeurs de maîtriser les frameworks web, les patterns d'architecture, les stratégies de test, les systèmes de build, de multiples types de bases de données, les caches, les outils d'automatisation, les orchestrateurs de conteneurs, les concepts réseau L4-L7, les API SaaS, les systèmes de monitoring, de nombreux clouds publics, et oh, pourquoi pas un peu de machine learning ! Je viens de parcourir Indeed.com, et c'est hallucinant de voir ce qu'on exige des développeurs juniors et seniors. C'est trop, tout simplement.]

En tant qu’industrie, nous ne pouvons rester immobiles et ne pas intervenir.

Shift Down !

Dans un premier temps, au lieu de dire aux développeurs (et à leurs managers !) de tout « décaler à gauche » (un Shift Left), nous devrions les encourager à « descendre d'un cran » (un Shift Down) et tirer pleinement parti des technologies disponibles en refilant le boulot aux plateformes qu'ils utilisent déjà.

Simplifiez votre pile technologique. N'obligez pas les gens à tout connaître pour faire leur job. Offrez des abstractions de plateforme. J'ai récemment fait une présentation pour un client sur « comment Google pratique le DevOps », mettant ainsi en lumière le nombre conséquent de plateformes que nous offrons à nos ingénieurs. Nous proposons des solutions managées pour le codage, les tests, la compilation, les déploiements, l'hébergement, les alertes et bien plus encore. Des équipes dédiées chez Google soutiennent ces plateformes essentielles afin que nos ingénieurs produits puissent se concentrer sur leur travail sans avoir à connaître ou gérer une "pile complète" d'infrastructure. Et, chaque organisation devrait en faire autant.

Au lieu d'exiger toujours plus de leurs équipes d'ingénierie actuelles - en leur demandant d'apprendre de nouveaux langages, plateformes et clouds - les dirigeants technologiques devraient désormais chercher à assembler des équipes d'ingénierie de plateforme qui traitent leurs diverses plateformes comme des produits à part entière.

L’optimisation commence par la réduction de la charge cognitive des développeurs et l’élimination des tâches inutiles qui les détournent de l’innovation. En parallèle, il est essentiel de leur fournir les outils et l’infrastructure nécessaires pour exploiter la puissance de l’IA et des modèles de langage (LLM). Ainsi, vos développeurs pourront se concentrer sur la création plutôt que sur des tâches répétitives. Nous mettons actuellement en place davantage de coaching et de supports pour aider chacun à adopter l'ingénierie de plateforme, alors restez à l'écoute !

Tout un potentiel à portée de mains

Dans un second temps, en tant que fournisseurs de cloud, nous pouvons accompagner les développeurs avec des principes universels de "déchargement", de « Shift down », qui assurent un partage de la charge de gestion de l'infrastructure.

J'apprécie, par exemple, que GKE Autopilot me fournisse à la demande un cluster Kubernetes sécurisé et managé, sans perturber mon flux de travail. Si vous devez utiliser Kubernetes, adoptez la méthode Autopilot et dites adieu aux prises de tête liées au provisionnement d'un cluster qui vous détourne du développement.

Autre exemple, vous voulez une chaîne d'approvisionnement sécurisée ? Ne demandez pas à un humain de décoder les manifestes Supply Chain Levels for Software Architects (SLSA). Ajoutez automatiquement des attestations aux builds (comme nous le faisons avec Cloud Build) et transformez les vérifications d’exécution… en une simple case à cocher !

Parallèlement, rendez les services hautement disponibles par défaut au lieu de demander à un développeur de se débrouiller. Nos services comme Pub/Sub, Firestore, Spanner, Cloud Storage ou Cloud Logging fonctionnent "tout simplement" et nativement de cette façon.

Nous pouvons également intervenir à un niveau plus bas, en aidant quelqu’un à analyser CloudEvents dans son code au lieu de le laisser se débrouiller seul.

Enfin, avec des outils comme Generative AI App Builder, les développeurs peuvent rapidement proposer de nouvelles expériences captivantes, telles que des assistants digitaux, des moteurs de recherche personnalisés, des interfaces de chat, et bien plus encore. Offrir aux clients des frameworks structurés mais extensibles, qui maximisent leur investissement technologique, est la clé d'une expérience cloud réussie.

Chez Google Cloud, nous aidons les entreprises à utiliser des technologies incroyables pour réaliser des choses extraordinaires. Pour y parvenir, nous créons des outils et des services qui offrent aux développeurs une expérience matérielle et logicielle sécurisée par conception (secure by design). Cela leur permet d'appliquer de façon totalement automatisée nombre de bonnes pratiques de "Shift Left", accélérant ainsi le développement. En assignant efficacement les workloads, nous veillons à ce que les ressources d'ingénierie restent disponibles et performantes au maximum de leur capacité, au moment où vous en avez le plus besoin.

Être développeur en 2024 est une expérience extraordinaire. Mais le job s’accompagne d’une charge mentale parmi les plus lourdes, toutes professions confondues. Plutôt que de surcharger les équipes de devs avec toujours plus de responsabilités dans le cycle de vie du logiciel, chez Google Cloud nous aidons nos clients à mettre en place une approche « plateforme » qui favorise une culture d’ingénierie durable et innovante. En adoptant les pratiques de « Shift Down » et en exploitant pleinement les avantages d'une stack technologique complète, l'innovation s’épanouit grâce à des automatisations bien ficelées et des services managés.

Nous sommes aujoud’hui à l'aube d'une nouvelle ère de technologies dopées par l'IA, où la création de code se simplifie et où les devs se tournent vers des chatbots en langage naturel pour obtenir des conseils en temps réel. Il est temps d’offrir aux développeurs du monde entier les moyens de favoriser le succès technologique et commercial. Et, contrairement au jeune Richard d’une dizaine d’années, leur permettre vraiment d’aller quelque part…

GenOps : s’inspirer du monde des microservices et du DevOps classique

Fri, 24 Jan 2025 06:00:00 +0000

Mais qui donc va gérer les applications d’IA générative ? Bien que la responsabilité de l'IA soit souvent confiée aux équipes de données, nous constatons que les exigences spécifiques aux applications d'IA générative diffèrent sensiblement de celles des équipes de données et d'IA traditionnelles.

En fait, ces exigences s'apparentent parfois davantage à celles d'une équipe DevOps. Nous allons ici explorer ces similitudes et différences, et examiner la nécessité de créer une nouvelle équipe "GenOps" pour répondre aux caractéristiques spécifiques des applications d'IA générative.

Contrairement aux pratiques de la Data Science, qui vise à créer des modèles à partir de données, l'IA générative se concentre sur la création de services dopés à l'IA à partir de modèles IA. Dit autrement, la GenAI implique une complexe intégration de données préexistantes, de modèles et d'API. Vu sous cet angle, l'IA générative ressemble dès lors étonnamment à un environnement de microservices traditionnel : plusieurs services distincts, découplés et interopérables, consommés via des API. Si le paysage présente des similitudes, il est logique que ces domaines partagent des exigences opérationnelles communes. Alors, quelles pratiques pouvons-nous emprunter au monde des microservices et du DevOps pour les appliquer au nouveau domaine du GenOps ?

Que mettons-nous en œuvre ? L'agent IA versus le microservice

En quoi les exigences opérationnelles d'une application d'IA générative diffèrent-elles des autres applications ?

Dans les applications traditionnelles, l'unité « opérationnelle » est le microservice : une unité de code fonctionnelle et distincte, encapsulée dans un conteneur et déployée dans un environnement d'exécution compatible avec les conteneurs, comme Kubernetes.

Pour les applications d'IA générative, l'unité comparable est l'agent d'IA générative, ou Agent IA. Il s'agit également d'une unité de code fonctionnelle et distincte, conçue pour gérer une tâche spécifique, mais avec des composants supplémentaires qui en font plus qu'un "simple" microservice.

Ces composants lui confèrent sa caractéristique distinctive clé : un comportement non déterministe tant dans son traitement que dans ses résultats. Voici ces composants :

1- Boucle de raisonnement - La logique de contrôle qui définit ce que fait l'agent et comment il fonctionne. Elle inclut souvent une logique itérative ou des chaînes de réflexion pour décomposer une tâche initiale en une série d'étapes animées par des modèles IA, qui travaillent à l'accomplissement de la tâche.

2- Définitions de modèles - Une ou plusieurs méthodes d'accès prédéfinies pour communiquer avec les modèles, lisibles et utilisables par la boucle de raisonnement.

3- Définitions d'outils - Un ensemble de méthodes d'accès prédéfinies pour agir sur d’autres services externes à l’agent, tels que d’autres agents, des flux d’accès aux données (RAG), et des API externes. Ces définitions devraient être partagées entre les agents et exposées via des API. Par conséquent, une définition d’outil prendra la forme d’une norme lisible par machine, comme une spécification OpenAPI.

Les composants logiques d’un Agent d’IA Générative

En poursuivant les analogies évoquées plus haut, on peut considérer que « la boucle de raisonnement » correspond essentiellement au spectre fonctionnel d'un microservice, autrement dit à l’ensemble des fonctions, opérations, processus et responsabilités typiques d’un microservice. Les définitions de modèles et d'outils constituent des capacités supplémentaires qui en étendent le potentiel.

Il est important de noter que, bien que la logique de la boucle de raisonnement ne soit que du code et donc soit de nature déterministe, elle est pilotée par les réponses de modèles d'IA qui sont, eux, non déterministes. Cette nature non déterministe justifie le besoin d'outils, car l'agent "choisit par lui-même" quel service externe utiliser pour accomplir une tâche. Au contraire, un microservice traditionnel est typiquement entièrement déterministe. Il n'a pas besoin de ce "livre de recettes" d'outils parmi lesquels choisir : ses appels aux services externes sont prédéterminés et codés en dur.

D’autres similarités émergent par ailleurs. Tout comme un microservice, un agent :

Est une unité fonctionnelle distincte qui devrait être partagée entre plusieurs applications, utilisateurs et équipes dans un modèle multi-locataire (multi-tenant).
Offre une grande flexibilité dans les approches de développement, avec un large éventail de langages de programmation disponibles. Chaque agent peut être construit d'une manière différente des autres.
Présente une très faible interdépendance d'un agent à l'autre : les cycles de développement sont découplés, avec des pipelines de CI/CD indépendants pour chacun. La mise à jour d'un agent ne devrait pas affecter un autre agent.

Plateformes opérationnelles et répartition des responsabilités

Ce que le tableau ci-dessus ne dit pas, c’est qu’il existe une autre différence majeure : la découverte de services.

Dans le monde des microservices, ce problème est déjà résolu. Les microservices n’ont plus à se soucier de la disponibilité, de l’emplacement ou des aspects réseau leur permettant de communiquer entre eux. Ces difficultés leur ont été retirées en les regroupant dans des conteneurs et en les déployant sur des plateformes communes comme Kubernetes et Istio.

Pour les agents d’IA générative, cette standardisation n’existe pas encore. Il y a plusieurs façons de créer et de déployer un agent d’IA générative, allant des solutions “bricolées” avec des bouts de code aux environnements managés de création d’agents en no-code. Bien que ces outils soient utiles, ils créent un paysage de déploiement plus varié que celui des microservices, ce qui pourrait à l’avenir engendrer des complications opérationnelles.

Pour résoudre cette difficulté, il est par exemple possible d’adopter un modèle en étoile (ou hub-and-spoke) au lieu du traditionnel modèle point-à-point utilisé sur les microservices. Dans un modèle en étoile, la découverte des agents, des outils et des modèles se fait via la publication d'API sur une passerelle API. Cette dernière vient offrir une couche d’abstraction cohérente au-dessus de ce paysage hétérogène d’agents. En d’autres termes, au lieu d’avoir des connexions directes entre tous les éléments (comme dans les microservices), on crée un point central (le hub) qui gère toutes les connexions. Cela simplifie la gestion et la communication entre les différents composants, même s’ils sont très variés.

Il en résulte un avantage supplémentaire : une séparation claire et nette des responsabilités entre, d'une part, les applications et les agents créés par les équipes de développement et, d'autre part, les composants spécifiques à l'IA générative, comme les modèles et les outils.

Séparation des responsabilités grâce à une API Gateway (Passerelle d’API)

En pratique, toute plateforme vraiment opérationnelle se doit de bien séparer les rôles et responsabilités entre les équipes de développements (d’apps et microservices) et les équipes des opérations IT.

Dans le cas des applications basées sur des microservices, le transfert des responsabilités se fait au moment du déploiement. À partir de ce moment clé, l'attention se porte sur les exigences non fonctionnelles telles que la fiabilité, la scalabilité, l'efficacité de l'infrastructure, la gestion du réseau, la sécurité.

Bien évidemment ces exigences restent tout aussi importantes pour une application d'IA générative. Néanmoins, j’estime qu'il existe des considérations supplémentaires spécifiques aux agents IA et aux applications IA génératives. Ces considérations nécessitent des outils opérationnels particuliers que je vais ici détailler :

Contrôles de conformité et d'approbation des modèles

Le monde des modèles d'IA est une vraie jungle ! On en trouve à toutes les sauces : open source, sous-licence, avec ou sans protection de la propriété intellectuelle. Chacun vient avec son lot de conditions d'utilisation, souvent complexes et pleines de pièges juridiques. Décrypter tout ça est un vrai casse-tête qui demande du temps et les compétences adéquates.

Soyons réalistes : on ne peut pas demander aux développeurs de jongler avec ces considérations quand ils choisissent un modèle. Ce serait comme leur demander d'être à la fois codeurs et avocats ! Dès lors, il devient essentiel de mettre en place un processus dédié de révision et d'approbation des modèles. Ce processus, géré par les équipes juridiques et de conformité, doit être soutenu techniquement par des procédures d'approbation ou de refus claires, gouvernables et auditées, qui se répercutent en cascade dans les environnements de développement.

Ainsi, l’entreprise s'assure que les choix de modèles sont non seulement techniquement solides, mais aussi juridiquement blindés. C'est la garantie d'une utilisation sereine et maîtrisée de l'IA dans votre organisation !

2 – Gestion des versions des prompts

Les prompts, ou invites ou encore instructions en français, ces petites phrases magiques qui font danser les modèles, doivent être optimisés pour chacun d’eux. Dit autrement, chaque modèle a besoin de prompts rédigés sur mesure pour donner le meilleur de lui-même.

Dès lors se pose une question fondamentale : est-ce vraiment le boulot des équipes de développements d’application de passer des heures à peaufiner des prompts ? Ne devraient-elles pas plutôt se concentrer sur ce qu'elles font de mieux : créer des apps d’exception qui font la différence pour les métiers ?

La gestion des prompts est un peu comme la plomberie d'un bâtiment, essentielle mais invisible. Évolutive, elle a tout à gagner à être séparée du code source des applications et à être gérée de manière centralisée. Il devient ainsi possible d’évaluer périodiquement les prompts et de les faire évoluer sans modifier les codes sources. Mieux encore, il est ainsi plus aisé de réutiliser les meilleurs prompts (et rentabiliser le travail nécessaire à leur création) à travers différentes applications et agents.

Évaluation des modèles (et des prompts)

Les modèles sont comparables à des athlètes de haut niveau dont il faut mesurer en permanence l’évolution des performances.
Tout comme avec une plateforme MLOps, il existe un réel besoin d'évaluations continues de la qualité des réponses des modèles. Objectif ? Disposer d’une approche basée sur les données pour évaluer et sélectionner les modèles les plus adaptés au cas d'utilisation considéré.
La principale différence avec les modèles d'IA générative est que l'évaluation est intrinsèquement plus qualitative par rapport à l'analyse quantitative du biais ou de la détection de dérive d'un modèle ML traditionnel.
L'IA générative vient cependant pimenter les choses avec son lot de subtilités ! Contrairement aux modèles ML traditionnels, où l'on peut facilement mesurer des dérives ou des biais avec des chiffres, l’IA générative demande d’évaluer, de juger, la qualité des réponses. Or il n’est pas toujours évident de mettre une note précise !

Les évaluations subjectives et qualitatives effectuées par des humains ne sont clairement pas évolutives et introduisent de l'incohérence lorsqu'elles sont réalisées par plusieurs personnes. À la place, nous avons besoin de pipelines automatisés cohérents alimentés par des évaluateurs IA qui, bien qu'imparfaits, assureront une cohérence dans les évaluations et fourniront une base de référence pour comparer les modèles entre eux.

Une telle approche basée sur l’IA offre une perspective plus précise, reproductible et impartiale sur les performances et les évolutions des modèles et des prompts. Elle permet d’intégrer une surveillance continue et « data-driven » pour garantir une utilisation optimale et éclairée des ressources IA.

Passerelle de sécurité des modèles

La fonctionnalité opérationnelle dont j'entends le plus souvent parler dans les grandes entreprises est un proxy de sécurité. Son rôle ? Effectuer des vérifications (éthiques et de sécurité/conformité) avant de transmettre une requête à un modèle (et vice versa : vérifier la réponse générée avant de la renvoyer à l’utilisateur).

Les points clés à considérer au niveau du Proxy de Sécurité :

Anticiper, détecter et bloquer les attaques par injection de prompt et autres menaces identifiées par l'OWASP Top 10 pour les LLM.
Détecter et bloquer les prompts nuisibles ou contraires à l'éthique
Repérer et traiter les données personnelles des clients ou autres informations sensibles nécessitant une censure ou une anonymisation avant d'être envoyées au modèle et aux systèmes IA en aval.

Certains modèles disposent de contrôles de sécurité intégrés. Toutefois cette intégration peut créer de l'incohérence et augmenter la complexité. Autre solution ? Mettre en place un point d'accès sécurisé indépendant du modèle, placé en amont de tous les modèles. Il en résulte une plus grande cohérence globale et une facilité accrue pour passer d'un modèle à l'autre.

Gestion centralisée des outils

Pour finir, les outils accessibles à l'agent IA devraient être séparés de celui-ci. Pourquoi ? Pour permettre leur réutilisation et une gouvernance centralisée. C'est la bonne façon de répartir les responsabilités, surtout quand il s'agit d’exploiter des données dont l'accès doit être contrôlé.

Les modèles RAG (Retrieval-Augmented Generation) ont tendance à se multiplier et à se complexifier. En pratique, ils ne sont pas toujours très robustes ni bien entretenus, ce qui peut engendrer une dette technique importante. D'où l'importance d'un contrôle centralisé pour garder les méthodes d'accès aux données aussi saines et visibles que possible.

Au-delà de ces considérations spécifiques, il est essentiel — comme nous l'avons évoqué ci-dessus — de disposer d’une passerelle API pour créer de la cohérence et une couche d'abstraction au-dessus de ces services d'IA générative. Utilisées à leur plein potentiel, les passerelles API peuvent jouer un rôle bien plus important qu'un simple point d'accès API. Elles peuvent devenir un centre de coordination et de regroupement pour une série d'appels API intermédiaires, de logiques diverses, de fonctionnalités de sécurité et de suivi d'utilisation.

Prenons l'exemple d'une API publiée pour envoyer une requête à un modèle. Elle peut être le point de départ d'un processus en plusieurs étapes :

Récupérer et "hydrater" le modèle de prompt optimal pour ce cas d'utilisation et ce modèle spécifique.
Effectuer des vérifications de sécurité via le service de sécurité du modèle.
Envoyer la requête au modèle.

Enregistrer le prompt, la réponse et d'autres informations pour les utiliser dans des processus opérationnels tels que les pipelines d'évaluation des modèles et des prompts.

Les principales composantes d’une plateforme GenOps

Concrétiser le GenOps avec Google Cloud

Bien évidemment (mais en doutiez-vous ?), pour chacune des considérations évoquées ci-dessus, Google Cloud propose des services managés uniques et différenciants pour aider à évaluer, déployer, sécuriser et mettre à niveau les applications et agents d'IA générative :

Pour les contrôles de conformité et d'approbation des modèles :
Le "Model Garden" de Google Cloud est la bibliothèque centrale regroupant plus de 150 modèles propriétaires de Google, de partenaires ou open source, avec des milliers d'autres disponibles grâce à une intégration directe avec Hugging Face.
Pour la sécurité des modèles :
Le tout nouveau "Model Armor", actuellement en preview, permet l'inspection, le routage et la protection des prompts et des réponses des modèles fondation. Il peut aider à atténuer les risques tels que les injections de prompts, les contournements de sécurité, les contenus toxiques et les fuites de données sensibles.
Pour la gestion des versions de prompts :
De nouvelles fonctionnalités de gestion des prompts ont été annoncées lors de Google Cloud Next '24, incluant le contrôle de version centralisé, la création de modèles, la gestion de branches et le partage de prompts. Nous avons également présenté des capacités d'assistance IA pour critiquer et réécrire automatiquement les prompts.
Pour l’évaluation des modèles (et des prompts) :
Les services d'évaluation automatisée de modèles de Google Cloud offrent des évaluations par l’IA avec une large gamme de métriques, de prompts et de réponses. Ils permettent des schémas d'évaluation flexibles et extensibles. Par exemple, vous pouvez comparer les réponses de deux modèles différents pour une même entrée, ou encore analyser les résultats obtenus avec deux prompts distincts sur un seul modèle.
Pour la gestion centralisée des outils :
Une suite complète de services managés est disponible pour soutenir la création d'outils. Parmi ceux-ci, on peut citer Document AI Layout Parser pour le découpage intelligent de documents, l'API d'embeddings multimodaux, Vertex AI Vector Search, et je tiens particulièrement à souligner Vertex AI Search : un service RAG entièrement managé, prêt à l'emploi, qui gère toutes les complexités, de l'analyse et du découpage des documents à la création et au stockage des embeddings.

Cette approche intégrée de Google Cloud permet aux entreprises de tirer pleinement parti des technologies d'IA générative tout en maintenant un contrôle et une sécurité optimaux.

En ce qui concerne la passerelle API, Apigee de Google Cloud permet de publier et d'exposer des modèles et des outils IA sous forme de proxies API. Ces proxies peuvent englober plusieurs appels API en aval, tout en intégrant une logique conditionnelle, des mécanismes de réessai, ainsi que des outils pour la sécurité, le suivi de l'utilisation et la refacturation interne.

La plateforme GenOps de Google Cloud avec ses outils et services managés

Peu importe la taille de votre entreprise, pour réussir avec l'IA générative, un impératif s'impose : maîtriser les spécificités et les besoins uniques de vos applications d'IA. C'est là qu'entre en jeu une plateforme opérationnelle taillée sur mesure, votre meilleure arme pour relever ces défis. Et c’est là que Google Cloud vous vient en aide avec sa plateforme GenOps Cloud pour l’IA générative.

J'espère que les idées présentées dans ce billet vous seront utiles pour naviguer dans cette ère technologique révolutionnaire. L'IA générative bouleverse nos façons de faire, et c'est passionnant !

Envie d'en savoir plus ? N'attendez pas ! Contactez votre équipe Google Cloud ou lancez-moi un message directement. Ensemble, explorons les possibilités infinies de l'IA générative pour booster votre business.

Débuter une carrière en ingénierie de plateforme : les fondamentaux

Tue, 05 Nov 2024 09:00:00 +0000

Imaginez un instant que vous soyez ingénieur dans l'entreprise Acme Corp et que l'on vous confie un grand projet : intégrer et fournir des logiciels en utilisant l’approche CI/CD et l'automatisation tout en mettant en place des métriques et des outils d'observabilité.
Malheureusement, les membres de votre équipe sont déjà submergés par une trop lourde charge mentale, provoquée par le déploiement et l'automatisation des clusters Kubernetes, la configuration des pipelines CI/CD sans oublier toutes les préoccupations concernant la sécurité.
Vous réalisez alors que si vous voulez pouvoir monter en charge et soutenir la croissance de votre entreprise, vous allez devoir adopter une nouvelle approche pour relever les défis de votre nouvelle mission. Pas de panique : C’est précisément là que l'ingénierie de plateforme peut vous apporter une aide précieuse.

L'ingénierie de plateforme, c'est l'art de concevoir et de fournir des environnements informatiques complets aux développeurs et utilisateurs. Selon la Fondation Cloud Native Computing (CNCF), cette discipline englobe tous les aspects des plateformes : les équipes, les processus, les politiques et les technologies, sans oublier les objectifs commerciaux qui les motivent. Ce domaine en plein essor s'appuie sur les enseignements tirés de la révolution DevOps, les récentes avancées du Cloud Native avec Kubernetes et le serverless, ainsi que les progrès en matière d'observabilité et de SRE.

Une carrière dans l'ingénierie des plateformes implique de faire partie d'une équipe « produit », chargée de fournir des logiciels, des outils et des services. Que vous débutiez votre carrière dans l'informatique en tant que jeune diplômé ou que vous soyez déjà un développeur ou un ingénieur confirmé, l'ingénierie de plateforme offre des possibilités d'évolution ainsi que l’opportunité d'acquérir de nouvelles compétences techniques.

Dans cet article, nous vous proposons un aperçu du domaine de l'ingénierie des plateformes. Nous aborderons également le rôle des ingénieurs de plateformes ainsi que les compétences requises pour exercer ce métier. Nous évoquerons également l'importance d’une approche centrée sur l’utilisateur et d’un état d’esprit orienté « produit ». Enfin, nous vous donnerons aussi quelques conseils pour définir vos objectifs et éviter les pièges courants dans ce domaine.

Les compétences clés d'un ingénieur de plateforme

Que peut-on attendre d'un ingénieur de plateforme ? En général, ce rôle exige un mélange de compétences techniques et relationnelles. Il s'agit à la fois de savoir-faire professionnels nécessaires pour accomplir le travail, et de qualités personnelles qui influencent la façon de pratiquer ce métier. Pour se lancer dans une carrière d'ingénieur de plateforme, il est possible d'acquérir certaines de ces compétences. Cependant, il n'est pas nécessaire de toutes les maîtriser pour réussir, car elles sont souvent réparties au sein de l'équipe. Voici un aperçu des différentes facettes du métier d'ingénieur de plateforme :

Il adopte une approche centrée sur le client : en étant un partenaire fiable pour les équipes d'ingénierie, en partageant les connaissances, en travaillant avec d'autres équipes, y compris les développeurs de logiciels, les SRE et les gestionnaires de produits ;
Il est familiarisé avec les pratiques DevSecOps ;
Il est avide d'apprendre, de résoudre des problèmes tout en étant attentif aux détails et capable de communiquer efficacement avec les différentes équipes ;
Il est capable de promouvoir les avantages de l'approche d'ingénierie de plateforme avec ses collègues et les ingénieurs ;
Il applique une philosophie « produit » à la plateforme, en utilisant, par exemple, des parcours utilisateurs et des analyses de points de friction.

Compte tenu de son importance dans le domaine de l'ingénierie de plateforme, examinons de plus près l'approche centrée sur le client mentionnée ci-dessus.

La boucle de conception et l'importance de la focalisation client

Si les plateformes sont avant tout un produit, comme le suggère le livre blanc de la CNCF sur les plateformes, l'accent est malgré tout mis sur les utilisateurs. Le rapport DORA Research 2023 de Google montre clairement que l'attention portée à l'utilisateur est essentielle : « Les équipes qui se concentrent sur l'utilisateur ont des performances organisationnelles 40 % supérieures à celles des équipes qui ne le font pas ».

Chez Google, nous sommes convaincus que si nous nous concentrons sur l'utilisateur, tout le reste suit naturellement : c’est un principe clé de notre philosophie. Adopter une approche empathique centrée sur l'utilisateur nécessite une compréhension approfondie de ses besoins et de ses attentes. Pour y parvenir, nous utilisons plusieurs méthodes : entretiens, analyses statistiques, indicateurs de performance et collecte de données. Notre approche combine des métriques quantitatives et qualitatives pour obtenir une vision complète.

Vous pourriez, par exemple, décider d'adopter le cadre HEART (Happiness, Engagement, Adoption, Retention, Task Success) de Google, décrit en détail dans ce livre blanc. En tant qu'ingénieur de plateforme, vous pourriez être particulièrement intéressé par le « bonheur » (autrement dit l’axe Happiness), autrement dit la satisfaction ressentie par vos utilisateurs avec les services offerts par la plateforme. Parallèlement, vous voudrez aussi probablement mesurer et suivre « l'adoption » de la plateforme ainsi que « la rétention » (autrement dit la capacité à conserver leurs utilisateurs sur le long terme) des différentes offres.
Pourquoi les utilisateurs adoptent-ils votre offre ou au contraire la quittent ? Qu'est-ce qui manque et qui pourrait être amélioré lors du prochain sprint de conception de la plateforme ? Vous pouvez également créer un journal des frictions qui documente les obstacles auxquels vos utilisateurs sont confrontés lorsqu'ils utilisent les services de votre plateforme. Idéalement, vous pourriez même devenir votre propre client et utiliser vos solutions, en vous référant au journal de frictions et aux parcours des utilisateurs à travers la plateforme.

Pour bien comprendre l'ingénierie de plateforme, imaginez-vous au cœur d'un cycle d'amélioration continue. Dans ce processus, vous renforcez votre orientation client en menant des études sur les usages des utilisateurs pour mieux cerner leurs priorités. Vous développez de l'empathie en documentant les points de friction et en réalisant d'autres types d'expériences. Point central, le backlog de la plateforme (cette fameuse liste hiérarchisée des tâches à faire) devient l’outil à partir duquel toute votre équipe prend les décisions en se concentrant sur la valeur ajoutée de la plateforme pour l'entreprise. Adopter une mentalité produit vous aide à comprendre les besoins des utilisateurs, à définir une vision et une feuille de route claires, à prioriser les fonctionnalités et la documentation, et à rester ouvert aux améliorations. Une fois la première version de votre plateforme livrée, vous continuez à itérer dans ce cycle, l'améliorant à chaque tour.

Que fait réellement un ingénieur plateforme ?

En pratique, un ingénieur de plateforme effectue une grande variété de tâches au sein d'un groupe d'ingénierie de plateforme plus large. Bien entendu, personne ne peut tout faire et vous devrez vous spécialiser, mais voici quelques-uns des sujets sur lesquels vous pourriez vouloir vous concentrer :

Services Google Cloud

Runtimes de container : Google Kubernetes Engine, Cloud Run
Runtimes de Compute : Compute Engine, Google Cloud VMware Engine
Bases de données : Spanner, Bigtable, Cloud SQL
Conception et gestion du portail interne développeur
Outillage pour le support développeurs : Cloud Workstations
Gestion de la chaine CI/CD : Cloud Build, Cloud Deploy et Artifact Registry
Mise en œuvre de la conformité en tant que Code (RCaC) pour certaines voies royales (golden paths) gérées par Infrastructure Manager et Policy Controller, ce qui permet de réduire la charge cognitive des développeurs et d'accélérer les délais de déploiement.

Architecture

Acquérir une compréhension approfondie de l'infrastructure et de l'architecture des applications.
Co-écrire avec les développeurs et utiliser les voies royales en s’appuyant sur l’usage de l’Infrastructure as Code.
Créer une très bonne documentation en s’inspirant, par exemple, des conseils donnés dans nos formations sur la rédaction technique. N'oubliez pas que les enregistrements de décision d'architecture sont une partie essentielle de votre documentation d'ingénierie.

Opérations et fiabilité

Site Reliability Engineering (SRE)- Adopter les meilleures pratiques pour une exploitation fiable de votre plateforme.
Ingénierie de la sécurité - Conformité, contrôles horizontaux et garde-fous pour votre plateforme.

Ingénierie backlog

Adopter un backlog pour lister les tâches en attente et établir des priorités pour les travaux d'ingénierie. L'essentiel de l'effort doit porter sur la résolution des demandes en attente, tout en réservant un peu de temps à l'amélioration continue et à l'expérimentation.
Expérimenter et innover avec de nouvelles technologies - Il s'agit d'une tâche essentielle pour les ingénieurs de plateforme. Exemples : maîtriser de nouveaux services et de nouvelles fonctionnalités pour améliorer votre plateforme.

Ces dernières années, notre industrie s'est beaucoup focalisée sur le concept de « shift left », c'est-à-dire déplacer la complexité en amont du processus de développement. L'objectif est d'obtenir un code mieux testé, mieux intégré et plus sécurisé. Chez Google, nous sommes convaincus qu'en plus de cette approche, une bonne stratégie de plateforme permet aussi de « déplacer vers le bas » cette complexité (principe du « shift down ») . Bien entendu, même le plus talentueux des ingénieurs de plateforme ne peut pas tout gérer seul - la charge cognitive a ses limites !

Que doivent absolument éviter les ingénieurs de plateformes ?

Au-delà des bonnes pratiques à adopter, voici aussi quelques erreurs que les nouveaux ingénieurs de plateforme devraient éviter :

Négliger les besoins des développeurs et les exclure du processus de conception ;
Devenir la « bonne à tout faire » pour les tâches diverses : il est crucial de prioriser et d'instaurer une culture adaptée, sous peine d'épuisement et de perte de productivité (comme le souligne le rapport State of DevOps Report 2023) ;
Stagner professionnellement : l'apprentissage continu n'est pas un simple avantage, c'est une part essentielle du travail quotidien d'un ingénieur ;
Céder au syndrome du « héros » : répartissez plutôt les compétences au sein de l'équipe et travaillez à un rythme soutenable ;
S'attendre à une adoption immédiate de la plateforme sans effort de promotion, de formation et sans avoir gagné la confiance des développeurs.

Cette liste n'est pas exhaustive, mais elle regroupe les écueils les plus courants que nous avons pu observer jusqu'à présent.

Ingénieurs de plateforme : les piliers de la livraison logicielle moderne

Les ingénieurs de plateforme sont essentiels au succès d'une stratégie logicielle d'entreprise moderne. Ils sont responsables de la création et de la maintenance des plateformes utilisées par les développeurs pour construire et déployer des applications. Dans un monde où les logiciels évoluent constamment, les ingénieurs de plateforme jouent un rôle clé en fournissant des services logiciels évolutifs, tout en gardant les utilisateurs au cœur des préoccupations. Ils comprennent finement les exigences et les besoins de leurs clients internes, combinant leur expertise technologique avec une connaissance pointue des dernières avancées du secteur.

Pour approfondir vos connaissances en ingénierie de plateforme, voici quelques ressources complémentaires :

Le livre « Software Engineering at Google » explore la création d'un écosystème logiciel durable en se penchant sur la culture, les processus et les outils
Les livres SRE et les ateliers de Google
DORA.dev - études sur les compétences qui stimulent la performance en matière de livraison et d'exploitation logicielles

Certifications Google Cloud : Cloud Architect, Cloud DevOps Engineer, Cloud Developer, Cloud Security Engineer, Cloud Network Engineer

5 façons pour les ingénieurs de plateforme d’aider les développeurs à créer des API performantes

Thu, 13 Jun 2024 09:00:00 +0000

Pour concevoir des applications modernes, il faut des développeurs capables de créer des API en un temps record qui offrent à la fois des fonctionnalités complexes et de très hautes performances. Il faut aussi des ingénieurs de plateforme (platform engineers). Véritables piliers des architectures modernes, héros discrets mais pourtant essentiels des applications modernes, ils fournissent aux développeurs les bons outils et les bonnes pratiques pour leur simplifier la tâche.

En tant qu’ingénieur de plateforme, vous pouvez influencer la conception des API en adoptant cinq stratégies fondamentales. Plus concrètement, vous pouvez aider vos développeurs :

En traitant les API et les plateformes internes comme des « produits »
En intégrant la gestion des API dans votre plateforme interne
En construisant des pipelines CI/CD pour vos proxies et vos politiques
En simplifiant la consommation des API par vos développeurs en leur proposant une « voie royale »
En tirant parti d'Apigee pour la gestion et l'automatisation des API

1. Traiter les API et les plateformes internes comme des produits

Aujourd’hui, toute expérience numérique connectée de qualité repose sur des API, autrement dit des mécanismes qui permettent aux applications de communiquer entre elles. En termes simples, les API sont des solutions logicielles pour intégrer des services. Comme toute autre solution logicielle, les API doivent être testées, sécurisées, déployées et gérées en s’appuyant sur des process systématiques, tels que le cycle de vie du développement logiciel (ou SDLC pour Software Development Life Cycle). Des plateformes internes permettent de mettre en place de véritables processus de livraison des API. Elles fournissent aux développeurs un ensemble d’outils communs et des modèles clairement définis. Par exemple, si votre organisation a décidé que toutes les applications doivent accéder aux API en présentant un jeton OAuth, l’ingénieur plateforme peut tout à fait simplifier et fluidifier le travail du développeur en mettant à sa disposition un pipeline de flux partagé, utilisé pour associer une politique OAuth v2 au proxy à l'aide d'une règle FlowCallout.

Tout comme les API, les plateformes internes sont des solutions logicielles. L’une des principales missions de toute équipe d’ingénierie plateforme qui se respecte est de briser les silos internes afin de pouvoir travailler harmonieusement avec les autres équipes de l’entreprise et mieux comprendre les besoins de chacun. Fondamentale, cette collaboration permet au final aux développeurs de disposer de meilleurs outils.

2. Intégrer la gestion des API dans votre plateforme interne

En tant qu’ingénieur plateforme, votre première mission consiste à créer des plateformes en interne que vos développeurs peuvent utiliser. Ces plateformes favorisent l’autonomie des développeurs en leur donnant directement accès à des modèles et des outils validés et standardisés par votre organisation. En créant de tels outils et modèles et en les intégrant à votre plateforme, vous assurez une bonne gestion et prise en compte de tous les aspects clés d’une API, à commencer par la normalisation, la sécurité, les quotas, la surveillance ou encore le déploiement automatisé.

3. Construire des pipelines CI/CD pour vos proxies et vos politiques

Les API étant des solutions logicielles, elles doivent être créées et gérées avec du code. Une des tâches courantes de l’ingénieur plateforme est de créer des pipelines CI/CD afin d'automatiser le cycle de vie du développement des API. Un pipeline CI/CD standard est composé de plusieurs étapes : analyse statique du code, tests unitaires, déploiement, et tests d’intégration.

De manière générale, un développeur code localement un proxy et utilise Git pour transférer le code de ce proxy vers un dépôt de code source. Un commit déclenche alors un pipeline automatisé qui effectue des tests et fournit des retours. Si cela réussit, le code est transféré dans différents environnements jusqu'à sa mise en production.

Après avoir construit vos API, vous souhaitez naturellement qu'elles soient découvrables par d'autres dans votre organisation. L’« API Hub » d’Apigee est idéale pour la découverte interne des API.

Parallèlement, un « portail des développeurs » peut automatiquement être généré avec la documentation de vos API pour offrir aux développeurs externes (ceux de vos clients) un moyen de les découvrir, d’apprendre à les utiliser, d’en réclamer l’accès, de les essayer, etc.

4. Simplifier la consommation des API par vos développeurs en leur proposant une « voie royale »

Le principe de la « voie royale » est assez simple : l’objectif est de proposer des modèles qui intègrent le code et l’outillage afin d’accélérer au maximum les temps de développement. Vous aidez ainsi le développeur à construire rapidement son chemin vers la livraison logicielle – d’où cette notion de voie royale – en lui proposant des workflows et des modèles accessibles en libre-service. Ces modèles englobent des tâches courantes et des stratégies prédéfinies. Si vous développez des API avec Apigee, cette voie royale peut comprendre les éléments suivants :

Un guide pour bien démarrer
Un modèle pour construire le proxy / des stratégies prédéfinies / une simulation de backend
Des configurations pour des flux partagés standards directement exploitables
Un pipeline CI/CD pour les tests et le déploiement
Des modèles pour l’ « API Registry » (qui regroupe des descriptions standardisées, lisibles par des machines et programmes, des différentes API).

5. Tirer parti d'Apigee pour la gestion et l'automatisation des API

Un mot sur la pièce maîtresse de votre stratégie : Apigee. Plateforme de gestion des API, Apigee propose aux ingénieurs de plateforme une solution pour construire, administrer et sécuriser les API. Apigee peut être utilisé pour gérer vos API tout au long de leur cycle de vie. Dans Apigee, tout commence par un proxy, autrement dit une interface numérique située entre le client et la logique métier (ou backend). Le proxy sert également de point d'attache pour les politiques d'API (les règles et comportements associés à une API) afin de programmer et personnaliser le comportement de l'API.
Les proxys permettent également de découpler l’API en évitant un accès direct au backend et en masquent la complexité. En tant qu'ingénieur de plateforme, vous aidez les développeurs à créer de meilleures API en leur permettant de se concentrer sur la création de proxys. Votre plateforme doit dès lors être préalablement paramétrée afin d’arrêter une stratégie de fonctionnement des API.

Certains outils d’Apigee, tels que Shared Flows, vous permettent de normaliser et préserver la cohérence de vos politiques. Les politiques FlowCallout et les flow hooks permettent d'attacher ces politiques aux proxys et de les réutiliser dans les différentes API créées.

6. Concevoir de meilleures API

En traitant les API et les plateformes internes comme des « produits », en intégrant la gestion des API à votre plateforme, en exploitant Apigee pour la gestion et l'automatisation des API, en construisant des pipelines CI/CD pour vos proxies et vos politiques, et en créant des voies royales pour faciliter la consommation des API, vous aidez indubitablement vos développeurs à créer de meilleures API avec Apigee.
Si vous souhaitez obtenir plus de conseils sur le sujet et aider davantage vos développeurs, consultez ce livre blanc qui détaille la démarche. Si vous n’utilisez pas encore Apigee, n’hésitez pas à consulter notre documentation pour en savoir plus ou rendez-vous directement sur ce lien pour tester notre plateforme d’API Management.

Le succès par la culture d’entreprise : pourquoi l'acceptation de l'échec favorise une meilleure livraison logicielle

Wed, 13 Mar 2024 07:00:00 +0000

Les choses se cassent. C'est la vie. Et lorsque tout ne se déroule pas comme prévu, c'est ce qui se passe ensuite qui est vraiment important.

Des études internes réalisées par Google et par notre organisation DORA (‘DevOps Research and Assessment’) montrent que les équipes qui réussissent le mieux sont celles qui encouragent une « culture de la confiance », autrement dit un climat de travail qui autorise la remise en question, la prise de risques et les erreurs.

La culture d’une entreprise façonne notamment la façon de réagir aux opportunités qui se présentent. Mais, dans le domaine de la livraison logicielle, et plus globalement de la performance des équipes, la façon de réagir à l’échec est tout aussi importante.

En adoptant des comportements et des méthodes de travail spécifiques qui encouragent la résilience, une organisation peut accroître significativement l'efficacité de ses équipes et améliorer ses performances.

Comment identifier les leviers pour optimiser l'efficacité des équipes logicielles et des cultures organisationnelles ?

Chez Google, nous ne nous contentons pas de fabriquer beaucoup de technologies, nous nous intéressons aussi à la manière dont elles sont fabriquées.

DORA est un programme de recherche rigoureux sur le plan académique et statistique qui vise à répondre aux questions suivantes : « Comment la technologie aide-t-elle les organisations à réussir et comment pouvons-nous améliorer la livraison et l'exploitation des logiciels ? »

Grâce à des études internes portant sur des centaines d'équipes Google, tels que le projet Aristote, nous avons étudié les moteurs des équipes les plus efficaces.

Nous vous proposons ici d’entamer une nouvelle série d’articles s’appuyant sur ces années de recherches menées par Google. Nous avons regroupé les résultats selon cinq grands axes d’analyse sur lesquels (chacun formant un article) vous pouvez vous appuyer pour optimiser la réussite au sein de votre organisation :

La Résilience (le sujet de ce premier article)
La Communication
La Collaboration
L’Innovation
La Responsabilisation

La résilience… Qu’est-ce donc ? Et surtout comment peut-elle améliorer les performances ? Comment votre équipe peut-elle en tirer le meilleur profit.

Résilience : positiver l’échec, oui, mais encore…

Dans le cadre de cet article, lorsque nous parlons de résilience, nous faisons référence à la résilience culturelle. Dans ce contexte, nous définissons la résilience comme la capacité des équipes à prendre des risques mesurés, à partager ouvertement les échecs et à s'améliorer continuellement sur la base du retour d'information. Les équipes qui font preuve de résilience sont manifestement plus performantes que les autres.

L'idée qu'une culture présentant des caractéristiques de résilience peut être bénéfique à l’entreprise n’est pas nouvelle. L'étude du sociologue Ron Westrum autour de l'influence de la culture sur le comportement de l'équipe en cas d'échec a mis en évidence trois cultures organisationnelles distinctes : pathologiques, bureaucratiques, génératives. Et les cultures dans lesquelles l'échec conduit à une investigation positive, plutôt qu'à la justice ou à la désignation d'un bouc émissaire, se montrent plus orientées vers la performance. Westrum qualifie ces cultures de « génératives ».

Cette analyse du sociologue a été corroborée par nos propres résultats DORA, dès la publication du premier rapport sur l'état de DevOps en 2014. Notre rapport 2023 Accelerate State of DevOps démontre que la présence d'une culture générative continue à favoriser une meilleure livraison logicielle et une meilleure performance organisationnelle. Nous pensons que c'est parce que, à la base, DevOps est une approche qui se focalise fondamentalement sur les personnes et les méthodes de travail de ces personnes. Or, les personnes sont le moteur de la culture.

« La culture joue un rôle essentiel dans la capacité à innover et à créer des technologies… les performances des équipes ayant une culture générative sont 30% supérieures à celles qui n’en ont pas ».

Source: DORA 2023 Accelerate State of DevOps Report

Prenons, par exemple, les pratiques de développement dans le domaine de la sécurité. Nos recherches ont montré que les organisations fondées sur une culture de confiance et de résilience sont 1,6 fois plus susceptibles d'adopter des pratiques de sécurité émergentes.
Nous sommes convaincus que ces cultures génératives, résilience comprise, constituent un avantage en termes de posture de sécurité en raison de leur influence sur les méthodes de travail des équipes. Typiquement, dans les organisations « génératives », les personnes sont plus enclines à signaler un problème ou un risque de sécurité car elles ne craignent pas d’être sanctionnées sur leur « irréprochabilité ». Dit autrement, si vous voulez améliorer la posture de sécurité de votre organisation (et aller au-delà), commencez par évaluer la culture de vos équipes.

La résilience peut être redécomposée en deux états d’esprit :

Le « Démarrer puis itérer »: lancer un projet, recueillir les retours et s’améliorer en continu
La « Sécurité psychologique » : insuffler la conviction au sein de l’équipe que chaque membre peut prendre des risques en toute sécurité

Démarrer et itérer : le « parfait » est l'ennemi du bien

Êtes-vous prêt à prendre le risque de partager une idée seulement ébauchée à 20% avec vos dirigeants ?

Le concept de « résilience » repose en partie sur la collecte d’information et l’amélioration continue. Nos études montrent que les équipes fondées sur l’amélioration continue réussissent mieux. Ce qui suppose des équipes capables de démarrer rapidement, de s'adapter à des circonstances changeantes et d'expérimenter.

Par exemple, dans le cadre de la livraison logicielle, la recherche DORA soutient la philosophie d’une livraison continue afin que le logiciel soit toujours dans un état « déployable ». Pour conserver le logiciel dans un tel état, il est essentiel de mettre en place des mécanismes de collecte des feedbacks et d’être en mesure de surmonter rapidement les échecs. D’après nos études, les équipes qui donnent la priorité à ces mécanismes de feedback affichent de meilleures performances sur la livraison logicielle. Nos études montrent également qu’une livraison par petits lots (donc par fréquentes itérations) améliore la façon dont les équipes reçoivent et utilisent ce feedback, ainsi que leur capacité à se remettre d’un échec notamment.

Ce concept – démarrer et itérer – n’impacte pas uniquement la qualité du logiciel livré. De fait, il soulève aussi la question de la capacité d’une équipe à s’auto-évaluer, à s’adapter et à changer de méthode quand les résultats le justifient. Inévitablement, cette approche par l’expérimentation entraînera des succès, mais aussi des échecs. Dans tous les cas, les équipes peuvent en tirer des enseignements précieux.

Sécurité psychologique : valoriser l’échec comme un succès

Êtes-vous prêts à accepter l’idée d’échouer ouvertement devant votre équipe ?

Des recherches approfondies menées chez Google ont montré que la sécurité psychologique constitue un facteur clef pour parvenir à des équipes hautement efficaces. Dans ce cadre, nos études montrent que l’efficacité dépend moins des membres de l’équipe que de la façon dont ils interagissent.

Selon les études réalisées par les analystes de Google, cinq facteurs impactent l’efficacité d’une équipe, classés ici par ordre d’importance. Source : Google re:Work Guide: Understand team effectiveness

Dans le cadre du projet Aristote, des centaines d’équipes Google ont été interrogées sur la question suivante : « Qu'est-ce qui rend une équipe efficace ? ». L'analyse statistique des données recueillies a révélé que la dynamique d'équipe la plus importante est la sécurité psychologique, c'est-à-dire la création d'un environnement où la prise de risques intelligents est encouragée. Autrement dit, un climat de travail dans lequel les collaborateurs sont convaincus qu'ils ne seront pas embarrassés ou sanctionnés pour leurs idées, leurs questions ou leurs erreurs.

Une analyse plus poussée de DORA montre que ces pratiques ne bénéficient pas uniquement aux équipes de Google : la culture de la « sécurité psychologique » permet d’obtenir de bien meilleurs résultats en matière de livraison logicielle, de performance organisationnelle et de productivité.

Enfin, il est important de rappeler que la culture d’une entreprise découle du management. La recherche DORA montre qu'un leadership efficace a un impact mesurable et significatif sur la livraison logicielle. Pour favoriser un climat psychologiquement sûr, où les reproches n’ont pas leur place, les dirigeants doivent accorder à leurs équipes la confiance nécessaire, leur permettre de s'exprimer et leur donner la possibilité d'expérimenter et d'échouer.

Comment, en pratique, améliorer votre résilience ?

Adopter une posture d’amélioration continue peut aider à obtenir de meilleures performances organisationnelles. De même, l'adoption de la sécurité psychologique dans votre organisation peut aider vos équipes à travailler plus efficacement. De notre point de vue, ces deux approches constituent les fondements d’une résilience qui favorise la réussite par la culture.

Alors, à quoi ressemble la résilience lorsqu'elle est appliquée concrètement dans nos comportements et renforcée dans notre travail quotidien ?

Nous pouvons nous améliorer continuellement en démarrant rapidement les projets, en définissant des indicateurs de réussite, en collectant des informations (y compris par le biais du crowdsourcing) et en valorisant ce que nous apprenons, à la fois pour améliorer nos produits et notre façon de travailler. Cette approche peut être renforcée par des pratiques techniques telles que l'intégration continue, les tests automatisés, la livraison continue, l’observabilité et le monitoring, pour n'en citer que quelques-unes. Ces pratiques constituent à la fois les fondations et les garde-fous qui favorisent une itération sûre, rapide et fiable.

Nous pouvons aussi normaliser l'échec en organisant des « pré-mortems », sorte d’analyse en vue d’anticiper les innombrables façons dont une idée peut échouer, et des « post-mortems sans reproches » (analyses a posteriori). L’idée étant d’avoir des conversations franches sur les moments où les choses ne se sont pas déroulées comme prévu en imaginant les leviers qui auraient pu être actionnés pour améliorer la situation. Le tout sans faire de reproche à qui que ce soit.

Nous avons, par exemple, constaté que les équipes qui encouragent des « pratiques de fiabilité », y compris des postmortems sans reproches, font état d’une meilleure productivité et d’une satisfaction professionnelle plus élevées. Elles affichent également un taux d'épuisement professionnel plus faible que leurs homologues qui utilisent des approches opérationnelles plus traditionnelles. Nous pensons que cela s'explique notamment par le fait qu'une peur persistante de commettre des erreurs peut entraîner un certain mal-être.

Les analyses a posteriori sans reproches permettent d'éviter que les problèmes se reproduisent, d’éviter d’engendrer plus de complexité et d'apprendre de ses erreurs et de celles des autres.

Ces méthodes de travail sont illustrées par nos derniers lauréats du Google Cloud DevOps Award. Ils ont montré comment ils mettent en œuvre ces pratiques (et d'autres) pour favoriser la réussite de leur organisation et se montrer plus performants. Typiquement, imaginez une entreprise qui s’appuie sur des équipes interfonctionnelles pour éliminer les goulets d'étranglement, débloquer des situations et améliorer la communication. Nous aurons l’occasion d’y revenir dans un prochain article.

En attendant, entraînez-vous à l'échec en expérimentant de nouvelles méthodes de travail, y compris en testant de nouvelles approches sur la livraison logicielle, l’opérationnel, etc. Et posez-vous la question suivante : comment réagirez-vous la prochaine fois que quelque chose ne fonctionnera pas ?

Pour en savoir plus, faites le DevOps Quick Check et lisez le dernier rapport sur l'état des DevOps, tous deux disponibles sur dora.dev.

Au cœur du rapport 2022 sur l’état de l’art des pratiques DevOps : une bonne culture d’équipe

Sun, 30 Jul 2023 08:55:00 +0000

Note de l'éditeur : Chaque année l'équipe DevOps Research and Assessment (DORA) de Google Cloud cherche à mieux comprendre les pratiques DevOps et leur lien avec la performance des organisations. Les résultats de l’étude réalisée chaque année sont publiés dans le rapport Accelerate State of DevOps.
Dans cet article et d’autres à venir, nous allons revenir plus en détail sur certains chiffres clés de l’étude mais également approfondir certaines conclusions auxquelles nous sommes parvenues et qui n’ont pas toujours été intégrées au rapport 2022.

La culture d’une entreprise est un facteur clé qui influe sur l’épanouissement ou l’échec des équipes face aux pressions croissantes du travail hybride. Dans ce contexte, et alors que nous adoptons tous des modes de travail plus flexibles, l’équipe du DORA a cherché à mieux comprendre les facteurs qui, aujourd’hui, influencent une culture d’entreprise et son impact sur la performance des équipes.

Année après année, la culture d’une entreprise, ou d’une équipe, apparait dans chaque rapport comme un élément clé de réussite : elle constitue le sol fertile à partir duquel les technologies et les processus se développent ou, au contraire, se dégradent… tout dépend des nutriments qui l’alimentent.

Les valeurs clés d’une bonne culture d’équipe

Ainsi, la culture organisationnelle impacte de façon significative les résultats d’une entreprise. Une bonne culture d’équipe se caractérise notamment par sa polarisation sur les performances. Dans les organisations orientées performances, l’information circule librement, les équipes sont stables et profitent de la flexibilité du travail tandis que les managers accompagnent leurs équipes en favorisant une démarche d’amélioration continue.

Libre circulation de l’information, flexibilité du travail, stabilité des équipes, soutien des managers… D’après notre rapport 2022, ces valeurs organisationnelles sont essentielles et se traduisent généralement par de meilleures performances de l’entreprise, une réduction des risques de burn-out chez les collaborateurs et moins de pression pour réaliser un travail de meilleure qualité.

L’objectif de cet article est d’explorer la taxonomie d’une culture basée sur les quatre dimensions énoncées ci-dessus (circulation, flexibilité, stabilité, soutien). Dans cette perspective, il convient dans un premier temps de répondre à trois questions fondamentales :

En se basant sur ces quatre dimensions, quels sont les types d’équipes que l’on retrouve le plus fréquemment ?
Quelles sont les caractéristiques associées à chaque catégorie d'équipe ?
Et ces équipes obtiennent-elles vraiment des résultats différents ?

Pour répondre à ces questions, nous avons utilisé l’analyse topologique, méthode statistique permettant d’examiner les différentes caractéristiques d’un type d’objet (comme la taille, la couleur et la forme de fleurs) pour ensuite essayer de trouver les combinaisons les plus courantes, aussi appelées topologies. Notre objectif dans le cas présent est de mettre en évidence la topologie d’équipe la plus répandue à partir des données recueillies dans le cadre de l’étude 2022.

En bref, en étudiant à la fois l’orientation organisationnelle (en fonction des modèles établis par le sociologue Dr Ron Westrum), la stabilité des équipes, le degré de soutien dont elles bénéficient et la flexibilité du lieu de travail, nous avons identifié trois grandes catégories d’équipes.

Nous vous proposons ici de revenir sur chacune d’elles et de voir dans quelle mesure elles permettent d’obtenir de bons résultats en nous basant sur quatre critères stratégiques pour l’entreprise : performance organisationnelle, burn-out, attractivité de l’équipe pour attirer de nouveaux collaborateurs, performance opérationnelle et performance de la livraison logicielle.

Catégorie 1 : L'équipe de rêve (The Dream Team)

La culture de la « Dream Team » est axée sur les performances, la stabilité, un soutien de la direction et de l'encadrement ainsi que des conditions de travail flexibles. Sans porter de jugement sur les autres catégories, c’est l’équipe à priori « idéale ». Plus de la moitié des équipes ayant été sondées dans le cadre de notre rapport (57%) appartiennent à cette catégorie, ce qui signifie qu’une personne a plus de chances de se retrouver dans cette catégorie si une équipe lui était attribuée de manière aléatoire.

La « Dream Team » constitue un excellent élément de comparaison, car elle semble prospérer sur tous les points de la culture qui nous intéressent. Elle va donc servir de référence dans notre comparaison avec les autres catégories d’équipe et nous permettre de juger si elles sont aussi efficaces ou significativement moins performantes.

Catégorie 2 : L'équipe isolée

L’équipe isolée représente 22% des équipes interrogées. Dans cette catégorie, les équipes bénéficient d’une certaine flexibilité, mais la collaboration y est faible, les erreurs sont sanctionnées, le développement du relationnel entre les membres est déconseillé, le taux d'attrition est élevé et l’équipe bénéficie d’un faible soutien. Nous avons baptisé cette équipe « isolée », car elle est isolée des initiatives de l'entreprise, comme en témoigne le faible soutien, et parce que la communication entre les membres de l’équipe est plus ou moins inexistante.

D’après nos estimations, le taux de burn-out y est 2,4 fois plus élevé que dans l’équipe de rêve. De la même façon, la performance organisationnelle et la performance de la livraison logicielle sont 2,3 fois inférieures à celle de la Dream Team.

Catégorie 3 : L'équipe rigide

Enfin, troisième et dernière catégorie, « l’équipe rigide » a été baptisée ainsi parce qu’elle ne bénéficie pas de flexibilité au travail et parce qu’elle ne semble pas disposer d’un environnement culturel propice à son développement. 21% des équipes interrogées sont dans ce cas de figure.

Dans cette équipe, la création de liens entre les membres et la collaboration sont tolérées, mais pas activement encouragées. Les nouvelles idées peuvent engendrer plus de problèmes qu'elles n'en résolvent, car l'équipe manque de marge de manœuvre pour se développer.

D’après nos estimations, le taux de burn-out y est 1,2 fois supérieur à celui d’une équipe de rêve et le niveau de performance organisationnelle y est 2,6 fois inférieur.
Les performances opérationnelles comme en termes de livraison logicielle sont aussi fortement impactées dans une telle équipe : 1,2 fois inférieures pour le côté opérationnel et 3,5 fois inférieures pour la livraison par rapport à une Dream Team.

Conclusion

La Dream Team n'est pas seulement l’équipe idéale pour travailler : elle est aussi la plus efficace pour faire avancer les choses. En outre, elle est aussi plus attractive : ses membres, convaincus de sa valeur, se disent deux fois plus enclins à encourager d'autres personnes à la rejoindre, ce qui est essentiel quand on sait que toutes les organisations cherchent à réduire le turn-over.

La plupart des personnes interrogées dans le cadre de notre enquête ont des profils techniques. Cela étant dit, on peut aisément transposer l’impact de ces catégories et de ces cultures organisationnelles dans d’autres départements de l’entreprise, tels que les ventes, le marketing ou même la finance !

Pour en savoir plus sur la culture d'entreprise et les autres facteurs qui peuvent affecter la performance de la livraison logicielle, téléchargez notre rapport 2022 State of DevOps Report. Et n’hésitez pas à rejoindre la communauté DORA.community group pour d’autres échanges autour de DORA, DevOps et la performance sur la livraison logicielle.

Stratégies SRE : normalisez le processus de conception des SLOs

Fri, 21 Jul 2023 08:00:00 +0000

Si vous demandez à trois Site Reliability Engineers la définition de SRE, vous obtiendrez probablement au moins cinq réponses différentes ! Une mise en œuvre de DevOps, un rôle, un ensemble de pratiques, un changement culturel, un titre accrocheur… Si ces définitions varient et ne correspondent pas forcément à celles que l’on peut trouver dans des ouvrages de référence sur le sujet, il existe néanmoins un point fondamental sur lequel SRE se différencie des autres méthodes de travail : les « Service Level Objectives » (SLO) ou Objectifs de Niveau de Service.

Conçus intentionnellement pour être simples à comprendre, les SLO sont, en revanche, souvent difficiles à définir dans la pratique. Même si les spécificités d'un SLO varient selon les industries et les secteurs verticaux, nous avons toutefois constaté que les équipes ayant réussi à les mettre en place pour leur workloads partagent certaines pratiques et stratégies.

Première étape, la collaboration entre les équipes « produit », développement et SRE est essentielle, de sorte qu’elles partagent le même niveau de compréhension du workload, tout particulièrement en termes de points stratégiques du parcours client ou CUJ pour Critical User Journey. La plupart du temps, cette étape conduit les équipes à formaliser par écrit les CUJ sous forme de flux détaillé ou de diagramme séquencé. La maturité de la relation existante entre ces trois équipes (développement, produit et SRE) intervient directement dans le niveau d’effort à fournir pour faire aboutir cette première étape. En effet, partager une vision commune des attentes des utilisateurs sur un workload constitue un prérequis pour définir des SLOs efficaces.

Bien que la modélisation d’un parcours utilisateur et sa décomposition en SLOs relève d’un véritable savoir-faire et qu’il n’existe pas deux applications identiques, vous pouvez toutefois ancrer cette première étape et les échanges qui l’accompagnent autour de quelques points clefs.

La question principale que nous vous recommandons de garder à l'esprit tout au long du processus est la suivante : « Qu'est-ce qui intéresse mes utilisateurs ? ». En formulant votre processus de réflexion de cette manière, vous éviterez les problèmes de mise en œuvre et les stratégies qui s’éloignent des attentes des utilisateurs. D'autres points doivent également être pris en compte :

Le parcours comprend-il des moments clefs au cours desquels l’utilisateur peut décider de ne pas poursuivre son action ?
Quelle(s) partie(s) du parcours sont mesurables et quelle(s) partie(s) ne le sont pas ? (Typiquement, certaines parties peuvent dépendre d’un tiers)
Quelles parties d’un parcours client sont communes à de nombreux clients et donc susceptibles d'être factorisées en tant que CUJ à part entière (exemple : login) ?
Quelles parties du parcours peuvent être mesurées globalement et quelles autres parties doivent être séparées en raison de différences de criticité, de variabilité de la demande ou d'autres facteurs ?
Quelles étapes du parcours sont strictement dépendantes les unes des autres ?

Armé des réponses à ces questions, d'un diagramme de requête détaillé (une représentation des étapes suivie par l’utilisateur en interagissant avec l’application) et du code de votre application, vous pouvez commencer à rédiger vos SLOs. Avant de vous jeter sur vos consoles de monitoring, nous vous conseillons de documenter vos SLOs en renseignant clairement les détails techniques qui vous ont conduit à choisir ces SLOs. Nous vous proposons un modèle pour vous aider à mettre en place ce processus de documentation. Si vous disposez d'un compte Google, vous pouvez en faire une copie en cliquant sur ce lien. Outre le modèle vierge à compléter, vous trouverez également des exemples déjà renseignés qui peuvent vous servir de référence lors de la création de vos propres spécifications.

Que vous exploitiez ce modèle ou non, nous vous recommandons d'utiliser les éléments suivants pour documenter vos SLO :

Soyez pointilleux sur les spécifications techniques - elles auront de l'importance lors de la mise en œuvre.
Conservez une section décrivant les clarifications, mises en garde et/ou compromis réalisés au moment de la conception.
Choisissez le bon endroit où effectuer des mesures - assurez-vous que c'est faisable.
Méfiez-vous des statistiques non agréables (comme les moyennes, médianes et percentiles qui dépendent de leur sous-ensemble de données et ne peuvent pas être combinés en statistiques globales) pour vos SLO de latence.
Veillez à ce que les périodes de conformité soient cohérentes pour l'ensemble des SLOs de vos workloads :

Nous recommandons les valeurs suivantes :

28 jours glissants pour les besoins opérationnels (comme les alertes sur le budget)
Trimestre calendaire fixe pour la priorisation (actions à entreprendre pour améliorer le service) et l’analyse rétrospective (lookback, analyse des causes et conséquences des violations des SLOs).

Changelog (journal des modifications apportées à un SLO) : incluez-en un, même si votre outil de documentation dispose d'un historique des versions, afin de pouvoir suivre plus aisément les changements majeurs.
Partagez votre documentation SLO dans un endroit accessible par toute votre équipe et les différentes parties prenantes dans l'entreprise (directions métiers notamment).
Une fois votre PRD SLO finalisé (le document de conception des SLO), traitez votre implémentation comme du code et stockez-la dans votre système de contrôle des versions.
N'oubliez pas le principe de développement DRY (Don't repeat yourself) ! Pour rappel, ce principe vise à réduire les répétitions et duplications pour éviter les incohérences et permettre une maintenance plus aisée).

Nous espérons que ces recommandations ainsi que le modèle proposé vous seront utiles et vous permettront d’être plus efficaces sur la conception de vos SLOs. Si vous avez besoin d'un outil pour mettre en œuvre vos SLOs, pensez à Google Cloud SLO Monitoring, solution qui permet de créer des SLOs pour n'importe quelle métrique disponible dans Google Cloud Monitoring. Elle détecte aussi automatiquement les erreurs de budget, favorisant ainsi la mise en place d’alertes vous informant dès que les dépenses mensuelles dépassent un certain seuil. Si vous ne vous sentez pas encore à l’aise avec ce processus de conception des SLOs ou si votre équipe a besoin d’aide sur un des points ci-dessus, n’hésitez pas à solliciter notre Team « reliability engineering professional services ». Elle peut vous accompagner dans votre démarche. Pour plus d'informations, consultez les pages cloud.google.com/sre ou contactez l'équipe chargée de votre compte Google Cloud.

2022 State of DevOps Report : fiabilité et SRE

Thu, 04 May 2023 07:00:00 +0000

Accélérer l’adoption de DevOps

Lorsqu’une modification logicielle est déployée – après avoir été conçue, codée, testée, packagée et testée à nouveau -, un cycle s’achève. Mais le projet n’est pas terminé pour autant : c’est à ce moment précis que commence un nouveau cycle, celui de la relation entre le client et le service déployé. Et c’est à ce stade de l’exploitation que des risques jusqu’alors abstraits se transforment en risques tangibles tels que la perte de revenus, la dégradation de la confiance ou encore l'atteinte à la réputation. Ce n'est que lorsqu'il est mis à la disposition des utilisateurs que le logiciel peut contribuer (ou menacer !) au succès de votre organisation. C'est pourquoi le projet DORA (DevOps Research and Assessment) a cherché à approfondir ses recherches au cours de ces dernières années sur la fiabilité des services, à travers et au-delà du déploiement, jusqu'au fonctionnement continu.

Au sens large, la « fiabilité » fait référence à la capacité d'une équipe à répondre aux attentes de ses utilisateurs. Dans le domaine logiciel, elle englobe aussi bien des notions de disponibilité, de latence, de corrections et autres caractéristiques qui influencent la cohérence et la qualité de l'expérience utilisateur. La pratique de l'ingénierie de la fiabilité des sites (ou SRE) de Google, adoptée et enrichie par une communauté mondiale d’ingénieurs SRE, propose une approche des opérations IT centrée sur les retours des utilisateurs, le partage des responsabilités et une collaboration basée sur l’amélioration continue plutôt que sur les reproches.

Dès la réalisation du rapport 2021 Accelerate State of DevOps, nous avons commencé à poser des questions précises sur l'ingénierie de la fiabilité dans leur organisation aux personnes impliquées. Nous avons poursuivi et élargi le spectre de notre enquête en 2022. Les résultats montrent que l'ingénierie de la fiabilité moderne est désormais très répandue : une majorité de répondants déclarent utiliser des pratiques de type SRE. Forts d’une impressionnante quantité d’informations collectées, nous avons cherché à affiner nos recherches portant sur l’impact de la fiabilité et son interaction avec d’autres dynamiques présentes dans notre modèle d’analyse de l’influence des technologies sur le succès des entreprises.

La fiabilité est fondamentale

« Lorsque la fiabilité est faible, les améliorations apportées à la livraison logicielle n’ont aucun effet sur les résultats de l’organisation. Elles peuvent même avoir un effet négatif ».

La fiabilité n’est pas seulement nécessaire : elle est essentielle. Comme dans les études précédentes, nous constatons que la performance des logiciels livrés impacte la performance des entreprises. Cette performance de la livraison logicielle est mesurée selon les « quatre indicateurs clés » : le délai de mise en œuvre des changements, la fréquence des déploiements, le taux d'échecs des déploiements et le délai de reprise après échec.
Nous avons toutefois découvert un nouveau facteur cette année : l’impact des livraisons logicielles sur les performances de l’entreprise repose sur la fiabilité. Lorsque la fiabilité est élevée, une livraison logicielle performante permet d’anticiper de meilleurs résultats pour l'organisation. Mais lorsque la fiabilité est faible, les améliorations apportées à la livraison des logiciels n'ont aucun effet, voire un effet négatif, sur les résultats de l'organisation ! Ce qui ne fait que confirmer ce que beaucoup d’ingénieurs SRE pensaient déjà : « la fiabilité est la caractéristique la plus importante de tout système ». Si un service ou un produit ne répond pas aux attentes de ses utilisateurs en matière de fiabilité, livrer rapidement de nouvelles fonctionnalités tape-à-l'œil est contre-productif car les utilisateurs ne peuvent pas les expérimenter correctement. Pour créer de la valeur, la livraison logicielle doit s’appuyer sur des fondations solides de fiabilité.

La fiabilité est un cheminement

Tout dirigeant expérimenté vous dira que le progrès est rarement linéaire : même avec une discipline comme le SRE, largement pratiquée et dont les avantages sont démontrables, le chemin du succès a peu de chances de suivre une ligne droite. DORA décrit ce parcours avec la "courbe en J" de la transformation organisationnelle, graphique expliquant le phénomène selon lequel le succès durable ne vient qu'après des revers et des leçons apprises.

Cette année, nous avons comparé le niveau des pratiques d'ingénierie de la fiabilité des équipes SRE avec leur impact sur les services fournis : une plus grande expertise SRE produit-elle une plus grande fiabilité ? La réponse est clairement « Oui » ! Mais attention : l’amélioration n’intervient pas dès le début.

Si l'on compare les résultats en matière de fiabilité en fonction de différents niveaux d'adoption de l'ingénierie de la fiabilité, la courbe en J apparaît clairement. Une équipe qui pratique la SRE de manière uniquement légère - au début de son parcours SRE, par exemple - risque non seulement de ne pas gagner, voire de régresser, en termes de fiabilité ressentie par ses utilisateurs. Toutefois, une fois que ces pratiques sont plus profondément ancrées, un point d'inflexion peut être atteint et nous constatons une incidence positive sur la fiabilité au fur et à mesure que l’équipe développe et approfondit ses pratiques SRE.

Partant du principe qu'il faudra probablement du temps pour réaliser les avantages de l'adoption du SRE, vous pourriez être tenté de lancer le processus le plus tôt possible en le généralisant à toutes les équipes. Mais attention ! Les initiatives impliquant une transformation culturelle à l'échelle de l'entreprise échouent généralement lorsqu'elles sont trop ambitieuses. Nous avons étudié cette question et fait part de nos conclusions dans un précédent rapport. Et même si vous parvenez à déjouer les pronostics et à adopter pleinement le SRE dans plusieurs équipes simultanément, le coût peut être inacceptable : les baisses de fiabilité que vous risquez de subir au début, amplifiées par le fait qu’elles se produiront au même moment dans toute l’organisation, pourraient entraîner des conséquences catastrophiques. C'est pourquoi le principe de changement progressif de la SRE doit également être appliqué à l'adoption de la SRE elle-même !

La fiabilité repose sur l’humain

Après plus d'une décennie de pratique et de théorie de l'ingénierie de la fiabilité des sites, l’ouvrage Enterprise Roadmap to SRE souligne l'importance de l’acculturation, suggérant que l'ingénierie de la fiabilité des sites s’impose en fait par la culture. Les outils et les frameworks sont importants ; le langage est essentiel. Mais seule une culture instaurant un climat de grande confiance avec un management positif de l’erreur permet de développer le processus d’amélioration continue, indispensable au SRE pour gérer les environnements technologiques complexes et dynamiques d'aujourd'hui. Les recherches menées par DORA en 2022 démontrent l'interaction entre culture et fiabilité : nous avons constaté que la culture "générative", telle que définie par le modèle de Westrum, permet de prédire des résultats de fiabilité plus élevés. Et la fiabilité présente des avantages non seulement pour les utilisateurs d'un système, mais aussi pour ses concepteurs : les équipes dont les services sont très fiables ont 1,6 fois moins de chance de souffrir d'épuisement professionnel.

Vos SLOs sont-ils réalistes ? Ou comment analyser vos risques comme un SRE

Tue, 12 Jul 2022 08:00:00 +0000

Définir les SLO (ou objectifs de niveau de service) est l’une des tâches fondamentales des pratiques SRE (Site Reliability Engineering ou « ingénierie de la fiabilité des sites »). Un SLO précise à l’équipe SRE, l’objectif cible à atteindre pour évaluer si un service est suffisamment fiable ou pas. L'inverse du SLO est ce qu’on appelle le « budget d'erreur » (error budget), c'est-à-dire le niveau de manque de fiabilité que vous êtes prêt à tolérer et à assumer financièrement. Une fois ces objectifs identifiés et leur définition apprivoisée, la question suivante consiste à savoir si vos SLO sont réalistes compte tenu de l’architecture de votre application et des pratiques de vos équipes. Êtes-vous sûr de pouvoir les atteindre ? Et qu'est-ce qui est le plus susceptible de dévorer votre budget d'erreur ?

Chez Google, les SRE répondent à ces questions dès la prise en charge d’un nouveau service, dans le cadre d'une revue de préparation à la production (PRR – Production Readiness Review). L'objectif de cette analyse des risques n'est pas de vous inciter à modifier vos SLO, mais plutôt de hiérarchiser (et de communiquer sur) les risques liés à un service donné, afin que vous puissiez évaluer si vous serez en mesure de respecter vos SLO, avec ou sans modification du service. En outre, une telle analyse peut vous aider à identifier les risques les plus importants, avec comme volonté finale de les hiérarchiser et de les atténuer.

« Vous pouvez rendre votre service plus fiable en identifiant et en atténuant les risques. »

Les bases de l'analyse des risques

Avant de pouvoir évaluer et hiérarchiser vos risques, vous devez dresser une liste exhaustive des éléments à surveiller. Cet article a justement pour vocation de fournir quelques lignes directrices aux équipes chargées de réfléchir à tous les risques potentiels liés à une application ou un service. Une fois cette liste établie, nous vous montrerons comment analyser et hiérarchiser les risques que vous avez identifiés.

Quels sont les risques à prendre en compte ?

Lors d’un brainstorming sur les risques potentiels, il est important d’essayer de les cartographier en les regroupant dans différentes catégories : risques liés aux dépendances, à la surveillance, aux ressources, aux opérations, au processus de publication. Pour chacun d’eux, imaginez ce qui se passera si des défaillances spécifiques se produisent, par exemple si un fournisseur tiers est en panne ou si vous introduisez un bug applicatif ou de configuration.

Lorsque vous réfléchissez aux mesures à mettre en place, posez-vous les questions suivantes :

Y a-t-il des lacunes dans vos capacités d’observabilité ?
Avez-vous des alertes pour ce SLI spécifique ?
Collectez-vous déjà les mesures utiles ?

Veillez également à cartographier toutes les dépendances de surveillance et d'alerte. Typiquement, que se passe-t-il si un système managé que vous utilisez tombe en panne ?

Idéalement, il vous faudra identifier les risques associés à chaque point de défaillance pour chaque composant critique dans un parcours utilisateur critique, ou CUJ. Et après avoir identifié ces risques, il vous faudra les quantifier :

Quel pourcentage d'utilisateurs sera affecté par la défaillance ?
À quelle fréquence estimez-vous que cette défaillance se produira ?
Combien de temps faudra-t-il pour détecter la défaillance ?

Il est également très utile de recueillir des informations sur tout incident survenu au cours de l'année écoulée et ayant impacté les CUJ. Un brainstorming repose essentiellement sur votre intuition. Mais s'appuyer sur des données historiques fournit des estimations plus précises et un bon point de départ pour cerner les incidents réels. Typiquement, vous pouvez envisager des incidents tels que :

Un incident de configuration qui réduit la capacité, provoquant une surcharge et des requêtes abandonnées.
Une nouvelle version qui casse un petit ensemble de requêtes. La panne n'est pas détectée pendant une journée. Un retour en arrière rapide lorsqu'elle est détectée.
Une panne de réseau ou de machine virtuelle dans une seule zone chez un fournisseur de services cloud.
Une panne régionale des VM ou du réseau d'un fournisseur Cloud.
Un opérateur qui supprime accidentellement une base de données, ce qui nécessite une restauration à partir d'une sauvegarde.

Autre aspect à ne pas négliger, les facteurs de risque ! Il s'agit de facteurs globaux qui affectent le temps global de détection (TTD) et le temps de réparation (TTR). Il s'agit généralement de facteurs opérationnels qui peuvent augmenter le temps nécessaire à la détection des pannes (par exemple lors de l'utilisation de mesures en appui sur les logs) ou nécessiter l'alerte des ingénieurs d'astreinte. Un autre exemple pourrait être le manque de documentations ou le manque de procédures automatiques. Par exemple, vous constatez :

Un temps estimé de détection (ETTD) de +30 minutes en raison d'une surcharge opérationnelle notamment liée à des alertes bruyantes.
Une fréquence accrue de 10 % d'une éventuelle défaillance, en raison du manque de « post-mortems » (analyses post-incident) ou de suivi des actions.

Bonnes pratiques de Brainstorming…

Au-delà des aspects techniques d’un risque potentiel pour un service donné et des questions vues ci-dessus et qu’il est essentiel de se poser, il existe aussi quelques bonnes pratiques à prendre en compte lors de la tenue d'une session de brainstorming avec votre équipe.

Commencez la discussion par un schéma fonctionnel de haut niveau de votre service, de ses utilisateurs et de ses dépendances.
Collectez un ensemble d'opinions diverses dans la salle en interrogeant différents rôles dont le rapport avec le produit au cœur des discussions diffère du vôtre. Évitez de donner la parole à une seule partie. Demandez aux participants comment chaque élément du diagramme pourrait provoquer une erreur perceptible par l'utilisateur. Regroupez les causes similaires dans une seule catégorie de risque, telle que "panne de la base de données" par exemple.
Essayez d'éviter de passer trop de temps à discuter de choses pour lesquelles le temps estimé entre deux défaillances est supérieur à quelques années, ou pour lesquelles l'impact est limité à un très petit sous-ensemble d'utilisateurs.

Création du catalogue de risques

Soyons clairs. Il ne sert à rien d’élaborer une liste interminable de risques. En pratique, sept à douze risques par indicateur de niveau de service (SLI) sont suffisants. L'essentiel, c’est que les données collectées capturent les risques critiques et à forte probabilité.

Il est préférable de commencer par des pannes réelles, déjà rencontrées sur ce service ou un service similaire. Des pannes qui peuvent être aussi banales que l’indisponibilité d’un service appelé ou du réseau.
Intéressez-vous à la fois aux problèmes liés à l'infrastructure et à ceux liés aux logiciels.
Pensez aux risques qui peuvent affecter le SLI, le temps de détection et le temps de résolution, ainsi que la fréquence - plus de détails sur ces mesures ci-dessous.
Collectez à la fois les risques issus du catalogue de risques et les facteurs de risques (facteurs globaux). Typiquement, le risque de ne pas disposer d'un playbook augmente le délai de réparation ; le risque de ne pas disposer d'alertes pour les CUJ augmente le délai de détection ; le risque d'un retard de synchronisation des journaux de x minutes augmente d'autant le délai de détection. Ensuite, cataloguez tous ces risques et leurs impacts associés dans un onglet d'impacts globaux.

Voici quelques exemples de risques :

Une nouvelle version interrompt un petit nombre de requêtes ; l’anomalie reste non détectée pendant une journée ; retour en arrière rapide une fois détectée.
Une nouvelle version brise un sous-ensemble important de requêtes ; et pas de retour en arrière automatique.
Un incident de configuration réduit la capacité ; il engendre un pic d'utilisation non immédiatement repéré.

Recommandation : L'examen des données ou des résultats de la mise en œuvre du SLI vous donnera une bonne indication de votre situation par rapport à la réalisation de vos objectifs. Je recommande de commencer par créer un tableau de bord pour chaque CUJ - idéalement un tableau de bord comprenant des mesures qui vous permettront également de dépanner et de déboguer les problèmes de réalisation des SLO.

Analyse des risques

Maintenant que vous avez dressé une liste des risques potentiels, il est temps de les analyser, afin de hiérarchiser leur probabilité et de trouver les éventuels moyens de les atténuer. En d'autres termes, il est temps de procéder à une analyse des risques.

L’analyse de risques doit s’appuyer sur une approche basée sur les données afin d’adresser et prioriser les risques en les évaluant selon 4 dimensions clés : les TTD et TTR déjà susmentionnés, le délai entre les défaillances (TBF), et leur impact sur les utilisateurs.

Dans le guide « Shrinking the impact of production incidents using SRE principles » (réduire l’impact des incidents en production à l’aide des principes SRE), nous proposons un diagramme du cycle des incidents de production. Dans ce dernier, reproduit ci-dessous, la zone bleue représente les moments où les utilisateurs sont satisfaits, et celle en rouge ceux où ils sont mécontents.

Le temps pendant lequel vos services ne sont pas fiables et vos utilisateurs sont mécontents dépend directement du temps de détection et du temps de réparation. Il est aussi affecté par la fréquence des incidents (qui peut être traduit en temps entre les défaillances).

Il en résulte que l’on peut améliorer « la fiabilité » en augmentant le temps entre les pannes, en diminuant le temps de détection ou le délai de réparation et, bien sûr, en réduisant l'impact des pannes en premier lieu.

Concevoir votre service pour qu’il soit résilient contribue à réduire la fréquence des pannes générales. Il faut éviter les points de défaillance uniques (single points of failure) au sein de votre architecture, qu'il s'agisse d'une instance individuelle, d'une zone de disponibilité ou même d'une région entière. Objectif : empêcher qu'une petite panne localisée ne fasse boule de neige et n'entraîne un temps d'arrêt mondial...

Pour réduire l’impact d’un incident sur vos utilisateurs, il faut chercher soit à réduire le pourcentage d’infrastructure affectée ou le pourcentage d’utilisateurs touchés, soit à diminuer les requêtes (par exemple en limitant une partie des demandes plutôt que de toutes les traiter). Afin de réduire le rayon d’action des pannes, cherchez à éviter les changements globaux et optez pour des stratégies de déploiement avancées qui permettent un déploiement progressif des changements sur plusieurs heures, jours voire semaines. Ceci permet de réduire le risque de panne majeure et l’identification des problèmes avant que tous les utilisateurs n’en soient affectés.

Au-delà de ces mesures de bon sens, disposer de pipelines robustes d'intégration continue et de livraison continue (CI/CD) vous permet de déployer et de revenir en arrière en toute confiance et de réduire l'impact sur les clients (voir : SRE Book : Chapitre 8 - Release Engineering). La création d'un processus intégré de révision et de test du code vous aidera à trouver les problèmes à un stade précoce, avant que les utilisateurs ne soient affectés.

Améliorer le temps de détection (TTD) permet de s’assurer de corriger les pannes au plus vite. Le TTD estimé (ETTD) exprime le temps nécessaire pour qu’un être humain soit informé du problème. Il doit inclure tous les délais qui retardent l’assimilation de l’information. Par exemple, si l’entreprise utilise une alerte basée sur les logs et que le système de log affiche un temps d’ingestion des données de 5 minutes, cela accroit d’autant le TTD pour chaque alerte.

L'ETTR (estimated time-to-repair) est le délai entre le moment où un humain découvre l'alerte et le moment où vos utilisateurs voient un retour à la normale. L’amélioration du TTR (time-to-repair) signifie en principe que les pannes sont plus rapidement réparées. Cela dit, nous devons toujours nous demander si l’incident affecte toujours nos utilisateurs. Dans la plupart des cas, des mesures d'atténuation comme le roll-back des nouvelles versions ou le détournement du trafic vers des régions non affectées peuvent réduire ou éliminer l'impact d'une panne en cours sur les utilisateurs beaucoup plus rapidement que d'essayer de passer à une nouvelle version corrigée du service. La cause profonde n'est pas encore résolue, mais les utilisateurs ne le savent pas ou ne s'en soucient pas - tout ce qu'ils voient, c'est que le service fonctionne à nouveau.

Si l’automatisation tend à mettre hors du jeu l’être humain, elle permet de réduire le TTR et peut s’avérer cruciale pour atteindre des objectifs de fiabilité toujours plus élevés. Cependant, elle n’élimine jamais totalement le TTR. Si une mesure d'atténuation telle que le basculement vers une autre région est automatisée, il lui faut du temps pour se mettre en place et avoir un impact.

Une remarque sur les valeurs "estimées" : Au début d'une analyse de risques, vous pouvez commencer par des estimations approximatives de ces paramètres. Mais au fur et à mesure que vous collectez davantage de données sur les incidents, vous devez mettre à jour ces estimations en vous basant sur les données des pannes précédentes afin de refléter l’expérience utilisateur.

Un processus d'analyse des risques à haut niveau

Comme déjà évoqué, tout processus d'analyse de risques débute par un brainstorming sur les risques pour chacun de vos SLO, et plus précisément pour chacun de vos SLI, car différents SLI seront exposés à différents risques.

Dans la phase suivante, construisez un catalogue de risques et itérez pour l’enrichir et le mettre à jour.

Créez une fiche d'analyse de risques pour deux ou trois SLI, en utilisant ce modèle. Pour en savoir plus, consultez la page « Comment hiérarchiser (et communiquer sur) les risques ».
Faites un brainstorming interne sur les risques, en considérant les éléments qui peuvent affecter vos SLO et en rassemblant quelques données initiales. Faites-le d'abord avec l'équipe d'ingénierie, puis avec l'équipe produit.
Les fiches d'analyse de risques pour chacun de vos SLI doivent inclure l'ETTD, l'ETTR, l'impact et la fréquence. Incluez les facteurs globaux et les risques suggérés et indiquez si ces risques sont acceptables ou non.
Recueillez des données historiques et consultez l'équipe produit concernant les besoins des métiers en termes de SLO.
Itérez et mettez à jour les données en fonction des incidents en production.

Acceptation des risques

Après avoir établi le catalogue des risques et déduit les facteurs de risques, finalisez les SLOs en fonction des besoins de l'entreprise et de l'analyse des risques.

Lors de cette étape, vous devez évaluer si votre SLO est réalisable compte tenu des risques encourus. Et, si ce n'est pas le cas, vous devez vous demander quoi faire pour atteindre vos objectifs.

Il est essentiel que les Product Managers participent à ce processus de révision, notamment parce qu'ils peuvent être amenés à donner la priorité aux travaux d'ingénierie qui atténuent ou éliminent tout risque inacceptable.

Dans l’article « how to prioritize and communicate risks », nous expliquons comment utiliser la fiche « Risk Stack Rank » pour évaluer combien un risque donné peut vous "coûter", et quels risques vous pouvez accepter (ou non) pour un SLO donné.

Typiquement, dans cette fiche modèle, vous pourriez accepter tous les risques et atteindre une fiabilité de 99,5 %, certains des risques pour atteindre 99,9 % et aucun d'entre eux pour atteindre 99,99 %. Si vous ne pouvez pas accepter un risque parce que vous estimez qu'il consommera plus de budgets d'erreur que ce que votre SLO vous permet, il vous faudra consacrer du temps d'ingénierie à la résolution de sa cause première ou à la mise en place d'une mesure d’atténuation.

Une dernière remarque : comme pour les SLO, vous voudrez itérer sur votre risque en affinant votre ETTD sur la base du TTD réel observé pendant les pannes. Idem pour votre ETTR. C’est pourquoi, après chaque incident, vous devez mettre à jour les données et voir où vous en êtes par rapport à ces estimations. En outre, réexaminez périodiquement ces estimations pour évaluer si vos risques sont toujours pertinents, si vos estimations sont correctes ou s'il existe des risques supplémentaires que vous devez prendre en compte. À l’instar du principe SRE d'amélioration continue, c'est un travail qui n'est jamais vraiment terminé, mais qui en vaut la peine !

L’ouvrage sur le SRE fête ses 6 ans !

Thu, 19 May 2022 08:00:00 +0000

Difficile de croire que notre ouvrage « Site Reliability Engineering : How Google Runs Production Systems », publié chez O'Reilly Media, a déjà 6 ans ! Nous avons été à la fois très touchés et agréablement surpris par la popularité que ce livre fondateur a connue et qu’il connaît toujours.

Après ce best-seller, Google a publié deux autres ouvrages connexes que vous connaissez peut-être déjà : The Site Reliability Workbook et Building Secure and Reliable Systems.

Ces trois incontournables références sur les pratiques SRE sont disponibles gratuitement sur sre.google/books.

Si le contenu de l’ouvrage initial reste toujours d’actualité, il ne faut pas perdre de vue que le SRE est une discipline dynamique. Nos pratiques n’ont cessé d’évoluer et nous avons depuis approfondi le sujet au travers de nombreux articles de journaux, rapports, billets de blog et autres formations en ligne, publiés par nos SRE depuis 2016. Si nos trois ouvrages de référence sont facilement accessibles, retrouver toutes ces autres publications se révèle en revanche plus complexe. Sans compter qu’au cours de ces dernières années, les experts SRE de Google sont aussi intervenus dans des dizaines de conférences autour des sujets abordés dans notre ouvrage SRE originelle.

Dit autrement, depuis 2016, nous n’avons pas cessé d’enrichir notre discours autour des pratiques SRE. Afin de vous permettre de découvrir et explorer plus facilement nos avancées dans le domaine, nous avons donc décidé de regrouper l’ensemble des publications dans un nouveau recueil. Elles sont organisées selon les thèmes du livre original et disponibles sur « sre.google » : SRE Book Updates, by Topic.

Vous y trouverez des dizaines de ressources sur certains de nos sujets les plus populaires : les SLOs (service-level objectives ou objectifs de niveau de services), la supervision et les alertes, le Canarying (méthode pour optimiser les déploiements), la gestion des incidents et sa culture post-mortem (procédure préétablie des gestions des incidents) sans oublier la formation des SRE. N'hésitez pas à les explorer !

Nos SRE ont bien entendu aussi abordé des thèmes qui ne sont pas couverts par le premier livre SRE, comme le Machine Learning, le capacity planning, les innovations, la sécurité et la confidentialité. Ces sujets sont progressivement ajoutés à notre catalogue. Alors restez connectés pour ne pas les rater !

Boostez vos pratiques DevOps ? Une étude conseille d’essayer SRE !

Fri, 10 Dec 2021 10:00:00 +0000

La fiabilité, c’est essentiel ! Lorsqu’une application est inaccessible, se montre lente et peu réactive ou se comporte de façon inattendue, les utilisateurs n’en retirent pas la valeur que vous espériez leur fournir. C’est pourquoi chez Google nous ne cessons d’affirmer que la fiabilité est la fonctionnalité la plus importante de tout système, toute application, tout service. Son impact peut être perçu à tous les niveaux car les temps d'arrêt sont très coûteux en termes de revenus, de réputation et de fidélité des utilisateurs.

Dès le début du projet DORA (DevOps Research & Assessment), nous avons insisté sur l’importance d’une expérience cohérente pour les utilisateurs. Nous mesurons cet aspect à l’aide de quatre métriques clés : deux suivent la vitesse de déploiement de nouvelles versions et deux autres capturent la stabilité initiale de ces versions. Une équipe qui obtient de bons scores sur les quatre métriques n’est pas seulement une équipe efficace dans la livraison de codes, c’est aussi une équipe qui produit du code de qualité.

Toutefois, ces quatre signaux – qui se focalisent sur le déploiement et ses effets immédiats – ne mesurent pas les succès obtenus tout au long du cycle de vie d’une version. En 2018, DORA a commencé à étudier la stabilité « en continu » des logiciels livrés sous forme de services (tels que les Web Apps) au travers d’une métrique supplémentaire de « disponibilité » permettant d’explorer l’impact des opérations techniques sur la performance organisationnelle.

Cette année, nous avons encore élargi notre enquête en commençant par renommer la métrique « disponibilité » en « fiabilité ». La fiabilité (Reliability en anglais), parfois abrégée sous l’acronyme « r9y », est un terme plus général qui englobe davantage de dimensions à commencer par la latence des réponses et la validité du contenu en plus de la disponibilité.

Dans notre rapport sur l’état du DevOps en 2021, les équipes ont été réparties en quatre catégories selon quatre critères clés de la livraison de logiciels. De prime abord, on pourrait penser qu’il n’existe pas de corrélation directe entre l’utilisation de pratiques de fiabilité et la performance sur la livraison logicielle. En effet, les équipes qui obtiennent de bons résultats sur les métriques de livraisons ne sont pas forcément les mêmes que celles qui ont adopté un fonctionnement moderne des opérations (ce que l’on appelait autrefois « l’exploitation »).

Néanmoins, combinées, “performance de la livraison logicielle” et “ingénierie de la fiabilité” influent considérablement sur les résultats de l’organisation : les meilleures équipes sur la livraison logicielle qui atteignent également leurs objectifs de fiabilité ont 1,8 fois plus de chances d’afficher de meilleurs résultats Business. Dit autrement, en alliant DevOps et SRE, les entreprises ont quasiment deux fois plus de chance de réussir.

La recette de Google pour atteindre la fiabilité : SRE

Au début, nous avions chez Google adopté une approche traditionnelle des opérations techniques : l’essentiel du travail se concrétisait par des interventions manuelles face à des problèmes distincts.

Toutefois, nous avons réalisé que cette approche n’était pas durable. Elle n’était pas adaptée à la taille et à la complexité croissante de nos systèmes. Rien que le fait d’essayer de tenir la cadence supposait des investissements inconcevables en ressources humaines.

Nous avons donc, ces 15 dernières années, pratiqué et amélioré une méthode baptisée Site Reliability Engineering (SRE) ou « ingénierie de la fiabilité des sites ».

SRE fournit un cadre, un framework, pour mesurer, hiérarchiser et partager des informations afin d’aider les équipes à trouver le meilleur équilibre entre rapidité de livraison de nouveaux services et prévisibilité du comportement de ces nouveaux services. Il met l’accent sur l’automatisation.

Objectif : réduire les risques et libérer les ressources d’ingénierie pour des tâches ayant plus de valeur ajoutée. Cette définition est très similaire à celle de DevOps. De fait, ces deux disciplines partagent de nombreuses valeurs. Cette similitude a d’ailleurs provoqué quelques remous en 2016 quand Google a publié son premier ouvrage sur le Site Reliability Engineering, les acteurs des communautés DevOps y voyant un courant de pensée similaire. Elle a aussi engendré une certaine confusion : DevOps et SRE sont parfois présentés comme deux courants en conflit ou en concurrence.

De notre point de vue - et dans la mesure où DevOps et SRE sont nés des mêmes problématiques et visent des objectifs similaires - ces deux approches sont mutuellement compatibles, voire complémentaires. Métaphoriquement, nous avons fait valoir que « class SRE implements DevOps ». Ce qui signifie que SRE propose un moyen pour réaliser les objectifs DevOps.

Inspirés par des communautés en croissance constante et des échanges continus d’idées, nous avons cherché à approfondir la relation entre ces deux courants. Ainsi, cette année, nous avons étendu le champ de notre étude afin d’évaluer l’adoption de SRE par les entreprises et comprendre comment ces pratiques opérationnelles modernes interagissent avec le modèle DORA (DevOps Research Assessment) d’évaluation des performances de la livraison logicielle.

En appui sur la littérature SRE existante, nous avons enrichi notre étude 2021 d’éléments clés du framework SRE. Nous avons évité le jargon technique pour privilégier un langage simple à même de décrire la façon de travailler des opérationnels ayant adopté une approche moderne.

Les personnes interrogées ont mentionné des pratiques telles que : définition de la fiabilité en termes de comportement visible par l’utilisateur ; utilisation de l’automatisation pour permettre aux opérationnels de se focaliser sur des tâches à valeur ajoutée ; disposer de processus bien définis et correctement appliqués pour réagir en cas d’incident...

Nous avons constaté que l’utilisation de SRE pour mettre en œuvre DevOps était beaucoup plus répandue que nous le pensions.
SRE, et d’autres approches connexes comme le « Production Engineering » de Facebook, ont la réputation d’être des disciplines de niche, pratiquées uniquement par une poignée de géants du Web. Dans les faits, nous avons découvert au cours de cette enquête DORA 2021 que la majorité des équipes interrogées utilisent le SRE, 52% des répondants ayant déclaré avoir recours à une ou plusieurs pratiques SRE.

SRE, un levier puissant pour gagner en excellence sur la livraison logicielle

L’analyse des résultats de cette enquête apporte la preuve que l’approche SRE est efficace dans toutes les organisations. En plus d’améliorer la performance des entreprises, SRE constitue une aide précieuse pour mieux gérer les efforts : les équipes ayant atteint leurs objectifs de fiabilité notent qu’elles consacrent plus de temps à coder parce qu’elles sont moins sollicitées par la gestion des incidents. Ces résultats sont cohérents avec le fait que la fiabilité des services peut directement impacter les revenus de l’entreprise tout en offrant aux opérationnels une plus grande flexibilité, leur permettant de passer plus de temps à améliorer les systèmes plutôt qu’à les réparer.

Toutefois, et bien que SRE se soit largement répandu avec des bénéfices concrets à la clé, peu de personnes interrogées ont indiqué que leurs équipes avaient implémenté la totalité des pratiques SRE examinées. Mais une application étendue de SRE apporte des avantages à tous les niveaux : dans chacune des 4 catégories de maturité de la livraison logicielle, les équipes qui atteignent parallèlement leurs objectifs de fiabilité surpassent les autres en résultats business.

Sur la route SRE, vers l’excellence DevOps

SRE est plus qu’un ensemble d’outils. C’est un état d’esprit, une certaine culture du rôle des équipes opérationnelles. SRE est une discipline d’apprentissage qui vise à comprendre l’information et savoir itérer en continu. C’est pourquoi l’adoption d’une doctrine SRE prend du temps et nécessite de démarrer modestement et d’itérer.

Voici quelques conseils pour bien démarrer :

* exploitez les livres et contenus proposés sur SRE.Google

* Rejoignez les conversations des spécialistes à différentes étapes de l’implémentation SRE sur bit.ly/reliability-discuss

* Parlez-en à votre responsable de compte GCP pour découvrir nos offres de services professionnelles

Enfin, n’hésitez pas à postuler aux DevOps Awards pour montrer comment votre organisation met en œuvre des pratiques SRE gagnantes grâce aux principes DORA.

Rapport DevOps 2021 : burnout et performance des équipes

Thu, 21 Oct 2021 09:00:00 +0000

Plus de 32 000 professionnels dans le monde ont participé à nos rapports « Accelerate State of DevOps » ces sept dernières années, ce qui en fait l’étude la plus complète sur ce sujet. Année après année, ces rapports - établis à partir des données collectées dans les entreprises - dressent un état des tendances dans le domaine de la production logicielle : capacités, pratiques, performances organisationnelles et opérationnelles… Et cette année ne fait pas exception : l’équipe DORA (DevOps Research & Assessment) de Google Cloud est ravie d’annoncer l’édition 2021 de son Accelerate State of DevOps Report.

Notre étude 2021 montre que l’excellence opérationnelle et la performance de la chaîne de production de logiciels continuent à jouer un rôle majeur dans la réussite de la transformation technologique des entreprises. Cette année, nous avons également porté notre attention sur les meilleures pratiques SRE, la sécurité de la chaîne de livraison des logiciels, la qualité de la documentation ou encore le multicloud afin d’en mesurer les conséquences. En parallèle, nous avons aussi cherché à comprendre quels impacts l’année qui vient de s’écouler a pu avoir sur le burnout et l’ambiance au sein des équipes.

Voici les points clés à retenir de cette étude :

Les indicateurs de performance de la production logicielle

Sur la base des conclusions des précédents rapports, nous avons arrêté 4 indicateurs (élite, haute, médium, faible) pour classer la performance des équipes sur la livraison des applications en prenant en compte la fréquence de déploiement, le délai pour implémenter des changements, le temps moyen de restauration et le taux d’échecs sur l’implémentation de changements.
Nous avons ainsi constaté que les équipes « élites » ont continué cette année à accélérer le rythme de leur production logicielle tout en améliorant les délais de déploiement des changements : moins d’une heure contre un jour auparavant. Elles déploient surtout 973 fois plus souvent qu’une équipe « faible » et affichent un délai 6.570 fois plus court pour déployer un changement, un taux de défaillance 3 fois plus faible et un temps moyen de restauration 6.570 fois plus court lorsqu’un incident de déploiement surgit.
Autrement dit, les équipes « élites » démontrent une performance organisationnelle sans commune mesure avec les équipes qui accusent un retard sur la transformation DevOps.

Le cinquième indicateur : de la disponibilité à la fiabilité

Jusqu’ici, nous mesurions la disponibilité plutôt que la fiabilité. Cependant la disponibilité n’est qu’un des critères de mesure de l’ingénierie de la fiabilité. Aussi avons-nous, en 2021, étendu notre étude à davantage de critères de fiabilité afin que, outre la disponibilité, la latence, les performances et l’évolutivité soient plus largement représentées. Plus précisément, nous avons demandé aux répondants d'évaluer leur capacité à atteindre ou à dépasser leurs objectifs de fiabilité. Nous avons constaté que les équipes – quels que soient les degrés de maturité dans la production logicielle et les approches DevOps – obtiennent de meilleurs résultats en matière de fiabilité lorsqu'elles accordent également la priorité à la performance opérationnelle.

Perspectives 2021 : impacts de la fiabilité, du COVID et des chaînes d'approvisionnement applicatives sécurisées

Outre l’impact de l’adoption de DevOps sur les performances de la production logicielle, le rapport DORA de cette année a également révélé de nouvelles tendances. En voici un échantillon.

1. Une culture d'équipe saine atténue le surmenage (burnout) pendant les périodes difficiles

Les répondants qui travaillaient à la maison en raison de la pandémie ont été plus sujets au burnout que ceux restés au bureau (qui ne constituaient qu’une petite partie de notre échantillon). Les équipes inclusives, ayant une vraie culture DevOps, ont expérimenté deux fois moins de burnouts pendant la pandémie de COVID-19.

2. Les équipes les plus performantes continuent à élever la barre

Pour la première fois, les équipes de niveau « élite » et « haute performance » représentent les deux tiers des répondants. Par comparaison, lors du rapport de 2019, les équipes classées « moyennes » ou « faibles » représentaient 56 % des répondants. Nous pouvons affirmer avec certitude que l'industrie continue d'accélérer son adoption des principes DevOps et que les équipes constatent des avantages significatifs en retour.

3. SRE et DevOps : deux philosophies complémentaires

Au-delà de ses principes intrinsèques, SRE (Site Reliability Engineering) apporte des techniques pratiques, tel le framework de mesures SLI/SLO (Service Level Indication/Service Level Objective).

Le cadre SRE définit les bonnes pratiques et les outils permettant d’améliorer la capacité d’une équipe à tenir les promesses faites aux utilisateurs. Les équipes qui donnent à la fois la priorité à l’excellence opérationnelle et à la production logicielle affichent également la meilleure performance organisationnelle.

Pour analyser cet aspect, nous avons cette année inclus, pour la première fois dans notre étude, des questions centrées sur les opérations IT. Il en ressort que les équipes qui excellent dans les pratiques opérationnelles modernes sont 1,4 fois plus susceptibles d’afficher une plus grande performance dans la production logicielle et les opérations (aussi appelée performance SDO). Elles sont aussi 1,8 fois plus susceptibles de parvenir à de meilleurs résultats Business.

4. L'adoption de cloud stimule la performance

En 2021, les équipes continuent de migrer les workloads vers le cloud. Celles qui tirent parti des cinq capacités du cloud voient non seulement leur performance SDO augmentée mais également leur performance organisationnelle. L'adoption multicloud est également en hausse, les équipes cherchant à tirer avantage des capacités spécifiques à chaque opérateur. Dans les faits, les répondants exploitant des services hybrides ou multicloud se sont révélés 1,6 fois plus susceptibles de dépasser leurs objectifs de performance organisationnelle.

5. Une supply chain des logiciels sécurisée est fondamentale et stimule les performances

La sécurité ne peut plus être une réflexion a posteriori. Elle doit être intégrée à toutes les étapes du développement logiciel pour construire une chaîne d'approvisionnement sécurisée. Les équipes de niveau « élite » qui ont atteint ou dépassé leurs objectifs de fiabilité étaient deux fois plus susceptibles d'avoir fait évoluer leurs pratiques de sécurité. Autrement dit, ces dernières ont mis en œuvre des pratiques de sécurité plus tôt dans le cycle du développement et ont livré des applications plus fiables, plus rapidement et en toute sécurité.

6. Une bonne documentation est essentielle à une mise en œuvre réussie de DevOps

Pour la première fois, nous avons mesuré la qualité de la documentation interne et son effet sur d'autres capacités et pratiques. Nous avons ainsi découvert que la documentation est fondamentale dans une mise en œuvre réussie de DevOps. Les équipes ayant une documentation de haute qualité sont 3,8 fois plus susceptibles de mettre en œuvre les meilleures pratiques de sécurité et 2,5 fois plus à même de tirer pleinement parti du potentiel du cloud.

Lancement des DevOps Awards

Depuis plusieurs années, nous partageons avec vous certaines de nos meilleures pratiques DevOps. Aujourd’hui, nous aimerions découvrir comment, de votre côté, vous transformez votre organisation avec DevOps.

À l’occasion de nos premiers DevOps Awards (qui seront reconduits chaque année), nous récompenserons les clients Google Cloud qui ont amélioré leur fréquence de déploiement, ont réussi à améliorer leur sécurité, ont réduit leur taux d’échecs, etc. Parlez-nous de l'impact positif de DevOps sur vos équipes, vos clients et votre organisation.

Partagez votre expérience DevOps ici dès aujourd’hui !

Merci à tous ceux qui ont répondu à notre sondage 2021. Nous espérons que ce rapport « Accelerate State of DevOps » aidera les organisations de toutes tailles, industries et régions à améliorer leur expérience DevOps, et nous sommes impatients d'entendre vos réflexions et vos commentaires.

Pour en savoir plus sur le rapport et la mise en œuvre de DevOps avec Google cloud, consultez les ressources suivantes :

Télécharger le rapport
Pour en savoir plus sur la façon dont votre organisation se situe par rapport à d'autres dans votre industrie, essayez notre DevOps Quick Check
Pour des solutions DevOps personnalisées pour votre organisation, consultez notre nouveau site web CAMP
Pour en savoir plus sur les aptitudes DevOps des équipes classées « Elite »

Quatre étapes pour bien démarrer votre initiative SRE

Thu, 23 Sep 2021 09:00:00 +0000

Il y a quelques mois, nous abordions le sujet de l'ingénierie de fiabilité des sites ou SRE (Site Reliability Engineering) en indiquant que pour mener à bien ce type d’approche, il fallait commencer par définir un leadership. Dans ce billet de blog, nous allons voir comment, en tant que leader IT, vous pouvez aborder les étapes suivantes et accélérer l’approche SRE au sein de vos équipes.

Étape 1 : Démarrer petit et itérer

« Rome ne s’est pas faite en un jour » comme le rappelle l’adage populaire. Mais il faut bien commencer quelque part. Pour mettre en pratique les principes de SRE, nous conseillons de démarrer par un PoC (Proof of Concept), d’apprendre de ses erreurs et d’itérer.

Commencez par identifier une application et/ou une équipe pertinente. De nombreux facteurs peuvent influencer le choix d’une équipe ou d’une application spécifique pour votre PoC SRE. Il s’agit cependant souvent d’une décision stratégique pour la DSI ou l’entreprise, qui dépasse le champ de cet article. Les candidats possibles peuvent être par exemple une équipe qui évolue d’opérations traditionnelles ou DevOps vers SRE ou un besoin particulier d’augmenter la fiabilité d’un produit clé pour l’entreprise.

Quelles que soient les raisons, il est essentiel de sélectionner une application qui soit à la fois :

Critique pour l’entreprise – sa disponibilité et sa fiabilité impactent profondément la satisfaction client.
En cours de développement – il faut choisir une application sur laquelle l’entreprise investit activement ses ressources.
Et, idéalement, qui fournit de nombreuses données et métriques sur son comportement.

À l'inverse, évitez les logiciels propriétaires. Si l’application n’a pas été construite en interne, elle n’est pas une bonne candidate au SRE ! Car vous aurez besoin de prendre des décisions stratégiques sur sa conception et son ingénierie.

Pro tip : De manière générale, si vous disposez de workloads à la fois sur site (on-premises) et dans le cloud, privilégiez les applications cloud. Il sera plus facile à des ingénieurs habitués à un environnement d’opérations traditionnel de se défaire de leur mentalité orientée « bare-metal » et métriques d’infrastructure si l’application est hébergée dans le cloud. Une infrastructure managée transforme en effet les opérationnels en utilisateurs et les oblige à consommer l’IT comme des développeurs (API, Infra as Code, etc.).

Rappel : fixer des objectifs accessibles. Des attentes trop irréalistes ne peuvent que décourager votre équipe et impacter l’initiative de façon négative.

Étape 2 : Encourager votre équipe

La mise en œuvre des principes SRE suppose le développement d’une culture d’apprentissage. À cet égard, il convient de souligner qu’il ne suffit pas de former son équipe. Elle doit bien entendu monter en compétences mais aussi en responsabilité et en autonomie.

Bâtir un programme de formation est déjà un défi en soi mais il est tout aussi important de réfléchir dès le départ à une stratégie pour se donner les moyens de réussir. Particulièrement au sein des grandes organisations, il est essentiel d’anticiper des sujets comme la promotion interne, le perfectionnement, l’embauche, l’accroissement de l’équipe tout comme le onboarding (intégration de nouveaux équipiers) et la création d’une communauté d’apprentissage.

Cette stratégie doit être personnalisée en fonction des niveaux et fonctions des membres de l’équipe. Typiquement, la formation des responsables sera très différente de celles des opérationnels IT. Pour imposer un tel changement à l’échelle d’une organisation, il peut ainsi s’avérer nécessaire de dispenser aux responsables une formation supplémentaire sur les concepts culturels et les bonnes pratiques.

Pour les leaderships et/ou les managers intermédiaires (managers qui gèrent d’autres managers), il convient de prévoir une formation qui mixte les concepts culturels de haut niveau (afin de favoriser le développement d’une culture SRE) à des pratiques techniques SRE avancées, essentielles pour comprendre la priorisation, l'allocation des ressources, la création de processus et les besoins futurs.

Concernant les opérationnels, il est préférable que l’ensemble de l'organisation soit aligné sur les mêmes valeurs, tant du point de vue culturel que de celui des compétences. Toutefois, comme nous l’avons mentionné précédemment, il vaut mieux commencer simplement, avec une seule équipe.

Pour revenir aux équipes, il est préférable de commencer par leur inculquer la notion de fiabilité et des concepts clés tels que SLAs, SLOs, SLIs ou encore les error budgets. SRE étant focalisé sur l’expérience client, la capacité des systèmes à répondre aux attentes des clients est au cœur de la démarche. Ce qui implique un changement de posture de la part des équipes qui peut parfois prendre du temps.

Une fois la première application sélectionnée, il convient d’identifier le parcours client proposé. Autrement dit les interactions déclenchées par le client pour réaliser une action spécifique (du simple clic à une succession d’opérations). Il ne reste plus ensuite qu’à les classer en fonction de leur impact business. Les plus critiques sont appelées CUJ (Critical User Journeys) et doivent servir de point de départ à l’élaboration de vos SLO (Service Level Ojectives) et SLI (Service Level Indicators).

Pro tip : Il existe quelques bonnes pratiques générales pour adopter une approche SRE plus rapidement. Par exemple, utiliser moins de repositories contribue à réduire les silos au sein de l’organisation et à mieux exploiter les ressources.

De même, donner la priorité aux processus automatiques et aux systèmes d’auto-maintenance peut non seulement améliorer la fiabilité, mais aussi accroître la satisfaction de toute l'équipe. Satisfaction essentielle pour aider l’entreprise à retenir ses talents.

Note finale : Comme dans toutes décisions d'architecture que vous prenez, la technologie, les solutions et les outils d'implémentation choisis doivent vous permettre d’atteindre vos objectifs et non vous handicaper dans votre initiative.

Étape 3: Propager ces enseignements

Après avoir éprouvé ces pratiques sur une ou plusieurs équipes, l’étape suivante consiste à mettre en place une communauté SRE et à formaliser les processus à travers toute l’entreprise. Certaines organisations entreprennent cette étape tout en finalisant la phase 2. D’autres préfèrent attendre la réussite de quelques implémentations avant d’attaquer cette nouvelle phase.

Au cours de cette étape, plusieurs sujets doivent impérativement être abordés : communauté, culture, autonomisation, processus… Aucun ne devra être oublié d’autant qu’ils sont imbriqués. Mais il appartient à chaque entreprise de définir ses propres priorités.

Ainsi, la création d’une communauté SRE est une composante essentielle, tant du point de vue des apprentissages que pour construire une base de connaissance des meilleures pratiques, former des experts sur le sujet, aider à la création de garde-fous indispensables et harmoniser les processus.

Mais la création de cette communauté va de pair avec le développement d’une culture de la fiabilité et la formation des équipes. Objectif : ambassadeurs SRE, les pionniers partagent ce qu’ils ont appris et forment les nouvelles équipes.

C’est pourquoi il convient d’identifier les potentiels ambassadeurs ou les champions au sein des équipes de développement : passionnés de SRE, ils faciliteront l’adoption de ces pratiques.

Il est également essentiel de créer des formations aisément répétables pour chaque rôle fonctionnel, y compris des sessions portant sur l’intégration de nouveaux membres. Accueillir de nouveaux membres dans une équipe constitue en effet un volet essentiel de tout programme de formation et participe au développement d'une culture SRE généralisée. En d’autres termes, il faut être très attentif au processus d’intégration tout en s’assurant que les connaissances ne sont pas perdues lorsqu’un membre de l'équipe change de rôle.

Cette phase est également le moment idéal pour encourager le développement d’une culture à l’échelle de l’entreprise qui promeut le bien-être psychologique, qui accepte l’échec et qui permet aux équipes d’apprendre de leurs erreurs. Pour y parvenir, les dirigeants doivent formaliser la culture qu’ils souhaitent mettre en place et promouvoir la transparence.

Enfin, des processus formalisés et structurés contribuent à réduire le stress face aux situations d’urgence. Les processus apportent de la clarté, facilitent la collaboration et rendent les équipes plus efficientes.

Pour un impact maximal, commencez par traiter les tâches les plus pénibles relevant des compétences de votre équipe. Effectuez, par exemple, un nettoyage des alertes afin d’éviter la surcharge de travail engendrée par les faux positifs. De la même façon, automatisez les processus de gestion du changement. Enfin, n’impliquez que les personnes nécessaires pour économiser la bande passante de l’équipe. Les membres d’une équipe ne devraient pas avoir à travailler sur des projets d’ingénierie logicielle tout en étant responsables de la gestion des incidents. Assurez-vous qu’ils ont la bande passante pour effectuer ces deux tâches séparément. Orientez vos décisions en vous appuyant sur des données factuelles, comme les activités qui reviennent le plus souvent et le temps que vos équipes y consacrent.

Si vous rencontrez des difficultés pour collecter ce type de données, qu’elles soient d’ordre qualitatif ou quantitatif, commencez par vos processus d’intervention d’urgence (processus d’escalade, gestion des incidents et politiques connexes) : ils ont généralement un impact direct sur le business.

Pro tip: Toutes ces pratiques contribuent à réduire les silos et à aligner toute l’entreprise sur des objectifs communs. Pensez également à intégrer vos fournisseurs et partenaires techniques. À cette fin, assurez-vous que les contrats signés avec eux intègrent bien ces objectifs.

Étape 4 : Développer une culture de la donnée

Même si vous ne l’appliquez qu’à une seule équipe, mettre en place une démarche SRE prend du temps. La collecte de données et la réalisation d’analyses « post-mortem » irréprochables (aussi appelées « PIR » ou « Revue post-incident ») permettent d’obtenir des résultats rapides.

Toute initiative SRE cherche à s’appuyer autant que possible sur des données à même de mesurer le niveau de fiabilité. Aussi est-il essentiel de développer une culture de la mesure au sein de votre organisation. Au moment de hiérarchiser la collecte des données, focalisez vos efforts sur celles qui mesurent l’expérience utilisateur. Collecter ces données vous aidera à mieux identifier vos lacunes et à hiérarchiser vos priorités en fonction des besoins de votre entreprise et de l’attente de vos clients.

Parallèlement, réaliser des analyses « post-mortem » constitue un excellent moyen d’apprendre de ses échecs et de favoriser une forte culture SRE. Il est important de garder en tête que ces analyses doivent être irréprochables de sorte que l’équipe se sente en confiance pour partager ses découvertes et apprendre de l’échec. Et afin d’éviter de répéter les mêmes erreurs, il est important d’intégrer dans ces analyses post-mortem des éléments d’action clairement assignés à un « owner », autrement dit à un responsable identifié.

Enfin, créer un repository partagé des analyses ‘post-mortems’ peut avoir un impact majeur sur les équipes : un tel repository améliore la transparence, réduit les silos et contribue à établir une culture d’apprentissage. Cela permet également de montrer aux équipes que l’organisation « pratique ce qu’elle prêche ». D’autant que l’implémentation d’un tel repository ne présente aucune difficulté et peut se limiter à la simple création d’un dossier partagé.

Pro Tip : Les analyses “post-mortem” doivent être irréprochables et suggérer des actions pour remédier aux causes de l’échec.

Plus loin avec le fast track SRE

Bien sûr, il n'y a pas deux organisations semblables. Il en va de même des équipes SRE. Mais en suivant ces étapes, vous pouvez guider votre équipe sur la voie du succès SRE plus rapidement. Pour en savoir plus sur l'élaboration d'une pratique efficace des SRE, consultez les ressources suivantes.

Apprenez à développer des applications sans code pour vous simplifier la tâche

Wed, 03 Feb 2021 11:04:00 +0000

Editor’s Note: Cet article est tiré du blog The Keyword.

Grâce à AppSheet de Google Cloud, n'importe qui peut créer des applications personnalisées sans avoir à écrire de code. Que vous travailliez pour une grande entreprise souhaitant passer au numérique ou au sein d'une petite équipe cherchant des solutions créatives pour organiser des événements pendant la pandémie, les possibilités sont infinies.

Notre meilleur conseil pour ceux qui débutent ? Lancez-vous, tout simplement. Le meilleur moyen d'apprendre à développer des applications sans code, c'est d'accéder à la plate-forme et de commencer à l'utiliser. Plus vous créerez des applications et corrigerez leurs problèmes, plus vous améliorerez leur qualité et vos compétences.

Voici la liste de certains de nos guides pratiques les plus populaires pour vous aider à vous lancer. Quel que soit votre cas d'utilisation ou votre secteur d'activité, vous découvrirez des conseils utiles, des modèles d'applications et des suggestions de dépannage pour booster vos compétences en développement.

1. Créer une application mobile intégrant la géolocalisation et Google Maps en 5 minutes

En intégrant Google Maps à votre application AppSheet, vous pouvez créer une application de géolocalisation simple en quelques minutes. Vous pouvez également y consacrer plus de temps pour qu'elle inclue des suggestions d'actions à effectuer en fonction de l'avancement des tâches, par exemple pour assurer le bon déroulement d'un projet ou des livraisons dans les délais impartis.

2. Développer 6 applications d'automatisation dès aujourd'hui

Prêt à découvrir les vrais avantages du développement sans code ? Tous les modèles d'applications présentés dans ce document vous permettent d'éliminer les processus manuels et de libérer de précieuses ressources. Copiez un ou deux de ces modèles (comme "Sequential Tasks" ou un autre de la sélection), et ajoutez-les à votre catalogue pour les personnaliser et créer vos propres applications. Le meilleur dans tout ça ? La fonctionnalité de workflow intégrée vous permet de tester et de vérifier votre application avant de la personnaliser.

3. Gérer les ventes : 3 modèles Excel gratuits pour la suivi des ventes

Les commerciaux ont souvent du mal à trouver des applications qui répondent à leurs besoins. Certains doivent pouvoir accéder aux données où qu'ils se trouvent, d'autres ont besoin d'applications adaptées aux ordinateurs de bureau, et d'autres encore cherchent des outils combinant toutes ces caractéristiques et même plus. La polyvalence imposée par ce travail nécessite une solution aussi agile que votre équipe. Avec ces trois modèles, vous disposez des éléments de base pour effectuer le suivi de vos prospects, créer des rapports et ajouter des données de terrain, indépendamment de l'environnement de travail et de la taille de votre entreprise.

4. Créer une application de gestion de l'inventaire depuis Google Sheets avec AppSheet

La gestion de l'inventaire est l'une des raisons les plus fréquentes qui poussent les développeurs d'applications à utiliser AppSheet et à se lancer sur la plate-forme. Que vous gériez l'inventaire d'un magasin en ligne ou que vous souhaitiez mettre à jour votre processus d'inventaire interne, ce tutoriel avancé vous offre une présentation détaillée de concepts clés pour améliorer vos compétences en développement, sans code.

5. Développer une application axée sur l'expérience client avec Google Docs

Deux points importants sont à retenir. Premièrement, vous pouvez créer des applications à partir de vos documents Google Docs. Deuxièmement, essayez de voir au-delà de votre cas d'utilisation lorsque vous parcourez les exemples d'applications. Découvrez dans cet exemple comment transformer notre modèle populaire d'application d'enquêtes de terrain en application axée sur l'expérience client.

6. Découvrir comment l'équipe AppSheet utilise le produit

Soyons honnêtes : il est toujours intéressant de voir comment l'équipe qui a développé un produit l'utilise en interne. Dans ce post, vous découvrirez des exemples et des aperçus de ce qui facilite l'organisation de notre équipe, simplifie l'avancée des projets et améliore la gestion de notre temps.

Maintenant que vous connaissez certaines des possibilités qui s'offrent à vous, il est temps de concevoir vos propres applications afin de tester vos nouvelles compétences. Et si vous avez besoin d'inspiration, accédez à la communauté AppSheet pour découvrir les applications créées par d'autres développeurs.

Vous êtes prêt à utiliser AppSheet ? Lancez-vous dès maintenant.

Trois mois, 30 fois plus de demande : comment nous avons fait évoluer Google Meet dans le contexte du COVID-19

Thu, 06 Aug 2020 17:59:00 +0000

Le COVID-19 ayant peu à peu obligé le monde entier à garder ses distances, de nombreuses personnes se sont tournées vers la visioconférence en ligne pour rester en contact avec leurs proches, leurs élèves ou enseignants, et leurs collègues. Comme le montre le graphique ci-dessous, ce changement a généré une très importante augmentation du nombre d'utilisateurs sur Google Meet.

Le nombre de sessions par continent en période de pic a dicté la capacité de diffusion qu'il nous fallait avoir à disposition

Dans cet article, je vais vous expliquer comment nous nous sommes assurés que Meet ait une capacité de service disponible suffisante pour supporter la multiplication par 30 de son utilisation en raison du COVID-19. Je détaillerai également les mesures que nous avons prises pour rendre cette croissance viable d'un point de vue technique et opérationnel, grâce à un certain nombre de bonnes pratiques d'ingénierie en fiabilité des sites (SRE).

Les premières alertes

Alors que le monde découvrait progressivement le COVID-19, les individus ont commencé à adapter leurs habitudes au quotidien. L'impact grandissant du virus sur les modes de travail, l'enseignement et les relations sociales s'est traduit par une augmentation croissante de l'utilisation de services comme Google Meet pour pouvoir rester en contact. Le 17 février, l'équipe d'ingénierie SRE de Meet a reçu les premières alertes indiquant des problèmes de capacité au niveau régional.

Les alertes étaient symptomatiques ou issues de surveillance par boîte noire, et renvoyaient des messages comme "Trop d'échecs de tâches" et "Délestage de charge trop élevé". Les services de Google directement accessibles aux utilisateurs étant développés avec de la redondance, ces alertes ne correspondaient pas à des problèmes en cours visibles par les utilisateurs. Cependant, il est vite devenu clair que l'utilisation du produit en Asie était en forte hausse.

L'équipe d'ingénierie SRE a commencé à travailler avec l'équipe de planification de la capacité afin de trouver des ressources supplémentaires et de gérer cette augmentation, mais il nous a paru évident qu'il fallait voir encore plus loin, dans l'éventualité d'une progression de l'épidémie en dehors de la région.

Et effectivement, l'Italie a entamé un confinement lié au COVID-19 peu de temps après, entraînant une augmentation progressive de l'utilisation de Meet dans ce pays.

Un incident peu conventionnel

C'est à ce moment-là que nous avons commencé à mettre une stratégie en place. Comme à son habitude, l'équipe d'ingénierie SRE a commencé par déclarer un incident et par enclencher notre plan de gestion des incidents pour répondre à ce risque de capacité à l'échelle mondiale.

Il faut cependant noter que, même si nous avons abordé ce défi à l'aide de notre framework éprouvé de gestion des incidents, nous n'étions pas à ce moment-là en plein milieu d'une interruption, ni même sur le point d'en avoir une. Il n'y avait aucun impact immédiat sur les utilisateurs. La plupart des effets du COVID-19 sur la société étaient encore inconnus ou difficiles à prévoir. Notre mission était abstraite : il nous fallait éviter de potentielles interruptions pour un produit qui était devenu essentiel à un grand nombre de nouveaux utilisateurs, tout en faisant évoluer le système sans savoir d'où viendrait la croissance ni à quel moment elle se stabiliserait.

En outre, les membres de notre équipe (et tous les employés Google) étaient en train d'effectuer la transition vers une période indéfinie de télétravail due au COVID-19. Même si la plupart de nos flux de travail et outils étaient déjà disponibles en dehors des bureaux, la gestion virtuelle d'un tel incident de longue durée posait des difficultés supplémentaires.

Sans la possibilité de se retrouver dans la même pièce, il devenait important de gérer nos canaux de communication de manière proactive, pour s'assurer de tous pouvoir accéder aux informations nécessaires à la réalisation de nos objectifs. Bon nombre d'entre nous devaient aussi gérer des défis extérieurs au travail, comme s'occuper de leurs proches pendant cette période d'adaptation. Même si ces facteurs présentaient des obstacles supplémentaires pour gérer l'incident, nous avons su les surmonter grâce à des tactiques comme la désignation de remplaçants supplémentaires, ou encore la gestion proactive des responsabilités et des canaux de communication.

Dans tous les cas, nous nous sommes tenus à notre approche de gestion des incidents. Notre première mesure à l'échelle mondiale a été de désigner plusieurs rôles : un chargé d'incidents, un responsable des communications et un responsable des opérations, à la fois en Amérique du Nord et en Europe, pour assurer une gestion 24h/24.

En tant que chargée d'incidents, ma fonction était semblable à celle d'un routeur d'informations avec état, mais un routeur avec des opinions, de l'influence et la capacité de prendre des décisions. Je récoltais des informations sur les problèmes tactiques en suspens, sur le rôle de chacun, et sur les contextes particuliers susceptibles d'influencer notre plan d'intervention (par exemple, les mesures prises par les gouvernements face au COVID-19). Je déléguais ensuite les différentes tâches aux personnes qualifiées. J'identifiais et examinais les zones d'incertitude, qu'il s'agisse de définir un problème ("Est-ce un souci que nous utilisions 50 % de nos processeurs en Amérique du Sud ?) ou de réfléchir à des solutions ("Comment allons-nous accélérer notre processus de mise en service ?"). Puis je coordonnais notre réponse globale et m'assurais que toutes les tâches à effectuer étaient clairement réparties.

Peu après le lancement du projet, nous nous sommes rendu compte que l'étendue de notre mission était colossale et que notre réponse devrait se faire sur le long terme. Pour que le périmètre de chaque contributeur reste gérable, nous avons divisé notre réponse en plusieurs axes de travail semi-indépendants. Dans les cas où les périmètres se chevauchaient, l'intersection entre les axes de travail était clairement définie.

Cliquez sur l'image pour l'agrandir

Nous avons mis en place les axes de travail suivants, illustrés dans le schéma ci-dessus :

● Capacité, dont la fonction était de trouver des ressources et de déterminer quelles proportions du service nous pouvions activer dans quelles régions

● Dépendances, dont les membres collaboraient avec les équipes gérant l'infrastructure de Meet (par exemple les systèmes d'authentification et d'autorisation des comptes Google), afin de s'assurer que ces systèmes disposaient eux aussi de ressources suffisantes pour s'adapter à la hausse d'utilisation

● Goulots d'étranglement, un axe qui se concentrait sur l'identification et la suppression des éléments de notre système pouvant limiter la mise en échelle

● Manœuvres de contrôle, un axe centré sur la création d'atténuations génériques au sein du système en cas d'interruption de la capacité, qu'elle soit imminente ou en cours

● Modifications en production, dont le but était de générer la capacité supplémentaire de manière sécurisée, de redéployer les serveurs avec des réglages améliorés et d'envoyer les nouvelles versions avec des manœuvres de contrôle additionnelles et prêtes à l'emploi

En tant que gestionnaires des incidents, nous devions continuellement réévaluer la validité de notre structure opérationnelle. Le but était d'avoir assez de structure pour opérer de manière efficace, mais pas plus. Si la structure est insuffisante, les gens prennent des décisions sans avoir eu accès aux bonnes informations, mais si elle est trop lourde, ils passent leur temps à prévoir des réunions.

Nous allions courir un marathon, et non un sprint. Tout au long du parcours, nous avons donc régulièrement vérifié si nos collègues avaient besoin d'aide ou devaient faire une pause. C'était essentiel pour éviter le surmenage et pour tenir dans la durée.

Pour prévenir les risques d'épuisement, chaque personne occupant un rôle au sein de l'équipe de gestion des incidents a désigné un collègue comme "remplaçant". Celui-ci participait aux réunions de son collègue responsable principal, avait accès aux documents pertinents, aux listes de diffusion et aux salons de discussion, et posait les questions nécessaires afin de pouvoir suppléer rapidement au responsable principal le cas échéant. Cette approche s'est révélée utile lorsque certains de nos collègues sont tombés malades ou ont dû faire une pause, car leur remplaçant disposait déjà de toutes les informations nécessaires pour être opérationnel sur-le-champ.

Création de notre marge de capacité

Pendant que l'équipe de gestion des incidents essayait de coordonner au mieux le flux d'informations et le travail nécessaires pour résoudre l'incident, la plupart des personnes qui travaillaient sur le projet s'occupaient des risques directement en production.

Notre principale exigence technique était simplement d'avoir une capacité de service supérieure à la demande des utilisateurs de Meet au niveau régional. Google possédant plus de 20 centres de données à travers le monde, nous pouvions nous appuyer sur une infrastructure solide. Nous avons rapidement tiré parti des ressources brutes dont nous disposions déjà, ce qui suffisait pour presque doubler la capacité de service disponible de Meet.

Précédemment, nous nous étions appuyés sur un historique des tendances pour prévoir la capacité qu'il nous faudrait provisionner. Cependant, nous ne pouvions plus nous fier aux extrapolations des données historiques. Nous devions à présent provisionner de la capacité en fonction de prévisions analytiques. Ces modèles devaient être transposés dans des termes que notre équipe chargée des modifications en production puisse utiliser. Les membres de l'axe "capacité" devaient donc traduire le modèle d'utilisation en quantités de processeurs et de RAM nécessaires. La création de ce modèle de traduction nous a ensuite permis d'accélérer la mise en production de la capacité disponible, car nous avons appris à nos outils et à nos processus d'automatisation à le comprendre.

Bientôt, il est devenu clair que simplement doubler notre empreinte ne serait pas suffisant. Nous avons donc commencé à travailler dans la perspective, autrefois impensable, d'une multiplication de nos services par 50.

Réduire les besoins en ressources

En plus d'effectuer une mise à l’échelle à la hausse de notre capacité, nous avons travaillé sur l'identification et la suppression des aspects inefficaces de notre pile de diffusion. La plupart de ces tâches entraient dans l'une des deux catégories suivantes : l'ajustement d'indicateurs binaires et l'allocation de ressources d'une part, et la réécriture de code pour limiter les dépenses d'autre part.

Pour rendre nos instances de serveurs plus économes en ressources, nous avons dû fournir des efforts sur plusieurs plans. Notre objectif pourrait être résumé ainsi : "traiter un maximum de requêtes avec un minimum de ressources, sans sacrifier l'expérience utilisateur ou la fiabilité du système".

Voici quelques-unes des questions que nous nous sommes posées :

● Pouvions-nous faire tourner moins de serveurs en réservant plus de ressources, pour réduire les calculs supplémentaires ?

● Avions-nous réservé plus de RAM ou de processeurs que nécessaire ? Pouvions-nous faire une meilleure utilisation de ces ressources ailleurs ?

● Avions-nous assez de bande passante de sortie en périphérie du réseau pour proposer des flux vidéo dans toutes les régions ?

● Pouvions-nous réduire la quantité de mémoire et de processeurs nécessaires à une certaine instance de serveur en créant des sous-ensembles de serveurs backend ?Même si nous validons toujours les nouveaux profils et configurations de serveurs avant de les mettre en service, à ce moment-là, il nous paraissait important de les réévaluer. Avec l'utilisation accrue de Meet, les caractéristiques d'utilisation ont elles aussi évolué : la durée des réunions, le nombre de participants et le partage du temps d'audio entre ces participants n'étaient plus les mêmes.

Le service Meet nécessitant plus de ressources brutes que jamais, nous nous sommes peu à peu aperçus qu'au lieu de prioriser la gestion des requêtes, un important pourcentage de nos cycles de processeurs était consacré à des opérations supplémentaires, par exemple à maintenir les équilibreurs de charge et les connexions aux systèmes de surveillance.

Afin de booster le débit, c'est-à-dire le nombre de requêtes traitées par un processeur à la seconde, nous avons augmenté les spécifications des ressources consacrées au traitement, à la fois en termes de processeurs et de RAM réservés. Dans ce genre de situation, on parle parfois de l'exécution de tâches "lourdes".

Dans l'exemple illustré ci-dessus, vous remarquerez deux choses : tout d'abord, les trois spécifications d'instances comportent les mêmes calculs supplémentaires (en rouge), et ensuite, plus le nombre global de serveurs réservés pour une instance est élevé, plus le débit des requêtes est important (en jaune). Avec la même quantité globale de serveurs réservés alloués, une instance de profil "x4" peut traiter 1,8 fois plus de requêtes que quatre instances avec un profil de base. C'est parce que le nombre de calculs supplémentaires (comme les entrées persistantes de journaux de débogage, la vérification du bon fonctionnement des canaux de connexion réseau et l'initialisation des classes) ne progresse pas de façon linéaire par rapport au nombre de requêtes entrantes traitées par la tâche.

Nous avons continué à essayer de doubler les réserves de nos tâches de diffusion tout en divisant par deux le nombre de tâches dans notre parc informatique, jusqu'à atteindre une limite dans le scaling limitation d’échelle.

Et bien sûr, il nous fallait tester et valider chacune de ces modifications. Nous avons utilisé des environnements Canary pour vérifier que ces modifications se comportaient comme souhaité, et n'introduisaient ou n'activaient pas de limites jusqu'alors inconnues. De la même manière que nous validons les nouvelles versions de nos serveurs, nous avons vérifié qu'il n'existait aucune régression fonctionnelle ou de performances, et que les effets désirés des modifications étaient bel et bien atteints en production.

Nous avons également apporté des améliorations fonctionnelles à notre codebase. Par exemple, nous avons réécrit un cache distribué en mémoire pour que sa segmentation des entrées dans les instances de tâches soit plus flexible. Cela nous a ensuite permis de stocker plus d'entrées dans une seule région en augmentant le nombre d'instances de serveurs au sein d'un cluster.

Imaginer des sorties de secours

Même si nous étions de plus en plus confiants quant aux prévisions sur la hausse d'utilisation, celles-ci n'étaient toujours pas fiables à 100 %. Que se passerait-il si nous venions à manquer de capacité de diffusion dans une région en particulier ? Ou si nous poussions un certain lien réseau à saturation ? Le but de l'axe de travail "manœuvres de contrôle" était de fournir des réponses satisfaisantes, à défaut d'être parfaites, à ce genre de question. Il nous fallait un plan acceptable pour les cygnes noirs qui pourraient apparaître dans nos consoles.

Un groupe a commencé à identifier et élaborer des contrôles et des sorties de secours en production. Bien sûr, nous espérions ne pas avoir à y recourir. Par exemple, ces manœuvres nous permettraient de passer rapidement d'une qualité vidéo haute définition (celle définie par défaut) à une définition standard à l'arrivée d'un nouveau participant dans une conférence Meet. Cette modification nous ferait gagner un peu de temps pour rectifier le tir en utilisant les autres axes de travail (améliorations du provisionnement et de l'efficacité), sans trop porter atteinte au produit. Les utilisateurs pourraient toujours repasser en vidéo haute définition s'ils le souhaitaient.

Créer, tester et mettre en place un certain nombre de contrôles instrumentés comme celui-là nous a permis d'avoir une marge supplémentaire au cas où nos pires prévisions se révéleraient inexactes, ce qui nous a tranquillisés.

Viabilité des opérations

Cette stratégie structurée a impliqué un grand nombre de Googleurs occupant des postes variés. Cela signifiait que pour continuer à avancer tout au long de l'incident, nous avions besoin d'une coordination poussée et d'une communication intentionnelle.

Tous les jours, nous organisions des réunions de transfert entre nos deux fuseaux horaires, pour les Googleurs basés à Zurich, Stockholm, Kirkland (Washington) et Sunnyvale (Californie). Nos responsables des communications transmettaient les dernières informations à de nombreux collaborateurs au sein de nos équipes produit, direction, infrastructure et service client, pour qu'ils soient au courant de l'état du projet au moment de prendre leurs propres décisions. Les chefs des axes de travail utilisaient Google Docs pour mettre à jour des documents partagés relatant l'état de l'incident. Ils y précisaient les différents risques actuels, les noms des personnes à contacter, les efforts d'atténuation en cours, et y consignaient leurs notes prises lors des réunions.

Cette approche a bien fonctionné au début, mais elle nous a vite paru fastidieuse. Il nous fallait faire passer la durée du cycle de planification de quelques jours à plusieurs semaines afin de réduire sensiblement les heures consacrées à la coordination, et augmenter le temps passé à véritablement atténuer la crise rencontrée.

Notre première tactique a été de créer des modèles de prévision plus efficaces et plus fiables. Cela a permis d'augmenter la prévisibilité et de stabiliser notre cible d'augmentation de la capacité de diffusion sur une semaine, plutôt qu'au jour le jour.

Nous avons également essayé de réduire le nombre de tâches laborieuses nécessaires pour générer de la capacité de diffusion supplémentaire. Nos processus, tout comme les systèmes que nous exploitions, devaient être automatisés.

À ce moment-là, mettre à l'échelle la pile de diffusion de Meet était l'opération en cours qui demandait le plus de travail, en raison tout d'abord du nombre de personnes qui devaient être informées des dernières prévisions et quantités de ressources, et ensuite du nombre d'outils (pas toujours fiables) nécessaires à certaines opérations.

Comme il est souligné dans le schéma du cycle de vie présenté ci-dessus, le meilleur moyen d'automatiser ces tâches était d'apporter des améliorations étape par étape. Nous avons d'abord rassemblé des informations sur les tâches, puis avons commencé par en automatiser certaines parties jusqu'à ce qu'enfin, dans les conditions idéales, le logiciel arrive à effectuer la tâche du début à la fin sans intervention manuelle.

Pour ce faire, nous avons demandé à un certain nombre d'experts en automatisation, appartenant ou non à l'équipe Meet, de se concentrer sur la résolution de cet espace de problème. Voici certains des éléments de travail :

●Rendre un plus grand nombre de services en production réactifs aux modifications grâce à un fichier de configuration testé et faisant autorité

●Renforcer les outils communs pour les adapter aux configurations système uniques à Meet (par exemple, des besoins élevés en termes de bande passante et de mise en réseau à faible latence)

●Ajuster les vérifications de régression, qui étaient devenues moins fiables à mesure que l'échelle du système augmentait

L'automatisation et la codification de ces tâches ont permis de réduire considérablement les opérations manuelles requises pour mettre Meet en service dans un nouveau cluster ou pour déployer une nouvelle version binaire qui aboutirait à des performances améliorées. Lorsque la fin de cet incident de mise à l’échelle est arrivée, nous avions pu pleinement automatiser notre empreinte de capacité par région et par tâche de diffusion, évitant ainsi des centaines d'appels manuels sur des outils de ligne de commande. Cela a permis de libérer du temps et de l'énergie pour un bon nombre d'ingénieurs, qui ont pu travailler sur des problèmes plus difficiles et tout aussi importants.

À cette étape d’intensification de nos opérations, nous avons pu passer à des transferts "hors connexion" entre les différents sites via e-mail, réduisant encore plus le nombre de réunions auxquelles il nous fallait participer. Maintenant que nous avions une stratégie mieux définie et une marge plus importante, nous pouvions passer à un mode d'exécution plus purement tactique.

Peu après, nous avons graduellement dissous notre structure consacrée à l'incident et avons commencé à travailler à peu près comme nous l'aurions fait pour n'importe quel projet au long cours.

Résultats

À la fin de l'incident, Meet comptait plus de 100 millions de personnes participants à des réunions chaque jour. Arriver à ce résultat n'a été ni simple, ni direct. Les scénarios envisagés par l'équipe Meet pendant les tests de gestion des incidents et des situations d'urgence avant le COVID-19 n'avaient pas pris en compte la durée ou l'échelle de l'augmentation de capacité que nous avons eu à gérer. Nous avons donc défini notre stratégie au fur et à mesure.

Nous avons rencontré plusieurs problèmes en cours de route, car nous devions équilibrer les risques d'une façon que nous n'avions jamais envisagée en temps normal. Par exemple, nous avons déployé du nouveau code sur nos serveurs en production en passant moins de temps que d'habitude en phase Canary, car celui-ci contenait des correctifs de performances qui nous permettaient de gagner du temps et de ne pas manquer de capacité disponible au niveau local.

L'une des compétences les plus cruciales que nous ayons affinées pendant les deux mois qu'a duré ce projet est la capacité à cataloguer, quantifier et vérifier les risques et les bénéfices de manière flexible. Chaque jour, nous recevions de nouvelles informations sur les confinements liés au COVID-19, sur de nouveaux clients qui prévoyaient d'utiliser Meet, et sur la capacité disponible en production. Parfois, ces informations rendaient obsolète le travail que nous avions entamé le jour d'avant.

Chaque minute comptait. Nous ne pouvions pas nous permettre d'attribuer la même priorité ou la même urgence à chaque tâche, mais nous ne pouvions pas non plus ignorer nos propres modèles de prévision. Il était hors de question d'attendre des informations parfaites. Nous devions donc faire de notre mieux pour avoir autant de marge que possible, tout en prenant des décisions avisées, mais rapides à partir des données à notre disposition.

Tout ce travail n'a été possible que grâce à nos collaborateurs intelligents et polyvalents, ayant le sens du collectif, qui venaient d'une dizaine d'équipes et occupaient de multiples postes : ingénieurs en fiabilité des sites, chefs de produit, chefs de projet, ingénieurs réseau et membres du service client. Ils ont travaillé tous ensemble pour mener à bien le projet.

Nous étions maintenant bien placés pour envisager la prochaine étape de notre parcours : la mise à disposition gratuite de Meet pour tous les utilisateurs ayant un compte Google. En temps normal, l'ouverture du produit à tous les consommateurs aurait été un effort d’une mise à l’échelle colossale, mais après l'intense travail que nous avions déjà accompli, nous étions prêts à relever le défi.

DevOps et ingénierie SRE

Ingénierie de plateforme : tirez parti de l’expérience Google

Faire les bons choix en matière d’ingénierie de plateforme

Pour vos besoins de modernisation, oubliez le "Shift Left" ! Visez le "Shift Down" !

Shift Down !

Tout un potentiel à portée de mains

GenOps : s’inspirer du monde des microservices et du DevOps classique

Que mettons-nous en œuvre ? L'agent IA versus le microservice

Plateformes opérationnelles et répartition des responsabilités

Concrétiser le GenOps avec Google Cloud

Débuter une carrière en ingénierie de plateforme : les fondamentaux

Les compétences clés d'un ingénieur de plateforme

La boucle de conception et l'importance de la focalisation client

Que fait réellement un ingénieur plateforme ?

Que doivent absolument éviter les ingénieurs de plateformes ?

Ingénieurs de plateforme : les piliers de la livraison logicielle moderne

5 façons pour les ingénieurs de plateforme d’aider les développeurs à créer des API performantes

1. Traiter les API et les plateformes internes comme des produits

2. Intégrer la gestion des API dans votre plateforme interne

3. Construire des pipelines CI/CD pour vos proxies et vos politiques

4. Simplifier la consommation des API par vos développeurs en leur proposant une « voie royale »

5. Tirer parti d'Apigee pour la gestion et l'automatisation des API

6. Concevoir de meilleures API

Le succès par la culture d’entreprise : pourquoi l'acceptation de l'échec favorise une meilleure livraison logicielle

Comment identifier les leviers pour optimiser l'efficacité des équipes logicielles et des cultures organisationnelles ?

Résilience : positiver l’échec, oui, mais encore…

Démarrer et itérer : le « parfait » est l'ennemi du bien

Sécurité psychologique : valoriser l’échec comme un succès

Comment, en pratique, améliorer votre résilience ?

Au cœur du rapport 2022 sur l’état de l’art des pratiques DevOps : une bonne culture d’équipe

Les valeurs clés d’une bonne culture d’équipe

Catégorie 1 : L'équipe de rêve (The Dream Team)

Catégorie 2 : L'équipe isolée

Catégorie 3 : L'équipe rigide

Conclusion

Stratégies SRE : normalisez le processus de conception des SLOs

2022 State of DevOps Report : fiabilité et SRE

Accélérer l’adoption de DevOps

La fiabilité est fondamentale

La fiabilité est un cheminement

La fiabilité repose sur l’humain

Vos SLOs sont-ils réalistes ? Ou comment analyser vos risques comme un SRE

Les bases de l'analyse des risques

Quels sont les risques à prendre en compte ?

Bonnes pratiques de Brainstorming…

Création du catalogue de risques

Analyse des risques

Un processus d'analyse des risques à haut niveau

Acceptation des risques

L’ouvrage sur le SRE fête ses 6 ans !

L’ouvrage sur le SRE fête ses 6 ans !

Boostez vos pratiques DevOps ? Une étude conseille d’essayer SRE !

Boostez vos pratiques DevOps ? Une étude conseille d’essayer SRE !

La recette de Google pour atteindre la fiabilité : SRE

SRE, un levier puissant pour gagner en excellence sur la livraison logicielle

Sur la route SRE, vers l’excellence DevOps

Rapport DevOps 2021 : burnout et performance des équipes

Les indicateurs de performance de la production logicielle

Le cinquième indicateur : de la disponibilité à la fiabilité

Perspectives 2021 : impacts de la fiabilité, du COVID et des chaînes d'approvisionnement applicatives sécurisées

Lancement des DevOps Awards

Quatre étapes pour bien démarrer votre initiative SRE

Étape 1 : Démarrer petit et itérer

Étape 2 : Encourager votre équipe

Étape 3: Propager ces enseignements

Étape 4 : Développer une culture de la donnée

Plus loin avec le fast track SRE

Google Cloud Next (du 12 au 14 octobre) : Ouverture des inscriptions

Apprenez à développer des applications sans code pour vous simplifier la tâche

Le machine learning : guide du débutant

Trois mois, 30 fois plus de demande : comment nous avons fait évoluer Google Meet dans le contexte du COVID-19

Les premières alertes

Un incident peu conventionnel

Création de notre marge de capacité

Réduire les besoins en ressources

Imaginer des sorties de secours

Viabilité des opérations

Résultats