ホストは復旧してオンラインなのに、正式版だけが署名もApp Store Connectへのアップロードもできない。
最短の解決策は、単一のMacに依存せず、低頻度なら再構築可能な基準と必要時に使える予備ノード、固定公開チームなら温備ノード、厳格なSLAがあるなら故障ドメインを分けた双活ノードを用意することです。署名情報、構成基準、制品、ログは故障したMacの外部に保存し、最後は実際のリリース流水線で復旧を証明します。
この手順は、1台または少数のMacビルドサーバーを管理し、ハードウェア障害による公開停止を心配する企業IT担当者向けです。Xcodeのビルド、署名、App Store Connectへのアップロードを管理する開発生産性担当者、固定予備機・弾性のある遠隔Mac・混合ノード群を比較する技術責任者にも適しています。
障害前に、復旧できる公開基準を作る
最初に、PRビルド、テスト、署名付きアーカイブ、正式版アップロードを同じ「ビルド成功」と扱わないでください。ホストに接続できる状態、Runnerがオンラインの状態、コンパイルが通る状態、署名が通る状態、App Store Connectへのアップロードが完了した状態は、それぞれ別の到達点です。
Appleの証明書管理では、証明書の確認や失効が独立した作業として扱われます。証明書の一覧と失効手順は、Appleの証明書管理資料と証明書を失効する手順を基準に、復旧 runbook へ記録してください。
次の項目を、故障したMacだけに残さない構成にします。
- リポジトリ、依存関係ロックファイル、サブモジュールの取得先
- Xcodeの版、macOSの版、追加ツール、SDK、CI Agentの設定
- macOSアカウント、SSH公開鍵、Runnerのラベルとルーティング条件
- 署名証明書、秘密鍵、Provisioning Profile、App Store Connect API Key
- 最後に成功したログ、アーカイブ、アップロード先、処理状態
- RTO、RPO、公開窓、責任者、承認者
RTOやRPOは、一般的な推奨値をそのまま採用するものではありません。業務影響分析、契約上のSLA、過去の演習記録から決め、NISTのIT継続計画ガイドが示す計画・復旧・検証の考え方に沿って見直します。
第一段階：障害発生直後に、状態を混同せず止血する
障害を検知した直後は、原因が分からないまま再起動を繰り返さないことが重要です。電源断、ネットワーク経路、ディスク障害、CI Runnerの離脱、証明書や外部認証の異常を分けて記録します。
最初に行う確認は次の順序です。
- CI管理画面で故障ノードへの新規ジョブ割り当てを停止する
- 外部監視、CI制御面、システムログ、最後の成功ジョブを保存する
- SSH接続だけでなく、Runnerの登録状態とジョブ実行履歴を確認する
- 署名サービスやApp Store Connect側の障害を、Mac本体の障害と分離する
- 不正アクセスやマルウェアの兆候があれば、元ノードを隔離する
社内で「検知から15分以内に初期判定する」などの運用枠を定めている場合、その時間内に原因を断定するのではなく、影響範囲と安全な切り替え先を確定します。セキュリティ事故の疑いがあるディスクイメージを、そのまま本番署名環境へ戻すことは避けてください。
GitHub Actionsの自ホストRunnerを利用している場合は、Runnerの登録、ラベル、ルーティングに関する公式資料を参照し、オンライン表示だけを復旧判定にしない設計にします。
第二段階：予備Macへ切り替え、基準から環境を再構成する
切り替え方式は、チームの公開頻度と停止許容度で決めます。低頻度のチームは、コードと設定から再構築できる冷備に加え、必要なときに利用できる遠隔Macを調達先として登録します。固定の公開日程がある場合は、XcodeやCI Agentの初期設定まで済ませた温備ノードが適します。
厳格なSLAを契約や社内制度で定めている場合は、2つのノードを同じ電源・ネットワーク・管理経路に置かない構成を検討します。ただし、ノード数や切り替え時間は製品仕様から決まるものではなく、実際の演習で測定してください。
切り替え時は、次の順番を崩さないでください。
- 予備Macの所有者、接続経路、隔離状態を確認します。
- macOSアカウント、管理用SSH、リモート管理経路を有効にします。
- Xcode、追加ツール、SDK、依存関係の取得を構成基準と照合します。
- CI Agentを登録し、専用ラベルまたはキュー規則で対象ジョブだけを送ります。
- 作業領域を消去し、クリーンチェックアウトから依存関係を解決します。
- 非重要なテストや検証ジョブを抑制し、署名付き公開ジョブの容量を確保します。
- 予備ノードでログ、制品、状態通知が従来の保存先へ到達することを確認します。
SSHの接続確認は、あくまで経路確認です。たとえば ssh user@backup-mac で接続できても、Xcodeの版、キーチェーン、Runnerラベル、書き込み権限が一致しているとは限りません。構成基準の各項目に、実行結果と確認者を残してください。
第三段階：署名情報を再構成し、公開経路を分離する
Xcodeのビルド環境を別のMacへ移す際、古いキーチェーンを丸ごとコピーする方法は、復旧完了の証拠になりません。証明書と秘密鍵、Provisioning Profile、App Store Connect API Key、ログインアカウントを別々に確認します。
Provisioning Profileは、AppleのApp Store用プロファイル作成手順に沿って、対象アプリ、チーム、署名 identity、用途を照合します。API Keyについては、App Store Connect APIの公式資料を基準に、発行者、Key ID、権限、保管場所、失効状態、監査記録を確認してください。
秘密鍵とAPI Keyは、企業が承認した認証情報管理基盤または管理対象バックアップから注入します。一般のビルドや第三者コードを扱うノードと、正式版に署名するノードを分離できるなら、署名処理は専用の信頼ノードに限定します。
FAQ：復旧設計で先に決めるべきこと
本文の手順とは別に、調達と演習の判断に直結する質問を整理します。
Macビルドサーバー停止後の復旧で、最初に何を確認しますか？
まず故障ノードへのジョブ投入を止め、ホスト、ネットワーク、Runner、ディスク、署名サービスを切り分けます。その後、最後に成功したジョブのログとアーカイブを保存し、セキュリティ事故の兆候があれば元ノードを隔離します。予備Macの起動より前に、証拠保存と切り替え範囲の確定を済ませてください。
iOS CIに予備Macが必要になる判断基準は何ですか？
公開停止が契約、売上、審査日程に影響するなら、単一ノードの復旧だけに依存しない設計が必要です。低頻度なら再構築基準と調達手順、固定公開なら温備、厳格な継続性なら分離された複数ノードを選びます。必要性はノード数ではなく、公開失敗時の業務影響で評価します。
Xcode環境のバックアップで、何を保存すべきですか？
Xcodeの版だけでは足りません。macOSの設定、追加ツール、依存関係ロックファイル、CI Agent、Runnerラベル、作業領域の初期化方法、署名証明書、秘密鍵、プロファイル、API Key、ログと制品の保存先を分離して管理します。秘密情報は通常のソースバックアップと同じ場所へ置かないでください。
冷備、温備、双活Macの違いをどう説明すべきですか？
冷備は故障後に基準から作り直す方式、温備は初期化済みのノードを待機させる方式、双活は複数ノードへ処理を分散しながら一方の故障を吸収する方式です。温備や双活を選んでも、署名情報や外部サービスが単一障害点なら公開は止まります。全経路を演習対象にしてください。
最終段階：完全な流水線で復旧を証明する
復旧判定は、Runnerがオンラインになった時点ではなく、クリーンチェックアウトからApp Store Connectの処理状態まで確認した時点に置きます。Appleが案内するビルドのアップロード手順に沿って、アーカイブ作成とアップロードの両方を検証します。
最低限、次を順に実行します。
- クリーンなチェックアウト
- 依存関係の解決
- Xcodeによるコンパイル
- テストの実行
- アーカイブの作成
- 証明書とProvisioning Profileによる署名
- App Store Connectへのアップロード
- CIへの成功状態の返却
- ログと制品の外部保存
記録する項目は、使用したXcodeの版、ノード identity、署名 identity、ジョブID、ログの保存先、制品の識別子、App Store Connectの処理状態です。最後に管理された再起動、または元ノードへの切り戻し演習を行い、当番担当者が同じ手順を再現できることを確認します。
復旧方式を選ぶための比較表
| 方式 | 適する条件 | 復旧時の主な作業 | 見落としやすい制約 |
|---|---|---|---|
| 冷備 | 公開頻度が低く、基準から再構築できる | Macの用意、Xcode・Agent設定、署名情報の注入、全流水線の検証 | 環境差分と容量不足が発生しやすい |
| 温備 | 固定の公開日程があり、切り替えを短くしたい | ノードの健全性確認、ジョブ切り替え、署名境界の確認 | 待機ノードのXcode更新、認証情報の失効確認が必要 |
| 故障ドメイン分離の双活 | 厳格なSLAや継続的な公開が必要 | キュー制御、成果物整合性、署名専用経路、切り戻し検証 | 複数ノードだけでは外部認証やネットワーク障害を吸収できない |
| 混合構成 | 通常負荷と公開ピークの差が大きい | 固定ノードを維持し、必要時だけ遠隔Macへ切り流す | 予備ノードの初期化とアクセス権を事前確認する必要がある |
KVMFLUXの企業向け利用シーンを確認する場合も、最初から本番ノードの代替と決めるのではなく、既存の構成基準を予備Macで再現できるかを検証対象にしてください。
復旧証跡の合格ラインを表にする
| 確認段階 | 合格条件 | 残す証跡 |
|---|---|---|
| ホスト到達 | 管理経路と必要なアカウントが利用できる | 接続記録、ノード identity |
| Runner稼働 | 対象ラベルでジョブを受け付ける | 登録状態、ルーティング記録 |
| ビルド成功 | クリーンチェックアウトからコンパイルとテストが完了する | Xcodeの版、依存関係、ログ |
| 署名成功 | 正しい証明書、秘密鍵、プロファイルでアーカイブを作成できる | 署名 identity、監査記録 |
| アップロード完了 | App Store Connect側で制品の処理状態を確認できる | 制品識別子、アップロード結果 |
| 切り戻し可能 | 当番担当者が元構成または別ノードへ戻せる | 演習記録、手順の差分 |
復旧後の最初の週は、実際に判定できた時刻、切り替えを止めた箇所、手作業、認証情報への依存、予備容量の不足を振り返ります。その記録に基づいて冷備を維持するか、温備へ移行するか、故障ドメインを分けた双活へ進むかを決めてください。金額、復旧時間、利用率を一般論で埋めず、演習記録、購買記録、CIログ、または自社の実測値から算出します。
単一のMacを使い続ける構成は、平常時には管理しやすい一方、故障時にXcode環境、署名、Runner、アップロード経路が同時に確認対象になります。固定の予備機を購入する方式も、ハードウェアの遊休、更新、保守、設置場所の制約を抱えます。そこで、通常は自社ノードを使い、公開ピークや障害演習だけKVMFLUXの遠隔Macを接続する方法は、物理機を増やす前の検証手段になります。
ただし、実際の採用判断では、まず既存ノード数、公開頻度、目標RTO・RPO、Xcode環境、署名境界を整理してください。そのうえで隔離した遠隔Macを1台用意し、クリーンチェックアウトから署名とアップロードまでを本番相当の流水線で検証すると、予備能力が本当に機能するかを判断できます。料金や利用条件を確認する場合は、KVMFLUXの料金案内を見ながら、単なる接続可否ではなく、切り替え演習の結果を基準に導入を決めてください。