Statt nach Abteilungen zu sortieren, prüfen Sie Verbindung, Build, Speicher, Leistung, Abrechnung und Knotenstatus Schritt für Schritt. Nach der Basisdiagnose kann das Ticket gezielt bearbeitet werden.
Mit vollständigen Belegen kann der Support zunächst feststellen, ob das Problem den Knoten, das Gerät, den Systemzugriff oder die Projektumgebung betrifft.
Raten Sie nicht zuerst nach der Ursache. Notieren Sie das direkt beobachtete Symptom, den Umfang und die Reihenfolge und folgen Sie dann dem passenden Prüfpfad. Bei mehreren Symptomen ist das zuerst aufgetretene maßgeblich.
Prüfen Sie zuerst Gerätestatus, Zugriffsmethode, lokales Ausgangsnetzwerk und Systemzeit. Unterscheiden Sie anschließend zwischen Timeout, verweigerter Berechtigung, geändertem Fingerabdruck und unterbrochener grafischer Sitzung.
Schritte zur Verbindungsprüfung anzeigenBewahren Sie den vollständigen Befehl, Exit-Code und ersten aussagekräftigen Fehler auf. Vergleichen Sie Xcode, macOS, Lockdateien und Projekt-Branch mit der erfolgreichen Basis.
Build-Fehlerbehebung öffnenPrüfen Sie freien Speicher auf dem Systemvolume, abgeleitete Daten, Build-Cache, Modelldateien und temporäre Dateien. Verlassen Sie sich nicht nur auf die Größe des Projektordners.
Speicherprüfung öffnenErfassen Sie CPU, Speicherdruck, freien Speicher und lange laufende Aufgaben gleichzeitig. So erkennen Sie Ressourcenlimits, Konkurrenz zwischen Aufgaben oder veränderte Projekteingaben.
Leistungsdiagnose öffnenHalten Sie Bestellkennung, Abrechnungszeitraum und Zahlungsergebnis aus der Konsole bereit. Bestellungen werden in USD abgerechnet; unterstützt werden USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe).
Abrechnung in der Konsole anzeigenStellen Sie zunächst fest, ob ein einzelnes Gerät, ein einzelner Knoten oder mehrere Standorte betroffen sind. Notieren Sie den tatsächlichen Knoten und den letzten erfolgreichen Zugriff; ersetzen Sie den Knotennamen nicht durch einen Standort.
Definition des Servicestatus anzeigenVerbindungsprobleme entstehen häufig durch Status, Berechtigungsumfang, lokales Netzwerk oder Zeitabweichungen. Die Prüfung in dieser Reihenfolge verhindert, dass wiederholte Versuche die ursprüngliche Situation verwischen.
Prüfen Sie Bestellkennung, aktuellen Knoten und Gerätestatus. Verwenden Sie keinen alten Browser-Screenshot als aktuelles Ergebnis; maßgeblich ist der aktuelle Status aus der Konsole.
Prüfen Sie beim Kopieren von Host, Benutzer und Port jeden Eintrag einzeln, damit Sie nicht Daten eines anderen Geräts oder einer alten Sitzung verwenden. Im Ticket genügt die verwendete Datenart; vollständige Geheimnisse gehören nicht hinein.
Bei Befehlszeilenaufgaben prüfen Sie zuerst SSH. Für Xcode mit grafischer Oberfläche testen Sie anschließend den Remote-Desktop. Dokumentieren Sie beide Ergebnisse getrennt.
Notieren Sie Netzwerktyp sowie Proxy- oder Unternehmens-Firewall-Nutzung und führen Sie einen Vergleichstest über ein anderes kontrolliertes Netzwerk durch. Melden Sie nur die Testergebnisse, nicht die vollständige interne Netzwerkkonfiguration.
Deutliche Zeitabweichungen können Zertifikate, Signaturen und Zugriffsprüfungen beeinflussen. Notieren Sie die Zeitzone und stellen Sie sicher, dass Ticket- und Protokollzeit zusammenpassen.
Die Fehlerzusammenfassung am Ende der Build-Ausgabe ist meist nicht die Ursache. Speichern Sie das vollständige Protokoll, suchen Sie den frühesten eindeutigen Fehler und vergleichen Sie dieselbe Eingabe mit der letzten erfolgreichen Basis.
sw_vers
xcodebuild -version
git rev-parse --short HEAD
git status --short
df -h /
xcodebuild -scheme App -configuration ReleaseVergewissern Sie sich vor der Ausführung, dass die Befehle keine Geheimwerte ausgeben. Bei Verwendung eines Abhängigkeitsmanagers erfassen Sie außerdem die Zusammenfassung der Lockdatei und das Ergebnis des Installationsbefehls.
Schlagen ein Minimaltestprojekt und das Produktionsprojekt in derselben Phase fehl oder zeigen Systembefehle ebenfalls Fehler, dokumentieren Sie macOS, Xcode, freien Speicher und den vollständigen Exit-Code.
Funktioniert das Minimalprojekt auf demselben Gerät, während der Zielbranch nach Änderungen an Lockdatei, Build-Parametern oder Ressourcen fehlschlägt, prüfen Sie zuerst die Projektänderungen.
Übermitteln Sie Xcode- und macOS-Version, Zusammenfassung der Abhängigkeits-Lockdatei, vollständigen xcodebuild-Befehl, Exit-Code sowie anonymisierte Ausgabe vor und nach dem ersten aussagekräftigen Fehler.
Aktualisieren Sie während der Analyse weder Abhängigkeiten noch Konfiguration.
Bewahren Sie das Originalprotokoll separat auf und erstellen Sie vor dem Teilen eine anonymisierte Kopie.
Prüfen Sie die Umgebungsbasis mit dem kleinsten Scheme oder einem Testprojekt.
Vergleichen Sie Versionen, Parameter, Cache-Status und Aufgabeneingaben.
Eine längere Laufzeit beweist noch keinen Gerätefehler. Erfassen Sie mindestens die Basislaufzeit derselben Eingabe, Ressourcenspitzen und parallele Aufgaben, bevor Sie Bereinigung, Ausbau oder eine andere Konfiguration wählen.
top -l 1 -o cpu
memory_pressure
df -h /
ps -axo pid,etime,command
M4 · 16GB · 256GB
Geeignet für Kompilierung einzelner Projekte, kurze Tests und Automatisierung mit geringer Parallelität. Bei dauerhaft hohem Speicherdruck reduzieren Sie zuerst die Parallelität und vergleichen Sie mit HopVM M4 24.
M4 · 24GB · 512GB
Geeignet für Entwicklungswerkzeuge, Simulatoren und Automatisierungsaufgaben gleichzeitig. Verwenden große Modelle oder schwere Builds dauerhaft Swap, ziehen Sie HopVM M4 Pro 64 in Betracht.
M4 Pro · 64GB · 2TB
Geeignet für Inferenz großer Modelle, schwere Builds und speicherintensive Workflows. Erfassen Sie vor dem Upgrade weiterhin Eingabegröße und Spitzenwerte, damit Netzwerkwartezeiten nicht mit fehlender Rechenleistung verwechselt werden.
Prüfen Sie, ob abgeleitete Daten, alte Build-Artefakte, ungenutzte Simulatordaten und Download-Caches neu erzeugt werden können. Prüfen Sie vor dem Löschen, ob das Projekt auf lokale Einzelartefakte angewiesen ist.
Sind Quelldateien klein, während Modelle, Medien oder Build-Archive dauerhaft wachsen, können Sie die vorgesehenen Zusatzoptionen +1TB SSD oder +2TB SSD prüfen.
Dokumentieren Sie Leerlauf, reguläre Aufgaben und maximale Parallelität getrennt. Nur anhaltender Ressourcendruck rechtfertigt ein Upgrade; bei gelegentlichen Spitzen suchen Sie zuerst die auslösende Aufgabe.
Alle Knoten sind für einen normalen Betrieb an 365 Tagen im Jahr ausgelegt. Die letzten 90 Tage werden täglich erfasst; die folgenden 30 Abschnitte fassen jeweils drei Kalendertage zusammen.
Grün steht für normalen Betrieb; Gelb kennzeichnet ausschließlich geschlossene Ereignisse und bedeutet keine aktuelle Störung.
Erfasst werden Knotenkonnektivität, Gerätestatus, Auswirkungsbereich, Beginn und Wiederherstellung sowie die Schlussfolgerung nach Abschluss eines Ereignisses. Ein Build-Fehler in einem einzelnen Projekt zählt nicht automatisch als Knotenausfall.
Reichen Sie über die Konsole Bestellkennung, tatsächlichen Knoten, Problemzeit und Zeitzone, Auswirkungsbereich sowie Verbindungsnachweise ein. Bei erfüllten Voraussetzungen beantragen Sie nach den im Servicevertrag festgelegten Nachweisen und Fristen eine Entschädigung.
Das Ticket sollte auch Außenstehenden eine Reproduktion mit denselben Schritten ermöglichen. Verwenden Sie die echte Bestellkennung und den tatsächlichen Knoten aus der Konsole, nicht Gerätenamen oder interne Teamkürzel.
Bestellkennung:
Tatsächlicher Knoten: SG / JP / KR / HK / US-E / US-W
Problemzeit und Zeitzone:
Letzte störungsfreie Zeit:
Auswirkungsbereich:
Reproduktionsschritte:
1.
2.
3.
Erwartetes Ergebnis:
Tatsächliches Ergebnis:
Exit-Code oder Fehlertyp:
Anonymisierter Protokollausschnitt:Die sechs Knoten sind Singapur, Japan (Tokio), Korea (Seoul), Hongkong, US-Ost und US-West. Behalten Sie nur den Code des tatsächlich verwendeten Knotens.
Die Bestellkennung verknüpft das Gerät; wählen Sie für den Knoten den tatsächlichen Wert aus SG, JP, KR, HK, US-E oder US-W.
Geben Sie das erste Auftreten, den letzten normalen Zeitpunkt und die Zeitzone an, damit Statusaufzeichnungen und Benutzerprotokolle abgeglichen werden können.
Beginnen Sie mit einem bekannten Normalzustand und dokumentieren Sie Befehle, Eingaben und Reihenfolge Schritt für Schritt, einschließlich der wichtigen Aktionen vor dem Fehler.
Beschreiben Sie getrennt, was geschehen sollte und was tatsächlich geschah. Schreiben Sie nicht nur „nicht nutzbar“ oder „sehr langsam“.
Übermitteln Sie bevorzugt den ersten aussagekräftigen Fehler, Exit-Code und Auftretensschritt statt nur die letzte Protokollzeile.
Bewahren Sie Aufrufbeziehungen, Zeitangaben und Fehlertypen auf; entfernen Sie Passwörter, vollständige Schlüssel, Token, Zahlungsdaten und Projektheimnisse.
Unterschiedliche Probleme erfordern unterschiedliche Nachweise. Solange Auswirkungsbereich und Umgebung nicht geprüft sind, werden keine nicht verifizierbaren Wiederherstellungszeiten zugesagt.
| Problemtyp | Durch HopVM prüfbarer Umfang | Vom Benutzer bereitzustellen | Ergebnis der Bewertung |
|---|---|---|---|
| Knotenkonnektivität | Knotenstatus, Netzwerkerreichbarkeit, Auswirkungsbereich und Statusaufzeichnungen | Tatsächlicher Knoten, Quellnetzwerk, Zeit und Zeitzone, Vergleichstest | Einzelnen Ausgang, einzelnes Gerät oder Knotenauswirkung unterscheiden |
| Gerätestatus | Gerätebetriebsstatus, Ressourcenbereitstellungsaufzeichnungen und Konsolenverknüpfung | Bestellkennung, letzter normaler Zeitpunkt, Anzahl betroffener Aufgaben | Abgleichen, ob Gerätestatus und Konsolenergebnis übereinstimmen |
| Systemzugriff | Umfang der Zugriffsdaten, Sitzungseinstieg und systemweite Verbindungsmerkmale | Zugriffsmethode, Fehlertyp sowie anonymisierte Fingerabdruck- oder Berechtigungsergebnisse | Timeout, Berechtigung, Zeitabweichung und lokale Netzwerkbeschränkung unterscheiden |
| Entwicklungswerkzeuge | Umgebung und Systemressourcen des Geräts auf Normalbetrieb prüfen | Xcode, macOS, Abhängigkeitsversionen, vollständiger Befehl, Exit-Code und Minimalreproduktion | Feststellen, ob die Analyse bei Projektabhängigkeiten oder Drittanbieterwerkzeugen fortgesetzt werden muss |
| Abrechnung und Bestellung | Bestellstatus, Abrechnungszeitraum, Zahlungsergebnis und Buchungsaufzeichnungen | Bestellkennung, Kategorie der Zahlungsmethode, Zeitpunkt und Konsolenergebnis | Maßgeblich sind die in Echtzeit von Konsole und Zahlungs-Gateway gelieferten Bestell- und Statusdaten |
Knotenkonnektivität, Gerätestatus, Systemzugriff, Bestellzuordnung und serviceseitige Statusaufzeichnungen.
Leistungsschwankungen, sporadische Verbindungen, Fehler in bestimmten Build-Phasen und Probleme bei bestimmten Eingaben.
Fehler in Drittanbieterabhängigkeiten, Projektcodefehler, Logik von Build-Skripten und unbestätigte Kompatibilitätsprobleme von Werkzeugen.
Probleme mit bestehenden Bestellungen, Verbindungen und Gerätestatus reichen Sie bitte über die Konsole ein, damit die tatsächlichen Ressourcen zugeordnet werden können. Bei dringenden Ereignissen nennen Sie zuerst Auswirkungsbereich, tatsächlichen Knoten, Problemzeit und letzten normalen Zeitpunkt.
Wenn Sie die Konsole nicht öffnen können, senden Sie eine E-Mail an support@hopvm.com. Verwenden Sie im Text weiterhin die Nachweisvorlage dieser Seite und entfernen Sie alle Geheimwerte.