Handbuch für den technischen Support

Den Cloud-Mac von der Verbindung bis zum stabilen Betrieb bringen

Prüfen Sie Zugangsdaten, VNC-Remote-Desktop, Umgebungs­migration und Build-Diagnose in der richtigen Reihenfolge. Jeder Schritt zeigt Ergebnis und nächste Maßnahme.

Im Control Panel Ticket einreichen Cloud-Mac jetzt mieten
Für wen
Exklusiver physischer Mac mini
Übliche Bereitstellung
Ca. 4 Minuten
Support
Control-Panel-Ticket oder E-Mail
RUN / CONNECT-01

Checkliste für die erste Verbindung

Umsetzbar
Zugangsdaten abgerufen Instanzdetails im Control Panel
01
Netzwerk erreichbar Zieladresse und Port erreichbar
02
Desktop geöffnet VNC-Sitzung zeigt die macOS-Oberfläche
03
Abnahmeergebnis

Synchronisieren Sie Projekt und Build-Cache erst, wenn Modell, Arbeitsspeicher, Speicher und ausgewählter Knoten übereinstimmen.

Nach Problem auswählen

Sechs Hilfethemen für den direkten Weg zur Lösung

Wählen Sie zunächst das Thema, das zu Ihrer aktuellen Phase passt. Bei Verbindungsfehlern beginnen Sie mit Zugangsdaten und Netzwerk, bei Build-Fehlern mit Umgebung und Logs. Bestellung und Knotenstatus prüfen Sie im Control Panel.

Remote-Verbindung

Zum ersten Mal den macOS-Desktop öffnen

Adresse, Port, Benutzername und temporäres Passwort prüfen, VNC-Sitzung herstellen und erste Sicherheitseinstellungen abschließen.

Verbindungsschritte anzeigen Konto und Bestellung

Bestell- und Knotendetails anzeigen

Modell, Laufzeit, Knoten, zusätzlichen Speicher, Abrechnung und Servicestatus im Control Panel prüfen.

Control Panel öffnen Systeminitialisierung

Grundlegende Abnahme nach der Bereitstellung abschließen

Temporäre Zugangsdaten ändern und Systemversion, Speicherplatz, Netzwerkzeit sowie Administratorrechte prüfen.

Abnahmecheckliste ausführen Entwicklungsumgebung

Xcode-, CI- und MLX-Umgebung reproduzieren

Toolchain anhand der Versionsliste installieren, Abhängigkeiten isolieren und Build- sowie Inferenzprotokolle aufbewahren.

Umgebungsleitfaden anzeigen Netzwerk und Speicher

Verbindungs- und Kapazitätsprobleme unterscheiden

Lokalen Ausgang, Zielport, freien Speicher, Synchronisierungsaufgaben und Strategie für große Dateien prüfen.

Diagnosebaum öffnen Servicestatus

Laufresultate von Knoten und Instanz prüfen

Maßgeblich ist die Echtzeitanzeige im Control Panel. Knotenstatus, Systemlast und Serviceprotokolle gemeinsam zur Eingrenzung des Einflusses auswerten.

Statusdefinition anzeigen
Leitfaden für die erste Verbindung

Erst Verbindung abnehmen, dann Projekte migrieren

Schließen Sie die vier Prüfungen ab, bevor Sie Repositorys, Modelle oder Medien synchronisieren. So lassen sich Bereitstellungs-, Netzwerk- und Projektumgebungsprobleme getrennt bearbeiten.

  1. 01

    Aktuelle Zugangsdaten im Control Panel abrufen

    Instanzdetails öffnen und Knotennummer, Modell, VNC-Adresse, Port, Benutzernamen und temporäres Passwort prüfen. Keine Verbindungsdaten aus alten Tickets oder Screenshots verwenden und vollständige Zugangsdaten nicht weitergeben.

    Knotennummer stimmt mit Bestellung überein Adresse und Port stammen aus der aktuellen Instanz Zugangsdaten enthalten keine überflüssigen Leerzeichen
  2. 02

    VNC-Remote-Desktop-Verbindung herstellen

    In einem vertrauenswürdigen Netzwerk einen kompatiblen VNC-Client öffnen und mit der im Control Panel angegebenen Adresse und dem Port verbinden. Bei einem Handshake-Fehler zuerst lokales Netzwerk, Proxy, Firewall und Zielport prüfen; falsche Passwörter nicht wiederholt eingeben.

    Lokales Netzwerk erreicht externe Dienste Proxy ändert den Zielport nicht Client speichert die aktuelle Adresse
  3. 03

    Kontosicherheitseinstellungen ändern

    Nach dem ersten Öffnen der grafischen Oberfläche sofort das temporäre Anmeldepasswort ändern und Bildschirmsperre, automatische Anmeldung sowie Remotezugriff gemäß Teamregeln prüfen. Für Teammitglieder jeweils ein nachvollziehbares lokales Konto anlegen.

    Temporäres Passwort ersetzt Richtlinie für Bildschirmsperre bestätigt Bereich autorisierter Mitglieder dokumentiert
  4. 04

    System- und Bestellkonfiguration prüfen

    macOS-Version, M4-Chip, Arbeitsspeicher, Speicherkapazität, freien Speicher, Systemzeit und Netzwerkausgang prüfen. SureVM M4 Core muss M4, 16GB und 256GB anzeigen; SureVM M4 Plus M4, 24GB und 512GB.

    Chip und Arbeitsspeicher entsprechen dem gewählten Tarif Speicherkapazität entspricht den Zusatzoptionen Zeit- und Netzwerkstatus normal
Migrationspfad

Dreistufige Migration vom lokalen zum Cloud-Mac

Ziel ist nicht, den alten Rechner vollständig zu kopieren, sondern eine überprüfbare und wiederverwendbare Arbeitsumgebung neu aufzubauen. Zuerst notwendige Daten synchronisieren, dann die Toolchain reproduzieren und zuletzt Automatisierungsaufgaben anbinden.

01 Datensynchronisierung

Nur projektbenötigte Inhalte migrieren

Zuerst Code-Repositorys, Konfigurationsvorlagen, notwendige Ressourcen und nachweislich wiederverwendbare Caches synchronisieren. Große Dateien vorab komprimieren oder in Paketen übertragen, damit der Speicher nicht auf einmal vollgeschrieben wird.

  • Code und Submodule über die Versionsverwaltung abrufen
  • Sensible Variablen separat injizieren und nicht ins Repository committen
  • Pfade für Ressourcen, Modelle und Build-Artefakte dokumentieren
  • Nach der Synchronisierung Anzahl und Prüfsummen wichtiger Dateien kontrollieren
Bereitstellungsergebnis Projektdaten lesbar, Verzeichnisgrenzen eindeutig
02 Toolchain-Reproduktion

Entwicklungsumgebung anhand der Versionsliste neu aufbauen

Zuerst Versionen von Xcode, Command Line Tools, Laufzeitumgebungen und Paketmanagern bestätigen, danach Projektabhängigkeiten installieren. Keine globalen Verzeichnisse unbekannter Herkunft vom alten Rechner kopieren.

  • Versionen von Xcode und Command Line Tools festlegen
  • Ruby-, Node.js-, Python- und Java-Versionen dokumentieren
  • CocoaPods-, SwiftPM- und npm-Abhängigkeiten aus Lock-Dateien wiederherstellen
  • Sauberen Build ausführen und vollständiges Log speichern
Bereitstellungsergebnis Derselbe Commit lässt sich auf dem neuen Knoten stabil bauen
03 CI-Anbindung und Validierung

Knoten in eine nachvollziehbare Warteschlange aufnehmen

Für den Runner ein eigenes Arbeitsverzeichnis und minimale erforderliche Rechte einrichten, eine Cache-Bereinigung definieren und Abruf, Build, Archivierung sowie Log-Rückgabe mit einem Test-Branch prüfen.

  • Für den Runner zugängliche Repositorys und Ausführungskonten begrenzen
  • Cache- und Build-Artefaktverzeichnisse trennen
  • Prüfen, dass fehlgeschlagene Aufgaben Exitcode und Logs zurückgeben
  • Knotennummer, Aufgabennummer und Commit-Hash dokumentieren
Bereitstellungsergebnis Automatisierte Aufgaben reproduzierbar, lokalisierbar und übertragbar
Xcode und CI

Build-Fehler anhand einer Beweiskette untersuchen

Nicht zuerst alle Caches löschen oder sämtliche Tools neu installieren. Zunächst das Fehlerlog sichern und den Bereich über Zertifikate, Signatur, Keychain, Runner-Rechte, Cache und konkrete Fehlermeldung schrittweise eingrenzen.

Signaturkette

Zertifikate, Profile und Keychain

  1. Zweck und Gültigkeit des Zertifikats bestätigen

    Zertifikatstyp, Teamkonfiguration und Gültigkeitsdauer des Build-Ziels prüfen, damit Entwicklungs- und Release-Umgebung nicht vermischt werden.

  2. Quelle der Signatur­einstellungen prüfen

    Prüfen, ob Projektkonfiguration, Build-Parameter und CI-Umgebungsvariablen auf dieselbe Signaturstrategie verweisen.

  3. Zugriff des Jobs auf die Keychain bestätigen

    Eine interaktive Anmeldung garantiert keinen Zugriff des Hintergrund-Runners. Entsperren und Leserechte daher unter dem Ausführungskonto des Runners prüfen.

Ausführungsumgebung

Runner-Rechte, Cache und Logs

  1. Tatsächliches Ausführungskonto des Runners bestätigen

    Arbeitsverzeichnis, Shell, PATH sowie Lese- und Schreibrechte prüfen, nicht nur im interaktiven Terminal des Remote-Desktops.

  2. Abhängigkeitscache und abgeleitete Daten isolieren

    Klare Verzeichnisse für CocoaPods, SwiftPM, npm und DerivedData festlegen und problematische Caches zunächst gezielt bereinigen.

  3. Erstes vollständiges Fehlerlog aufbewahren

    Aufgabennummer, Commit-Hash, Xcode-Version, Exitcode und ersten Fehler dokumentieren, statt nur die letzten Zeilen zu übermitteln.

Reihenfolge der Loganalyse

Zuerst den ersten Fehler finden, dann Folgefehler prüfen

Am Ende eines Build-Logs stehen oft zahlreiche Folgefehler. Mit dem ersten Exitcode ungleich null, dem ersten Signaturfehler oder dem ersten Fehler bei der Abhängigkeitsauflösung beginnen und anhand der Startzeit der Aufgabe die eigentliche Ursache bestimmen.

01 Aufgabenkontext

Knotennummer, Aufgabennummer, Commit-Hash, Branch.

02 Umgebungskontext

macOS, Xcode, Laufzeit- und Abhängigkeitsversionen.

03 Fehlerkontext

Erster Fehler, Exitcode, zugehöriger Befehl und Zeitpunkt.

MLX und Entwicklungsumgebung

Experimentierumgebung reproduzierbar machen, statt sie nur in der aktuellen Sitzung nutzbar zu halten

Python-Umgebung, Modelldateien, Parameter und Ausgaben getrennt verwalten. So bleibt der Speicherverbrauch kontrollierbar und Änderungen nach Abhängigkeitsupdates lassen sich schnell vergleichen.

Umgebungsprotokoll

Empfohlene Verzeichnis- und Dokumentationsstruktur

ENV
Python-Umgebungen isolieren

Für jedes Projekt eine eigene virtuelle Umgebung verwenden, die Python-Version festlegen und die Abhängigkeitsliste versionieren.

DEP
Abhängigkeiten installieren

Abhängigkeiten aus Lock-Dateien installieren und MLX- sowie wichtige Bibliotheksversionen dokumentieren. Vor Updates Umgebungsdatei und Referenzergebnisse kopieren.

MODEL
Modelldateien verwalten

Modelle, quantisierte Versionen und temporäre Downloadverzeichnisse getrennt speichern. Quelle, Prüfsumme und Speicherbedarf dokumentieren, um Duplikate zu vermeiden.

RUN
Ausführungsprotokolle aufbewahren

Bei jedem Experiment Commit-Hash, Parameter, Abhängigkeitsversionen, Eingabezusammenfassung, Dauer und Ausgabepfad speichern; keine sensiblen Rohdaten dokumentieren.

Vor dem Start

Speicherbudget prüfen

Modelldateien, virtuelle Umgebungen, Cache und Ausgaben belegen gleichzeitig Speicher. Vor dem Download die verfügbare Kapazität prüfen und Reserve für temporäre Dateien einplanen.

  • Im Modellverzeichnis nur benötigte Versionen behalten
  • Eindeutigen Bereinigungszyklus für den Cache festlegen
  • Zwischendateien erst nach der Ergebnisarchivierung löschen
Nach Änderungen

Mit einem Minimalbeispiel prüfen

Nach Änderungen an Abhängigkeiten oder Modellen zunächst ein kleines Beispiel mit festen Eingaben ausführen. Exitcode, Ausgabestruktur und Ressourcenverbrauch vergleichen, dann den vollständigen Auftrag starten.

  • Umgebungslisten vor und nach der Änderung aufbewahren
  • Fehlerbefehl und ersten Fehler dokumentieren
  • Schreibbarkeit und ausreichende Kapazität des Ausgabepfads bestätigen
Verbindungsdiagnose

Von den Zugangsdaten bis zum Knotenstatus schrittweise ausschließen

Jede Ebene beantwortet nur eine Frage. Wenn eine Ebene nicht bestanden ist, nicht zur nächsten springen und Software neu installieren. Das reduziert unnötige Änderungen und liefert klare Nachweise für das Ticket.

01
Zugangsdaten

Stammen Adresse, Port, Benutzername und Passwort aus der aktuellen Instanz?

Wenn nicht

Instanzdetails im Control Panel erneut öffnen, aktuelle Verbindungsdaten manuell kopieren sowie Leerzeichen am Anfang und Ende und alte Client-Einträge prüfen.

02
Netzwerk

Erreicht das lokale Netzwerk Zieladresse und Zielport?

Wenn nicht

Proxy, der Datenverkehr umschreibt, vorübergehend deaktivieren, Unternehmensrichtlinien für den Ausgang prüfen und über ein anderes vertrauenswürdiges Netzwerk gegenprüfen.

03
Remote-Desktop-Dienst

Ist das Netzwerk erreichbar, scheitert die VNC-Sitzung aber beim Handshake?

Wenn nicht

Clientname, Version, Originalfehlermeldung und Zeitpunkt dokumentieren, statt fehlerhafte Zugangsdaten wiederholt zu senden.

04
Systemlast

Ist die Verbindung hergestellt, aber die Anzeige träge, weil eine Aufgabe die Ressourcen stark belastet?

Zu prüfen

CPU, Arbeitsspeicher, freien Speicher sowie laufende Build- oder Inferenzaufgaben prüfen. Nicht benötigte Warteschlangen zunächst pausieren und erneut testen.

05
Knotenstatus

Meldet das Control Panel für die aktuelle Instanz den normalen Betriebsstatus?

Bei abweichendem Status

Aufgaben nicht wiederholt selbst neu starten. Knotennummer, Control-Panel-Status, Zeitpunkt und bisherige Prüfergebnisse dokumentieren und ein Ticket einreichen.

Servicestatus

Echtzeitergebnis des Control Panels ist maßgeblich

Alle Knoten sind für einen normalen Betrieb an 365 Tagen im Jahr ausgelegt. Stimmen Instanzstatus, Verbindungsergebnis und lokale Prüfung nicht überein, bitte Knoten und Zeitraum dem Support zur Prüfung mitteilen.

Zuerst dokumentieren
Knotennummer und Zeitpunkt des Auftretens
Dann abgleichen
Control-Panel-Status und lokale Beobachtung
Zuletzt einreichen
Bereinigte Logs und Reproduktionsschritte
Supportanfrage einreichen

Support in die Lage versetzen, das Problem direkt zu reproduzieren

Ein vollständiges Ticket beschreibt Objekt, Zeitpunkt, Aktion und Ergebnis. Repository-Adressen, Token, private Schlüssel, personenbezogene Daten und Geschäftsinhalte vorher aus Logs entfernen.

TICKET / REQUIRED

Ein Ticket muss fünf Angaben enthalten

Nach der Bereinigung einreichen
NODE
Knotennummer und Region

Die im Control Panel angezeigte Knotennummer sowie Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder US-West angeben.

MODEL
Modell und Konfiguration

SureVM M4 Core oder SureVM M4 Plus angeben und vermerken, ob zusätzlicher Speicher oder Thunderbolt 5 Parallelbetrieb verwendet wird.

TIME
Zeitpunkt und Zeitzone

Ersten und letzten Reproduktionszeitpunkt sowie Zeitzone angeben, statt nur „gerade eben“ oder „ungefähr gestern“ zu schreiben.

STEPS
Kürzeste Reproduktionsschritte

Ausgehend vom Normalzustand Aktionen, Eingaben, erwartetes Ergebnis und tatsächliches Ergebnis in der richtigen Reihenfolge beschreiben.

LOG
Bereinigtes Log und Originalfehler

Zeitpunkt, Exitcode und Fehlerkontext beibehalten, Passwörter, Zugriffstoken, private Schlüssel, vollständige Zahlungsdaten und geschäftlich sensible Daten entfernen.

Für Kunden mit Bestellung

Knotenticket über das Control Panel einreichen

Control-Panel-Tickets können Instanz, Bestellung und Knotenstatus verknüpfen und eignen sich für Verbindungs-, System-, Abrechnungs- und länger andauernde technische Probleme.

Anmelden und Ticket einreichen
Anmeldeprobleme oder Fragen vor der Bestellung

Supportteam per E-Mail kontaktieren

Eine zusammenfassende Anfrage von einer erreichbaren E-Mail-Adresse senden. Die einzige Supportadresse ist support@surevm.com. Keine Kontopasswörter oder privaten Schlüssel per E-Mail senden.

support@surevm.com
Nächster Schritt

Bei Problemen Nachweise einreichen, bei Bedarf den Knoten direkt konfigurieren

Das Control Panel dient zur Instanzverwaltung und für Supporttickets. Über den Bestellbereich wählen Sie zwischen zwei M4-Konfigurationen, Laufzeiten und fünf verfügbaren Knoten.

Control Panel öffnen Cloud-Mac jetzt mieten