対象読者
- トラブルプロジェクトに投入されるインフラエンジニア
- そのエンジニアを使うプロジェクトマネージャ
はじめに
常日頃から、突発的なシステム障害に際し、昼夜問わず対応することを迫られているインフラエンジニア。
そのような立場にあるインフラエンジニアにとって、トラブルプロジェクトに投入されるということは、本来のプロジェクト遅延キャッチアップ作業に加え、日々巻き起こる嵐のような障害（特に、ハードウェア・OS・ミドルウェア障害）に24時間忙殺されることを意味する。そのようなときは、「トラブルを収束させ、困っている人を助けねばならない」「リスクが恐怖であってはならない」と頭では分かっていても、身がすくむ思いがしてしまうものである。
通常のシステムエンジニアとインフラエンジニアのトラブル対応には、以下のような特性の違いがある。
通常のシステムエンジニアのトラブル対応
- 想定外の突発的な事態の発生確率が（比較的）少ない
- 自分の専門に何らかの関係があることが多い
インフラエンジニアのトラブル対応
- 想定外の突発的な事態の発生確率が（比較的）多い
- 自分の専門でないことが多いにも係わらず、何とかする必要がある
通常のシステムエンジニアのトラブル対応は、何らかの自分の専門対象に係わる内容が多いのが普通である。例えば、PMスキルメンバーであればPMOとしての活動、特定アプリケーションの専門家であればコードレビュアー、DBアドミニストレーターであればSQLチューニングなどである。
しかしインフラエンジニアの場合、発生している多くの障害は自分の専門外のことである。例えば、バックアップや監視系が専門のインフラエンジニアであっても、現場に出ると、今その場で発生している障害、例えば、ディスク障害や、パフォーマンス低下、プロセス／サーバーハングアップ、などの調査をさせられる。
「ちょっと、サーバーに繋げないんだけど！ 基盤、なんとかしろ！」 「俺達今日は帰るので、基盤の責任で、明日の朝までに復旧させとけよ。」
開発者や、プロジェクトマネージャーにこのような悲しい発言をされたインフラエンジニアも少なくないだろう。
このようなケースの場合、仮に、「これは私の専門ではないので……」と断っても、それで専門のメンバーを別途呼んでもらえることはまずない。
「そのために君を呼んだのだよ。テストケースが消化できないから、なんとかして。」とプロジェクトマネージャーになだめすかされ、結局 端末の前に座らされ、自力でなんとかすることになる。
かくして、トラブルプロジェクトに着任したインフラエンジニアの最初の仕事は半自動的に障害対応、問題判別ということに落ち着く。
しかし、ここで気をつけるべき点がある。
それは、『現在発生している障害は氷山の一角で、水面下には、まだ顕在化していない障害が大量に存在する可能性が高い』 ということだ。特にトラブルプロジェクトの場合、障害を未然に防ぐための、リスク軽減プロセスがうまく回っていないことが多々あるため、その傾向が通常のプロジェクトより大きいと言える。
ただし、『顕在化していない障害が大量に存在する可能性が高い』状態は、必ずしも悪いことばかりではない。なぜならば、着任する前から発生していた障害については、もはやそれを解決する（または軽減する）ことしかできないが、まだ顕在化していない障害については、着任したその日から、「その障害が顕在化する前に、解消もしくは回避する」アプローチを取ることが可能であるからである。
逆に言うならば、そのアプローチを取ることをせず、顕在化していない障害を次々に解決していかないからこそ、次々に発生する障害に対し、24時間忙殺される、というはめになるのである。
このような事態に陥らないようにするためには、直近で発生すると予想される新たな障害の予兆をできるだけ早く検知し、顕在化する障害の総量を減らす必要がある。
多くの場合、障害は、発生する前に解決した方が圧倒的に復旧しやすい。特にデータを失うような障害は、いったん発生させてしまったら致命的である。
重要なのは、障害が発生する前に、先手を打って、障害発生を防止することだ。どんなにひどい障害でも、発生さえ回避できれば、被害は抑えられるからである。すなわち「当たらなければ、どうということはない」。まさに「やられる前にやる」ことが最も大切なのだ。
とはいえ、トラブル対応のまっただ中にいる状態では、なかなかそうした活動を実践するのは難しいというのも理解できる。
そこで、この記事では、トラブルプロジェクトに不幸にも投入されてしまったインフラエンジニアが、さらなる苦境に陥るのを未然に防ぎ、一刻も早く人間らしい生活を回復させるために、一日一時間でできる障害発生防止策について記載していくことにする。
