Prod2 war zeitweise nicht verfügbar
Pending
Betroffene Komponenten
Platform
- investigating
Wir untersuchen derzeit dieses Problem.
- resolved
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
82 Split incidents · April 2026 — official updates, affected components, duration and resolution details.
Wir untersuchen derzeit dieses Problem.
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Die Pipeline-Ausführung ist in Prod1 stecken geblieben. Wir untersuchen das Problem.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
## Zusammenfassung Zwischen dem 27. August und dem 28. August 2026 kam es zu einem Problem, bei dem einige Pipelines, Bereitstellungen und verwandte Ressourcen als nicht in der Harness-Benutzeroberfläche und -API gefunden erschienen, obwohl die zugrunde liegenden Daten intakt blieben. Das Problem trat während eines geplanten Updates der internen Infrastruktur auf, das die Kommunikation zwischen internen Plattformdiensten beeinflusste. Infolgedessen konnten Anfragen, die von Konto, Organisation und Projektumfang abhängig waren, nicht erfolgreich abgeschlossen werden, was dazu führte, dass falsche, nicht gefundene Antworten an Kunden für bestehende Einheiten zurückgegeben wurden. Engineering identifizierte das Problem, rollte die Änderung zurück und stellte den normalen Service wieder her. Während des Vorfalls gingen keine Kundendaten verloren oder wurden gelöscht. ## Wurzelursache Das Problem wurde durch einen Konfigurationsfehler verursacht, der während eines geplanten internen Service-Routing-Updates in der Produktion eingeführt wurde. Ein interner Plattformdienst, der für die Lösung von Konto, Organisation und Projektkontext verantwortlich ist, konnte nach der Änderung keine Anfragen von anderen Harness-Diensten validieren. Da dieser Validierungsschritt erforderlich ist, bevor viele Entitätslesungen und Pipeline-bezogene Aktionen fortgesetzt werden können, tauchten die fehlgeschlagenen Anfragen an die Kunden als nicht gefundene Fehler für Ressourcen auf, die normalerweise weiterhin existierten. Das Problem beschränkte sich auf die betroffene Produktionsumgebung und wurde durch das Zurücksetzen der Änderung und die Wiederherstellung des vorherigen Servicekommunikationspfades behoben. ## Auswirkungen * Einige Kunden haben gesehen, dass bestehende Pipelines, Bereitstellungen und verwandte Entitäten als nicht in der Benutzeroberfläche und API zu finden erscheinen. * Einige Pipeline-bezogene Operationen, einschließlich Ausführungsfortschritt, Webhook-ausgelöste Starts, geplante Trigger-Auswertung und Entity-Listing, wurden vorübergehend unterbrochen. * Das Problem betraf die Verfügbarkeit und Sichtbarkeit bestehender Entitäten, es wurden jedoch keine Daten entfernt oder Kundenkonfigurationen geändert. * Es gab keinen unbefugten Zugriff und es wurde kein Verlust von Kundendaten beobachtet. ## Sanierung * **Sofort:** Das Update der Infrastrukturkonfiguration wurde wiederhergestellt und der zuvor funktionierende Dienstkommunikationspfad wiederhergestellt. * **Validierung der Wiederfindung:** Überprüfen Sie, ob die betroffenen Entity-Lookups, Pipeline-Operationen und abhängigen APIs nach dem Rollback normal funktionierten. * **Dauerhaft:** Die mit dem Update verbundene Konfigurationsbehandlung wurde korrigiert, sodass ähnliche Probleme die Service-to-Service-Authentifizierung in zukünftigen Rollouts nicht beeinträchtigen. ## Aktionspunkte Um zu verhindern, dass sich solche Probleme wiederholen, wird Harness 1. Verbesserung der Konfigurationsvalidierung durch Verbesserung der Vorbereitungstests zur Überprüfung der internen Servicekommunikation vor einer Verschiebung des Produktionsverkehrs. 2. Verbesserte Überwachung und Alarmierung auf interne Authentifizierungsfehler, damit Probleme früher erkannt werden können. 3. Verbesserung der Fehlerbehandlung, so dass Abhängigkeitsfehler den Kunden weniger wahrscheinlich als nicht gefundene Ressource erscheinen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit ein Problem, das in IACM-Pipelines in Prod-1, Prod-2, Prod-4 und EU1-Geschirrclustern gemeldet wurde.
Wir werden dieses Problem weiter untersuchen.
Wir haben die Änderung, die dieses Problem verursacht hat, in allen Clustern rückgängig gemacht.
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Wir untersuchen derzeit Berichte, dass die Benutzeroberfläche für Feature Management & Experimentation (FME) nicht geladen werden kann. Kunden, die versuchen, auf die FME-Konsole zuzugreifen, können auf Fehler oder nicht reagierende Seiten stoßen. Es wird nicht angenommen, dass die Feature-Flag-Auswertung und der SDK-Verkehr betroffen sind. Ein weiteres Update wird in Kürze folgen.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
## Zusammenfassung * Ab **23:42 UTC** am 23. August 2026 meldeten mehrere FME-Kunden Ausfälle beim Laden der FME-Benutzeroberfläche. * FME UI Artefakte, die vom CDN serviert wurden, sind aufgrund einer Aufbewahrungsrichtlinie abgelaufen, was dazu führte, dass FME UI nicht geladen wurde. * Jede Flag-Anfrage ändert sich über die API, die Änderungsbereitstellung und die Datenpipeline funktionierte ohne Unterbrechung weiter. ## Wurzelursache * Die FME UI wird von einem CDN bedient. Die UI-Artefakte wurden aufgrund einer Aufbewahrungsrichtlinie vertrieben, wodurch die Benutzeroberfläche nicht für alle Benutzer geladen werden konnte. ## Auswirkungen * Die FME-Benutzeroberfläche konnte nicht für alle Benutzer in allen Produktionsumgebungen geladen werden. ### Was war nicht betroffen? * SDK-Funktionalität und Laufzeitflag-Auswertung Admin API Calls * Konfigurationsdaten des Kundenflags * Kein Datenverlust aufgetreten ## Sanierung * FME UI wurde im CDN durch eine Bereitstellung wiederhergestellt * Die Wiederherstellung wurde in allen Produktionsumgebungen bestätigt, bevor der Vorfall abgeschlossen wurde. ## Aktionspunkte * Verbessern Sie die Aufbewahrungsrichtlinien für Vermögenswerte, damit die derzeit aktive Version niemals einer Räumung unterliegt.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Die Langsamkeit kann eines der folgenden Symptome verursachen: Pipelines starten nicht - Verzögerungen bei der Ausführung Pipelines werden aufgrund von Timeouts gestrichen
Unser Cloud-Anbieter steht vor einem aktiven Vorfall und wir verfolgen ihn.
Wir werden dieses Problem weiter untersuchen.
Unser Cloud-Anbieter hat einen anhaltenden Vorfall bestätigt, der mehrere Regionen betrifft. Harness-Pipelines haben keine Ausfälle erlebt, obwohl einige Benutzer weiterhin Langsamkeit erleben können. Wir beobachten die Situation genau und werden Updates bereitstellen, sobald mehr Informationen verfügbar werden.
Wir beobachten verbesserte Latenzen auf der ganzen Linie nach dem Fix von unserem Cloud-Anbieter implementiert. Wir beobachten die Situation weiterhin genau und werden weitere Updates bereitstellen, wenn dies gerechtfertigt ist. Wir haben einige festgefahrene Hinrichtungen für CI für einige Kunden festgestellt, die wir untersuchen
Dieser Vorfall wurde behoben.
# Zusammenfassung Am 20. August 2026, ab ca. 15:00 Uhr UTC, erlebte die Harness-Plattform eine weit verbreitete Leistungsminderung in allen Produktionsumgebungen. Pipeline-Ausführungen, die normalerweise in etwa zwei Minuten abgeschlossen sind, dauerten sieben bis zehn Minuten. Continuous Delivery, Continuous Integration, Pipeline-Orchestrierung und Feature Management & Experimentation waren alle betroffen. Die Google Cloud Platform erlebte einen Multi-Produkt-Vorfall in der US-West1-Region, der Bigtable, Compute Engine, Google Kubernetes Engine und Persistent-Disk-I/O betraf. Die Degradation erhöhte die Latenz des Datenbankbetriebs von etwa 2 ms auf über 10 ms beim 95. Perzentil, was wiederum zu einer Verzögerung bei der Verarbeitung von Nachrichten in der Warteschlange führte und sich auf jeden Dienst ausbreitete, der von einem rechtzeitigen Datenbankzugriff abhängt. # Auswirkungen Dies war eine Verschlechterung, kein Ausfall. Pipelines fuhren fort, überall erfolgreich auszuführen und abzuschließen; sie waren langsam, anstatt zu scheitern. Es gingen keine Daten verloren, und infolge dieses Vorfalls wurde keine Kundenarbeit eingestellt. # **Wurzelursache** Die Nutzung der Produktionsinfrastruktur in den betroffenen Umgebungen läuft auf persistenten Festplatten der Google Cloud Platform in der Region us-west1. Wenn diese Speicherschicht abgebaut wurde, verbreitete sich der Effekt in einer vorhersehbaren Kette durch die Plattform: **Persistent-disk I/O-Abbau in us-west1.** Die Google Cloud Platform erlebte einen Multi-Produkt-Vorfall, der Bigtable, Compute Engine, Google Kubernetes Engine und Persistenzdatenträger-Performance betraf. Dies war ein Infrastrukturfehler in der Umgebung des Anbieters, der sich der Kontrolle von Harness entzog. # **Vorbeugende Maßnahmen** Obwohl Harness einen Ausfall der Cloud-Provider-Infrastruktur nicht verhindern kann. Die folgenden Aktionen zielen darauf ab, einen schneller zu erkennen und besser positioniert zu sein, um darauf zu reagieren. | **Action** | --- | Fortsetzung der routinemäßigen Vortests von gezielten bereichsübergreifenden Datenbank-Failovers, wie sie während dieses Vorfalls durchgeführt wurden, um die Failover-Bereitschaft eher verifiziert als angenommen zu halten. | Bewertung der Vollstapel-Multi-Region-Failover-Bereitschaft für Zukunftsszenarien, in denen eine regionenübergreifende Latenz inakzeptabel wäre |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
### Zusammenfassung Am 20. August 2026, zwischen 10:24 und 14:55 UTC, scheiterte eine Teilmenge der FME-Schreiben. Writes aus der FME-Benutzeroberfläche und Writes mit Harness-Zugriffstoken (PATs und SATs) waren nicht betroffen. Die Runtime-Flag-Bewertung funktionierte weiterhin normal. Das Problem wurde gemildert, indem eine kürzliche Authentifizierungsänderung in einem Shared-Governance-Service rückgängig gemacht wurde, und betroffene Schreibvorgänge wurden um 14:55 UTC wieder normalisiert. Status: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) ### Wurzelursache Eine Änderung in der Art und Weise, wie ein Shared Governance Service eingehende Anrufe authentifizierte, führte dazu, dass einige FME-Schreiben abgelehnt wurden. Diese Schreibvorgänge verwendeten Service-to-Service-Anmeldeinformationen, die der Governance-Service nach der Änderung nicht mehr überprüfen konnte. FME zeigt einen Governance-Fehler an den Client als HTTP 499, den gleichen Status, der verwendet wird, wenn eine Governance-Richtlinie eine Änderung absichtlich ablehnt. Da 499 eine gültige, erwartete Antwort in diesem Deny-Pfad ist, sahen die Ausfälle nicht wie ein Ausfall in unseren Warnungen aus, und der Vorfall wurde aus Kundenberichten und nicht aus der internen Erkennung identifiziert. ### Auswirkungen * Eine Teilmenge von FME-Schreiben ist während des Fensters fehlgeschlagen, hauptsächlich solche, die mit Legacy-Split-API-Schlüsseln oder Änderungsanforderungen erstellt wurden. * Writes aus der FME UI wurden nicht betroffen. * Schreibt mit Harness-Zugriffstoken (PATs und SATs) wurden nicht beeinflusst. * Die Laufzeitflag-Auswertung wurde normal fortgesetzt. * Es ist kein Datenverlust aufgetreten. Failed Writes gelten nicht. ### Sanierung Die Änderung der Governance-Service-Authentifizierung wurde rückgängig gemacht. Betroffene schreiben sofort wieder normal. ### Aktionspunkte Um zu verhindern, dass sich solche Probleme wiederholen, * Harness gibt einen eindeutigen Fehler zurück (nicht 499), wenn ein Schreiben fehlschlägt, weil die Governance nicht bewertet werden konnte, so dass sie nicht mit einer absichtlichen Politikverweigerung verwechselt wird. * Fügen Sie eine Warnung zum Governance-Evaluierungsaufruf selbst hinzu, anstatt sich auf den Client-Statuscode zu verlassen. * Erweitern Sie die Authentifizierungsunterstützung für Richtlinienbewertungen. * Erweitern Sie die automatisierte Abdeckung für zusätzliche Schreibszenarien.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Wir werden dieses Problem weiter untersuchen.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Wir werden weiterhin auf weitere Probleme achten.
Dieser Vorfall wurde behoben.
**Zusammenfassung** Am 19. August 2026 zwischen 12:35 und 17:29 UTC erlebte der Harness Application Security Service eine erhebliche Störung, die sowohl die kundenorientierte Konsole als auch die Datenaufnahme-Pipeline in den Regionen SaaS Production und US1 betraf. **Wurzelursache** Der interne Konfigurationsdienst, der die Laufzeiteinstellungen für fast alle anderen Komponenten bereitstellt, wurde überlastet und trat in einen wiederholten Neustartzyklus ein. Da so viele Dienste davon abhängen, waren die Auswirkungen breit: Konsolenseiten wie Schutzrichtlinien, Haltungsansichten, Aktivitätsprotokolle, API-Inventar und benutzerdefinierte Richtlinien konnten nicht geladen oder zeitversetzt werden, und die nachgelagerte Verarbeitung blieb stehen, während sie auf die Konfiguration wartete, die sie nicht erhalten konnte. # **Kundenauswirkungen** | **Dimension** | **Detail** | | --- | --- | Auswirkungen auf die Konsole \(UI\) | Mehrere Seiten konnten nicht geladen oder zeitgesteuert werden, einschließlich Schutzrichtlinien, Haltungsereignisseiten und Haltungsansichten in Dashboards und Einblicksseiten, Aktivitätsprotokollabfragen, API-Inventarbildschirmen, benutzerdefinierten Richtlinien und Ansichten von sensiblen Daten und Widgets. | | Ingestion Impact | Security Telemetry Processing verschlechterte sich stark und stoppte auf einigen Wegen vollständig. Der Verbraucherrückstand wuchs in den Phasen Normalisierung, Gruppierung, Anomalieerkennung, Generierung und verwandter Verarbeitung. | | Datenverlust | Eine Teilmenge der Telemetrie, die während der Störung aufgenommen wurde, wurde dauerhaft fallen gelassen. | **Abschwächung** Mehrere Zwischenminderungen zusätzliche CPU und Speicher, entspannte Health-Check-Schwellenwerte, ein Datenbankneustart und ein größerer Verbindungspool haben das Problem gelindert. Deaktivierung der neuen Funktion in beiden betroffenen Regionen wiederhergestellt Durchsatz scharf und dauerhaft. Der Vorfall wurde um 17:29 UTC gelöst. # **Vorbeugende Maßnahmen** Die folgenden Aktionen werden festgelegt und intern bis zum Abschluss verfolgt. Die Funktion, die diesen Vorfall ausgelöst hat, bleibt deaktiviert und wird erst wieder aktiviert, wenn die unten stehende Arbeit abgeschlossen und validiert ist. | **Action** | --- | | | | OPtimieren Sie den Code durch Tuning-Parameter wie Cache-Räumung und Retention , bewerten Sie die Cursor-basierte Paginierung für den Massenregelabruf, wenn die Regelzahl wächst | | Fügen Sie einen zweckgebundenen Datenbankindex für das Service-Scoping-Zugriffsmuster hinzu | | Beheben Sie die Semantik der Pipeline-Wiederherstellung, damit Verbraucher nach Positionsmarkerverlust sicher spielen können, anstatt den Rückstand zu überspringen | | Mandatsstufen-Rollout für Konfigurationsüberschreibungen, die nachgelagerte Anforderungsmuster verändern: Cluster mit niedrigem Volumen, dann mit mittlerem Volumen, dann mit hohem Volumen | | Fügen Sie dem Konfigurationsdienst Gegendruck- und Parallelitätsschutz hinzu: Stromkreisunterbrechung, begrenzte Warteschlangen und Timeout-Isolation | | Erhöhen Sie die Beobachtbarkeit durch Instrumentierung detaillierterer Metriken |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Wir überwachen die steckengebliebenen Pipelines in prod2. Die neuen Hinrichtungen gehen vorüber, da wir die Dienste kontinuierlich überwachen.
Wir überwachen die steckengebliebenen Pipelines in prod2. Für die Kunden, die immer noch steckengebliebene Pipelines sehen, bitten wir Sie, abzubrechen und neu auszulösen.
Dieser Vorfall wurde behoben.
## **Zusammenfassung** Am 6. August 2026 (morgendliche PDT) beobachteten einige Kunden, die Pipelines in der Prod2-Produktionsumgebung betrieben, Pipelineausführungen, die keine Fortschritte mehr machten - Phasen, die nicht vorankamen und keine weiteren Output- oder Statusaktualisierungen produzierten. Das Problem wurde von betroffenen Kunden gemeldet. Harness-Ingenieure identifizierten die Ursache, milderten die Auswirkungen und Pipeline-Ausführungen kehrten in den normalen Betrieb zurück. Das Problem wurde durch einen selbstreferenziellen Pipeline-Ausdruck verursacht. Ein Git-Webhook löste eine Pipeline aus, die sich auf den Inhalt der Webhook-Nutzlast bezog, und die Nutzlast selbst enthielt weitere Kopien desselben Ausdrucks. Jede Runde der Ausdrucksauflösung erzeugte daher mehr aufzulösende Ausdrücke, wodurch sich der Arbeitsaufwand jedes Mal verdoppelte. Dies erschöpfte die Ressourcen der Dienstinstanz, die diese Ausführung verarbeitete, und andere, derselben Instanz zugewiesene Ausführung konnte nicht fortschreiten, während sie sich in diesem Zustand befand. ## **Auswirkungen** Während des Ereignisfensters \(ca. 6:11 Uhr bis 11:23 Uhr PDT am 6. August 2026\): * Einige Kunden Pipeline-Ausführungen auf Prod2 ins Stocken geraten Mitte Ausführung und machte keine weiteren Fortschritte. * Betroffene Executions erzeugten keine neuen Schritt-Outputs oder Status-Updates und mussten nach der Minderung abgebrochen und erneut ausgeführt werden. * Das Verhalten beschränkte sich auf die Ausführung, die von der betroffenen Serviceinstanz verarbeitet wurde – Pipelines, die von anderen Instanzen bearbeitet wurden, wurden weiterhin normal ausgeführt. Es gab ** keinen Datenverlust **. Pipeline-Definitionen, Ausführungshistorie und gespeicherter Zustand waren nicht betroffen. Die meisten Pipelines auf Prod2 wurden während des gesamten Vorfalls weiterhin erfolgreich ausgeführt; die Hauptauswirkungen waren, dass einige Ausführungsvorgänge während des Fluges nicht abgeschlossen werden konnten und erneut ausgeführt werden mussten, sobald das Problem behoben war. ## **Wurzelursache** Harness-Pipelines unterstützen Ausdrücke, die zur Laufzeit aufgelöst werden – zum Beispiel ein Ausdruck, der den Inhalt der Git-Webhook-Nutzlast einfügt, die die Pipeline ausgelöst hat. In diesem Fall enthielt eine Git-Commit-Nachricht zweimal den wörtlichen Text des Nutzlastausdrucks selbst, und die Pipeline referenzierte denselben Nutzlastausdruck. Da die Commit-Nachricht Teil der Webhook-Nutzlast ist, hat das Auflösen des Ausdrucks die gesamte Payload eingefügt - einschließlich der beiden wörtlichen Kopien des Ausdrucks, die in der Commit-Nachricht enthalten sind. Diese neu eingefügten Kopien wurden dann als aufzulösende Ausdrücke behandelt, und jeder Durchlauf fügte zwei weitere vollständige Kopien der Nutzlast ein. Die Größe des zu verarbeitenden Wertes und die zu seiner Verarbeitung erforderliche Arbeit verdoppelten sich daher bei jedem Durchlauf und wuchsen exponentiell, anstatt sich anzunähern. Harness hat einen Schutz, der genau dies verhindern soll: Die Ausdrucksauflösung wird durch eine maximale Verschachtelungstiefe begrenzt, ab der die Auflösung endet und die Pipeline mit einem expliziten Fehler ausfällt. Ein Fehler in dieser Sicherung bedeutete, dass der Grenzwert in diesem speziellen selbstreferenziellen Fall nicht angewendet wurde, so dass die Auflösung ungeprüft fortgesetzt wurde. Ausdrucksauflösung läuft inline auf den Threads, die Pipeline-Schritte starten. Da jeder Durchlauf progressiv mehr Speicher und CPU verbrauchte, ohne jemals abgeschlossen zu sein, hörte die Dienstinstanz, die diese Arbeit ausführte, auf, Fortschritte zu machen, und jede Ausführung, die dieser Instanz zugewiesen wurde, blieb stehen - was Kunden berichteten. ## **Abschwächung** Harness hat die folgenden sofortigen Minderungsschritte abgeschlossen: * Identifizierte die Pipeline und das Ausdrucksmuster, das für die außer Kontrolle geratene Auflösung verantwortlich ist. * Stoppte die betroffene Serviceinstanz, damit sie keine weiteren Arbeiten übernehmen würde. Die verbleibenden gesunden Instanzen nahmen ab und verarbeiteten normalerweise Schlangenausführungen. * Bestätigt, dass Pipeline-Ausführungen wieder normalisiert wurden und der Vorfall geschlossen wurde. Diese Aktionen stellten das normale Pipeline-Ausführungsverhalten wieder her und lösten die Auswirkungen auf den Kunden. ## **Aktionspunkte** Um das Rezidivrisiko zu verringern und die Erkennung zu verbessern, sind die folgenden Maßnahmen in verschiedenen Phasen implementiert: * Beheben Sie den Fehler in der Ausdruckstiefe und Schleifenerkennung, damit selbstreferenzielle Ausdrücke abgefangen werden und schnell mit einem klaren Fehler versagen, anstatt Ressourcen ohne Grenzen zu verbrauchen. * Verhindern Sie, dass Nutzlastausdrücke aus dem Trigger-Nutzlastinhalt aufgelöst werden, wodurch der selbstreferenzielle Pfad vollständig entfernt wird. * Verschärfung der maximalen Ausdrucksverschachtelungstiefe und Auswertung der expliziten Schleifenerkennung zusätzlich zur vorhandenen Tiefengrenze. * Verbessern Sie automatisierte Tests in Vorproduktionsumgebungen, die selbstreferenzielle Ausdrucksmuster reproduzieren, und überprüfen Sie, ob der Schutz sie erkennt und stoppt. * Fügen Sie die Überwachung dieses Musters in Pipeline-Ausführungen hinzu, damit es proaktiv erkannt wird.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
Wir untersuchen derzeit dieses Problem.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
# **Zusammenfassung** Zwischen dem 25. Juli und dem 4. August 2026 zeigten Pipelineausführungs-Dashboards und Übersichtsseiten in den Clustern Harness Prod 2 und Prod 3 Daten an, die in Echtzeit dazwischen lagen. Pipelines selbst bauten, implementierten und ausgeführten weiterhin normal; das Problem beschränkte sich darauf, wie schnell Ausführungsdatensätze in die Datenbank kopiert wurden, die Berichts- und Dashboardansichten bedient. **Es gingen keine Kundendaten verloren.** Jeder betroffene Datensatz blieb dauerhaft gespeichert und wurde in den Analysedatenspeicher wiedergegeben, sobald die zugrunde liegende Einschränkung entfernt wurde. Harness migrierte die betroffenen Cluster am 1. August 2026 auf eine horizontal skalierbare, Warteschlangen-gestützte Version der Replikationskomponente und führte gezielte Daten-Backfills für alle betroffenen Konten durch. # **Wurzelursache** Harness unterhält eine Change-Data-Capture-Komponente, die kontinuierlich Pipeline-Ausführungsdatensätze aus dem primären Betriebsdatenspeicher in einen separaten Zeitreihen-Datenspeicher repliziert, der für Dashboards und Berichtsabfragen optimiert ist. Dashboards lesen ausschließlich aus dem Analytics-Datenspeicher. Wenn die Replikation zurückfällt, stellen Dashboards eine genaue, aber ältere Ansicht der Welt dar, während die Ausführung selbst nicht betroffen ist. Dies wurde durch einen starken, anhaltenden Anstieg des Datenbankschreibvolumens von einem anderen Harness-Plattformmodul verursacht, das sich den gleichen Replikationspfad teilt und die Durchsatzobergrenze der älteren Single-Instance-Version dieser Komponente, die noch in Prod 2 und Prod 3 läuft, überschritten hat. Ein Backlog bildete sich und wuchs. # **Vorbeugende Maßnahmen** Harness hat die folgenden Maßnahmen abgeschlossen oder sich verpflichtet, um solche Probleme zu verhindern. | **Action** | --- | | Feintune die Replikationsverzögerung Warnung, so dass jede Verzögerung über einen definierten Schwellenwert hinaus benachrichtigt wird | | Fügen Sie ein Replikations-Lag-Panel zum Standard-Plattform-Monitoring-Board hinzu, damit der Zustand der Pipeline standardmäßig für den Bereitschaftsdienst sichtbar ist | | Schreibverstärkung von Co-Tenant-Modulen durch pro-Module-Ratenbegrenzung oder Entitätsfilterung im Replikationsstrom reduzieren |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
# **Zusammenfassung** Am 31. Juli 2026 scheiterten Artefakt-Uploads, die über eine Pipeline im EU1-Cluster durchgeführt wurden, mit einem Authentifizierungsfehler. manuell initiierte Uploads (außerhalb einer Pipeline) waren nicht betroffen, und die Fähigkeit, vorhandene Artefakte abzurufen (Downloads) war ebenfalls nicht betroffen - dies wurde auf den spezifischen Pipeline-Upload-Pfad in einem Cluster isoliert. # ** Auswirkungen ** * Artefakt-Uploads, die über eine Pipeline im EU1-Cluster durchgeführt wurden, scheiterten mit einem Authentifizierungsfehler für etwa 4 Stunden und 34 Minuten. * Das Abrufen vorhandener Artefakte \(Downloads\) war nicht betroffen. * Das manuelle Hochladen von Artefakten außerhalb einer Pipeline war nicht betroffen. * Andere Cluster/Regionen waren von diesem Problem nicht betroffen. # **Wurzelursache** Die Komponente, die für den Umgang mit Pipeline-basierten Artefakt-Uploads verantwortlich ist, wird als Container-Image verteilt. Im EU1-Cluster wird dieses Bild aus einer internen Registrierung abgerufen, die eine öffentliche Bildquelle widerspiegelt; in anderen Clustern wird dasselbe Bild direkt aus der öffentlichen Quelle abgerufen. Ein Veröffentlichungsfehler in unserem Veröffentlichungsprozess führte dazu, dass ein neuer Build dieser Komponente unter Verwendung eines bereits verwendeten Versionslabels veröffentlicht wurde, anstatt eine neue, einzigartige Version zu erhalten. Infolgedessen wurden zwei verschiedene Bilder mit dem gleichen Versionslabel in der öffentlichen Quelle assoziiert. Unsere interne Registry spiegelt Bilder aus der öffentlichen Quelle über einen automatisierten Replikationsprozess. Aufgrund der Art und Weise, wie diese Replikation ausgelöst wurde, kopierte sie das ursprüngliche \(früher\) Bild, das mit diesem Versionslabel assoziiert ist, anstatt das korrigierte. Dies bedeutete, dass der EU1-Cluster, der aus dem internen Spiegel zieht, am Ende ein anderes, defektes Bild ausführte als andere Cluster, die direkt aus der öffentlichen Quelle ziehen und daher das korrigierte Bild erhalten. Das defekte Bild enthielt ein Authentifizierungsproblem, das dazu führte, dass Pipeline-Uploads fehlschlugen. # **Abwehr** * Das betroffene Konto wurde auf die letzte bekannte-gute Version der Upload-Komponente zurückgesetzt und die Pipeline-Uploads sofort wiederhergestellt. * Veröffentlichte eine korrigierte, dauerhafte Version der Komponente, um das Problem in allen Clustern zu beheben. # **Nächste Schritte** * Beheben Sie den Upload-Schritt, um den zugrunde liegenden containerbezogenen Defekt zu entfernen, der diesen Fehlermodus ermöglicht hat. * Aktualisieren Sie unsere Release-Pipeline für diese Komponente, so dass die Veröffentlichung eines Bildes niemals eine bestehende Version überschreiben kann - jeder Verlag muss eine neue, eindeutige Version erstellen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Zusammenfassung - Wir stehen gelegentlich vor Netzwerkverbindungsproblemen mit unseren Build-VMs, die keine Verbindung zu externen Ressourcen herstellen können. Wir untersuchen derzeit das Problem.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Wir werden weiterhin auf weitere Probleme achten.
Dieser Vorfall wurde behoben.
## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Wir werden dieses Problem weiter untersuchen.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Wir arbeiten weiter an einer Lösung für dieses Problem.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Wir werden weiterhin auf weitere Probleme achten.
Dieser Vorfall wurde behoben.
# Zusammenfassung Während einer kürzlichen Bereitstellung in der Produktion führte ein Fehler in unserem internen Bereitstellungstool dazu, dass zwei kritische Dienste mit falschen, nicht produktionsbezogenen Konfigurationswerten in unserer Produktionsumgebung ausgeführt wurden. Dies führte zu einem verwandten Satz von vier verschiedenen Symptomen: falsches Konfigurationsverhalten, intermittierende Anmelde- / Zugriffsfehler, ein Filestore-Zugriffsproblem, das eine Kundenumgebung betrifft, und verzögerte Pipeline-Statusaktualisierungen in der Benutzeroberfläche. Wir haben eine dauerhafte Korrektur für den zugrunde liegenden Konfigurationsfehler identifiziert und implementieren diese und haben bereits Ressourcen- und Kapazitätsänderungen vorgenommen, die das UI-Verzögerungssymptom beheben. Zu keinem Zeitpunkt während dieses Vorfalls waren Pipeline-Exekutionen selbst verloren, korrumpiert oder in einem steckengebliebenen Zustand. Wo das Ausführungsverhalten betroffen war, beschränkte es sich auf Verzögerungen in der Statussichtbarkeit, nicht in der zugrunde liegenden Verarbeitung. # Vorfall Details ## Angewandte falsche Produktionskonfigurationswerte Unser Engineering-Team bestätigte einen Fehler in der Service Manager-Bereitstellungspipeline, der dazu führte, dass bestimmte Produktionsdienste mit Konfigurationswerten bereitgestellt wurden, die für eine andere Umgebung bestimmt waren, anstatt die richtige Produktionskonfiguration. **Wurzelursache** Der für das Abrufen der Konfiguration zuständige Dienst überschreibt während der Bereitstellungsabfragen eine interne API, die maximal 1.000 Ergebnisse pro Anforderung zurückgibt. Die Gesamtzahl der Dienstleistungen in der Umwelt ist kürzlich über diese Grenze hinaus gewachsen. Infolgedessen wurde jeder Dienst, der über die ersten 1.000 zurückgegebenen Dienste hinausging, nicht in die Antwort einbezogen, und die Bereitstellungspipeline fiel stillschweigend auf die Standardkonfigurationswerte für diese Dienste zurück. Dies ist ein bestätigter Paginierungsfehler im Bereitstellungstool, kein Problem mit den Konfigurationswerten selbst. **Resolution** Engineering hat den Mechanismus bestätigt und implementiert eine dauerhafte Lösung, um diese grenzüberschreitende Lücke in der Bereitstellungspipeline zu beseitigen. ## Intermittierender Login / Zugriffsfehler Während der oben genannten Service-Manager-Bereitstellung traten bei einigen Benutzern intermittierende Anmelde- oder Zugriffsfehler auf. Im Normalbetrieb sollten zuvor ausgeführte Instanzen den Datenverkehr weiterhin ohne Unterbrechung bedienen, während eine neue Bereitstellung im Gange ist. Bei diesem Vorfall trat dieses Fallback-Verhalten nicht wie erwartet auf und trug zu Zugriffsfehlern während des Bereitstellungsfensters bei. Issue Filestore Access Es wurde ein Filestore-Zugriffsproblem identifiziert, das spezifisch für die Prod-3-Umgebung war und die Umgebung eines einzelnen Kunden betraf. **Wurzelursache** Dies bezieht sich auf eine IAM / Storage-Bucket-Berechtigungskonfiguration im Service Manager, die möglicherweise durch Rollback-Aktivitäten ausgelöst wird. ## Delayed Pipeline Execution Status Updates in UI Einige Benutzer beobachteten, dass das Pipeline-Ausführungsdiagramm in der Benutzeroberfläche langsam aktualisiert wurde und den neuesten Status nicht sofort widerspiegelte. Wichtig ist, dass dies nur eine Sichtbarkeitsverzögerung war: Es gab keine Auswirkungen auf die tatsächlichen Pipeline-Ausführungen, und keine Hinrichtungen wurden aufgrund dieses Problems blockiert oder fehlgeschlagen. **Wurzelursache** Der Pipeline-Ausführungsgraph stützt sich auf einen Nachrichtenstrom (das Orchestrierungsprotokoll), um Statusaktualisierungen zu erhalten. Während des Incident-Fensters fiel die Verbraucherverarbeitung dieses Streams hinter \(hohe Verbraucherverzögerung\), was verzögerte, wie schnell Statusaktualisierungen die Benutzeroberfläche erreichten. Dies wurde dadurch verursacht, dass sich die zugrunde liegende Datenbank gleichzeitig mitten in einer geplanten Skalierungsoperation befand und ein Traffic-Spike während dieses Fensters die Verzögerung weiter verschärfte. Benutzer erlebten dies als offensichtliche Pipeline-Langsamkeit, obwohl die zugrunde liegenden Ausführung normal lief. **Resolution** Wir haben die Ressourcenkapazität für die betroffenen Komponenten erhöht, um in Zukunft mehr als 50% freie Kopfhöhe zu erhalten und die Empfindlichkeit gegenüber ähnlichen Lastspitzen zu reduzieren. Diese Änderung wurde implementiert und wird derzeit im Rahmen der längerfristigen Härtung für diesen Teil der Plattform validiert. # Impact Summary * Service Manager und License Manager liefen mit falschen Konfigurationswerten in den Prod-1- und Prod-3-Umgebungen. * Einige Benutzer erlebten während des betroffenen Bereitstellungsfensters intermittierende Anmelde- oder Zugriffsfehler. * In einer Kundenumgebung in Prod-3 kam es zu einem Filestore-Zugriffsproblem. * Benutzer in den betroffenen Umgebungen sahen verzögerte Statusupdates für die Pipelineausführung in der Benutzeroberfläche; die zugrunde liegenden Pipelineausführungen liefen weiterhin korrekt und gingen nicht verloren, blieben stecken oder wurden beschädigt. # Präventivmaßnahmen Die folgenden Korrektur- und Vorbeugungsmaßnahmen wurden ermittelt. | **Korrektive / Präventivmaßnahmen** | | --- | | Korrigieren Sie das Paginierungslimit im Configuration-Lookup-Dienst, so dass alle Dienste zurückgegeben und ausgewertet werden, unabhängig von der Gesamtanzahl. | Hinzufügen von Sicherheitsvorkehrungen, damit ein Dienst, der seine Konfiguration nicht abrufen kann, sicher ausfällt (z. B. Warnungen und Blockierungen der Bereitstellung), anstatt stillschweigend auf Nicht-Produktions-Standards zurückzugreifen. | Steigern Sie die Ressourcenreserve von Postgres und Messaging-Pipeline (Ziel: mehr als 50% freie Kapazität), um die Empfindlichkeit gegenüber gleichzeitiger Belastung und Skalierungsereignissen zu reduzieren. | Wir erkennen die Auswirkungen dieses Vorfalls auf mehrere Bereiche der Plattform und schätzen Ihre Geduld, während wir eine vollständige Lösung durcharbeiten.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen ein Problem, das sich auf AIDI-Dashboards auswirkt. Benutzer können beim Zugriff auf Dashboards erhöhte Ladezeiten oder intermittierende Ausfälle feststellen. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und die normale Leistung wiederherzustellen. Wir werden Updates bereitstellen, sobald weitere Informationen verfügbar sind.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
## Zusammenfassung Kunden mit Prod1-, Prod2- und Prod3-Clustern erlebten intermittierende Widget-Ausfälle und erhöhte Ladezeiten beim Zugriff auf AIDI 2.0-Dashboards am 22. Juli 2026. Nicht alle Widgets waren gleichzeitig betroffen, das Problem manifestierte sich als sporadische Ausfälle und nicht als vollständiger Ausfall. Es gingen keine Kundendaten verloren. SEI 1.0-Kunden waren nicht betroffen. ## Wurzelursache Im Laufe der Zeit konnte ein routinemäßiger Datenbankwartungsprozess in bestimmten Tabellen in unserer Analysedatenbank nicht ausgeführt werden, was dazu führte, dass diese Tabellen eine große Menge interner Metadaten ansammelten, die zum Nachverfolgen gelöschter Datensätze verwendet wurden. Als die Datenbank Abfragen für diese Tabellen plante, lud sie all diese akkumulierten Metadaten in den Speicher, was dazu führte, dass die Speichernutzung auf den betroffenen Knoten wiederholt anstieg. Diese wiederholten Spikes lösten einen automatischen Sicherheitsmechanismus aus, der einen Knoten neu startet, wenn er einen übermäßigen Speicherdruck erkennt, und die betroffenen Knoten begannen daraufhin in einer Schleife neu zu starten. Dies führte zu einer intermittierenden, beeinträchtigten Abfrageleistung auf AIDI 2.0-Dashboards für die Dauer des Vorfalls. ## Auswirkungen Kunden mit Prod1-, Prod2- und Prod3-Clustern haben möglicherweise zeitweise Widget-Ausfälle oder erhöhte Ladezeiten auf AIDI 2.0-Dashboards erlebt. **Dauer:** 22. Juli 2026, 07:58 PDT – 16:16 PDT \(~8 Stunden 18 Minuten\), mit intermittierenden Widget-Ausfällen; System wurde neu gestartet und unter aktiver Überwachung ab 08:25 PDT weiter. ### Was war nicht betroffen? * Datenaufnahme und -verarbeitung * SEI 1.0 Kunden * Integrationen und Metadatenflüsse Es gingen keine Kundendaten verloren. ## Sanierung Bei der Identifizierung des Problems wurden die betroffenen Datenbankknoten um 08:25 PDT neu gestartet, wodurch die anfängliche Stabilität wiederhergestellt wurde. Wir fuhren fort, das System genau zu überwachen, und wenn intermittierende Degradation später noch beobachtet wurde, haben wir mehrere zusätzliche Fixes angewendet: * Angepasste Datenbankkonfigurationseinstellungen, um die Speichermenge für die Verarbeitung von akkumulierten Metadaten zu begrenzen, und abgestimmte Abfrageplanungseinstellungen, um den Speicherdruck zu reduzieren. * Ran-Bereinigungsaufträge, um den Rückstand der akkumulierten Metadaten auf den betroffenen Tabellen zu reduzieren. * Erhöhte Kapazität auf den betroffenen Datenbankknoten, um zusätzliche Headroom bereitzustellen. Diese Veränderungen stabilisierten das System schrittweise, und der Vorfall wurde um 16:16 PDT vollständig behoben. ## Aktionspunkte Um Wiederholungen zu verhindern, setzen wir Folgendes um: 1. Wir haben das Backend aktualisiert, das grundlegende Verbesserungen enthält, die Speicherspitzen behandeln, die durch übermäßige Löschdateien verursacht werden. 2. Wir haben automatisierte Verdichtungsaufträge für neu eingeführte Tabellen eingeführt, um zu verhindern, dass die Dateiakkumulation fortgesetzt wird.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Dieser Vorfall wurde behoben.
# Zusammenfassung Am 17. Juli 2026 begannen Kunden mit älteren Delegiertenversionen (858xx und darunter) nach einer routinemäßigen Codebereitstellung mit verzögerten CI-Builds auf Harness Cloud-gehosteten Builds mit unserer globalen Build-Warteschlangen-Fähigkeit. Betroffene Builds erlebten eine unerwartete Pause von bis zu etwa 8 Minuten in der Phase "Warten auf Infrastruktur", bevor sie fortfuhren, anstatt innerhalb der erwarteten Untersekundenzeit fortzufahren. Insgesamt Aufbau Langsamkeit war intermittierend. # Auswirkungen * Alle CI-Builds waren potenziell verzögerungsbehaftet; die Auswirkungen waren bei Builds auf Harness Cloud-gehosteter Infrastruktur mit der globalen Build-Warteschlangen-Funktion am stärksten ausgeprägt. * Betroffene Builds erlebten eine unerklärliche Pause von bis zu ca. 8 Minuten vor dem Weiterfahren, gefolgt von einem langsameren "Kaltstart", da ein vorreservierter Rechenplatz nicht verfügbar war - dies wurde den Benutzern als langsame Builds und nicht als Buildfehler angezeigt. * Konten, die auf neueren Delegiertenversionen (858xx und höher) ausgeführt werden, waren nicht betroffen. * Keine Builds scheiterten als direkte Folge dieses Problems und es gingen keine Daten verloren. # Wurzelursache Die Ursache war eine interne Codeänderung, die versehentlich brach, wie ein bestimmter Build-Warteschlangen-Datensatz aus unserer Datenbank zurückgelesen wurde, sobald Builds, die bereits unter der vorherigen Version des Codes in der Warteschlange standen, auf die neu bereitgestellte Version stießen. Wir haben die unmittelbaren Auswirkungen behoben, indem wir die betroffenen Datensätze bereinigt und die zugrunde liegende Codeänderung rückgängig gemacht haben, und wir implementieren mehrere Sicherheitsvorkehrungen, um zu verhindern, dass sich diese Klasse von Problemen wiederholt. # Nächste Schritte Wir bewerten das Risiko einer ähnlichen Wiederholung so gering, wie die folgenden Maßnahmen unterschätzt werden. Der spezifische Codepfad, der diesen Vorfall verursacht hat, wurde bereits rückgängig gemacht, und wir implementieren strukturelle Sicherheitsvorkehrungen, damit diese allgemeine Klasse von Problemen nicht wieder auftreten kann, unabhängig davon, wo sie sonst in der Codebasis auftreten könnten. | **Korrektive / Präventivmaßnahmen** | | --- | Fügen Sie allen internen Datenklassen, die in unserer Datenbank gespeichert werden, explizite, stabile Identifikatoren hinzu, damit zukünftige interne Code-Reorganisationen die Fähigkeit des Systems, zuvor gespeicherte Datensätze zurückzulesen, nicht beeinträchtigen können. | Einführung von Rollback- und Rückwärtskompatibilitätstests in unserer Vorproduktionsumgebung, die speziell darauf ausgelegt ist, diese Problemklasse zu erfassen, bevor sie die Produktion erreicht. |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit dieses Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Wir werden weiterhin auf weitere Probleme achten.
Dieser Vorfall wurde behoben.
# Zusammenfassung Zwischen dem 19. Juni und dem 17. Juli 2026 scheiterte der eingebaute Git Clone-Schritt - und jeder Pipeline-Schritt mit dem Drohnen-Git-Klon-Plugin - an der ARM64 Kubernetes Build-Infrastruktur mit dem Fehler exec /usr/local/bin/clone: exec format error. AMD64 \(Intel/AMD\) Builds, Windows Builds und der VM Containerless Binärpfad waren nicht betroffen. Die Ursache war ein Defekt in unserem internen Bildveröffentlichungsprozess, der dazu führte, dass ARM64-markierte Drohnen-Git-Bilder tatsächlich AMD64-Binärdateien enthielten. Wir identifizierten und milderten das Problem am selben Tag, an dem es gemeldet wurde, indem wir das Drohnen-Git-Bild auf die letzte bekannte gute Version zurücksetzten. Es war keine Kundenaktion oder Konfigurationsänderung erforderlich. # Wurzelursache Am 19. Juni 2026 wurde durch eine Sicherheitssanierung neu strukturiert, wie das Drohnen-Git-Bild aufgebaut ist. AMD64-Builds wurden korrekt aktualisiert, aber die ARM64-Build-Pipeline hat ARM64-Dateien nicht direkt erstellt - sie hat die AMD64-Build-Datei über Textsubstitution angepasst und auf der ARM64-Infrastruktur kompiliert. Die Änderung vom 19. Juni änderte die AMD64-Datei, so dass die Substitution stillschweigend nicht op'd statt zu scheitern, so dass die Pipeline ein Bild mit dem Tag ARM64 veröffentlichte, dessen Git Clone- und Git LFS-Binärdateien immer noch für AMD64 kompiliert wurden. # Auswirkungen Betroffen: Der eingebaute Git Clone-Schritt und jeder Pipeline-Schritt mit dem Drohnen-Git-Klon-Plugin, der zwischen dem 6. Juli und dem 17. Juli 2026 auf der ARM64 Kubernetes Build-Infrastruktur läuft. * Symptom: Builds sind beim Git Clone-Schritt mit exec /usr/local/bin/clone: exec format error fehlgeschlagen. * Nicht betroffen: AMD64 \(Intel/AMD\) Kubernetes und VM Builds, Windows Builds, der VM Containerless Ausführungspfad und unsere gehärtete Bildvariante. # Minderung Wir haben die Drohnen-Git-Bildversion, die für alle betroffenen Dienste verwendet wurde, auf die letzte bekannte gute Version zurückgesetzt. Dadurch wurden die Fehler bei der Ausführung von ARM64 vollständig behoben; es waren keine Änderungen an der Kundenkonfiguration erforderlich. # Nächste Schritte Um zu verhindern, dass sich solche Probleme wiederholen. * Bauen Sie die ARM64 Image Publishing Pipeline neu auf, um unsere dedizierten ARM64 Build-Dateien direkt zu erstellen, anstatt die AMD64 Build-Dateien anzupassen. * Verbessern Sie die automatisierte Post-Publish-Validierung für jede Bildfreigabe: Überprüfen Sie, ob die binäre Architektur mit dem Image-Tag übereinstimmt, und führen Sie einen funktionalen Rauchtest durch, bevor ein Bild als freigebbar gilt. * Erweitern Sie die automatisierte Testabdeckung um ARM64 Kubernetes Build-Szenarien. * Entfernen Sie die betroffenen Zwischenbildversionen aus dem Umlauf, sobald die korrigierte Freigabe validiert ist.
Automatisch aus der offiziellen Störungsmeldung übersetzt.