「当たらなければ どうと言うことはない」 先制攻撃7日間 - インフラエンジニアのトラブル防御策(前編)

CodeZine / 2012年3月1日 14時0分

 専門外のテーマであっても、突発的なトラブルに対し、昼夜問わず、なんとかすることを強いられることが多いインフラエンジニア。身を守るには、今後の発生が予想されるトラブルの芽をつぶすような、積極的な防御策が必要となる。本稿では、その指針を新任エンジニアの着任7日間になぞらえて紹介する。

■対象読者

トラブルプロジェクトに投入されるインフラエンジニア そのエンジニアを使うプロジェクトマネージャ ■はじめに

 常日頃から、突発的なシステム障害に際し、昼夜問わず対応することを迫られているインフラエンジニア。

 そのような立場にあるインフラエンジニアにとって、トラブルプロジェクトに投入されるということは、本来のプロジェクト遅延キャッチアップ作業に加え、日々巻き起こる嵐のような障害(特に、ハードウェア・OS・ミドルウェア障害)に24時間忙殺されることを意味する。そのようなときは、「トラブルを収束させ、困っている人を助けねばならない」「リスクが恐怖であってはならない」と頭では分かっていても、身がすくむ思いがしてしまうものである。

 通常のシステムエンジニアとインフラエンジニアのトラブル対応には、以下のような特性の違いがある。

●通常のシステムエンジニアのトラブル対応

想定外の突発的な事態の発生確率が(比較的)少ない 自分の専門に何らかの関係があることが多い ●インフラエンジニアのトラブル対応

想定外の突発的な事態の発生確率が(比較的)多い 自分の専門でないことが多いにも係わらず、何とかする必要がある  通常のシステムエンジニアのトラブル対応は、何らかの自分の専門対象に係わる内容が多いのが普通である。例えば、PMスキルメンバーであればPMOとしての活動、特定アプリケーションの専門家であればコードレビュアー、DBアドミニストレーターであればSQLチューニングなどである。

 しかしインフラエンジニアの場合、発生している多くの障害は自分の専門外のことである。例えば、バックアップや監視系が専門のインフラエンジニアであっても、現場に出ると、今その場で発生している障害、例えば、ディスク障害や、パフォーマンス低下、プロセス/サーバーハングアップ、などの調査をさせられる。

「ちょっと、サーバーに繋げないんだけど! 基盤、なんとかしろ!」 「俺達今日は帰るので、基盤の責任で、明日の朝までに復旧させとけよ。」
 開発者や、プロジェクトマネージャーにこのような悲しい発言をされたインフラエンジニアも少なくないだろう。

 このようなケースの場合、仮に、「これは私の専門ではないので……」と断っても、それで専門のメンバーを別途呼んでもらえることはまずない。

 「そのために君を呼んだのだよ。テストケースが消化できないから、なんとかして。」とプロジェクトマネージャーになだめすかされ、結局 端末の前に座らされ、自力でなんとかすることになる。

 かくして、トラブルプロジェクトに着任したインフラエンジニアの最初の仕事は半自動的に障害対応、問題判別ということに落ち着く。

 しかし、ここで気をつけるべき点がある。

 それは、『現在発生している障害は氷山の一角で、水面下には、まだ顕在化していない障害が大量に存在する可能性が高い』 ということだ。特にトラブルプロジェクトの場合、障害を未然に防ぐための、リスク軽減プロセスがうまく回っていないことが多々あるため、その傾向が通常のプロジェクトより大きいと言える。

 ただし、『顕在化していない障害が大量に存在する可能性が高い』状態は、必ずしも悪いことばかりではない。なぜならば、着任する前から発生していた障害については、もはやそれを解決する(または軽減する)ことしかできないが、まだ顕在化していない障害については、着任したその日から、「その障害が顕在化する前に、解消もしくは回避する」アプローチを取ることが可能であるからである。

 逆に言うならば、そのアプローチを取ることをせず、顕在化していない障害を次々に解決していかないからこそ、次々に発生する障害に対し、24時間忙殺される、というはめになるのである。

 このような事態に陥らないようにするためには、直近で発生すると予想される新たな障害の予兆をできるだけ早く検知し、顕在化する障害の総量を減らす必要がある。

 多くの場合、障害は、発生する前に解決した方が圧倒的に復旧しやすい。特にデータを失うような障害は、いったん発生させてしまったら致命的である。

 重要なのは、障害が発生する前に、先手を打って、障害発生を防止することだ。どんなにひどい障害でも、発生さえ回避できれば、被害は抑えられるからである。すなわち「当たらなければ、どうということはない」。まさに「やられる前にやる」ことが最も大切なのだ。

 とはいえ、トラブル対応のまっただ中にいる状態では、なかなかそうした活動を実践するのは難しいというのも理解できる。

 そこで、この記事では、トラブルプロジェクトに不幸にも投入されてしまったインフラエンジニアが、さらなる苦境に陥るのを未然に防ぎ、一刻も早く人間らしい生活を回復させるために、一日一時間でできる障害発生防止策について記載していくことにする。



■関連記事
「当たらなければ どうと言うことはない」 先制攻撃7日間 - インフラエンジニアのトラブル防御策(後編)
「当たらなければ どうと言うことはない」 先制攻撃7日間 - インフラエンジニアのトラブル防御策(前編)
先輩ライターに訊く、技術文書執筆のアレコレ(3) ~初心者向けの技術文書/合田英二さん
先輩ライターに訊く、技術文書執筆のアレコレ(2) ~チーム執筆/須江信洋さん
先輩ライターに訊く、技術文書執筆のアレコレ(1) ~花井志生(宇野るいも)さん

■記事全文へ

CodeZine

トピックスRSS

ランキング