対象読者
- トラブルプロジェクトに投入されるインフラエンジニア
- そのエンジニアを使うプロジェクトマネージャ
前回のあらすじ
前回の記事では、トラブルプロジェクトに不幸にして着任してしまったインフラエンジニアが、更なるトラブルに巻き込まれないために、まず確認すべきシステムの健康状態について記載した。今回は、そのほかに確認すべき事項について記載する。
なお、前編では、一日目～三日目という順番で優先順位を付けて対応を実施するようにしていたが、四日目以降の内容については、プロジェクトの状況に応じて優先順位を変化させて構わない。例えば、パフォーマンス障害が出ているプロジェクトの場合は、調査のためにログなどを大量に出力することが多いため、ディスク容量周りの確認を優先して実施したほうがよい。
着任四日目：ウィルス検知ソフトの確認
トラブルプロジェクトに限った話ではないが、クライアント端末が大量に存在するプロジェクトの開発環境には常にコンピュータウイルスの感染の危険が付きまとう。インターネットに接続された環境はもちろん、外部から遮断された開発環境の場合でも、USBメモリによるデータのやり取りなどで、ウィルス感染するケースがある。
トラブルプロジェクトの場合、開発環境のクライアント端末の状態は利用者任せになっていることがある。具体的には、各社の持ち込みクライアント端末が繋がれ放題になっている、等である。そのため、各クライアント端末に導入されているウィルス検知ソフトのパターンファイルが最新化されていることを確認しておくべきである。
ただし、ウィルス検知ソフトの確認作業は、サーバーだけではなく、全てのクライアント端末に対して調査を行う必要があることに注意が必要である。
サーバーの場合、主たる設置場所であるプロジェクトルームは、多くの場合ただのオフィスビルであり、データセンターのように大量の電力が使用できるわけではない。そのため、プロジェクトルームに設置可能なサーバーは通常数台～多くても十数台程度であるため、新規着任のインフラエンジニアでも片手間に確認できる規模である。
一方、クライアント端末は少なくとも開発者の人数分、一人で数台使っている場合はその台数分の確認が必要となる。そのため、全クライアント端末に対して調査するとなると、確認作業のワークロードは一日一時間でできる内容をはるかに超えてしまう。よって、クライアント端末の状況確認と更新運用の確認を一通り実施した後は、開発者や、プロジェクトマネージャーを巻き込み、個別のメンバーが自分のクライアント端末の状態を確認する運用を設ける等の工夫をするとよい。
着任五日目：システムバックアップの状態検査
トラブルプロジェクトの場合、作業ミスや製品パッチ適用などによりサーバーが論理的に破壊されてしまう確率が通常の安定稼働中のシステムより高い。
それにもかかわらず、トラブルプロジェクトの場合、サーバーのシステムバックアップが定期的に取られていることはまずなく、往々にしてOS導入後のイメージしかない状態であったりする。ひどい場合だとそれすら存在せず、OSの再導入になるケースもある。この場合はインフラエンジニアが数日徹夜するだけでは済まず、プロジェクトへのインパクトも多大なものになってしまう。
ここでは、一日一時間でできる範囲ということで、まずはシステムバックアップの状態がどうなっているかを検査する。具体的には、システムバックアップがそもそも存在するか、それはいつ取得されたものか、システムバックアップの保管先媒体の状態は良好か、等といったことである。
また、システムバックアップが取られていても、そのバックアップと紐づいた管理者パスワードが記録されていない場合、復元後のシステムは旧パスワードに戻ってしまっているため、ログインできない。そのため、システムバックアップを取得した時のパスワードが保管されているか、についても、併せて確認が必要である（OSによってはパスワードリセット用のディスクを用いる等の手段でこの問題を回避可能なものも存在する）。
確認の結果、システムバックアップが取られていなかったり、古かったりする場合は、更新の計画を立てる必要がある。
システムバックアップ取得中は、ある程度の時間サーバーが停止することになるため、スケジュールや作業する人手を確保する必要がある。かといって、システムバックアップを取得しないわけにもいかない。仮にシステムバックアップを取得しなかった場合のリスクが甚大になるということを、プロジェクトマネージャーによく説明し、対応する方向で調整を実施する必要がある。
着任六日目：ディスク容量確認
トラブルプロジェクトの場合、ワークエリアやログが適切に掃除されていることは少なく、往々にしてたまり放題、使われっぱなしになっている。ひどい場合は、容量フルになってしまった区画は放置し、新しい区画を作成するといった、焼畑農業のような運用になっていることもある。
まずは各ファイルシステムの容量一覧を取得しておき、容量フルになっている場所がないかを調査。すでに100%近くなっている場所については不要ファイル調査や、割当量を増やせないか検討する必要がある。割当量を増やす際は、増やした領域が正しく冗長化構成されているかも確認すること。前編でも記載したが、区画増設の際に冗長化構成が適切に実施されていないという事例は、初歩的なミスであるが、しばしば見受けられる状態でもある。
また、区画の使われ方によっては、手当をしても、しばらくするとまたいっぱいになるということもあるため、しばらくの間は週に一回程度の頻度で再度容量フルになっていないか確認したほうがよい。
着任七日目：構成管理
通常のプロジェクトの場合、システム管理者の目が行き届いていることが期待できるが、トラブルプロジェクトの場合は、各サーバーの設定内容がシステム管理者の適切な運用の元構成管理されていることは少なく、権限委譲された各システムの管理担当者が都度いきあたりばったりのメンテナンスを行ったり、ひどい場合にはアプリの開発者が試行錯誤でメンテナンスを実施していたりする場合がある。
また、構成管理の中でも、特にパッチのバージョン管理については、注意が必要である。パッチ適用は十分な計画の元、速やかに各サーバーに適用される必要があるが、トラブルプロジェクトの場合、往々にして、パッチ不整合によるトラブルが発生する。その理由は様々であるが、例えばテスト実施のために必要なパッチであるにもかかわらず、テストでフル回転しているサーバーは止められない、という本末転倒な理由で適用されていなかったり、ひどい事例では、台帳上は全サーバーに適用したことになっているのに、特定のサーバーのみ適用失敗しており、実は古いバージョンで稼働していたり、ということすらある。
構成パラメータや、作り込みのツールのバックアップを一度取得し、管理すると共に、構成の運用について確認・整理を行うべきである。
