第7回トラブルシューティングコンテストの裏側
3月4~5日にかけて、第７回トラブルシューティングコンテストが調布市にあるNTT中央研修センターにて開催されました。
僕は h-otter と共に問題リーダーとして運営に携わりました。ここでは技術面、マネジメント面で運営の裏側をいろいろ書こうと思います。
第7回トラブルシューティングコンテスト
トラブルシューティングコンテストとは
全国の専門学校生、高専生、大学生、大学院生を対象とした サーバー・ネットワークのトラブルシューティングや運用技術をチーム単位で競うコンテストです。
第7回は、NTT東日本杯ということで、NTT東日本様にプラチナスポンサーをしていただきました。
スケジュール
10月にキックオフミーティング合宿が行われ、3月の本番まで約半年準備期間がありました。
ざっくりと問題リーダーとしてのタスクをスケジュール順に書くと、
- 問題の案を集める
- 大会に出題するのに適切な問題案かどうかを検討する
- 大会の出題方式の検討/決定
- 自分の問題案の再現性を検証する＆他の問題検証のお手伝いをする
- 全ての問題からストーリー、問題文の作成
- 問題の追加・編集と共にシナリオの再編成
- 大会ルールの決定
- スコアのバランス決め
- 協賛企業向けの資料作成
という感じでした。正直記憶が混乱しているので順不同です。
技術的な仕事以外の方が多く、とても苦労しました。
さらに、これらはあくまで問題リーダーの仕事であり、それぞれ個人タスク(OpenStackの修理やzabbix監視など)やリーダー不在時に全体のタスク管理等も行っていました。
hotstageを振り返って
運営は、2週間会場で缶詰になって作業する期間があります。その期間をhotstageと呼んでいます。
ざ〜〜っと写真で振り返ってみます。
hotstage フェーズ1(2/18~2/24)
最初の１週間は六本木にあるciscoさんにて機材の運搬、検品、問題構築等の作業を行いました。
また、各個人のタスクをすべて付箋で管理しました。
hotstage フェーズ2(2/24~3/6)
ciscoさんでのhotstage期間終了から大会終了まで、NTT中央研修センターにて残ってる仕事を全て行いました。
↓会場の様子
打ち上げ
写真を見てわかる通り、皆騒ぐ体力がある状態でした。これは本当に奇跡的なことです。
技術面から見る運営の裏側
運営中、様々なトラブルに見舞われ、知見を得ました。
ざっと紹介しようと思います。
ipv6
ipv6関連の問題を検証する際に、リンクローカルアドレスでルーティングは本当にできないかを確かめる必要がありました。
RFC 4291 - IP Version 6 Addressing Architecture
RFCは偉大ですね。
Routers must not forward any packets with Link-Local source or destination addresses to other links.
BGP
iBGPとeBGPを仕様した際の仕様の違いによるトラブルは初めて知りました。
http://www.infraexpert.com/study/rp5bgp7.htm
今回の問題でも出題されましたね。(問題解説はまた別にICTSCのブログで公開します)
これを検証する時バグなんじゃないかと騒いでvyatta-quaggaのソースコードひたすら読んで、結局仕様だったというオチで辛かったです…
OpenStack
サーバー問題を出題するにあたってOpenStackを用いたのですが、検証環境から本番環境に移行する途中Horizonとかglance、neutron等いろいろ壊れてリアルトラブルシューティングしてました。
glanceが壊れたのは参照先ファイルのパスがおかしくなっていて、明示的にパスを指定したら直り、neutronはdbをsyncしなおしたら直りました。
Horizonなんてものはありませんでした。次のOpenStackのリリースで亡くなることでしょう。(Horizonが壊れているのを直そうとしたら、どうやらKeystoneの認証がバグっていたため直そうとして、他のコンポーネントを壊してしまい、復旧で1日が潰れたためすごくつらい)
CloudStack
CloudStack問題を作成しました。
自分がトラブルだらけですごく苦しんだプロダクトなので、トラブルが起きている状態を作るのはとても簡単でした。
CloudStack on OpenStack
CloudStack問題を参加者に提供するため、OpenStackの上にCloudStackをのっけました。すごく辛かったです。
他にもいろいろ知見を得ましたが長くなってしまうのでここら辺で技術編は終えます。また他の記事やサイトで書くかもしれません。
マネジメント面から見る運営の裏側
第5回から運営をしていて今回で3回目ですが、個人的に今回はかなり成功した回ではないかと感じています。
当日に参加者の機材にコンフィグが流れていないものがあったりまだまだ至らないところはありましたが、炎上もあまりしておらず、hotstage期間中毎日睡眠をとることができました。第5回、第6回を振り返ってみるとこれは奇跡的なことです。
今回試みたマネジメント面の話をざっくりとします。
裁量の調整
今回、なるべく参加者に面白い大会だと感じてもらうため、問題に統一感を生み出したい気持ちがありました。
そのため、出題方法決め、ストーリー、問題文作成を全て問題リーダー間で話し合い案を出し、みんなに提示して決定してもらいました。
そうすることによって大会自体に世界観を植え付けることができ、問題作成者の負担も減らすことができました。
不必要な締め切りの撤廃
「例年こうだからこの辺で締め切ろう」
このようなノリでたくさん締め切りが毎回存在していたのですが、今回問題作成の締め切りを思い切ってなくしました。
理由は単純で、締め切りを作る理由がないからでした。
僕らは学生のため、どうしても他のことを主体に生活をせざるをえません。(学校やアルバイト、就活など)
その中で、本来意味のない締め切りを守るというのは検証の質を落としたり、ストレスを生み出してしまいます。
また、直前でいい案を思いついたのだが意味のない締め切りが過ぎてしまっていたため出題できないというのもおかしな話です。
そのため、今回は問題の締め切りを設けませんでした。
その分、僕たち問題リーダーが検証の手伝いなどをし、遅めに提案した問題案も出題できるレベルまで検証し終えられるように調整しました。
リーダーのタスク調整
上記を読んでもらえると伝わると思いますが、問題リーダーとしてのタスクが大変多かったです。
本来リーダーは全体を見渡せる余裕を常に持っているべき存在で、一つのタスクに集中するのはあまり好ましくありません。
そのため、今回は問題リーダー含めリーダー職の人は問題作成などの個人タスクを控えめに しました しようと努力しました。
OpenStackの使用
前回は、あまり小回りの利かないCloudStackを採用していたのですが、今回は知見のある方が多いOpenStackを使用することによりトラブルが最小限にとどまりました。
まとめ
とても身になる大会でした。
協賛企業の方、運営の方、実行委員の方本当に有難うございました。
ここで得た知識とハリボーを全部食べられた恨みを忘れずにこれからも精進していこうとおもいます。
