2016年9月13日火曜日

[ICTSC6] ICT トラブルシューティングコンテストに参加して優秀賞をもらってきました

WordpressでVPSで運用していたブログをぶっ壊してが何故か壊れて、ずっと放置していましたが書く内容もできたし記事を一つ。

ちょうど同じチームの先輩が良い記事を書いて下さったのでパクって流用して書いていきます

第6回ICTSCトラブルシューティングコンテストで優秀賞をもらった&writeupのようなもの - 烏龍茶より麦茶派です

チームには「自チーム用のWriteUPを書きます」って言ってたけど結局ブログが使いたくてこっちに。

---

8月27,28日に大阪のNTT西日本 研修センター(PRISM)で開催された 第6回 ICT トラブルシューティングコンテストにチームNo.7 WCDIとして参加して優秀賞(2位)を頂いてきました。

今回で2回目の参加です。先輩は4回目ということもあって、事前に問題予想を聞いたりして勉強してきました。(問題予想当たりすぎててすごい)

第5回の記事は不慮の事故で失われたので、心を入れ替えて書いていきます。


WCDIチーム

新たに1年生に参加してもらい、3年2人、2年2人、1年1人の構成となりました。
私は、前回はサーバのみを担当していましたが、今回はいろいろあってネットワークにも手を出して、フルスタック要員として働きました。
全体の役割分担としては、サーバ2人、ネットワーク2人、フルスタック1人という構成で、先輩曰く「サーバとネットワークでどちらかに問題が偏った場合に、片方に負荷がかかりすぎないような構成」だそうです。

たしかに分散していたおかげで手を付けられなかった問題が少なく済みました。高得点が頂けたのもこのチーム構成がいい影響を及ぼしていました。


大会内容の突っ込んだところ


問題は大まかに分けて「1日目午前、1日目午後、2日目午前、2日目午後」の4つの区切りに分けて出題されます。
例年ではこの区切りをまたいで問題が出題されることはなく、制限時間はからなず各区切り内で終わるように設定されていました。
また、問題は大体3問ずつ、5人で参加した場合は分担する必要があるような問題構成でした。
しかし、今回大会の2日目は、この区切りを午前午後で跨いだ問題が1問、午後には一気に5問出題というカオスな状況が生まれました。
自分は午前午後を跨いだ問題を午前から午後終了1時間前まで担当していたため(しかも解答できなかった)、自分としてはこの時間の使い方がまずかったなと思いました。
しかし、チームとしては1人1問で割り振ることができ、大きな混乱もなく進行できていました。


大会前

自分のこと

フルスタックとはいえ、基本的にはサーバの低レイヤーの問題解決についての勉強を行い、大会前2週間程度を使ってネットワークに関する必要知識を詰め込むような感じで勉強しました。
サーバの高レイヤーについては、同じくサーバを担当する先輩と後輩が勉強していたので、自分は復習程度にとどめて、できるだけアプリケーションがかかわらないような部分を勉強していました。
この予想は大きく外れて、低レイヤーについては出てもDHCPくらいしか出なかったのが悲しいところです。
しかしこの勉強のおかげか、それとも神のおかげか、「アプリケーション問題でLoopbackを流れるパケットを読む」ような発想ができたのは良かったです。
ネットワークについては、そもそも授業で低難度の部分はやっており、さらにサーバで低レイヤーを触る際に技術概要や必要知識、単語くらいは頭に入っていたのでネットワーク機材の操作方法を学習するのみで済んだのがよかったです。

チームのこと

今回も学校の協力を得て、7月から夏休みまで教室を開けてもらい、そこで勉強会を開き(
半もくもく)勉強してきました。
前回の反省を元に、情報伝達をなるべくするように心がけるようにしました。
それを活かし、同じサーバ側でも学習内容をあまり重複させないように学習内容を割り振っていました。
さらに当日のタスク振りをスムーズにするために、勉強会ごとに"どの技術をどのくらい学習したか"をSlackを利用して共有し、”だれが””どこを””どのくらい”やったかをわかりやすくしてきました。

大会当日

自分のこと

自分は原因のようなものを見つけたらまず報告することを心がけて解いていました。
そのおかげもあって、何かを見つけたときに無闇に手を出すのではなく、まずは報告するために頭で内容を一旦整理するというワンステップを入れることができました。
おかげで今までより落ち着いて回答できたと思います。

チームのこと

チームWCDIは「一番最初にトラブルの原因を見つけた人がそのまま解答提出まで一人で行う」というスタイルで解答しました。
そのため、問題の原因が特定できた地点でそのタスクに割り振る人を最小限にでき、まだ解けてない問題に人を回すことができました。
また、これによって情報伝達不足から起こる「やらかした」も減らせました。

余談

各日毎に夜に集まってミーティングをして、寝る暇も惜しんで学習はしてました。
ただ、1日目・2日目間の映画鑑賞(ナウシカ)は結構マズかったです。2日目は集中が切れるのが早かった気がします。

大会終了

自分のこと

前回大会よりも貢献はできたのでは、と自分では思っています。
しかし、頭に残るのはやっぱり2日目の午前午後問題・・・
後から運営から聞いた模範解答で必要になる情報収集は自分でやっており、それでいて解けなかったのは自分の判断力と想像力が不足していたのかと思います。
Writeupを後述しますが、やっぱり3時間以上かけた問題が解けなかったのはとても悔しいです。

チームのこと

結果は優秀賞(2位)でした。
430点中、1位は219点、私達は175点でした。
という結果が物語っているとおり、結構頑張ってました。
後から配布された資料によると、1日目については1問を除いて点数をもらえていました。満点も4問あり、結構すごいと思いました。
2日目午前も1問落としただけで残りは点数をもらえていて、ここまでは順調でした。
が、やっぱり2日目午後のラッシュがすごく辛く、1問も点数がもらえてませんでした。くやしい。
(むしろ2日目午後をまるっと落として2位って・・・)


感想

やっぱりトラコン楽しいです。
というかトラブルシュートしている瞬間がとても楽しいです。
実際の障害対応の現場だとこうはいかないんだろうとは思っていますが、こういう大会に参加すると見聞も広がるし、トラブルに対する耐性もついてきます。
こういうの、本当に好きです。

気持ち的に、サーバとネットワーク双方を組み合わせたような問題が比較的多くなっている感じがしました。
サーバ問題かと思ったらネットワーク問題だったり、DHCPは動いているのにサーバが受信できない問題(解けてない)だったりサーバで経路情報をいじる問題(誤答)だったり・・・
あとは、設定を間違えた問題よりも「この知識は必要だよね」系な問題(inode,AUX)もあり、「へぇ〜」となる問題が多かったです。
こういうのもやっぱりトラコンだなぁと思っています。
あとは先輩が「運営募集してるなら運営に」とも言っているので、それを阻止(笑)したり後輩育成したりもしないと。。。

(次回も当選するといいなぁ)


Q1 の コンソール問題については、自分の癖(家で稼働するCisco機器は全部コンソール速度が115200になってる)で解答不可能にしてしまって、本当に申し訳ないです。


最後に

トラコン運営様、実行委員会様、スポンサー様
今回は本当にありがとうございました。おかげで楽しく参加でき、とても楽しかったです。
また次回参加するつもりです。次回は最優秀賞をいただけるよう更に精進いたしますので、次回もよろしくお願いいたします。


WriteUP

自分が唾つけた問題かつ先輩が書いていない問題だけ、獲得点数と一緒に自分たちの解答を書き記します。
公式が問題を公開するらしいので大雑把に。

Q3,6,7,9 : http://blog.hnron.net/entry/2016/09/06/220845

Q2. [1日目 午前] 繋がらなくなりました (10/10点)

  • あなたはとあるビルのネットワーク管理を任されている 
  •  ある日そのビルの点検で停電が発生した。点検後、ある部署でインターネットに繋がらなくなったという連絡を受けた。
    •  部署アドレス ( 10.100+x.5.0/24 ) 
  •  部署アドレスで正しく繋がるようにしてほしい 
  •  その後、設定を変更した箇所とその理由を詳しく説明してほしい。
ルータを確認したところ、ルーティングポートにサブインターフェイスは作成されていて、説明として" connect to 10.107.5.0/24 "と書かれたポートが存在していた。
インターフェイスを作成し、保存した後にネットワークの設定を行い、保存を怠ったせいで停電後の再起動で疎通が不可能になったと判断し、以下の設定を投入し保存を行った。
interface FastEthernet 8.2
encapsulation dot1Q 795
no shutdown
ip address 10.107.5.1 255.255.255.0
以上でFa0/8 - 11 で疎通可能になったため、11:04に解答を投稿した

が、11:13に「Fa0/21 - 24に接続し繋がるようにしてください」との補足が流れ、それを確認せずに1日目午前が終わってしまい、後で気づいて点数はもらえないと思っていたが満点もらえていた。ラッキー。


Q4. [2日目 午前]  アップローダが動きません! (20/30点)

  • とある喫茶店では、「らびっとほーす」というサービスをWebにて提供している。
  • このサービスはログイン扶養で自由にファイルをアップロード/ダウンロードできるサービスです。
  • このサービスは今まで順調に稼働していたが、ある日を境に突然アップロードができなくなってしまった
  • まだ調査が進んでおらず、原因がわかっていないので。原因究明を行ってほしい。また、可能であれば対処を行ってほしい。
  • ただ、このサービスはある程度のユーザーがおり、アップロードができない状態でもダウンロードを行うユーザーはいるため、できる限り復旧時にダウンタイムを設定しないこと。
  • また、喫茶店の一人娘の自称姉がよくわからないままに立てたサービスであるため、サーバーのログイン情報以外のことはわかっていません。
  • このサービスは人気であるため、ダウンタイムが発生すると減点される可能があります。
`df`を叩くと空き容量は潤沢、でもtouchでファイル作成ができない、パーミッションや拡張属性は正常、となると考えられるのはinode一択。
`df -i`で調べた結果ビンゴ。
しかしダウンタイムなしで復帰がとてもむずかしく(というか知らなかった)、実験したがどうしても7秒以上はダウンタイムが発生する状況だった。
どうしようもないと判断したため、tcpdumpでSLAチェックの合間を縫ってシェルスクリプトでバックアップからサーバ停止、レストアしてサーバ復旧して後始末までを自動化して実行した。
しかしやっぱりtcpdump結果を見ると1回SLAチェックでアウトになっていそうだった。

ディスクの中身を確認したところ平均でも10バイト程度しかないファイルが大量にある状況だったので、できる限りinodeを大量に配置するように再フォーマットした。


Q4. [2日目 午前午後]  聞きたくても、聞こえない (0/50点)

  • あなたの会社では、先日待望のIP電話が導入されました。
  • IP Phone は業務に関係のないことにも使えるようです
  • 社長(運営)との雑談のため
  • そんなIP Phoneですが、どうやら先日社内インフラ部がセキュリティ上の理由でスイッチの設定を変更した結果、こちら(参加者)の声が社長に聞こえなくなてしまったようです。
  • インフラ部は非常に対応が悪く、問題アアルト行っても一向に聞き入れず、調査を行ってくれません。しかし、何か正当な理由があればスイッチの設定変更には応じてくれるみたいです。
  • もしコアスイッチ等に問題があるのであれば、質問に 設定変更依頼 と題して変更したい内容とポートなどの情報を伝えてください。
  • 社員とワイワイ雑談できないためか、最近は社長もごきげんななめです。早めに解決してください。  
  • 出題される環境の資料
    • 運営への電話は自由
    • FastEthernet 0/1がミラーポートになっている

この問題は大会終了後に運営にお伺いした結果、「
スイッチで16384〜32768/udpポートがふさがっていた
TFTPでIP Phoneに送られてくる使用するポート番号100つ分だけ開放申請すれば満点だった
」との解答をいただきました。ありがとうございました。


0 件のコメント:

コメントを投稿