深夜2時に故障したルーター：香港クリニックグループのための24時間365日NOC監視

要約： 香港のクリニックグループが運営する8拠点のうちの1つで、深夜2時にルーターが故障した。誰もそれに気づいたのはその日最初の患者の受付ができなかった時だった――なぜなら、グループのヘルプデスクはネットワーク上で動くソフトウェアだけを監視しており、その下にあるハードウェア自体は誰も見ていなかったからだ。本記事では、なぜネットワークハードウェアがその上で動くアプリケーションと同じレベルの能動的な監視を必要とするのか、そして実際にはどのような形になるのか――1分ごとのヘルスチェック、交換にかかる時間を定めたSLA、そして故障が起きる前にあらかじめ現地に用意された予備部品――を解説する。

中央ITチームを持たないクリニックグループ

本記事のシナリオは、Brocentが香港の医療グループで繰り返し目にしてきたインフラのギャップをもとに構成した複合ケースであり、特定の実在する顧客ではない。ただし、実際に多く見られる運営パターンを代表するものである。

香港島、九龍、新界にまたがって8つのクリニックを運営する香港の医療グループを想像してほしい――およそ6～10拠点というのは、「何でも知っている一人のIT担当者」だけでは対応しきれなくなっているものの、まだ中央のIT部門を構築するには至っていない規模だ。各クリニックは、予約管理・カルテ・請求のための患者管理システムを稼働させている。そして各クリニックは、その患者管理システムをインターネットに接続し、グループの中央サーバーと通信させるために、1台のルーター、1台のスイッチ、場合によってはいくつかの無線アクセスポイントに依存している。

臨床側の運営はしっかりしている。受付スタッフは患者の受付方法を熟知し、医師は自分のシステムを使いこなし、一日の終わりには請求も締まっている。一方でIT側は手薄だ――ソフトウェア関連のトラブルに対応する外部委託のヘルプデスク契約と、各拠点のオフィスマネージャーが現場でどうにか対応できる範囲の組み合わせにすぎない。この体制は、それが本来想定していた問題――ログインが遅い、プリンターの再起動が必要、スタッフのアカウントのリセットが必要――に対してはうまく機能する。しかし、まったく別の問いに答えるようには設計されていなかった。ネットワークハードウェアそのもの――その上で動く何かではなく、ルーター自体――が、現場にITスタッフがおらず、営業時間外の拠点で、単純に動作を停止したらどうなるのか、という問いだ。

このギャップがちょうどこの規模の企業で生じやすいのには、もう一つ目立たない理由がある。2～3拠点から8拠点へと成長したグループが、ネットワークハードウェアを一度に統一して調達することはめったにない。設備は多くの場合、その拠点の内装工事を担当した業者によって、拠点ごとに、数年かけて追加されていく。グループが8拠点にまで成長する頃には、複数の異なるルーターやスイッチのブランドが、異なる時期に導入されたまま混在して稼働しているのが一般的で、その中にはメーカーが「現行モデル」と呼ぶ範囲をとうに過ぎたものも含まれる。誰もこの混在を意図的に計画したわけではない――それは、グループ全体のIT機能がインフラを一元管理しないまま、拠点ごとにインフラが拡大していった結果、自然に生じるものにすぎない。この点が重要なのは、それが「誰も全体を監視していない」ことの一因でもあるからだ。数少ない中核アプリケーションを中心に組まれたヘルプデスク契約は、そもそも自分が選定に関わっておらず、全体像を把握してもいない混在ハードウェア群を監視するようには求められていなかった。

これはグループの成長の仕方を批判しているわけではない――複数拠点を持つ医療事業者にとって、これはごく普通の成長パターンだ。しかし同時に、それはまさにルーターが実際に故障するまで表面化しない類のギャップでもある。

ヘルプデスクはソフトウェアをカバーするが、誰もハードウェアを監視していない

これがこのギャップの実際の姿であり、正確に述べる価値がある。「ITサポートがある」ということと、「ネットワークハードウェアを誰かが監視している」ということは、まったく別の主張でありながら、同じことのように扱われがちだからだ。

一般的な24時間365日のヘルプデスク契約は、チケットへの対応を前提に設計されている――スタッフがログインできない、アプリケーションがエラーを出す、パスワードのリセットが必要、といった具合だ。これは設計上、受動的なモデルである。誰かが問題に気づき、チケットを起票し、誰かがそれを解決する。ソフトウェアの問題に対してはこれが適切なモデルだ。なぜなら、端末の前に座る医師や、カルテを呼び出そうとする受付スタッフなど、そもそもそれに気づく人間がその場にいることがほとんどだからだ。

ネットワークハードウェアの故障の仕方はまったく異なる。ルーターは自らチケットを起票しない。夜7時に閉院し、翌朝9時まで開かないクリニックでルーターが故障した場合、その14時間の間、その拠点には何かに気づく人間が誰もいない。患者管理システム、電話システム、そのデバイスを経由するあらゆるものが停止する――そして誰もそれを知らない。なぜなら故障は、ヘルプデスクが監視しているソフトウェア層のさらに下で起きているからだ。ヘルプデスクの監視は、たとえあったとしても、通常は自分たちが直接サポートするアプリケーションやサーバーに向けられており、8つの物理拠点に散らばる450種類以上ものルーター、スイッチ、アクセスポイントのブランドやモデルには向けられていない。

これはまさに要約で述べたシナリオが起きる仕組みそのものだ。あるクリニックのルーターが、閉院後のある時点で故障する。どこにもアラートは上がらない。なぜなら、その層でそのデバイスを監視している人間が誰もいないからだ。翌朝、クリニックが開く。最初の患者が受付にやって来る。受付スタッフが受付処理をしようとするが、患者管理システムが読み込まれない。そのクリニックをネットワークに接続していたルーターが機能を停止しているためだ。この組織全体の中で、深夜2時に起きたハードウェア障害を最初に知ることになるのは、朝9時にカウンターの前に立つ患者であり、そして今まさに、自分でも理解できず解決もできない遅延を患者に説明しなければならない受付スタッフである。

この盲点が実際に生む代償

ハードウェア障害がこのような形で表面化すると、たいてい複数のことが重なって起きる。そのいずれも、実際にはルーターそのものとはあまり関係がない。

ハードウェア障害はITではなく、患者と受付スタッフによって発見される。 ネットワーク障害を冷静に受け止める準備が最も整っている人々――対応手順を持つITチーム――が、最後にそれを知る。一方、その衝撃を受け止める準備が最もできていない人々――シフトの最中の受付スタッフ、そして診察を待つ患者――が、最初にそれを知ることになる。医療現場において、受付の遅延は単なる軽微な不便ではない。その拠点のその日一日のスケジュール全体を後ろ倒しにし、クリニックグループが簡単には説明しきれないほど目に見える摩擦を生み出す。

故障したデバイスをどれだけ早く交換するかについて、SLAが存在しない。 明確な所要時間の約束がなければ、「誰かに対応させます」という言葉は、その日のうちに直るケースから、数日待たされるケースまで、幅広い意味を持ちうる。それは、その時に誰が対応可能か、適切な交換部品が存在するか、外部委託ベンダーがどれだけ早く連絡が取れて動けるかによって左右される。ベストエフォートで運営されているクリニックには、この不確実性に対して計画を立てる手段がなく、修理が業務の許容範囲を超えて長引いた場合の契約上の担保もない。

予備部品は事前に用意されておらず、事後にゼロから調達される。 誰もハードウェアの健全性を能動的に監視していなければ、特定のクリニックのために、そのルーターが故障する前にあらかじめ交換用の機器を用意しておく理由もない。現実的な流れはこうなる――故障が発生し、数時間後に誰かがそれに気づき、正確な交換部品を探すか発注する必要が生じ、そこでようやく実際の修理が始まる。このプロセスの一つひとつの段階が、停止そのものに加えてさらなる遅延を積み重ねていく。そしてそのいずれも、適切な運用モデルがあれば回避できるものだ。

停止は患者管理システムだけにとどまらない。 クリニックのルーターやスイッチは、通常、複数のサービスが共有する経路である――患者管理システムはもちろんのこと、同じネットワークを通る電話回線、カード決済端末、クリニックが依存するクラウドベースの検査・画像ツールなどもそうだ。基盤となるハードウェアがダウンすれば、これらすべてが一斉に止まる。だからこそ、監視されていないルーター1台の故障が、その機器自体の大きさに見合わないほど大きな混乱を生むのである。

Brocentの考え方：深夜2時の故障は「発見」ではなく「何も起きなかったこと」であるべきだ

この問題についてのBrocentの立場は明快だ。ネットワークハードウェアには、その上で動くソフトウェアと同じレベルの能動的で常時稼働の監視が必要である――簡易版でも、ヘルプデスク契約に後付けされた付け足しでもない。

平たく言えばシンプルな話だ。患者管理システムが朝9時にダウンし、スタッフと患者がリアルタイムでそれに気づく――これは臨床運営上の問題であり、その日の予定を乱し、クリニックがサービスを提供する相手に直接見えてしまい、事後に説明が必要になる。一方、ルーターが深夜2時に故障し、自動化されたヘルスチェックによって1分以内に検知され、クリニックが開く前にすでに技術者が調査を始めている――これは「何も起きなかったこと」になる。両方のシナリオで、根本にあるハードウェア障害はまったく同一だ。違いは完全に、誰がいつそれを知ったか、という点にある。

だからこそBrocentは、ネットワーク・ハードウェア監視をソフトウェア監視の副産物としてではなく、それ自体独立した専門領域として扱っている。これはネットワーク・ハードウェアメンテナンスサービスとして提供され、社内ではInfra 365 NOCと呼ばれる。450以上のベンダーブランド（Cisco、HP、Juniper、Fortinet、Meraki、Ruckus、Dell、Canon、D-Linkなど）に対応しており、対象範囲が限られた承認済みハードウェアのリストに縛られることはない。8つのクリニックにまたがって、長年にわたる部分的な調達で積み重なった複数ベンダーの機器を混在させている医療グループも、能動的な監視を受けるためにまず単一ベンダーへ標準化する必要はない。

SLA付きハードウェア交換を伴う24時間365日のNOC監視とは、実際にはどのようなものか

実務上、これは3つの具体的な仕組みに集約される。「気にかけておきます」といった曖昧な約束ではない。

10か所以上のグローバル拠点からの1分ごとのヘルスチェック。 BrocentのNetwork Operations Centre（NOC）は、ネットワーク・サーバー・クラウド・アプリケーションの各層を継続的に監視している。日次や週次のポーリングサイクルではなく、APAC、EMEA、北米にまたがる10か所以上のグローバル拠点から、1分ごとにヘルスチェックを実行する。デバイスへの接続不能やサービスの停止といった異常が検知されると、時刻を問わず、その瞬間にチケットが起票され、技術者による調査が始まる。

ベストエフォートではなく、明確に定められた所要時間SLA。 「いずれ対応します」というオープンエンドな約束ではなく、このサービスは公開された所要時間SLAの階層を前提に構築されている――エントリーレベルのStarterプランでは2時間の所要時間コミットメント、上位のProプランでは4時間の所要時間コミットメントがあり、いずれも誰かがたまたま気づいた時点からではなく、障害が検知された時点から計測される。これが、「そのうち誰かが見てくれるだろう」という状態と、クリニックの運営責任者が実際に計画の根拠にできる具体的な数字との違いだ。

故障前にあらかじめ現地に用意された予備部品。 故障後に交換部品を探すことこそが、通常なら日常的なハードウェア交換で済むはずのものを数日規模の停止に変えてしまう遅延そのものであるため、Brocentは香港、中国本土、日本、シンガポールに現地在庫の予備部品をあらかじめ用意しており、機器の故障が確定してから受動的に発注することはない。九龍のあるクリニックで深夜2時にルーターが故障した場合、交換機器はまず通関を待つ必要がない。

これら3つの仕組みの土台には、SNMPベースの自動検出とネットワークマッピングがある。これにより、クリニックグループの全拠点――8拠点すべて――にある完全な機器インベントリ、すなわちすべてのルーター、スイッチ、アクセスポイントが、拠点ごとに存在するかもしれないバラバラなドキュメントに頼るのではなく、単一の監視ビューにまとめられる。この統一されたビューこそが、前述したブランドの混在という課題を解決する鍵となる。監視プラットフォームが最初から450以上のベンダーブランドに対応しているため、対象範囲を得るために単一ブランドへ統一する必要がないのだ。

その上で、四半期ごとの予防保守、構成のバックアップ、ファームウェアのアップグレードが実施され、何年も更新されていないファームウェアを積んだアクセスポイントや、まもなくベンダーサポートが終了するスイッチといった、じわじわと蓄積する問題を、本記事の冒頭で描いたような一夜の障害へと発展する前に発見する。そして問題が検知された際も、対応は自動的に現地出動になるわけではない。リモート監視・管理ツールにより、技術者は管理対象デバイスに仮想的にアクセスできるため、多くの問題はまずリモートで切り分けと解決が行われ、現場への派遣は実際にハードウェアへの手当てが必要な故障のために取っておかれる。月次レポートは、これらすべてを、全クリニックにわたるシステム可用性・パフォーマンス・キャパシティの単一のビューにまとめ上げる。これにより、クリニックの運営責任者は、先月ネットワークが実際どう動いていたかを推測したり、拠点ごとに事後的に組み立て直したりする必要がなくなる。

この3つのモデルを並べて比較する価値がある。遠目には似て見えるかもしれない――いずれも「最終的には誰かが問題に対応する」という点では共通しているからだ。しかし、夜間のハードウェア障害にとって本当に重要な違いは、問題がどれだけ早く発見されるか、そして修理がどれだけ予測可能かという点に完全にかかっている。

受動的サポート vs. ソフトウェアのみの監視 vs. SLA付きハードウェア交換を伴う24時間365日のNOC監視

• 受動的サポート（「何か起きたら連絡してください」）――インシデントとインシデントの間、誰もハードウェアの健全性を監視していない。障害は、それが支えているシステムが停止したことに誰かがたまたま気づくまで発見されず、無人の夜間帯ではそれが数時間にわたって誰にも知られないことを意味しうる。
• ソフトウェアのみの監視――アプリケーションのエラー、ログイン失敗、サービスのクラッシュは捉えるが、その下にあるハードウェア層については何も見えていない。ルーターやスイッチが機能を停止しても、このモデルはそもそもそこを見るように設計されていないため、単純に気づかない。
• SLA付きハードウェア交換を伴う24時間365日のNOC監視（Brocentのモデル）――10か所以上のグローバル拠点からの1分ごとのヘルスチェックが、ルーターの故障をその瞬間に捉える。公開された所要時間SLAが、交換機器が取り付けられるまでの速さを規定する。現地にあらかじめ用意された予備部品により、部品はすでに発注中ではなく棚の上にある。

よくある質問

ヘルプデスクサポートとNOC監視の違いは何ですか？

ヘルプデスクは受動的で、スタッフがソフトウェア、ログイン、使用しているアプリケーションについて起票したチケットに対応します。NOC（ネットワークオペレーションセンター）監視は能動的で、ネットワークハードウェア自体を継続的に監視するため、ルーターやスイッチの故障は、スタッフや患者がそれが支えるシステムの停止に気づく前に、自動化されたヘルスチェックによって検知されます。ほとんどの組織には両方が必要です。それぞれが異なる問いに答えるものだからです。

故障したデバイスは実際どれくらい早く交換されますか？

交換にかかる時間は、ベストエフォートの約束ではなく、公開された所要時間SLAによって規定されます。エントリーレベルのプランでは2時間、上位プランでは4時間の所要時間コミットメントがあり、いずれも障害が検知された時点から計測されます。エンタープライズレベルの対応範囲は、環境ごとに個別に検討・見積もりされます。

予備部品は香港に現地在庫として用意されていますか？

はい。Brocentは香港、中国本土、日本、シンガポールに現地在庫の予備部品をあらかじめ用意しているため、香港のクリニック向けの交換機器を、故障後に探したり輸入したりする必要はありません。すでに現地にあります。

これは機器単位の料金ですか、それとも拠点単位ですか？

ネットワーク・ハードウェア監視は機器単位の監視プランとして構成されていますが、より広いBrocentの受管型ITサポート料金のもとでは、ユーザー単位で料金設定されたプランの中に、24時間365日のNOC監視が個別の課金項目ではなく、すべてのプラン階層に標準で含まれる機能として組み込まれています。機器数、拠点数、適用するSLA階層といった具体的な範囲は、プラン検討の際に確定します。市場ごとの具体的な数字については最新の料金をご覧ください。

これはルーターだけでなく、スイッチやアクセスポイントもカバーしますか？

はい――機器レベルの監視は、ルーター、スイッチ、ファイアウォール、無線アクセスポイント、プリンター、UPS、ストレージをカバーし、450以上のハードウェアベンダーブランドに対応しています。対象範囲は単一拠点の単一ルーターに限定されず、複数クリニックにまたがるすべてのネットワーク機器に及びます。

「1分ごとのヘルスチェック」とは具体的にどういう意味ですか？

Brocentの監視プラットフォームが、10か所以上のグローバル拠点から、監視対象の各デバイスの状態をおよそ1分ごとに能動的にチェックすることを意味します。日次や時間単位のサイクルでポーリングするのではありません。「デバイスが応答を停止した」から「技術者が調査を開始した」までのギャップは分単位で計測され、患者による発見というシナリオが示唆するような数時間、あるいは一晩にわたる待ち時間ではありません。

あるクリニックの障害は他のクリニックに影響しますか？

監視の観点からは影響しません――各拠点の機器は、SNMPベースの自動検出を用いて各クリニックのルーター、スイッチ、アクセスポイントをマッピングした上で、同一の監視ビューの中で個別に追跡されます。あるクリニックのルーター故障は、それ自体独立したインシデントとして検知・対応され、他の拠点が影響を受けていないことをまず確認する必要はありません。なぜなら各機器の状態はすでに個別に、リアルタイムで把握されているからです。

これは営業時間だけをカバーしますか、それとも本当に24時間365日ですか？

本当に24時間365日です。ヘルスチェックは複数のグローバル拠点から継続的に、途切れることなく実行され、クリニックが夜間に閉院しても止まることはありません。これは医療グループにとって特に重要です。なぜなら、無人となる夜間帯こそ、ハードウェア障害が翌朝最初の患者が来るまで誰にも気づかれずに放置されやすい時間帯だからです。

このサービスは受管型ITプランの中でどう位置づけられるか

このサービスを検討しているクリニックグループのために、24時間365日のNOC監視が実際にどこに位置づけられるのかを率直に述べておく価値がある。それは単独で購入を検討する別個の製品ではない。Brocentの受管型ITサポートプランのあらゆる階層――StarterからEnterpriseまで――において、24時間365日のNOC監視は、ヘルプデスク対応、受管型ファイアウォール、パッチ管理、バックアップ・災害復旧と並んで、すべての階層に標準で含まれる項目の一つである。これらのプランのいずれかに移行する医療グループは、ネットワーク監視を追加項目として別途購入しているわけではない。ハードウェア層のカバーを、受管型ITプランの基本的な構成要素の一部として、機器ごとに追加課金されるのではなく、ユーザーあたり月額で得ているのだ。

これは明確に言語化する価値のある設計上の選択だ。本記事冒頭のルーター故障のシナリオは、本質的には「監視を購入するかどうか」の問題ではない。「ハードウェアを含めた環境全体に誰が責任を持つのか」という問題なのだ。すでにソフトウェア側のヘルプデスクを外部委託しているにもかかわらず、ネットワークハードウェアが同じように監視されたことが一度もないクリニックグループは、実質的に、自分たちが持っていると思い込んでいたカバー範囲の半分の対価しか支払ってこなかったことになる。

これを検討している複数拠点のクリニックグループにとって、実務的な次のステップはプランレビューである――拠点数、拠点ごとの機器数、そしてグループが夜間障害に対してどれだけのリスク許容度を持つかに応じたSLA階層について、一つひとつ検討していくことだ。この対話は、先述したブランド混在の問題も自然に浮かび上がらせる。プランレビューは多くの場合、グループが8拠点にまたがって実際にどれだけ多くの異なるハードウェアブランドやファームウェアバージョンを稼働させているかを初めて正確に把握し、その結果として、バラバラで記録の乏しい8通りのリストではなく、一つにまとまった監視対象インベントリを得る機会となる。

本記事の冒頭で深夜2時に故障したルーターは、朝9時の問題になるのを避けるために、より大きなIT予算を必要としていたわけではない。必要だったのは、グループがすでにソフトウェアサポートに対して当然のように期待している水準のカバーの中に、ハードウェア層を組み込むことだった。Brocentにお問い合わせいただき、単一拠点の事業者向けではなく、複数拠点の医療事業者向けに設計された受管型ITプランの一部として、貴グループ固有のクリニックネットワークにおける24時間365日のNOC監視の内容をご検討ください。