技術を楽しもう!

IT(ネットワーク)業界を中心に、仕事や趣味等、色々な技術を記録します。

私や周囲のエンジニアが慌てた瞬間ワースト10

f:id:takashi-tobey:20200126155230j:plain 皆さまにも、失敗談や慌てた経験がたくさんあると思います。 当時は笑い事ではなかったですが、今となってはネタとして面白いこともあるので、 私や、周囲のエンジニアのエピソードをいくつかご紹介しようと思います。

私がネットワーク中心のエンジニアなので、 開発系のエンジニアとは少し観点が異なっていると思いますが、 何となく意味合いはわかるように記述しておりますし、 同業の方は知っているだけで防げる事例もありますので、読んで頂けますと幸いです。

10位. ls -a の落とし穴

あるディレクトリ内のすべてのファイルに対し処理をするために、 下記のようにコマンドを実行しました。

ls -a | xargs hogehoge

意味としては下記コマンドを実行するのと同じになります。

hogehoge ls -a の結果1つ目
hogehoge ls -a の結果2つ目
hogehoge ls -a の結果3つ目

「ls -a」の結果には「..」(上のディレクトリ)が含まれるので、 予想外の範囲に対して実行することになります。 hogehoge が rm や chmod だと所定のファイルにアクセス出来ない等の申告が発生します。 「ls -a 」ではなく「ls -A」を使用すると「.」「..」が含まれなくなるので問題は起きません。

9位. 休日作業に作業担当者が来ない

平日日中帯の作業であれば、 担当者が急遽不在となっても代理人を割り当てる等の対処がしやすいかと思います。 休日作業でこれが起きると悲惨です。

現用のネットワークを変更する作業は、休日や夜間に行うことも多いです。 例えば、日曜0:00~5:00まで等の枠で、「ネットワークを止めても良い時間」(借用時間)を調整しているわけです。

この件は、作業直前の時間(土曜の深夜)になって、 担当者が来なかったために連絡すると、「明日の夜だと思ってました!」とのこと。

作業タイムチャート上は日曜日(の0時)と表記されていたために勘違いしたようですが、 土曜日の終電で現地に向かっていないと間に合いません。

担当者の自宅も遠く、借用時間的に間に合わなくなるので、 近隣の従業員がタクシーで駆けつける羽目に。

社会人としてどうなの?という意見もあるかもしれませんが、 特に日付をまたぐような作業の場合は、土曜の夜なのか、日曜の夜なのか、 間違えてしまうこともあるかもしれません。 対策としては、休日作業前に従業員間で注意喚起するくらいしかないですね。。

8位. 作業終了連絡をせずに帰宅

ネットワークの作業をする際は、大抵の場合、ケーブル結線や抜去やステータス変化などで運用部門でアラームが鳴ります。 想定のアラームにも関わらず、障害対応のフローが動いてしまうのは問題となりますし、 運用部門としても、アラームが出たら計画作業の担当者に連絡し、「作業影響ですか?」と確認をとります。

これらを防ぐために、作業終了連絡があるまでは非監視(アラーム鳴らさない)という電話連絡をして、監視端末を確認しながら作業を行うことがあります。

なお、作業は商用設備にアクセスできる専用端末室で行っていましたが、ユーザの疎通確認を待つ間、通常業務ができないので、効率の点で自席に戻るという事例があります。

その間、担当者は別件の資料作成などを進めており、疎通確認完了の連絡を受けた状態で、キリの良いところまで資料作成を終えてから、運用部門に連絡すれば良いと思ったようです。

案の定、資料作成が終わった後に帰宅してしまったので、 作業終了連絡を忘れてしまったというわけです。

専用端末室にいるときは緊張感が出ますが、自席にいると緊張感がなくなってしまいますね。

翌日、運用部門から「まだ作業中ですか?」という確認で発覚し、作業終了後からその当時までの全ての障害が検知できなかった可能性を考慮し、監視端末メッセージを全て確認した結果問題なしだったのでお咎めはなかったようです。

7位. 商用作業中にバグや故障が出る

作業をしていた人は悪くないのですが、以下のような、 ヒヤッとするバグ・故障が過去にありました。 いずれも監視装置において、マップが赤くなるのでびっくりすると思います。

  • ルーティングを設定すると、パケットをドロップする
  • QoSの設定をするとBGPネイバーが全断する
  • SSH接続をすると、機器が再起動する
  • 再起動をしたはずが、二度と起動しない

6位. 接続不能になる設定をしてしまう

以下のような事例があります。

JuniperのJUNOSであれば「commit confirmed」を駆使すれば予防できるものもあります。 指定時間内に「commit」が実行されない場合は、元の状態に戻すという機能です。 Cisco IOSでも似た運用ができれば良いのですが、私は良い方法を知りません。

接続に必要な通信要件を拒否してしまう

管理インタフェースでHTTP(S) / SSH / telnetを拒否してしまったり、 通信経路のアクセスリストやルーティングで遮断してしまうケースです。

ログインするユーザを作成前に、ユーザ認証を設定

取り急ぎ管理IPのみ設定し、リモートでSSH接続できるように設定した場合に注意です。 Cisco機器の例なら、「username user1 password hogehoge」を設定する前に、 line vty において「login local」を設定してしまった場合に発生します。

パスワードがわからなくなってしまう

機器に搭載されたボタンを長押ししたり、シリアル番号が必要な機器もありますので、 パスワードリセットには現地対応が必要なケースが多いため要注意です。

5位. ログファイルを削除

今も同じ実装になっているのかはわかりませんが、 商用DBソフトのOracleでは、所定のフォルダにログファイル「.log」が格納されており、 単なるSyslogとは異なり、以下のような性質のものらしいです。

  • データベースの変更を記録している
  • データベースそのものが壊れてしまっても、ログがあれば復旧できる  
  • データベースのデータより大事  

要は、ログさえあれば、直近のデータを復旧できますが、 削除された状態で障害が起きるとどうしようもない、というログです。 運用を続けていると結構な容量になるようです。運用部門の理解が不十分な場合は、 ストレージの容量切迫のアラーム起因で、「.log」であることから不要と判断されて削除されてしまうこともあるようです。 外部のバックアップがあれば、ある程度復旧させられるようですが、 単なるログ肥大化と勘違いしやすい点が恐ろしいですね。

4位. お客様環境の装置電源を誤抜去

各拠点に専用線を敷設し、データセンタに通信させる構成はよくあります。 拠点には設定済みのルータを搬送し、 現地作業員と設計担当者が電話で連絡を取り合いながら障害試験等を実施する作業が行われます。

作業完了後、現地作業員が作業用PCの電源ケーブルを抜去する際に、 誤って、お客様環境の装置電源を抜去してしまう事例がありました。

幸いにも業務影響は出なかったものの、今後の対策について検討する必要があり、 「工事中」というテープが添付された機器以外は触らない、という厳密なルールになりました。 参考画像を探したところ、Amazonでも販売しているようです。

3位. show短縮形を安易に投入

ネットワーク機器では、所定の階層まで遷移してから、設定作業を行うことが多くあります。

例えばFortiGateでは「config system interface」 と打鍵するとIPアドレスなどの設定コマンドを受け付ける状態になり、 この階層で「show」を打鍵すると、「config system interface」配下の設定だけ表示させることができます。 もちろん短縮系の「sh」でも実行可能です。

この操作に慣れた人がCisco機器を操作すると、 インタフェース設定モードで「sh」と投入してしまう可能性があります。

もちろん、実行されるのは「shutdown」です。 商用環境で実施してしまうと当該インタフェースを通過する通信が遮断されてしまいます。 担当者個人が商用環境の機器にログインできるような環境では、 このような事故に注意が必要です。

2位. サーバ作業後コンソールケーブル繋いだままノートPCをシャットダウン

聞いた話です。昔はコンソールケーブルを通じて、 再起動やシャットダウンのシグナルが伝わるようになっていたらしく、 サーバをコンソールケーブルで作業した後は、コンソールケーブルを抜いてから、 ノートPCをシャットダウンするのが掟だったようです。

この事例では商用のDNSサーバをシャットダウンしてしまいました。 幸いなことに冗長化されていたことと、借用時間内に収まっていたようで、 大ごとにはならなかったようですが、怖い事例ですね。

1位. ルートディレクトリ配下全消し

エンジニア歴が長い人は、あるあるの事例だと思います。

とあるサーバに含まれるデータを、他の場所にコピーするスクリプトを作成中で、 繰り返しテストするために、コピー先のデータを削除をしようとしており、 下記のように打鍵するつもりでした。

rm -fr /hogehoge

ところが、下記のようにスペースが紛れ込んでしまいました。

rm -fr / hogehoge

これにより「/」配下と「hogehoge」配下を全て削除する操作になりました。 商用環境ではなかったのですが、お客様のサーバだったので結構な騒ぎになりました。

これは私が新人だった、10年以上前の話です。 現在の大抵の環境では「--no-preserve-root」というオプションを使用した場合だけ動作するようですが、 特定のディレクトリ配下を消したいという際、スペースが紛れ込んだだけで大惨事になるということが、 あちこちで発生したがために、システムを守るためのオプションが用意されたのではないでしょうか。

ちなみにこの後、rmコマンドを使うときは、 lsコマンドに替えた状態で実行し、対象の問題なければ、カーソルキー↑の履歴入力を使用して、 先頭をrmに変更したものを実行するという対策をとりました。

コマンドラインは恐ろしいということを早い段階で知れたこと、 商用環境ではなかったこと、というのは不幸中の幸いだったかもしれません。