-
01
Node-Daten bestätigen Bestellnummer, Node-Adresse, Port und Kontoname müssen zum selben Host gehören.Basis
-
02
Netzwerkpfad prüfen Nach einem Netzwerkwechsel erneut testen, um lokalen Ausgang und Ziel-Node zu unterscheiden.Netzwerk
-
03
Zugangsdaten prüfen Aktualisierungszeitpunkt der Zugangsdaten, SSH-Schlüssel und Host-Fingerabdruck kontrollieren.Identität
-
04
macOS-Sitzung prüfen Kontrollieren, ob grafische Sitzung, Sperrbildschirm und Hintergrundaufgaben noch laufen.Sitzung
-
05
Client-Unterschiede ausschließen Clientversion, Anzeigeparameter, Proxy und Originalfehlermeldung dokumentieren.Lokal
Erst systematisch eingrenzen, dann an die richtige Stelle weitergeben
Hier geht es um Bereitstellung, Remotezugriff, SSH, Xcode, CI/CD, Speicher und Abrechnung für Cloud-Macs. Mit fünf grundlegenden Prüfungen lässt sich meist in einem Durchlauf feststellen, ob die Ursache im lokalen Netzwerk, bei den Zugangsdaten, in der macOS-Sitzung oder in der Build-Umgebung liegt.
Wenn Engineering-Unterstützung nötig ist, fügen Sie dem Ticket in der Konsole Bestellnummer, Ziel-Node, Zeitpunkt, Screenshots und bereits ausgeführte Schritte hinzu. Senden Sie keine Passwörter, privaten Schlüssel oder Wiederherstellungsdaten.
- 7 Kategorien
- Problemzugänge
- 5 Schritte
- Basisdiagnose
- 2 Wege
- Kontaktmöglichkeiten
Sieben Zugänge – damit die Diagnose in die richtige Richtung startet
Wählen Sie den Zugang, der dem aktuellen Verhalten am nächsten kommt. Jede Karte nennt den ersten Prüfschritt und die zu sichernden Nachweise.
Bestellung aufgegeben, Zugangsdaten noch nicht bestätigt
Prüfen Sie zuerst Bestellstatus, gewähltes Modell und Ziel-Node. Kontrollieren Sie anschließend, ob die Konsole Node-Adresse, Port, Kontoname und Verbindungsanleitung bereitstellt.
- Bestellnummer und Bestellzeit dokumentieren
- Prüfen, ob Node und Bestellung übereinstimmen
- Keine identische Bestellung wiederholt anlegen
Grafische Oberfläche öffnet nicht, bleibt schwarz oder trennt häufig
Prüfen Sie zunächst Node-Adresse und Port und testen Sie anschließend über ein anderes Netzwerk. Bewahren Sie Clientname, Version, Anzeigeeinstellungen und einen vollständigen Fehler-Screenshot auf.
- Sicherstellen, dass die Sitzung nicht am Sperrbildschirm hängt
- Mit niedrigerer Bildschirmauflösung erneut testen
- Lokalen Proxy und Firewall-Regeln prüfen
Schlüssel abgelehnt, Fingerabdruck geändert oder Verbindung läuft ab
Prüfen Sie lokalen privaten Schlüssel, öffentlichen Schlüssel, Zielkonto, Port und Host-Fingerabdruck getrennt. Fügen Sie private Schlüssel niemals Tickets oder E-Mails bei.
- Originalfehlermeldung mit Zeitstempel aufbewahren
- Prüfen, dass der öffentliche Schlüssel nicht durch Zeilenumbrüche beschädigt ist
- Nach einem Schlüsseltausch die alte Sitzung zunächst offen lassen
Versionskonflikt, Build fehlgeschlagen oder Cache fehlerhaft
Dokumentieren Sie macOS-, Xcode-, Projekt-Commit- und Abhängigkeitsversionen. Prüfen Sie zunächst die Umgebung, ohne Code zu ändern, und entscheiden Sie erst danach über eine Cache-Bereinigung.
- Erstes echtes Fehlerprotokoll sichern
- Umgebungs- und Codefehler unterscheiden
- Belegung der Cache-Verzeichnisse vor der Bereinigung dokumentieren
Runner offline, Aufgabe hängt oder Arbeitsverzeichnis weicht ab
Prüfen Sie Runner-Prozess, Registrierungsbereich, Arbeitsverzeichnis, parallele Aufgaben und Netzwerkausgang. Starten Sie zuerst einen minimalen Test und anschließend die vollständige Pipeline.
- Fehlerhafte Aufgabennummer dokumentieren
- Letzten Online-Zeitpunkt des Runners prüfen
- Sicherstellen, dass der Cache den Datenträger nicht füllt
Weniger Speicherplatz, übergroßer Cache oder fehlgeschriebene Daten
Erfassen Sie die Belegung nach Verzeichnis und unterscheiden Sie Projektdateien, Abhängigkeits-Cache, Build-Artefakte, Protokolle und temporäre Dateien. Löschen Sie keine Systemverzeichnisse unbekannter Herkunft.
- Freien Speicher und auffällige Verzeichnisse dokumentieren
- Kontinuierlich wachsende Protokolldateien prüfen
- Nach der Bereinigung einen Minimal-Build ausführen
Abrechnungszeitraum, Node, Zusatzoptionen oder Zahlungen müssen geprüft werden
Prüfen Sie im USD-Beleg Modell, Mietdauer, Node, Speichererweiterung und Anzahl der Thunderbolt-5-Parallelschaltungen einzeln. Gleichen Sie anschließend die Zahlungsdaten ab.
- Tages-, Wochen-, Monats- oder Quartalszeitraum bestätigen
- Anzahl und Einzelpreis der Zusatzoptionen abgleichen
- Bestellnummer beifügen, keinen Zahlungsschlüssel senden
Build-Logs, Originalfehler, Clientversion, Speicherbelegung und Zeitpunkt verkürzen Rückfragen deutlich. Bei Zugangsdaten nur den Status beschreiben – keine Passwörter, privaten Schlüssel oder Wiederherstellungsdaten senden.
„Keine Verbindung“ in fünf überprüfbare Schritte zerlegen
Dokumentieren Sie das Ergebnis jedes Schritts. Wechseln Sie nicht gleichzeitig Netzwerk, Schlüssel und Client, sonst bleibt die eigentliche Ursache unklar.
Schnell-Diagnosepanel
-
01
Node-InformationenAusgabe: Node-Datensatz
Bestätigen Sie in der Konsole Bestellnummer, Node-Code, Node-Adresse, Port und Kontoname. Prüfen Sie beim Kopieren Leerzeichen am Anfang und Ende; nicht aus dem Gedächtnis eingeben.
-
02
NetzwerkerreichbarkeitAusgabe: Netzwerkvergleich
Dokumentieren Sie aktuelles Netzwerk, Proxy und Ausgangsumgebung und testen Sie sowohl über das ursprüngliche als auch über ein anderes vertrauenswürdiges Netzwerk. Schlägt nur ein Netzwerk fehl, prüfen Sie zuerst lokale Ausgangsbeschränkungen.
-
03
Status der ZugangsdatenAusgabe: Statusbeschreibung
Prüfen Sie, ob temporäre Zugangsdaten aktualisiert wurden, der öffentliche SSH-Schlüssel vollständig ist, die Berechtigungen des privaten Schlüssels stimmen und der Host-Fingerabdruck dem ersten Eintrag entspricht.
-
04
Status der macOS-SitzungAusgabe: Sitzungsgrenze
Stellen Sie fest, ob der gesamte Host unerreichbar ist oder nur die grafische Sitzung nicht reagiert. Wenn SSH noch funktioniert, prüfen Sie zuerst Sitzung, Sperrbildschirm und zugehörige Prozesse.
-
05
Lokale Client-EinstellungenAusgabe: Clientvergleich
Dokumentieren Sie Clientname, Version, Bildschirmauflösung, Farbeinstellungen, Proxy und Originalfehlermeldung. Bei einem Test mit einem anderen kompatiblen Client alle übrigen Bedingungen unverändert lassen.
Ein einzelner Bereich ist eingegrenzt
Beispielsweise schlägt nur ein lokales Netzwerk fehl, nur ein alter Schlüssel wird abgelehnt oder nur ein Client zeigt Fehler. Ändern Sie jeweils nur eine Variable und prüfen Sie erneut.
Über mehrere Netzwerke und Clients reproduzierbar
Fügen Sie die fünf Prüfergebnisse, Zeitpunkt und Fehler-Screenshots in ein gemeinsames Ticket ein. Engineering kann anhand dieser Nachweise Node und Sitzung direkt weiter prüfen.
Objekte eindeutig benennen, statt Protokoll, Sitzung und Host zu vermischen
Diese Begriffe erscheinen in Bereitstellungsunterlagen, Verbindungsanleitungen und Ticketantworten. Verwenden Sie bei der Problembeschreibung möglichst den passenden Fachbegriff.
- Cloud-Mac
- Eine über das Netzwerk erreichbare macOS-Arbeitsumgebung für Xcode-Builds, automatisierte Tests, Skriptaufgaben und lokale Modellinferenz. Der Begriff beschreibt die Nutzung, nicht die Virtualisierung.
- Physischer Node
- Der Apple-Silicon-Host, auf dem die Bestellung tatsächlich läuft, einschließlich seines Netzwerkstandorts. Node-Daten enthalten meist Adresse, Port und Regionscode.
- Exklusiv
- Eine gültige Miete entspricht einem dedizierten physischen Host; Rechenressourcen dieses Hosts werden nicht mit anderen Mietern geteilt.
- Keine virtuelle Maschine
- Geliefert wird ein exklusiver physischer Host, keine aus einem gemeinsam genutzten Host ausgeschnittene virtuelle Instanz. Bei der Diagnose sind Host- und Remote-Sitzungsstatus getrennt zu betrachten.
- VNC
- Remote-Desktop-Protokoll für den Zugriff auf die grafische macOS-Oberfläche. Geeignet für Xcode, grafische Tools und die Prüfung der Desktop-Sitzung.
- SSH
- Sichere Verbindung für Kommandozeilenanmeldung, Skriptausführung, Dateiverarbeitung und CI/CD-Verwaltung. Prüfen Sie Adresse, Port, Konto, Schlüssel und Host-Fingerabdruck.
- self-hosted runner
- Continuous-Integration-Executor auf dem gemieteten Host. Teamseitig konfiguriert werden Projektbereich, Arbeitsverzeichnis, Parallelität und Cache-Strategie.
- Sitzung wiederherstellen
- Nach einer Trennung des Remote-Desktops wieder in die bestehende macOS-Sitzung wechseln. Wiederhergestellt wird die grafische Sitzung, nicht der Host oder die Build-Umgebung.
Erstanmeldung, Schlüsseltausch und Anzeigeprobleme getrennt behandeln
Öffnen Sie den Eintrag, der zum aktuellen Verhalten passt, und arbeiten Sie die Schritte der Reihe nach ab. Ändern Sie jeweils nur eine Bedingung und testen Sie erneut.
Was sollte ich prüfen, wenn die erste Remoteanmeldung fehlschlägt?
Kopieren Sie Node-Adresse, Port und Kontoname erneut aus der Konsole und bestätigen Sie, dass sie zur selben Bestellung gehören. Prüfen Sie anschließend Proxy, Portbeschränkungen und zusätzliche Firewall-Regeln im lokalen Netzwerk.
- Clientname, Version und vollständige Fehlermeldung dokumentieren.
- Sicherstellen, dass keine überflüssigen Leerzeichen eingegeben wurden und die Groß-/Kleinschreibung des Kontonamens unverändert bleibt.
- Über ein vertrauenswürdiges anderes Netzwerk testen, ohne gleichzeitig die Zugangsdaten zu wechseln.
- Wenn SSH erreichbar ist, die grafische Oberfläche aber nicht, diesen Unterschied im Ticket eindeutig nennen.
Warum schlägt die alte Verbindung nach der Aktualisierung temporärer Zugangsdaten weiterhin fehl?
Beenden Sie den Client, der die alten Zugangsdaten speichert, vollständig und stellen Sie die Verbindung neu her. Manche Clients speichern Konto- oder Authentifizierungsdaten im Cache; das Ändern eines Passwortfelds löscht alte Einträge nicht immer.
Sobald die neuen Zugangsdaten funktionieren, löschen Sie die alten Einträge. Zeigen Sie Passwörter nicht in Tickets, Screenshots oder E-Mails; nennen Sie nur Aktualisierungszeit, verwendetes Konto und Fehlertyp.
Wie tausche ich SSH-Schlüssel sicher aus, ohne mich auszusperren?
Lassen Sie die aktuelle SSH-Sitzung geöffnet, fügen Sie zuerst den neuen öffentlichen Schlüssel hinzu und prüfen Sie ihn. Stellen Sie über ein zweites Terminal eine neue Verbindung her und entfernen Sie den alten Schlüssel erst nach erfolgreicher Prüfung.
- Für diesen Host einen eigenen Schlüssel erzeugen und keine Schlüsseldateien unbekannter Herkunft wiederverwenden.
- Prüfen, dass der öffentliche Schlüssel vollständig in einer Zeile steht und beim Kopieren weder umgebrochen noch abgeschnitten wurde.
- Berechtigungen des lokalen privaten Schlüssels und Zielkonto prüfen.
- Host-Fingerabdruck sichern; bei unerwarteter Änderung Verbindung pausieren und per Ticket prüfen lassen.
Wie gehe ich bei schwarzem Bildschirm, Bildfehlern oder Eingabeverzögerung in VNC vor?
Prüfen Sie zuerst, ob SSH noch funktioniert. Ist die Kommandozeile erreichbar, liegt die Ursache eher in der grafischen Sitzung oder den Anzeigeparametern des Clients als in einem offline geschalteten physischen Node.
Verringern Sie Auflösung und Farbqualität des Clients, deaktivieren Sie den lokalen Proxy und testen Sie erneut. Dokumentieren Sie, ob das Problem nur im Vollbild-, Skalierungs- oder Mehrmonitorbetrieb auftritt. Beenden Sie nicht nacheinander mehrere Systemprozesse erzwingend.
Wie erhalte ich bei hoher Latenz reproduzierbare Ergebnisse?
Dokumentieren Sie Netzwerktyp, Ziel-Node, Testzeitraum, Protokoll und Clientversion. Führen Sie dieselben Schritte im ursprünglichen und in einem anderen vertrauenswürdigen Netzwerk aus und halten Sie Auflösung, Proxy und Auslastung konstant.
Liefern Sie nicht nur die Aussage „sehr langsam“. Geben Sie im Ticket an, ob Eingabereaktion, Bildaktualisierung, Dateiübertragung oder Kommandoausgabe betroffen ist und ob das Problem dauerhaft auftritt.
Umgebung fixieren, dann Xcode, Runner und Speicher analysieren
Ziel der Build-Diagnose ist nicht, sofort alle Caches zu leeren, sondern die veränderte Ebene zu identifizieren und reproduzierbare Nachweise zu sichern.
Xcode- und macOS-Version bestätigen
Dokumentieren Sie die vollständige Xcode-Version, den Pfad der Command-Line-Tools, die macOS-Version und den Projekt-Commit. Vergleichen Sie bei einer festen Team-Baseline zuerst mit dem letzten erfolgreichen Build.
xcodebuild -version
xcode-select -p
sw_vers
Grenzen der Signierungsumgebung prüfen
Prüfen Sie die Beziehungen zwischen Projekteinstellungen, Zertifikatsdateien, Bereitstellungsprofilen und Build-Skripten. Sensible Felder dürfen in einem Screenshot abgedeckt eingereicht werden; Signierungsschlüssel oder Passwörter nicht hochladen.
- Erste originale Signierungsfehlermeldung sichern
- Fehlerhaftes Target und Build-Konfiguration dokumentieren
- Lokalen Skriptfehler und Projektkonfigurationsfehler unterscheiden
Cache evidenzbasiert bereinigen
Dokumentieren Sie zuerst die Belegung von DerivedData, Abhängigkeits-Cache und Arbeitsverzeichnis. Bereinigen Sie nur Verzeichnisse des fehlerhaften Projekts und führen Sie anschließend einen Minimal-Build aus.
du -sh ~/Library/Developer/Xcode/DerivedData
df -h
CI-Runner erneut verbinden
Prüfen Sie Runner-Prozess, Registrierungsbereich, Arbeitsverzeichnis und letzten Online-Zeitpunkt. Testen Sie Netzwerk, Berechtigungen und Ausführungsumgebung mit einer minimalen Aufgabe ohne Veröffentlichung.
- Fehlerhafte Aufgabennummer und Zeitpunkt dokumentieren
- Sicherstellen, dass derselbe Executor nicht doppelt registriert ist
- Eigentümer des Arbeitsverzeichnisses und freien Speicher prüfen
Ursachen des Speicherwachstums prüfen
Erfassen Sie Projektdateien, Abhängigkeiten, Build-Artefakte, Protokolle und temporäre Dateien getrennt. Bei weiter sinkendem Speicherplatz Wachstumsverzeichnis und Beobachtungsintervall dokumentieren und ein Ticket erstellen.
df -h
du -sh ~/Library/Developer/*
du -sh ~/Library/Caches/*
Sichern Sie zunächst Logs, Versionen, Speicherbelegung und fehlerhafte Aufgabennummern. Das vollständige Leeren von Caches oder Überschreiben der Konfiguration kann den Fehler vorübergehend verbergen und zugleich die Diagnosegrundlage zerstören.
Zeitraum, Konfiguration, Node und Zusatzoptionen Zeile für Zeile prüfen
Alle Bestellungen werden in USD berechnet und abgerechnet. Welche Zahlungs-Gateways tatsächlich verfügbar sind, zeigt die Konsole in Echtzeit.
Zuerst den Mietzeitraum bestätigen
Der Abrechnungszeitraum kann Tag, Woche, Monat oder Quartal sein. Leiten Sie andere Zeiträume nicht direkt aus dem Tagespreis ab; maßgeblich ist der Katalogpreis des gewählten Modells.
Nur zwei Zahlungsarten prüfen
Unterstützt werden USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Im Ticket genügen Bestellnummer und ein nicht sensitives Kennzeichen aus der Transaktion.
Abrechnungsbestandteile einzeln prüfen
Modell, Mietdauer, Ziel-Node, Typ des Zusatzspeichers und Anzahl der Thunderbolt-5-Parallelschaltungen bestätigen. Der verfügbare Status wird in Echtzeit von der Konsole angezeigt.
| Zusatzoption | Pro Tag | Pro Woche | Pro Monat | Pro Quartal |
|---|---|---|---|---|
| +1TB SSD | $2.6 | $7.1 | $13.2 | $35.9 |
| +2TB SSD | $5.2 | $14.2 | $26.4 | $71.8 |
| Thunderbolt 5 parallel (pro Gerät) | $2 | $5.3 | $9.9 | $26.9 |
Geben Sie Bestellnummer, Modell, Mietzeitraum, Ziel-Node sowie Name und Anzahl der Zusatzoptionen und ein nicht sensibles Transaktionskennzeichen an. Senden Sie keine vollständigen Kartennummern, Verifizierungscodes, Wallet-Schlüssel oder Passwörter.
Engineering alle direkt verwertbaren Informationen bereitstellen
Probleme mit genutzten Nodes bevorzugt über ein Konsolen-Ticket melden. Wenn Sie sich nicht anmelden können, senden Sie eine E-Mail an support@officevps.com.
Ein vollständiges Ticket enthält sechs Angaben
Vollständige Nummer aus der Konsole kopieren, nicht nur Modellname oder Node-Stadt nennen.
Den tatsächlich bestellten Node angeben: Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste oder US-Westküste.
Lokale Zeit und Zeitzone nennen und angeben, ob das Problem dauerhaft oder sporadisch auftritt.
Originalfehler und Kontext sichern; Kontozugangsdaten, private Schlüssel, Signiermaterial und andere sensible Inhalte abdecken.
Getestete Netzwerke, Clients, Befehle und Ergebnisse der Reihe nach auflisten, nicht nur „alles probiert“ schreiben.
Angeben, ob die Verbindung wiederhergestellt, die Abrechnung bestätigt, der Runner neu verbunden oder ein konkreter Buildfehler lokalisiert werden soll.
Konsolen-Ticket
Geeignet für Node-, Verbindungs-, Build-, Speicher- und Abrechnungsprobleme. Der Bestellkontext bleibt im selben Konto mit dem Ticket verknüpft.
Support-E-Mail
Nennen Sie beim E-Mail-Versand Konto-E-Mail, Bestellnummer und eine Problembeschreibung. Fügen Sie keine Passwörter, privaten Schlüssel oder Wiederherstellungsdaten bei.
Wenn Wissensartikel nicht helfen, nach Status fortfahren
Der Ticketstatus zeigt den aktuellen Verantwortlichen und die nächste Aktion. Antworten Sie im bestehenden Ticket und fügen Sie dort Unterlagen hinzu; erstellen Sie nicht mehrere Tickets zum selben Problem.
Unterlagen in der Warteschlange
Prüfen Sie, ob Bestellnummer, Node, Zeitpunkt, Fehlerprotokoll und ausgeführte Schritte vollständig sind. Fehlende Angaben können im bestehenden Ticket ergänzt werden.
Engineering prüft den Fall
Geprüft werden können Node-Erreichbarkeit, Sitzungsstatus, Bereitstellungsdaten oder Abrechnungsbestandteile. Vermeiden Sie weitere Umgebungsänderungen, damit keine neuen Variablen den Zustand überlagern.
Weitere reproduzierbare Informationen benötigt
Ergänzen Sie auf Anfrage Logs, Screenshots, Netzwerkvergleich oder Clientversion. Senden Sie nur relevante Ausschnitte und decken Sie sensible Felder weiterhin ab.
Wiederherstellung prüfen und Ergebnis dokumentieren
Führen Sie mit dem bisherigen Workflow einen Test aus und dokumentieren Sie Ursache, erfolgreiche Schritte und Umgebungsversion als Basis für das Team.
Exklusiven physischen Host wählen und die Build-Umgebung am passenden Node bereitstellen
Drei Apple-Silicon-Konfigurationen decken leichte Builds, tägliche Entwicklung, parallele CI und lokale Modellinferenz ab. Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); abgerechnet wird stets in USD.