Wir möchten uns aufrichtig für die Unannehmlichkeiten entschuldigen, die durch die jüngsten Serviceunterbrechungen entstanden sind. Zuverlässigkeit und Kundenservice haben für uns weiterhin höchste Priorität, und wir entschuldigen uns für etwaige Schwierigkeiten, mit denen unsere Kunden konfrontiert waren. Nachfolgend finden Sie eine detaillierte Ursachenanalyse (RCA) des Vorfalls:
Ausgabe:
Ein BGP-Routenleck in den Gcore-Reinigungszentren führte zur Nichtverfügbarkeit von Cloud-, Baremetal- und WAAP-Diensten.
Zeitleiste:
11.04.2025 07:32 (UTC) – Die Einführung der Funktion „Aggregierte Adressen“ hat für einen Kunden begonnen. Hiera-YAML-Änderungen wurden übernommen.
11.04.2025 07:51 (UTC) - Puppet geändert, mit dem Master-Zweig zusammengeführt
11.04.2025 08:11 (UTC) – Auswirkungen haben begonnen; Kunden haben begonnen, Probleme zu melden.
11.04.2025 08:18 (UTC) - Untersuchung begonnen
11.04.2025 08:25 (UTC) – Beginn einer Notfall-Konferenzschaltung; Ingenieure und wichtige Teammitglieder werden zur Untersuchung zusammengerufen
11.04.2025 08:28 (UTC) – Die Grundursache wurde identifiziert und die Vorbereitungen für ein Rollback haben begonnen.
11.04.2025 08:32 (UTC) - Schadensbegrenzung gestartet
11.04.2025 08.38 (UTC) - Ende des Aufpralls
Grundursache:
• Cloud, Baremetal und WAAP waren teilweise nicht verfügbar, da der Datenverkehr zu ihnen durch das Threat Mitigation System (TMS) blockiert wurde.
• TMS-Server haben begonnen, die Netzwerkpräfixe von Gcore bekannt zu geben
• Der TMS-Agent hat falsche Präfixe an die Knoten für die Konfiguration übermittelt
• TMS hat im Feld customers.<customer_id>.prefixes nachgesehen und für jedes definierte Präfix xxxxx/32 ein Aggregat prefix_agg = xxxx0/24 erstellt und die Vorlage gerendert
◦ Liquid-Fehler: Unbekannter Operator ist
◦ Diese Logik wählte Kunden-IPs (/32) aus gemeinsam genutzten Cloud-Netzwerken aus und kündigte breitere Präfixe (/24) von TMS an, für die keine DDoS-Konfiguration vorhanden war. Daher wurde der Datenverkehr blockiert (Standardrichtlinie).
• fehlerhaftes Verhalten wurde global eingeführt
• Im Preprod-Netzwerk wurde kein fehlerhaftes Verhalten erkannt
• Wir haben von TMS-Knoten keine Warnung über verlorene Pakete erhalten
◦ Fehlende Warnung für den Zähler „Mellanox XDP Counters: Errors“ (wird erst am 17.04.2025 hinzugefügt)
Auswirkungen:
Einige Kunden und Service Cloud-Konten waren betroffen. Dauer der Ausfallzeit ~30 Minuten.
Aktionselemente:
• Implementieren Sie Änderungen im Testprozess
◦ [Benachrichtigung über ein bevorstehendes Update] Aktualisieren Sie den TMS-Agenten in der Produktion und Vorproduktion, damit jeder das Update sehen kann
◦ [vollständigen Testablauf prüfen] Erstellen Sie eine Sandbox für BGP-Tests
• Canary-Bereitstellung
◦ [Funktionalität vorübergehend aktivieren] Verwenden Sie Feature-Flags für den Sifter-Agent, um die Funktionalität für 5–10 Minuten zu aktivieren und sehen Sie sich dann die Dashboards an (schneller als mit Puppet).
◦ [Auswirkungen reduzieren] Canary-Updates eingeschränkter bereitstellen, nicht nur nach Client-ID, sondern in sichereren Regionen (z. B. WA2-Standort).
◦ [Erhöhte Beobachtbarkeit] Fügen Sie Commit-Anmerkungen zu Dashboards mit Verkehr hinzu, damit Sie sehen können, wann etwas passiert ist
• Verfahren und Richtlinien verbessern
◦ [Auswirkungen reduzieren] Testverfahren für Sifter-Agent aktualisieren.
◦ [Auswirkungen reduzieren] Erstellen Sie eine ausgehende Präfixliste, die alle Netzwerke filtert, die nicht in der Sifter-Konfiguration enthalten sind.
◦ [Verbesserung der Beobachtbarkeit] Fehlende Warnung für den Zähler „Mellanox XDP Counters: Errors“
Wir entschuldigen uns nochmals für etwaige Unannehmlichkeiten. Wir danken Ihnen für Ihre Geduld und Ihr Verständnis und Ihre Mitarbeit.
Wenn Sie weitere Hilfe benötigen oder Bedenken haben, wenden Sie sich bitte an unser Support-Team unter support@gcore.com .
