Written by aki(あき)
情シスが日頃行うシステムの変更作業や運用管理作業は、失敗しないで当たり前、失敗した日には社内から非難を一斉に浴びるというなかなかとヒリヒリした仕事です。しかもそれが「しょうもない失敗」だった日には目も当てられません。
失敗は誰もがしたくないけど、それでも残念なことに失敗は起きてしまいます。何とか情シスさんのために失敗を減らすことはできないものかと思案した結果、現場でよくある失敗事例を紹介すれば、現場での失敗をある程度は避けられるのではと思った次第。
そこで今回は特に現場作業でよくある失敗を8つ紹介したいと思います。最後にこれらの失敗を起こさないためのチェックシートを掲載しましたのでぜひ現場で活用してみてください。
深く考えずに機器の設定を変更する
何も考えずにサーバーやネットワーク機器、業務アプリケーションの設定を変更して、機器に接続出来なくなったり、アプリケーションが応答しなくなった経験はないでしょうか?残念ながら私はそのような場面に遭遇したことがあります(しかも何度も・・・)。
簡単な設定変更だったり、変更しても影響がないと思い込んで、事前に机上確認や動作確認をすっ飛ばして、いきなり本番環境で設定変更するのは愚の骨頂です。特に業務アプリケーションやコアのルータなど、やらかしたら会社全体に影響が出そうな設備の設定を変える場合は特に注意が必要です。
ちなみに私がやらかしたもっとも大きな失敗は、大阪にあるルータに東京の事務所からSSH接続して、深く考えずに設定変更したらルータに接続できなくなったということがあります。設定変更したことによる影響を考慮にいれておかないと、取り返しのつかない事態になる可能性がありますので気をつけてくださいねー。
バックアップを取得せずに設定を変更する
機器の設定を変更する前に、現状の状態をバックアップしておくことは、リスク管理の上でもとても重要です。設定変更をミスったり、想定外の事象が発生した時に設定前の状態に切り戻すことがあると仮定して、事前に準備しておきましょう。
さらに現状の設定はもちろんのこと、現在の状態を確認しておくことで、設定変更で思わぬトラブルに陥ったときの切り分けを実施する際に役立ちます。
また、設定作業中も作業ログを取得しながら作業する癖をつけておきましょう。Tera Termなどのターミナルソフトには、ログを取得しながらコマンド操作する機能がついていますので、ぜひ活用しましょう。
設定後の保存を忘れる
非常に初歩的なミスだけど、意外と多いのがこの失敗です。
ネットワーク機器や業務アプリケーションによっては、設定変更後は明示的に設定を保存しなければ、機器が再起動した場合に以前の設定に戻ってしまうものがあります。
当日の設定変更自体は問題なく終わっても、後日ビルの停電作業があり機器の再起動が発生すると以前の設定に戻ってしまい、通信障害が発生したなんてことが過去にありました。
さすがに最後の保存作業を忘れるなんてことはないでしょ、と思うかも知れませんが意外にやらかしがちなので設定作業が終わったら必ず保存する癖をつけておきましょう。
ドキュメントを残さない
社内システムを構築したら、必ずシステムに関するドキュメントを残しておきましょう。システム論理/物理構成図や導入機器、IPアドレス、VLANなどの一覧表、システム操作手順書など必要なドキュメントは多岐にわたります。これらドキュメントを残しておかないと、いつか担当者が変わったときに何もドキュメントがないまま引き継ぎを行うという最悪の状態が起きてしまいます。
また、新規システムを構築したタイミングで、きちんとドキュメントを作成していたとしても、日々のシステム変更をドキュメントに反映できていないことが多いようです。システムの構成や設定を変更したら、併せてドキュメントも更新して常に最新の情報にUpdateしておくことも忘れずに。
ユーザーへの事前連絡なく作業を行う
情シスから見たユーザーとはシステムを利用する他部門の社員です。そのユーザーに対して事前に連絡をすることなくシステムの変更作業等は避けるようにしましょう。どんなに小さな作業であっても、ユーザーの許可なく作業することは許されないこと。もし、許可なく行った作業によってトラブルが発生した場合、あなた個人だけではなく、情シス部門としてユーザーからの信頼を失う危険性もあるので要注意です。
事前に社内ポータルサイト上への掲載やメールでの連絡等を怠らず、作業終了後には終了した旨の連絡をすると親切です。
本番環境で動作検証してしまう
「そういえば、このタイマーを変更すれば経路の収束が早くなるんだっけ。ちょっと変更してみるか」などと、本番環境を使って動作検証したくなる誘惑が過去にあったことはありませんか?ありますよね?
いうまでもなく、本番環境を使って検証するなどという暴挙は絶対にやめておきましょう。そのようなことは検証環境を使ってやるべきであって、本番環境でやるべきではありません。
また作業をしている中で、今まで使ったことがない機能や構成に出くわすこともあるかもしれません。このようにあなたが知らないことに出くわした時、エンジニアはどうしてもすぐに学びたいという欲求がでてくるかもしれませんが、本番環境を使って学ぼうとしてはいけません。ユーザーが情シスに期待していることは、あなたのスキルを上げるためではなく、システムを活用して業務を円滑に行うためであることを忘れてはいけません。
状況を把握せずに障害切り分けを開始する
システムで障害が発生し、あなたが現場に駆けつけてまずやることは、状況を把握することです。いきなり障害切り分けを実施しようとするエンジニアは決してプロフェッショナルとは呼べません。
まず「障害の内容」、「現在の状況」を把握し、現在のネットワーク構成から考えられる問題点を洗い出してから障害切り分けに取り組むべきです。状況把握から切り分けを行うことは、一見すると遠回りに思うかもしれませんが、事前に状況を把握することで切り分けを効率良く行うことができるので、障害復旧への近道になることが多いです。
最終的な確認をすることなく作業を終了してしまう
情シスとしてのあなたの視点からは、作業がすべて完了したかのように見えているかもしれません。だからといってそこで作業を終了して退室してしまうのは大きな間違いです。
最終的な作業の終了は、ユーザーの視点から見ても想定とおりの動作をしていることです。実際に使うのは情シスさんではなくユーザーであることを忘れてはいけません。そのためにはユーザーにコンピュータ等を操作してもらい、最終的な動作の確認をしてもらうことまで実施して本当の作業終了だということを覚えておきましょう。
以上、現場でよくある8つの失敗をご紹介しました。
現場作業を実施する際のチェックシート
現場での失敗は、直接ユーザーからの信頼を失うことにつながります。そうならないためにも、失敗事例を事前に知っておくことはもちろん、実際に現場作業を実施する際の手順を明確化しておくことが重要です。そこで最後に「情シスが現場作業を行うためのチェックシート」をご紹介したいと思います。
工程 | 作業項目 | ✔ | 詳細 |
---|---|---|---|
作業前準備 | 作業変更による動作確認 (机上/実機) |
机上や実機で、作業変更による影響に確認を実施する | |
作業手順書の確認要否検討 | 作業が多い場合は、作業手順書を作成する | ||
切り戻し手順検討 | 作業中に問題があって場合、すぐに切り戻せるように事前に切り戻し手順を検討しておく | ||
ユーザーへの作業連絡 | 影響がありそうなユーザーに作業日時と影響範囲について連絡する | ||
当日作業 ※作業手順書を作成する場合は、右記項目を作業手順書に盛り込むこと |
事前バックアップ | 作業実施前に現状の状態をバックアップしておく | |
事前正常性確認 | 作業実施前にエラーやアラーム等発生しておらず、正常状態であることを確認する | ||
作業中のログ保存 | 作業中のコマンド操作はログとして保存しておく | ||
作業後の設定保存 | 作業後に設定の保存が必要な機器は忘れずに保存する | ||
作業後の正常性確認 | 作業終了後にユーザーレベルでの正常性確認を行う | ||
後日作業 | ユーザーへの作業終了連絡 | ユーザーに作業終了連絡を行う | |
ドキュメント更新 | 各種ドキュメントへ、作業後の状態を反映する |
おすすめ記事