障害切り分けとは何か – 影響範囲から構造を読む

監視は、システムの状態を観測するための仕組みです。

しかし、状態が見えていることと、障害を理解できることは同じではありません。CPU 使用率、メモリ使用量、HTTP ステータス、ログ、SNMP Trap、メトリクス、ダッシュボード。これらはすべて材料です。

問題は、その材料をどう読むかです。

障害切り分けとは、観測された情報を並べ、影響範囲を確定し、原因候補を狭めていく作業です。最初から原因を当てることではありません。

むしろ、最初に原因を探し始めると失敗します。

原因ではなく影響から見る

障害が起きた時、人は原因を知りたくなります。ネットワークか。サーバーか。アプリケーションか。DNS か。認証か。ストレージか。

もちろん最終的には原因を特定する必要があります。しかし、最初に見るべきものは原因ではありません。

最初に見るべきものは、何が、どこまで、どのように影響を受けているのかです。

一人のユーザーだけなのか。特定の拠点だけなのか。特定のアプリケーションだけなのか。管理画面だけなのか。API だけなのか。内部通信だけなのか。外部公開だけなのか。

この影響範囲が見えないまま原因を探すと、切り分けではなく推測になります。

障害切り分けは主語を決める作業である

障害対応で難しいのは、同じ事象でも主語によって見え方が変わることです。

利用者を主語にすれば「画面が開かない」です。アプリケーションを主語にすれば「HTTP 500 が返っている」です。サーバーを主語にすれば「プロセスは起動している」です。ネットワークを主語にすれば「宛先 IP へは到達できる」です。DNS を主語にすれば「名前解決が失敗している」です。認証基盤を主語にすれば「トークン発行に失敗している」です。

どれも間違いではありません。ただし、主語が混ざると会話が壊れます。

「サーバーは生きている」と「サービスが使える」は別です。「ping が通る」と「アプリケーションが正常に動く」は別です。「ログイン画面が表示される」と「認証が成功する」は別です。

障害切り分けとは、まず主語を揃える作業でもあります。

レイヤで見る

影響範囲を整理する時、レイヤで見ると考えやすくなります。

レイヤ	見るもの
物理 / 仮想基盤	電源、ホスト、VM、ストレージ、NIC
ネットワーク	L2、L3、ルーティング、Firewall、NAT、LB
名前解決	DNS、検索ドメイン、内部 / 外部ゾーン
認証	LDAP、SAML、OIDC、証明書、MFA
OS / ミドルウェア	プロセス、ポート、ログ、リソース
アプリケーション	HTTP、API、DB 接続、エラー率
利用者影響	遅い、開けない、ログインできない、処理できない

重要なのは、下から順番に全部見ることではありません。影響に近いところから見て、必要に応じて下位レイヤへ降りることです。

利用者が「ログインできない」と言っているなら、最初に CPU 使用率を見るより、認証経路を見る方が自然です。「特定拠点だけ遅い」なら、アプリケーションログよりネットワーク経路や名前解決を疑う方が自然です。

切り分けは、チェックリストを上からなぞる作業ではありません。事象から構造を読む作業です。

DNS 障害はあらゆる障害に見える

DNS の障害は分かりにくいです。名前解決ができないだけで、アプリケーション障害にも、ネットワーク障害にも、認証障害にも見えます。

Web サイトが開かない。API に接続できない。メールが送れない。LDAP に接続できない。Kubernetes の Service 名が解決できない。外部 SaaS に接続できない。

これらは一見すると別々の障害に見えますが、名前解決が原因であることがあります。

だから DNS は、単なる補助機能ではありません。システム間接続の前提です。

障害切り分けでは、IP で到達できるのか、名前で到達できるのかを分けて確認する必要があります。ここを分けないと、ネットワーク障害と DNS 障害を混同します。

認証障害はアプリケーション障害に見える

認証も同じです。利用者から見ると、「ログインできない」はアプリケーション障害です。しかし実際には、LDAP、SAML、OIDC、MFA、証明書、時刻同期、Cookie、リダイレクト URI など、複数の要素が関係します。

アプリケーション本体が正常でも、認証基盤に問題があれば利用者は使えません。逆に、認証が成功していても、アプリケーション側の権限マッピングが誤っていれば利用できません。

認証障害では、「認証できない」のか「認可できない」のかを分ける必要があります。

本人確認が失敗しているのか。ログイン後の権限付与が失敗しているのか。IdP と SP の連携が壊れているのか。属性やグループの受け渡しが壊れているのか。

ここを分けないと、すべてが「ログインできない」に潰れます。

Kubernetes では Pod だけを見ても足りない

Kubernetes の障害切り分けでは、Pod の状態だけを見ても足りません。

Pod が Running でも、Service の selector が誤っていれば通信できません。Endpoint が空なら、Service は転送先を持ちません。Ingress が正しくても、外部 LoadBalancer や BGP 経路が壊れていれば到達できません。DNS が壊れていれば、Service 名で通信できません。NetworkPolicy が効いていれば、Pod 間通信は遮断されます。

Kubernetes は抽象化が多い分、障害時に見るべき境界も増えます。

Pod。Service。Endpoint。Ingress。CNI。DNS。Node。外部経路。ストレージ。認証。

これらを別々の部品として見るのではなく、通信や処理の経路としてつなげて見る必要があります。

監視と切り分けは違う

監視は、状態を観測する仕組みです。切り分けは、観測された状態を解釈する思考です。

監視項目を増やしても、切り分けができるとは限りません。ダッシュボードがあっても、何を見るべきか分からなければ意味がありません。アラートが出ても、それが影響なのか原因候補なのか分からなければ判断できません。

必要なのは、情報量ではありません。構造です。

どの情報がサービス影響を示しているのか。どの情報が原因候補なのか。どの情報は結果にすぎないのか。どの範囲まで正常で、どこから異常なのか。

この整理ができて初めて、監視の情報は障害対応に使える情報になります。

まとめ

障害切り分けとは、原因を当てる作業ではありません。観測された事実から影響範囲を確定し、正常な範囲と異常な範囲の境界を探す作業です。

最初に見るべきものは原因ではなく影響です。次に見るべきものは境界です。その上で、原因候補を狭めていきます。

サーバーが生きていること。ネットワークが通ること。名前解決できること。認証できること。アプリケーションが応答すること。利用者が目的を達成できること。

これらは似ていますが、同じではありません。障害切り分けで重要なのは、この違いを潰さないことです。

障害対応の質は、知っているコマンドの数だけで決まりません。どの主語で、どの範囲を、どの順番で見るか。そこに設計の理解が現れます。