第4話 深夜二時の変更者
会社の業務を支えるシステムのメンテナンスは、業務への影響を避けるため、
深夜や休日に行われることも少なくありません。
これは、そんな深夜のシステムメンテナンスにまつわるお話です。
ある月曜日の朝。
Aさんが出社すると、オフィスは朝から少し騒がしくなっていました。
どうやら、1台のサーバーでエラーが発生しているようです。
画面の反応が遅い。
ログインも不安定。
昨日までは問題なく動いていました。
Aさんは、同僚のBさんに尋ねました。
「昨日、何か作業ありました？」
Bさんはすぐに答えます。
「確か、週末の深夜にメンテナンス作業をしていたはずです」
Aさんは作業担当者へ連絡を取ろうとしました。
しかし、担当者は深夜作業明けのため休務中。
何度連絡しても、つながりません。
そこでAさんは、メンテナンスの手順書を確認しました。
昨夜の作業内容は、別の本番サーバーに対する設定変更です。
現在エラーが発生しているサーバーは、作業対象に含まれていませんでした。
チェック欄も、すべて完了済み。
実施報告にも、異常は記載されていません。
書類を見る限り、問題はなさそうです。
Aさんはログを確認しました。
すると、深夜2時頃に設定変更の記録が残っていました。
02:07 Login Success
02:10 Service configuration updated
02:14 Service restarted
確かに、誰かがサーバーへログインしています。
そして、設定を変更し、サービスを再起動しています。
しかし、その作業は手順書にありません。
実施報告にも書かれていません。
「じゃあ、一体誰が、このサーバーに設定変更をしたんだ……」
誰が、何のために、何を変更したのか。
ログだけでは分かりませんでした。
数時間後。
休みだった作業担当者と、ようやく連絡が取れました。
Aさんはすぐに尋ねます。
「深夜に、このサーバーで何か作業しました？」
すると相手は、少し困った様子で答えました。
「いや……今回の作業対象は別の本番サーバーです。そのサーバーには入っていません」
数秒の沈黙。
そして、担当者はもう一言付け加えました。
「でも作業中、何回か接続し直したかも……」
その瞬間、Bさんが言いました。
「録画、見ましょうか」
画面には、深夜2時の作業記録が映し出されました。
そこに映っていたのは――
作業対象の本番サーバーへ接続したつもりで、
よく似た名前の別の本番サーバーを開き、
手順書にはない設定変更を行う様子でした。
途中で接続先の間違いに気づいたのでしょう。
担当者は慌てて設定を元に戻し、サービスを再起動しました。
しかし、入力したパラメーターは、変更前の値とはわずかに異なっていました。
その小さな不整合が、翌朝のエラーを引き起こしていたのです。
数秒の沈黙。
そして作業担当者が、小さな声で言いました。
「……これ、録画残るんですね」
この怪異の正体：作業者の記憶頼みの運用
危険度：★★★★★
よく似た名前のサーバーが並ぶ環境で、作業者が自ら接続先を選ぶことで現れる怪異。
作業対象ではないサーバーに入り込み、手順書に存在しない変更を行ったあと、
実施報告には何の痕跡も残しません。
設定変更の履歴はログに残ります。
しかし、ログから分かるのは、何らかの変更が行われたという事実だけ。
誰が、なぜそのサーバーへ接続し、どのような操作を行ったのかまでは分かりません。
今回は操作の録画が残っていたため、深夜に起きた出来事を突き止めることができました。
録画がなければ、作業者の曖昧な記憶と断片的なログを頼りに、
存在しない変更者を探し続けていたかもしれません…
一見すると、人が引き起こした「ヒトコワ」のようにも見えます。
しかし、本当に怖いのは人間ではありません。
人が接続先を間違えても止められず、間違えたあとの操作も残らない。
そんな、人の失敗を怪異に変えてしまう運用なのです。
今回の障害では、作業者が誤って本番サーバーへ接続し、手順書にない操作を行っていました。
しかし、原因を単なる操作ミスだけで片付けてはいけません。
-
作業者が、本来触る必要のない機器にも接続できる状態だったこと。
-
実際に何を操作したのか、すぐには確認できなかったこと。
-
申請された作業と、実際の操作が別々に管理されていたこと。
こうした環境が重なったことで、深夜二時の変更者は現れました。
一般的なVPN ( 社外から社内ネットワークへ安全に接続する仕組み ) では、
作業者を社内ネットワークへ接続させたうえで、そこから対象のサーバーや機器へアクセスします。
構成や権限設定によっては、作業対象以外の機器にも到達できてしまいます。
そのため、接続先の選択を誤ると、予定していなかった本番環境を操作してしまう可能性があります。
そこで重要になるのが、作業者へネットワーク全体の入口を渡すのではなく、
必要な機器への接続だけを許可する考え方です。
OpsRampのリモートコンソールでは、管理画面上で接続対象となる機器を選択し、
ブラウザからSSHやRDPといった方式でリモート操作を行います。
ユーザーや役割ごとに接続できる対象を制限できるため、
「この作業者は、ログ採取の対象となるサーバーにだけ接続できる」
といった形で、作業に必要な範囲だけを許可できます。
作業者をネットワークの中へ入れるのではなく、許可された扉だけを開ける。
これにより、接続先の取り違えや、不要な機器へのアクセスを抑えられます。
さらに、リモートコンソール上で行われた操作は録画として残すことができます。
障害が発生した際には、次の点を確認できます。
- 誰が接続したのか。
- どの機器を操作したのか。
- どのような作業を行ったのか。
- 手順書にない操作がなかったか。
担当者の記憶や、作業報告に書かれた文章だけに頼らず、実際の操作画面から確認できます。
作業者ごとにアカウントと権限を分け、接続対象を限定し、操作内容を記録する。
さらに、変更申請やチケット番号と作業記録を紐付けておけば、
申請された作業と実際の操作が一致しているかも追跡しやすくなります。
本番環境で作業を行う以上、人による操作ミスを完全になくすことはできません。
だからこそ、次の3点が欠かせません。
- 誰でもどこへでも入れる環境を作らないこと。
- 何が行われたのかを、後から確認できるようにすること。
- 申請と実際の作業を、同じ記録として残すこと。
今回の話では、たまたま操作の録画が残っていたため、原因を特定できました。
しかし、録画がなければ、断片的なログと曖昧な記憶を頼りに調査を続けるしかなく、
原因不明の障害として処理されていたかもしれません。
深夜二時の変更者は、怪異ではありません。
広すぎるアクセス権と、
操作の記録が残らない運用が生み出す、
IT運用の現場に潜む影なのです。
「うちにも心当たりがあるかもしれない……」
と思った方は、ぜひお気軽にご相談ください。
お問い合わせ (総合) | 法人向けパソコン (PC) ・計測器レンタルなら横河レンタ・リース
