Un coup d'œil sous la couverture de Datto SaaS Protection + (en anglais)

Nous savons tous que la migration vers les infrastructures cloud et les services hébergés dans le cloud connaît une croissance rapide depuis longtemps déjà, et que la pandémie n’a fait qu’accélérer cette tendance. Le service « SaaS Protection » de Datto protège les offres SaaS telles que Microsoft 365 et Google Workspace (anciennement G Suite). Souvent, une croissance rapide s’accompagne de changements importants et, parfois, d’une certaine instabilité. Même pour des entreprises comme Microsoft et Google, qui opèrent à très grande échelle, cette croissance accélérée peut poser des problèmes.

Datto est spécialisé dans la protection des données, ce qui signifie que la qualité, la fiabilité et la résilience sont au premier plan de nos priorités en matière d'ingénierie. L'année écoulée nous a tous mis à l'épreuve dans ces domaines clés. Nous sommes une organisation agile qui s'adapte continuellement et apporte des améliorations progressives. Dans ce billet de blog, je mettrai en évidence certains des défis récents que nous avons rencontrés, les mesures que nous avons prises et nos plans pour l'avenir afin de fournir le meilleur service de protection des charges de travail SaaS.

Bien que nous soutenions à la fois Microsoft 365 et Google Workspace, je vais me concentrer sur M365 spécifiquement parce qu'il représente une majorité croissante de notre base de clients. Toutefois, bon nombre de ces sujets s'appliquent également à Google Workspace.

API Microsoft

Les API Microsoft sont en pleine transition : elles passent des anciennes API spécifiques à chaque service (par exemple, Exchange Online, SharePoint, OneDrive) à l’API Graph. Nous avons rapidement migré vers Graph et tous nos nouveaux développements sont désormais réalisés via Graph. C’est le cas depuis un certain temps déjà. Nous connaissons toutes les dates de fin de vie des API spécifiques à chaque service et nous prenons largement les devants sur chacune d’entre elles. Nous accélérons la transition au fur et à mesure des besoins, car certaines API héritées spécifiques à des services ont des dates de fin de vie (EOL) fixes. Je voudrais mettre en avant deux cas particuliers concernant les API :

• Les API modifient les résultats qu’elles renvoient : nous constatons que le comportement des API Microsoft évolue assez régulièrement. La signature des API ne change pas, conformément à la politique standard destinée aux développeurs. Cependant, les résultats renvoyés par les appels d’API peuvent changer (et changent effectivement) sans préavis. Par exemple, il peut arriver que nous recevions régulièrement une chaîne de caractères spécifique qui varie, ou que nous obtenions des codes d’erreur différents pour des appels parfaitement identiques. J’ai vu nos concurrents faire publiquement référence à ce type de changements. Pour reprendre une expression courante ces derniers temps, « nous sommes tous dans le même bateau ». Les API que nous utilisons sont les mêmes que celles utilisées par nos concurrents (à une exception près, décrite au point suivant). Cela signifie que si nous rencontrons des erreurs ou des exceptions dues à un problème chez Microsoft, il y a de fortes chances que d’autres solutions en subissent de même.
• L'utilisation d'une API bêta comporte des risques : Microsoft met certaines fonctionnalités à disposition via des API bêta afin de recueillir les retours d'expérience en temps réel de ses partenaires et clients les plus proches. En tant que partenaire stratégique de Microsoft, Datto exploite régulièrement ces API bêta pour concevoir et développer de nouvelles fonctionnalités destinées à nos partenaires et à nos clients finaux le plus rapidement possible. À titre d'exemple, nous sommes fiers d'avoir été les premiers à proposer, l'année dernière, la prise en charge native de la sauvegarde Microsoft Teams. Cependant, nous ne sacrifierons pas la stabilité et la fiabilité au profit de la rapidité. Les API bêta de Microsoft, comme c’est le cas pour tous les codes et fonctionnalités en préversion, comportent un risque inhérent. Contrairement à ce que j’ai indiqué plus haut, les API bêta peuvent enfreindre les règles standard (par exemple, un changement de signature) ou très probablement disparaître complètement sans préavis, voire sans aucun préavis. Nous n’utilisons tout simplement pas les API bêta en production en raison de ce risque. Méfiez-vous de tout fournisseur qui n’adopterait pas une pratique similaire, car cela constituerait un risque inhérent à la capacité de protéger et de restaurer vos données.

À l’instar de nombreux fournisseurs de services cloud, Microsoft met en œuvre une limitation du débit des appels API afin de garantir une qualité de service élevée. Pendant les périodes de forte affluence, Microsoft accorde la priorité à certains appels API par rapport à d’autres. Par exemple, une requête utilisateur (comme la récupération d’un message via un client final) sera priorisée par rapport à une requête provenant d’une application tierce, telle que celle de Datto SaaS Protection. Lorsque nos appels API sont limités, nous recevons un code d’erreur spécifique, généralement « 429 Too Many Requests ». L’un de nos avantages, en tant que développeur et opérateur du service, par opposition à un éditeur de logiciels indépendant (ISV) qui concède une licence d’utilisation de son logiciel à un fournisseur tiers, est que nous avons accès à une montagne de données télémétriques. Nous avons réalisé d’importants investissements dans l’analyse de ces données dans le but explicite d’améliorer les performances et la fiabilité de notre service. Un exemple concret en est une modification que nous avons apportée en début d’année afin de planifier stratégiquement les sauvegardes aux moments de la journée où nous constatons le moins d’erreurs de limitation. Cela a permis d’augmenter de manière mesurable notre taux global de réussite des sauvegardes.

Événements Microsoft

De nombreux services en nuage qui connaissent une hypercroissance similaire à celle de M365, en particulier au cours des 18 derniers mois, doivent procéder à des changements pour suivre le rythme de la demande. Cela implique non seulement l'ajout de nouvelles fonctionnalités, mais aussi l'ajout d'une infrastructure pour répondre à la demande. Deux événements survenus l'année dernière ont eu un impact significatif sur notre service.

Le premier incident de ce type s’est produit le 15 mars, lors d’une panne mondiale du système d’authentification. Cet incident, qui a fait grand bruit, a touché aussi bien les utilisateurs finaux que les fournisseurs de services. De notre côté, il a entraîné un afflux massif de demandes d’assistance concernant Datto SaaS Protection, qui a plus que doublé le volume d’assistance prévu pour le mois de mars. Le traitement de toutes ces demandes a pris du temps et a généré un retard important. Depuis, nous avons apporté des modifications à nos processus et à nos effectifs afin d’être en mesure de gérer un tel incident, s’il venait à se reproduire à l’avenir.

Pratiquement au moment même où le problème d’authentification s’est produit, nous avons également constaté des erreurs sur l’une de nos liaisons de peering dans la région des États-Unis. Microsoft propose un service de peering qui garantit une latence réduite et une fiabilité accrue pour le trafic à destination et en provenance des services Microsoft tels que M365 et Azure. Nous investissons dans ces liaisons lorsque nous atteignons un certain niveau d’échelle dans une région donnée. L’utilisation de liaisons de peering est mutuellement bénéfique pour Datto et nos partenaires. Dans la région des États-Unis, nous disposons de plusieurs liaisons de peering vers nos centres de données, dont une seule présentait des erreurs, ce qui a compliqué le diagnostic précis du problème. La principale difficulté pour identifier la cause première des erreurs sur la liaison de peering résidait dans le fait que nous recevions simplement des erreurs d’API Microsoft qui ressemblaient en tous points à celles que nous avions reçues lors de la panne d’authentification. En raison de la coïncidence temporelle, ces problèmes se sont combinés pour créer une véritable tempête et ont entraîné une forte augmentation du nombre de tickets d’assistance.

Le dernier événement notable de Microsoft s’est déroulé sur plusieurs jours consécutifs en mai. Nos systèmes de surveillance et d’alerte ont rapidement détecté un problème, car nos indicateurs clés de performance (KPI) ont commencé à chuter brutalement. Après enquête, nous avons identifié la cause première : un échec de la négociation TLS. Microsoft procédait en effet à des mises à jour progressives des versions TLS et des algorithmes de chiffrement qu’il acceptait. Nous utilisions déjà le protocole TLS v1.2. Cependant, Microsoft avait sélectionné manuellement un ensemble spécifique d’algorithmes de chiffrement au sein de la version TLS v1.2 qu’il était le seul à accepter. Ce changement n’ayant pas été correctement communiqué, nous avons ouvert un ticket de panne en production auprès de Microsoft. Je ne peux que supposer que d’autres fournisseurs ont fait de même, car très peu de temps après, Microsoft a suspendu les mises à jour progressives et est revenu sur ses modifications (ce qui est en effet très rare). Malheureusement, Microsoft a recommencé à déployer ces mises à jour à peine 24 heures plus tard. Nous étions en train de tester les modifications apportées aux algorithmes de chiffrement, mais nous avons dû rapidement nous réorienter pour déployer les modifications TLS sur notre parc. Cela nous a donné l’occasion de collaborer avec Microsoft afin de mettre en place un dispositif de communication approprié pour nous avertir correctement de ces changements à l’avenir. Croyez-le ou non, même nos interlocuteurs du support premium n’étaient pas au courant de cette opération de maintenance.

Notre partenariat avec Microsoft

Compte tenu de l'importance de Microsoft pour nous et nos clients, nous investissons de manière significative dans cette relation. Il y a quelques points à souligner en particulier :

• Depuis deux ans, nous disposons d'un contrat d'assistance aux développeurs premium de Microsoft. Cela nous permet d'avoir un responsable de support dédié qui nous aide à escalader nos tickets de support et nous donne également accès à des ressources techniques supplémentaires.
• En plus du contrat de support développeur premium, nous achetons des blocs d'heures de conseil développeur en fonction des besoins. Nous avons utilisé ces blocs de différentes manières :
  • Lorsque nous créons une nouvelle fonctionnalité, nous pouvons faire appel à un expert dans un domaine donné qui peut revoir notre conception et notre logique pour s'assurer que nous utilisons les bonnes API et que nous interprétons les données de la bonne manière. C'est un moyen pratique de faire appel à un expert de Microsoft pour nous aider dans la conception et la révision de notre solution.
  • Pour les cas de support spécifiques qui, selon nous, ne reçoivent pas l'attention nécessaire, nous pouvons utiliser ces heures de conseil pour obtenir l'affectation d'une ressource dédiée. D'une certaine manière, nous payons pour obtenir une attention plus rapide à certains de nos problèmes Microsoft les plus importants. Parfois, Microsoft doit modifier le code, ce qui peut prendre beaucoup de temps. D'autres fois, ils peuvent suggérer une solution de contournement ou une solution alternative pour éviter complètement le problème.
• Enfin, du point de vue du support Microsoft, nous ajoutons une option à notre support premium qui permettra à nos partenaires et clients de travailler conjointement avec nous sur un ticket Microsoft. Cela permettra non seulement d'assurer la transparence du statut, mais aussi de raccourcir le temps de cycle de certains tickets. Nous sommes souvent la personne au milieu (c'est-à-dire que Microsoft nous demande de demander quelque chose au partenaire ou au client final et vice versa). Nous pensons que cela fera une grande différence dans des situations spécifiques et qu'il s'agit d'une valeur ajoutée supplémentaire que nous pouvons apporter.
• Avec le programme « Datto Backup for Microsoft Azure », désormais disponible en accès anticipé, nous ne sommes pas seulement un partenaire de Microsoft, mais aussi un client émergent de premier plan. Nous avons tous à cœur de faire de cette collaboration un véritable succès. C'est véritablement une situation gagnant-gagnant-gagnant (pour Datto, Microsoft et nos partenaires).

Nous n'avons fait qu'effleurer la surface des histoires et des défis techniques que nous avons rencontrés. Revenez consulter les prochains blogs consacrés à différents aspects de la SaaS Protection + de Datto.