Webサイトのダウンや停止を2回経験したGDOが得た経験と教訓 | ゴルフダイジェスト・オンライン

クリックするとセミナーの内容を動画でご覧いただけます（動画を別ウィンドウで開く）

クリックで動画を表示
（ボックスが広がって
再生が始まります）

powered by 株式会社ヒューマンセントリックス

イベント最後の基調講演には、ゴルフダイジェスト・オンライン（GDO）のシステム部 部長 渡邉信之氏が登壇。「システムの安定稼働の維持」という観点から、同社が過去に経験したシステム刷新プロジェクトやトラブルなどの事例をもとに、企業はどのようにシステムを運用すべきか、また、万一のトラブルからの早期回復に向け、企業が準備しておくべきポイントについて解説した。

インターネットサービス事業者として致命的な状態だった

株式会社ゴルフダイジェスト・オンライン
システム部 部長
渡邉 信之 氏

GDOは会員数約200万人、月間約1.5億PVという、巨大なゴルフ総合サイト（予約・EC・メディア）である。金融業界を経て2006年に同社に入社し、現在はシステム全体の設計やマネジメントなどを行っている渡邉氏は、まず入社当時に抱えていた同サイトのシステム上の問題点について語った。

GDOは、「ゴルフ場総合メディア」「ゴルフ場の予約サービス」「ゴルフ用品のEC」の3つサービスから構成されている。しかし、2006年当時のGDOはいくつかの問題点を抱えていた。

1つは「予約サービス」で、ピーク時である昼間（12:30～13:00ごろ）はほとんど予約できない状態であった。もう1つは「ECサイト」で、こちらもアクセスのピークである夜間（22:00～0:00ごろ）は、検索結果の表示エラーや注文確定時のタイムアウトエラーが頻発する状況であり、「インターネットサービス事業者としては致命的な状態だった」と渡邊氏は振り返った。

また、ベンダーとの保守契約がないため自社で原因を解析し対応しなくてはならなかった。システム部門では復旧を目指すものの原因を特定できず、障害対応に追われていたため、新しい改善策に十分な工数を割けない状態だった。

こうした状況を改善するため、同社はシステムの安定稼働を企図して、2006年と2007年の計2回にわたりシステム刷新プロジェクトをスタートさせた。しかし、プロジェクト全体を取りまとめるマネジメントの不備など様々な要因があり、結局プロジェクトは頓挫する形となる。渡邉氏は当時を振り返り、システムの問題点を認識しつつも延命せざるを得なかった原因として、システム開発や運用を行う事業者として組織的に対応する体制になかった点を挙げた。

こうした中、最初のトラブルが発生する。2008年9月のことであった。

10日間の営業停止状態を通じて得たさまざまな教訓

2008年9月30日、SQLインジェクションによる不正アクセス事件が起こり、GDOは10日間の営業停止状態に陥る。復旧までに10日間も時間を要した原因について、渡邉氏は以下の2点を挙げた。

1つは、「ログの解析にかなりの時間を要した」点である。月間1.5億PVとアクセス数の多いサイトだったため、ログの量も膨大で、相当な時間と労力を要することになった。

2つ目は、「システムを止めることは実は容易ではなかった」という点だ。システムを止めようにも、ユーザーへの説明サイトを立ち上げる必要もあり、全部のシステムを止めることは容易ではなかったという。また、問題のあるシステムの一部を切り離してサービスを再開したかったものの、問題ある部分が他の部分にどういう影響を及ぼすのかが判断できなかったことが要因として挙げられる。つまり、「何をもってサービスを再開する判断を下すのか」という判断基準の問題である。

その他にも、経営陣に対する障害報告や社内の情報統制、株主への説明責任をどう果たすかという点についても、このトラブルを通じて示唆が多かったと語る渡邉氏は、緊急事態における準備事項として次の3点を示した。

1. 緊急連絡フロー（エスカレーションフロー）の準備
   • 障害レベルの定義とそれぞれのエスカレーションフローの整備
     （社外、社内メンバー含む、連絡網の準備）
   • 障害発生時のサイト告知テンプレート準備

   社外のアライアンス先など、連絡をとらなくてはいけないが、どこのだれに連絡していいのかがわからないということがあった。また、どういうタイミングで、どういう文言で告知したらいいのか、これらについても時間を要した経験から、「障害発生時の告知テンプレート」も準備するようにした。

2. 緊急対策本部の設置
   • どのタイミングで招集するかの定義
   • メンバーアサイン（担当と責任範囲の定義）
   • 解散条件の設定

   メンバーが集まりすぎると意志決定ができなくなるため、だれをアサインするのかが大切だ。「解散条件の設定」については、いつ、どういう条件が満たされるまでこの体勢を続けるのかという定義をあらかじめ決定しておくものだ。

3. システムの状況を説明できる準備

   自分たちのシステムがどういう仕組みになっているのか。状況を可視化し、客観的に説明できる資料を準備しておく必要性を痛感したことによる。この要素をさらに詳しく説明すると、次のようなものが必要ということだ。

   設計書	トラブル時だけではなく、開発や改修を行ううえで重要。コストも手間もかかるが、緊急時には頼みの綱になる。
   何が起きているか追跡できる仕組みの導入	ログ管理、アクセス解析、統合運用管理などIT基盤に関わる部分。投資判断が難しく、コストもかかる部分であるが、状況の可視化においても重要になる。
   経営層との定期的な情報共有	セキュリティトレンド、キャパシティー計画、インシデント状況、リソース稼働状況などを定期的に共有しておく。

   この中でもログ管理、アクセス解析、統合運用管理などについては、IT基盤への投資に関わることでなかなか経営判断がむずかしい。しかし、こういう仕組みがいざという時には重要になるので、状況を可視化するというためにぜひ導入したいツールである。

さらに渡邉氏は、IT基盤への投資の必要性を正しく経営陣に理解してもらうための考えについても以下のように示した。

渡邉氏が常に心がけていることは、「IT用語を駆使せず経営にわかりやすい言葉を使う」ことだという。特にシステム部門で使われる専門用語は経営者が判断できないケースがあるため、わかりやすい言葉を用いるほか、図解やプレゼンテーションを取り入れることもポイントになるという。

「G10プロジェクト」と2度目の障害を経験して

そして2010年、同社は10周年という節目の年に中期経営計画を策定する。いよいよGDOのIT基盤を整備し、システムを刷新することとなり、「G10プロジェクト」を立ち上げる。10年後に世界一のゴルフサービス企業となるべく、既存事業強化へのイノベーションや新規展開、世界市場への進出などがビジョンとして掲げられた。

そして渡邉氏はこのプロジェクトマネジメントリーダーに就任し、これまでの経験も踏まえて組織的なプロジェクト管理を推進した。特に、要件定義を具体的にし、「だれがいつまでに何をするのか」「主管（責任者、責任プロジェクト）はどこか」「課題に対する期限管理」「リスクを徹底的に洗い出した対策」などを徹底した。

こうして2010年1月1日にスタートしたプロジェクトは、200人以上が携わり、複数のプロジェクトが同時進行する大規模なものとなったが、プロジェクト管理を徹底したことで開発は順調に進行した。そして、2011年7月1日金曜日正午、いよいよシステムはカットオーバーを迎える。しかし、もう1つのトラブルが近づいていた。

カットオーバーのわずか10分後、ECシステムにトラブルが発生し、24時間経過しても根本解決には至らない大規模障害となった。

金曜日の正午にカットオーバーを設定したのにはいくつかの理由があったそうだが、金曜日に大きなトラブルが発生したため、追加の人員を要請しようとしても土日にリソースが用意できないという悪条件も重なった。その後、開発ベンダーとログ解析ベンダーのスペシャリストの協力を得て、日曜日には復旧された。

ところで、カットオーバー時にあらかじめ有事に備えベンダーをアサインしていれば、長時間の解消は回避できたのだろうか。

障害が解消しない状況、あなたならどうしますか？

このように会場に問いかける渡邊氏は、このときの障害発生の原因と復旧に至る経験から、次の教訓を伝えた。

1. かなりの回避策（コンテンジェンシープラン）を用意していたが、足りなかった
   パフォーマンスの問題についても回避策を用意していたが、セカンドオピニオンが足りなかった
2. 開発、テスト段階で、もっと実運用を想定した監視系ツール整備を行うべきだった
3. 最悪のシナリオを想定したリソースのアサインを行うべきだった
4. 開発会社に頼りっきりにならない。事業の基幹部分は自社運用を目指す

渡邉氏は、特に最悪のシナリオの想定と、開発会社に頼らない自社運用の重要性について強調した。また、セッションを総括したポイントを次のように示した。

1. トラブルにどう向き合うか
   • 障害レベルの定義と連絡フローの準備
   • 障害対応マニュアルの整備
   • 障害箇所の特定をスムーズに行う為の仕組みの導入
2. プロジェクト運営に関して
   • 曖昧な要件定義の排除
   • 課題管理、期限管理を実行（何を誰がいつまでに！）
   • リリース時は可能な限り最悪のシナリオを準備する
3. IT投資、経営層とのコミュニケーションについて
   • 定時レポートの実行
   • 中期目線でのIT投資計画の共有（目先のサービス拡張だけに集中しない）
   • セキュリティなどのトレンドの共有（危機感の共有）

G10プロジェクトの課題が収束し、現在は今後のシステム運用の安定化に向けたフェイズに移っているという。最後に渡邉氏は、「計画が品質を担保する」という言葉を紹介して、システムの安定稼働の重要性を貴重な体験談を交えて解説した基調講演を締めくくった。