Partager via


Comment Microsoft exploite des systèmes fiables avec DevOps

Microsoft exploite des plateformes en ligne complexes depuis les premiers jours de l’Internet commercial. En chemin, nous avons développé un ensemble important de pratiques pour assurer la disponibilité, la santé et la sécurité des systèmes. Ces pratiques font partie d’une initiative plus vaste visant à maintenir et à améliorer une culture de site en direct.

Culture du site en direct

La culture de site en direct est le focus d’une organisation pour hiérarchiser l’expérience et la fiabilité du site en direct sur tout le reste. Après tout, les clients peuvent se déplacer assez facilement entre les fournisseurs de services aujourd’hui avec les services cloud et Internet, en amplifiant considérablement l’importance de la confiance des clients. Le site en direct doit toujours être disponible et effectuer comme promis aux clients.

Il existe différents facteurs qui contribuent à une culture de site dynamique réussie.

Diagramme de la culture de site en direct de Microsoft.

Site en direct en premier

La mise en œuvre de l’expérience de site en direct est essentielle à une plateforme réussie. Teams ne peut pas mettre l’accent sur les nouvelles fonctionnalités brillantes et ignorer l’avenue dans laquelle ces fonctionnalités sont présentées aux utilisateurs. Nous nous appuyons sur des pratiques de déploiement sécurisées qui permettent de s’assurer que nos clients bénéficient d’un accès ininterrompu à la plateforme. Cela peut se compliquer particulièrement lorsqu’il s’agit de publier des mises à jour de service avec version avec aucun temps d’arrêt.

Contrôler l’exposition par le biais d’indicateurs de fonctionnalité

À mesure que nous déployons à travers nos niveaux et étapes, en contrôlant l’exposition avec des indicateurs de fonctionnalité, nous découvrons parfois un problème en production. Malgré toutes nos automatisations et révisions, les choses se produisent parfois. Comme ils disent, il n’y a pas d’endroit comme la production !

En règle générale, la surveillance de l’intégrité et la télémétrie nous alertent quand quelque chose n’est pas correct. Un développeur peut créer une branche, maineffectuer un correctif et le demander main. Conserver le même flux de travail général signifie que les développeurs n’ont pas besoin de changer de contexte ou d’apprendre un processus différent pour une modification de code différente.

Pour résoudre un déploiement de correctif logiciel, une étape supplémentaire est nécessaire, qui consiste à sélectionner la modification dans la branche de mise en production. Nous exécutons un déploiement de correctif logiciel hors de la branche de mise en production actuelle chaque jour de la semaine, bien que nous puissions également le faire à la demande pour des correctifs urgents. Le correctif atteint réellement la production hors de la branche de mise en production en premier. Mais parce que nous développons en main premier, nous savons qu’il ne régresse pas le sprint suivant lorsqu’une nouvelle branche de mise en production est créée à partir de main.

Les versions de produits locaux sont largement identiques, mais sans les niveaux de déploiement et les étapes. En outre, étant donné que nous effectuons des tests manuels sur différentes configurations et formes de données, il existe une queue plus longue entre couper la branche de mise en production et mettre le produit entre les mains des clients.

La sécurité doit être prise personnellement

Le focus est de rendre les vulnérabilités réelles et personnelles. Cela garantit que les gens s’occupent vraiment. Nous utilisons également largement les jeux de guerre pour trouver et résoudre les risques de sécurité dans tout le système, que ce soit dans le code ou non. Lorsque l’équipe rouge peut montrer qu’elle est entrée dans le code en tournant une boîte de dialogue à l’envers, elle motive vraiment le propriétaire du code à résoudre le problème et s’assurer qu’il ne se produit plus ailleurs. Ce genre de concurrence est beaucoup plus réel et personnel qu’un avertissement d’analyse statique sur un risque XSS potentiel. Nous créons ce genre de culture et dynamique par le biais de jeux de guerre et d’autres exercices de sécurité. Les gens sont fiers du piratage dans le code de l’autre ou d’être en mesure de bloquer les tentatives. Cela inculque une culture de code sécurisée.

Nous ne pouvons pas planifier chaque vecteur d’attaque, mais ce que nous pouvons faire est de supposer qu’il y aura une violation, et planifier la vitesse à laquelle nous pouvons réagir à cette violation. Beaucoup de travail de sécurité a été autour de cela pour nos équipes.

Enfin, les humains font des erreurs. Ils sont parfois différés et font des choses comme stocker des mots de passe sur des partages de fichiers. Nous pouvons leur dire de ne pas et nous pouvons les envoyer à la formation de sécurité et nous pouvons faire toutes sortes d’autres choses. La plupart des gens apprennent, mais il ne faut qu’une seule personne pour briser le système. Vous pouvez avoir toutes sortes de listes de bonnes pratiques, mais sauf si vous faites cela réel, vous devez supposer que les gens vont faire des erreurs. Cela nécessite un certain niveau de supervision pour s’assurer que les processus critiques sont suivis.

L’ingénierie est plus qu’un partenaire d’opérations

Nous avons appris dès le début à faire du site en direct une partie importante des responsabilités de l’équipe d’ingénierie. C’était énorme pour nous parce que, dans le passé, une personne pouvait aller déployer quelque chose, partir pour le week-end, et retourner lundi pour trouver 900 problèmes clients que les équipes de support client et d’ops ont affaire avec tout le week-end. Il est important que l’ingénierie paye le prix des problèmes de site en direct. Sinon, il n’y a pas d’incitation à créer des systèmes qui évitent ces problèmes. Quand vous êtes appelé à 2 H.M. pour corriger quelque chose que vous avez cassé, vous vous souvenez.

À mesure que nous avons évolué cette responsabilité, le site Live est la chose la plus importante que nous faisons est devenue le mantra de toute l’équipe. C’est l’expérience client qu’ils ont pour le moment et ce n’est pas seulement une taxe. C’est en fait quelque chose que les gens comptent de nous et nous sommes fiers de lui. Il doit s’agir d’une fonctionnalité de différenciation de notre produit.

La télémétrie de production est la pulsation de votre service

Afin de survivre dans le monde rapide où pratiquement tout peut aller mal, nous avons besoin de grands systèmes d’alerte. Les alertes non exploitables, les alertes redondantes ou les volumes d’alertes écrasants vous permettent d’ignorer toutes les alertes. Il est facile de créer trop d’alertes, donc le processus se distille vraiment à une question simple : Cette alerte peut-elle être actionnable ? Cela garantit que nous nous engageons sur les bons problèmes clients et que nous les gérons aussi rapidement que possible.

Comme l’équipe d’ingénierie s’est mise à zéro sur les alertes actionnables, ils ont remarqué qu’un grand nombre de problèmes qui se sont produits, surtout au milieu de la nuit, ont tendance à avoir des correctifs similaires, au moins temporairement. Cela a entraîné une concentration sur les systèmes qui étaient mieux à basculer et à guérir soi-même. Maintenant, les problèmes se produisent, déclenchent des alertes, puis se corrigent suffisamment pour que l’équipe d’ingénierie attende jusqu’au matin pour résoudre. Cela n’aurait pas eu lieu si l’équipe d’ingénierie vient de pousser des bits qui ont gardé d’autres personnes debout la nuit. Maintenant, ils travaillent pour équilibrer ces améliorations dans le cadre non seulement de la vitesse de fonctionnalité, mais aussi de la vitesse d’amélioration de l’ingénierie.

Résumé

L’adoption d’une culture de site en direct a impacté la façon dont Microsoft crée et fournit des logiciels. En rendant les équipes d’ingénierie un élément clé de la sécurité et des opérations, la qualité de notre code et de notre expérience utilisateur final s’est considérablement améliorée. Étant un participant complet aux opérations, l’ingénierie est une partie prenante clé, ce qui entraîne des systèmes conçus pour de meilleures opérations.