Einstieg in den Engineering-Support

Fehler zuerst eingrenzen, dann reproduzierbare Informationen einreichen

Hier finden Sie gebündelte Hilfe zu Verbindungs-, System-, Build-, Netzwerk-, Speicher- und Kontoproblemen bei Cloud-Macs. Führen Sie zunächst die grundlegenden Prüfungen in der angegebenen Reihenfolge durch und dokumentieren Sie anschließend Knoten, Zeitpunkt und bereinigte Protokolle. So lassen sich meist mehrere Rückfragen vermeiden.

Konsolen-Ticket einreichen Kontaktmöglichkeiten anzeigen

Problemzuordnung

Beginnen Sie bei dem Schritt, an dem das Symptom auftritt

Ändern Sie nicht mehrere Variablen gleichzeitig. Passen Sie pro Durchgang nur Verbindungsart, Client-Einstellungen, Build-Parameter oder Netzwerkpfad an und bewahren Sie die Ergebnisse davor und danach auf.

Verbindung

Anmeldedaten werden abgelehnt, Ports sind nicht erreichbar, die Anzeige verhält sich fehlerhaft, Eingaben reagieren verzögert oder die Sitzung bricht ab.

Verbindungsprüfung öffnen

System

Grafiksitzung, Berechtigungen, Laufwerkseinbindung, Zeiteinstellungen oder Prozessstatus weichen von der Erwartung ab.

Systemstatus prüfen

Build

Runner offline, Warteschlange blockiert, Abhängigkeits-Cache ungültig, Signierumgebung oder Paketierung fehlgeschlagen.

Build-Prüfung öffnen

Netzwerk

Paketverlust, Jitter, fehlerhafte DNS-Auflösung, veränderter Pfad oder instabile Up- und Download-Leistung.

Diagnosewerkbank öffnen

Speicher

Kapazitätsplanung, Erkennung einer zusätzlichen SSD, Cache-Bereinigung, Backups und Migration vor Ende der Laufzeit.

Speicher und Daten prüfen

Konto

Bestellkennung, Zugangsdaten, Abrechnungsdaten, Zahlungsergebnis oder Konsolenaktionen müssen geprüft werden.

Supportanfrage vorbereiten

Fehlerbehebung bei Remote-Verbindungen

Verbindung, Datenpfad und Sitzung in dieser Reihenfolge prüfen

Prüfen Sie zuerst, ob das Verbindungsziel korrekt ist, und kontrollieren Sie anschließend Port und Client. Setzen Sie Zugangsdaten nicht wiederholt zurück, um Probleme auf Netzwerk- oder Sitzungsebene zu verdecken.

01

Bereitstellungsdaten und Zugangsdaten abgleichen

Kopieren Sie Hostadresse, Port und Benutzernamen der aktuellen Instanz aus der Konsole und stellen Sie sicher, dass keine alten Bestelldaten verwendet werden. Prüfen Sie Eingabemethode, Groß- und Kleinschreibung, Leerzeichen am Anfang und Ende sowie das Ergebnis der automatischen Vervollständigung durch den Passwortmanager. Fügen Sie Passwörter, private Schlüssel oder vollständige Verbindungszeichenfolgen weder Screenshots noch dem Tickettext hinzu.

02

Port-Erreichbarkeit prüfen

Verwenden Sie im lokalen Terminal nc um den angegebenen Port zu prüfen. Eine erfolgreich aufgebaute TCP-Verbindung bestätigt nur die Erreichbarkeit des Ports, nicht die Funktionsfähigkeit der Grafiksitzung. Bei einem Timeout dokumentieren Sie zusätzlich lokales Netzwerk, Netzbetreiber und Zielknoten.

nc -vz "$TARGET_HOST" "$TARGET_PORT"
03

Bildschirmfreigabestatus prüfen

Stellen Sie sicher, dass die Instanz läuft, der Grafiksitzungsdienst verfügbar ist und das aktuelle Konto über die Berechtigung für Remote-Sitzungen verfügt. Wenn die Befehlszeile erreichbar ist, die Anzeige jedoch nicht aufgebaut werden kann, beschränken Sie die Suche auf Grafikdienst, Client-Aushandlung oder zurückgebliebene Sitzung, statt weiter die Netzwerkkonfiguration zu ändern.

04

Anzeigeparameter zum Vergleich reduzieren

Stellen Sie zunächst mit einem Monitor, niedrigerer Auflösung und geringerer Bildqualität eine Basis her. Stellen Sie Skalierung, Farbqualität und Multi-Monitor-Einstellungen anschließend einzeln wieder her. Läuft die niedrige Auflösung stabil, bei hoher Auflösung jedoch ruckelig, erfassen Sie zusätzlich Latenz, Paketverlust und Client-Codierung.

05

Alte Sitzungen beenden und erneut verbinden

Beenden Sie den Client ordnungsgemäß, warten Sie, bis die alte Verbindung freigegeben ist, und bauen Sie die Sitzung anschließend neu auf. Vermeiden Sie mehrere Clients gleichzeitig an derselben Grafiksitzung. Wenn der Abbruch erneut auftritt, notieren Sie die minutengenaue Uhrzeit, die Client-Version, einen eventuellen Netzwerkwechsel und ob die Befehlszeilenverbindung ebenfalls betroffen war.

Schnellprüfung auf Systemebene: Wenn Sie die Befehlszeile erreichen, prüfen Sie nacheinander Systemzeit, freien Speicher, Speicherdruck und Prozesse mit hoher Auslastung. Eine Zeitabweichung kann Zertifikate und Build-Signaturen beeinträchtigen; zu wenig Speicher zeigt sich häufig bei der Installation von Abhängigkeiten, beim Schreiben des Caches oder beim Archivieren.

CI/CD-Fehlerbehebung

Fehler auf Runner, Umgebung oder Auftrag eingrenzen

Führen Sie zunächst einen minimalen Auftrag aus, der weder Projektschlüssel liest noch Abhängigkeiten installiert. Erst wenn dieser erfolgreich ist, fügen Sie Repository, Cache, Signiermaterial und Archivierung Schritt für Schritt hinzu.

Runner

Registrierung und Online-Status

Prüfen Sie, ob der Runner beim richtigen Projekt oder in der richtigen Organisation registriert ist, die Labels übereinstimmen und der Executor online ist. Bleibt ein Auftrag dauerhaft in der Warteschlange, prüfen Sie zuerst Labels und Parallelitätslimits und anschließend den Runner-Prozess, statt die vollständige Pipeline direkt erneut zu starten.

ps aux | grep -i runner
launchctl list | grep -i runner
Signing

Signierumgebung

Stellen Sie sicher, dass Konto des Build-Prozesses, Schlüsselbund-Suchpfad, Sichtbarkeit der Zertifikate und Gültigkeitsbereich des Bereitstellungsprofils übereinstimmen. Protokolle sollten nur Zertifikatsnamen, Fehlerphase und Fehlermeldung enthalten. Entfernen Sie vor dem Einreichen Passwörter, private Schlüssel und vollständiges Signiermaterial.

security list-keychains
security find-identity -v -p codesigning
Cache

Cache-Verzeichnisse

Legen Sie Abhängigkeits-Cache, abgeleitete Daten und endgültige Artefakte in getrennten Verzeichnissen ab. Bei ungewöhnlichen Cache-Treffern notieren Sie zunächst Cache-Schlüssel und Verzeichnisbelegung und bereinigen Sie dann nur das betroffene Projekt, damit Vergleichsdaten erhalten bleiben.

du -sh "$CACHE_PATH"
df -h
find "$CACHE_PATH" -maxdepth 1 -type d
Queue

Build-Warteschlange

Dokumentieren Sie Beginn der Wartezeit, tatsächlichen Start und Ende und unterscheiden Sie zwischen „Auftrag wurde nicht übernommen“ und „Auftrag wurde gestartet, liefert aber lange keine Ausgabe“. Im ersten Fall prüfen Sie vor allem Labels, Parallelität und Runner-Status, im zweiten wartende Skripte, Netzwerkabhängigkeiten und Unterprozesse.

Logs

Protokolle erfassen

Bewahren Sie mindestens 50 Protokollzeilen vor und nach dem fehlgeschlagenen Schritt auf und ergänzen Sie Exit-Code, Tool-Version und die kleinsten im Projekt veröffentlichbaren Reproduktionsparameter. Reichen Sie nicht nur einen Screenshot des Fehlerdialogs ein und laden Sie kein vollständiges Protokollpaket mit Token, Repository-Zugangsdaten oder Geschäftsdaten hoch.

xcodebuild -version
sw_vers
uname -m
Retry

Fehler erneut versuchen

Speichern Sie nach dem ersten Fehler zunächst die Originalprotokolle und wiederholen Sie den Lauf einmal mit demselben Commit und denselben Parametern. Bei Erfolg vergleichen Sie Netzwerkanfragen, Cache-Treffer und Laufzeit. Bei stabilem Fehlschlag grenzen Sie auf einen einzelnen Befehl ein und dokumentieren Eingabe, Exit-Code und Dauer.

Netzwerkdiagnosewerkbank

Dasselbe Ziel fortlaufend messen

Ein einzelner Ping sagt nichts über die Leitungsqualität aus. Erfassen Sie während des Problems und nach der Wiederherstellung jeweils eine Messreihe und lassen Sie lokales Netzwerk, Zieladresse und Befehlsparameter unverändert.

Latenz und Paketverlust

Senden Sie 20 Pakete hintereinander und speichern Sie Minimum, Durchschnitt, Maximum und Paketverlustquote.

ping -c 20 "$TARGET_HOST"

Routenpfad

Anhand des Routenverlaufs lässt sich erkennen, ab welchem Hop sich die Latenz verändert. Dass einzelne Router auf die Messung nicht antworten, bedeutet nicht automatisch einen Verbindungsabbruch.

traceroute "$TARGET_HOST"

DNS-Abfrage

Dokumentieren Sie Auflösungsergebnis, Antwortzeit und aktuell verwendeten DNS-Server, um DNS-Probleme von Problemen am Zielport zu unterscheiden.

dig "$TARGET_HOST"
scutil --dns

Up-/Download und Reaktionsfähigkeit

Erfassen Sie mit den in macOS integrierten Tools Up- und Download-Kapazität, Reaktionsfähigkeit und Leerlauflatenz. Pausieren Sie während der Messung die Synchronisierung großer Dateien und andere bandbreitenintensive Aufgaben.

networkQuality -v
Internationale Verbindungen schwanken je nach Netzbetreiber-Routing und Auslastung des lokalen Netzwerks. Wählen Sie Knoten nicht nur nach der Luftlinienentfernung aus. Testen Sie verfügbare Ziele in Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong separat und berücksichtigen Sie anschließend Teamstandort und wichtigste Arbeitszeiten.

Speicher und Datenverwaltung

Quellcode, Cache, Artefakte und Backups trennen

Speicherprobleme bestehen meist nicht nur aus einer Kapazitätszahl. Verzeichnisgrenzen, Schreibberechtigungen, wiederherstellbare Kopien und Migrationsdauer sollten vor dem ersten Build festgelegt werden.

Arbeitsverzeichnisse planen

  • Das Quellcodeverzeichnis enthält nur Repository-Inhalte und erforderliche Konfigurationen; große Build-Artefakte gehören nicht hinein.
  • Abhängigkeits-Cache und abgeleitete Daten in getrennten Verzeichnissen speichern, um sie projektweise zu bereinigen und die Belegung zu analysieren.
  • Archive, Installationspakete und Debug-Symbole in einem mit der Auftragskennung versehenen Artefaktverzeichnis ablegen.
  • Für temporäre Dateien Bereinigungsregeln festlegen und vor der Bereinigung prüfen, dass kein Build läuft.

Verantwortung für Backups auf Anwendungsebene

  • Für Quellcode, Datenbanken, Signiermaterial und nicht regenerierbare Artefakte unabhängige Kopien erstellen.
  • Regelmäßig prüfen, ob Backups gelesen werden können. „Auftrag hochgeladen“ ersetzt keinen Wiederherstellungstest.
  • Schlüssel und Zugangsdaten kontrolliert speichern und nicht in Repositorys, Build-Protokollen oder gemeinsam genutzten Verzeichnissen ablegen.
  • Vor Ablauf der Laufzeit exportieren und Dateianzahl, Prüfsummen sowie Lesbarkeit am Ziel prüfen.

Zusätzliche SSD erkennen

Prüfen Sie nach dem Hinzufügen von zusätzlichem Speicher zunächst, ob das System das Gerät erkennt, das Volume eingebunden und das Dateisystem beschreibbar ist, bevor Sie das Build-Verzeichnis ändern. Wechseln Sie Cache- oder Artefaktpfade nicht während eines laufenden Auftrags.

diskutil list
df -h
mount

Prüfung vor der Migration

  • Beenden Sie Builds, Synchronisierungen und Hintergrundaufgaben, die weiterhin Daten schreiben.
  • Kopieren Sie zunächst eine kleine Stichprobe, um Berechtigungen, Dateinamen und den Umgang mit symbolischen Links zu prüfen.
  • Vergleichen Sie nach der vollständigen Migration Verzeichnisgröße, Dateianzahl und Prüfsummen wichtiger Dateien.
  • Führen Sie in der Zielumgebung zunächst einen Lese- oder Build-Test durch, bevor Sie das ursprüngliche Verzeichnis bereinigen.

Serviceverfügbarkeit

Auswirkungen anhand kontinuierlicher Messungen prüfen

Statusaufzeichnungen helfen, den Umfang serverseitiger Auswirkungen zu bestimmen. Maßgeblich für Messfenster, Ausschlüsse, Voraussetzungen, Servicegutschriften und Geltungsbereich sind die Servicebedingungen.

Zielverfügbarkeit
99.9%

Der Knoten läuft 365 Tage im Jahr durchgehend normal. Auswirkungen durch höhere Gewalt, eigene Nutzeraktionen, das nutzerseitige Netzwerk oder die Konfiguration der Arbeitslast werden bei der Plattformverfügbarkeit nicht berücksichtigt.

Täglicher Status der letzten 90 Tage 90 TAGE
Normal Beeinträchtigung erfasst

Wenn Sie glauben, dass eine Bestellung von einem plattformseitigen Serviceereignis betroffen war, bewahren Sie Bestellkennung, Knoten, Zeitpunkt der ersten Feststellung, Wiederherstellungszeit und kontinuierliche Messungen auf und reichen Sie diese über ein Konsolen-Ticket ein. Ob die Voraussetzungen für eine Servicegutschrift erfüllt sind und wie diese erfolgt, richtet sich nach den konkreten Regeln der Servicebedingungen.

Servicebedingungen anzeigen

Supportanfrage einreichen

Den für die Prüfung erforderlichen Kontext vollständig bereitstellen

Organisieren Sie jede Supportanfrage um ein einzelnes Problem. Beschreiben Sie unterschiedliche Knoten, Bestellungen oder Fehlerphasen getrennt, damit sich die Zeitverläufe nicht überschneiden.

Sechs erforderliche Informationen

  1. 01
    Bestellkennung

    Geben Sie die Bestell- oder Instanzkennung aus der Konsole an. Senden Sie keine Kontopasswörter.

  2. 02
    Zielknoten

    Geben Sie ausdrücklich Singapur, Japan (Tokio), Südkorea (Seoul) oder Hongkong an.

  3. 03
    Zeitpunkt des Fehlers

    Nennen Sie Datum, Zeitzone, Beginn, Dauer und ob der Fehler bereits behoben ist.

  4. 04
    Erwartetes und tatsächliches Ergebnis

    Beschreiben Sie getrennt, was passieren sollte und was tatsächlich zu sehen war. Schreiben Sie nicht nur „nicht nutzbar“.

  5. 05
    Reproduktionsschritte

    Führen Sie die kürzesten Schritte vom Normalzustand bis zum Auftreten des Fehlers auf und geben Sie an, ob er sich beim Wiederholen zuverlässig reproduzieren lässt.

  6. 06
    Bereinigte Protokolle

    Fügen Sie Protokolle vor und nach dem fehlerhaften Schritt, Exit-Codes der Befehle und erforderliche Screenshots bei. Entfernen Sie Token, Passwörter, private Schlüssel, Zahlungsdaten und Geschäftsdaten.

Wie werden Protokolle bereinigt?

Behalten Sie Fehlercode, Zeitpunkt, Befehlsnamen, Tool-Version, Pfadstruktur und Exit-Code bei. Ersetzen Sie Zugriffstoken, Passwörter, private Schlüssel, Zugangsdaten in Repository-Adressen, echte Namen und Geschäftsdaten. Suchen Sie nach der Bereinigung erneut nach gängigen Schlüsselpräfixen und E-Mail-Adressen.

Welche Ergebnisse müssen Netzwerkproblemen mindestens beigefügt werden?

Fügen Sie mindestens eine kontinuierliche Ping-Messung, einen Traceroute, den Zeitpunkt des Problems, den Zielknoten sowie lokale Stadt und Netzbetreiber bei. Geben Sie außerdem an, ob sich das Ergebnis nach einem Wechsel zu Kabel, WLAN oder mobilem Hotspot verändert hat.

Muss bei einem fehlgeschlagenen Build das vollständige Projekt hochgeladen werden?

In der Regel nicht. Stellen Sie zunächst den fehlgeschlagenen Befehl, Exit-Code, Protokolle davor und danach, Tool-Version und minimale Reproduktionsschritte bereit. Falls ein Beispiel erforderlich ist, entfernen Sie Geschäftscode, Schlüssel, Signiermaterial und Produktionsdaten und behalten Sie nur die kleinste Struktur, mit der sich das Problem reproduzieren lässt.

Einreichung vorbereiten

Bestellung, Knoten, Zeitverlauf und bereinigte Protokolle beifügen

Probleme zu bestehenden Bestellungen sollten vorrangig über ein Konsolen-Ticket eingereicht werden. Allgemeine Anfragen können per Support-E-Mail gestellt werden. Vollständiger Kontext ermöglicht es dem Engineering-Team, die Prüfung direkt mit verwertbaren Daten zu beginnen.

Konsolen-Ticket einreichen Kontaktinformationen anzeigen