トラブル☆しゅーたーずで障害対応能力の真髄を感じてきた。

報告がすっごく遅くなってしまって申し訳ございません(´Д`；)

04/07にニフティセミナールームで開催されたhbstudy+ncstudy+odstudy合同開催
「トラブル☆しゅーたーず〜障害対応(トラブルシュート)の先にあるもの〜」に参加してきました。

troubleshooters_eyecatch.jpg

今回はncstudy運営として、主に事前の仕込みである擬似障害発生環境構築を担当させていただきました。
初めての「合同開催」という試みでしたので、どんな感じになるか当日までドキドキしてました。

「トラブル☆しゅーたーず」について

今回の勉強会はhbstudy、ncstudy、odstudyの合同開催の勉強会として、ニフティクラウド上に構築されたシステムに対して、実際にありそうな障害対処をするだけでなく、障害報告や再発防止の検討、より障害が発生しにくいような提案をまとめることによって、「実践的な障害対処能力を養う事」を目的にして開催されました。

合同開催として、各勉強会の要素がしっかりと組み込まれたものだったと思います。

  • クラウド上に構築されたシステムの利用→ncstudyの要素
  • LAMP構成のシステムへの対処→hbstudyの要素
  • 障害報告、再発防止策等の報告書の作成→odstudyの要素

当日の様子については、勉強会参加者の方々の悲痛な叫び素晴らしいレポートが挙がっていますので、そちらを参考にしていただき、自分は運営側として当日までの仕込みや当日の運営チームの様子をレポートしようと思います。

擬似障害の内容を考える

擬似障害の内容については下記のポリシーに沿って設定しました。

  • 山◯君がすっごーーーく悪者に見えるんだけど、実際には彼に非がない障害である事
  • ありがちなミス等で発生する障害である事（リアリティがある障害）
  • 時間内で終わる程度の障害である事
troublememo.png

この辺は、馬場さん(@netmarkjp)、山口さん(@meryo2000)、前田さん(@tmae)とホワイトボートを囲みながら ヾ(´∀`)ﾉ ｷｬｯｷｬｯ（・∀・）ﾆﾔﾆﾔしながら大まかな状態を決めていきました。（夜22時過ぎとは思えないテンションでしたｗ
内容決めに当たっては、「どの程度なら時間内に解決出来そうなのか」というレベル感の設定に苦労した感じがあります。
実際の環境構築時は、細かなデティールを馬場先生監修の元作り込み、リアルさを出せる様に努力しました。

擬似障害発生環境紹介

今回はニフティクラウド上に作成されたシステムで発生した障害を題材にしていましたのっで、下記のような擬似障害環境を１チームに１セットづつ、アカウント毎に作成してお配りしました。
（沢山のニフティクラウドのアカウントを貸していただき有難うございました。）

構成

  • 基本的なLAMP構成をベースにいろいろ仕込み。今回障害が発生したサーバ。
ホスト名Honban
OSCentOS 64bit Plane
スペックNIFTY Cloud Small
その他作成時に「起動スクリプト」適用済み
  • 謎のWindowsサーバ（本当はこのサーバからコンソール接続でHonbanにログインして操作してもらう予定だった）
ホスト名Fumidai
OSWindows 2008 R2 Standard
スペックNIFTY Cloud Small4
その他

外から見える主なURL

  • 復旧対象の本番環境サイト（WordPress + ソースからコンパイルしたMySQL5.5）
    • http://「HonbanのIP」/
  • 罠サイト　その１（WordPress + yumでbaseからインストールしたMySQL5.1)
    • http://「HonbanのIP」/test/
  • 罠サイト　その２ (MovableType + SQLite）
    • http://「HonbanのIP」/mt/

仕掛けた罠とその意図

  • HonbanのzshでHistoryを残さない→HISTSIZE=0

「セキュリティには詳しくないが、セキュリティにウルサイ企業」という想定

  • Nginxが起動している

キャッシュとして使っているかの様なそれっぽい設定は書いてあり、実際に8080ポートで待受しているが、単に起動しているだけで何も影響が無い
負荷対策を考え、途中まで設定したが設定途中で諦めたという想定

  • PostgreSQLが起動している

ユーザも作成してあり、実際に利用可能な状態。なぜかデータベースにもデータ投入済みであるが、単に起動しているだけで何も影響が無い
過去にPostgreSQLを検証したままほったらかしという想定

  • Apacheのドキュメントルート配下にWordPressが２種類、MovableTypeが１種類存在する

過去にMovableTypeとWordPressを比較検証し、検証時の設定がそのまま残っているという想定
/mt配下のMovableTypeはSQLiteをデータベースとして、デフォルトセットアップしただけ

  • /test配下にテストで作成したWordPressが残っている

yumからインストールしたMySQL5.1を利用
/etc/init.d/mysqld が起動スクリプト　ポート3307で起動
自動起動する(chkconfig mysqld on)
運用途中から最新版のMySQLを使いたくなり、本番では別途ソースから導入したという想定

  • ドキュメントルート(/)直下に本番サイト用WordPress。が、DBの設定がいびつになっている。

ソースからコンパイルしたMySQL5.5を利用
/etc/init.d/mysql が起動スクリプト　ポート3306で起動
自動起動しない(chkconfig mysqld off)

  • 開始時点では「/etc/init.d/mysql.bak」と「/etc/init.d/mysql」という２つの起動スクリプトが存在する
    • ２つの起動スクリプトの異なる点は「datadir」のパス
    • 「/etc/init.d/mysql」が「datadir=/usr/local/mysql/data」で「/etc/init.d/mysql.bak」が「datadir=/usr/local/mysql」となっている
      -「/usr/local/mysql」配下と「/usr/local/mysql/data」配下それぞれに似たようなMySQLのバイナリデータが配置されている
    • 「/usr/local/mysql」配下のバイナリが正しいサイトのデータを持っている。
    • 前任者がソースからコンパイルして、自前で起動スクリプトを作成した際に誤った設定をし、そのまま運用されていたという想定

なお、直前の山◯君のメンテナンスはこの本番サイトのDBのフラグメント解消を目的としていた

  • ApacheのモジュールとWordPressのプラグインで２種類のキャッシュが有効になっている

Acpcheがmod_disk_cacheでドキュメントルート(/)直下だけ静的にキャッシュしており、さらにWordPressがWP SuperCacheプラグインでドキュメントルート(/)直下だけキャッシュする設定
WP SuperCacheは強制的に１年間有効なキャッシュを生成し、コンテンツの更新が無い限りはデータベース接続が無くてもキャッシュからページを返す設定
当初mod_disk_cacheを導入したが、効果が薄かったので、WP SuperCacheを後から導入したという想定

  • /root/mente配下にメンテナンス用のshellスクリプトを配置

今回実施するメンテナンスの正しい作業内容が記載されたスクリプトが下記のいずれかに含まれている

　dump_all-new.sh
　dump_all.sh
　dump_all.sh.bak
　dump_all.sh.bak2
　dump_data.sh
　dump_data.sh.save
　restore-all.sh
　restore.sh

実は前任者は作業を全てスクリプトにしていたため、簡単な手順書しか作ってなかったという想定

仕込む予定だったもの

  • Honbanではsshdが起動していない

chkconfig sshd offにした上でsshdを落としておき、Fumidaiからコンソール経由じゃないとサーバにログイン出来無い状態にする、、、予定でした。
環境構築用のスクリプトでこの処理が抜けていた・・・完全に自分のミスですごめんなさい(´Д⊂

  • Honbanに「Oracle Database Express Edition 11g Release 2」がセットアップされていて、Fumidaiにクライアントが入っている

惑わすために仕込みたかったが、環境構築スクリプトに組み込むのが間に合わなかった。
Oracle様は難しいアルヨ。Oracleェ・・・

環境構築の感想と反省

環境構築については、作成した環境構築スクリプトの不備でいくつかつまらなくなってしまったのが悔やまれます。
sshdを落とし忘れるとか最もたる例で、大分つまらなくしてしまったなぁと反省。
さらに、/usr/local/mysql/data配下のバイナリデータ（謎のコーポレートサイトのDB）の中に、IPアドレスの書き換え漏れがあって運営チームで検証していた時のIPのままだった箇所がありました。
これは、チーム４が大ハマリした原因となってしまった様なので、申し訳なかったなぁと思っています。
（言い訳すると、誤った方のデータベースの中身まで確認するチームがいる事を想定していませんでした。ゴメンナサイデス。。。）

環境構築は、運営チームで障害内容の大枠を決めたのが木曜日22時で、実施に環境構築スクリプト作成開始したのが金曜日20時でした。
後はFacebookのチャットでワイワイやりながら作り込みをしていきました。
そして、自分がスクリプトを組みながら寝落ちするという失態をかまし、復活後、4時過ぎくらいから一気に全チームの環境構築と動作確認をしていました。
結局全チーム分の環境が揃ったのが当日土曜日の11時！という超ギリギリなスケジュールでした(´Д`；)

差し迫る期限の中、追われる様に環境構築をするという、さながら障害対応の様な作業をしていました。

仕込んだ内容については、馬場さんがいつの間にか作っていた「五月女商会」のサイトがいい感じに罠を張っていて面白かったです。
混乱を促す仕掛けとして、キャッシュによる静的ページと動的生成されるサイトを混ぜて、画像を外部参照にしたり、問い合わせページを用意したりと勉強になりました。

当日の感想とまとめ

当日の感想としては、みなさんレベルが高く、運営側としてはあっという間に終わってしまうんじゃないかとドキドキしていました。

特に自分としては、チーム５とチーム２がすごく良かったなぁと思います。
チーム５はダントツに障害復旧するまでの時間が早く、なんと運営チームへの問い合わせを１回もせずに障害復旧させました。
さらに、発表資料の体裁も完璧で、発表時の雰囲気は本当に顧客影響がある障害が発生してたんじゃないかと思わせる物でした。
チーム２は復旧連絡は早かったのですが、お問い合わせページがおかしいままだったので差し戻しをした関係で、障害復旧時間は多少遅めでした。
しかし、発表資料は報告のポイント（詳細は解答編を参照の事）がキチンと抑えてありました。

結局すっごく悩みましたが、「顧客視点」に重きをおいて判断した結果、チーム２が優勝となりました。
チーム５はとても僅差だったと思うので、次回も是非トラブル☆しゅーとして頂きたいです(・∀・)!!

あとは、運営としては、「お客様」って窓口（席やTwitterタグ）を一個作ると良かったかなと思いました。
TwitterのTLを見返していて、「運営」としての発言なのか、「お客様」としての発言なのかちょっとわかりづらかったかなと思います。
こうした反省点は次回に活かしたいですね。

今回は、想像していた以上に盛り上がって仕込みをがんばったかいがありました。
運営チームでは、すでに次回案（障害内容）も練り始めていますので、また面白い勉強会が開催できればと思います。

選りすぐりの障害を用意して皆様をお待ちしております。

最後に