もっと時間が取れる場合
以上、着任したてのインフラエンジニアが、一日一時間・一週間かけて実施可能な、安定稼働のための確認項目について記載した。
インフラエンジニアがトラブルシューティングのために臨時着任した場合、トラブルの元となっている事象（パフォーマンス障害など）が収束したらほどなく着任解除されるのが常である。
そのため、今回記載した確認項目について事前に手を打っておけば、一、二か月程度の期間は都度発生する障害対応に苦労するかもしれないが、そのあとは比較的安定した環境で自分の活動に専念することができるであろう。
しかし運悪く（?）、数か月以上、継続してトラブルプロジェクトに参入するということになった場合は、今まで記載した内容だけで乗り切るのは心許ないので、下記の内容についても確認しておくようにしたい。
保守内容の整理
トラブルプロジェクトの場合、どこからか調達した中古のサーバーを使って開発環境を追加することも多い。このようなサーバーは、ハードウェアが保守切れになっている可能性がある。保守切れとなったサーバーの場合、故障した場合に修理代が余計にかかったり、最悪の場合修理不可能となってしまったりする場合もある。そのため、重要な位置づけのサーバーについては、保守を復活させるか、または別のきちんとした保守のあるサーバーにその役割を移管することを検討する必要がある。
また、ハードウェアだけではなく、ミドルウェアやOSについても、サポートの状況や、ライセンス状況、ソフトウェアの保守期限の情報を確認し、一覧にしておくのが望ましい。トラブルプロジェクトでは、カットオーバーの時期が延びることもよく発生する。その結果、開始時点では十分な保守期間があったはずなのに、気がつくとシステムがカットオーバーした直後に保守切れとなっていたり、ひどい場合には開発期間中に保守切れになってしまっていたりすることすらある。この場合は、PMに支援を求め、延長保守加入やソフトウェアの中途バージョンアップを実施するなど、適切な対応を取る必要がある。
あと、保守の確認とは別に、ハードウェア・ミドルウェア・OSごとに、トラブルになった場合のサポート元の電話連絡先や、質問に必要なID・パスワードについても、事前に整理しておくことが有用である。万一の障害の時に速やかな対応が可能となるばかりでなく、手が離せないような場合であっても、他の誰かに障害サポートコールの実施を依頼できるかもしれないからである。
OS・ミドルウェアのパラメータ管理
OS・ミドルウェアのパラメータリストを作成し、管理しておく。「何を当たり前のことを……」と考えられるかもしれないが、当たり前のことが実施されていないのがトラブルプロジェクトである。
これにより、突発的にサーバーや設定内容が初期化されてしまっても、被害を最小限に防ぐことが可能となる。
UNIXサーバーであればcrontabなどシステム構成ファイルの内容、OSのオプション。Windowsサーバーであれば環境変数の値などである。
ただし、これらについては、管理すべき項目が多いため、網羅的に調査するとなると結構な工数がかかる。そのため、本来の工数に余裕ができた場合や、バックエンドの支援が得られる場合に依頼するとよい。
運用安全性向上
トラブルプロジェクトでは、長時間の労働に加え、作業品質の低下が懸念される。具体的には、人手不足により一人だけで作業したり、手順書なしでの作業を行ったり、疲労により通常はやらないようなミスをしてしまったり、といったことである。
例えば、疲労により、指が必要以上にぴくんぴくんと動いてしまい、マウスの右クリックを押してはいけない場面で突然右クリックが押されてしまった結果、コマンドプロンプトに削除コマンドやホスト名変更コマンドが大量に投入されてしまった……などということが発生しうるのである。また、スケジュールに追われる担当者が、一人で勝手に作業を実施した結果、システム破壊が発生してしまった事例もある。
長時間労働や、人手不足によるミスを極小化するためには、現在の運用の問題点を洗い出し、運用改善を行う必要がある。
すぐにできる運用改善の例としては、重要作業についてペアで実施する・マウスの右クリック操作によるコピーペーストは最小限にする・何かを削除する場合は事前にレビュー・もしくは作業申請を行う、特定のコマンドを禁止とする（rmなど）、端末のtelnetクライアントやOSの機能で接続ログを必ず残すようにする、などが挙げられる。
電力配線調査
急造のマシン室では、タコ足配線が枝分かれになっている状態のコードをしばしば見受けるが、このような配線は火災のもととなり、大変危険である。
また、仮にタコ足配線にはなっていなくとも、単一の電源経路に大量の機器を接続すると、ブレーカーが落ちる事故や、落ちるとまでは行かずとも、各サーバーへの電圧供給低下を招き、ひいてはハードウェア障害のもととなる。
「サーバーが一番電力を消費するのは起動時で、待機時の電力はそれほどでもないから、一個ずつ10分ずつあけて順番に起動すれば、ブレーカーの制限を超えないから大丈夫」という裏技（?）を編み出しているプロジェクトもあるが、例えばテストにより複数のサーバーに高負荷がかかったり、一斉に再起動が発生してしまい、結果として一度に大量の電力消費が発生してしまったりする場合もある。この場合、あっという間にブレーカーが落ちれば運がよい方で、ひどい場合はコードが発熱して火災が発生する。仮に運用により、そのような事態を回避できていたとしても、このような配線は安全性の観点で問題が多々あるので、やめるべきである。
では、すでにこのような配線になっていた場合、どのように改善すればよいか。
前編にも記載したが、まずは、電源経路やコンセントがほこりまみれになっていないかを確認しよう。ほこりまみれになってしまったサーバーの場合、やみくもに配置換えを行っても、ほこりが舞い上がってかえって危険だからである。
この場合は、電気配線のほこりをなるべく取っておき、火災の可能性を防ぐと共に、プラグの接続状態を確認し、トラッキング現象が発生しないようにする。ただし、前述した通り、サーバー本体を移動させると、内部にたまったほこりがマザーボードに落下することによりサーバーが稼働しなくなることもある。そのため、勢いよく移動したり、サーバーを傾けたりして、ほこりを不要に舞いあげないように、細心の注意が必要である。
その後、各電源経路の配線の電力量を見直し、必要に応じてつなぎ替える。このときは冗長化電源となっているサーバーであれば、2つの経路から電源を取るようにするとなお良い。統制の取れたプロジェクトであれば、勝手にサーバーが持ち込まれることは考えられないが、トラブルプロジェクトの場合、闇サーバーが立っていることがよくある。この場合は、電力量表示やブレーカー機能付きのタップをあらかじめコンセントにじかにつけておき、想定電力量を超えていないか確認する、という手段も有効である。
電源配線については、例え別々のコンセントから電気を引いていても、その上流では単一の電源経路になっていることもある。ビルの管理室などに照会し、配線図や、各経路単位での許容電力量の情報を入手しておくことで、より安全な電力配線を計画することが可能となる。
監視運用
急造のマシン室に配置された機器については、適切な監視運用がなされていないことが多々ある。ランプ確認など目に見えるものであれば人海戦術でも対応可能であるが、毎回コマンドを打たねば確認できないような確認内容については、時間が経つにつれ、実施することを忘れてしまったり、確認作業がおろそかになったりしがちである。
このような確認については、簡単なシェルなどを組み、システムの状態を自動的にログに出力させることで、負荷軽減させることが可能である。メールでプロジェクト内アドレスに送付させるとより楽に確認可能である。
なお、機器のランプについては、同じ人が毎日確認すると変化に気づきにくいことがある。そのため、当番制を設定し、複数人での監視を行うことも有効である。
まとめ
以上、トラブルプロジェクトに着任したインフラエンジニアが、簡単に確認可能な事項について、重要な順に記載した。
とかくトラブルの最中は、スケジュールの遅延を取り戻すことが最優先となるため、品質の担保が後回しになってしまう。
プログラム開発の場合、品質低下⇒バグの増加⇒さらなるプロジェクトの遅延、という負のスパイラルとなって帰ってくるため、そこで、最終的な歯止めがかかる（もちろん、その負のスパイラルに陥らないようにする必要があることは言うまでもない）。
しかし、インフラエンジニアの担当範囲は、システム全体の基盤である。そのため、ここの品質がおろそかになった場合、プロジェクトのさらなる遅延を招くのみならず、最悪の場合、データロストや、火災発生など、取り返しの付かない事態を招くことすらある。
トラブルプロジェクトでしばしば見受けられる「品質の悪い、危険なインフラ」という地雷を回避し、一刻も早く健全な状態を取り戻すために、本稿の記載をぜひご活用いただきたい。
