SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

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

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

「機器のランプ」「ディスクのミラーリング」「日々のバックアップ」の確認

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

対象読者

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

はじめに

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

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

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

通常のシステムエンジニアのトラブル対応
  • 想定外の突発的な事態の発生確率が(比較的)少ない
  • 自分の専門に何らかの関係があることが多い
インフラエンジニアのトラブル対応
  • 想定外の突発的な事態の発生確率が(比較的)多い
  • 自分の専門でないことが多いにも係わらず、何とかする必要がある

 通常のシステムエンジニアのトラブル対応は、何らかの自分の専門対象に係わる内容が多いのが普通である。例えば、PMスキルメンバーであればPMOとしての活動、特定アプリケーションの専門家であればコードレビュアー、DBアドミニストレーターであればSQLチューニングなどである。

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

「ちょっと、サーバーに繋げないんだけど! 基盤、なんとかしろ!」
「俺達今日は帰るので、基盤の責任で、明日の朝までに復旧させとけよ。」

 開発者や、プロジェクトマネージャーにこのような悲しい発言をされたインフラエンジニアも少なくないだろう。

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

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

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

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

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

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

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

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

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

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

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

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

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
着任一日目:機器のランプの確認

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
「当たらなければ どうと言うことはない」 先制攻撃7日間 - インフラエンジニアのトラブル防御策連載記事一覧
この記事の著者

浜口 悟(ハマグチ サトル)

90年代前半のUnixサーバ管理業務を皮切りに、主に金融機関のネットワーク/サーバ構築・CGI/サーブレット開発・インフラ構築を担当。現在は企業のBCP策定支援を行う傍ら、運用ミスや基盤品質低下による障害発生を未然に防止するための草の根活動を行っている。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6389 2012/03/01 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング