SUPPORT-PFAD

Problem zuerst eingrenzen, dann ausreichende Diagnosedaten einreichen

Hier finden Sie eine feste Prüfreihenfolge – von der ersten Verbindung bis zur Analyse von Build und Performance. Prüfen Sie zunächst lokales Netzwerk, Zieladresse, Zugangsdaten und Knotenstatus, bevor Sie Toolchain oder Ressourcen untersuchen. So vermeiden Sie wiederholtes Ausprobieren und ermöglichen dem Support eine schnellere Reproduktion.

Ticket in der Konsole einreichen Leitfaden für Remoteverbindungen ansehen Cloud-Mac jetzt mieten
diagnostic-path
01 Lokales Netzwerk prüfen Basisebene
02 Adresse und Authentifizierung prüfen Verbindungsebene
03 Knotenstatus bestätigen Steuerungsebene
04 Aufgabe und Ressourcen messen Aufgabenebene

PFAD FINDEN

Prüfpfad nach Symptomen suchen

Geben Sie Fehlertest, Verbindungsart, Systemaufgabe oder Knotenstatus ein. Die Suche durchsucht nur die sichtbaren Dokumente dieser Seite; Eingaben werden nicht hochgeladen.

7 Support-Pfade anzeigen

Erste Schritte

Was ist vor der ersten Verbindung zu prüfen?

Stellen Sie sicher, dass der Knoten bereit ist, die Zugangsdaten aus der richtigen Quelle stammen und das lokale Netzwerk erreichbar ist. Prüfen Sie außerdem Tastaturbelegung und Zeitzone.

Prüfung dauert etwa 3–5 Minuten Verbindungsproblem

Verbindung läuft ab oder Authentifizierung schlägt fehl

Grenzen Sie nacheinander lokales Netzwerk, Zieladresse, Zugangsdaten, Knotenstatus und Client-Einstellungen ein.

Fünf Prüfebenen der Reihe nach durchlaufen Build-Aufgabe

Probleme mit Xcode, Signierung oder Abhängigkeiten

Fixieren Sie zuerst die Tool-Versionen und prüfen Sie anschließend Signaturmaterial, Abhängigkeits-Cache, freien Speicher und Aufgabenprotokolle.

Vollständige Befehle und Zeitstempel aufbewahren Performance-Diagnose

Build wird langsamer oder reagiert unregelmäßig

Erfassen Sie während des Auftretens synchron CPU, Arbeitsspeicher, Datenträger und Netzwerk. Reichen Sie nicht nur einen einzelnen Moment-Screenshot ein.

Kontinuierliche Messung über 5–10 Minuten empfohlen Ticket eskalieren

Welche Ticketart ist die richtige?

Ordnen Sie das Anliegen Konto, nicht erreichbarem Knoten, Hardwarefehler oder Datenanfrage zu und fügen Sie die jeweils kleinsten erforderlichen Belege bei.

Für bestehende Bestellungen eignet sich ein Konsolenticket Statusbewertung

Regionale Störung oder Fehler eines einzelnen Knotens?

Beschreiben Sie den Einflussbereich anhand eines Vergleichs in derselben Region, Tests über verschiedene Netzwerke und des Konsolenstatus klar.

Erst Einflussbereich bestimmen, dann eskalieren Belege vorbereiten

Welche Informationen sind am hilfreichsten?

Stellen Sie Knoten-ID, Zeitraum, originalen Fehlertext, Reproduktionsschritte und anonymisierte Protokolle zusammen, um Rückfragen zu reduzieren.

Keine Passwörter, privaten Schlüssel oder Projektquellen einreichen

ERSTE SITZUNG

Checkliste für die erste Nutzung: Eine reproduzierbare Verbindungsbasis schaffen

Ändern Sie nicht mehrere Verbindungsparameter gleichzeitig. Dokumentieren Sie das Ergebnis jedes Schritts, damit sich der Fehler der lokalen Umgebung, dem Netzwerk, der Authentifizierung oder dem Knoten zuordnen lässt.

  1. 01

    Knotenstatus bestätigen

    Prüfen Sie in der Konsole, ob der Zielknoten als bereit angezeigt wird, und gleichen Sie Knoten-ID, Region und gewähltes Modell ab. Befindet sich der Knoten noch in der Vorbereitung, darf ein Clientfehler nicht als Verbindungsproblem gewertet werden.

    Abschlusskriterium: Knoten-ID stimmt mit der Bestellung überein und der Status erlaubt Verbindungen.
  2. 02

    Anmeldedaten kopieren

    Kopieren Sie Adresse, Port und Benutzernamen aus den Details des aktuellen Knotens in der Konsole. Verwenden Sie keine alten Tickets, Screenshots oder gespeicherten Daten anderer Knoten. Achten Sie beim Einfügen des Passworts auf Leerzeichen und Vollbreitenzeichen.

    Abschlusskriterium: Adresse, Port und Benutzername stammen aus denselben Knotendetails.
  3. 03

    Lokales Netzwerk prüfen

    Bestätigen Sie zunächst, dass gewöhnlicher HTTPS-Zugriff funktioniert, und testen Sie anschließend Büro- und vertrauenswürdiges Ersatznetzwerk getrennt. Unternehmens-Gateway, Firewall oder Proxy können bestimmte Ports blockieren; eine erreichbare Webseite bedeutet daher nicht automatisch eine erreichbare Remoteverbindung.

    Abschlusskriterium: verwendetes Netzwerk, Gateway-Typ und Fehlerzeit dokumentieren.
  4. 04

    Tastaturbelegung kalibrieren

    Testen Sie nach dem Öffnen der grafischen macOS-Oberfläche zunächst Buchstaben, Zahlen, Sonderzeichen sowie die Zuordnung von Command und Option. Stimmen Sonderzeichen nicht überein, dokumentieren Sie lokale und entfernte Tastaturbelegung.

    Abschlusskriterium: Anführungszeichen, Schrägstriche und Bindestriche lassen sich im Terminal korrekt eingeben.
  5. 05

    Zeitzone und Uhrzeit vereinheitlichen

    Kennzeichnen Sie Aufgabenprotokolle, CI-Aufzeichnungen und Ticketzeiten einheitlich mit der Zeitzone. Bei der Suche nach sporadischen Fehlern lässt sich „14:20“ ohne Zeitzone keinem Knotenereignis zuordnen. Verwenden Sie vollständige Datums- und Zeitangaben mit Zeitzone.

    Abschlusskriterium: Zeiten aus lokaler, Knoten- und Automatisierungsprotokollen sind ineinander umrechenbar.
Speichern Sie nach der ersten erfolgreichen Verbindung eine Basisaufzeichnung ohne vertrauliche Zugangsdaten: Knoten-ID, Region, Verbindungsart, Clientversion, Tastaturbelegung, Zeitzone und Zeitpunkt einer erfolgreichen Verbindung. Spätere Probleme können direkt damit verglichen werden.

ENTSCHEIDUNGSBAUM

Entscheidungsbaum bei Verbindungsproblemen: Pro Schritt nur eine Ebene ausschließen

Ein Timeout deutet meist auf Netzwerk oder Adresse hin; eine fehlgeschlagene Authentifizierung meist auf Benutzername, Passwort, Schlüssel oder Client-Konfiguration. Ordnen Sie zunächst nach Fehlertyp und durchlaufen Sie dann die fünf Prüfebenen.

1

Ist das lokale Netzwerk stabil?

LOKAL

Deaktivieren Sie vorübergehende Proxys, die das Routing verändern, und versuchen Sie es erneut. Führen Sie zusätzlich einen Vergleich über ein vertrauenswürdiges Ersatznetzwerk durch. Funktioniert es im Büronetz nicht, im Ersatznetz aber schon, dokumentieren Sie Gateway-Regeln und betroffene Ports; das Problem sollte zuerst an die lokale Netzwerkadministration gehen.

Voraussetzung zum Fortfahren:Verbindungsversuch zum selben Ziel über mindestens ein vertrauenswürdiges Netzwerk abgeschlossen.

2

Gehören Zieladresse und Port zum aktuellen Knoten?

ZIEL

Kehren Sie zur Konsole zurück und kopieren Sie die Zieldaten erneut. Verwenden Sie keine Adresse aus dem Befehlsverlauf. Für den Remote-Desktop im Browser nutzen Sie den von der Konsole bereitgestellten Einstieg; bei SSH prüfen Sie Host, Port und Benutzername innerhalb desselben Verbindungseintrags.

Abbruchbedingung:Adresse hat sich geändert oder der Eintrag stammt von einem anderen Knoten; nach der Aktualisierung erneut testen.

3

Sind die Zugangsdaten vollständig und von der Eingabemethode unverändert?

AUTH

Prüfen Sie Groß- und Kleinschreibung des Benutzernamens, Leerzeichen vor und nach dem Passwort, Dateiberechtigungen des Schlüssels und die ausgewählte Identitätsdatei. Beim ersten Auftreten eines SSH-Hostschlüssels gleichen Sie den Fingerabdruck mit den Konsolendaten ab. Bei unerwarteten Änderungen pausieren Sie die Verbindung und klären Sie die Ursache über ein Ticket.

Anforderung an Belege:Originalen Fehlertext aufbewahren, aber Passwort, Schlüsselinhalte und vollständige Zugriffsadresse schwärzen.

4

Erlaubt der Knotenstatus in der Konsole eine Verbindung?

KNOTEN

Aktualisieren Sie die Knotendetails und bestätigen Sie Status, Knoten-ID und Zeitpunkt der letzten Änderung. Bei anomalem Status führen Sie nicht wiederholt Neustartaktionen aus. Dokumentieren Sie Zustand vor der Aktion, bereits ausgeführte Schritte und jeden Zeitpunkt, damit die Fehlerlage erhalten bleibt.

Eskalationsbedingung:Knotenstatus anomal oder trotz normalem Status über zwei vertrauenswürdige Netzwerke nicht erreichbar.

5

Verursachen Client-Einstellungen Anzeige- oder Sitzungsprobleme?

CLIENT

Bei einer leeren Browserseite verwenden Sie die aktuelle stabile Browserversion, löschen die Sitzungsdaten dieser Website und versuchen es erneut. Bei falscher Tastaturbelegung reduzieren Sie auf eine einzige Belegung. Bei häufigen SSH-Unterbrechungen deaktivieren Sie zunächst Terminal-Erweiterungen und bauen eine Vergleichssitzung mit Basisbefehlen auf.

Abschlussbedingung:Clientname, Version, Verbindungsart und reproduzierbare Schritte dokumentieren.

Fehler: „Timeout“ oder „nicht erreichbar“

Geben Sie vorrangig Netzwerktyp, Fehlerzeit, Zielregion, Vergleichsergebnisse beider Netzwerke und den Knotenstatus aus der Konsole an. Reichen Sie nicht nur einen Screenshot ohne Zeit und Knoten-ID ein.

Fehler: „Authentifizierung fehlgeschlagen“

Prüfen Sie zuerst Benutzername, Authentifizierungsart und Identitätsdatei des aktuellen Knotens. Im Ticket genügen Authentifizierungsart und originaler Fehlertext. Senden Sie keine Passwörter, privaten Schlüssel oder direkt nutzbaren Zugangsdaten.

BUILD-PIPELINE

Build-Fehlerbehebung: Von den Tool-Versionen nach außen prüfen

Beginnen Sie bei Build-Fehlern mit dem ersten eindeutigen Fehler, nicht mit der zusammenfassenden letzten Zeile. Fixieren Sie zunächst die Toolchain und prüfen Sie danach Signierung, Abhängigkeiten, Speicher und Automatisierungsprozesse.

Xcode-Toolchain

Dokumentieren Sie macOS-Version, Xcode-Version, Pfad der Kommandozeilenwerkzeuge und Build-Befehl. Wenn Oberfläche und Automatisierung unterschiedliche Tool-Pfade verwenden, können auf demselben Knoten abweichende Ergebnisse entstehen.

  • Den tatsächlich verwendeten Xcode-Pfad bestätigen
  • Vollständigen Build-Befehl und Arbeitsverzeichnis aufbewahren
  • Versionsunterschiede zwischen erfolgreicher und fehlgeschlagener Aufgabe vergleichen

Zertifikate und Signierung

Unterscheiden Sie fehlende Zertifikate, nicht passende Profile, unzureichende Berechtigungen und fehlgeschlagenen Schlüsselbundzugriff. Bewahren Sie für die Diagnose Zertifikatsname, Gültigkeit und Fehlertext auf, schwärzen Sie jedoch Zertifikatsdateien, Passwörter und vertrauliche Projektkennungen.

  • Bestätigen, dass der Automatisierungsprozess auf das benötigte Signaturmaterial zugreifen kann
  • Prüfen, ob Ziel, Build-Konfiguration und Signiereinstellungen übereinstimmen
  • Dokumentieren, ob der Fehler beim Archivieren, Exportieren oder Hochladen auftrat

Abhängigkeiten und Cache

Prüfen Sie zuerst, ob sich der Fehler mit der Sperrdatei zuverlässig reproduzieren lässt, und löschen Sie anschließend nur den kleinstmöglichen Cache-Bereich. Das gleichzeitige Löschen aller Abhängigkeits- und Build-Caches vergrößert die Zahl der Variablen und kann das ursprüngliche Problem vorübergehend verschwinden lassen.

  • Gesperrte Abhängigkeitsdateien und Paketmanager-Version aufbewahren
  • Nur direkt mit dem fehlgeschlagenen Ziel verbundene Caches löschen
  • Build-Dauer und Fehler vor und nach der Bereinigung dokumentieren

Datenträger und Automatisierungsprotokolle

Archivierung, Entpacken von Abhängigkeiten und temporäre Artefakte benötigen zusätzlichen Speicher. Die Größe des Projektordners allein reicht nicht aus. Prüfen Sie auch freien Speicher, temporäre Verzeichnisse, Build-Cache und Prozesse, die wegen Ressourcenmangels beendet wurden.

  • Freien Speicher vor und nach dem Fehler dokumentieren
  • Start, Ende und Exit-Code der Aufgabe aufbewahren
  • Mindestens 50 Protokollzeilen vor und nach dem ersten Fehler erfassen

PERFORMANCE-MESSUNG

Performance-Diagnose: Vier Metrikarten im selben Zeitraum erfassen

Ein einzelner CPU-Screenshot erklärt weder Datenträgerwartezeiten noch Speicherdruck oder Netzwerkschwankungen. Erfassen Sie die Daten 5–10 Minuten lang vor und nach dem Problem und markieren Sie Beginn und Fehlerzeit der Aufgabe.

Metrik Mindestens erfassen Zu beobachtende Symptome Mit Aufgabe abgleichen
CPU Gesamtauslastung, wichtigste Prozesse, Messzeit Dauerhafte Auslastung eines Prozesses, plötzlicher Lastanstieg, keine Rückkehr nach Aufgabenende Startzeit von Kompilierung, Linken, Tests oder Inferenz markieren
Arbeitsspeicher Belegter Speicher, Speicherdruck, Auslagerungsbereich Anhaltend steigender Druck, häufiges Swapping, vom System beendete Prozesse Anzahl paralleler Aufgaben und Eingabegröße dokumentieren
Datenträger Freier Speicher, Lese-/Schreibdurchsatz, I/O-Wartezeit Speicher nahezu voll, deutliche Wartezeit beim Entpacken oder Archivieren Abhängigkeits-Download, Build-Cache und Artefaktschreiben unterscheiden
Netzwerk Lokaler Netzwerktyp, Round-Trip-Latenz, Paketverlust Nur bestimmtes Gateway auffällig, Interaktion stockt, Knotenaufgabe normal Remote-Bild, Abhängigkeits-Download und Code-Abruf unterscheiden
MESSUNG

Messung muss den Zeitraum vor und nach dem Fehler abdecken

Erfassen Sie die Basis vor Aufgabenbeginn bis mindestens eine Minute nach dem Fehler. Daten nur aus dem Fehlerzeitpunkt zeigen nicht, ob Ressourcen Ursache oder Folge waren.

VERGLEICH

Eine erfolgreiche Aufgabe zum Vergleich aufbewahren

Führen Sie mit identischem Projekt, identischen Abhängigkeiten und gleicher Parallelität eine erfolgreiche Aufgabe aus. Vergleichen Sie die Zeitabschnitte und Ressourvenkurven, nicht nur die Gesamtdauer.

GRENZE

Interaktions- und Rechenverzögerung unterscheiden

Stockt nur die Remoteanzeige, während die Aufgabe auf dem Knoten stabil bleibt, prüfen Sie zuerst das Netzwerk. Steigt die Laufzeit der Aufgabe selbst, untersuchen Sie CPU, Arbeitsspeicher und Datenträger.

MINIMALE BELEGE

Minimale Diagnosedaten: Probleme reproduzierbar machen

Sie müssen nicht das gesamte Projekt hochladen. Die folgenden Angaben reichen meist für eine erste Einschätzung; fehlende Informationen fordert der Support nach.

  1. 01

    Knoten und Umgebung

    Knoten-ID, Knotenregion, macOS-Version sowie Xcode- oder Clientversion. Keine Passwörter, privaten Schlüssel oder vollständigen Zugangsdaten angeben.

  2. 02

    Genauer Zeitraum

    Verwenden Sie „Datum + Uhrzeit bis auf Sekunden + Zeitzone“ und kennzeichnen Sie erstes, letztes und zuletzt reproduziertes Auftreten.

  3. 03

    Originaler Fehlertext und Exit-Code

    Kopieren Sie durchsuchbaren Text statt nur einen Screenshot hochzuladen. Bewahren Sie Fehlercode, Fehlerphase und den Protokollkontext vor und nach dem ersten Fehler auf.

  4. 04

    Kürzeste Reproduktionsschritte

    Beginnen Sie in einem bekannten Normalzustand und listen Sie Aktionen, Befehle, erwartetes und tatsächliches Ergebnis in Reihenfolge auf. Geben Sie außerdem die Reproduktionswahrscheinlichkeit an.

  5. 05

    Bereits ausgeführte Schritte

    Listen Sie Zeitpunkt und Ergebnis von Netzwerkwechsel, Adressaktualisierung, Cache-Bereinigung oder Neustart der Aufgabe auf, damit die Fehlerlage nicht überschrieben wird.

ESKALATIONSREGELN

Regeln für Ticket-Eskalationen: Nach betroffenem Objekt kategorisieren

Ein Ticket sollte nur ein Hauptproblem beschreiben. Treten Kontozugriff und Knotenfehler gleichzeitig auf, legen Sie getrennte Einträge an, damit sich Bearbeitungsstatus nicht überschreiben.

Kategorie Geeignet für Empfohlene Belege Bevorzugter Kanal
Konto Kein Konsolenzugriff, fehlerhafte Kontodaten oder Probleme bei der Zugriffsprüfung Registrierungs-E-Mail, Zeitpunkt, originaler Seitenfehler, Browserversion Support-E-Mail
Knoten nicht erreichbar Knoten erlaubt Verbindungen, aber weder Browser-Remote-Desktop noch SSH können eine Sitzung aufbauen Knoten-ID, Region, Testergebnisse zweier Netzwerke, Fehlerzeit und Originaltext Konsolenticket
Hardwarefehler Wiederholte unerwartete Neustarts, Speicherfehler oder Ressourcenprobleme, die sich nicht durch eine einzelne Aufgabe erklären lassen Knoten-ID, Zeitraum der Systemprotokolle, Aufgabe vor dem Fehler, Reproduktionshäufigkeit Konsolenticket
Datenanfrage Anfragen zur Freigabe des Knotens, zum Datenexport oder zu Datenschutzrechten Bestell-ID, Umfang der Anfrage, gewünschte Aktion, erforderliche Identitätsprüfung Konsolenticket
Auswirkungsstufe A

Gesamter Knoten nicht erreichbar

Der Knotenstatus erlaubt Verbindungen, doch Browser-Remote-Desktop und SSH sind nach Tests über zwei vertrauenswürdige Netzwerke nicht erreichbar. Geben Sie Knoten-ID, Region und Zeitpunkt der letzten erfolgreichen Verbindung an.

Auswirkungsstufe B

Wichtige Aufgabe blockiert

Der Knoten ist erreichbar, aber Build oder Automatisierung schlagen bei fixierter Toolchain zuverlässig fehl. Reichen Sie ersten Fehler, vollständigen Befehl, Exit-Code und kürzesten Reproduktionsablauf ein.

Auswirkungsstufe C

Konfigurations- und Nutzungsberatung

Der Knoten ist verfügbar; es geht um Tastatur, Auflösung, Abhängigkeits-Cache oder Workflow-Optimierung. Beschreiben Sie aktuelle Konfiguration, Ziel und bereits geprüfte Lösung.

SERVICEKONTINUITÄT

Servicekontinuität und Statusbewertung

Alle Knoten sind für einen regulären Betrieb an 365 Tagen im Jahr ausgelegt. Bei Problemen unterscheiden Sie anhand des Einflussbereichs zwischen regionaler Netzwerkschwankung, Fehler eines einzelnen Knotens und lokalem Verbindungsproblem.

REGION

Regionale Netzwerkschwankung

Bei mehreren Verbindungsquellen derselben Region steigen Latenz oder Paketverlust nahezu gleichzeitig oder Sitzungen werden unterbrochen, während Aufgaben im Knoten weiterlaufen können.

  • Quellstadt, Anbieter und Netzwerktyp dokumentieren
  • Vergleich über ein vertrauenswürdiges Ersatznetzwerk durchführen
  • Startzeit, Dauer und Zielregion angeben
KNOTEN

Fehler eines einzelnen Knotens

Lokales Netzwerk und andere Dienste derselben Region funktionieren, der Zielknoten zeigt jedoch einen anomalen Status, verliert wiederholt die Verbindung oder meldet Systemfehler, die sich nicht durch die Nutzeraufgabe erklären lassen.

  • Knoten-ID und Konsolenstatus sichern
  • Wiederholte Aktionen vermeiden, die den Zustand verändern könnten
  • Bestellung über ein Konsolenticket verknüpfen
LOKAL

Lokales oder Clientproblem

Der Zielknoten ist über ein Ersatznetzwerk oder einen anderen Client erreichbar; nur ein Büro-Gateway, eine Browserkonfiguration oder ein SSH-Client schlägt fehl.

  • Unterschiede zwischen fehlerhafter und erfolgreicher Umgebung vergleichen
  • Proxy, Firewall und Clientversion prüfen
  • Probleme mit Netzwerkregeln an die lokale Administration geben

Status mit überprüfbaren Fakten beschreiben

Empfohlene Formulierung

„Knoten SG-Beispiel ist seit 2026-08-08 14:20 +0800 nicht mehr per SSH erreichbar; Heim- und Büronetzwerk laufen in einen Timeout, der Konsolenstatus erlaubt weiterhin Verbindungen.“

Vage Beschreibungen vermeiden

Schreiben Sie nicht nur „Der Server ist kaputt“, „Das Netzwerk ist langsam“ oder „Die Verbindung bricht gelegentlich ab“. Ohne Knoten, Zeit, Netzwerkquelle und Originalfehler lässt sich der Einflussbereich nicht bestimmen.

KURZANTWORTEN

Häufige Fragen vor einer Supportanfrage

Was ist der erste Schritt, wenn ein Knoten nicht erreichbar ist?

Bestätigen Sie in der Konsole zuerst Knoten-ID und Status, kopieren Sie anschließend Adresse, Port und Benutzername erneut aus den Details des aktuellen Knotens. Führen Sie danach einen Vergleich über ein vertrauenswürdiges Ersatznetzwerk durch. Führen Sie nicht mehrere statusverändernde Aktionen aus, bevor der Ausgangszustand dokumentiert ist.

Muss ich bei einem fehlgeschlagenen Build das vollständige Protokoll einreichen?

Reichen Sie bevorzugt mindestens 50 Zeilen vor und nach dem ersten Fehler, den vollständigen Build-Befehl, Exit-Code, Xcode-Version und Zeitpunkt ein. Enthält das Protokoll Projektpfade, Repository-Adressen oder Signaturinformationen, anonymisieren Sie es zuerst. Entfernen Sie keine Fehlercodes oder Zeitstempel.

Warum reicht ein einzelner Performance-Screenshot meist nicht aus?

Ein Screenshot zeigt nur einen Moment und nicht, ob die Ressourcenänderung vor oder nach der Aufgabe auftrat. Erfassen Sie CPU, Arbeitsspeicher, Datenträger und Netzwerk 5–10 Minuten lang und markieren Sie Beginn, Fehler und Ende der Aufgabe.

Soll ich eine E-Mail senden oder ein Konsolenticket einreichen?

Bestehende Bestellungen sowie Anfragen zu Knoten, Hardware und Daten sollten zur Verknüpfung mit Bestell- und Knotendaten über die Konsole eingereicht werden. Bei Kontoproblemen ohne Konsolenzugriff schreiben Sie an support@macworker.com. Diese beiden Kontaktwege stehen zur Verfügung.

Welche Inhalte gehören nicht in ein Ticket oder eine E-Mail?

Senden Sie keine Passwörter, privaten Schlüssel, Zahlungsdaten, vollständigen Zugriffsadressen oder Projektquellen. Vertrauliche Werte in Protokollen dürfen geschwärzt werden; Feldnamen, Versionen, Fehlercodes, Zeitstempel und Reihenfolge der Aufrufe müssen erhalten bleiben.

BEREIT ZUR ESKALATION

Sind Knoten-ID, Zeitpunkt und Originalfehler vorhanden?

Verknüpfen Sie die bestehende Bestellung über ein Konsolenticket und senden Sie die kürzesten Reproduktionsschritte sowie anonymisierte Protokolle. Wenn Sie noch keinen Knoten gemietet haben, öffnen Sie zunächst das Portal und wählen Sie Konfiguration, Region und Laufzeit des exklusiven physischen Rechners.

Ticket in der Konsole einreichen Cloud-Mac-Mietoptionen ansehen