要約

  • Zone Networks の SLA では、故障した機器の交換品に電源が入れば、ソフトウェアの再導入、RAID の再構築、バックアップからの復元が続いていても、機器障害として数える停止時間が終わり得る。顧客は、この事業者側の時計と、自社サービスが実際に使えるようになるまでの時計を分けて管理する必要がある。
  • シドニーでの運用、二つの自律システム、Equinix SY3 および SY4 との関連には相応の公開根拠がある。一方で、Zone Networks が使うラック数、契約電力、予備機、ストレージ余力、迂回時の通信余力、異地バックアップの所在地は公表されておらず、建物全体の冗長性や10 Gbps の接続口を顧客向けの復旧余力とみなすことはできない。
  • 購入判断で問うべきなのは、通常時のプラン表だけではない。どの故障領域をまたいでコピーが置かれ、誰が何を復元し、交換機器の起動後にどれだけの作業が残り、DNS、ライセンス、秘密情報、接続元制限まで含めて事業を戻せるかを、日付のある契約と復元試験で確かめるべきである。

障害が起きると、二つの時計が同時に動き出す

ホスティング障害を一つの時間で表すと、最も重要な境界が消えてしまう。サーバーが故障した瞬間、Zone Networks が機器を診断し、交換品を用意し、電源を入れるまでの時計が動く。同じ瞬間に、顧客側では、データベースの整合性を確認し、オペレーティングシステムとミドルウェアを戻し、アプリケーションを起動し、外部からの通信を正しい宛先へ向け、利用者が再び取引できるまでの時計が動く。二つは同時に始まっても、同時に止まるとは限らない。

Zone Networks のService Level Agreementが明示するのは、そのずれである。機器故障について、交換機器が設置され電源を投入された後に行うソフトウェアの再導入、RAID の再構築、バックアップからの復元は、機器障害の停止時間から除かれ得る。つまり、事業者が扱う「機器が動く状態」は、顧客が必要とする「事業が動く状態」より先に成立し得る。これは言葉の細部ではない。復旧時間を誰が負担し、どの時間に補償が結び付くかを決める境界である。

この境界を理解するには、稼働率の数字だけを比較しても足りない。99.9％、99.99％、あるいは一部のページに現れる100％という表現は、同じ測定対象、同じ除外条件、同じ救済を指しているとは限らない。公開ページには表現の揺れがあり、法的文書は2018年1月の更新とされている。したがって、購入者にとって支配的なのは、ウェブ上で最も大きく見える数字ではなく、自分のサービス、施設、測定方法、連絡手順を名指しした、日付のあるサービス明細である。

二つの時計を分けると、質問も変わる。「交換に何時間かかるか」だけでなく、「交換品が起動した後、誰が、どのコピーから、どの順番で、何を戻すのか」と問えるようになる。さらに、復元中に必要なストレージ、通信、技術者、認証情報が同じ障害の影響を受けないかを確かめられる。復旧能力は、交換用の箱があるかどうかだけではなく、作業を最後まで通すための連鎖全体に宿る。

稼働を示す証拠と、復旧力を示す証拠は別である

Zone Networks を、単に古い商品ページだけが残る名前として扱うのも適切ではない。Australian Business Registerは、Zone Networks Pty Ltd を ABN 83 136 050 578、ACN 136 050 578の活動中のオーストラリア非公開会社として示している。ABN は2009年3月24日から有効で、ZONE NETWORKS という事業名は2011年8月から記録され、主たる所在地は NSW 2015である。これは法人の継続を裏付ける強い証拠だが、現在使えるサーバー台数や復旧実績までは示さない。

同社のホームページはクラウドホスティング、VPS、専用サーバー、コロケーションを掲げ、会社紹介は EMC のストレージや Juniper のルーティングおよびセキュリティ機器に触れている。顧客ポータルには商品区分、アカウントへの入口、サポート、告知、ネットワーク状況への導線がある。だが、ページが開き、商品名が並ぶことは、各商品が今すぐ注文できること、表示構成の在庫があること、障害時に使える予備分が確保されていることとは同義ではない。

現在のネットワーク観測は、運用の存在をもう一段支える。Cloudflare Radar はAS56106とAS45152をオーストラリアの Zone Networks の名称、ウェブサイト、同一組織の関連で結び付けている。法的な継続、公開ポータル、二つの自律システムが同じ方向を指すため、活動中のオーストラリアのホスティング兼ネットワーク事業者とみる判断は中程度の確かさを持つ。

ただし、ここで確かめられるのは「運用の痕跡」であって、「障害時に余力がある」という事実ではない。経路が観測されていることは、予備の筐体、空きラック、空き電力、複製済みのストレージ、復元を担当する人員の存在を証明しない。古い製品説明と現在の経路観測を合わせても、過去の構成がそのまま残るとも、最新の構成に置き換わったとも断定できない。運用の確からしさと、容量の確からしさを同じ尺度に載せないことが重要である。

また、オーストラリアの.com.auの会社と、名称が似た ZONENETWORKS.COM Inc.を混同してはならない。今回確認できる範囲には、親子会社、共通支配、資産共有、ネットワーク共有、運用上の関係を結ぶ根拠がない。名称の近さを使って別会社の規模や設備を補えば、まさに不足している容量証拠を想像で埋めることになる。

SLA が止めるのは、機器障害としての時間である

公開 SLA の読みどころは、稼働率の表題よりも、何を停止時間に含め、何を含めないかにある。交換機器へ電源を入れた時点で機器障害の時計が止まり得るなら、その後の作業は顧客の業務停止として残っていても、同じ区分では測られない。RAID の再構築はディスク群の整合した状態を取り戻す工程であり、バックアップ復元は必要なデータを使える場所へ戻す工程である。ソフトウェアの再導入も、起動媒体を用意するだけでは終わらず、版、設定、依存関係、証明書、鍵をそろえる必要がある。電源投入は復旧の終点ではなく、顧客側から見れば中間点になり得る。

SLA はさらに、保守、上流事業者や第三者による遅延、電力または供給上の問題、外部 DNS、DDoS、複数の非 HTTP サービスなどについて、救済の範囲を除外または限定している。クレジットの請求には顧客の行動が必要で、明記された救済はクレジットに限られる。障害で失われた注文、従業員の復旧作業、顧客への補償、規制対応の費用が、サービス料金のクレジットと同じ大きさになる理由はない。

Terms of Serviceも、契約主体だけでなく、請求、停止、解約、通知、データ削除、責任の境界を読むために欠かせない。技術障害だけを想定した復旧計画は、支払いの行き違い、ポータルに入れない状態、解約時の書き出し期限、連絡先の陳腐化に弱い。サーバーが正常でもアカウントが停止されれば、顧客にとってサービスは使えない。可用性は、物理機器、論理サービス、契約上のアクセスという三つの面を持つ。

したがって、購入者は一つの RTO だけを書いて終えるべきではない。少なくとも、事業者が機器を交換する目標、データを復元する目標、アプリケーションが利用可能になる目標、外部依存を含めて業務を再開する目標を区別したい。どの時点を SLA が測り、どの時点から先を顧客が担うかが明確になれば、補償と事業継続のずれも見える。契約上の時計を、経営上の時計の代用品にしてはならない。

電源投入の後に残る、顧客の復旧作業

交換用サーバーが立ち上がった後も、復旧は多数の手順を必要とする。まず、正しいファームウェア、RAID 構成、仮想化層または基本ソフトウェアを用意する。次に、データのどの時点を採用するかを決め、復元中に書き込みが進まないよう制御し、データベースとファイルの整合性を検査する。さらに、アプリケーションの設定、秘密情報、証明書、利用許諾、監視、定期処理を戻す。最後に、DNS や接続元制限を切り替え、外部サービスとの通信を確認し、利用者の操作で結果を確かめる。どれか一つが欠ければ、機器は稼働していても事業は戻らない。

Zone Networks のサーバー管理の案内は、自己管理、Bronze、Gold という層を示し、システム、データベース、ファイアウォール、監視、バックアップに関わる作業を掲げている。しかし、ページ上の図示だけでは、個々の契約で誰が復元作業を担うかを十分に確定できない。管理付きという言葉から、アプリケーションの完全復旧まで自動的に含まれると考えるのは危険である。

顧客が自己管理の専用サーバーを使う場合と、管理付き VPS を使う場合では、事業者に期待できる作業が異なる可能性がある。だが、どちらでも、顧客固有の業務知識は事業者だけでは補えない。正しいデータの締め時刻、注文番号の欠落、会計処理の重複、外部決済との不一致を判定できるのは、多くの場合、顧客の担当者である。技術的に起動したことと、業務上正しいことの間には検証の時間がある。

復元に必要な資源も見落とせない。バックアップ保管先から読み出す帯域、復元先の空き容量、RAID 再構築中の入出力性能、作業する技術者、顧客側の承認者が同時に必要になる。通常時には十分でも、複数顧客が同時に復旧を求める障害では競合する。公開情報には、復元の並列数、復元時の通信量、担当者数、優先順位が示されていない。だからこそ、平常時のサービス説明ではなく、障害条件下での復元試験が判断材料になる。

シドニーの施設名は、顧客の配置図ではない

Zone Networks の専用サーバー概要は、専用サーバーをシドニーの Equinix データセンターに置くと説明する。コロケーション案内は SY3 と SY4、共有ラックからフルラックまでの区分、電力割当、プライベートケージ、SY3 のネットワーク運用拠点に言及する。これらは、シドニーが広告上のホスティング中心地であることを示す。専用サーバーやコロケーションの物理的な重心をシドニーに置く判断には根拠がある。

しかし、施設名の列挙から個々の顧客の配置を作図することはできない。専用サーバー概要は、注文ごとの施設を特定していない。コロケーションのプランは、現在の空き、占有ラック数、ケージ番号、顧客が実際に使う電源系統を示さない。「SY3 と SY4 にいる」という説明だけでは、同じ顧客のワークロードが両方に複製されているのか、一方だけに置かれているのか、別々の商品が別々の建物にあるのかは分からない。

施設とワークロードを混同すると、二拠点という語が自動的に冗長性へ変換されてしまう。実際には、二つの建物でサービスを扱っていても、ある顧客の本番機、ストレージ、バックアップ、ネットワーク終端が一つの建物に集まっている可能性は残る。逆に、特定の契約で二拠点構成が用意されている可能性も否定はできない。公開証拠が足りない以上、どちらも事実として置くべきではない。

PeeringDB にあるシンガポールの施設記載も同じである。そこから読み取れるのは AS56106 のネットワーク接続地点に関する申告であり、顧客の計算資源やバックアップがシンガポールに置かれるという保証ではない。シドニーを越える通信上の存在を、第二都市の復旧拠点へ読み替えてはならない。サービスが世界中の利用者から到達できることと、計算資源が複数大陸に分散していることも別である。

建物の冗長性を、Zone Networks の余力へ足してはならない

Equinix のSY3 施設情報は、47 Bourke Road, Alexandria の施設について、総床面積6,894平方メートル、キャビネット当たり最低4 kVA、電力と冷却の N+1、発電機の冗長性と自立運転に関する仕様を掲載する。SY4 施設情報は、200 Bourke Road, Alexandria、総床面積7,445平方メートル、最低4 kVA、電力 N+1、冷却 N+20％などを示す。これらは建物運営者が示す施設全体の設計と能力であり、施設の実在と性格を理解するうえで価値がある。

それでも、6,894平方メートルや7,445平方メートルのうち Zone Networks が何平方メートルを使うかは分からない。最低キャビネット密度は同社の契約電力ではなく、N+1 は同社の各ラックが冗長な経路を実際に利用している証拠ではない。サーバーが単一電源装置であれば、建物に二つの供給経路があっても末端で一つになることがある。二重電源装置があっても、両方を同じ PDU へ接続すれば、期待した分離は得られない。公開情報には、その末端設計がない。

Equinix のシドニー都市圏ページは、複数施設と広い相互接続環境を示す。しかし、その都市圏全体の規模や接続相手を Zone Networks の資産として数えることはできない。建物、受電、UPS、発電機、冷却、物理警備を担うのは Equinix であり、Zone Networks は契約した空間の中で、サーバー、ネットワーク機器、通信契約、ソフトウェア、運用支援を組み合わせて小売サービスを作ると考えるのが妥当である。障害の責任境界も、建物運営者と小売事業者で同じではない。

建物全体が N+1 だから顧客サービスも N+1、と結論するには、間にある情報が多すぎる。Zone Networks が使うラック、電源経路、PDU、サーバー電源、ストレージ、ネットワーク終端、運用手順のすべてが冗長経路を利用し、障害時に切り替わる必要がある。さらに、その切り替えが顧客の負荷を支える容量を持たなければならない。施設仕様は必要条件の一部であって、顧客単位の復旧試験の代わりではない。

ラック、電力、予備機の「空き」は公開されていない

Zone Networks のコロケーション商品には、1U からフルラック、0.5A から20A までの区分、PDU ポート、IP、転送量の枠が示される。これは販売単位の形を説明するが、現在据え付け済みのラック数、稼働中のラック数、空いているラック数、契約済み電力、実消費電力を示さない。商品表の「20A」を、障害時にも別系統で使える20A と読むことはできない。

容量には少なくとも、設計上の容量、設置済み容量、通電済み容量、通常運用に使える容量、販売済み容量、予備として予約した容量、障害中にも使える容量という違いがある。公開商品は主に最初の「販売単位」を見せる。購入者が事業継続のために必要とするのは最後の「障害中にも使える余力」だが、その値は公開されていない。通常時の未使用率が分かっても、故障した電源系統やストレージと同じ故障領域にあれば、復旧には使えない。

予備機についても同様である。専用サーバーの特価ページに「余剰在庫」を思わせる表現があっても、数量と日付がなく、現在の交換在庫を証明しない。交換には、筐体だけでなく、互換するディスク、RAID コントローラー、メモリー、電源、ネットワーク部品が要る。古い世代の構成が商品ページに残っているなら、同一構成の部品をいつまで確保できるかという問いはむしろ重要になる。別構成へ移す場合は、ドライバー、起動方式、利用許諾、性能差が新たな復旧作業を生む。

公開されていない値は、ラック数、契約電力、ホスト数、利用率、過剰割当、SAN の物理容量と実用容量、複製方式、予備ノード、交換部品、販売済み在庫、バックアップ使用量、障害時に使える余力である。値がないことは、容量がないことを意味しない。しかし、容量があると認定する根拠にもならない。誠実な評価は「不在」と「非公開」を分け、ここでは後者として扱うべきである。

10 Gbps の接続口は、10 Gbps の避難路ではない

ネットワーク側には、現在性を示す有用な証拠がある。PeeringDB のAS56106 記録は、Zone Networks Pty Ltd との関連、NSW-IX の10 Gbps 接続口、シドニーとシンガポールの施設記載を示す。AS45152 記録は、Zone Networks Managed Hosting Solutions との関連、Equinix Sydney の10 Gbps 接続口、シドニー施設での存在を示す。両方には1～5 Gbps の申告通信量帯も記載されている。

ここで、接続口の最大速度、通常時の通信量、購入済みのトランジット、障害時に使える迂回容量を分けなければならない。10 Gbps はインターフェースの上限であり、常に10 Gbps の有効通信が保証されるという意味ではない。DDoS 時に洗浄できる量、別経路へ移したときの余力、顧客ごとの予約帯域も示さない。1～5 Gbps という帯も申告値であり、瞬間的な利用率や契約条件ではない。

現在の経路観測では、AS56106について八つの IPv4 経路、四つの上流、NSW-IX との関係が見え、AS45152について七つの IPv4 経路、AS56106 や Vocus を含む上流関係が見える。複数の上流が観測されることは、一つしかない場合よりも接続構造を考える材料になる。しかし、自律システム間の隣接は、光ファイバーが別の道路や別の建物入口を通ることを証明しない。異なる上流名でも、同じクロスコネクト、同じ配管、同じ電源、同じ機器を共有する可能性は公開情報から排除できない。

顧客固有のサービスが AS56106 と AS45152 のどちらに載るかも、公開商品だけでは確定できない。経路の多さを顧客ワークロードの多拠点性へ置き換えることもできない。ネットワーク障害の検証では、上流名だけでなく、物理的な引き込み、クロスコネクト、境界ルーター、電源、収容施設がどこまで分離され、片側喪失時に残る側が通常負荷を運べるかを確認する必要がある。

DDoS も容量の意味を変える。接続口が十分でも、上流で遮断されたり、対象 IP が null-route されたりすれば、アプリケーションは到達不能になる。SLA が DDoS や第三者要因を狭く扱うなら、顧客は攻撃時の連絡経路、判断者、遮断解除条件、代替宛先、DNS 切替の時間を自分の復旧計画に入れなければならない。ネットワークの存在証拠は強まっても、迂回能力の証拠は別に必要である。

商品プランは顧客の割当を示すが、設備総量を示さない

Zone Networks のクラウドホスティング概要は、Linux と Windows の共有ホスティング、Dell の機器、EMC SAN、日次バックアップ、可用性について説明する。クラウド VPS 概要は、自己修復型の仮想基盤、監視、日次バックアップ、Linux または Windows の選択を掲げる。これらは商品の設計思想を知る資料になるが、クラスタの大きさ、現行機器、空き資源、ストレージの故障領域を示さない。

管理付き cPanel VPSの表示では、4～8 vCPU、4～8 GB のメモリー、50～100 GB の SAN、1～3 TB の転送量というプランが並ぶ。管理付き Windows VPS の一プランには、8 vCPU、8 GB のメモリー、100 GB の SAN、3 TB の転送量が示され、別ノードへの移動や日次イメージにも触れる。これらの数字は一顧客に見せる論理的な割当であり、物理 CPU の総数、ホスト台数、過剰割当率、SAN の総容量を表さない。

「別ノードへ移せる」という説明が実際の復旧力になるには、別ノードが同じ障害を免れ、必要な CPU とメモリーを空け、同じストレージまたは健全な複製へ接続でき、管理面も動いていなければならない。全顧客の通常時割当を満たすだけの設備と、一台または一群が故障したときに残りを受け入れる設備は別である。後者を予約していなければ、平常時には効率的でも、障害時には移動先が足りなくなる。

プレミアム専用サーバーとエンタープライズ専用サーバーは、単一ソケットまたは二ソケットの構成、メモリー、ディスク、RAID、転送量、1 Gbps 接続口などを商品単位で示す。専用サーバー特価は、小売構成、転送量、50 GB から1 TB までのバックアップ商品、SY3 での監視、プライベートケージ、オンサイトとオフサイトの区分に触れる。だが、いずれも日付のある設備台帳ではなく、現在据え付け済みの台数、販売可能な台数、交換用に確保した台数を示さない。

商品表を読むときは、「顧客が買える形」と「事業者が持つ総量」を切り離したい。4 vCPU の商品が百件売れる設備があるのか、十件なのかは表から分からない。1 Gbps のポートを持つ専用機が並んでも、外部へ向かう共有経路が同じ量だけ増えるわけではない。50 GB から1 TB のバックアップ枠も、保管基盤の総量、使用率、復元時の読み出し能力を示さない。販売単位を足し上げて設備規模を推定するのは、分母のない計算である。

バックアップの予定表と、復元できた証拠の間

バックアップについて最も重要なのは、作成頻度だけではない。Zone Networks のAcceptable Use Policyは、特定サービスの日次イメージに触れる一方、顧客自身がローカルまたはオフサイトのバックアップを保持する責任を置く。これは、事業者側に何らかのコピー予定があるとしても、それだけを唯一の復旧手段として扱わないよう促す境界である。

SSD VPS の案内には、夜間バックアップと七日間保持が記されている。保持日数は、どの時点まで戻れるかを考える材料にはなる。しかし、各回が正常終了したか、バックアップが本番環境と同じ認証情報で削除できないか、同じストレージや同じ建物の障害を免れるか、どの速度で戻せるかは分からない。バックアップが存在しても、復元に必要な時間が事業の許容停止時間を超えれば、期待した継続性は得られない。

「オフサイト」という表現も、距離や故障領域を自動的に決めない。公開資料には、第二の保管施設の名称、都市、Zone Networks または別会社の管理境界、暗号化鍵の所在、複製の遅れ、削除方法、復元速度、試験履歴がない。SY3 の本番から SY4 へ置けば別建物ではあるが、同じ都市圏の出来事には相関し得る。別都市にあれば地理的な分離は増えるが、その事実は確認できない。シンガポールのネットワーク記載からバックアップの所在地を推測することもできない。

オーストラリア政府の定期バックアップに関する技術例は、調整されたバックアップ、復元試験、権限のない変更や削除からの保護を重視する。これは Zone Networks の実績を評価したものではないが、購入者が試験項目を作る助けになる。予定通りコピーしたか、別の認証境界にあるか、実際に戻したかという三つを分ければ、「毎日」という言葉だけで安心する誤りを避けられる。

復元試験は、ファイルが読めたところで終えてはいけない。データベースの整合性、アプリケーションの起動、利用者認証、証明書、外部 API、メール配送、DNS、監視、定期処理を含む業務の通し試験が必要である。その試験に要した時間を、交換機器の起動後に残る時間として測れば、二つ目の時計が初めて数値になる。バックアップ容量より、検証済みの復元経路のほうが事業回復には近い。

一つの障害が、複数の商品を同時に止める可能性

共有ホスティング、VPS、専用サーバー、コロケーションは商品名として分かれている。しかし、背後で同じラック電源、同じストレージ、同じハイパーバイザー群、同じ上流回線、同じ運用担当を共有すれば、一つの障害が複数商品へ広がる。公開情報は、商品間の故障領域を示していない。したがって、「別商品を契約したから分散した」とは限らない。

施設またはラックの電力障害では、建物の冗長設備が正常でも、特定ラックの PDU、ブレーカー、配線、サーバー電源に単一点が残り得る。共有ストレージまたはハイパーバイザーの障害では、計算ノードを替えてもデータへ到達できないことがある。上流、交換接続、クロスコネクト、ルーティングの障害では、サーバーが動いていても外部利用者が到達できない。DDoS では、設備の物理容量だけでなく、上流の処理能力と遮断判断が結果を左右する。

予備機不足は、一件の故障なら吸収できても、複数台または共通部品の故障では表面化する。サポートの遅れは、管理範囲が不明確なほど長引く。請求、停止、ポータルへのアクセス障害は、技術者へ連絡する経路そのものを狭める。バックアップの破損、共通認証情報、未試験の復元は、最後のコピーを必要とする瞬間に初めて問題になる。DNS、利用許諾、秘密情報、接続元 IP の許可リストは、別環境への移行時に物理機器とは別の障害物になる。

これらは Zone Networks で実際に発生した事故の一覧ではない。公開された商品構造と契約境界から、購入者が検証すべき故障経路を整理したものである。事実として言えるのは、どの経路についても顧客単位の試験結果や故障時余力が公開されていないということだ。可能性を事故歴として語らず、未確認の経路を未確認のまま質問へ変えることが、適切な調査になる。

相関障害を避けるには、二つのサービス名より二つの故障領域が必要である。別ラック、別電源系統、別ストレージ、別ネットワーク終端、別施設、別管理認証のどこまでが分かれているかを一つずつ確かめる。分離が一部だけなら、残る共通部分を明示する。完全な独立をうたうより、どの障害まで耐えられるかを限定して示すほうが、復旧設計として有用である。

オーストラリア内という説明だけでは、データの境界は閉じない

Zone Networks のPrivacy Policyは、収集した個人情報の大半をオーストラリアに保管するとしつつ、一部が海外に保管される可能性も認める。ここで対象となるのは、事業者が集めるアカウント関連の個人情報である。この記述を、すべての顧客ワークロード、バックアップ、ログ、サポートアクセス、委託先がオーストラリア内に限られるという保証へ広げることはできない。

オーストラリアのPrivacy Act 1988は連邦のプライバシー法制の枠組みを与えるが、具体的な適用は顧客、データ、状況によって異なる。OAIC のAPP 8ガイダンスは、海外への開示、海外委託先を実効的に管理している場合、通信が国外を通過する場合などを区別して扱う。IP 経路が海外を通ること、海外の施設に保存すること、海外の担当者がアクセスすることは、同じ出来事ではない。

OAIC のAPP 11ガイダンスは、合理的な安全措置、第三者サービスの危険、物理的管理、情報のライフサイクルを考慮するよう求める。これも Zone Networks への適合認定ではない。購入者が自ら、保管、アクセス、複製、削除、委託の実態を把握するための視点である。シドニーに本番サーバーがあるという一事実は、その全項目への回答にはならない。

APRA 規制下の組織にとって、CPS 230は重要業務の維持とサービス事業者リスクの管理を購入者側へ課す基準である。しかし、Zone Networks が APRA 規制対象の顧客へサービスを提供していることも、同社のサービスが個別顧客の管理策を満たすことも、公開資料からは確認できない。基準の存在を、事業者の認証や実績として使ってはならない。

所在地を契約するなら、「オーストラリア」という一語を構成要素へ分ける必要がある。本番データ、バックアップ、ログ、監視情報、サポートチケット、アカウント情報をそれぞれどこに置くか。誰がどの国からアクセスできるか。海外の委託先がいるか。削除後の複製はいつ消えるか。通信経路の通過と保存をどう区別するか。これらを明記して初めて、近接性がデータ主権の要求へ接続する。

復旧演習で、二つ目の時計を実測する

SLA を読んで境界を理解しても、顧客側の復旧時間はまだ推定にすぎない。それを実務で使える値に変えるのが復旧演習である。演習では「サーバー障害から復旧する」とだけ書かず、どの故障を仮定し、どの資源を使えないものとし、どの状態を業務再開と認めるかを先に決める必要がある。交換機器の電源が入った時点を一つの通過点として記録し、そこから顧客の利用確認までを別の区間として測れば、公開 SLA では見えにくい二つ目の時計が姿を現す。

最初の演習は、単一サーバーの機器故障を想定できる。予備機の選定、設置、通電までに誰が動き、どの時点で顧客へ通知されるかを記録する。その後、RAID の構成、基本ソフトウェア、設定、バックアップ、データ検証、アプリケーション起動を順に進め、各工程の開始と終了を残す。こうすれば、機器交換が速くても復元の読み出しや設定の再現に時間がかかるのか、それとも機器の調達自体が支配的なのかを分けて考えられる。

次の演習では、単一機器より広い故障領域を置く。ラック電源を使えない想定なら、同じラック内の予備機は復旧資源から外す。共有ストレージを使えない想定なら、健全な計算ノードがあっても元の SAN へ依存しない復元先が要る。上流またはクロスコネクトを使えない想定なら、経路広告が見えるだけでなく、残る通信経路が実際の負荷と復元通信を同時に運べるかを確かめる。故障の範囲を明示しなければ、演習は最も都合のよい資源だけを使う実演になってしまう。

バックアップ演習では、最新のコピーを一つ読むだけでは不十分である。保持期間内の別の時点を選べるか、壊れたデータを含むコピーを識別できるか、本番環境の認証情報を失っても保管先へ到達できるかを確認したい。さらに、復元先に十分な空きがあるか、読み出し通信と利用者向け通信が競合しないか、復元作業が他の顧客の同時要求で遅くならないかを問い直す。公開資料に復元の並列性や処理量がない以上、試験条件を記録しなければ、良い結果を混雑時へ一般化できない。

演習の終点は、監視画面の緑色やサーバーへの応答ではなく、業務上の受入条件で決める。利用者が認証できるか、直前までの取引がそろっているか、重複処理がないか、外部連携が成功するか、監査に必要な記録が残るかを顧客自身が確認する。技術担当だけで完了を宣言すると、業務部門が後から欠落を見つけ、時計が実質的に動き続けることがある。事業回復は、機器の生命反応ではなく、正しい結果を再び出せる状態で測るべきである。

演習には連絡と権限も含める。顧客ポータルへ入れない場合に使う連絡先、夜間に復元を承認できる担当者、DNS や証明書を変更できる担当者、第三者へ支援を求める条件を確かめる。秘密情報が本番サーバーだけに置かれていれば、サーバーを失ったとき復旧手順にも入れない。連絡先や権限が一人に集中していれば、その人が不在の時間が停止時間になる。こうした待ち時間は機器仕様に現れないが、二つ目の時計には確実に加算される。

結果は、成功または失敗の一語で残すのではなく、前提、使えなかった資源、使ったコピー、工程ごとの時間、手作業、判断待ち、検証結果とともに保存する。同じ演習を繰り返したとき、前回より速くなった理由が自動化なのか、たまたま担当者がそろっていたからなのかを区別できる。構成や担当が変わった後にも再実施すれば、古い成功記録を現在の回復力と取り違えにくい。

Zone Networks との協議では、この演習結果を SLA の数値と競わせる必要はない。二つは別の問いに答えるからである。SLA は、契約上どの停止をどう測り、どの救済があるかを定める。復旧演習は、顧客固有のデータと依存関係を含めて事業が戻るまでの実時間を示す。両方を並べれば、契約上の停止が終わった後に残る作業を予算化し、役割を割り当て、改善すべき最長工程を選べる。

買い手が確認すべきなのは、平常時の最大値ではなく障害時の残量

購入前の質問は、商品表の CPU、メモリー、ディスクから始めてもよいが、そこで終えてはいけない。最初に、契約する法人、サービス名、施設、SLA の版、測定開始点と終了点、除外条件、連絡方法を一枚のサービス明細にそろえる。法人は Zone Networks Pty Ltd であるか、対象は共有ホスティング、VPS、専用サーバー、コロケーションのどれか、SY3 か SY4 か、それ以外かを曖昧にしない。

次に、機器の故障領域を尋ねる。顧客のサーバーはどのラックと電源系統を使い、二重電源は別々の PDU へ接続されるか。仮想基盤なら、ホスト数、ストレージ方式、管理面、障害時に予約された計算資源を確認する。専用機なら、互換する予備筐体、ディスク、RAID 部品がどこにあり、交換後に同じ構成を再現できるかを確認する。数値が機密なら、少なくとも顧客負荷を引き受けられるという契約上の約束と試験結果を求めたい。

ネットワークについては、AS 番号と上流名だけでは足りない。顧客のサービスがどちらの自律システムに載り、境界ルーター、クロスコネクト、建物入口、電源がどこまで分離されているかを確認する。一経路が失われたとき、残る経路が通常負荷を運べるか、DDoS 時にどの段階で遮断するか、DNS 切替に誰が必要かを文書化する。10 Gbps の接続口があるという回答は、これらの代わりにならない。

バックアップについては、保存先の施設と都市、保管主体、暗号化、鍵、保持、削除、複製の遅れ、復元時の帯域を問う。さらに、日付のある完全復元試験を求める。試験はサーバー起動ではなく、データ検証とアプリケーション利用まで通す。目標復旧時点と目標復旧時間を定め、交換機器の電源投入から業務再開までに費やした時間を別に記録する。ここが SLA の外に残りやすい時計である。

最後に、支援範囲を役割表にする。Zone Networks が機器交換、基本ソフトウェア、RAID、バックアップ復元、データベース、アプリケーション、DNS のどこまでを担うか。顧客、第三者の開発会社、利用許諾元、DNS 運営者は何を担うか。夜間や休日に誰が承認し、ポータルへ入れない場合にどの連絡経路を使うか。責任の名前が付いていない作業は、障害時に待ち時間へ変わる。

評価の結論は「運用中」だが、「余力あり」ではない

公開証拠からは、Zone Networks を活動中のオーストラリアのホスティング兼ネットワーク事業者として扱うのが妥当である。法人登録、公開ポータル、二つの自律システム、現在観測される経路、シドニーの施設との整合が、その判断を支える。運用中であることへの確かさは中程度で、法的な同一性については高い。

一方、規模、設備総量、顧客ワークロードの配置、障害時に使える余力、復元性能への確かさは低い。ラック数、契約電力、ホスト数、SAN 容量、予備機、バックアップ使用量、迂回通信量は公開されていない。SY3 と SY4 の建物仕様は Zone Networks の割当ではなく、PeeringDB の施設記載はワークロード地図ではなく、BGP の隣接は物理経路図ではない。これらを足し合わせても、顧客単位の冗長構成にはならない。

この不確かさは、直ちにサービスが弱いという判定ではない。非公開の容量が十分にあり、個別契約で強い復旧条件が提供されている可能性はある。だが、公開情報だけでその可能性を事実へ昇格させることもできない。購入者が必要とするのは、一般的な安心感ではなく、自分のワークロードに割り当てられた故障時の残量と、試験済みの復元経路である。

この評価を定期的に見直すときも、通常時の新しい商品名だけを追うのでは足りない。施設の変更、上流接続の変更、機器世代の更新、管理範囲の変更、バックアップ保管先の変更があれば、以前の復元試験が現在の構成を代表するかを問い直す必要がある。反対に、公開ページが古く見えても、日付のある個別資料と新しい演習結果が十分なら、購入者は現在の実態をより正確に判断できる。公開説明の新しさと、障害時に業務を戻せることは別の証拠で測るべきである。

最終的な判断では、分からない値を無理に推計するより、契約で固定できる項目と、試験で観測できる項目へ変換するほうがよい。ラック数そのものを開示できなくても、契約対象がどの故障領域をまたぐかは明記できる。予備機の総数を開示できなくても、対象サービスの交換目標と互換部品の扱いは合意できる。バックアップ基盤の総容量を開示できなくても、顧客データを所定時間内に復元する試験は実施できる。非公開を推測で埋めるのではなく、顧客に必要な結果へ置き換えて確かめることが、調達側の現実的な対応になる。

Zone Networks を選ぶかどうかの中心には、シドニーにあるという利点や商品価格だけでなく、二つの時計の差を誰が埋めるかを置くべきだ。交換品の電源が入ったとき、事業者の機器時計は止まり得る。その後、RAID、バックアップ、ソフトウェア、データ、DNS、秘密情報、外部接続を戻し、利用者が業務を再開するまで、顧客の時計は動き続ける。その差を契約、容量証拠、役割分担、復元試験で短くできるかどうかが、ホスティングの実際の回復力を決める。