Diese Seite enthält die Diagnosebefehle für die drei häufigsten Problemarten: Verbindung, Build und Netzwerk. Rund 80 % unserer Support-Tickets lassen sich in unter 10 Minuten im Selbstservice lösen – für den Rest gilt: Bei Störungstickets antworten wir innerhalb von maximal 2 Stunden.
Persönlichen Support gibt es über genau zwei Kanäle: Ticket im Kundenportal und E-Mail. Beide werden direkt vom Bereitschaftsingenieur bearbeitet – ohne Callcenter-Weiterleitung.
Geeignet für: Instanzstörungen, Rückerstattungsanfragen, Migrationstermine und alles, was sich auf eine konkrete Maschine bezieht. Weg: Im Kundenportal anmelden → Tickets → Neu erstellen. Der gesamte Bearbeitungsverlauf wird protokolliert, Statusänderungen werden automatisch per E-Mail gemeldet.
Erstreaktion ≤ 2 Std.
Geeignet für: Probleme beim Anmelden im Kundenportal, Kontosicherheit, Rechnungen und geschäftliche Anliegen. Schreiben Sie an support@armmini.com und geben Sie Ihre registrierte E-Mail-Adresse sowie die Instanz-ID im Text an – das spart eine Rückfrage.
Erstreaktion ≤ 8 Std.
Das Fehlerbehebungs-Handbuch auf dieser Seite deckt die drei Bereiche Verbindung, Build und Netzwerk ab; unter „So stellen Sie eine Verbindung her“ finden Sie die vollständige VNC/SSH-Anleitung samt Schnellreferenz für Störungen; unter „Häufige Fragen“ stehen Einträge zu Abrechnung und Berechtigungen. Ein Blick ins Handbuch ist meist schneller als das Warten auf die Erstreaktion.
| Stufe | Typisches Szenario | Erstreaktion | Status-Updates | Empfohlener Kanal |
|---|---|---|---|---|
| P1 | Instanz nicht erreichbar / Störung auf Knotenebene | ≤ 30 Min. | Alle 60 Min. | Ticket im Kundenportal |
| P2 | Einzelne Funktion beeinträchtigt (z. B. VNC funktioniert, SSH nicht) | ≤ 2 Std. | Alle 4 Std. | Ticket im Kundenportal |
| P3 | Nutzungsfragen, Konfigurationshilfe | ≤ 4 Std. | Nach Bearbeitungsstand | Ticket oder E-Mail |
| P4 | Feedback, Geschäfts- und Kooperationsanfragen | ≤ 24 Std. | Nach Bearbeitungsstand |
Unser Support-Team arbeitet in zwei Zeitzonen (UTC+8 und UTC-8) im Schichtbetrieb. Die SLA gelten in Kalenderstunden, auch an Wochenenden und Feiertagen. Die Einstufung des Schweregrads nehmen wir anhand der Auswirkung selbst vor – Sie müssen sie im Ticket nicht angeben.
Neustart, Neuinstallation und das Zurücksetzen von Zugangsdaten erfordern keinen menschlichen Support. Die Power-Steuerung im Kundenportal läuft über einen Out-of-Band-Kanal und funktioniert selbst dann, wenn das System komplett eingefroren ist – ein Vorteil dedizierter physischer Maschinen.
Weg: Kundenportal → Instanz → Power → Neustart. Die Maschine wird vollständig ausgeschaltet und wieder eingeschaltet, die Wiederherstellung dauert rund 90 Sekunden. Die Festplattendaten bleiben unberührt, nicht gespeicherte Arbeit geht jedoch verloren. Die erste Maßnahme bei schwarzem VNC-Bildschirm oder eingefrorenem System.
Weg: Kundenportal → Instanz → System → Neu installieren. Die gewünschte macOS-Version wählen Sie aus der Liste aus. Die Neuinstallation löscht die gesamte Festplatte, dauert 25–40 Minuten, neue VNC/SSH-Zugangsdaten werden per E-Mail zugestellt. Pro Abrechnungszeitraum ist eine kostenlose Neuinstallation inklusive.
Weg: Kundenportal → Instanz → Zugriff → VNC-Passwort zurücksetzen. Die Änderung wirkt sofort, das neue Passwort wird nur einmal auf der Seite angezeigt – bitte sofort sichern. Nutzen Sie diese Funktion bei vergessenem Passwort, Verdacht auf Kompromittierung oder Übergabe der Maschine; SSH und die Daten auf der Maschine sind davon nicht betroffen.
Weg: Kundenportal → Instanz → Zugriff → SSH-Public-Key. Nach dem Einfügen des neuen Public Keys wird dieser innerhalb von 60 Sekunden in die authorized_keys geschrieben; alte Schlüssel können optional gleichzeitig widerrufen werden. Unterstützt werden ed25519 und RSA (≥ 3072 Bit), pro Instanz sind maximal 5 Schlüssel möglich.
Gehen Sie die Schritte der Reihe nach durch – zu jedem Schritt gibt es eine überprüfbare Ausgabe. Bleibt das Problem danach bestehen, fügen Sie die Ausgabe des letzten Schritts ins Ticket ein – wir übernehmen dann direkt an dieser Stelle.
Symptom: Der VNC-Client zeigt „verbunden“ an, das Bild ist komplett schwarz oder bleibt bei grauem Bildschirm stehen, Maus und Tastatur reagieren nicht.
$ sudo launchctl list | grep -i screensharing
$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
Done.
$ sudo pmset -a displaysleep 0 sleep 0Symptom: ssh reagiert lange nicht und meldet dann Operation timed out, oder es kommt sofort Permission denied zurück.
sudo pfctl -d aus, um die Regeln vorübergehend zu deaktivieren, bevor Sie korrigieren.$ ping -c 5 <Öffentliche-IP-der-Instanz>
$ chmod 600 ~/.ssh/id_ed25519
$ ssh -vvv -o ConnectTimeout=10 dev@<Öffentliche-IP-der-Instanz>
$ sudo pfctl -sr | grep 22Symptom: xcodebuild meldet in der CI errSecInternalComponent oder User interaction is not allowed, während der lokale GUI-Build problemlos funktioniert.
$ security unlock-keychain -p "$KEYCHAIN_PASS" ~/Library/Keychains/login.keychain-db
$ security set-key-partition-list -S apple-tool:,apple: -s -k "$KEYCHAIN_PASS" ~/Library/Keychains/login.keychain-db
$ security find-identity -v -p codesigning
1 valid identities foundLaden Sie das Runner-Installationspaket für arm64 macOS von der Runner-Einstellungsseite Ihrer CI-Plattform herunter; die folgenden Befehle führen Sie direkt in der SSH-Sitzung der Instanz aus.
$ mkdir ~/actions-runner && cd ~/actions-runner
$ tar xzf actions-runner-osx-arm64.tar.gz
$ ./config.sh --url <Repository- oder Organisations-URL> --token <Registrierungstoken> --labels self-hosted,macos,arm64
$ ./svc.sh install && ./svc.sh start
√ runner service startedInstallieren Sie den Runner mit svc.sh als launchd-Dienst statt run.sh im Vordergrund laufen zu lassen: automatische Wiederverbindung nach Verbindungsabbruch, automatischer Start nach Instanz-Neustart – ohne zusätzliches Keep-Alive-Skript. Das Registrierungstoken ist nur eine Stunde gültig; bei Ablauf einfach ein neues generieren.
$ brew install gitlab-runner
$ gitlab-runner register --executor shell --url <Ihre GitLab-URL> --token <Auth-Token> --tag-list macos,xcode,arm64
$ brew services start gitlab-runner
Successfully started `gitlab-runner`Wählen Sie als Executor shell – der Build läuft direkt in der macOS-Benutzersitzung mit vollem Zugriff auf die Xcode-Toolchain und den Simulator. Die Parallelität sollte bei 1 bleiben: Auf Apple Silicon nutzt ein Job alle Performance-Kerne exklusiv, was schneller ist, als wenn sich zwei Jobs die Kerne teilen.
Mischen Sie CI-Zertifikate nicht in die Login-Keychain. Legen Sie eine eigene build.keychain an, setzen Sie das Timeout auf 21600 Sekunden (6 Stunden) und führen Sie zu Beginn jedes Jobs einmal unlock aus – Signierungs-Popups gehören dann der Vergangenheit an.
Übergeben Sie xcodebuild mit -derivedDataPath ein festes Verzeichnis außerhalb des Jobs. Auf dedizierten physischen Maschinen bleibt der Cache über Jobs hinweg dauerhaft auf der Festplatte erhalten – bei großen Swift-Projekten ist die inkrementelle Kompilierung dadurch 40–70 % schneller als ein vollständiger Build.
Erstellen Sie mit xcrun simctl create die gängigen Gerätemodelle im Voraus und lassen Sie sie dauerhaft bestehen – UI-Tests überspringen dann den Kaltstart des Simulators, was pro Job meist 60–90 Sekunden spart. Da die Instanz nicht zurückgesetzt wird, gilt die einmalige Vorbereitung dauerhaft.
$ security create-keychain -p "$PASS" build.keychain
$ security set-keychain-settings -lut 21600 build.keychain
$ security unlock-keychain -p "$PASS" build.keychain
$ xcodebuild -scheme App -derivedDataPath ~/ci-cache/DerivedData buildJeder der fünf Standorte verfügt über eine Testadresse mit demselben Netzwerk-Ausgang wie die Produktionsinstanzen – ein Test dieser Adresse entspricht also einem Test Ihrer Instanz. Referenzwerte für die tatsächliche Latenz je Region finden Sie in der Latenztabelle auf der Seite „So stellen Sie eine Verbindung her“.
| Standort | Testadresse | Rechenzentrumsregion | Hinweis |
|---|---|---|---|
| Tokio | ping.tyo.armmini.com | Ostasien | Gleicher Ausgang wie die Tokio-Instanzen, Latenz spiegelt die tatsächliche Erfahrung wider |
| Seoul | ping.icn.armmini.com | Nordostasien | Gleicher Ausgang wie die Seoul-Instanzen |
| Silicon Valley | ping.sjc.armmini.com | Nordamerika-Westküste | Gleicher Ausgang wie die Silicon-Valley-Instanzen |
$ ping -c 20 ping.tyo.armmini.com
20 packets transmitted, 20 received, 0% loss
$ mtr -rwzbc 100 ping.tyo.armmini.com > mtr-report.txt
-r Berichtsmodus -c 100 sammelt 100 Pakete, dauert rund zwei Minutenmtr -rwzbc 100 zur passenden Standort-Testadresse aus und speichern Sie den Report.Probleme am Rechenzentrums-Ausgang bearbeiten wir noch am selben Tag; Paketverluste auf der Zwischenstrecke über verschiedene Netze hinweg erfordern eine Hop-für-Hop-Abstimmung mit dem Upstream-Provider und lassen sich meist innerhalb von 1–2 Werktagen eingrenzen – der Bearbeitungsstand wird laufend im Ticket aktualisiert.
Alle Standorte laufen 365 Tage im Jahr durchgehend – es gibt keine geplanten Unterbrechungen, die Ihre Mitwirkung erfordern; Hardwarewechsel an den Standorten erfolgen durch Ersatzsysteme, ohne Ihre Nutzungszeit zu beeinträchtigen. Kommt es dennoch zu einer Störung, gilt der folgende, vollständig nachvollziehbare Ablauf.
Der Monitoring-Alarm löst aus, der Bereitschafts-SRE greift ein. Alle fünf Standorte sind rund um die Uhr im Schichtbetrieb besetzt.
Die Auswirkung wird ermittelt, betroffene Nutzer erhalten die erste Störungs-E-Mail mit Symptom, Umfang und geschätzter Wiederherstellungszeit.
Alle 60 Minuten folgt eine E-Mail mit dem aktuellen Stand, bis zur vollständigen Wiederherstellung – ohne stille Reparaturen.
Die Ausfallzeit wird gegen die monatliche Verfügbarkeitszusage von 99,5 % berechnet; ein etwaiger Ausgleich an Nutzungszeit wird automatisch dem Konto gutgeschrieben, ohne dass Sie diesen beantragen müssen.
Veröffentlichung des Post-Mortem-Berichts: Ursache, vollständiger Zeitverlauf und Verbesserungsmaßnahmen – per E-Mail versendet und zusätzlich als Ankündigung im Kundenportal veröffentlicht.
Die konkreten Ausgleichsstufen und Ausnahmeregelungen (höhere Gewalt, Fehlbedienung durch den Nutzer) finden Sie in Kapitel 5 der Nutzungsbedingungen. Falls Sie eine Unterbrechung feststellen, zu der Sie keine Störungs-E-Mail von uns erhalten haben, erstellen Sie bitte direkt ein P1-Ticket – wir gleichen dies dann mit Ihren Monitoring-Aufzeichnungen ab.
Ob Wechsel des Standorts, Umzug von einem anderen Anbieter oder von einem lokalen Mac zu ArmMini: Unsere Ingenieure bieten dafür eine persönliche, kostenlose Begleitung. Umfang und Grenzen sind unten aufgeführt – bitte vorab durchlesen und dann einen Termin vereinbaren.
$ rsync -avzP --exclude 'Library/Caches' -e ssh ~/work/ dev@<Neue-Instanz-IP>:~/work/
-P ermöglicht Fortsetzung nach Abbruch, Tokio→Seoul im selben Segment real gemessen ca. 45–80 MB/s
sent 182.4G speedup is 1.31Fügen Sie die Ausgabe des letzten Schritts ins Ticket ein – der Bereitschaftsingenieur übernimmt direkt an Ihrem Abbruchpunkt. Bei Störungstickets antworten wir innerhalb von maximal 2 Stunden, auch an Wochenenden und Feiertagen.