～はじめに～
運用保守は、手順書通りするだけの楽な業務と勘違いしていませんか？
私は3年間運用保守(インフラ)に携わり、手順書作成や障害対応/調査、運用支援など様々なことを行ってきました。そんな私が思うに運用保守は、全くそんな楽な業務でありません。
運用保守は過信と油断をすれば、すぐに業務影響を出してしまいます。
構築設計段階でのお客様に影響を出すのとは、全く影響度合いが違います。
既に稼働しているシステムで業務影響を出すというのは、エンドユーザーへ多大なるご迷惑をおかけするということ、つまり絶対に許されません。
そんな状況にならないために、私が運用保守をする上で意識して行っていることについて書きたいと思います。
～運用保守をする上で意識して行っていること～
1. 簡単な作業や慣れた作業でも慎重に行う
私はどんな作業だとしても、過信や油断をせずに慎重を行うようにしています。
簡単または慣れた作業だからと言ってスピードを重視するあまり、実行するコマンドや手順等をしっかり確認せずに実施してしまうと、いつかは予期しないことが発生し業務影響を出してしまう可能性があります。今までにそのような状況に陥った人/陥りそうな人を何人も見てきました。
迅速に対応するのは良いことですが、確認を疎かにして問題を起こしてしまっては元も子もないです。どんな作業だとしても、慎重に行いましょう。
2. 作業前に手順書を再度確認する
自分が対応する作業の手順書は、事前に再度確認するようにしています。
手順書のレビューが完了しているからといって、１００％安全な手順書というわけではありません。レビュー者も人間であり、問題部分を見落としてしまうこともあります。また手順書が作成されたあとに仕様が変わり、手順書に反映されていないケースもあります。
(そもそも上記の問題が発生するのは、運用方針がまずいからなんですよね。)
だからこそ作業前にもう一度確認するのは大切です。
3. 作業後に問題があった手順書には修正をかける
作業時に手順書の不備や分かりずらい部分を見つけた場合、作業後に修正しています。
作業が同様または似ているものは、以前使われた手順書を焼き直しして使用するケースは多いかと思います。なので作業時に見つけた手順書の不備や分かりずらい部分は、直さなければ次回も同じところで引っかかり無駄な作業を生んでしまう可能性があります。面倒くさがらずに、修正しましょう。
4. 運用資料（運用スケジュール等）等を鵜吞みにしない
資料だけを見て判断するのではなく、実際に本番環境も見るようにしています。
何かをきっかけに本番環境の構成や運用方針が変わったにも関わらず、資料に反映されていないケースがあります。特に初めての案件の場合は、資料だけを見るのではなく本番環境も調べてから手順書を作成すべきです。また反映されていない資料を見つけた場合は、放置せずに修正しましょう。
5. 可能な限り誰でも分かる手順書を作成する
作成する手順書には責任を持ち、誰もが分かる手順書を作成しています。
分かっている前提で作成された手順書は、認識違いから手順漏れが出てしまい業務影響を出しかねません。また経験が浅い方にとっては、その手順書は使い物にならず対応が遅くなってしまいます。だからこそ作成する手順書は、初見でどういうことをするのかが分かるレベルで作成する必要があります。
(何でもかんでも手順書に記載するのは、NGです。それは手順ではなく、説明書です。)
6. 作業を行う前にサーバーやコンソールの接続確認をする
初めて接続するサーバーに関しては事前に接続を確認し、ブラウザで接続するコンソールに関しては、毎度事前に接続できるか確認しています。
接続するサーバーによっては、踏み台のHostsに書かれていないケースや更に踏み台を経由して接続しないといけないケース等などがあります。コンソールに関しては、サービスが落ちているせいで接続できなくなっているケースや特定の踏み台からしか接続できないケースがあります。
ですので事前確認は、作業をスムーズに行う上で大切です。
コンソールのサービス起動方法も事前に確認しておくと、いざというとき焦らずに対応できます。
7. 問題発生時は速やかにエスカレーションする
作業中などに予期せぬ障害が発生した場合、速やかにエスカレーションしています。
速やかにエスカレーションせずに調査優先で行った場合、業務影響を出す可能性が高くなります。早く調査したからと言って、すぐに解決できるとは限りません。また迅速に問題を解決できたとしても、エスカレーションは絶対に実施しなければなりません。
(大ベテランが障害対応をして問題解決したと思いエスカレーションしなかった結果、翌日大きな問題を起こしてしまったケースを見たことがあります。)
8. 分からないことがあれば全てクリアにする
手順や仕様等で分からないことがあれば、すべてクリアにするようにしています。
そうしなければ、何時までたっても担当しているシステムについて詳しくなれませんし、問題が発生してしまっても何が問題だったのかも分からず対応が遅くなってしまいます。
分からないことは恥ではありません。分からないことを分からないままにしておくのが恥です。
忙しい先輩方に質問するのは度胸がいりますが、そこは自分の成長のために頑張りましょう。
9. ゆとりをもって作業できるように事前準備は念入りにする
本番作業時は、ゆとりをもって作業できるように念入りに準備しています。
私の場合、事前に実行するコマンドをテキスト等に張り付け本番に持ち込んだり、使用するサーバーに事前にアクセスしすぐに対応できるようにする等しています。事前準備をするかしないかで、作業時間が大幅に変わります。また事前準備をすることで、問題が起きてしまった場合でも焦らずに対応できます。
10. コマンド（シェルスクリプト）の実行結果は念入りに確認する
コマンドの実行結果は、念入りに確認するようにしています。
以前チームメンバーに実行結果を確認せずに、作業を完了する人がいました。案の定翌日に業務影響を出して、その人は二度とその作業を任されることはありませんでした (原因：異常終了の見落とし)。そうならないためにも、実行結果は念入りに確認しましょう。
11. CLIでの直でのコマンド入力はできる限り避ける
作業時にCLIでの直でのコマンド入力は、できる限りしないようにしています。
直でコマンドを入力してしまうと、予期しないコマンドを実行してしまう可能性があります。
コマンドのオプションが複雑で間違うケースや、ワンラインで入力するあまりにコマンドが長くなりすぎて誤字脱字が出てしまうケースなどがあげられます。そういう状況を避けるためにも一旦エディタ(メモ帳など)に書いて確認し、それを切り取りして貼り付けて実行することをお勧めします。また貼り付ける際も直でCLIに貼り付けるのではなく、ちゃんと貼り付けたいものが切り取られていることを確認してから、貼り付けるようにしましょう。
12. CLIでの右クリックには要注意
CLIで安易に右クリックをしてしまうと何かしらコピーされたものが貼り付けられてしまい、想定していないものが実行されてしまう可能性があるため、右クリックには注意しています。
PowerShellやTeraTarmなど右クリックをすると貼り付けが行われてしまうことがあります。その際に改行が混じっているコピーが存在してしまっていると、一気にコピーされているものが実行されてしまい、予期しない動きをしてしまいます。ですので、右クリックには注意しましょう。
13. 調べたことはナレッジ化して共有する
システムの仕様などを調べた際は、ナレッジ化してチームメンバーに共有しています。
業務をする上で分からないことを調べた際は、理解して終わるのではなくナレッジ化して残すべきです。その分からなかったことは、他の人も分からない可能性があります。ナレッジ化された情報があれば一から調べる必要はなくなり、いち早く知識の再習得ができます。積極的にナレッジは残しましょう。
14. 業務改善(効率化)を積極的におこなう
業務に余裕ができた際は、業務を効率化するためにシェルスクリプトの作成を行っています。
作業を行っていると、「これは簡略化できるのでは？」と思うことがあるかと思います。そういったものは思うだけではなく、実際に改善に取り掛かるべきです。私の場合は運用シェルスクリプトを作成したり、Tera Termマクロを組んだりして改善しています。結果、作業時間は短縮しオペミスの回避に繋がっています。またこういう取り組みをすることで、運用保守業務ではなかなか難しい技術的成長にもつながります。
15. 本番環境で初めて行うことは開発環境で事前に確認する
始めて実行するコマンドや運用操作などは、事前に開発環境で検証しています。
本番環境でやったことないコマンドや手順は、想定通りの動きをしなかったりするケースがあるため開発環境で事前に確認すべきです。ですが本番環境と開発環境では、環境の差があったりするため、開発ではうまくいくが本番ではうまくいかないケースも多々あります。(逆もしかり)
16. 待ち時間の間に次の手順の準備やエビデンスをまとめる
本番作業で処理待ちをしている時間に、次の手順の準備やエビデンスの整理をしています。
処理時間が長いシェルスクリプトやジョブが終わるのをぼけ～っと待つのではなく、その時間を利用して手順の再確認や次に行う手順の準備、エビデンスの整理等を行うことで作業時間は大幅に変わってきます。
時間は有意義に使いましょう。
17. 障害対応を迅速に対応するために障害資料をまとめる
障害に対して迅速に対応できるように、システムごとに障害対応資料を集めて管理しています。
障害が発生したとき、障害対応資料を探すのに時間を掛けるのはナンセンスです。障害は直ちに調査し対応しなければなりません。だからこそ事前に準備できるモノは準備しておき、少しでも早く対応できるようにする必要があります。もちろん担当するシステムに対して勉強することも重要です。この二つが伴ってこそ、迅速に障害対応ができます。
18. 取得するエビデンスは、確認者が確認しやすいように取得する
確認者が確認し易いように、エビデンスの取得には、必要な部分のみ取得し、時にはマーカーを引き強調等をしています。
作業の実施ログを全てエビデンスにするのではなく、不要な部分は取り除き必要な部分のみをエビデンスとして取得すべきです。確認者はあなたの作業証跡だけを確認しているわけではありません。確認漏れが起こらないようにするためにも、エビデンス取得には配慮しましょう。また手順書に取得するエビデンス部分を記載するのもありです。そうすることでエビデンス取得を迷わず行えます。
19. 安易にスクリプトは実行しない
始めて実行するスクリプトは、できるかぎり中身を見るようにしています。
スクリプトの中には、予想外の動きをするものが存在します。サーバーチェックをするためのスクリプトを実行したはずが、実は内部にプロセス再起動の処理も入っており業務提供時間にプロセスが再起動してしまったという話を聞いたことがあります。なのでスクリプトの名前がサーバーチェックの名前をしているからと言って、実行したことが無いのにもかかわらず安易に実行するのはやめましょう。
20. TeraTerm等でサーバーに接続した際は画面をきれいに配置する
TeraTerm等でサーバーに接続した際は、画面をデスクトップ上に見やすく分かりやすくきれいに配置しています。
適当に配置してしまうと、コマンドを実行するサーバーを間違ってしまう可能性が出てきます。そうならないためにもできる限りきれいに画面を配置しましょう。また複数のサーバーを開いている場合、コマンドを実行する前に実行しようとしているその画面が本当に対象のサーバーかも確認するようにしましょう。
21. l(小文字エル) I(大文字アイ) O(大文字オー) 0(数字ゼロ)には気を付ける
l(小文字エル) I(大文字アイ) O(大文字オー) 0(数字ゼロ)は似ているため、使用するときは注意を払っています。
コマンドのオプションやパスワードとして使用するときは、本当に間違いやすいです。念入りに確認して使用するようにしましょう。
手順書のフォントを工夫するのもいいでしょう。おすすめフォントはConsolasです。lIO0 が lIO0 に見えるようになります。
22. 第三者の質問に対してはこころよく教える
第三者の質問に対しては、基本的にどんな状況でも答えるようにしています。
質問者が経験値があるあなたに救いを求めて質問するのは、一生懸命考えた挙句分からなくてモヤモヤしているからです。(たまに自分で考えもせずに質問してくる方もいますが・・・。)
あなたも第三者に質問する時って、そんな感じだったりしませんか？だからこそ自分が分かるモノであれば、こころよく質問に答えてあげましょう。そうすることで質問者は成長しますし、最終的には自分の仕事も楽になるかもしれません。また教えることでアウトプットになり自分の成長にもつながります。
～まとめ～
改めて意識して行っていることを書いてみたのですが、意外と多くて驚きました。システム運用保守はどんなにひどいシステムを引継がれたとしても絶対に安定稼働させなければなりませんし、そのシステムが使われなくなるまで運用保守を続けなければなりません。だから運用保守は本当に大変な仕事ですし、責任重大なポジションなんです。もうIT業界の中で運用保守に携わっている人が一番頑張っているんじゃないか？と思えるほどです。だから軽視などしてほしくないわけです。運用保守に携わっている人が常日頃から頑張っているからこそ、当たり前のようにシステムが使えているということを忘れないでください。今後も引き続きシステムを安定稼働させるために、過信と油断をせずに頑張っていきたいと思います。