Comment Microsoft exploite des systèmes fiables avec DevOps

Microsoft opère des plates-formes en ligne complexes depuis les premiers jours d’Internet commercial. En chemin, nous avons développé un ensemble important de pratiques pour maintenir les systèmes disponibles, en bonne santé et sécurisés. Ces pratiques font partie d’une initiative plus vaste visant à maintenir et à améliorer une culture de site live.

Culture de « site live»

Pour une organisation, la culture de « site live» consiste à donner la priorité à l’expérience et à la fiabilité du site live par rapport à tout le reste. Après tout, de nos jours, les clients peuvent facilement changer de fournisseurs de services avec le cloud et les services Internet, ce qui amplifie considérablement l’importance de la confiance des clients. Le site live doit toujours être disponible et fonctionner comme promis pour les clients.

Différents facteurs contribuent à une culture de site live réussie.

Faire passer le site live en premier

Donner la priorité à l’expérience du site live est essentiel pour une plate-forme réussie. Les équipes ne peuvent pas se concentrer uniquement sur la conception de nouvelles fonctionnalités attrayantes et négliger la manière dont ces fonctionnalités sont présentées aux utilisateurs. Nous nous appuyons sur des pratiques de déploiement sécurisé qui aident à garantir que nos clients bénéficient d’un accès ininterrompu à la plate-forme. Cela peut devenir particulièrement compliqué lorsqu’il s’agit de publier des mises à jour de service versionnées sans interruption.

Contrôle de l’exposition grâce aux indicateurs de fonctionnalité

Lorsque nous déployons nos mises à jour par anneaux et étapes, tout en contrôlant l’exposition grâce aux indicateurs de fonctionnalité, il nous arrive parfois de découvrir un problème en production. Malgré toute notre automatisation et nos vérifications, nous sommes malgré tout parfois confrontés à des imprévus. Comme on dit, rien ne vaut la production !

En général, la veille sanitaire et la télémétrie nous alertent lorsque quelque chose ne va pas. Un développeur peut créer une branche à partir de main, élaborer un correctif et faire un pull request dans main. En suivant le même processus global, les développeurs n’ont pas besoin de changer de contexte ou d’apprendre un processus différent pour chaque modification de code.

Pour effectuer un déploiement de correctif, une étape supplémentaire est nécessaire, à savoir la sélection de la modification dans la branche de publication. Nous effectuons un déploiement de correctif à partir de la branche de publication actuelle chaque matin en semaine, bien que nous puissions également le faire sur demande pour les corrections urgentes. Le correctif atteint en fait la production à partir de la branche de publication en premier. Mais parce que nous développons d’abord dans main, nous savons qu’elle ne se répercutera sur le prochain sprint lorsque nous créerons une nouvelle branche de publication à partir de main.

Les versions des produits sur site sont en grande partie identiques, bien qu’il n’y ait pas de déploiement par anneaux et étapes. De plus, parce que nous effectuons plus de tests manuels sur différentes configurations et formes de données, il y a un laps de temps plus long entre la création de la branche de publication et la mise du produit entre les mains des clients.

Faire de la sécurité un affaire personnelle

L’objectif est de rendre les vulnérabilités réelles et personnelles. Cela garantit que les gens y attachent une réelle importance. Nous avons également un recours intensif aux jeux de guerre pour repérer et traiter les risques de sécurité dans tout le système, qu’ils soient liés au code ou non. Lorsque l’équipe rouge peut montrer qu’elle a réussi à accéder au code en retournant une boîte de dialogue, cela motive vraiment le propriétaire du code à résoudre le problème et à s’assurer qu’il ne se reproduit nulle part ailleurs. Ce genre de concurrence est beaucoup plus réel et personnel qu’un avertissement d’analyse statique concernant un risque potentiel d’injection de code. Nous créons ce type de culture et de dynamique grâce aux jeux de guerre et à d’autres exercices de sécurité. Les gens sont fiers de pirater le code les uns des autres ou de réussir à bloquer les tentatives. Cela instaure une culture de code sécurisé.

Nous ne pouvons pas prédire chaque vecteur d’attaque, mais nous pouvons cependant assumer la possible existence de failles et prévoir notre vitesse de réaction à une violation pour chacune de ces failles. C’est en cela qu’a consisté une grande partie du travail en matière de sécurité pour nos équipes.

Enfin, l’erreur est humaine. Il arrive que des personnes finissent par baisser leur garde et se retrouvent par exemple à stocker des mots de passe sur des partages de fichiers. Il existe diverses mesures pour éviter de tels comportements comme leur rappeler de ne pas le faire, les envoyer en formation de sécurité, etc. La plupart des gens tire les leçons de leurs expériences, mais une seule personne suffit pour casser le système. Toutes les listes de bonnes pratiques n’éradiqueront pas les erreurs humaines à moins de les rendre concrètes. Cela nécessite un certain niveau de supervision pour s’assurer que les processus critiques sont suivis.

L’ingénierie, bien plus qu’un partenaire opérationnel

Nous avons appris dès le début à faire du site live une partie importante des responsabilités de l’équipe d’ingénierie. Cela a été majeur pour nous, car par le passé, quelqu’un pouvait déployer quelque chose avant de partir en week-end et revenir le lundi matin pour découvrir que l’équipe de support client et les équipes d’exploitation avaient passé tout leur week-end à traiter 900 problèmes clients. Il est important que l’ingénierie fasse les frais des problèmes de site live. Sans cela, il n’y a rien pour motiver la création de systèmes qui évitent ces problèmes. Lorsqu’on vous appelle à 2 heures du matin pour réparer quelque chose que vous avez cassé, ça ne s’oublie pas.

À mesure de notre évolution, cette responsabilité est devenue le mantra de nos équipes : Le site live est notre activité la plus importante. C’est l’expérience client que nous offrons aujourd’hui et ce ne sont pas que des mots. C’est en réalité quelque chose sur lequel les gens comptent de notre part et dont nous sommes fiers. Cela doit être une caractéristique qui différencie notre produit.

La télémétrie de production est le pouls de votre service.

Pour survivre dans une monde tellement rapide où pratiquement tout peut mal tourner, il nous faut des systèmes d’alerte performants. Des alertes non actionnables, des alertes redondantes ou un volume d’alertes trop important ont souvent pour résultat que toutes les alertes sont ignorées. Il est facile de créer beaucoup trop d’alertes, de sorte que le processus se résume vraiment à une question très simple : cette alerte est-elle actionnable ? Cela garantit que nous nous engageons sur les bons problèmes clients et que nous les traitons aussi rapidement que possible.

Alors que l’équipe d’ingénierie se concentrait sur les alertes actionnables, elle a remarqué que de nombreux problèmes qui surviennent, surtout au milieu de la nuit, ont tendance à avoir des correctifs similaires, du moins temporairement. Cela a conduit à se concentrer sur des systèmes plus performants en matière de basculement et d’auto-guérison. À présent, les problèmes surviennent, déclenchent des alertes, puis se réparent suffisamment bien pour que l’équipe d’ingénierie puisse attendre jusqu’au matin pour les résoudre. Cela n’aurait pas été possible si l’équipe d’ingénierie avait simplement déployé des éléments susceptibles de réveiller tout le monde en pleine nuit. Ils travaillent désormais à équilibrer ces améliorations dans le cadre de la vélocité de l’amélioration de l’ingénierie, et non seulement de la vélocité de la fonctionnalité.

Résumé

L’adoption d’une culture de site live a eu un impact sur la manière dont Microsoft construit et déploie des logiciels. En intégrant les équipes d’ingénierie dans la sécurité et les opérations, la qualité de notre code et de l’expérience utilisateur finale s’est considérablement améliorée. Faire participer pleinement les opérations a fait de l’ingénierie un acteur clé, ce qui a permis de concevoir des systèmes conçus pour de meilleures opérations.