Ein Blick unter die Haube von Datto SaaS Protection

Wir alle wissen, dass die Umstellung auf Cloud-Infrastrukturen und Cloud-basierte Dienste schon seit Langem rasant zunimmt – und die Pandemie hat dieses Wachstum nur noch weiter beschleunigt. Der „SaaS Protection“-Dienst von Datto schützt SaaS-Angebote wie Microsoft 365 und Google Workspace (ehemals G Suite). Mit rasantem Wachstum gehen oft erhebliche Veränderungen und gelegentlich auch Instabilität einher. Selbst für Unternehmen wie Microsoft und Google, die im Hyper-Scale-Bereich agieren, kann dieses beschleunigte Wachstum Probleme mit sich bringen.

Datto hat sich auf die Datensicherung spezialisiert, was bedeutet, dass Qualität, Zuverlässigkeit und Ausfallsicherheit zu den obersten Prioritäten unserer Technik gehören. Das vergangene Jahr hat uns alle in diesen Schlüsselbereichen auf die Probe gestellt. Wir sind ein agiles Unternehmen, das sich ständig anpasst und schrittweise Verbesserungen vornimmt. In diesem Blogbeitrag werde ich einige der jüngsten Herausforderungen, die wir erlebt haben, die Maßnahmen, die wir ergriffen haben, und unsere Pläne für die Zukunft vorstellen, um einen erstklassigen Service zum Schutz von SaaS-Workloads zu bieten.

Obwohl wir sowohl Microsoft 365 als auch Google Workspace unterstützen, werde ich mich speziell auf M365 konzentrieren, da dies eine zunehmende Mehrheit unserer Kundenbasis darstellt. Allerdings gelten viele dieser Themen auch für Google Workspace.

Microsoft-APIs

Die Microsoft-APIs durchlaufen derzeit einen Übergang von dienstspezifischen (z. B. Exchange Online, SharePoint, OneDrive) Legacy-APIs zur Graph-API. Wir haben die Umstellung auf die Graph-API zügig vorangetrieben, und alle unsere neuen Entwicklungen erfolgen mittlerweile über die Graph-API. Das ist bereits seit einiger Zeit der Fall. Wir kennen alle Termine für die Einstellung dienstspezifischer APIs und sind jedem einzelnen davon deutlich voraus. Wir beschleunigen die Umstellung nach Bedarf, da einige dienstspezifische Legacy-APIs feste End-of-Life-Termine (EOL) haben. Es gibt zwei API-Szenarien, auf die ich besonders hinweisen möchte:

• APIs ändern ihre Rückgabewerte: Wir stellen fest, dass sich das Verhalten der Microsoft-APIs relativ regelmäßig ändert. Die Signatur der APIs ändert sich nicht, da dies einer Standardrichtlinie für Entwickler entspricht. Die von den API-Aufrufen zurückgegebenen Ergebnisse können sich jedoch ohne Vorankündigung ändern (und tun dies auch). Beispielsweise erhalten wir möglicherweise regelmäßig einen bestimmten String-Wert, der sich ändert, oder wir erhalten unterschiedliche Fehlercodes bei genau denselben Aufrufen. Ich habe gesehen, dass unsere Mitbewerber öffentlich auf solche Änderungen hinweisen. Um einen derzeit gängigen Ausdruck zu verwenden: Wir sitzen alle im selben Boot. Die von uns genutzten APIs sind dieselben, die auch unsere Mitbewerber nutzen (mit einer Ausnahme, die im nächsten Punkt beschrieben wird). Das bedeutet: Wenn bei uns aufgrund eines Problems bei Microsoft Fehler oder Ausnahmen auftreten, ist die Wahrscheinlichkeit hoch, dass dies auch bei anderen Lösungen der Fall ist.
• Die Nutzung einer Beta-API birgt Risiken: Microsoft stellt bestimmte Funktionen über Beta-APIs zur Verfügung, um Echtzeit-Feedback von seinen engsten Partnern und Kunden zu erhalten. Als strategischer Partner von Microsoft nutzt Datto regelmäßig Beta-APIs, um neue Funktionen für unsere Partner und Endkunden so schnell wie möglich zu entwickeln und zu implementieren. So waren wir beispielsweise stolz darauf, im vergangenen Jahr als Erste die Unterstützung für native Microsoft Teams-Backups auf den Markt zu bringen. Wir werden jedoch Stabilität und Zuverlässigkeit nicht zugunsten der Geschwindigkeit opfern. Die Beta-APIs von Microsoft bergen, wie alle Vorabversionen von Code und Funktionen, ein inhärentes Risiko. Im Gegensatz zu dem, was ich oben gesagt habe, können Beta-APIs gegen Standardrichtlinien verstoßen (z. B. durch eine Änderung der Signatur) oder durchaus ohne große Vorankündigung oder gar ohne Vorankündigung vollständig wegfallen. Aufgrund dieses Risikos setzen wir Beta-APIs in der Produktion schlichtweg nicht ein. Seien Sie vorsichtig bei Anbietern, die möglicherweise keine ähnliche Vorgehensweise verfolgen, da dies ein inhärentes Risiko für die Sicherheit und Wiederherstellbarkeit Ihrer Daten darstellen würde.

Wie viele Cloud-Dienstleister wendet auch Microsoft eine Drosselung bei API-Aufrufen an, um eine hohe Dienstqualität zu gewährleisten. In Spitzenzeiten räumt Microsoft bestimmten API-Aufrufen Vorrang vor anderen ein. So wird beispielsweise eine Benutzeranfrage (z. B. das Abrufen einer Nachricht über einen Endbenutzer-Client) gegenüber einer Anfrage einer Drittanbieteranwendung, wie beispielsweise von Datto SaaS Protection, priorisiert. Wenn unsere API-Aufrufe gedrosselt werden, erhalten wir einen bestimmten Fehlercode, in der Regel „429 Too Many Requests“. Ein Vorteil, den wir als Entwickler und Betreiber des Dienstes im Gegensatz zu einem unabhängigen Softwareanbieter (ISV) haben, der seine Software an einen Drittanbieter lizenziert, ist, dass wir Zugriff auf eine riesige Menge an Telemetriedaten haben. Wir haben erhebliche Investitionen in die Analyse dieser Daten getätigt, mit dem ausdrücklichen Ziel, unseren Dienst leistungsfähiger und zuverlässiger zu machen. Ein konkretes Beispiel hierfür ist eine Änderung, die wir Anfang dieses Jahres vorgenommen haben, um Backups strategisch zu Tageszeiten einzuplanen, zu denen wir die geringste Anzahl an Drosselungsfehlern feststellen. Dies hat unsere Gesamterfolgsquote bei Backups messbar erhöht.

Microsoft-Veranstaltungen

Viele Cloud-Dienste, die ein ähnliches Hyperwachstum wie M365 erleben, insbesondere in den letzten 18 Monaten, müssen Änderungen vornehmen, um mit der Nachfrage Schritt zu halten. Dazu gehört nicht nur das Hinzufügen neuer Funktionen, sondern auch die Erweiterung der Infrastruktur, um die Nachfrage zu unterstützen. Im vergangenen Jahr gab es zwei Ereignisse, die sich erheblich auf unseren Dienst ausgewirkt haben.

Der erste Vorfall dieser Art ereignete sich am 15. März, als es zu einem weltweiten Ausfall der Authentifizierung kam. Dies war ein sehr öffentlichkeitswirksames Ereignis, von dem sowohl Endnutzer als auch Dienstleister betroffen waren. Bei uns führte dies zu einem enormen Anstieg an Supportanfragen für Datto SaaS Protection, wodurch sich unser für den Monat März erwartetes Supportvolumen mehr als verdoppelte. Die Bearbeitung all dieser Supportanfragen nahm viel Zeit in Anspruch und führte zu einem erheblichen Rückstau. Seitdem haben wir Änderungen an den Prozessen und der Personalbesetzung vorgenommen, um ein solches Ereignis bewältigen zu können, sollte es in Zukunft erneut auftreten.

Praktisch zeitgleich mit dem Auftreten des Authentifizierungsproblems traten auch Fehler bei einer unserer Peering-Verbindungen in der US-Region auf. Microsoft bietet einen Peering-Dienst an, der eine geringere Latenz und höhere Zuverlässigkeit für den Datenverkehr zu und von Microsoft-Diensten wie M365 und Azure gewährleistet. Wir investieren in diese Verbindungen, sobald wir in einer bestimmten Region eine bestimmte Größenordnung erreichen. Die Nutzung von Peering-Verbindungen ist sowohl für Datto als auch für unsere Partner von Vorteil. In der US-Region verfügen wir über mehrere Peering-Verbindungen zu unseren Rechenzentren, von denen jedoch nur eine Fehler aufwies, was die Diagnose des genauen Problems erschwerte. Die größte Herausforderung bei der Ermittlung der Ursache der Peering-Verbindungsfehler bestand darin, dass wir lediglich Microsoft-API-Fehlermeldungen erhielten, die genau wie die Fehler aussahen, die wir während des Authentifizierungsausfalls erhalten hatten. Aufgrund des zeitlichen Zusammenfalls verschmolzen diese Probleme zu einer perfekten Sturmfront und führten zu einem sprunghaften Anstieg der Support-Anfragen.

Das letzte nennenswerte Microsoft-Ereignis fand an aufeinanderfolgenden Tagen im Mai statt. Unsere Überwachungs- und Warnsysteme erkannten das Problem umgehend, da unsere KPIs rapide abfielen. Nach einer Untersuchung konnten wir als Ursache einen Fehler bei der TLS-Verhandlung identifizieren. Microsoft führte schrittweise Aktualisierungen der akzeptierten TLS-Versionen und Verschlüsselungsalgorithmen durch. Wir nutzten bereits TLS v1.2. Microsoft hatte jedoch innerhalb von TLS v1.2 eine bestimmte Gruppe von Verschlüsselungsalgorithmen handverlesen, die das Unternehmen fortan nur noch akzeptieren würde. Da diese Änderung nicht ausreichend kommuniziert worden war, eröffneten wir bei Microsoft ein Ticket wegen eines Produktionsausfalls. Ich kann nur vermuten, dass andere Anbieter dasselbe taten, denn schon sehr bald darauf stoppte Microsoft die schrittweisen Updates und machte die Änderungen rückgängig (was in der Tat sehr selten vorkommt). Leider begann Microsoft bereits 24 Stunden später erneut mit der Einführung dieser Updates. Wir waren gerade dabei, die Änderungen an den Verschlüsselungsalgorithmen zu testen, mussten aber schnell umschwenken und die TLS-Änderungen in unserer gesamten Infrastruktur bereitstellen. Dies bot die Gelegenheit, gemeinsam mit Microsoft ein geeignetes Kommunikationskonzept zu entwickeln, um uns in Zukunft ordnungsgemäß vor solchen Änderungen zu warnen. Ob Sie es glauben oder nicht: Selbst unsere Ansprechpartner im Premium-Support waren über diese Wartungsarbeiten nicht informiert.

Unsere Microsoft-Partnerschaft

Da Microsoft für uns und unsere Kunden so wichtig ist, investieren wir erheblich in diese Beziehung. Es gibt einige Dinge, die besonders hervorzuheben sind:

• Wir haben seit zwei Jahren einen Microsoft Premium Developer Support Vertrag. Damit haben wir einen eigenen Support-Manager, der uns bei der Eskalation unserer Support-Tickets hilft und Zugang zu zusätzlichen technischen Ressourcen hat.
• Zusätzlich zum Premium-Supportvertrag für Entwickler kaufen wir je nach Bedarf Beratungsstunden für Entwickler. Wir haben diese auf verschiedene Weise genutzt:
  • Wenn wir neue Funktionen entwickeln, können wir einen Experten auf einem bestimmten Gebiet hinzuziehen, der unser Design und unsere Logik überprüfen kann, um sicherzustellen, dass wir die richtigen APIs verwenden und die Daten auf die richtige Weise interpretieren. Es ist eine bequeme Möglichkeit, einen Experten von Microsoft zur Unterstützung bei der Entwicklung und Überprüfung unserer Lösung hinzuzuziehen.
  • Für bestimmte Supportfälle, die unserer Meinung nach nicht die richtige Aufmerksamkeit erhalten, können wir diese Beratungsstunden nutzen, um eine spezielle Ressource zugewiesen zu bekommen. In gewisser Weise zahlen wir dafür, dass einige unserer wichtigsten Microsoft-Probleme zeitnah behandelt werden. Manchmal führt dies dazu, dass Microsoft eine Code-Änderung vornehmen muss, was einen längeren Zeitraum in Anspruch nehmen kann. In anderen Fällen können sie eine Umgehung oder eine alternative Lösung vorschlagen, um das Problem vollständig zu vermeiden.
• Was schließlich den Microsoft-Support betrifft, so fügen wir unserem Premium-Support eine Option hinzu, die es unseren Partnern und Kunden ermöglicht, ein Microsoft-Ticket gemeinsam mit uns zu bearbeiten. Dies schafft nicht nur Transparenz über den Status, sondern verkürzt auch die Bearbeitungszeit bestimmter Tickets. Wir sind oft die Person in der Mitte (d.h. Microsoft bittet uns, den Partner oder Endkunden etwas zu fragen und umgekehrt). Wir sind der Meinung, dass dies in bestimmten Situationen einen großen Unterschied machen wird und einen weiteren Mehrwert darstellt, den wir bieten können.
• Da sich „Datto Backup for Microsoft Azure “ nun in der Early-Access-Phase befindet, sind wir nicht nur Partner von Microsoft, sondern auch ein wichtiger aufstrebender Kunde. Wir haben gemeinsam ein großes Interesse daran, unsere Zusammenarbeit zu einem großen Erfolg zu machen. Es ist wirklich eine Win-Win-Win-Situation (für Datto, Microsoft und unsere Partner).

Wir haben nur an der Oberfläche einiger der Geschichten und technischen Herausforderungen gekratzt, die wir erlebt haben. In zukünftigen Blogs werden wir uns mit verschiedenen Aspekten von Datto SaaS Protection beschäftigen.