SONiCをbuildしました

ごぶさたしております。ライトノベル好きのツチノコです。グレブナー基底に興味を持ち始めました

注意: ONIEインストールしたところ文鎮化しましたので手順見直しています

さて、MicrosoftがOCP SummitでSONiCというEthernet SwitchのOSを公開しました。
・SONiCを紹介しているMicrosoftのBlog: Microsoft showcases “Software for Open Networking in the Cloud (SONiC)”
・SONiCのgithub: Software for Open Networking in the Cloud SONiC

このSONiCのimageをbuildするのに少し手間取りましたので、手順を共有したいと思います。
・github上のbuild手順書: Build Switch Images – buildimage

以下の手順は完全版ではなく、今後修正がある可能性はあります(試行錯誤したこと、Dell S6000にインストールしてみるのはこれからというのが主な理由です)。

手順概略

1. Kernel buildの準備
2. Kernel build
3. Image buildの準備
4. Image build

1. Kernel buildの準備

Debian Jessie(8.3) x64なマシンを準備します。最初、Stretch(testing)でやっててはまりました。

$ uname -a
Linux vm9705 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux
$ cat /etc/debian_version 
8.3

https://github.com/Azure/sonic-linux-kernel/blob/master/build.shで利用されているpackageを入れます。

# apt-get install git-core stgit fakeroot dpkg-dev gcc-4.8 g++-4.8

kernel buildに必要なpackageも入れます。

# apt-get build-dep linux

2. Kernel build

cloneしてbuildするだけ。時間がかかるので(手元の環境だと5時間)、夜中とかにやるのがいいと思います。

$ git clone https://github.com/Azure/sonic-linux-kernel/
$ cd sonic-linux-kernel/
$ ./build.sh
$ cd ..

3. Image buildの準備

https://github.com/Azure/sonic-buildimage/blob/master/build_debian.shで利用されているpackageを入れます。

# apt-get install debootstrap sudo curl squashfs-tools zip 

sudoerになります

# visudo

4. Image build

git cloneします。

$ git clone https://github.com/Azure/sonic-buildimage

ONIE installer imageが依存するファイルをbuildします。initramfsなどのようです。

$ mkdir sonic-buildimage/deps/
$ cp sonic-linux-kernel/*.deb sonic-buildimage/deps/
$ cd sonic-buildimage
$ ./get_deps.sh

Imageをbuildします。build中にファイルのダウンロードなどを行うのでこちらも時間がかかります(30分くらい)。

$ ./build_debian.sh "sonic" "$(perl -e 'print crypt("sonic", "salt"),"\n"')" && ./build_image.sh

うまくいけばImageが作られているはずです。

$ ls -l acs-generic.bin 
-rw-r--r-- 1 watanabe-k watanabe-k 238388488 Mar 30 15:28 acs-generic.bin

そんなわけでこの後、ONIEでインストールしてみます。

p.s. 魔王サスペンス劇場 土けむりダンジョン、美人勇者殺しがすごく気になっています。

STOMP と rabbitmq-stomp の話

はじめに

 先日 CodeZine に寄稿した記事 で簡単に触れた STOMP について紹介します。
 後ほど解説しますが、STOMP は非常にシンプルなプロトコルで読もうと思えば数時間で読めてしまいます。
 今回は STOMP プロトコルがどんなものかという事と、STOMP の実装として RabbitMQ の STOMP アダプタ (以下、’rabbitmq-stomp’) に注目し、どういう事ができて AMQP と比べてどうなのかということを簡単に示したいと思います。

STOMP とは?

 STOMP は非常にシンプルで拡張可能なメッセージパッシングプロトコルになります。STOMP は AMQP や MQTT などのバイナリプロトコルと異なり、テキストベースのプロトコルになります。
 どういうことかというと、STOMP ではフレームという単位でメッセージ (content) のやり取りを行います。キューにメッセージを送る際には SEND フレームを STOMP サーバに対して送り、キューに格納されているメッセージを取得する際にはサーバに対して SUBSCRIBE フレームを送信し、メッセージ本体が格納された MESSAGE フレームの送信をサーバから待ち受けるというように、フレームを単位として処理が行われます。そして STOMP は一般にテキストベースのプロトコルと呼ばれる、フレームのヘッダー及びメッセージ本体をテキストデータとしてネットワークに流します。これに対して AMQP や MQTT では、ネットワークに流すデータを圧縮するために、こうしたデータ (AMQP の場合フレーム (Frame)、MQTT ではコマンドメッセージとそれぞれ呼ばれている) をバイナリにエンコードした上でネットワークに流しています。
 こうしたテキストベースのプロトコルでは、実装が非常に簡単に行える利点があります。例えば、クライアント側の処理であれば、telnet からメッセージを送信するなんて事も出来てしまいます。
 以下では、telnet から STOMP サーバに対してメッセージ ‘hogefuga’ を送信し、その後そのメッセージを取り出すという処理を行っています。

ubuntu@localhost:~$ telnet localhost 61613
Trying ::1...
Connected to localhost.
Escape character is '^]'.
CONNECT
accept-version:1.2
login:guest
passcode:guest

^@
CONNECTED
session:session-xEhXUf-LPI_ZxLiRqjUPFA
heart-beat:0,0
server:RabbitMQ/3.6.1
version:1.2


SEND
destination:/queue/test1
content-type:text/plain
receipt:123

hogefuga
^@
RECEIPT
receipt-id:123


SUBSCRIBE
id:0
destination:/queue/test1
ack:client

^@
MESSAGE
subscription:0
destination:/queue/test1
message-id:T_0@@session-xEhXUf-LPI_ZxLiRqjUPFA@@1
redelivered:false
ack:T_0@@session-xEhXUf-LPI_ZxLiRqjUPFA@@1
receipt:123
content-type:text/plain
content-length:10

hogefuga

DISCONNECT
receipt:789

^@
RECEIPT
receipt-id:789


Connection closed by foreign host.
ubuntu@localhost:~$ 

 (太文字の部分が STOMP サーバから送られた内容になります)

 更にクライアントがサーバからメッセージを取得した際に送る確認応答 (ACK) を TCP などのように後から累積して返す方法 (累積応答確認) が選択でき、短時間に大量のメッセージを受信することができます。
 しかし AMQP 0.9.1 にあるような fanout や topic exchange による複数のキューに対するメッセージのブロードキャストや、柔軟なメッセージルーティングを実現させることが出来ません(ただ rabbitmq-stomp では拡張機能として topic 機能によるメッセージブロードキャストをサポートしています)。またトランザクション処理について、STOMP ではサポートされていますが AMQP のようにシステムが自動でトランザクション処理をしてくれるのに対して、ユーザがトランザクション (複数のフレームから成る処理のまとまり) を規定してやらなければなりません。
 このように STOMP ではリッチな機能やトランザクション処理の抽象化が行われている AMQP と比べて非常に簡素なプロトコルで、特定のプロセスとメッセージパッシングを行う上でプリミティブな機能を提供しています。

STOMP 実装について

 STOMP の実装は いろいろ ありますが、人気が無いためか最新の STOMP v1.2 に対応し且つキチンとメンテされているプロジェクトは ActiveMQ Artemisrabbitmq-stomp くらいです。今回は rabbitmq-stomp に注目して特徴を解説します。
 rabbitmq-stomp のセットアップの方法については 公式マニュアル をご参照ください。

使い方

 以下は Ruby の STOMP パッケージ stomp を用いて、キュー ‘hoge’ に対してメッセージを送信するサンプルプログラムになります。

送信処理(sender.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.publish "/queue/fuga", "hello world!"
受信処理(receiver.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.subscribe '/queue/fuga'
loop { puts conn.receive.body }

 簡単ですね。stomp パッケージでは Stomp::Client クラスの publish, subscribe の第一引数で指定しる文字列がそれぞれ SEND フレームと SUBSCRIBE フレームの destination ヘッダで指定されます。先頭の ‘/queue/’ は STOMP のキューを表す予約語で、その後にキュー名 ‘hoge’ を指定しています。
 rabbitmq-stomp ではこうした STOMP v1.2 で規定されている機能に加えて、STOMP クライアントから AMQP のキューに対して送る機能やメッセージを broadcast する機能拡張を行っています。以下では、rabbitmq-stomp の拡張機能について簡単なサンプルと共に紹介してゆきます。

/topic/xxx

 送信キュー名 (SEND フレームの destination ヘッダで指定されてる値) のプレフィックスが ‘/topic’ の場合、rabbitmq-stomp ブローカーは AMQP の topic exchange(*1) の要領でメッセージを STOMP キューに格納します。
 STOMP v1.2 の仕様では destination ヘッダのセマンティクスは規定されていませんが、rabbitmq-stomp ではこうした独自のセマンティクスを持たせる事で、様々なオリジナル機能を提供しています。逆に rabbitmq-stomp で規定されていない値を SEND や SUBSCRIBE フレームの destination ヘッダで指定した場合、ERROR が帰ってきます。

送信処理(sender.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.publish("/topic/fuga", "hello world!")
受信処理(receiver.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.subscribe '/topic/fuga'
loop { puts conn.receive.body }

(*1) AMQP にどのような exchange があって、それぞれどのような働きをするかについては こちらの記事 が詳しいです。

/exchange/(exchange-name)/xxx

 destination ヘッダーの冒頭に予約語 ‘/exchange’ が指定された場合、それに続く (exchange-name) で指定される RabbitMQ の exchange によってメッセージの転送を実施することができます。RabbitMQ によって提供されている exchange は ‘rabbitmqctl list_exchanges’ コマンドによって取得できます。以下ではメッセージのブロードキャストを行う fanout exchange を使って、メッセージを送受信する処理を記述しています。

送信処理(sender.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.publish("/exchange/amq.fanout/foo", "hello world!")
受信処理(receiver.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.subscribe '/exchange/amq.fanout/foo'
loop { puts conn.receive.body }

/amq/xxx

 ’/amq’ が destination で指定された場合、AMQP 側(RabbitMQ 本体)の処理で作成されたキューに対してメッセージを送ることができます。これによって STOMP クライアントから AMQP のキューに対してメッセージが送れるわけですが、用途は謎です。RabbitMQ 本体で作成した AMQP の名前付きキュー ‘amq-test’ に対して STOMP クライアントからメッセージを送受信する処理を以下に示します。

送信処理(sender.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.publish("/amq/queue/amq-test", "hello world!")
受信処理(receiver.rb)
require 'bunny'

c = Bunny.new(:host => 'localhost', :user => 'guest', :password => 'guest')
c.start

ch = c.create_channel
q = ch.queue('amq-test')

begin
  q.subscribe(:block => true) do |_, _, data|
    puts data
  end
rescue Exception => _
  ch.close
  c.close
end

/temp-queue/xxx

 最後に ‘/temp-queue’ が指定された場合について紹介します。これまでの機能は全て ‘destination’ ヘッダに対して指定する予約語でしたが、これは SEND フレームの ‘reply-to’ ヘッダに記述します。SEND フレームの ‘reply-to’ に ‘/temp-queue’ を指定すると、rabbitmq-stomp はランダムな名前が設定された一時キューを作成し、メッセージを受信する側が受け取る MESSAGE フレームの reply-to ヘッダに一時キューの名前を格納します。MESSAGE フレームを受け取った側は ‘reply-to’ ヘッダに指定されたキューに対してメッセージを送信すると、最初に SEND フレームを送った側において ‘reply-to’ ヘッダで指定したラベルから、メッセージを受け取ることができます。図にすると以下のようになります。

 この仕組みは、特定の相手からのメッセージの返信があるケースで便利です。特に RPC などにおいて効果を発揮します。また client から送った最初の SEND フレームの ‘reply-to’ ヘッダで指定する受信用のキュー名はセッション毎に独立しており、別のプロセスが同名の ‘/temp-queue’ を指定したとしても、別のプロセス宛の返信メッセージが混在することはありません。最後にサンプルプログラムを示します。

送信処理(sender.rb)
require 'stomp'

conn = Stomp::Connection.open
conn.publish("/queue/test-fuga", "hello world!", {
  'reply-to' => '/temp-queue/test'
})
puts conn.receive.body
受信処理(receiver.rb)
conn = Stomp::Connection.open
conn.subscribe '/queue/test-fuga'
loop do
  msg = conn.receive

  puts "received: #{msg.body}"

  conn.publish(msg.headers['reply-to'], '(reply) ' + msg.body)
end

AMQP との比較

 ここまでの話で STOMP がどんなもので、STOMP の実装の一つ rabbitmq-stomp でどんなことが出来るかについて紹介しました。最後に RabbitMQ の AMQP 実装と STOMP 実装での簡単なパフォーマンスベンチマークを取った結果を紹介したいと思います。ベンチマークで用いたスクリプトは こちら になります。またベンチマークの実行環境は以下のとおりです。

* CPU : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
* RAM : 32GB
* OS              : Ubuntu 14.04.4 LTS
* Ruby            : 2.2.2
* Erlang          : R16B03
* rabbitmq-server : 3.6.1-1
* rabbitmq-stomp  : 3.6.1

 ベンチマークでは、複数のサイズのメッセージを大量に送受信し、処理が完了するまでの時間でスループットの傾向を調べています。以下が実行結果になります。

 横軸が送信した各メッセージサイズを表し、縦軸が処理を終えるまでの時間になります。また棒グラフと折れ線グラフはそれぞれ、送信処理と受信処理を表しています。
 メッセージストアは STOMP の方が高速ですが、メッセージの取得処理は AMQP の方が 2 ~ 3 割ほど早いです。恐らく、rabbitmq-stomp において何がしかの実装上のオーバーヘッドがかかっていることが予想されます。

最後に

 rabbitmq-stomp の Contributor に名前を連ねました☆(ゝω・)vキャピ

user@localhost:~/rabbitmq-stomp$ git log | grep -i ohyama
Author: Hiroyasu OHYAMA 
user@localhost:~/rabbitmq-stomp$ 

RabbitMQ 記事を CodeZine に書きました

 こんにちは、インフラ統括本部の大山裕泰です。

 CodeZine に RabbitMQ ネタの記事 を寄稿致しました。
こちらは、本稿執筆時点での最新メジャーバージョンで組み込まれた Lazy Queues についての記事になります。

 要点をまとめると

* Apache Kafka のようなストレージストアのキューイングが選択できるようになった。

* 消費メモリが劇的に減りバッチシステムなどから定期的に取り出す処理など、
 キューに大容量のデータが滞在するようなケースで利用できるようになった。
 また、キューイングのスループットが安定するようになった。

* Lazy Queues の使い方についてコードを用いて紹介。

 また Lazy Queues は 時期メジャーバージョン (3.7.0) でデフォルトのキュー設定に切り替える といった議論が進められており、
 RabbitMQ を使っている方には益がある内容だと思いますので、是非ご一読いただければと思います。

第5回ICTトラブルシューティングコンテストにOpenStackを導入してみた

こんにちは、電気通信大学 学部3年の森 優輝です。
2016年2月27,28日に開催されました第5回ICTトラブルシューティングコンテスト(以後トラコン)にて運営委員を務め、主に運営サーバーの構築を担当しました。
ありがたいことにツチノコの仲間に入れてもらいました。ありがとうございます。

今回のトラコンはDMM.com Labのみなさまも大人枠で参戦いただきました(第5回ICTトラブルシューティングコンテスト結果)。
ありがとうございました。

大会の模様はトラコン公式ページにてフォトレポートとして掲載しています。是非そちらもご覧ください。
cloudpack杯 ICTSC5 レポートまとめ

出題した問題の解説はトラコン運営委員によるtech-blogにて近日公開予定です。

OpenStack導入の動機

一番の動機は「チャレンジ!」です。

少し具体的に書きます。

前回の第4回トラコンでは使用したハイパーバイザーにVMware vSphereの評価版を使用していました。
そこから脱却したいという思いがあり、今回はオープンソースなハイパーバイザーであるKVMを採用しようと考えました。

また前回大会の準備では問題VMのテンプレートから全チーム分展開するのにAnsibleを用いる予定でしたが、想像以上にうまくいかず、断念。
そこで今回はあえてプライベートクラウドを構築し、クラウドの利点の1つであるサーバー増減のしやすさを利用できないかと考えました。

そして今年の4月に新バージョン「Mitaka」がリリースされる、話題のOpenStackを使ってみようと考えました、

そういった経緯から、プライベートクラウド基盤としてOpenStack、ハイパーバイザーとしてKVMを採用することにしました。

構成

今回はシンプルな構成を目指しました。

サーバーは2台構成で、片方は管理&コンピュート兼用ノード。もう片方はコンピュートノード。
作成されるVMはそのまま問題用VLANネットワークに所属するようにするため、OpenStackで標準的に使用される仮想ルーターは今回はなし。ネットワークノードも不要。
OpenStackのコンポーネントはインスタンス起動に最低限必要なもののみ。

簡単な構成図は私が懇親会でLTした資料に掲載しています。
ICTSC5 meets…

OpenStackのインストール方法

2台だけの構成ですので、OpenStackのインストールガイドをシェルスクリプトに起こしたものを使用しました。
スクリプトはGitHubにアップしてあります。2,3台構成でサクッと構築する用途に、ご興味あればぜひご活用ください。

VMの提供と問題作成

今回の大会ではサーバーOSとして基本的にはUbuntuを使用し、一部問題でFreeBSDを使用しました。
なんとなくこれらのクラウドイメージファイルを落としてきてOpenStackに登録すればいいや。と軽い気持ちでいましたが、
標準ではCloud-initの力によってSSHは公開鍵認証のみしか受け付けず、ホスト名もインスタンス作成時につけた名前がそのままついたり。

問題ごとにホスト名の変更をAnsibleを用いて行うと聞いていたため、ここではCloud-initはOSイメージから削除し、
必要最低限のパッケージインストール&設定を済ましたものを問題作成者に配布しました。

問題作成者はそのベースイメージからVMを必要な数だけ作成し、問題サーバーを構築してもらいました。
作成完了後はスナップショットをとってもらい、後日全チーム分展開する形をとりました。

サーバー展開方法

今回の大会ではおよそ250-300台のVMを用意しました。
VMの展開は、Ansibleのos_serverモジュールを主に使用しました。Playbookは近日中に公開予定です。

1つ展開に際して工夫した点があります。
問題出題の都合上、問題用サーバーにはチーム別にIPアドレスを固定で割り振る必要があります(例えば10.X.14.2のような。Xはチーム番号)。

任意のサーバーに対して特定のIPアドレスを固定する方法の1つに、DHCPサーバーにてMACアドレスとIPアドレスを紐付ける方法があります。前回大会ではシェルスクリプトを使ってガムシャラにコンフィグ部分を自動生成し、DHCPサーバーの設定ファイルにぺたっと・・・。

今回はOpenStackのポート機能を使用しました。基本的にはこちらもDHCPを利用しますが、感覚的にはあらかじめIPアドレスを割り振ったNICをVMにくっつける、というイメージです(ちょっと詳しい話はこのあたりとかこのあたりを参照)。
この機能をAnsibleから利用するために、os_networkではなくquantum_networkを使用しました。

ハマったところ

・OpenStack管理外のIPアドレスの通信フィルター
VMに設定されるIPアドレスは、OpenStackによって割り当てられたもの以外は基本的に使用できません。VMに入って手動でIPアドレスを違うものに変更すると通信がiptablesによってフィルターされます。
コンテストの性質上、問題の中には悪意のあるサーバーから変な通信が飛んでくるものがあり、悪意サーバーが持つIPアドレスとは異なるアドレスを送信元としてパケットを送出することなどがたまにあります。
そこで、カーネルパラメーターを変更することで、変な通信をiptablesによってフィルタされないようにしました。具体的には

/etc/sysctl.confに以下を追記し、

net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-arptables=0

適用します。

# sysctl -p

こうすることで運営学生が作る変な通信を流すことが可能となりました。

・Ansibleからポートが作れない
AnsibleからVM展開Playbookを適用する際にIPアドレス固定のためのポートを作成するようにしていました。
しかし一般ユーザーからではポートが権限の問題で作成できず、管理者ユーザーが作成したポートが一般ユーザーから見えないというもの。
ここは権限ポリシーを変更することで対処しました。ネットワーク関係はNeutronというコンポーネントが管理しているので、そこのポリシーを変更しました。

# editor /etc/neutron/policy.json
"*_port"と名のついたキーの値をすべて "" に変更。

OpenStackを導入してよかったこと

1. 気軽にサーバー問題の検証ができた
VMの作成が簡単にでき、OSもあらかじめイメージを登録してあったために10~20秒ほどでVMが起動していたためストレスも少なかったと思います。VMware vSphereのWeb Clientは不安定なことなどが多く、取っつきづらい一面があったことから、特にこのように感じられたのかもしれません。

2. Linuxの知識でメンテナンスができた
上で構成図を載せましたが、OpenStackは比較的レガシーなミドルウェアを組み合わせて使ってることが多いため、メンテナンスがしやすかったと感じました。たとえばAnsibleでVMの展開を一気に行おうとしたとき
にMySQLが最大接続数に達していたことが判明しました。スピードを上げるためにMySQLのチューニングを行うことで改善を図った、ということがありました。

3. ディスクイメージのサイズが小さかった
問題の展開前にあった懸念事項に、ストレージは足りるか?というものがありました。いざ300VM弱の展開を終え、dfコマンドを叩いてみると大して容量を使っていないことが判明しました。
展開に使用したベースのイメージはおよそ1GB強あったのですが、1つ1つのインスタンスに割り当てられたディスクイメージの実サイズは数百MBほどで大変驚きました。
ディスクイメージにQCOW2というフォーマットを使用したのですが、QCOWは”QEMU Copy on Write”の略で、ベースイメージの差分だけを保存できる仕組みになっていたようです。(Dockerも似たような感じだったと記憶しています。)
そのおかげで展開時のIO負荷も少なく済んだと思います。

まとめ

この記事ではトラコンの運営サーバーにOpenStackを導入したお話を書きました。
一応は大きな障害もなく、基本的には問題なくサーバーの提供が出来ていたと思います。
私自身、今回のようなOpenStack環境(約300VMが立ったり、Linux BridgeでVMとVLANネットワークを直接つないだり)は初めてでしたが、なんとかなりました。
VMの展開もAnsibleを用いて無事にでき、また大きなトラブルもありませんでした。
今更ですが、OpenStackの内部で動いているWorkerを増やすなどのパフォーマンスチューニングもしてみればよかったなあとも思っています。

これは個人的な想いなのですが、なんとかして参加者にVMのコンソール画面を参加者に提供したいです。
サーバー側のネットワーク設定が悪く疎通がとれないような場合やPXEブートなどを想定した問題が出題可能となり、問題の幅がより広がるのではないかと思っています。

インターネットが当たり前になり、クラウドも当たり前になりつつある今、クラウド特有のトラブルを出題することを考えてもいい頃かもしれません。

今回はOpenStack+KVMを基盤に使用しましたが、次回のサーバー基盤はどういう構成になるでしょうか。サーバーだけでなく、どんなコンテストになるのでしょうか。まだ何も決まっていません。
トラコンの運営に興味を持った方、ぜひ第6回トラコン 大阪の陣にて一緒に運営やりましょう!

改めて、cloudpack杯 第5回ICTトラブルシューティングコンテストに協賛いただいた企業様をはじめ、参加されたみなさま、そして運営委員&実行委員には大変感謝しております。本当にありがとうございました。

第5回ICTトラブルシューティングコンテスト結果

2/27, 28 に 学生による学生のためのインフラトラブルシューティングコンテスト ICTSC 第5回 cloudpack 杯 が開催されました。

IMG_8397
最優秀賞は早稲田大学のチーム “MWWC” の皆さんです。おめでとうございます!

IMG_8392
優秀賞は東北電子専門学校のチーム “I WAN PUNK MAN’s” の皆さんです。おめでとうございます!

去年の夏に開催された第4回ツチノコ杯での出題を見て「これは楽しそう、大人チームとして解いても絶対おもしろいはず」とブログに書いたら、実行委員会の伊勢さんより「出る???」とのお誘いをいただき、私どもも参加してまいりました。「Exhibition 大人げないチーム」

学生による学生のためのコンテストですが、大人も全員が大人げなくエキサイトして楽しめました。基礎的な問題からマニアックな問題もあり、出題者も選手も皆さん楽しんでやっていましたね(運営側もリアル・トラブルシューティングがありました)。ちょっとひねりが効きすぎている出題もあり、難易度が高くともスキルがあれば必ず解ける問題だとよいのかな、とはいえ現実世界のトラブルシューティングはもっとおかしなものもたくさんありますからね…

大人チームの結果 >>>2位<<< ぐぬぬぬぬ。。MWWCチーム凄い…。

IMG_8382
結果はまあいいじゃないか

# 言い訳すると大人チームメンバーが朝起きられなかったとか、問題の機器の設定が正しく行われていなかったとかでハンデがあったんだ!!!

  • チームワーク大切
  • 何問かが同時に出題され、チームメンバー各位が「私これやりまーす」「これやったらいいんじゃない」のようにふわっと担当を決めていました。ひとつの対象機器に二人以上の担当がつくことがあり、本来ならば作業が衝突しないようコミュニケーションを密にすべきでしたが、ふわっとしすぎて各々が自由に探った結果「あれ? いま何かやった?」のようなことが何度か発生。証拠を保全すべきだったものを復活できない状態にしてしまい、手がかりを掴んだが時すでに遅し、のような典型的ミスをやらかしました。
  • 事前準備大切
  • 選択したコミュニケーションツールが適切でなかったり、「コンソールケーブル持って行ったほうがいいかなぁ」「有線LANインタフェイス持っていったほうがいいかなぁ」「多分あったほうがいいんじゃないかなぁ」← 必須でした。ないと何もできませんw
  • 視野を広く
  • トラシューがテーマのはずなので、出題環境が正常に構成されていればあまり変なことにはなっていないはずなんですよね。だから「こういう問題の該当箇所は難読化するはず」「なんかこの問題だけ難易度が低いから出題意図は別のところにあるはずだ」「このトラブル、どこまでがお題なのか…」などと考えたらだいたい外しています。

いやぁ、お恥ずかしい。大人もヘマします。
すばらしく楽しいイベントでした。次回ICTSC6は大阪開催との噂ですよ。