接続できない
デバイスの状態、アクセス方法、ローカルの外向きネットワーク、システム時刻を確認し、タイムアウト、権限拒否、フィンガープリント変更、グラフィカルセッション切断を切り分けます。
接続チェック手順を見るまず再現し、その後エスカレーション
問題が起きたら、クラウドMacの状況を正確に記録する
部署別ではなく、接続不可、ビルド失敗、ディスク容量、パフォーマンス変動、請求、ノード状態の順に確認します。基本診断が完了すれば、チケットを効率的に調査できます。
6
障害カテゴリ
99.9%
目標稼働率
6
提供中のノード
診断ランブック
待機中の情報
症状を確認可能な記録に変える
影響範囲
単一タスク / 1台のデバイス / チーム全体
必要な時刻
発生時刻、タイムゾーン、直近の正常時刻
環境の基準値
macOS、Xcode、コマンド、終了コード
セキュリティ境界
匿名化したログのみを送信し、完全な秘密情報は送らない
証拠が揃っていれば、サポートチームはノード、デバイス、システムアクセス、プロジェクト環境のどこに問題があるかを先に判断できます。
症状から選択
現在の状況に最も近い入口を選ぶ
原因を先に推測しないでください。実際に確認した症状、影響範囲、発生順を記録し、該当する確認手順へ進みます。複数の症状がある場合は、最初に発生したものを基準にします。
ビルドに失敗する
完全なコマンド、終了コード、最初の有効なエラーを保存し、Xcode、macOS、依存関係ロックファイル、プロジェクトブランチが成功時の基準と一致するか確認します。
ビルド診断へ進むディスク容量
システムボリュームの空き容量、Derived Data、ビルドキャッシュ、モデルファイル、一時生成物を確認し、プロジェクトフォルダだけを見てシステムボリュームの圧迫を見落とさないようにします。
ストレージ確認手順を見るパフォーマンスの変動
CPU、メモリプレッシャー、ディスク空き容量、長時間タスクを同時に収集し、リソース上限、タスク競合、プロジェクト入力の変化を切り分けます。
パフォーマンス診断へ請求に関する問題
コンソールの注文ID、請求期間、支払い結果を準備してください。注文はすべてUSDで決済され、USDT-TRC20とVisa / Mastercard / Amex（Stripe経由）に対応しています。
コンソールで請求を確認ノード状態
1台のデバイス、1つのノード、複数拠点のどれに影響があるかを確認し、実際のノードと直近の正常アクセス時刻を記録します。ノード名を地理的位置で代用しないでください。
サービス状態の基準を見る接続前の確認
5つの基本情報。1つでも欠けると誤判断につながります
接続問題は、状態、認証情報の範囲、ローカルネットワーク、時刻のずれが原因になることがよくあります。順番に確認すれば、元の状況を上書きする再試行を避けられます。
-
01
コンソールでデバイス状態を確認
注文ID、現在のノード、デバイス状態を確認します。ブラウザキャッシュの古いスクリーンショットを現在の結果と混同しないでください。利用可能状態はコンソールのリアルタイム結果を基準にします。
-
02
アカウントとアクセス情報が同じデバイスのものか確認
ホスト、ユーザー、ポートをコピーする際は1項目ずつ確認し、別のデバイスや古いセッションの情報を混在させないでください。チケットには使用した情報の種類だけを記載し、完全な秘密情報は貼り付けないでください。
-
03
アクセス方法がタスクに合っているか確認
コマンドラインタスクではまずSSHを検証します。Xcodeのグラフィカルインターフェースが必要な場合のみリモートデスクトップを検証します。2つの結果を別々に記録し、一方の失敗で他方を判断しないでください。
-
04
ローカルの外向きネットワークを確認
現在のネットワーク種別、プロキシや企業ファイアウォールの有無を記録し、管理下の別ネットワークでも1回比較テストを行います。テスト結果のみを報告し、内部ネットワーク設定全体は送信しないでください。
-
05
ローカルとリモートのシステム時刻を確認
大きな時刻差は、証明書、署名、アクセス認証に影響します。タイムゾーンを記録し、チケットの発生時刻とログ時刻を対応させてください。
ビルド障害のトラブルシューティング
最初の有効なエラーを探し、環境かプロジェクトかを判断する
ビルド出力末尾の失敗概要は通常、根本原因ではありません。完全なログを保存し、最初に現れた明確なエラーを特定して、同じ入力を直近の成功基準と比較します。
環境情報の収集コマンド
読み取り専用チェック
sw_vers
xcodebuild -version
git rev-parse --short HEAD
git status --short
df -h /
xcodebuild -scheme App -configuration Release実行前に、コマンドが秘密情報を出力しないことを確認してください。依存関係管理ツールを使う場合は、ロックファイルの概要とインストールコマンドの結果も記録します。
無関係なプロジェクトも同時に失敗
最小テストプロジェクトと本番プロジェクトが同じ段階で失敗する、またはシステムコマンドにも異常がある場合は、macOS、Xcode、ディスク空き容量、完全な終了コードを記録します。
特定のブランチまたは依存関係の組み合わせだけが失敗
同じデバイスの最小プロジェクトは成功し、対象ブランチだけがロックファイル、ビルドパラメータ、リソース更新後に失敗する場合は、プロジェクトの変更を優先的に確認します。
バージョン、コマンド、終了コード、ログ抜粋
XcodeとmacOSのバージョン、依存関係ロックファイルの概要、完全なxcodebuildコマンド、終了コード、最初の有効なエラー前後の匿名化済み出力を送信します。
1
ブランチと入力を固定
診断中に依存関係を更新したり設定を切り替えたりしないでください。
2
完全な出力を保存
元のログは別途保存し、共有前に匿名化したコピーを作成します。
3
最小タスクを実行
最小のschemeまたはテストプロジェクトで環境の基準を検証します。
4
直近の成功記録と比較
バージョン、パラメータ、キャッシュ状態、タスク入力を比較します。
パフォーマンスとストレージ
「遅い」をCPU、メモリ、ディスク、タスク時間に分解する
1回の処理時間が延びただけでは、デバイスの異常とは限りません。同じ入力の基準時間、リソースピーク、並列タスクを最低限記録してから、クリーンアップ、容量追加、設定変更を判断します。
サンプリング項目
4種類の指標
アクティビティモニタとコマンドラインを突き合わせる
CPU
継続使用率、プロセス名、並列タスク数
top -l 1 -o cpu
メモリ
メモリプレッシャー、スワップ使用量、ピーク時点
memory_pressure
ディスク
システムボリュームの空き容量、キャッシュと生成物の増加
df -h /
長時間タスク
開始時刻、入力規模、実行時間
ps -axo pid,etime,command
HopVM M4 16
M4 · 16GB · 256GB
単一プロジェクトのコンパイル、短時間のテスト、低並列の自動化に適しています。メモリプレッシャーが長時間高い場合は、まず並列数を減らし、HopVM M4 24と比較してください。
HopVM M4 24
M4 · 24GB · 512GB
開発ツール、シミュレーター、自動化タスクの同時実行に適しています。大規模モデルや重いビルドでスワップを使い続ける場合は、HopVM M4 Pro 64を検討してください。
HopVM M4 Pro 64
M4 Pro · 64GB · 2TB
大規模モデルの推論、重いビルド、高メモリワークフローに適しています。アップグレード前に入力規模とピークを記録し、ネットワーク待ちを計算能力不足と混同しないようにします。
再生成できるデータから整理する
Derived Data、古いビルド生成物、不要なシミュレータデータ、ダウンロードキャッシュを再生成できるか確認します。削除前に、プロジェクトがローカル固有の生成物に依存していないか確認してください。
容量が増え続ける場合はストレージを追加
プロジェクトのソースは小さくても、モデル、メディア素材、ビルドアーカイブが増え続ける場合は、既定の+1TB SSDまたは+2TB SSDオプションを検討できます。
ピークと基準値を分けて記録
アイドル、通常タスク、ピーク並列実行の3段階を記録します。アップグレードの根拠にできるのは継続的なリソース圧迫であり、一時的なピークはまず発生タスクを特定してください。
サービス稼働率
99.9%
目標稼働率
すべてのノードは年間365日、継続的に稼働する設計です。直近90日間の状態を日次で記録し、以下の30区間で3日ごとの結果を集計します。
直近90日間の稼働概要
緑は正常稼働、黄は解決済みのイベントを示すだけで、現在の異常を意味しません。
正常稼働
解決済みイベント
集計基準：直近90日間の日次状態記録
状態記録に含まれる内容
ノード接続性、デバイス状態、影響範囲、開始時刻と復旧時刻、イベント解決後の結論を記録します。単一プロジェクトのビルドエラーは、ノード停止として直接カウントしません。
目標未達時の申請方法
コンソールから注文ID、実際のノード、問題の時刻とタイムゾーン、影響範囲、接続証拠を送信してください。条件を満たす場合は、サービス規約に定める証拠と期限に従って補償を申請できます。
チケット用証拠テンプレート
6項目を一度に明確に書き、追加質問を減らす
チケットは、現場にいない人でも同じ手順で再現できる内容にします。コンソールの実際の注文IDとノードを使い、デバイスのニックネームやチーム内の略称で代用しないでください。
推奨する本文構成
コピーして記入
注文ID：
実際のノード：SG / JP / KR / HK / US-E / US-W
問題の時刻とタイムゾーン：
直近の正常時刻：
影響範囲：
再現手順：
1.
2.
3.
期待する結果：
実際の結果：
終了コードまたはエラー種別：
匿名化済みログ抜粋：6つのノードは、シンガポール、日本（東京）、韓国（ソウル）、香港、米国東部、米国西部です。実際に使用したノードコードを1つだけ残してください。
注文とノード
注文IDはデバイスとの関連付けに使います。ノードはSG、JP、KR、HK、US-E、US-Wから実際の値を選択してください。
時刻とタイムゾーン
初回発生時刻、直近の正常時刻、タイムゾーンを明記し、状態記録とユーザーログを照合できるようにします。
再現手順
既知の正常状態から始め、コマンド、入力、操作順を省略せず、失敗前の重要な操作も記載します。
期待する結果と実際の結果
何が起きるはずだったか、実際に何が起きたかを分けて記述します。「使えない」「遅い」だけの説明は避けてください。
エラーと終了コード
ログの最後の1行だけをコピーするのではなく、最初の有効なエラー、終了コード、発生段階を優先して提供します。
匿名化済み出力
呼び出し関係、時刻、エラー種別を残し、パスワード、完全な鍵、トークン、支払い情報、プロジェクトの秘密情報を削除します。
対応範囲
サポートチームがまずサービス範囲を確認し、次の手順を案内します
問題ごとに必要な証拠は異なります。影響範囲と環境の確認が完了する前に、検証できない復旧時刻を約束することはありません。
| 問題の種類 | HopVMで確認できる範囲 | ユーザーが提供する情報 | 判定結果 |
|---|---|---|---|
| ノード接続性 | ノード状態、ネットワーク到達性、影響範囲、状態記録 | 実際のノード、送信元ネットワーク、時刻とタイムゾーン、比較テスト | 単一の出口、1台のデバイス、ノード全体への影響を切り分け |
| デバイス状態 | デバイス稼働状態、リソース提供記録、コンソール関連情報 | 注文ID、直近の正常時刻、影響を受けたタスク数 | デバイス状態がコンソール結果と一致するか確認 |
| システムアクセス | アクセス情報の範囲、セッション入口、システム層の接続症状 | アクセス方法、エラー種別、フィンガープリントまたは権限結果の匿名化情報 | タイムアウト、権限、時刻差、ローカルネットワーク制限を切り分け |
| 開発ツール | デバイス環境とシステムリソースが正常か確認する支援 | Xcode、macOS、依存関係のバージョン、完全なコマンド、終了コード、最小再現 | プロジェクト依存関係またはサードパーティツールの調査が必要か判断 |
| 請求と注文 | 注文状態、請求期間、支払い結果、会計記録 | 注文ID、支払い方法の種類、発生時刻、コンソール結果 | コンソールがリアルタイムで返す注文・決済ゲートウェイの状態を基準にする |
直接確認できる項目
ノード接続性、デバイス状態、システムアクセス入口、注文との関連、サービス側の状態記録。
共同で再現が必要な項目
パフォーマンス変動、断続的な接続、特定のビルド段階での失敗、特定の入力でのみ発生する問題。
プロジェクト側で継続対応が必要な項目
サードパーティ依存関係の不具合、プロジェクトコードのエラー、ビルドスクリプトのロジック、未検証のツール互換性問題。
エスカレーション窓口
基本診断が完了したら、ランブックをサポートチームへ引き渡す
既存の注文、接続、デバイス状態に関する問題は、実際のリソースと関連付けられるようコンソールからチケットを送信してください。緊急の場合は、影響範囲、実際のノード、問題の時刻、直近の正常時刻を先に明記します。
コンソールにアクセスできない場合は、次のアドレスへメールを送信できます： support@hopvm.com本文にはこのページの証拠テンプレートを使用し、すべての秘密情報を削除してください。