こんばんは。2012/04/07に、普段怒られながら障害対応してるであろう僕らが休みの日にわざわざ障害対応しに集まるイベント「トラブル☆しゅーたーず」に参加してきた (っ´∀｀)っ ゃーです。

■ トラブル☆しゅーたーず とは

シナリオ
あなたはとあるwebインテグレーターにつとめる社員です。
立ち居値としては、リーダークラス？
ちょっといい気分になってきていました。

ある日、待望の新入社員の山〇君がやってきました。
しかも、あなたの部署です。
OJTが一通り行われたあと、幸運にもあなたの配下に配属されたではありませんか。

さっそく、いろいろ教えつつ「これで少しでも負荷がさがれば。。。」とほくそ笑むのでした。
さてある日、山〇君にお客様のクラウド上のシステムメンテナンスを指示します。
さほど難しい作業ではなかったので、彼にまかせて別の作業を実施します。
しばらくすると、お客様から入電が・・・・

どうもお客様のシステムが調子がおかしいとのこと
山〇君にどのような作業を実施したのか確認しても
「何もやっていない」
「ログはとっていない」
と繰り返すばかりです。

一抹の不安を覚えつつ、あなたはチームを従えてコンソールに向かうのでした

という前提で障害対応のロールプレイをしよう！というhbstudy、ncstudy、odstudy合同開催の勉強会でした。

■ 最初にハンズオン

本編は会場およびインフラ提供のniftyさんで13時から開始だったのですが、ニフティクラウドの簡易ハンズオンを11時からやるということで、ニフクラ初体験の私はハンズオンから参加しました。ニフクラのゲストOSを触って気づいたことは次の通りです。

• ゲストOSはVMWare
• コンソールログインはvmware-vmrcから繋ぐ
• コントロールパネルはIEのみサポート (IronやFirefoxではvmware-vmrcのActiveXダウンロード不可)

ひと通り説明を受けた後、niftyの方から「よろしかったら rm -rf してみてくださいｗｗｗ」と言われたので、-v オプションまでつけてやってみました。今生きてるプロセスが掴んでいるファイル以外はまるっと消えて (当たり前ですね) lsコマンドも打てないので 「 echo * 」などのように bash内部コマンドのみで戦わざるを得ない状況でしたｗ

■ いよいよ本番

50名弱のドMなインフラエンジニアたちが集まり、いよいよ6チームに別れての障害対応です。はじめの前提条件は、次のスライドに示されていますが、詳細はログインしてみないとわかりません。
https://docs.google.com/presentation/d/1aIAh6JAzHHufsc_O1Xb0o_CY1pnJQgXxYfhep1rp-n0/edit#slide=id.p22

○ やらなければならないこと
・ サイトの復旧
・ 原因究明
・ 再発防止策提案
・ 障害報告書作成

○ こりゃひどいと声を上げたサーバの中身
・ MySQLがrpmとソースからインストールされていたのが1つずつあった
・ WordPressとMovableTypeが同居していた
・ PostgreSQLが動いていた
・ 踏み台サーバからログインと思いきやSSHでログインできた
・ WordPressは他所のサーバで作ったものを単純にコピーしただけだった (URIがDBに書かれているのでdumpして置換してインポートした)
・ zsh、bashのヒストリーサイズが0だったw
・ などなど・・・

ときどき運営スタッフがお客様という体で見回りに来るので、実際に手を動かす人(オペレータ)と全体統括者、顧客対応者(全体統括者が兼ねる場合もあり)がおのずと必要になってきそうです。全体的なタイムラインは Togetter をご覧ください。ここでは、私がいたチームについて振り返ってみたいと思います。

○ 同じチームに @koyhoge さんがいる！ということは、障害切り分けにそれほど苦労しなさそう (他力本願ではなく、スキルセットがある程度把握できているという意味で)
○ と思いきや、先に @koyhoge さんと私で手を動かす作業の7割がたを担ってしまい、特にドキュメンテーションまで @koyhoge さんがされていたので恐らく人的負荷が偏っていた
○ 僕も手を動かしたかったけど、ファシリテータに徹するか、ファシリテータを誰かにやってもらえばよかったかも
○ 運営が仕掛けた罠を一生懸命調査してたけど、それが障害の本質だったのかをもっと早めに判断できればよかった
○ 自分に自信がなくてあまり積極的に発言していなかったメンバーもいたけど、最初の15分くらいでチームビルドのための時間を設けて、間違ってもいいからどんどん自分の意見を言っていこうという空気を作ればよかった

というような反省があったかなーと思います。インフラ寄りのメンバーからアプリ開発者さんまでいたので、それぞれのスキルセットでできることをやったので、チームビルドと時間配分をしっかり意識していれば、時間内に100パー復旧しないまでも、きちんとした体裁で中間報告書は書けたのかなーと反省しきりです。(あくまでエクストリームスポーツであって、実際の障害対応はもっときちんと体制考えてやりますけどね)

■ 結果発表

タイムリミットがやってきて各チームの発表 (障害報告会) が行われましたが、みんな普段から謝り慣れているのか、どのチームもガチの障害報告すぎて笑えませんでした (；´Д｀) というか本当に胃が痛くなって、帰りに胃薬飲みましたがwww 今回はタイムリミットがある中にもかかわらず、時系列も含め原因特定から今後の再発防止策まで顧客にきちんと説明できたチーム2 が優勝で、ただただ感心するばかりでした。繰り返しになりますが、ほんとにお通夜な雰囲気でしたが・・・。ココらへんの雰囲気作りや壇上での障害報告の喋り方まで、ほんとの障害報告会のようで、なので「演技派インフラエンジニア」とタイトルにつけたのです。このあと、hbstudyの馬場さんによる講評がありました (以下資料参照)。

https://docs.google.com/presentation/d/117SdD0NjMaunm1UfFBFPPaXxdrgvvkeXnmMETConnMI/edit#slide=id.p22

■ やってみた感想

ほんっと繰り返しますけど、休みの日にわざわざ障害対応しに来るって、どんだけ僕らドMなのでしょうかｗ 一部、その後ガチ障害対応しに行った参加者もいましたが。。。けど、単なるハンズオンと違ってマイナスから0に持っていくという緊張感で、しかも初見のサーバで烏合の衆が集まって対応するんですから、いい勉強になったと思います。技術的にすごい人の真価(嗅覚やコマンド捌き、何が大事かの判断)を見られるのは勿論、手前味噌ながら自分も食らいついていけるだけのアシストはそこそこできたのかなと思いました。

あと、私は誰かに声かけするより先に、まずSSHの画面に向かって対応していたのですが、確かに障害対応ではこういう姿勢が大事です。メンバーの半分くらいは自分から声を出して「僕この作業しますー」というようなタイプではなかったので、次回があればそこに気をつけて、最初の15分くらいは手を止めてでも役割分担をきちんと明確にしておくべきでした。(先に気づいたもん勝ちなエクストリームは、チーム間でやるべきであってチーム内ではやるべきではなかった)

ここいらの反省を踏まえたら、仕事での障害対応をメンバーとしてもリーダーとしても更に高品質な対応ができるのかなと思いました。とにもかくにも、これだけの障害を仕込んだ運営の皆様、参加者の皆様、本当ーっに、お疲れ様でした！