Leitfaden zur Fehlerbehebung für iOS-, macOS-, CI/CD- und Apple-Silicon-Workloads. Zuerst Knoten und Netzwerk prüfen, dann Toolchain und Aufgaben-Logs – ohne mehrere Variablen gleichzeitig zu ändern.
Das Dashboard zeigt die Knoteninformationen der aktuellen Bestellung. Beim Kopieren von Feldern das Originalformat beibehalten und Adresse, Benutzername oder Port nicht erraten.
Im Dashboard anmelden und Bestellung, Region, Hostadresse, Benutzername sowie zulässige Verbindungsmethoden prüfen. Der Knoten befindet sich in Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, der US-Ostküste oder der US-Westküste.
Sicherstellen, dass das Büronetzwerk den Zielport nicht blockiert, temporäre Routing-Proxys deaktivieren und die Verbindungsergebnisse über kabelgebundene, drahtlose und andere Netzwerke getrennt dokumentieren.
Für Kommandozeile, Dateisynchronisierung und Automatisierung bevorzugt SSH verwenden; für die grafische macOS-Oberfläche VNC nutzen. Beim ersten Test nur eine Verbindung herstellen, damit sich die Ergebnisse nicht gegenseitig beeinflussen.
Nach der Anmeldung Systemversion, freien Speicherplatz, Xcode-Pfad und aktuelle Netzwerkzeit dokumentieren. Zuerst ein Minimalprojekt ausführen und erst danach das vollständige Projekt sowie Build-Caches übernehmen.
Keine Projekte im großen Umfang hochladen, Systemeinstellungen ändern oder einen CI-Runner registrieren, bevor die Verbindung stabil ist. Zuerst eine reproduzierbare Baseline sichern.
Bei Verbindungsfehlern von den Zugangsdaten aus schrittweise nach außen bis zum Netzwerk vorgehen. Pro Schritt nur eine Bedingung ändern und Befehlsausgaben oder Fehlermeldungen sichern.
Prüfen, ob Benutzername, Schlüssel oder Verbindungspasswort aus der aktuellen Bestellung stammen; Daten beendeter Bestellungen nicht wiederverwenden. Dateirechte des Schlüssels kontrollieren und sicherstellen, dass beim Kopieren keine Leerzeichen oder Zeilenumbrüche hinzugekommen sind.
Mit dem im Dashboard angezeigten Port einen Verbindungstest ausführen. Ein Timeout weist meist auf den Netzwerkpfad hin; eine sofortige Ablehnung bedeutet in der Regel, dass das Ziel erreichbar ist, aber Dienst oder Port nicht passen.
Terminal-Sicherheitssoftware, Richtlinien am Unternehmensausgang und Routerregeln prüfen. Ein erneuter Test über ein anderes, bekanntermaßen funktionierendes Netzwerk trennt lokale Einschränkungen schnell von Problemen auf dem Knoten.
Latenz, Jitter und Paketverlust dokumentieren, statt nur einen einzelnen Ping zu betrachten. VNC reagiert empfindlicher auf anhaltenden Jitter; auch SSH-Builds können durch zurückgesetzte Download-Verbindungen abbrechen.
Im Dashboard Instanz- und Bestellstatus prüfen. Wenn die Verbindung über verschiedene Netzwerke trotz korrekter Zugangsdaten nicht möglich ist, Zeitpunkt und Originalfehler sichern und ein Ticket zur Knotenstörung einreichen.
Derselbe Commit kann mit unterschiedlichen Toolchains zu verschiedenen Ergebnissen führen. Systemumgebung und Projektabhängigkeiten getrennt prüfen, um Knoten-, Toolchain- und Repository-Probleme zu unterscheiden.
xcodebuild -version und Xcode- sowie Build-Version notieren.xcode-select -p und prüfen, ob Command Line Tools auf das erwartete Verzeichnis zeigen.sw_vers
xcodebuild -version
xcode-select -p
df -h
Eine erfolgreiche Runner-Registrierung bedeutet nicht, dass der Workflow sicher reproduzierbar ist. Ausführungsumfang, Arbeitsverzeichnis, Zugangsdaten und Parallelisierungsstrategie müssen gemeinsam umgesetzt werden.
Kurzlebige Registrierungsdaten des Projekts oder der Organisation verwenden und Tags für Chip, Region und Zweck festlegen. Nach der Registrierung lokale temporäre Befehlsprotokolle löschen.
Ergebnis: Runner-Name und Tag-ListeNur vertrauenswürdige Repositorys, geschützte Branches und ausdrücklich freigegebene Workflows dürfen den Knoten aufrufen. Durch externe Beiträge ausgelöste Aufgaben prüfen und unbekannte Skripte niemals direkt mit Knotenrechten ausführen.
Ergebnis: Freigaberegeln für Repositorys und BranchesTemporäre Dateien, abgeleitete Daten und ungültige Caches vor und nach Aufgaben bereinigen. Bei aufbewahrten Caches Schlüssel, Quelle und Ablaufbedingungen dokumentieren, damit alte Artefakte neue Builds nicht verfälschen.
Ergebnis: Bereinigungsskript und Cache-StrategieToken, SSH-Schlüssel und Signierungsmaterial über einen kontrollierten Secret-Prozess verwalten. Bei Teamabgängen, geänderten Repository-Berechtigungen oder auffälligen Logs sofort widerrufen und neu ausstellen.
Ergebnis: Verantwortliche für Zugangsdaten und RotationsprotokollNicht nur den allgemeinen Exitcode am Ende des Logs ausschneiden. Das vollständige Log sichern und ab dem ersten Fehler nach oben lesen, um Ziel, Befehl und Abhängigkeitskontext zu erfassen.
| Fehlerkategorie | Häufige Log-Signale | Zuerst prüfen | Dem Ticket beifügen |
|---|---|---|---|
| Abhängigkeitsauflösung | Konflikt bei Paketversionen, Abruf des Repositorys fehlgeschlagen, Lockfile inkonsistent | Lockfile, Abhängigkeitsquelle, Cache-Schlüssel und Ergebnis des Netzwerkdownloads | Methode der Abhängigkeitsverwaltung, Name des fehlgeschlagenen Pakets, erster Fehlerabschnitt |
| Signierungskonfiguration | Zertifikat passt nicht, Berechtigung nicht verfügbar, Konfigurationsvariable fehlt | Scheme, Build-Konfiguration und Ablauf der Secret-Injektion | Bereinigter Originalfehler und Build-Ziel |
| Testfehler | Assertion fehlgeschlagen, Unterschiede in der simulierten Umgebung, Test-Timeout | Fehlgeschlagener Test, Destination, Parallelisierungsparameter und Wiederholungsergebnis | Testname, Exitcode, reproduzierbarer Befehl |
| Netzwerkdownload | Verbindung zurückgesetzt, Auflösung fehlgeschlagen, Download-Timeout | Wiederholte Anfragen an dieselbe Adresse, DNS, Proxy und Ausgangspfad | Zeitpunkt, Zieltyp und Ergebnis des Netzwerktests |
Vollständiges Original-Log sichern
Ersten aussagekräftigen Fehler finden
Mit einem Minimalbefehl unabhängig reproduzieren
Nach dem Entfernen von Zugangsdaten einen Auszug einreichen
Mehr Kapazität ersetzt weder Datenklassifizierung noch Backups. Zuerst festlegen, welche Inhalte erhalten bleiben müssen, und anschließend Synchronisierung, Caching und Auslagerung bestimmen.
Quellcode bevorzugt über das Versionsrepository synchronisieren; große Binärdateien und private Abhängigkeiten über einen kontrollierten Speicherprozess verwalten. Nach der ersten Migration Commit-Hash, Submodule und Lockfiles vergleichen.
DerivedData, Paket-Caches und das Runner-Arbeitsverzeichnis können die Reproduzierbarkeit beeinflussen. Vor dem Löschen Verzeichnisgröße und Cache-Schlüssel dokumentieren, danach Build-Zeit und Fehleränderungen vergleichen.
Die zusätzliche SSD dient Projekten, Caches oder Datensätzen mit höherem Speicherbedarf. Mountpoint, Lese-/Schreibpfade und Aufgabenberechtigungen vor dem produktiven Einsatz prüfen.
Projektdateien, Signierungsmaterial, Zugangsdaten und Build-Artefakte gemäß Teamrichtlinien sichern. Vor Ablauf der Mietdauer auslagern und die Lesbarkeit der Kopien prüfen; die einzige Kopie auf dem Knoten ist kein Langzeitarchiv.
Je konkreter die Supportanfrage, desto schneller lassen sich Reproduktion und Ursache bestimmen. Zuerst die Auswirkungen, dann Zeitachse und minimale Logs angeben – niemals Geheimwerte senden.
Passwörter, private Schlüssel, Wiederherstellungscodes, vollständige Token, Signierungsmaterial und vollständige Zahlungsdaten. Geheimwerte in Logs vor dem Senden löschen oder durch eine eindeutige Schwärzungsmarkierung ersetzen.
Im Dashboard ein Ticket erstellen und die passende Bestellung auswählen. So kann der Support den richtigen Knoten und die zugehörigen Servicedaten prüfen.
Im Dashboard ein Ticket erstellenVerbindungsabbrüche, Knotenstörungen und Abrechnungsfragen erfordern unterschiedliche Nachweise. Die richtige Kategorie wählen und zusätzliche Unterlagen in derselben Sitzung ergänzen, damit der Kontext erhalten bleibt.
Lokalen Netzwerktyp, Zielporttest, Originalfehler und Zeitpunkt beifügen. Wenn der Wechsel zu einem anderen Netzwerk die Verbindung wiederherstellt, den Unterschied zwischen beiden Tests angeben.
Kategorie: Verbindung und ZugriffAuswirkungsbereich, letzten erfolgreichen Zeitpunkt, Instanzstatus und reproduzierbaren Minimalbefehl angeben. Nicht durch wiederholte Neustarts oder umfangreiche Konfigurationsänderungen den ursprünglichen Zustand überschreiben.
Kategorie: KnotenbetriebBestellkennung, Abrechnungszeitraum, relevante Zusatzoptionen und Problembeschreibung angeben. Alle Bestellungen werden in US-Dollar (USD) abgerechnet; keine vollständigen Zahlungsdaten im Ticket senden.
Kategorie: Bestellung und AbrechnungBearbeitungsstand, Rückfragen und abschließende Ergebnisse im zugehörigen Dashboard-Ticket aktualisieren. Bei neuen Logs Erfassungszeitpunkt und zwischenzeitliche Änderungen angeben, damit Ergebnisse verglichen werden können.
Bei einer neuen Bestellung stehen zwei Konfigurationen und sechs Knoten zur Auswahl; bei Problemen mit bestehenden Bestellungen im Dashboard ein verknüpftes Ticket einreichen.