Technisches Support-Handbuch

Vom ersten Verbindungsaufbau bis zur Fehleranalyse: den Cloud-Mac Schritt für Schritt in Betrieb nehmen

Hier finden Sie eine direkt ausführbare Prüfreihenfolge: Zuerst Bestell- und Knoteninformationen bestätigen, dann die Remote-Verbindung herstellen, die Entwicklungstools konfigurieren und die kontinuierliche Integration anbinden. Sammeln Sie zuletzt anhand des Fehlerbilds die Protokolle und reichen Sie ein Ticket ein.

Ticket im Portal einreichen Kontaktmöglichkeiten für den Support anzeigen
Knotenstandorte
Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong
Betriebszeit
365 Tage im Jahr verfügbar
Kontaktwege
Portal-Ticket oder Support-E-Mail
Den richtigen Weg finden

Sechs Problemtypen, sechs kürzeste Lösungswege

Wenn ein Fehler mehrere Kategorien betrifft, prüfen Sie zuerst unter „Erste Verbindung“ die Basisinformationen und wechseln Sie anschließend zu „Fehlerbehebung“. Maßgeblich sind der tatsächliche Status von Konto, Bestellung und Knoten, wie er im Portal angezeigt wird.

Erste Verbindung

Nicht mit wiederholten Verbindungsversuchen beginnen, sondern zuerst fünf Basisprüfungen durchführen

Bei der ersten Nutzung entstehen Probleme meist durch falsch übertragene Knoteninformationen, Einschränkungen des lokalen Netzwerks oder ungeeignete Anzeigeparameter. Die Prüfung in der richtigen Reihenfolge verhindert, dass Umgebungsprobleme fälschlich dem Knoten zugeschrieben werden.

  1. 01

    Aktuelle Bestellung im Portal öffnen

    Bestellnummer, Modell, Knotenregion, Verbindungsadresse, Benutzername und Zugangsdaten müssen zur selben Bestellung gehören. Verwenden Sie keine Screenshots älterer Bestellungen oder frühere Angaben aus Chatverläufen. Zugangsdaten dürfen nur in einem kontrollierten Passwort-Manager gespeichert werden.

    Modell und Region stimmen mit der aktuellen Bestellung überein
  2. 02

    Remote-Desktop-Verbindung herstellen

    Verwenden Sie einen Remote-Desktop-Client mit Unterstützung für die grafische macOS-Oberfläche und geben Sie Verbindungsadresse und Benutzernamen exakt ein. Wenn die Verbindung fehlschlägt, wechseln Sie zunächst einmal das lokale Netzwerk, um Unternehmensproxy, ausgehende Firewall oder Richtlinien öffentlicher Netzwerke als Ursache auszuschließen.

    Die grafische macOS-Oberfläche ist sichtbar und der Desktop lässt sich bedienen
  3. 03

    Grundlegende Sicherheitseinstellungen vornehmen

    Ändern Sie nach der ersten Anmeldung das Systempasswort, prüfen Sie die Zeit bis zur Bildschirmsperre und stellen Sie sicher, dass private Projektschlüssel, Signaturzugangsdaten und Zugriffstoken nicht in gemeinsam genutzten Skripten, der Befehlshistorie oder öffentlichen Repositories gespeichert werden. Senden Sie Passwörter oder private Schlüssel nicht an Supportmitarbeiter.

    Die Zugangsdaten wurden geändert und sicher im Team verwahrt
  4. 04

    Auflösung und Bildqualität anpassen

    Wählen Sie passend zu Ihrem lokalen Monitor eine geeignete Skalierung. Bei Netzwerkschwankungen senken Sie zunächst Bildqualität und Auflösung und beurteilen erst danach die Reaktion des Knotens. Mausverzögerungen und ein unscharfes Bild bedeuten nicht automatisch, dass Kompilierung oder Festplattenleistung nachgelassen haben.

    Text ist scharf, Eingaben und das Verschieben von Fenstern reagieren stabil
  5. 05

    Prüfung der ersten Anmeldung durchführen

    Öffnen Sie das Terminal und prüfen Sie Systemzeit, verfügbaren Speicherplatz, Namensauflösung und den Pfad der Xcode-Kommandozeilentools. Erstellen Sie anschließend ein temporäres Verzeichnis und testen Sie Schreiben, Lesen und Löschen, um die erforderlichen Berechtigungen des aktuellen Benutzers für das Projektverzeichnis zu bestätigen.

    Zeit, Speicher, Netzwerk und Verzeichnisberechtigungen sind in Ordnung
Entwicklungsumgebung

Zuerst Versionen und Verzeichnisse festlegen, dann Projektabhängigkeiten installieren

Der Cloud-Mac ist ein exklusiver physischer Rechner und keine virtuelle Maschine. Die Umgebung sollte dennoch als reproduzierbare Checkliste dokumentiert werden, damit sich über längere Zeit angesammelte manuelle Änderungen zurücksetzen lassen.

Xcode

Die für das Projekt erforderliche Toolchain-Version festlegen

Lesen Sie zunächst die Versionsvorgaben in der Projektdokumentation und CI-Konfiguration und wählen Sie anschließend die passende Xcode-Version. Prüfen Sie nach dem Wechsel auch Compilerpfad, SDK-Liste und Kommandozeilentools, damit Version der grafischen Oberfläche und tatsächlich verwendeter Terminalpfad übereinstimmen.

xcode-select -p
xcodebuild -version
xcrun --show-sdk-path

Prüfkriterium: Lokale Entwicklung und kontinuierliche Integration verwenden dieselbe Xcode-Hauptversion, dasselbe SDK und dieselben Toolpfade.

Homebrew

Reproduzierbare Abhängigkeiten mit einer Brewfile verwalten

Verlassen Sie sich bei der Liste installierter Tools nicht auf Ihr Gedächtnis. Exportieren Sie zunächst aus der bestehenden Umgebung eine Brewfile, entfernen Sie nicht benötigte Pakete und installieren Sie anschließend anhand dieser Liste auf dem Cloud-Mac. Zugriffstoken für private Quellen sollten über kontrollierte Umgebungsvariablen eingespeist werden.

brew bundle dump --force
brew bundle check
brew bundle install

Prüfkriterium: Die Brewfile lässt sich in einem sauberen Verzeichnis ausführen, ohne dass vertrauliche Token in das Repository geschrieben werden müssen.

Git

Repository-Identität und Projektberechtigungen trennen

Prüfen Sie Benutzername, Commit-E-Mail-Adresse, Standardbranch und Zeilenumbruchregeln. Wenn mehrere Projekte unterschiedliche Repository-Berechtigungen verwenden, konfigurieren Sie Schlüsseldateien und Host-Aliase getrennt. Lassen Sie nicht zu, dass ein hochprivilegierter Zugang alle Build-Aufgaben abdeckt.

git config --global --list
git remote -v
ssh -T git@your-git-host

Prüfkriterium: Abruf, Commit und Submodulzugriff verwenden jeweils die erwartete Identität; Token erscheinen nicht in den Protokollen.

Signatur und Kommandozeile

Vertrauliche Materialien außerhalb des Build-Prozesses halten

Zertifikate, private Schlüssel und Signaturzugangsdaten sollten über einen vom Team freigegebenen sicheren Prozess importiert und projektbezogen mit den geringsten erforderlichen Berechtigungen eingerichtet werden. Tools wie Node, Ruby, Python und CocoaPods sollten versionsgebunden sein; Versionsdateien gehören ins Repository.

node --version
ruby --version
python3 --version
pod --version

Prüfkriterium: Eine neue Sitzung kann die Umgebung anhand der Versionsdateien wiederherstellen; Build-Protokolle enthalten keine Zugangsdaten.

CI/CD-Anbindung

Den Cloud-Mac als nachvollziehbaren permanenten Build-Knoten einsetzen

Definieren Sie bei der Anbindung des GitLab CI Runners zunächst die Aufgaben des Knotens und registrieren Sie anschließend den Executor. Ein Knoten kann mehrere Warteschlangen bedienen, doch Signaturaufgaben mit hohen Berechtigungen und normale Kompilierungsaufgaben sollten unterschiedliche Tags, Verzeichnisse und Berechtigungsbereiche verwenden.

Registrierung

GitLab CI Runner installieren und registrieren

Führen Sie die Installation mit den vom Projekt oder Team bereitgestellten Registrierungsdaten durch. Vergeben Sie Tags für Architektur, Xcode-Version und Aufgabentyp. Deaktivieren Sie die Annahme nicht getaggter Aufgaben, damit keine beliebige Pipeline den Build-Knoten belegt.

  • Runner-Namen und zugehöriges Projekt dokumentieren
  • Tags enthalten Toolchain und Aufgabentyp
  • Verzeichnisberechtigungen des Ausführungsbenutzers prüfen
Dauerbetrieb

Permanente Build-Aufgaben verwalten

Betreiben Sie den Runner als kontrollierte Hintergrundaufgabe und stellen Sie sicher, dass er nach einem Neustart wieder startet. Lassen Sie Build-Prozesse nicht dauerhaft in einer persönlichen Terminalsitzung laufen; eine getrennte Sitzung darf laufende Kompilierungen oder Tests nicht unterbrechen.

  • Prozessbesitzer und Startart prüfen
  • Anzahl gleichzeitig ausgeführter Aufgaben begrenzen
  • Beendigungsregeln für Aufgaben mit Zeitüberschreitung festlegen
Cache

Cache-Verzeichnisse und Bereinigungsgrenzen festlegen

Trennen Sie Abhängigkeits-Cache, DerivedData, Archive und endgültige Artefakte. Caches können wiederverwendet, Archive müssen nachverfolgt und temporäre Dateien je Pipeline bereinigt werden. Bei ungewöhnlichem Speicherwachstum lokalisieren Sie zunächst das Verzeichnis und löschen Sie keine unbekannten Projektdaten direkt.

  • Cache- und Artefaktpfade getrennt dokumentieren
  • Projektbezogene Verzeichnisse einrichten
  • Freien Speicher und Wachstumsursachen regelmäßig prüfen
Trennung

Signaturzugangsdaten und Repository-Berechtigungen trennen

Injizieren Sie pro Projekt nur die erforderlichen Berechtigungen und erlauben Sie Signaturaufgaben ausschließlich für geschützte Branches. Protokollieren Sie nur, ob Zugangsdaten erfolgreich geladen wurden; Passwörter, private Schlüssel, Token und Signaturmaterial dürfen nicht ausgegeben werden.

  • Vertrauliche Variablen schützen und Branches begrenzen
  • Normale Kompilierungs- und Signaturaufgaben mit unterschiedlichen Tags versehen
  • Temporäre Dateien nach Abschluss der Aufgabe löschen
Abnahmetest

Mit einer minimalen Pipeline prüfen statt alle Aufgaben direkt zu migrieren

  1. Ein Test-Repository ohne vertrauliche Daten abrufen.
  2. Xcode-, SDK- und Versionen der Abhängigkeitstools ausgeben.
  3. Einmal ohne Signatur kompilieren und das Artefakt speichern.
  4. Cache, Protokolle und temporäre Verzeichnisse nach Abschluss der Aufgabe prüfen.
Serviceverfügbarkeit

Servicestatus anhand einheitlicher Kennzahlen bewerten, nicht anhand einzelner Netzwerkschwankungen

Die Cloud-Mac-Knoten von MacMLab sind 365 Tage im Jahr verfügbar. Die Verbindungsqualität wird außerdem durch lokales Netzwerk, Richtlinien für ausgehenden Datenverkehr, Remote-Desktop-Parameter und Aufgabenlast beeinflusst. Bei der Analyse müssen diese Faktoren getrennt vom Knotenstatus dokumentiert werden.

Kennzahl zur Serviceverfügbarkeit
99.9%
Beobachtungszeitraum
90Tage

Wenn die Bestellung die geltenden Bedingungen erfüllt und als Plattformserviceproblem bestätigt wurde, erfolgt die Bearbeitung einer Servicegutschrift anhand der Servicebedingungen und der jeweiligen Bestelldokumentation.

Täglicher Status der letzten 90 Tage Die täglichen Aufzeichnungen dienen der Beurteilung der Kontinuität; maßgeblich sind der aktuelle Status und die Bestellinformationen, die das Portal tatsächlich zurückgibt.
Aufzeichnungen zum Normalbetrieb Von den frühesten bis zu den neuesten Aufzeichnungen
Fehler-Entscheidungsbaum

Vom Fehlerbild zum passenden Zweig – jeweils nur eine Variable ändern

Notieren Sie zuerst Zeitpunkt und originalen Fehler und führen Sie anschließend die Prüfungen durch. Installieren Sie Tools nicht gleichzeitig neu, wechseln Sie nicht zugleich das Netzwerk und bereinigen Sie keine Verzeichnisse parallel; andernfalls lässt sich selbst nach einer Wiederherstellung die Ursache nicht sicher bestimmen.

Start

Kann der Knoten eine Remote-Verbindung herstellen?

Bestätigen Sie zunächst Bestellstatus, Knotenregion und Verbindungsdaten im Portal und wählen Sie anschließend den zum Fehlerbild passendsten Zweig.

Keine Verbindung

Adresse reagiert nicht oder Zugangsdaten werden abgelehnt

  1. Bestätigen, dass die Verbindungsdaten aus der aktuellen Bestellung stammen.
  2. Lokales Netzwerk wechseln, Proxy pausieren und erneut testen.
  3. Originalen Client-Fehlertext und Zeitpunkt dokumentieren.

Einreichen: Bestellnummer, Knotenregion, Typ des lokalen Netzwerks, Fehler-Screenshot und Clientname.

Langsame Reaktion

Verzögerte Anzeige, träge Eingaben oder langsame Aufgaben

  1. Auflösung und Bildqualität des Remote-Desktops reduzieren.
  2. Verzögerung der Desktop-Anzeige von der Dauer von Terminalbefehlen unterscheiden.
  3. CPU, Arbeitsspeicher, Speicher und parallele Aufgaben prüfen.

Einreichen:Name des langsamen Vorgangs, Start- und Endzeit, Anzahl paralleler Aufgaben und bereinigte Ressourcenübersicht.

Speicherplatz

Schreibfehler oder anhaltend sinkender freier Speicher

  1. Größe der Projekt-, Cache-, Archiv- und Protokollverzeichnisse prüfen.
  2. Prüfen, ob fehlgeschlagene Aufgaben temporäre Dateien hinterlassen haben.
  3. Nur wiederherstellbare Caches bereinigen; unbekannte Daten nicht löschen.

Einreichen:Freier Speicher, am schnellsten wachsendes Verzeichnis, letzte Aufgaben sowie bereinigte Ergebnisse vor und nach der Bereinigung.

Build fehlgeschlagen

Fehler in Compiler, Abhängigkeiten oder Signaturprozess

  1. Xcode-, SDK- und Versionen der Abhängigkeitstools dokumentieren.
  2. Die minimale Build-Aufgabe in einem sauberen Verzeichnis reproduzieren.
  3. Namen der Umgebungsvariablen lokal und in CI vergleichen.

Einreichen:Fehlgeschlagener Befehl, Exit-Code, erster aussagekräftiger Fehler und relevante bereinigte Protokollausschnitte.

Knotenfehler

Mehrere unabhängige Vorgänge fallen gleichzeitig aus

  1. Einzelnes Repository, Tool und einzelnen Client als Ursache ausschließen.
  2. Gemeinsame Symptome in Terminal und grafischer Oberfläche dokumentieren.
  3. Wiederholte Versuche beenden und die aktuellen Informationen sichern.

Einreichen: Bestellnummer, Knotenregion, Zeitverlauf des Fehlers, Auswirkungsbereich und der zuletzt erfolgreich ausgeführte Vorgang.

Support kontaktieren

Technische Probleme bevorzugt per Ticket, allgemeine Fragen per Support-E-Mail

MacMLab bietet extern ausschließlich Portal-Tickets und Support-E-Mail als Kontaktwege an. Fragen zu bestehenden Bestellungen, Knoten oder Abrechnungen sollten bevorzugt per Ticket eingereicht werden, damit sie der Bestellung zugeordnet und laufend aktualisiert werden können.

Empfohlener Weg

Im Portal ein Ticket einreichen

Geeignet für fehlgeschlagene Verbindungen, Knotenfehler, Build-Umgebungen, Abrechnungsstatus und bestellbezogene Fragen. Schreiben Sie im Ticket zuerst das Ergebnis und führen Sie anschließend die Reproduktionsschritte chronologisch auf.

Empfohlener Titel Knotenregion + Fehlerbild + Zeitpunkt des ersten Auftretens
Reihenfolge des Inhalts Bestellnummer → Auswirkungsbereich → Reproduktionsschritte → Originaler Fehlertext → Bereits durchgeführte Prüfungen
Anforderungen an Anhänge Nur bereinigte Screenshots und Protokollzusammenfassungen hochladen; Passwörter, private Schlüssel, Token und Signaturzugangsdaten schwärzen
Im Portal ein Ticket einreichen
Allgemeine Fragen

Support-E-Mail senden

Geeignet für Konfigurationsfragen vor der Bestellung, Anforderungen von Unternehmen, Feedback zur Dokumentation oder Fälle, in denen die Anmeldung im Portal nicht möglich ist.

support@macminilab.com
Datenschutzhinweis

Supportmitarbeiter benötigen keine geheimen Informationen von Ihnen

Senden Sie keine Systempasswörter, privaten Schlüssel, Zugriffstoken, Signaturzugangsdaten oder vollständigen Geschäftsdaten. Protokolle sollten den Fehlerkontext bewahren, aber Repository-Adressen, Benutzernamen und Schlüsselwerte ersetzen.

Hinweise zur Datenverarbeitung anzeigen

Bestellnummer und Reproduktionsschritte bereithalten und anschließend das Supportteam übernehmen lassen

Bei bestehenden Bestellungen reichen Sie bitte ein Ticket über das Portal ein. Wenn Sie noch Modell, Laufzeit oder Knotenstandorte vergleichen, können Sie zunächst die zwei Tarife und die Abrechnungsstruktur ansehen.

Ticket im Portal einreichen Miettarife anzeigen