Ordnen Sie das Problem zunächst den Bereichen Verbindung, Entwicklungsumgebung, CI/CD, Speicher, Netzwerk oder Kontoverwaltung zu. Prüfen Sie anschließend Status, Parameter und Protokolle in einer festen Reihenfolge. Oakmini stellt dedizierte physische Mac-mini-Knoten bereit, keine virtuellen Maschinen. Prüfen Sie lokale Verbindungsbedingungen, Knotenstatus und Projekt-Toolchain getrennt.
$ uname -m
arm64
$ sw_vers -productVersion
macOS ready
$ ssh -v oak-node
debug1: Authentication succeeded
$ df -h /
Filesystem status: availableÄndern Sie Netzwerk, Zugangsdaten und Toolversionen nicht gleichzeitig. Wählen Sie zunächst das passendste Symptom, prüfen Sie pro Schritt nur eine Variable und protokollieren Sie Zeitpunkt, Aktion und Ergebnis. So vermeiden Sie, dass eine Änderung ein anderes Problem verdeckt.
Geeignet bei SSH-Timeouts, schwarzem VNC-Bildschirm, abgelehnten Zugangsdaten oder sofortigen Verbindungsabbrüchen.
Mit dem Hoststatus beginnenGeeignet bei abweichenden Xcode-Pfaden, Homebrew-Paketen, Git-Konfigurationen, Fastlane- oder Laufzeitversionen.
Pfade und Versionen abgleichenGeeignet bei Offline-Runnern, nicht passenden Labels, langen Warteschlangen, fehlerhaften Caches oder unvollständigen Build-Ausgaben.
Mit dem Registrierungsstatus des Runners beginnenGeeignet bei knappem Speicherplatz, wachsenden Caches, unübersichtlichen Arbeitsverzeichnissen oder nicht exportierbaren Build-Artefakten.
Kapazität, Verzeichnisse und Belegung prüfenGeeignet bei hoher Interaktionslatenz, sporadischem Paketverlust, langsamen Dateiübertragungen oder Zugriff nur aus bestimmten lokalen Netzwerken.
Verbindungen und Zeiträume vergleichenGeeignet bei Auftragszuordnung, Hostberechtigungen, Verlängerungsstatus oder nicht aktualisierten Konsolenaktionen.
Auftrag und Aktionsprotokoll zuerst prüfenVerwenden Sie df -h zur Anzeige der Volume-Kapazität und anschließend du -sh zur Prüfung von Projekten, Build-Caches und Exportverzeichnissen. Stellen Sie vor dem Löschen sicher, dass Artefakte gesichert sind, und leeren Sie unbekannte Systemverzeichnisse nicht direkt.
Erfassen Sie separat die Dauer für SSH-Verbindung, VNC-Bedienung, Codeabruf und lokalen Build. Ist nur die grafische Oberfläche langsam, reduzieren Sie zunächst die VNC-Qualität. Sind Befehlszeile und Übertragung gleichzeitig betroffen, prüfen Sie lokale Verbindung und Knotenerreichbarkeit.
Prüfen Sie angemeldetes Konto, Auftragskennung, ausgewählte Region und Zeitpunkt der letzten Aktion. Hoststatus, Aufträge und Verwaltungsaktionen werden vollständig in der Konsole bearbeitet. Übermitteln Sie im Supportfall nur die Auftragskennung, niemals Zugangsdaten.
Verbindungsfehler treten meist auf einer der Ebenen Hoststatus, lokales Netzwerk, Verbindungsparameter, Firewall oder Zugangsdaten auf. Prüfen Sie sie der Reihe nach und ändern Sie die nächste Ebene erst, wenn die vorherige bestanden ist.
Stellen Sie sicher, dass der zum Auftrag gehörende Cloud Mac verbindungsbereit ist. Prüfen Sie, ob Knotenregion und Verbindungsdaten zum selben physischen Knoten gehören. Nach einer Verwaltungsaktion sollten Sie Zeitpunkt und aktuellen Status notieren und dieselbe Aktion nicht wiederholt absenden.
Erfolgsbedingung: Der Hoststatus ist normal; Auftragskennung, Knotenregion und Verbindungsziel stimmen überein.Prüfen Sie zunächst, ob das lokale Netzwerk Zieladresse und Port erreicht, und vergleichen Sie anschließend ein anderes vertrauenswürdiges Netzwerk. Schlägt nur das Büronetzwerk fehl, prüfen Sie die Ausgangsrichtlinien. Schlagen alle Netzwerke fehl, bewahren Sie Testzeit, Zielport und Fehlertyp auf.
nc -vz HOST PORT
ssh -vvv USER@HOSTStellen Sie sicher, dass Hostadresse, Port, Benutzername und Verbindungsmethode aus dem aktuellen Auftrag stammen. SSH-Konfigurationsaliase können Port oder Schlüsselpfad überschreiben. Mit ausführlichen Protokollen sehen Sie die tatsächlich verwendeten Parameter. Bei VNC prüfen Sie Zieladresse, Anzeigeeinstellungen und alte gespeicherte Clientdaten.
ssh -G oak-node
ssh -v USER@HOST -p PORTDokumentieren Sie vor einem temporären Test zunächst die bestehenden Regeln. Prüfen Sie, ob Terminal, SSH- oder VNC-Client Verbindungen initiieren dürfen und ob das Unternehmensnetz den Zielport beschränkt. Deaktivieren Sie den lokalen Schutz nicht dauerhaft zur Fehlersuche.
Erfolgsbedingung: Programm und Port besitzen eine eindeutig erlaubte ausgehende Verbindung; Tests über ein alternatives Netzwerk liefern dasselbe Ergebnis.Unterscheiden Sie zwischen „Netzwerk-Timeout“ und „Authentifizierung abgelehnt“. Ein Timeout wird nicht durch einen Passwortwechsel behoben. Bei abgelehnter Authentifizierung prüfen Sie Benutzername, Schlüsseldatei, Dateiberechtigungen und kürzlich geänderte Zugangsdaten. Supportanfragen dürfen nur den Authentifizierungsfehler enthalten, niemals Passwort oder privaten Schlüssel.
chmod 600 ~/.ssh/id_ed25519
ssh-add -l„Installiert“ bedeutet nicht automatisch, dass die Pipeline das Tool verwendet. Erfassen Sie bei der Toolchain-Analyse ausführbaren Pfad, Version, aktuelle Shell-Umgebung und tatsächliches Projektergebnis.
| Tool | Zuerst prüfen | Empfohlener Befehl | Häufige Abweichung |
|---|---|---|---|
| Xcode | Aktuelles Entwicklerverzeichnis, Version, SDK-Liste | xcode-select -pxcodebuild -version |
Die Befehlszeile verweist auf eine andere Xcode-Version; das benötigte SDK ist in der aktuellen Version nicht vorhanden |
| Homebrew | Binärpfad, Paketliste, Diagnoseergebnis | brew --prefixbrew doctor |
Die Shell lädt nicht den richtigen Pfad; nach einer Migration stimmen Paketliste und lokale Umgebung nicht überein |
| Git | Version, Remote-Adresse, Repository-Berechtigungen und Benutzerkonfiguration | git --versiongit remote -v |
Runner und interaktive Shell verwenden unterschiedliche Zugangsdaten oder Arbeitsverzeichnisse |
| Fastlane | Aufrufquelle, gesperrte Abhängigkeiten, Lane und Namen der Umgebungsvariablen | bundle exec fastlane --version |
Die globale Version wird direkt aufgerufen, statt die Projektabhängigkeiten zu verwenden |
| Laufzeitumgebung | Interpreterpfad, Versionsmanager und im Projekt festgelegte Version | which rubywhich node |
Interaktive Shell und nicht interaktive Aufgabe laden unterschiedliche Initialisierungsdateien |
Dokumentieren Sie macOS-Version, Chiparchitektur, Xcode-Version, Homebrew-Paketliste, Git-Version und Laufzeitumgebungen. Ändern Sie bei jedem Upgrade nur eine Hauptkomponente und speichern Sie die Liste jeweils vor und nach dem Upgrade.
Wenn ein Befehl im lokalen Terminal funktioniert, der Runner jedoch fehlschlägt, schreiben Sie echo "$PATH",which und Versionsbefehle in temporäre Diagnoseschritte. Entfernen Sie nach der Prüfung unnötige Umgebungsdaten, damit keine sensiblen Variablen im Protokoll erscheinen.
Führen Sie zunächst die Abhängigkeitsauflösung, anschließend einen sauberen Build aus und prüfen Sie danach Artefaktpfad und Exit-Code. Funktioniert das Minimalprojekt, das Geschäftsprojekt jedoch nicht, prüfen Sie Projektkonfiguration, gesperrte Abhängigkeiten und Skriptberechtigungen.
Die folgenden Ausgaben reichen für eine grundlegende Versionsaufzeichnung. Entfernen Sie vor einer Supportanfrage Projektnamen aus Verzeichnissen und alle sensiblen Parameter.
uname -m
sw_vers
xcode-select -p
xcodebuild -version
brew --prefix
git --version
which ruby
which node
df -h /CI/CD-Probleme sollten schrittweise geprüft werden: Auftrag angenommen, Arbeitsverzeichnis betreten, Berechtigungen erhalten, Abhängigkeiten getroffen und Build abgeschlossen. Ziehen Sie keine Schlussfolgerung nur aus der abschließenden Fehlermeldung.
Prüfen Sie, ob der Runner-Dienst läuft, die Registrierung gültig ist und die Konsole ihn als online anzeigt. Notieren Sie vor einem Neustart den Zeitpunkt des letzten Online-Status und des letzten erfolgreichen Auftrags.
Wenn ein Auftrag lange wartet, der Runner aber online ist, vergleichen Sie die geforderten Labels mit den tatsächlichen Runner-Labels. Unterschiede bei Großschreibung, Leerzeichen oder Architektur können verhindern, dass der Auftrag übernommen wird.
Stellen Sie sicher, dass der Runner-Benutzer die erforderlichen Rechte für Repository-, Cache- und Artefaktverzeichnisse besitzt. Erweitern Sie nicht die Berechtigungen aller Verzeichnisse, um einen Fehler in einem einzelnen Pfad zu kaschieren.
Bei Cachefehlern führen Sie zunächst einen Vergleichsauftrag ohne Verwendung des alten Caches aus. Wenn parallele Aufträge Dateien überschreiben, weisen Sie jedem Auftrag ein eigenes Arbeitsverzeichnis zu und prüfen Sie, ob Speicher und Storage von Oak Core oder Oak Forge zur Auftragsgröße passen.
Bewahren Sie Startzeit, Runner-Name, Commit-ID, wichtige Toolversionen, fehlerhaften Schritt, Exit-Code und das Ende des Protokolls auf. Bei reproduzierbaren Fehlern dokumentieren Sie die kürzeste Reproduktion; bei sporadischen Fehlern mindestens einen erfolgreichen und einen fehlgeschlagenen Vergleich.
Prüfen Sie zuerst Runner-Status, Projektberechtigung und Labels. Löschen Sie den Cache noch nicht, da der Auftrag die Build-Phase noch nicht erreicht hat.
Prüfen Sie zuerst Arbeitsverzeichnis, Skriptberechtigungen, Shell-Initialisierung und Toolpfad. Vergleichen Sie Umgebungsvariablen von interaktivem Terminal und Runner.
Prüfen Sie Sperrdatei, Cache-Schlüssel, freien Speicher und Netzwerk-Downloadprotokolle. Verwenden Sie einen Auftrag mit sauberem Cache als Vergleich und überschreiben Sie nicht fortlaufend die Originalnachweise.
Prüfen Sie Speicherauslastung, Schreibkonflikte in gemeinsamen Verzeichnissen, belegte Ports und Namen temporärer Dateien. Reduzieren Sie zunächst die Parallelität und entscheiden Sie danach über eine Anpassung der Aufteilung oder Konfiguration.
Einheitliche Begriffe reduzieren Rückfragen. Beschreiben Sie das konkrete Objekt, etwa „SSH-Verbindung zum Tokio-Knoten läuft in einen Timeout“, statt nur „Server nicht verfügbar“ zu schreiben.
Oakmini bietet nur zwei Kontaktwege: Melden Sie sich in der Konsole an und reichen Sie ein Ticket ein oder senden Sie eine E-Mail an support@oakmini.com. Für bestehende Aufträge, Hoststatus und laufende Prüfungen ist das Ticket vorzuziehen; vor dem Kauf oder ohne Konsolenzugriff können Sie E-Mail verwenden.
Füllen Sie jeden Punkt aus; schreiben Sie bei unbekannten Angaben „nicht bestätigt“ und raten Sie nicht. Bei mehreren Versuchen führen Sie diese chronologisch auf.
Betreff: Auftragskennung / Problemkategorie / Knotenregion
Zeitpunkt und Zeitzone:
Verbindungs- oder Auftragstyp:
Erwartetes Ergebnis:
Tatsächliches Ergebnis:
Reproduktionsschritte:
1.
2.
3.
Bereits durchgeführte Prüfungen:
Originalfehler und Exit-Code:
Beschreibung der bereinigten Protokollanhänge:Die Supportseite bietet Prüfabläufe, Befehle und Methoden zur Vorbereitung der erforderlichen Informationen. Bestellung, Verlängerung, Auftragsansicht, Hoststatus und Verwaltung des Cloud Macs erfolgen in der Konsole. Alle Knoten laufen 365 Tage im Jahr normal. Bei Abweichungen zwischen Status und tatsächlichem Verbindungsergebnis notieren Sie den Zeitpunkt und reichen Sie ein Ticket ein.