ENGINEERING SUPPORT

まず証拠を残し、クラウドMacの障害範囲を絞り込む

実行順に構成したエンジニアリングガイドです。まずデバイスとネットワークを確認し、次にXcode、署名、CI環境を調べ、最後にストレージ、アップグレード、復旧へ進みます。

6種類 エンジニアリング問題の入口
5拠点 選択可能なノード
365日 ノード稼働中
診断ラン RUN / SUPPORT
依存関係の順に確認

接続 → 環境 → ビルド → データ

READY
01 / デバイス
デバイスID、ノード、ホストフィンガープリント
02 / ネットワーク
ローカル接続、ルート、ポート、遅延
03 / ツールチェーン
macOS、Xcode、証明書、依存関係
04 / タスク
再現コマンド、ログ、終了コード、時刻
チケット提出前 ログをマスキングし、実施済みの手順を記録
GUIDE INDEX

現在のボトルネックから始めれば、最初から読む必要はありません

6つの入口で、本人確認、システム変更、開発ツール、自動化タスク、ネットワーク経路、注文情報を扱います。各項目で、最初に調べること、残す情報、チケットを提出するタイミングを案内します。

CONNECTION ORDER

接続に失敗したら、まず対象マシン、次に接続ツールを確認

ホストアドレス、ポート、認証情報を確認する前にクライアントを何度も切り替えないでください。以下の4ステップを順番に実行し、各ステップで次の検証可能な情報を得ます。

  1. 01

    デバイス情報を確認

    コンソールにログインし、対象注文でデバイスID、選択ノード、ホストアドレス、SSHポート、現在の認証情報を確認します。複数デバイスを並行して使う場合は、注文番号とデバイスIDを先に対応付けます。

    保持する情報 注文番号、デバイスID、ノード、ポート
  2. 02

    ホストフィンガープリントを照合

    初回接続では、クライアントに表示されたフィンガープリントをコンソールの記録と照合します。デバイス再インストール後に変化した場合は、変更履歴を確認してからローカルの古い項目を削除し、警告を無視しないでください。

    ssh-keygen -R example-host
    ssh -p 22 user@example-host
  3. 03

    まずSSHの基準を確立

    まず有線ネットワークからDNS、ポート、SSHをテストします。成功したらログイン時刻、出口ネットワーク、コマンドラインの応答を記録します。失敗時は完全なエラー情報を残し、「接続に失敗しました」の1行だけを抜き出さないでください。

    判断 タイムアウトはルートまたはポート、接続拒否は対象サービス、認証失敗は認証情報と権限を優先して確認します。
  4. 04

    次にGUI接続を設定

    SSHの基準が安定してから、GUIに必要なアドレス、ポート、クライアントバージョン、ローカルファイアウォールを確認します。画面が途切れる場合は、解像度、エンコード設定、ネットワーク遅延も記録します。

    注意点 GUIが使えることは、高ビットレートのメディアプレビューがローカル表示と同等であることを意味しません。実際の経路で検証してください。
NETWORK MEASUREMENT

5ノードのping中央値を同じ条件で比較する

以下は主要都市からシンガポール、日本(東京)、韓国(ソウル)、香港、米国西部へのルート差を示します。データはノード選択の参考であり、アプリのスループット、GUIフレームレート、タスク完了時間を保証するものではありません。

テスト時間帯 平日14:00–16:00 UTC+8
サンプル数 各ノード50回
接続方式 ギガビット有線ネットワーク
統計値 往復遅延の中央値
3都市から5つのVMDebugノードへのping中央値の目安(単位:ミリ秒)
テスト元 通信事業者 シンガポール 日本(東京) 韓国(ソウル) 香港 米国西部
上海 中国電信 71 ms 42 ms 46 ms 34 ms 141 ms
深圳 中国聯通 44 ms 55 ms 59 ms 18 ms 157 ms
北京 中国移動 91 ms 48 ms 39 ms 63 ms 138 ms
まずローカルを測定

Wi-Fiとローカル出口の変動を除外

LANケーブルで直接接続し、大容量ファイルの同期、ビデオ会議、システムアップデートを停止します。ローカルゲートウェイとノードアドレスを連続してテストし、両方が同時に揺れる場合は、まずローカル接続を対処します。

次にルートを確認

中央値だけでは体感のすべてを説明できない

リモート操作には、パケットロス、ジッター、上り帯域幅、クライアントのエンコードも影響します。ネットワーク問題を提出する際は、通信事業者、都市、テスト時間帯、サンプル数、traceroute結果を併記してください。

XCODE DIAGNOSTICS

署名失敗時に環境を先に削除せず、5層の依存関係を順に絞り込む

同じエラーでも、証明書の利用不可、プロファイル不一致、Keychainのアクセス権、キャッシュ汚染、ビルドパラメータの差異が原因になり得ます。まず元のログを保存し、以下の順に確認してください。

  1. 01

    証明書

    対象証明書が存在し、有効期限内で、証明書と秘密鍵が対応し、現在のビルドユーザーが読み取れることを確認します。まず署名IDを一覧表示し、すべての資料を再インポートしないでください。

    security find-identity -v -p codesigning
  2. 02

    Provisioning Profile

    Bundle Identifier、チームID、証明書タイプ、デバイス範囲、Capability宣言を確認します。手動署名のプロジェクトでは、設定が古いキャッシュではなく対象ファイルを指していることを確認します。

    CODE_SIGN_STYLE / PROVISIONING_PROFILE_SPECIFIER
  3. 03

    Keychain権限

    CIユーザーと対話ログインユーザーでは、Keychainの検索リストが異なる場合があります。対象Keychainのロック解除、検索パスへの追加、ビルドプロセスによる秘密鍵の読み取り許可を確認します。

    security list-keychains
  4. 04

    DerivedData

    現在のパスと失敗したタスクを記録してから、対象プロジェクトの派生データだけを削除します。すべてのキャッシュ削除を最初に行うと、比較可能なビルド証拠を失います。

    xcodebuild -showBuildSettings
  5. 05

    ビルドログ

    完全なコマンド、Scheme、Configuration、SDK、Xcodeバージョン、終了コード、最初の失敗箇所を保存します。最後の要約行ではなく、最初の根本原因エラーを優先して確認します。

    xcodebuild -version
CI/CD RUNNER

ランナーを常設の作業ディレクトリではなく、再現可能な実行単位として扱う

専用の物理Macでビルドタスクを継続実行できますが、安定性はID、ディレクトリ、キャッシュ、キー、ロールバック範囲に左右されます。変更ごとに「何を変え、どう検証し、どう戻すか」を説明できる状態にします。

ランナー接続チェックリスト 5 CHECKS
  1. 01

    ランナーIDを登録

    各デバイスに識別可能なランナー名とタグを付け、登録範囲、サービスユーザー、起動方法を記録します。複数ランナーで判別できない同じ名前を共有しないでください。

  2. 02

    作業ディレクトリを分離

    リポジトリ、ブランチ、タスク単位で独立したディレクトリを作成し、並列タスクが同じDerivedData、アーカイブ、依存関係の出力先へ書き込まないようにします。

  3. 03

    キャッシュに上限を設ける

    再生成可能なキャッシュと保持必須の成果物を分けます。削除前にディレクトリ容量、最終使用時刻、タスクの所属を記録し、全削除によるコールドスタートを避けます。

  4. 04

    実行時にキーを注入

    キーはタスク実行時だけプロセス環境または一時Keychainに入れ、ログのエコーを無効にします。終了後は一時資料を削除し、アクセスをロックします。

  5. 05

    失敗時のロールバックを定義

    ランナー、Xcode、依存関係を更新する前にバージョン記録を残します。検証に失敗したら、設定ファイル、ツールチェーンの選択、キャッシュインデックスを復元し、変更を重ねないでください。

作業ディレクトリ

タスクごとに一意のパスを生成

パスには少なくともプロジェクトID、タスクID、試行回数を含めます。削除処理は今回のタスクディレクトリだけを対象にし、並列ビルドの誤削除を防ぎます。

WORK_ROOT="$HOME/ci-work"
JOB_DIR="$WORK_ROOT/$PROJECT/$RUN_ID"
mkdir -p "$JOB_DIR"
失敗の証拠

終了前に4種類の情報をアーカイブ

ランナーバージョン、ツールチェーンバージョン、完全な終了コード、最初の根本原因ログを保存します。キャッシュヒット率とディスク空き容量もタスク概要に記録し、前後を比較できるようにします。

  • ランナーとmacOSのバージョン
  • Xcodeのパスとバージョン
  • コマンド、終了コード、ログ
  • ディスク空き容量とキャッシュ状態
STORAGE & TB5

追加ストレージを接続する前に復旧可能なコピーを作り、接続前にトポロジーを図にする

追加ストレージとThunderbolt 5の並列接続は、データ経路と権限範囲を変えます。フォーマット、マウントポイント変更、デバイス切断の前に、データコピーとタスク停止状態を確認してください。

追加ストレージ

マウント前の確認

  1. データコピーを確認

    重要なコード、素材、ビルド成果物、設定は少なくとも1つの独立したコピーを保持します。検証前のボリュームを唯一の保存先にしないでください。

  2. ディスク情報を記録

    ボリューム名、ファイルシステム、容量、デバイスID、想定マウントポイントを記録し、表示順だけで対象ディスクを判断しないでください。

  3. アクセス権を確認

    ビルドまたはメディアタスクを実行するユーザーが必要なディレクトリ権限を持つことを確認します。所有権の問題を回避するために全体の権限を緩めないでください。

  4. 読み書きを検証

    削除可能なテストファイルで作成、読み取り、名前変更、削除を確認してから、実際の作業ディレクトリを移行します。

Thunderbolt 5

複数デバイスの接続順序

  1. 物理トポロジーを図にする

    各Mac、ケーブルの向き、共有ストレージ、タスクの役割を示します。上流・下流のデバイスを特定できない状態で接続を変更しないでください。

  2. 権限範囲を統一

    どのデバイスが書き込み、どれが読み取り専用かを決め、自動化タスクには独立したディレクトリを設定して同時上書きを防ぎます。

  3. 経路を1台ずつ検証

    デバイスを1台追加するたびに接続、権限、読み書きをテストします。すべて配線してからまとめて調査しないでください。

  4. タスクの逆順で切断

    まず書き込みとビルドタスクを停止し、キャッシュがディスクに反映されたことを確認してからボリュームをアンマウントし、経路末端からデバイスを切断します。

UPGRADE & RECOVERY

システムアップグレードには検証機、基準、復旧資料を用意する

すべてのノードは365日継続稼働しています。macOSとツールチェーンのアップグレードはタスクの進行に合わせて変更時間を設定し、まず重要度の低いタスクで検証してから長期稼働ランナーへ展開します。

アップグレードの実行手順 6 PHASES
  1. 01

    スナップショット形式のチェックリストを作成

    コードの状態、依存関係ロックファイル、Homebrew一覧、Xcodeパス、証明書名、Keychain一覧、ランナー設定、ディスク空き容量をエクスポートします。

  2. 02

    再生成できないデータをバックアップ

    プライベート設定、署名資料、ビルド成果物、プロジェクトデータを独立した場所へ移し、少なくとも1ファイルを実際に復元できることを確認します。

  3. 03

    ツールチェーンの互換性を検証

    対象macOS、Xcode、コマンドラインツール、パッケージマネージャー、ランナー、プロジェクト依存関係の互換範囲を確認し、保持必須の旧バージョンを記録します。

  4. 04

    書き込みタスクを停止

    CIキュー、素材処理、データ同期を停止し、作業ディレクトリ、キャッシュ、追加ストレージへ書き込むプロセスがないことを確認します。

  5. 05

    最小限の受け入れテストを完了

    アップグレード後、SSH、ディスク、Xcodeバージョン、証明書読み取り、依存関係復元、テスト、アーカイブ、成果物ダウンロードを順番に検証します。

  6. 06

    新しい基準を記録

    最初に成功したタスクの所要時間、ログ、キャッシュ状態、ディスク空き容量を保存してから、並列タスクを段階的に戻します。キューを一度に全開放しないでください。

停止条件

次の状況では先にロールバック

  • 重要な証明書または秘密鍵を読み取れない
  • プロジェクトが必要とするXcodeバージョンを利用できない
  • 追加ストレージが読み取り専用またはマウント異常になる
  • 同じ基準コマンドで新たな安定した失敗が発生する

根本原因が明確になる前に複数のコンポーネントを連続してアップグレードすると、システム、ツールチェーン、プロジェクト設定の影響をログで切り分けられなくなります。

チケット資料

サポート担当者がそのまま再現できるようにする

  • 注文番号とデバイスID
  • 問題発生時刻と選択ノード
  • macOS、Xcode、ランナーのバージョン
  • 最小限の再現手順と期待結果
  • マスキング済みの完全なログと終了コード
  • 実施した確認とその結果
コンソールチケットを提出
NEXT ACTION

ログのマスキングが済んだら、実行単位をサポートチームへ引き渡す

既存の注文に関する問題は、デバイスID、再現手順、完全なエラーコンテキストを添えてコンソールからチケットを提出してください。未注文の構成に関する質問は、専用のサポートメールでお問い合わせいただけます。

support@vmdebug.com